Incident Report Writing — For Every Audience

An incident report is the permanent record of what happened, what you found, what you did, and what to do next. It’s read by people who make budget decisions, people who file regulatory notifications, and people who build better defenses. Writing one well requires knowing which reader you’re writing for in each section.

Report Structure

Section 1: Executive Summary (1 paragraph)

Audience: CISO, CEO, board, legal. Reads this section only.

What to include:

What type of incident occurred (without jargon)
When it was detected and when it occurred (if known)
What was affected (systems, data, users)
Current status (contained, ongoing, remediated)
Any decisions leadership needs to make

Template:

On [date], our security operations team identified [description of incident in plain language].
The incident [began / was first detected] at [time] and was [contained / is ongoing] as of [time].
[Number] [systems / user accounts / data records] were affected.
[Data type] was [confirmed / potentially] accessed.
The immediate threat has been [removed / is under investigation].
[Decision needed: whether to notify customers / regulators / insurance].

Example:

On August 14, 2024, our security team detected that a finance employee's email account
was taken over by an attacker using a sophisticated phishing technique that bypasses
multi-factor authentication. The attacker had access to the account for approximately
25 minutes between 09:21 and 09:46 AM EST. During that time, they read email content
and sent one fraudulent payment request to our finance team. The fraudulent wire transfer
was intercepted before processing. The employee's account has been secured. Legal and
compliance must determine if this constitutes a reportable incident under our cyber
insurance policy.

Section 2: Incident Timeline

Audience: IR team, auditors, legal, compliance.

Format: Chronological table with UTC timestamps and evidence citations.

| Timestamp (UTC)        | Actor    | Event                                      | Evidence Source       | Confidence |
|------------------------|----------|--------------------------------------------|-----------------------|------------|
| 2024-08-14 09:14:22    | Attacker | Phishing email delivered to jdoe@corp.com  | Exchange Msg Trace    | Confirmed  |
| 2024-08-14 09:21:03    | Victim   | jdoe opened phishing email, clicked link   | Exchange UAL ReadItems| Confirmed  |
| 2024-08-14 09:21:14    | System   | M365 sign-in: jdoe from corp VPN           | Entra SigninLogs      | Confirmed  |
| 2024-08-14 09:21:17    | Attacker | Session token replayed from 185.220.101.44 | Entra SigninLogs      | Confirmed  |
| 2024-08-14 09:22–09:47 | Attacker | MailItemsAccessed from 185.220.101.44      | M365 UAL              | Confirmed  |
| 2024-08-14 09:50:31    | Attacker | New-InboxRule created (delete finance mail)| M365 UAL              | Confirmed  |
| 2024-08-14 09:51:14    | Attacker | BEC email sent to ap-team@corp.com         | Exchange UAL Send     | Confirmed  |
| 2024-08-14 10:14:30    | SOC      | Incident detected via DLP alert            | SIEM Alert TKT-4421   | N/A        |
| 2024-08-14 10:15:00    | SOC      | Inbox rule removed                         | Analyst action log    | N/A        |
| 2024-08-14 10:17:00    | SOC      | All sessions revoked for jdoe              | Entra admin log       | N/A        |
| 2024-08-14 10:22:00    | SOC      | Finance team contacted — wire not processed| Call log + ticket     | N/A        |

Section 3: Technical Findings

Audience: Security engineers, IR team, detection team.

What to include:

Full IOC list (IPs, domains, file hashes, email addresses, URLs)
ATT&CK technique chain with justification for each tag
Affected systems with roles
Full attacker activity: what they read, what they sent, what they changed
Gaps identified: what allowed the attack to succeed

IOC table:

INDICATORS OF COMPROMISE
  Type          Value                        Confidence  Status
  Domain        corp-finance.net             Confirmed   Blocked (gateway + DNS)
  Domain        secure-docs.corp-finance.net Confirmed   Blocked
  IP            185.220.101.44               Confirmed   Blocked (firewall)
  Email         mikes@corp-finance.net       Confirmed   Blocked
  Inbox Rule    "Delete if contains: finance alert" Confirmed  Removed

ATT&CK CHAIN
  T1566.002     Spearphishing Link — phishing email with link to AiTM proxy
  T1557         Adversary-in-the-Middle — proxy captured session token post-MFA
  T1528         Steal Application Access Token — session cookie theft
  T1114.002     Email Collection: Remote Email Collection — attacker read mailbox
  T1564.008     Hide Artifacts: Email Hiding Rules — inbox rule to delete alerts
  T1534         Internal Spearphishing — BEC email sent from victim's account

Section 4: Impact Assessment

Audience: Legal, compliance, executive team, possibly regulators.

AFFECTED SYSTEMS
  Primary: jdoe@corp.com mailbox — compromised for 25 minutes
  Secondary: Finance team received fraudulent BEC email (no wire processed)

DATA AT RISK
  Mailbox content visible to attacker: jdoe's inbox and sent items (approx. 3 months)
  Known sensitive items: Q3 invoice list (no SSNs, no financial account numbers)
  Unknown: attacker may have extracted attachments (no confirm — UAL shows read events
           but not attachment download events; this is a forensic limitation)

