Post Security Incident Report Template

Standard Operating Procedure: Post Security Incident Report (PSIR)

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Purpose

This Standard Operating Procedure (SOP) defines the mandatory, repeatable workflow for producing, validating, and archiving a Post Security Incident Report (PSIR) following the containment and eradication of a verified information security event. The PSIR serves as the definitive organizational record for forensic analysis, root cause determination, liability assessment, and operational remediation.

2.2 Operational Boundaries

• In-Scope: All P1 (Critical), P2 (High), and P3 (Moderate) security incidents affecting enterprise-owned cloud infrastructure, on-premises data centers, hybrid environments, corporate endpoints, and third-party SaaS integrations.
• Out-Scope: Routine security alerts that are triaged and closed as false positives within the Security Operations Center (SOC) baseline workflow without escalation.

2.3 Regulatory & Compliance Standards

Outputs generated under this SOP must satisfy evidentiary and reporting mandates set forth by:

• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide (Post-Incident Activity phase).
• ISO/IEC 27035: Information security incident management.
• GDPR (Articles 33 & 34) & CCPA: Data breach notification and forensic documentation requirements.
• PCI-DSS v4.0 (Requirement 12.10.5): Post-incident reviews for cardholder data environments.
• SOC 2 Type II: Trust Services Criteria (Availability and Confidentiality controls).

---

3. Prerequisites & Tool Requirements

3.1 Software & System Access

• SIEM Platform: Splunk Enterprise Security, Datadog, or Microsoft Sentinel (Read/Query access to incident-specific indices).
• EDR/XDR Console: CrowdStrike Falcon, Microsoft Defender for Endpoint, or SentinelOne (Isolation and telemetry review logs).
• Ticketing & Case Management: Jira Service Management, ServiceNow Security Operations (SecOps), or PagerDuty.
• Forensic Storage: Write-blocked, access-controlled S3 bucket or isolated network share with AES-256 encryption at rest for evidence locker integration.
• Documentation Engine: Enterprise Confluence or secure Markdown-based repository with immutable version control.

3.2 Certifications & Qualifications

• Personnel authoring the PSIR must hold at least one of the following baseline credentials: CISSP, GIAC Certified Incident Handler (GCIH), CompTIA CySA+, or CISM.
• Forensic evidence handlers must maintain chain-of-custody tracking certification or internal authorization by the Office of the CISO.

3.3 Safety & Security Equipment

• Zero-trust multi-factor authentication (MFA) hardware tokens for administrative systems access.
• Role-based least-privilege API keys for automated log extraction.

---

4. Roles & Responsibilities (RACI Matrix Table)

Legend:

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

---

5. Step-by-Step Operational Procedure

Phase 1: Data Gathering & Timeline Reconstruction

• 1.1 Initialize the master PSIR case file within the enterprise ticketing system, referencing the primary incident ticket identifier.
• 1.2 Harvest and freeze all relevant telemetry logs (SIEM, firewall, proxy, EDR, and cloud provider audit logs) spanning from $T_{-24\text{h}}$ prior to the earliest indicator of compromise (IoC) through $T_{+12\text{h}}$ post-containment.
• 1.3 Export system state snapshots, memory dumps, and disk images of compromised assets into the secure forensic evidence locker, logging hashes (SHA-256) to verify chain of custody.
• 1.4 Construct a chronological, minute-by-minute timeline of the attack lifecycle, mapping initial access, lateral movement, privilege escalation, and exfiltration attempts against the MITRE ATT&CK framework.

Phase 2: Root Cause Analysis (RCA)

• 2.1 Convene an RCA working session with the Lead Forensic Investigator, System Owners, and Threat Intelligence analysts.
• 2.2 Apply the "5 Whys" methodology or Ishikawa (Fishbone) diagramming to determine the foundational vulnerability or process failure that permitted the incident.
• 2.3 Differentiate between the proximate cause (e.g., stolen credentials) and the root cause (e.g., absence of phishing-resistant MFA enforcement on legacy VPN gateways).
• 2.4 Validate the identified root cause against historical asset inventories and patch management compliance metrics.

Phase 3: Impact & Scope Quantification

• 3.1 Enumerate all affected digital assets, databases, endpoints, and internal microservices, categorizing them by data classification level (Public, Internal, Confidential, Restricted).
• 3.2 Quantify data exposure metrics: Determine exact volume and nature of exfiltrated or accessed Personally Identifiable Information (PII), Protected Health Information (PHI), or intellectual property.
• 3.3 Calculate total business interruption duration (measured from initial disruption to full service restoration).
• 3.4 Estimate direct financial impact, including remediation labor, forensic consulting fees, regulatory exposure, and operational downtime.

