Security Breach Incident Report Template

Standard Operating Procedure: Security Breach Incident Report Template

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Operational Boundaries

This Standard Operating Procedure (SOP) defines the mandatory lifecycle for identifying, containing, investigating, reporting, and closing security breaches across all enterprise information systems, cloud environments, and physical data facilities. This protocol governs all corporate entities, third-party vendors with direct network access, and contracted managed service providers (MSPs).

2.2 Regulatory Standards & Frameworks

Execution of this procedure ensures continuous alignment with and adherence to the following regulatory mandates and security frameworks:

• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide.
• ISO/IEC 27001:2022: Information Security Management Systems (Clause 16: Information Security Incident Management).
• GDPR (General Data Protection Regulation): Article 33/34 requirements for 72-hour supervisory authority and data subject notifications.
• CCPA / CPRA: California Consumer Privacy Act breach definitions and remediation thresholds.
• PCI-DSS v4.0: Requirement 12.10 (Incident Response Plan for payment card environments).
• HIPAA Security Rule: 45 CFR § 164.308(b) (Security Incident Procedures).

---

3. Prerequisites & Tool Requirements

Execution of this SOP requires authorized personnel to possess specific access rights, certified competencies, and specialized operational equipment.

3.1 Technical Access & Software Tools

• Security Information and Event Management (SIEM): Enterprise deployment (e.g., Splunk Enterprise Security, Microsoft Sentinel) with administrative query access.
• Endpoint Detection and Response (EDR): Centralized control plane (e.g., CrowdStrike Falcon, SentinelOne) capable of real-time machine isolation.
• Forensic Imaging Utilities: Certified write-blockers and acquisition suites (e.g., EnCase, FTK Imager, Volatility for memory dumps).
• Ticketing & Incident Management: Enterprise ITSM (e.g., ServiceNow Security Incident Response) configured with restricted-access security containers.
• Out-of-Band Communication: Encrypted messaging platform (e.g., Signal Enterprise, Wickr) and dedicated conference bridge for crisis response teams.

3.2 Certifications & Qualifications

• Incident Commanders must hold active industry certifications, including CISSP, GIAC Certified Incident Handler (GCIH), or CompTIA Advanced Security Practitioner (CASP+).
• Forensic analysts must be certified in digital forensics (e.g., GCFA, EnCE).

---

4. Roles & Responsibilities (RACI Matrix Table)

---

5. Step-by-Step Operational Procedure

Phase 1: Detection, Triage, and Validation

• 1.1 Receive security alert from SIEM, EDR, user report, or external threat intelligence feed.
• 1.2 Log initial indicators of compromise (IoCs), timestamps, and affected assets in the ServiceNow Security Incident Response module.
• 1.3 Conduct preliminary triage to differentiate between false positives and confirmed malicious activity within 15 minutes of alert generation.
• 1.4 Validate severity classification (Sev-1: Critical Enterprise Impact; Sev-2: Major Incident; Sev-3: Moderate/Localized; Sev-4: Minor/Low Risk).
• 1.5 Convene the Incident Response triage channel and assign the Incident Commander (IC) role if severity is rated Sev-1 or Sev-2.

Phase 2: Containment, Eradication, and Evidence Preservation

• 2.1 Execute immediate containment protocols (network segmentation, IP blacklisting, or host isolation via EDR) to prevent lateral movement.
• 2.2 Preserve volatile system memory (RAM) and storage states on compromised hosts prior to remediation for forensic analysis.
• 2.3 Generate cryptographic hashes (SHA-256) for all acquired disk images and log files to ensure chain of custody integrity.
• 2.4 Identify vector of entry, root cause, and associated vulnerabilities (CVEs) exploited by the threat actor.
• 2.5 Eradicate malicious artifacts, close exploited vectors, revoke compromised credentials, and patch vulnerable configurations.

Phase 3: Forensic Analysis and Documentation

• 3.1 Complete deep-dive forensic analysis of memory dumps, registry hives, network traffic captures (PCAPs), and event logs.
• 3.2 Map threat actor behaviors, persistence mechanisms, and exfiltrated datasets against the MITRE ATT&CK framework.
• 3.3 Draft the core sections of the Security Breach Incident Report, detailing timeline, impact radius, and technical root cause.
• 3.4 Submit technical findings to the DFIR Lead and General Counsel for independent verification.

Phase 4: Executive Reporting and Regulatory Notification

• 4.1 Assemble the final Incident Report package using the mandatory template structure (Section 5.1).
• 4.2 Brief the CISO, General Counsel, and Executive Leadership on operational impact and data exposure risk.
• 4.3 Evaluate data exfiltration logs against GDPR, HIPAA, and state privacy mandates to determine statutory notification requirements.
• 4.4 Draft and dispatch required regulatory disclosures within the statutory timeframes (e.g., 72 hours for GDPR supervisory authorities).
• 4.5 Issue internal communications and external stakeholder notifications under the direction of Legal Affairs and PR.

