Security Incident Investigation Report Template

Standard Operating Procedure: Security Incident Investigation Report Template

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

---

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Operational Boundaries

This Standard Operating Procedure (SOP) governs the standardized creation, authorization, and archival of Security Incident Investigation Reports within the enterprise ecosystem. This protocol applies to all information systems, cloud environments, endpoint devices, and physical facilities under enterprise operational control. It mandates the collection, handling, analysis, and reporting methodology for any confirmed or suspected compromise of confidentiality, integrity, or availability.

2.2 Regulatory Standards

All investigations executed under this framework must maintain strict alignment with established international and industrial regulatory mandates, including:

• ISO/IEC 27035: Information technology — Security techniques — Information security incident management.
• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide.
• GDPR (Article 33/34): Data protection impact assessment and supervisory authority breach notification timelines.
• PCI-DSS v4.0 (Requirement 12.10): Incident response programs for entities handling cardholder data.

---

3. Prerequisites & Tool Requirements

Prior to initiating an investigation and drafting the incident report, investigators must verify access to and operational readiness of the following assets:

• Hardware / Equipment:
  • Forensically isolated hardware write-blockers (Tableau T8u or equivalent).
  • Certificated Write-Protected Evidence Storage Drives (LTO-8 or encrypted external SSDs).
  • Air-gapped triage workstation operating a verified Linux/Windows forensic environment.
• Software & Tool Access:
  • EDR Platform Access (CrowdStrike Falcon, Microsoft Defender for Endpoint) with administrative containment permissions.
  • SIEM / Log Aggregation Engine (Splunk Enterprise Security, Elastic SIEM) with query permissions.
  • Forensic Acquisition Suites (FTK Imager, Volatility Framework, EnCase, or open-source equivalents).
  • Enterprise Ticketing and Incident Management platform (Jira Service Management, ServiceNow SecOps).
  • Secure Evidence Repository with immutable logging (AWS S3 Object Lock or equivalent WORM storage).
• Certifications & Clearances:
  • Investigators must hold active GIAC Certified Incident Handler (GCIH), Certified Information Systems Security Professional (CISSP), or Certified Forensic Examiner (GCFE/GCFA) credentials.
  • Level 3 Security Clearance within the enterprise access control list.

---

4. Roles & Responsibilities (RACI Matrix Table)

(Definitions: Responsible = The doer; Accountable = The owner; Consulted = Subject matter input; Informed = Kept updated)

---

5. Step-by-Step Operational Procedure

Phase 1: Triage, Scoping, and Intake

• 1.1 Receive automated or manual security alert via the enterprise ticketing system and assign a unique Incident Identification Number (INC-YYYY-XXXX).
• 1.2 Verify the authenticity of the alert and conduct an initial blast-radius assessment to determine affected systems, business units, and data classifications.
• 1.3 Convene the initial incident response triage bridge with the Security Operations Lead (SOL).
• 1.4 Formally open the Master Incident Log, recording exact UTC timestamps for all subsequent actions.

Phase 2: Evidence Acquisition & Chain of Custody

• 2.1 Isolate compromised endpoints or network segments using EDR network containment protocols to prevent lateral movement without destroying volatile RAM.
• 2.2 Execute volatile memory (RAM) acquisition on target hosts utilizing certified tools prior to system power-down.
• 2.3 Perform bit-stream forensic imaging of storage media using hardware write-blockers.
• 2.4 Calculate cryptographic hashes (SHA-256 and MD5) for all acquired evidence images and log them in the Chain of Custody manifest.
• 2.5 Transfer acquired evidence to the secure, immutable evidence repository and secure physical media in a biometric-controlled evidence locker.

Phase 3: Technical Analysis & Root Cause Determination

• 3.1 Extract and parse artifact logs (Windows Event Logs, auth.log, cloudTrail, VPC Flow logs) relevant to the incident window.
• 3.2 Perform static and dynamic malware analysis within an isolated sandbox environment to extract Indicators of Compromise (IoCs).
• 3.3 Reconstruct the attack timeline using MITRE ATT&CK framework tactical mappings (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Impact).
• 3.4 Identify the definitive root cause vector (e.g., unpatched vulnerability, phishing credential harvest, misconfigured S3 bucket).

Phase 4: Report Drafting & Executive Summarization