Phase 4: Corrective Action Plan (CAP) Formulation

• 4.1 Draft specific, measurable, achievable, relevant, and time-bound (SMART) remediation tasks designed to eliminate the root cause.
• 4.2 Assign ownership and firm deadlines for each Corrective Action (maximum acceptable remediation window: P1 = 14 days, P2 = 30 days, P3 = 60 days).
• 4.3 Define mitigating controls to be deployed immediately if permanent remediation requires extended engineering timelines.
• 4.4 Update the enterprise risk register to reflect residual risk scores post-remediation.

Phase 5: Executive Briefing & Archival

• 5.1 Compile the finalized sections into the standardized PSIR markdown template.
• 5.2 Submit the draft report to Legal Counsel for regulatory liability review and redaction clearance.
• 5.3 Conduct an executive readout with the CISO and Business Unit Owners to secure formal sign-off.
• 5.4 Publish the finalized PSIR to the immutable compliance repository and update the internal knowledge base for SOC training reference.

---

6. Quality Assurance & Verification Criteria

6.1 Audit Checklist

An auditor reviewing a completed PSIR must be able to verify the presence of:

• Unambiguous unique incident tracking ID and classification level.
• A cryptographically verifiable chain of custody for all digital evidence.
• A continuous, gap-free attack timeline mapped to MITRE ATT&CK techniques.
• Explicit identification of both proximate and root causes.
• Quantified impact metrics covering data classification, regulatory exposure, and downtime.
• Named owners and hard target completion dates for every corrective action item.
• Sign-off signatures from both Legal Counsel and the CISO.

6.2 Tolerance Thresholds & Acceptance Benchmarks

• Timeline Completeness: The initial detection timestamp must be accounted for within a $\pm 30$-second margin across log sources.
• Report Delivery SLA: The draft PSIR must be delivered to Legal and the CISO within five (5) business days following incident closure for P1/P2 events; ten (10) business days for P3 events.
• CAP Implementation Adherence: Zero tolerance for overdue corrective actions without an approved formal risk exception waiver signed by the CISO.

---

7. Practical Troubleshooting Scenarios

Scenario A: Fragmented or Corrupted Log Data

• Symptom: Critical log sources (e.g., domain controller security logs or cloud API trails) were overwritten, disabled, or missing during the incident window, preventing precise timeline reconstruction.
• Immediate Corrective Action Protocol:
  1. Pivot immediately to secondary telemetry sources (e.g., EDR telemetry, DNS query logs, netflow data, or edge proxy logs) to reconstruct proxy events.
  2. Issue an emergency out-of-band request to cloud service providers or third-party vendors for raw telemetry backups.
  3. Document the telemetry gap explicitly in the PSIR Scope Limitations section, noting the impact on confidence levels for forensic assertions.
  4. Create an immediate P1 Corrective Action task to enforce centralized, immutable log forwarding (SIEM ingestion hardening) across all critical segments.

Scenario B: Disputed Root Cause Among Stakeholders

• Symptom: Development and Security teams disagree on the root cause; Security points to unpatched application vulnerabilities, while Development points to insufficient infrastructure hardening and edge filtering.
• Immediate Corrective Action Protocol:
  1. Halt single-perspective drafting and invoke an independent technical arbitration session chaired by the Principal Operations Consultant or Lead Forensic Investigator.
  2. Re-examine raw telemetry and source code commits to establish objective proof of exploit execution vectors.
  3. Document both contributing factors in the PSIR under a bifurcated root cause model (e.g., "Primary Vector: Application Vulnerability CVE-XXXX-XXXX; Contributing Factor: Inadequate Network Segmentation").
  4. Mandate joint remediation ownership assigned equally to both engineering and security leads.

Scenario C: Unresponsive Corrective Action Owners

• Symptom: Assigned owners of Corrective Action Plan (CAP) items fail to respond, reject ownership, or miss intermediate milestone deadlines.
• Immediate Corrective Action Protocol:
  1. Send an automated escalation notice via the incident management platform to the delinquent owner's direct supervisor and department head.
  2. If unacknowledged within 48 hours, escalate the item directly to the CISO and Enterprise Risk Committee during the weekly governance review.
  3. Reassign ownership of the stalled CAP item to the Head of Security Operations until a permanent operational owner is formally designated and briefed.