REGULATORY IMPLICATIONS
  GDPR: Employee personal data in email — notification to DPO required
  Cyber insurance: Policy clause 3.2 requires notification within 72h of discovery
  PCI-DSS: No cardholder data in jdoe's mailbox — PCI notification not triggered

BUSINESS IMPACT
  Financial: Wire transfer not processed — no direct financial loss from BEC
  Operational: jdoe's account unavailable for 4 hours during re-enrollment
  Reputational: No customer-facing impact

Section 5: Remediation & Recommendations

Audience: Security engineering, management, compliance.

Short-term (completed):

Inbox rule removed
All sessions revoked, password reset, MFA re-enrolled
Phishing email quarantined from all mailboxes
Lookalike domain and IPs blocked

Long-term recommendations:

1. DMARC policy: upgrade corp.com from p=quarantine to p=reject
   Owner: email-security team | Priority: High | Deadline: 30 days

2. Detection rule: alert on MailItemsAccessed from new IP within 60 min of phishing delivery
   Owner: detection-engineering | Priority: High | Deadline: 14 days

3. MFA policy: pilot FIDO2/passkeys for finance team (AiTM defeats push/TOTP MFA)
   Owner: identity team | Priority: Medium | Deadline: Q4 planning

4. Security awareness: targeted AiTM simulation for finance team
   Owner: security-awareness | Priority: Medium | Deadline: 60 days

Worked Example

Executive summary vs. technical summary: same incident, two versions

Incident: Cobalt Strike beacon on CORP-PC-014. No confirmed lateral movement. Contained via EDR isolation.

Executive summary version:

On September 3, 2024, our security team identified malicious software running on a marketing
workstation (CORP-PC-014) that was communicating with an external attacker-controlled server.
The software was designed to give the attacker remote control of the machine.
It was detected at 2:47 PM and the workstation was disconnected from the network within 11 minutes.
No evidence was found of the attacker accessing other systems or taking any data.
The workstation will be reimaged (wiped and restored to factory settings) tomorrow.
No customer data was accessed. IT management should be aware the marketing team will need
a temporary loaner machine for the next 24 hours.

Technical summary version:

Cobalt Strike beacon detected on CORP-PC-014 (10.2.1.44), user mwilson@corp.com.
Initial detection: Suricata ET JA3 rule match on conn to 91.213.50.22:443.
Zeek conn.log: beacon interval CV=0.031, duration=3601s, service=-, resp_bytes=4.5MB.
ssl.log: JA3 72a7c4de (known CS default), cert self-signed, issued 8 days prior.
Sysmon Event 3: connection from svchost.exe (PID 7824), ParentImage=explorer.exe (PID 892).
Abnormal parent: legitimate svchost.exe spawns from services.exe, not explorer.exe.
Sysmon Event 1: svchost.exe created 4 hours prior — not a system svchost (path=C:\Users\mwilson\AppData\Local\Temp\svchost.exe).
VT: 0/90 (unknown sample), sandbox detonation: CS stager → CS beacon.
ATT&CK: T1036.005 (Masquerading: Match Legitimate Name), T1071.001 (Web Protocols), T1055 (Process Injection).
Scope: no lateral movement confirmed (no SMB/RDP from CORP-PC-014 to other hosts in past 24h).
Host isolated via EDR at 14:58 UTC. Evidence preserved: memory dump + Sysmon .evtx.

Retrieval Practice

An incident report's timeline entry reads: 'Attacker accessed email at approximately 3pm.' What is wrong with this entry and what should it say instead?

Reveal answer

Three problems: (1) 'Approximately 3pm' lacks a precise timestamp — forensic timelines must use specific timestamps (HH:MM:SS). (2) No timezone specified — '3pm' is ambiguous across time zones; UTC is the standard. (3) No evidence citation — the entry doesn't state which log or query provided this information, making it unauditable. Corrected entry: '2024-08-14 15:02:17 UTC | Attacker | MailItemsAccessed event from IP 185.220.101.44 for mailbox jdoe@corp.com | M365 Unified Audit Log (Operation=MailItemsAccessed) | Confirmed'. Every timeline entry must have a timestamp (UTC, precise), an actor, a specific event description, an evidence source, and a confidence level.

Retrieval Practice

Legal asks: 'Can you tell us exactly what data the attacker took from the mailbox?' What is the honest and accurate answer based on what M365 UAL MailItemsAccessed events show?

Reveal answer

Honest answer: 'We can confirm which mail items were accessed (read) by the attacker — MailItemsAccessed events log the FolderID and ItemID of accessed items. We can determine which messages were opened. However, M365 UAL does not log attachment download events separately from message read events — we cannot definitively confirm whether specific attachments were opened or downloaded locally. We have evidence of which messages were accessed, but not a definitive list of what data was extracted. The forensic limitation should be documented explicitly: we know what was read but not what was copied.' Never overclaim certainty in legal submissions — 'possibly accessed' vs. 'confirmed extracted' have very different legal implications.