Sample Security Incident Report Template

Standard Operating Procedure: Sample Security Incident Report Template

Document Identifier: SOP-SEC-OPS-042
Classification: Internal Operations / Enterprise Security Governance

---

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Operational Boundaries

This Standard Operating Procedure (SOP) defines the mandatory, standardized lifecycle for identifying, containing, eradicating, recovering from, and reporting information security incidents across all enterprise computational environments, cloud infrastructures, and physical data facilities. This protocol governs all operational units, third-party vendors, and contractors interacting with enterprise information assets.

2.2 Regulatory Standards & Compliance Frameworks

Execution of this SOP ensures strict adherence to the following regulatory and statutory frameworks:

• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide.
• ISO/IEC 27001:2022 / ISO/IEC 27035: Information Security Incident Management.
• General Data Protection Regulation (GDPR): Articles 33 and 34 (Mandatory Data Breach Notification).
• Payment Card Industry Data Security Standard (PCI DSS v4.0): Requirement 12.10 (Incident Response Plan).
• Health Insurance Portability and Accountability Act (HIPAA): Security Rule (45 CFR § 164.308(a)(6)).

---

3. Prerequisites & Tool Requirements

3.1 Hardware, Software, & Access Requirements

• Security Information and Event Management (SIEM): Enterprise deployment (e.g., Splunk Enterprise Security, Microsoft Sentinel) with administrative read/write access.
• Endpoint Detection and Response (EDR): SentinelOne / CrowdStrike Falcon console with remote isolation capabilities.
• Forensic Acquisition Toolkit: EnCase, FTK Imager, or open-source equivalents (Volatility, Sleuth Kit) for live memory and disk image capture.
• Secure Communications Out-of-Band: Encrypted messaging and audio platform (e.g., Signal Enterprise, Wickr Pro) isolated from corporate Active Directory infrastructure.
• Ticketing & Case Management: Jira Service Management (Security Project) or ServiceNow Security Incident Response (SIR) module.

3.2 Certifications & Clearances

• Personnel executing Phases 3 through 6 must maintain active industry certifications, including CISSP, GCIH, GCFA, OSCP, or equivalent internal Tier-3 SOC validation.
• All handlers must possess active corporate background clearances and signed Non-Disclosure Agreements (NDAs) covering high-sensitivity data access.

---

4. Roles & Responsibilities (RACI Matrix Table)

• R (Responsible): The role that performs the activity.
• A (Accountable): The sole role with final approval and ownership.
• C (Consulted): The role providing advisory input.
• I (Informed): The role updated on progress and outcomes.

---

5. Step-by-Step Operational Procedure

Phase 1: Detection, Triage, & Scoping

• 1.1 Receive security alert via SIEM automation, EDR telemetry, or manual employee reporting channel.
• 1.2 Validate alert authenticity to eliminate false positives using baseline asset intelligence and threat feeds.
• 1.3 Classify the incident severity level using the Enterprise Severity Matrix (Sev-1: Critical Enterprise Impact, Sev-2: Major Operational Disruption, Sev-3: Isolated Incident, Sev-4: Minor Anomaly).
• 1.4 Open an official ticket in the Security Incident Case Management system, assigning the unique incident ID (INC-YYYY-XXXX).
• 1.5 Notify the Incident Response Lead and convene the tactical response bridge if severity is rated Sev-1 or Sev-2.

Phase 2: Containment & Evidence Preservation

• 2.1 Execute immediate tactical containment protocols to halt lateral movement (e.g., network isolation via EDR, revocation of compromised OAuth tokens, disabling Active Directory user accounts).
• 2.2 Verify containment efficacy by running verification scans across adjacent subnetworks.
• 2.3 Initiate forensic preservation procedures prior to system remediation.
• 2.4 Capture volatile memory (RAM) and non-volatile storage images of compromised endpoints following chain-of-custody protocols.
• 2.5 Secure and export relevant SIEM logs, firewall flows, and proxy artifacts into the immutable evidence repository.

Phase 3: Eradication & System Recovery

