Writing the Incident Report

The response is over, the box is rebuilt, everyone wants to go home. The report is the only part of the whole incident that outlives it. It is what the next responder reads, what leadership uses to fund the fix, and what legal reaches for if this turns into a lawsuit or a breach notification. A sloppy report wastes the entire response.

Write it for two readers at once. Executives need the impact and the ask in the first half page. Engineers need the technical detail to actually close the gap. Lead with a short executive summary, then go deep, so each reader finds their altitude without fighting the other's.

The four sections that carry the report

Timeline is the spine. Every confirmed event with a UTC timestamp, in order, from the attacker's first action to your last recovery step. This is where all those timestamped log lines and case-note entries pay off. If you kept the case log honestly during the response, the timeline is mostly assembly, not writing.

Impact states what was actually affected in plain terms: which systems, which accounts, how many records, whether data left the building, and the dwell time from first compromise to detection. Say what you confirmed and, separately, what you could not rule out. Never inflate and never soften.

Root cause is the one honest sentence about how this happened. Not the malware name, the underlying failure: an unpatched internet-facing service, a user who entered credentials on a phishing page, a missing MFA control. The symptom is the ransomware. The root cause is what let it run.

Recommendations are specific, assigned, and dated. Not "improve security." Instead: "enforce MFA on the VPN by 2026-08-15, owner IT infrastructure." Each one should trace directly back to something in the timeline or root cause, and each one feeds the preparation phase of the next lifecycle.

Build the timeline from artifacts, not memory

If you ran a full forensic collection, tools stitch your disk and log artifacts into one sorted super-timeline so you are not hand-copying timestamps. Plaso is the standard.

Even without full forensics, keep the format the same: one line per event, UTC timestamp, source, host, actor, action. A timeline anyone can sort and audit beats a paragraph of prose describing roughly what happened.

Drive root cause past the first answer

The five-whys keeps you from stopping at the symptom. Ransomware ran. Why? A user opened a macro. Why did the macro run? Macros were not blocked. Why was the attacker on the network at all? A phished credential with no MFA. Why did that credential reach a server? Flat network, no segmentation. Four whys in, you have three real fixes instead of one useless "user clicked a bad link."

Watch the tone while you write. The report documents system and process failures, not people to blame. "The account had no second factor" is actionable. "The user was careless" ends the investigation and teaches nobody anything.