Cybersecurity Incident Report Template

## ROLE

You are a senior incident response analyst and cybersecurity technical writer who has led breach investigations for Fortune 500 companies, government agencies, and critical infrastructure operators. You have experience with incident reporting under [REGULATORY FRAMEWORK: NIST CSF / ISO 27001 / SOC 2 / HIPAA / PCI-DSS / GDPR Article 33 / SEC cybersecurity disclosure rules / CISA reporting requirements / NIS2 Directive / industry-specific regulations]. You have written hundreds of incident reports that have been reviewed by legal counsel, shared with regulators, presented to boards of directors, and used as evidence in law enforcement proceedings. You understand that an incident report serves multiple simultaneous purposes: it documents the technical facts for the investigation team, it communicates business risk to executives, it satisfies regulatory notification requirements, and it provides the foundation for post-incident improvements. You write with forensic precision while making complex attack chains comprehensible to non-technical stakeholders.

## OBJECTIVE

Draft a comprehensive incident report for a cybersecurity event at [ORGANIZATION NAME], a [ORGANIZATION TYPE: healthcare provider / financial institution / technology company / government agency / educational institution / manufacturing company / retail company / critical infrastructure operator / other] with approximately [SIZE: number of employees, revenue, or user base]. The incident type is [INCIDENT TYPE: ransomware attack / data breach / phishing compromise / insider threat / supply chain attack / DDoS / advanced persistent threat / business email compromise / zero-day exploitation / cloud misconfiguration / credential stuffing / other]. The incident was detected on [DETECTION DATE] and the initial attack vector was [ATTACK VECTOR: if known]. The report is intended for [AUDIENCE: internal executive leadership / board of directors / regulatory body / law enforcement / cyber insurance carrier / affected customers / public disclosure / all of the above]. The report classification is [CLASSIFICATION: confidential / attorney-client privileged / regulatory filing / public].

## TASK: COMPLETE INCIDENT REPORT FRAMEWORK

### Section 1 — Executive Summary

Write a [LENGTH: 1-2 page] executive summary designed for C-suite and board-level readers who need to understand the incident's business impact without technical details. Structure as: (a) Incident overview in three sentences: what happened, when, and the current status [STATUS: contained / eradicated / recovered / ongoing investigation]. (b) Business impact summary: systems affected [SYSTEMS], data potentially compromised [DATA TYPES AND VOLUME: e.g., "personally identifiable information of approximately 50,000 customers" / "proprietary source code for 3 product lines" / "financial records spanning 2 fiscal years"], operational disruption [DOWNTIME: duration and affected business functions], and estimated financial impact [FINANCIAL IMPACT: remediation costs, lost revenue, regulatory fines, legal exposure]. (c) Current risk posture: has the threat been eliminated? What is the residual risk? Are there indicators of ongoing compromise? (d) Key decisions required: what actions need executive approval — regulatory notification, customer notification, law enforcement engagement, public disclosure, insurance claim, vendor contract reviews. (e) Timeline to full recovery and resource requirements.

### Section 2 — Incident Timeline (Forensic Chronology)

Construct a detailed, timestamped timeline of the incident from initial compromise through detection, containment, eradication, and recovery. Use UTC timestamps throughout for consistency. Organize in two parts:

**Attack Timeline (reconstructed):** Document the attacker's activities based on forensic evidence. For each event: [TIMESTAMP UTC] — [EVENT DESCRIPTION] — [EVIDENCE SOURCE: log file / EDR alert / network capture / file system artifact / memory forensics / email headers / cloud audit log]. Example entries:
- "[DATE TIME UTC] — Initial access achieved via [VECTOR: spear phishing email to [USER] / exploitation of [CVE-ID] on [SYSTEM] / compromised third-party credentials from [VENDOR]] — Evidence: [LOG SOURCE]"
- "[DATE TIME UTC] — Lateral movement to [SYSTEM] using [TECHNIQUE: Pass-the-Hash / RDP / PSExec / WMI / SSH keys / compromised service account] — Evidence: [LOG SOURCE]"
- "[DATE TIME UTC] — Data exfiltration of [DATA VOLUME] to [DESTINATION: external IP / cloud storage / DNS tunneling / encrypted channel] — Evidence: [LOG SOURCE]"
- "[DATE TIME UTC] — [PAYLOAD: ransomware deployment / backdoor installation / persistence mechanism established / data destruction] — Evidence: [LOG SOURCE]"

**Response Timeline:** Document the organization's detection and response activities:
- "[DATE TIME UTC] — Incident detected by [DETECTION METHOD: SOC analyst / automated alert from [TOOL] / user report / external notification from [SOURCE]] — [SEVERITY ASSIGNED]"
- "[DATE TIME UTC] — Incident response team activated — [TEAM MEMBERS / ROLES]"
- "[DATE TIME UTC] — [CONTAINMENT ACTION: network segment isolated / accounts disabled / systems quarantined / firewall rules deployed]"
- Continue through eradication, recovery, and return to normal operations.

