cyber security incident response plan example

Enterprise Cybersecurity Incident Response Framework

Document Control

• Document ID: [__________]
• Version: [1.0.0]
• Effective Date: [YYYY-MM-DD]
• Review Cycle: [Annual / Bi-annual]

---

1. Purpose & Scope

This policy establishes the standardized framework for detecting, responding to, and recovering from information security incidents at [Company Name]. This document applies to all employees, contractors, and third-party vendors with access to [Company Name] information systems.

2. Prerequisites

• Emergency Communication: Access to [Secure Messaging Platform/Out-of-Band Channel].
• Access Control: Privileged administrative credentials stored in [Password Vault Name].
• Forensic Tools: Access to [EDR/SIEM/Forensic Imaging Toolset].
• Documentation: Access to the [Incident Log/Centralized Repository].

3. Roles & Responsibilities (RACI)

4. Step-by-Step Procedure

Phase 1: Identification & Triage

• Verify the report of the potential incident via [Primary Monitoring Tool].
• Determine the scope of impact (systems, data sensitivity, user accounts).
• Assign an Incident Severity Level: [Low/Medium/High/Critical].
• Notify the Incident Commander: [Name/Pager Alias].

Phase 2: Containment

• Implement short-term containment (e.g., isolate affected hosts, disable compromised accounts).
• Capture forensic evidence (memory dumps, logs, disk images) before system reboot.
• Implement long-term containment (e.g., firewall rule changes, patch deployment).

Phase 3: Eradication

• Identify the root cause (e.g., malware, unauthorized access, misconfiguration).
• Remove the threat (e.g., delete malicious files, re-image infected systems).
• Reset credentials for all potentially compromised accounts.

Phase 4: Recovery

• Restore services from clean backups verified on [Date].
• Perform vulnerability scanning to ensure the environment is hardened.
• Monitor systems for signs of re-infection or anomalous behavior for [Number] days.

Phase 5: Lessons Learned

• Conduct a post-incident review meeting within [Number] business days.
• Document all timeline gaps and communication failures.
• Update [Policy/Control Name] based on incident findings.

---

5. Quality Assurance, Pro-Tips, and Pitfalls

Quality Assurance

• All incident logs must be timestamped and cryptographically signed.
• Evidence handling must follow [Standard/Legal Requirement] chain-of-custody protocols.

Pro-Tips

• Out-of-Band Communication: Never use internal email if the incident involves a potential compromise of the mail server. Use a pre-established external channel.
• Automation: Use playbooks for repetitive tasks like account lockout or firewall shunning to reduce Mean Time to Respond (MTTR).

Common Pitfalls

• Ignoring Legal: Failing to involve Legal Counsel early can jeopardize attorney-client privilege during forensic investigations.
• Premature Recovery: Rushing to restore systems before the root cause is fully eradicated often leads to re-infection.

---

6. FAQs

Q: Who triggers the declaration of a formal security incident? A: Any employee who suspects a breach must report it to [Security Email/Phone Number]. The Incident Commander then officially declares the severity level.

Q: When should we involve external law enforcement? A: Consult with [Legal Counsel Name] immediately if the incident involves personal identifiable information (PII) theft, extortion, or significant financial loss.

Q: How do we handle communication with the public? A: All external communications must be approved by [Communications/PR Department] to ensure compliance with regulatory disclosure requirements.