Phase 5: Post-Incident Review and Closure

• 5.1 Restore systems to production following multi-factor validation, integrity checks, and vulnerability re-scanning.
• 5.2 Conduct a mandatory "Lessons Learned" post-mortem meeting with all key stakeholders within 5 business days of incident closure.
• 5.3 Update enterprise security controls, SIEM correlation rules, and firewall rule-sets based on post-incident recommendations.
• 5.4 Archive all incident artifacts, forensic images, and final reports in immutable, encrypted storage for a minimum retention period of 7 years.
• 5.5 Formally close the incident ticket in the enterprise ITSM platform.

5.1 Mandatory Incident Report Template Structure

When completing the final report documentation, analysts must strictly adhere to the following schema:

1. Header Information: Incident ID, Date/Time Logged, Severity Level, Incident Commander.
2. Executive Summary: High-level narrative of the event for non-technical leadership.
3. Chronological Timeline: UTC-stamped sequence of events from initial compromise to containment.
4. Scope of Impact: Enumeration of compromised endpoints, servers, databases, and exposed data categories (PII, PHI, IP).
5. Root Cause Analysis (RCA): Deep technical explanation of vulnerabilities exploited and entry vectors.
6. Remediation & Corrective Actions: Immediate fixes deployed and long-term preventative controls scheduled.
7. Sign-Off Block: Formal approvals from Incident Commander, CISO, and General Counsel.

---

6. Quality Assurance & Verification Criteria

6.1 Audit Checklist

• Chain of Custody: Every acquired forensic artifact must have a completed, signed digital chain of custody log recording transfer of ownership.
• Containment SLA: Time-to-Contain (TTC) for Sev-1 incidents must not exceed 60 minutes from initial validation.
• Notification SLA: Regulatory notifications must be reviewed by Legal and dispatched with a minimum 12-hour buffer ahead of statutory deadlines.
• Data Integrity: Cryptographic verification (SHA-256) of forensic images must match pre- and post-transfer calculations with zero bit-rot or corruption.

6.2 Tolerance Thresholds & Acceptance Benchmarks

• False Positive Rate: Daily security alert false-positive triage error rate must remain below 3.5%.
• Report Completion Window: Final Incident Report must be fully authored, reviewed, and signed within 10 business days post-incident closure.

---

7. Practical Troubleshooting Scenarios

Scenario A: EDR Agent Fails to Isolate a Compromised Domain Controller

• Symptom: The central EDR console returns a command timeout error when attempting remote network isolation on an active domain controller exhibiting ransomware behavior.
• Immediate Corrective Action Protocol:
  1. Do not reboot the server, as this destroys volatile cryptographic keys in RAM.
  2. Direct the network operations team to execute out-of-band switchport shutdown (port security disable) or apply a temporary ACL block at the core router level to sever network connectivity.
  3. Deploy local administrative scripts via PowerShell Out-of-Band management (iLO/iDRAC) to terminate rogue processes and stop active directory replication services.
  4. Escalate immediately to the Infrastructure Lead to physically inspect and disconnect redundant network interface cards (NICs) if software-level isolation fails.

Scenario B: Massive Log Volume Exhausts SIEM Storage During an Active Attack

• Symptom: SIEM ingestion pipeline drops logs due to license capacity exhaustion or disk-space thresholds being reached during a distributed brute-force event.
• Immediate Corrective Action Protocol:
  1. Access the SIEM administration console and immediately adjust ingestion filters to drop verbose, non-critical debug logs (e.g., standard HTTP 200 GET requests) while prioritizing authentication, firewall, and EDR telemetry.
  2. Provision emergency hot-bucket storage allocation via cloud administration tooling or secondary cold-storage buckets.
  3. Spin up a localized, isolated secondary collector instance (e.g., standalone Graylog or fluentd node) to ingest raw packet captures and local host logs directly from critical assets until central storage capacity is restored.
  4. Document all log retention gaps in the final Incident Report to maintain compliance transparency.

Scenario C: Key Stakeholder Unavailable During Critical Severity Incident

• Symptom: The designated General Counsel or CISO cannot be reached via primary or secondary mobile channels during a Sev-1 midnight incident.
• Immediate Corrective Action Protocol:
  1. Initiate the secondary escalation tree defined in the enterprise Business Continuity Plan (BCP), which identifies pre-approved deputy legal counsel and interim security deputies.
  2. If secondary contacts are unreachable within 30 minutes, the Incident Commander is authorized to execute standard containment protocols and mandated regulatory notifications under emergency delegation of authority clauses.
  3. Log all attempted communication timestamps and transmission failures in the incident timeline for subsequent audit review.