Identify the key time metrics: Dwell Time (time from initial compromise to detection) [DWELL TIME], Time to Contain [CONTAINMENT TIME], Time to Eradicate [ERADICATION TIME], Time to Recover [RECOVERY TIME]. Compare these to industry benchmarks where applicable.

### Section 3 — Technical Analysis

Provide detailed technical findings for the investigation team. Cover:

**(a) Attack Vector and Initial Access:** How did the attacker gain initial access? Document the specific vulnerability exploited [CVE-ID if applicable], the phishing lure content and delivery mechanism, the compromised credentials and their provenance, or the supply chain component that was compromised. Include IoCs (Indicators of Compromise): [IOC TYPE: IP addresses / domains / file hashes / email addresses / user agents / mutex names / registry keys / YARA rules / Sigma rules / MITRE ATT&CK technique IDs].

**(b) Attacker Tactics, Techniques, and Procedures (TTPs):** Map the attack to the MITRE ATT&CK framework. For each phase of the attack chain, document: Tactic [TACTIC ID and name] — Technique [TECHNIQUE ID and name] — Procedure [specific implementation details observed] — Evidence [forensic artifact]. Cover: Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact as applicable.

**(c) Affected Systems and Data:** Provide a complete inventory of compromised systems: [SYSTEM NAME / IP / OS / FUNCTION / SENSITIVITY LEVEL / COMPROMISE EVIDENCE / REMEDIATION STATUS]. For data exposure, categorize by type and sensitivity: [DATA CATEGORY: PII / PHI / PCI / trade secrets / credentials / internal communications / financial records / source code] with volume estimates and affected individuals or entities count.

**(d) Root Cause Analysis:** Identify the root cause(s) that enabled the incident. Distinguish between the proximate cause (the specific vulnerability or weakness exploited) and the systemic causes (the organizational, process, or architectural failures that allowed the proximate cause to exist). Use the "Five Whys" methodology or a fishbone diagram framework to trace root causes. Document contributing factors: [CONTRIBUTING FACTORS: unpatched systems / misconfigured controls / insufficient monitoring / inadequate training / vendor management gaps / architectural weaknesses / staffing shortages / policy violations].

### Section 4 — Impact Assessment

Quantify the impact across multiple dimensions:

**(a) Operational Impact:** Systems offline [SYSTEMS AND DURATION], business processes disrupted [PROCESSES], productivity loss [HOURS/DAYS × AFFECTED EMPLOYEES], customer-facing service degradation [SERVICE AND DURATION].

**(b) Data Impact:** Number of records exposed [RECORD COUNT by category], data sensitivity classification [CLASSIFICATION], whether data was viewed, copied, exfiltrated, encrypted, or destroyed [DATA STATUS], ongoing risk of data misuse [RISK ASSESSMENT].

**(c) Financial Impact:** Direct costs [BREAKDOWN: incident response retainer, forensic investigation, legal counsel, regulatory notifications, credit monitoring, system rebuilding, overtime, hardware replacement]. Indirect costs [BREAKDOWN: lost revenue, contract penalties, increased insurance premiums, reputational damage estimate]. Projected future costs [BREAKDOWN: regulatory fines, litigation exposure, increased security spending].

**(d) Regulatory and Legal Impact:** Which notification requirements are triggered [REGULATIONS AND DEADLINES]? Has notification been made [STATUS AND DATES]? What regulatory penalties could apply [POTENTIAL FINES]? What litigation risk exists [ASSESSMENT]?

### Section 5 — Containment, Eradication & Recovery Actions

Document all response actions taken, organized by phase:

**(a) Containment (Immediate Actions):** List every containment action with timestamp, responsible person, and effectiveness assessment. [ACTIONS: network isolation / account lockouts / firewall rule changes / DNS sinkholing / certificate revocation / vendor access suspension].

**(b) Eradication (Threat Removal):** Document how the threat was removed from the environment. [ACTIONS: malware removal / backdoor elimination / compromised account credential resets / system reimaging / patch deployment / configuration hardening]. Describe how eradication was verified — what scanning, monitoring, or testing was performed to confirm the attacker no longer has access.

**(c) Recovery (Return to Operations):** Document the recovery sequence, prioritization rationale (which systems were restored first and why), validation testing before returning systems to production, enhanced monitoring deployed during the recovery period, and the criteria used to determine when recovery was complete.

### Section 6 — Recommendations and Lessons Learned

Provide [NUMBER: 10-15] specific, prioritized recommendations organized by timeframe:

**Immediate (0-30 days):** Critical security gaps that must be closed to prevent recurrence. [RECOMMENDATIONS with specific actions, responsible parties, and success criteria].

**Short-term (30-90 days):** Security improvements that address the systemic root causes identified in the analysis. [RECOMMENDATIONS].

**Long-term (90-365 days):** Strategic security program enhancements, architectural changes, and capability investments. [RECOMMENDATIONS].

For each recommendation, provide: priority [CRITICAL / HIGH / MEDIUM], estimated cost [COST RANGE], responsible team [TEAM], and the specific risk it mitigates. Include a lessons-learned section documenting what worked well in the response, what did not work, and what processes or capabilities need improvement.