# how to write an incident report for a security event

## TL;DR
A good incident report lets someone who wasnt there understand what happened, what you did, and what changes next. Write it blameless, lead with a one-paragraph summary, then a timeline, then impact, root cause, and follow-ups with owners and dates. If it takes more than 20 minutes to read, it wont get read.

```text
how to write an incident report for a security event
```

## Use this when
- a security incident just closed and needs documenting
- leadership or the board needs a written account
- the same kind of incident keeps happening and nobody remembers the last one
- you need the team to actually learn from what happened

## Not for this skill when
- the incident is still active (coordinate first, write later)
- you need a public disclosure statement (counsel drives that)
- it was a near miss with no impact (use the lighter variant below)
- you want a real-time status doc (that is a different artifact)

## Steps
1. Write the summary first: what happened, when, what the impact was, and the current status, in one paragraph. Executives read only this, so make it complete on its own.

2. Build the timeline from logs, not memory. Every entry gets a UTC timestamp, the event, and the source. Memory lies about sequence and timing; logs dont. Start the timeline before the incident, at the last known-good state.

3. State the impact plainly: which systems, which data, how many users, how long. Say what you know and say what you still dont know. "No evidence of data access" is honest; "no data was accessed" is a claim you may not be able to back.

4. Name the root cause, or say it is unknown and name what would answer it. "Attacker logged in with a phished credential at 14:02 UTC" beats "human error." If the root cause is still open, say so and give the investigation a date.

5. List what you did: containment, eradication, and recovery, each with a timestamp. This is your proof the response worked and your record for the next team that faces the same thing.

6. Assign follow-ups. Every lesson gets an owner and a date. "Improve MFA coverage" is not a follow-up; "enforce phishing-resistant MFA on all admin accounts by Nov 15, owner: Priya" is. Unowned action items are wishes.

7. Keep it blameless. The report explains how the system allowed the incident, not who to punish. Blame kills future reporting, and the next incident goes unreported until it is worse.

### Variant: incident report for a near miss
Same format, smaller impact section. Near misses are free lessons; write them up while they are cheap. The timeline and follow-ups matter just as much when nothing broke.

### Variant: executive one-pager version
Summary, impact in business terms, what changed, and what it costs. No log excerpts, no tool names, no jargon. One page, or it becomes a second document nobody reads either.

### Variant: incident report that becomes a public disclosure
Start from the internal report, then strip it with counsel: remove internal system details, attacker tradecraft specifics, and anything that helps the next attacker. The public version answers "what happened to my data," nothing more.

## Why this happens
Incidents repeat when the lessons stay in people's heads. The report is how the organization actually learns: it turns one team's bad week into everyone's better runbook.

## Edge cases and pitfalls
- Dont publish the full report widely if it contains sensitive details. Make a sanitized version for broad distribution.
- Get legal review before the report goes anywhere external. Internal candor and external statements are different documents.
- Timelines assembled during the incident are drafts. Finalize them after, when you have all the logs, or the report will contradict itself.
- If the incident is still open, mark the report as a draft and keep updating it. A "final" report for an open incident is a lie with formatting.
- Name the report consistently and store it where the next responder will find it. A perfect report in someone's personal drive is the same as no report.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1i1DoHqaoW8bwB2YkVT-mg