• 4.1 Populate the standardized Security Incident Investigation Report template with empirical technical findings.
• 4.2 Draft the Executive Summary avoiding excessive technical jargon, explicitly detailing business impact, data exposure metrics, and financial risk exposure.
• 4.3 Compile the complete timeline of events, incorporating raw log snippets and forensic exhibits as appendices.
• 4.4 Include specific preventative and corrective recommendations categorized by immediate, medium-term, and long-term remediation milestones.

Phase 5: Review, Sign-off, and Archival

• 5.1 Submit the draft investigation report to the Security Operations Lead (SOL) for technical peer review.
• 5.2 Escalate the report to Legal Counsel (LC) if regulatory notification triggers are met.
• 5.3 Secure final sign-off approval from the Chief Information Security Officer (CISO).
• 5.4 Archive the final report, evidence logs, and communication transcripts in the secure vault with a retention classification matching corporate compliance policy (minimum 7 years).

---

6. Quality Assurance & Verification Criteria

6.1 Audit Checklist

• Completeness: Every section of the report template contains verified data; no legacy placeholder text remains.
• Chronological Accuracy: All event timestamps are explicitly converted and aligned to Coordinated Universal Time (UTC).
• Cryptographic Integrity: SHA-256 verification hashes for all forensic artifacts match pre- and post-transfer records.
• Regulatory Compliance: Timelines for notification align with statutory requirements (e.g., 72-hour GDPR window if PII was accessed).
• Attribution Validity: Claims of threat actor identity or intent are supported by at least two distinct intelligence sources or verified behavioral artifacts.

6.2 Tolerance Thresholds & Benchmarks

• Time-to-Triage (TTT): Initial acknowledgment and classification must occur within $\le 15$ minutes of alert generation.
• Time-to-Containment (TTC): Host isolation or network segmentation must occur within $\le 60$ minutes for critical-severity incidents.
• Report Delivery SLA: The final Security Incident Investigation Report must be completed, reviewed, and delivered to the CISO within $\le 5$ business days following incident closure.

---

7. Practical Troubleshooting Scenarios

Scenario A: Destruction or Volatility of Evidence During Live Capture

• Failure Symptom: The target endpoint crashes or reboots unexpectedly during live volatile memory acquisition, destroying potential RAM artifacts.
• Immediate Corrective Action Protocol:
  1. Cease all interactive attempts to acquire memory from the unstable host to prevent further disk write operations.
  2. Immediately pull network flows, firewall connection states, and hypervisor-level metrics from the upstream infrastructure to capture ephemeral state data.
  3. Execute a bit-stream physical disk image from the storage media via write-blocker to preserve persistent file system artifacts.
  4. Document the unexpected system reboot explicitly in the incident report log, noting the exact UTC timestamp and potential hardware/OS instability vectors as an operational constraint.

Scenario B: Conflicting Timestamps Across Distributed Multi-Cloud Log Sources

• Failure Symptom: SIEM logs, AWS CloudTrail, and local host logs display misaligned timestamps due to clock drift (NTP synchronization failure), obscuring the attack sequence.
• Immediate Corrective Action Protocol:
  1. Identify all NTP configuration drift parameters across the affected hypervisors, domain controllers, and cloud environments.
  2. Cross-reference internal log entries with external, immutable reference points (e.g., authoritative DNS query logs, ISP boundary gateway records, or cryptographic handshake timestamps).
  3. Normalize all reported timeline entries in the investigation report to UTC using the verified delta offset.
  4. Add a dedicated subsection in the report methodology noting the clock skew, the calculated drift variance (e.g., $+42$ seconds), and the mathematical normalization formula applied.

Scenario C: Legal Hold and Privacy Conflict Over Employee PII

• Failure Symptom: Forensic imaging of a compromised corporate laptop captures personal employee data (personal emails, banking credentials, local photos) that triggers regional privacy protections (e.g., GDPR/CCPA).
• Immediate Corrective Action Protocol:
  1. Halt broad-scope keyword searches that expose unneeded personal data; narrow analysis strictly to indicators of compromise and unauthorized access artifacts.
  2. Consult Legal Counsel (LC) immediately to establish a targeted data minimization protocol.
  3. Encrypt and isolate the harvested personal data partitions within the forensic container, ensuring access is strictly restricted to authorized judicial/legal reviewers.
  4. Explicitly document the minimization and masking procedures applied to non-security-relevant personal data within the evidence handling section of the incident report.