Incident Report Template for Security

Standard Operating Procedure: Incident Report Template for Security

Document ID: SOP-SEC-IR-042
Classification: Internal Operational Standard / Confidential Enterprise Policy

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Purpose

This Standard Operating Procedure (SOP) defines the mandatory lifecycle, governance, structural parameters, and technical validation mechanisms for generating, auditing, and archiving enterprise security incident reports. It ensures complete evidentiary chain-of-custody, regulatory compliance, and cross-functional operational alignment following any suspected or confirmed breach of information security controls.

2.2 Operational Boundaries & Scope

This SOP applies to all global business units, subsidiaries, contractors, cloud infrastructure environments, on-premises data centers, and endpoint devices owned, leased, or managed by the enterprise. It governs all phases from initial alert triage through root-cause analysis (RCA), executive notification, and post-incident review.

2.3 Regulatory Standards Alignment

Execution of this procedure mandates strict adherence to the following regulatory and statutory frameworks:

• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide.
• ISO/IEC 27035: Information Security Incident Management.
• GDPR (Articles 33 & 34): 72-hour mandatory supervisory authority notification for personal data breaches.
• PCI-DSS v4.0 (Requirement 12.10): Incident response plan maintenance and testing.
• HIPAA Security Rule (45 CFR § 164.308): Administrative safeguards and security incident procedures.

---

3. Prerequisites & Tool Requirements

Execution of this SOP requires authorized access, verified operational tooling, and specific certifications. Personnel failing to meet these prerequisites are strictly prohibited from generating or modifying official incident report documentation.

3.1 Technical Tools & Software Access

• Security Information and Event Management (SIEM): Splunk Enterprise Security / Microsoft Sentinel (Tier-3 read/write query privileges).
• Endpoint Detection & Response (EDR): CrowdStrike Falcon / Microsoft Defender for Endpoint (Isolation and forensic collection privileges).
• Incident Management & Ticketing: ServiceNow Security Incident Response (SIR) module (ITIL-compliant).
• Forensic & Evidence Vault: AWS S3 Object Lock-enabled secure bucket with KMS envelope encryption, or certified on-premises SAN with write-once-read-many (WORM) capability.
• Secure Communications: OMEMO-encrypted XMPP or Signal Enterprise for out-of-band crisis coordination.

3.2 Personnel Certifications & Training

• Mandatory Certifications: Personnel leading incident reporting must hold at least one of the following active credentials: ISC2 CISSP, GIAC Certified Incident Handler (GCIH), or CompTIA CySA+.
• Annual Compliance: Completion of Enterprise Information Security Policy (EISP) and Chain of Custody handling modules within the last 365 days.

---

4. Roles & Responsibilities (RACI Matrix Table)

Definitions: Responsible (The doer), Accountable (The owner), Consulted (In-the-loop advisors), Informed (Kept updated).

---

5. Step-by-Step Operational Procedure

Phase 1: Triage, Intake, and Initial Classification

• 1.1 Ingest the security alert via SIEM automated webhook or manual ticketing portal entry in ServiceNow SIR.
• 1.2 Assign a unique Universal Incident Identifier (format: INC-YYYYMMDD-[4-digit sequence]).
• 1.3 Assess initial severity level based on enterprise impact matrix:
  • Sev-1 (Critical): Active enterprise-wide data exfiltration, ransomware encryption, or core infrastructure compromise.
  • Sev-2 (High): Targeted malware containment, isolated privilege escalation, or unauthorized access to confidential zones.
  • Sev-3 (Moderate): Policy violation, localized phishing attempt without payload execution.
  • Sev-4 (Low): False positive or exploratory port scan with zero perimeter breach.
• 1.4 Populate the core metadata fields in the Incident Report Template (Date/Time of detection, Systems affected, Data classifications impacted).

Phase 2: Containment, Eradication, and Evidence Preservation

• 2.1 Coordinate with the IT Systems Lead to execute containment protocols (e.g., network segment isolation, EDR host containment, account suspension).
• 2.2 Capture volatile system memory (RAM) and disk snapshots for systems exhibiting indicators of compromise (IoCs) prior to remediation.
• 2.3 Compute cryptographic hashes (SHA-256) of all gathered forensic artifacts and log files.
• 2.4 Log all evidence items into the Master Chain-of-Custody Ledger, documenting exact time, collector ID, and secure storage destination.
• 2.5 Eradicate identified threat vectors (e.g., purge malicious payloads, revoke compromised API keys, patch zero-day vulnerabilities).

Phase 3: Root Cause Analysis & Formal Report Compilation

• 3.1 Execute systematic Root Cause Analysis (RCA) utilizing the "5 Whys" and Ishikawa (Fishbone) diagram methodologies.
• 3.2 Draft the comprehensive Incident Report narrative within the standardized enterprise template, including:
  • Executive Summary: Non-technical overview for executive leadership.
  • Timeline of Events: Chronological accounting from initial vector to remediation.
  • Impact Assessment: Quantification of operational, financial, and reputational damage.
  • IoC Matrix: Structured list of IP addresses, domain names, file hashes, and user accounts involved.
