Security Incident Report Template

Standard Operating Procedure: Security Incident Report Template

Document ID: SOP-SEC-042
Classification: Enterprise Internal / Restricted

---

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Purpose

This Standard Operating Procedure (SOP) defines the mandatory lifecycle, governance framework, and forensic documentation standard for the collection, escalation, remediation, and archival of security incidents across all enterprise assets. It ensures absolute uniformity, defensibility, and regulatory compliance in organizational responses to security breaches.

2.2 Operational Boundaries

This procedure applies to all corporate networks, cloud environments (IaaS, PaaS, SaaS), endpoint devices, intellectual property repositories, and physical data facilities owned, leased, or managed by the enterprise or its direct subsidiaries.

2.3 Regulatory Standards & Frameworks

Execution of this SOP guarantees strict alignment with:

• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide.
• ISO/IEC 27001:2022 / 27035: Information Security Incident Management.
• GDPR Article 33/34: 72-hour supervisory authority and data subject notification mandates.
• HIPAA / PCI-DSS v4.0: Data integrity, access controls, and forensic preservation standards.

---

3. Prerequisites & Tool Requirements

Execution of this workflow requires authorized personnel to possess specific access credentials, hardware, and software tooling prior to incident triage.

3.1 Software & System Access

• SIEM / XDR Platform Access: Splunk Enterprise Security, CrowdStrike Falcon, or Microsoft Sentinel (Level 3 Analyst privileges or higher).
• Ticketing & Incident Management: ServiceNow Security Operations (SecOps) module or Jira Service Management (Enterprise Tier with restricted security project permissions).
• Forensic & Acquisition Suites: EnCase, FTK Imager, Volatility Framework (v3+), or cloud-native forensic collection scripts (AWS CloudTrail/GuardDuty access, Azure Security Center).
• Secure Collaboration: Signal Enterprise or Wickr Pro (for out-of-band incident commander communication).

3.2 Hardware & Physical Equipment

• Write-blockers (hardware/software SATA/NVMe/USB blockers).
• Certified pristine forensic acquisition drives (Wiped per DoD 5220.22-M standard).
• Faraday bags/boxes for mobile device and endpoint isolation.

3.3 Certifications & Clearances

• Personnel executing containment or forensic acquisition must hold active internal Incident Responder Tier 2 (IR-2) status or higher, alongside industry certifications (e.g., CISSP, GCIH, GCFA, OSCP).

---

4. Roles & Responsibilities (RACI Matrix Table)

(Key: Responsible – executes the work; Accountable – final owner/approver; Consulted – provides input; Informed – kept updated)

---

5. Step-by-Step Operational Procedure

[Detection & Triage] ---> [Containment] ---> [Eradication & Recovery] ---> [Forensic Analysis] ---> [Reporting & Closure]

Phase 1: Detection, Triage, and Scoping

• 1.1 Ingest automated alert from SIEM/XDR or manual ticket via ServiceNow; assign unique Incident ID format (INC-YYYYMMDD-XXXX).
• 1.2 Verify alert validity to rule out false positives within 15 minutes of initial notification.
• 1.3 Establish severity rating based on impact matrix:
  • Sev 1 (Critical): Active data exfiltration, ransomware deployment, enterprise-wide service disruption.
  • Sev 2 (High): Isolated host compromise, credential stuffing with successful access, unauthorized privilege escalation.
  • Sev 3 (Medium): Policy violation, malware detected and blocked at endpoint, reconnaissance scanning.
  • Sev 4 (Low): Benign anomalies, dropped perimeter probes.
• 1.4 Convene initial bridge line with SecOps Lead if severity is rated Sev 1 or Sev 2.

Phase 2: Containment (Short-term & Long-term)

• 2.1 Isolate compromised endpoints from the network immediately via EDR network-quarantine command (preserving volatile RAM where feasible).
• 2.2 Revoke active session tokens, force password resets, and disable compromised IAM identities within Active Directory / Azure AD / Okta.
• 2.3 Implement emergency firewall, WAF, or network segmentation rules to block malicious IP/domain IOCs (Indicators of Compromise).
• 2.4 Validate containment effectiveness by re-running network traffic and behavioral telemetry queries.

Phase 3: Eradication and System Recovery

• 3.1 Identify root cause vector (e.g., zero-day exploit, phishing payload, misconfigured S3 bucket).
• 3.2 Remove malicious persistence mechanisms (scheduled tasks, unauthorized root accounts, modified binaries, web shells).
• 3.3 Patch underlying vulnerabilities or apply compensating controls.
• 3.4 Restore affected systems from verified, uncompromised golden images or immutable backups.
• 3.5 Bring restored assets back online in a monitored, phased rollout (canary deployment).

