Incident Report Template for Cyber Security

Standard Operating Procedure: Cyber Security Incident Reporting (CSIR-001)

1. Document Control & Revision History

2. Executive Summary & Scope

Purpose: To define the institutional mechanism for identifying, documenting, and reporting cyber security incidents to ensure regulatory compliance (GDPR, HIPAA, SOC2, PCI-DSS) and minimize operational downtime.

Scope: This procedure applies to all internal employees, third-party vendors, and contractors accessing corporate assets. It encompasses all digital infrastructure, cloud environments, and endpoint devices owned or managed by the organization. Any deviation from this protocol requires written authorization from the CISO.

3. Prerequisites & Tool Requirements

• Software Access: SIEM (Splunk/Sentinel), EDR (CrowdStrike/Defender), and IT Service Management (ITSM) tool (Jira/ServiceNow).
• Authentication: Multi-Factor Authentication (MFA) token and privileged access credentials.
• Compliance: Current "Cyber Security Awareness & Incident Handling" certification.
• Documentation: Access to the secure offline Incident Response Log (Encrypted PDF/Repository).
• Equipment: Hardware-encrypted workstation, Out-of-band communication device (Signal/Encrypted VoIP).

4. Roles & Responsibilities (RACI Matrix)

5. Step-by-Step Operational Procedure

Phase I: Detection & Classification

• Log entry created in ITSM with timestamp.
• Event triage: Assign Severity (Low, Medium, High, Critical).
• Confirm indicator of compromise (IOC) via SIEM correlation.

Phase II: Containment & Analysis

• Isolate affected network segments/endpoints from production.
• Capture volatile memory (RAM) and disk images for forensics.
• Document specific breach vector and scope of data exposure.

Phase III: Reporting & Escalation

• Draft Incident Report using the standardized schema (Time, Vector, Impact, Remediation).
• Notify Data Protection Officer (DPO) if PII/PHI breach is confirmed.
• Execute regulatory notification sequences based on jurisdiction.

Phase IV: Recovery & Post-Mortem

• Restore services from clean backups post-sanitization.
• Validate system integrity through penetration testing.
• Conduct Post-Incident Review (PIR) within 72 hours.

6. Quality Assurance & Verification Criteria

• Completeness: 100% of fields in the incident form must be populated.
• Latency: Mean Time to Detect (MTTD) must not exceed 60 minutes for high-severity threats.
• Integrity: Evidence chain of custody must be verified by two independent security analysts.
• Acceptance Benchmark: Post-remediation audit must yield zero high-risk vulnerabilities on the impacted asset.

7. Practical Troubleshooting Scenarios

Scenario A: Incident Escalation Failure (Communication Blackout)

• Failure: Primary notification channels (Email/Slack) are compromised by the attacker.
• Corrective Action: Immediate pivot to Out-of-Band (OOB) communication protocols. Execute "Blackout Comms" sheet containing pre-shared encrypted contact numbers for the IR team.

Scenario B: Evidence Volatility (Improper Forensics)

• Failure: Responder attempts reboot before dumping RAM, destroying volatile evidence.
• Corrective Action: Cease all activity on the machine. Flag the incident as "Forensically Compromised" in the report. Document the exact sequence of errors for the post-mortem to prevent recurrence.

Scenario C: Regulatory Reporting Delay

• Failure: Incident exceeds the 72-hour reporting window due to misclassification.
• Corrective Action: Immediate disclosure to Legal. Prepare a "Good Faith" explanation summary for regulatory bodies; initiate root cause analysis (RCA) to identify process bottlenecks.