Post-Incident Review
The incident is not over when the attacker is gone — it is over when the organization has learned from it. The post-incident review, a blameless post-mortem, reconstructs what happened, why the controls that failed failed, and what specific changes prevent a repeat — and its output is a tracked list of improvements, not a document that is filed and forgotten.
This topic closes the IR chapter and connects the whole book back to Chapter 1: every incident is a threat model validated in the worst way, and the review is how it makes the program stronger.
Blameless by Design
People who fear blame withhold the details that matter, so the review targets systems and processes, not individuals. The goal is truth and improvement, and a culture that punishes turns the most valuable learning source into a cover-up (the same reporting-culture point from Chapter 9). Blameless does not mean no accountability — it means accountability aimed at systems, where the fixes actually live.
Reconstructing and Analyzing
Walk the timeline (the forensics of this chapter): how did they get in, why did detection not fire sooner, what let them spread, what worked. Separate the root cause from the symptoms, because fixing the symptom — this host, this account — while leaving the cause — the missing control, the process gap — leaves the door open for the next intrusion to walk through the same way.
Actionable, Tracked Improvements
The output is specific, owned changes with deadlines: a new detection, a closed gap, a process fix, each tracked to completion. A review whose findings are not tracked and closed is theater, and the same incident recurs. The measure of a good review is not the quality of the document but whether the improvements actually landed.
Feeding the Whole Program
Improvements flow back everywhere: new detections (Chapter 10), closed vulnerabilities (Chapter 7), threat-model updates (Chapter 1), process and training changes (Chapter 9). The review is the loop that makes "assume breach" a system that gets stronger, not just survives — Meridian's post-mortem traces the entry vector (the web flaw of Chapter 6), the detection gap, and the tracked fixes across the program, closing the book's arc where it began, at the threat model.
Blameless — examines why the system allowed the failure, gets honest detail, and produces systemic fixes; people report freely.
Blame-focused — finds someone to fault, drives the real causes underground, fixes nothing systemic, and ensures the next incident is hidden longer. Blameless is not "no accountability" — it is accountability aimed at systems, where the fixes live.
- Blame-focused reviews that punish individuals, suppressing the honest detail needed to find the real cause.
- Fixing symptoms — this host, this account — without the root cause (the missing control, the process gap), leaving the door open.
- Producing findings that are not assigned, tracked, or closed, so the review is a filed document and the incident recurs.
- Skipping the review after "small" incidents, missing the cheap lessons that prevent the big one.
- Writing a polished report but never feeding its findings back into detection, hardening, or threat-modeling.
- Run every incident's review blamelessly, targeting systems and processes to get honest, complete analysis.
- Separate root cause from symptoms and fix the cause, validating against the timeline and evidence.
- Produce specific, owned, deadlined improvements and track them to completion across the program.
- Feed findings back into detection, hardening, threat modeling, and training — closing the loop to Chapter 1.
- Review small incidents too, since they carry the cheapest lessons.
Knowledge Check
Why is a blameless review more effective than a blame-focused one?
- Fear of blame makes people withhold the detail needed to find the real cause
- Blameless reviews are faster to complete
- Blameless means no one is ever held accountable
- Blame-focused reviews reliably find the true root cause far more often than blameless ones
Why must a review separate root cause from symptoms?
- Fixing the symptom leaves the cause open to reuse
- Symptoms are always much harder to fix than their root causes
- Root causes are irrelevant once the attacker is gone
- Separating the two is only ever needed for legal reasons
What makes a post-incident review more than theater?
- Its findings become owned, deadlined fixes tracked to completion
- It produces the longest possible written incident report for the archive
- It identifies which employee to discipline
- It is filed with management and archived
You got correct