• 2.6 Identify the precise vector of compromise (Root Cause Analysis - RCA) through forensic artifact examination.
• 2.7 Remove all malicious artifacts, backdoors, webshells, and unauthorized user accounts from affected systems.
• 2.8 Patch vulnerable software, update firewall rules, and harden configurations to prevent re-exploitation of the root vector.
• 2.9 Restore systems from verified uncompromised backups or rebuild assets from golden disk images.
• 2.10 Reconnect restored assets to the production network under active monitoring for a minimum observation window of 72 hours.

Phase 4: Post-Incident Reporting & Closure

• 4.1 Complete the mandatory Security Incident Report Template (Section 6.1 format).
• 4.2 Conduct a mandatory "Blameless Post-Mortem" meeting with key stakeholders within 5 business days of incident closure.
• 4.3 Submit the finalized report and compliance artifacts to the CISO, Legal Counsel, and Risk Committee.
• 4.4 Archive all forensic evidence, logs, and case notes in compliance with statutory data retention schedules.
• 4.5 Officially transition the incident ticket status to "Closed - Resolved" in the case management system.

---

6. Quality Assurance & Verification Criteria

6.1 Audit Checklist

• Chain of Custody Integrity: All acquired digital evidence must feature verifiable cryptographic hashes (SHA-256) recorded in the evidence log.
• Containment SLA: Time-to-Contain (TTC) must not exceed 60 minutes for Sev-1 incidents and 4 hours for Sev-2 incidents.
• Notification SLA: Regulatory and legal notifications must be drafted and approved within 24 hours to meet the 72-hour GDPR/compliance threshold.
• RCA Completeness: Root cause must be explicitly defined with technical evidence rather than speculative attribution.

6.2 Acceptance Benchmarks

• Zero recurrence of the identical vector within 90 days post-remediation.
• 100% concordance between forensic logs and the final Incident Report narrative.

---

7. Practical Troubleshooting Scenarios

Scenario A: EDR Isolation Command Fails Due to Network Severance

• Symptom: The malicious host is actively beaconing to Command and Control (C2), but the EDR management plane returns an "Agent Unreachable / Timeout" error when executing an isolation command.
• Immediate Corrective Action Protocol:
  1. Contact the local network operations or data center team to enact port-level isolation or physical port shutdown on the upstream switch/router.
  2. Implement perimeter firewall blocks to drop all egress/ingress traffic originating from the target IP address (SRC_IP) and destination C2 IPs.
  3. If cloud-hosted (AWS/Azure/GCP), execute API-level Security Group detachment or Network Security Group (NSG) isolation directly via the cloud console, bypassing the OS-level EDR agent.

Scenario B: Evidence Collection Destroys Volatile Memory Artifacts

• Symptom: Forensic technician inadvertently reboots or powers down a compromised hypervisor host prior to capturing volatile memory, destroying active RAM artifacts.
• Immediate Corrective Action Protocol:
  1. Immediately halt further destructive actions on the asset and document the exact timestamp and action taken in the incident log.
  2. Pivot to alternative telemetry sources to reconstruct volatile states: review hypervisor logs, kernel crash dumps (/var/crash or MEMORY.DMP), and network flow records (NetFlow/IPFIX) from upstream core routers.
  3. Flag the incident record to denote incomplete RAM acquisition; adjust internal risk scoring to reflect limited visibility into fileless malware execution chains.

Scenario C: Legal Hold Conflict with Automated Data Retention Policies

• Symptom: Automated log rotation or lifecycle policies threaten to overwrite critical log files required for forensic analysis before the investigation concludes.
• Immediate Corrective Action Protocol:
  1. Issue an emergency administrative suspension on all log retention lifecycle policies for the affected storage buckets, SIEM indexes, and backup vaults.
  2. Export point-in-time snapshots of the targeted log indices to an isolated, write-once-read-many (WORM) secure S3 bucket or offline storage array.
  3. Notify General Counsel immediately to formally log the preservation action and confirm legal hold coverage across all interacting systems.