Phase 4: Forensic Preservation and Evidence Chain of Custody

• 4.1 Capture volatile memory (RAM) dumps prior to powering down physical assets.
• 4.2 Generate bit-stream forensic disk images (E01 or RAW format) using write-blockers.
• 4.3 Calculate cryptographic hashes (SHA-256) of all collected artifacts and log them in the Master Evidence Log.
• 4.4 Store physical and digital media in a secure, access-controlled evidence locker or encrypted storage bucket (/secure/forensics/INC-YYYYMMDD-XXXX).

Phase 5: Incident Report Generation & Closure

• 5.1 Complete all fields within the standardized Security Incident Report Template (Section 6 format).
• 5.2 Submit report to CISO and Legal Counsel for review and regulatory assessment (GDPR/HIPAA timers).
• 5.3 Conduct mandatory Post-Incident Review (PIR) / "Blameless Post-Mortem" within 5 business days of closure.
• 5.4 Archive all tickets, logs, and forensic artifacts with a retention period of no less than 7 years (or per regulatory mandate).

---

6. Quality Assurance & Verification Criteria

To ensure institutional rigor, every completed incident report must pass the following QA checklist before administrative sign-off is granted.

6.1 Audit Checklist

• Timeline Integrity: Event timeline must be chronological, precise to the millisecond (UTC), and reconcile log sources across network, host, and application layers.
• Root Cause Completeness: The vector of entry must be definitively identified; "Unknown" is only permissible with written CISO sign-off and documented obstruction factors.
• Cryptographic Verification: All forensic evidence items must show matching SHA-256 hashes between collection time and archival storage.
• Legal Review Stamp: Incidents involving PII, PHI, or intellectual property loss must carry documented sign-off from Enterprise Legal Counsel regarding regulatory disclosure obligations.

6.2 Tolerance Thresholds & Acceptance Benchmarks

• Mean Time to Detect (MTTD): $\le 15 \text{ minutes}$ for Sev 1/2 incidents.
• Mean Time to Contain (MTTC): $\le 60 \text{ minutes}$ from detection for Sev 1 incidents.
• Report Finalization Window: Draft report completed within 24 hours of incident containment; final administrative closure within 10 business days.

---

7. Practical Troubleshooting Scenarios

Scenario A: Encrypted Endpoint / Active Ransomware Execution

• Symptom: EDR telemetry reports mass file-renaming operations, CPU spikes, and shadow copy deletions across multiple departmental file shares.
• Immediate Corrective Action Protocol:
  1. Instant Isolation: Issue immediate network isolation command via EDR. Do not shut down or reboot the machine (preserves ransomware encryption keys in RAM).
  2. Segment Isolation: If network segmentation fails to propagate via EDR, issue emergency BGP null-route or port-shutdown commands at the switch/VLAN level for the affected subnet.
  3. Backup Verification: Immediately verify integrity and air-gap status of primary immutable backup repositories.
  4. Escalation: Notify CISO, Legal, and external Incident Response retainer partners within 30 minutes.

Scenario B: Compromised Cloud Service Account (Privileged IAM)

• Symptom: CloudTrail/Cloud Audit logs show anomalous API calls from foreign jurisdictions using a master administrator IAM user, accompanied by mass resource creation (EC2 cryptomining instances).
• Immediate Corrective Action Protocol:
  1. Credential Revocation: Immediately execute an automated script or manual console action to invalidate all active sessions, delete active access keys, and attach an "Deny-All" explicit IAM inline policy to the compromised account.
  2. Scope Assessment: Query cloud audit logs using Athena/Log Insights to extract all actions performed by the compromised account between the estimated compromise window and remediation time.
  3. Resource Terminations: Terminate unauthorized compute, storage, or networking assets provisioned by the attacker.
  4. Infrastructure Review: Inspect CloudFormation/Terraform state files and IAM trust relationships for backdoors or newly established rogue roles.

Scenario C: Forensic Contamination / Chain of Custody Failure

• Symptom: During audit review, it is discovered that an unverified system administrator rebooted a compromised server prior to RAM acquisition, altering volatile artifacts.
• Immediate Corrective Action Protocol:
  1. Documentation: Immediately document the exact nature of the procedural breach, including timestamp, user identity, and actions taken, directly within the Master Evidence Log.
  2. Fallback Collection: Pivot to alternative forensic data sources (e.g., hypervisor-level memory snapshots, network flow logs, centralized SIEM logs, proxy logs) to corroborate missing volatile data.
  3. Legal Notification: Inform Legal Counsel immediately of the compromise in chain of custody to evaluate evidentiary admissibility in potential litigation or law enforcement proceedings.
  4. Corrective Administrative Action: Issue a formal operational warning and mandatory retraining ticket to the individual responsible for the operational deviation.