Cis Incident Response Plan Template

Standard Operating Procedure: Incident Response (IR) Framework

Author: Julian Vance, Chief Architect
Department: Engineering & Security Operations
Classification: Internal / Confidential

---

1. Document Control Block

---

2. Executive Summary & Purpose

This document establishes the institutional-grade Incident Response Plan (IRP) aligned with CIS Critical Security Controls. The purpose is to provide a structured, repeatable methodology for detecting, containing, eradicating, and recovering from cybersecurity incidents to minimize business disruption and data exfiltration.

---

3. Scope & Prerequisites

• Scope: All digital assets, cloud environments (AWS/Azure/GCP), physical hardware, and endpoints managed by Template Registry.
• Prerequisites:
  • Access to SIEM/EDR consoles (e.g., Splunk, CrowdStrike).
  • Verified communication channels (Out-of-Band Signal/Slack).
  • Operational VPN access with MFA.
  • PPE/Hardware: Hardware security keys (YubiKey), encrypted incident-specific storage, hard-copy escalation list.

---

4. Roles & Responsibilities (RACI Matrix)

---

5. Step-by-Step Procedure

Phase 1: Detection & Analysis

• Validate alert trigger via SIEM/EDR log correlation.
• Determine incident severity (Low/Medium/High/Critical) per impact matrix.
• Initialize "Incident War Room" (Out-of-Band communication channel).

Phase 2: Containment

• Execute short-term isolation (e.g., segment network, revoke compromised credentials).
• Capture volatile memory (RAM dumps) and disk snapshots for forensic analysis.
• Implement "Read-Only" state on affected production databases if required.

Phase 3: Eradication

• Identify root cause (e.g., misconfiguration, phishing, zero-day).
• Remove malicious artifacts, backdoors, or unauthorized accounts.
• Rebuild compromised systems from hardened, verified "Golden Images."

Phase 4: Recovery

• Restore operations via phased, validated deployment.
• Increase logging granularity on recovered assets for 48 hours.
• Perform integrity validation checks to confirm no persistence remains.

Phase 5: Post-Incident Activity

• Conduct "Lessons Learned" meeting within 72 hours of closure.
• Update documentation and IRP based on procedural gaps.
• Generate final Incident Report for executive stakeholders.

---

6. Quality Assurance & Pro-Tips

• Metric Thresholds:
  • MTTD (Mean Time to Detect): < 30 minutes.
  • MTTR (Mean Time to Recover): < 4 hours for critical services.
• Pro-Tip: Never perform live debugging on a compromised host; always clone the volume for forensics first.
• Common Pitfall: Failing to document forensic steps contemporaneously. Log every action taken during the response.

---

7. Frequently Asked Questions

Q: At what point do we contact external legal counsel?
A: Immediately upon determination that a "Data Breach" (unauthorized access to PII/Sensitive data) has occurred, or if required by regulatory mandates (GDPR/CCPA).

Q: Should we shut down systems immediately upon discovery?
A: No. Improper shutdown can destroy volatile memory evidence. Follow the Containment phase steps to isolate network traffic while preserving machine state.

---

End of Document