Security Incident Response Report Template

Standard Operating Procedure: Security Incident Response Report Template

1. Document Control & Revision History

2. Executive Summary & Scope

Purpose: This document establishes the mandatory structural requirements for documenting cybersecurity incidents to ensure forensic integrity, regulatory compliance, and operational recovery.

Scope: This procedure applies to all internal and third-party IT systems, cloud environments, and physical assets under the organization’s purview. It adheres to the requirements set forth by NIST SP 800-61 Rev. 2 and regulatory frameworks including GDPR, HIPAA, and SOC2 Type II.

Clinical Statement: Any deviation from this template without prior authorization from the Information Security Office constitutes a breach of corporate governance.

3. Prerequisites & Tool Requirements

• Access: Active administrative credentials for the SIEM/SOAR platform.
• Software: Standardized Forensic Imaging tools (e.g., FTK Imager, EnCase), Write-blockers (for physical hardware), and Encrypted Log Repositories.
• Documentation: Access to the secure incident management portal (e.g., Jira Service Management, ServiceNow Security Operations).
• Certifications: Responders must hold active GCIH, CISSP, or equivalent operational security certification.
• Safety: Physical PPE (Anti-static wrist straps) required for on-premise hardware seizure.

4. Roles & Responsibilities (RACI Matrix)

5. Step-by-Step Operational Procedure

Phase 1: Identification & Triage

• Log incident ticket with unique reference ID.
• Determine incident classification (Low/Medium/High/Critical).
• Confirm breach of PII/PHI or proprietary data.

Phase 2: Containment & Eradication

• Isolate compromised network segments (VLAN segmentation).
• Execute memory dumps and disk imaging of affected assets.
• Terminate malicious sessions and reset privileged credentials.

Phase 3: Reporting & Documentation

• Populate the "Executive Summary" section with incident timeline (UTC).
• Attach forensic evidence hashes to the incident log.
• Draft narrative of Root Cause Analysis (RCA).

Phase 4: Recovery & Post-Mortem

• Verify system integrity before restoring from immutable backups.
• Execute vulnerability scanning on restored systems.
• Conduct "Lessons Learned" briefing within 72 hours.

6. Quality Assurance & Verification Criteria

• Documentation Completeness: 100% of fields in the report template must be populated; "N/A" must be justified.
• Evidence Integrity: Chain of Custody logs must demonstrate zero gaps from acquisition to storage.
• Reporting Latency: Final report submission must occur within 24 hours of incident closure.
• Accuracy Threshold: Peer-reviewed audit must verify that timestamps correlate across all log sources within ±50ms.

7. Practical Troubleshooting Scenarios

Scenario A: Remote Access Denied to Isolated Asset

• Issue: The incident response team cannot access a compromised server due to restrictive firewall rules implemented during containment.
• Corrective Action: Utilize an Out-of-Band (OOB) management channel (iDRAC/ILO) via a dedicated, air-gapped security workstation.

Scenario B: Evidence Corruption During Acquisition

• Issue: Disk image hash verification fails against the live source.
• Corrective Action: Immediately cease acquisition. Document the failure in the log, identify the last known good state, and initiate a new capture using an alternative forensic tool or method.

Scenario C: Stakeholder Refusal of Access

• Issue: Department head refuses to allow a system to be taken offline for analysis.
• Corrective Action: Escalate immediately to the Accountable executive defined in the RACI matrix. Document the refusal as a "Risk Acceptance" event signed by the executive, shifting liability from the security team to the department head.