Writing an incident report your executives will actually read

The post-incident report is where most of the value of an incident either gets captured or thrown away. It is also, reliably, the part everyone least wants to write — which is how you end up with a forty-page forensic timeline that three people read and nothing changes as a result.

The technical detail matters. But it isn't what makes a report effective.

Two audiences, two documents in one

An incident report serves people who want completely different things:

Executives and risk owners want to know: how bad was it, is it over, what did it cost, and what are we doing so it doesn't happen again. They will read one page. If your one page doesn't answer those questions, they will form their own answers from whatever they heard in the corridor.

Technical teams and future responders want the timeline, the indicators, the queries that worked, and the detail of what was actually touched. They will read everything, possibly a year from now, when something similar happens.

Trying to serve both in one voice produces a document that serves neither. Write the executive summary as a genuinely standalone page, then the technical body underneath it.

What belongs in the one page

Keep it to five short blocks:

What happened. Two or three sentences, in plain English. "An attacker obtained the credentials of a finance user through a phishing email and accessed their mailbox for four days before being detected." No tool names, no technique IDs.

Impact. What was actually affected — systems, data, people, service availability. Be specific about what you know and equally specific about what you don't. "We have no evidence of data being copied out" is a different statement from "no data was copied out", and the difference matters enormously later.

Current status. Contained, eradicated, monitoring, or still active. Give a date, not an adjective.

Root cause. Singular where possible. Resist the urge to list every contributing factor here — that belongs in the body. Leadership needs the one thing that, had it been different, would have prevented this.

What we're changing. Three to five actions, each with a named owner and a date. This is the part that determines whether the incident produces improvement or just paperwork.

Things that quietly ruin reports

Passive voice around decisions. "It was decided to isolate the host at 14:20" hides who decided and how long it took them. "The on-call lead isolated the host at 14:20, twelve minutes after the alert" is a fact you can improve on.

Confidence you don't have. Use consistent language — confirmed, assessed with high confidence, possible — and define it once at the top. Mixing certainty levels without signalling them is how a "possible" becomes a board-level "definitely" by the third retelling.

Blame framed as root cause. "User clicked a link" is not a root cause. It's the expected behaviour of a human being who receives two hundred emails a day. The root cause is upstream: why the link reached them, why the credential worked from an unfamiliar location, why it took four days to notice.

Actions without owners. An action item assigned to "IT" or "the security team" is an action item that will still be open at the next incident review.

Write the timeline as you go

The single biggest quality improvement available is not a writing technique — it's keeping a running log during the incident itself. Timestamps, decisions, who was told what and when. Reconstructing this a week later from chat history is miserable, slow, and produces a worse document.

A shared document with append-only notes, updated by whoever is on point, costs almost nothing during the response and saves days afterwards.

The report isn't finished until something changed

A useful test: three months after the report, can you point at something that is measurably different? A new detection, a removed permission, a shortened escalation path?

If not, the incident cost you everything it cost and bought you nothing.