• 3.3 Attach all cryptographic hashes, memory dumps, and log snippets to the immutable ServiceNow SIR ticket.

Phase 4: Review, Executive Sign-Off, and Regulatory Disclosures

• 4.1 Submit draft report to the Enterprise Workflow Auditor for format and data-integrity verification.
• 4.2 Route the validated report to Legal Counsel and the Privacy Officer to determine mandatory regulatory notification obligations (GDPR, HIPAA, SEC disclosure rules).
• 4.3 Secure formal sign-off from the CISO and Incident Response Lead.
• 4.4 Disseminate executive summary to the Board Risk Committee and relevant stakeholders.

Phase 5: Post-Incident Review and Closure

• 5.1 Schedule and execute a mandatory "Post-Mortem" or "Lessons Learned" meeting within 5 business days of incident closure.
• 5.2 Update enterprise threat intelligence feeds, firewall rules, and SIEM detection signatures based on lessons learned.
• 5.3 Archive the complete, sealed incident report package in the WORM forensic vault for the mandatory retention period (minimum 7 years).
• 5.4 Transition the ServiceNow SIR ticket state from Resolved to Closed-Archived.

---

6. Quality Assurance & Verification Criteria

To ensure institutional rigor, every security incident report must undergo an automated and manual audit before final archival.

6.1 Audit Checklist

• Completeness: All mandatory fields in the template (Vector, Assets, IoCs, Timeline) are fully populated without placeholder text.
• Chronological Accuracy: Timeline entries match raw system log timestamps synchronized via NTP.
• Evidentiary Integrity: SHA-256 hashes of collected artifacts match entries in the Chain-of-Custody ledger.
• Regulatory Compliance Check: Explicit sign-off from Legal Counsel regarding data privacy and disclosure mandates is attached.

6.2 Tolerance Thresholds & Benchmarks

• Sev-1 Triage SLA: Initial triage and severity assignment must occur within 15 minutes of alert generation.
• Sev-1 Containment SLA: Active containment protocols must be initiated within 60 minutes of confirmation.
• Report Finalization SLA: The complete incident report must be finalized and signed off within 48 hours of incident containment for non-regulatory events, and within 24 hours for potential GDPR/regulatory reportable breaches.
• Data Integrity Benchmark: 100% hash verification match rate across all stored forensic images. Any checksum discrepancy results in an immediate audit failure and rejection of the report.

---

7. Practical Troubleshooting Scenarios

Scenario A: Discrepancy in System Log Timestamps During Timeline Reconstruction

• Symptom: Cloud infrastructure logs (AWS CloudTrail) and on-premises domain controller logs exhibit a 14-minute drift, creating ambiguity in the attack timeline sequence.
• Immediate Corrective Action Protocol:
  1. Do not manually alter or normalize raw log files, as this invalidates the evidentiary chain-of-custody.
  2. Query the authoritative Enterprise NTP server (ntp.internal.net) to establish exact clock drift offsets for each affected system.
  3. Insert a dedicated "Chronological Synchronization Note" subsection directly into the Incident Report Timeline, explicitly detailing the calculated time offsets ($\Delta t$) and referencing the synchronization source.
  4. Re-calculate the absolute timeline in Coordinated Universal Time (UTC) and have the correction verified by the Enterprise Workflow Auditor.

Scenario B: Evidence Corruption / Hash Mismatch During Forensic Vault Ingestion

• Symptom: During Phase 2.3, the computed SHA-256 hash of an acquired memory dump (mem_dump_srv04.raw) does not match the secondary verification hash generated upon upload to the AWS S3 secure vault.
• Immediate Corrective Action Protocol:
  1. Halt automated ingestion pipeline immediately to prevent ingestion of corrupted or tampered data.
  2. Isolate the local acquisition workstation and verify its physical and logical write-blockers.
  3. Re-run the live acquisition from the target host (if system remains accessible) or re-transfer the source image via authenticated, checksum-verified secure copy (scp with -o HashKnownHosts=yes or rsync --checksum).
  4. If corruption persists due to storage media failure, document the hardware failure event in the Incident Report Log, flag the asset for physical forensic destruction analysis, and utilize secondary redundant snapshot backups stored in the immutable cloud vault.

Scenario C: Refusal of Executive Sign-Off Due to Scope Disagreements

• Symptom: Legal Counsel declines to sign off on the incident report during Phase 4.2, citing potential over-disclosure of proprietary architectural vulnerabilities that go beyond statutory regulatory requirements.
• Immediate Corrective Action Protocol:
  1. Convene an emergency alignment session between the Incident Response Lead, CISO, and Legal Counsel within 2 hours of the rejection notice.
  2. Create a bifurcated report structure: Split the document into a Statutory Regulatory Disclosure Annex (containing strictly what is legally mandated) and an Internal Technical Remediation Document (containing deep architectural vulnerabilities for internal engineering use).
  3. Obtain independent sign-off for the regulatory annex from Legal Counsel, and separate sign-off for the internal document from the CISO and IT Infrastructure Lead.
  4. Document the structural split and justification within the Document Control Revision History table (Version increment).