The Post-Incident Review: A Lessons-Learned Process That Survives the Blame Question

Key takeaways

• The review is a NIST 800-61 phase, not a courtesy. Lessons learned closes the incident response lifecycle, and its output is supposed to feed straight back into preparation. A skipped review leaves the plan exactly as wrong as it was.
• Timing matters: hold it within two weeks. Long enough that the fires are out, short enough that memory and logs are still fresh.
• Blameless is a method, not a vibe. The review examines decisions and systems, not people. The distinction that keeps it honest: accountability for what was documented and decided, without prosecuting the decisions people made with the information they had.
• Privilege shapes what you write down. When breach counsel directs the review, the work product can be protected. That changes both who attends and how honestly people speak. Decide it before the meeting, not during.
• The deliverables are owned actions, a board summary, and plan changes. A review that produces no changes was a meeting.

What a post-incident review actually is

NIST SP 800-61 ends its incident response lifecycle with a lessons-learned phase: hold a review, examine what happened, and use the findings to improve. The framework page covers where the phase sits in the lifecycle. In practice, the review answers five questions in order: what happened, when did we know, what did we do, what worked, and what changes.

The review is not the forensic report read aloud. The forensics establish the facts of the intrusion. The review examines the response: detection, escalation, decisions, communications, recovery, and the plan's promises versus what actually happened. Organizations that conflate the two get a technical debrief that skips the organizational failures, which are usually where the real losses were.

Who attends, and who leads

Attendees: everyone who made or escalated a decision during the incident. That usually means security, IT operations, legal, communications, and the business owner of the affected system. The executive sponsor attends or explicitly receives the output; a review whose findings vanish into a team nobody funds was theater.

The leader question is the important one. An internal facilitator knows the context and carries internal politics into the room. An external facilitator (often the retainer IR firm, or an independent consultant) arrives without a stake in who looks good, which matters most after incidents involving leadership decisions. For significant breaches, reviews conducted under breach counsel's direction serve a second purpose: the work product can sit under legal privilege. That decision, who leads and under whose direction, belongs to counsel and the executive sponsor before invitations go out. Our retainer cost guide covers what firms charge for this and how to compare.

The structure that works

Run the review in this order, and timebox the whole thing to two or three hours. Longer reviews rehash; they do not reveal.

1. Timeline reconstruction. One shared timeline from first detection to closure: what was observed, when, by whom, and what was done. Disagreements about the timeline are findings, not noise: if two people remember the escalation happening differently, the escalation path is ambiguous.
2. Detection analysis. Time from initial compromise to detection, and time from detection to escalation. Compare both against your targets. If detection took three weeks, the finding belongs to monitoring, not to the response team.
3. Decision audit. Revisit the hard calls: containment scope, shutdown decisions, ransom posture, notification timing. For each, establish what information the decider had at the time. The question is never "would you decide differently now," which everyone answers yes. It is "did the plan pre-authorize this call, and did the decider have the authority and the information the plan promised."
4. Communications audit. The notification clocks you faced (SEC, regulators, contracts), what went out, when, and how much rework the facts required. Call center and helpdesk volume counts belong here.
5. Control and plan changes. The concrete list: detections to deploy, access to revoke permanently, contracts to renegotiate, plan sections to rewrite, drills to schedule (our drill guide covers the follow-up testing).

Keep a scribe. The gap between what people say in the room and what gets remembered a month later is where improvement goes to die.

The blame question, handled

Reviews fail in two directions. Run them as trials and people stop volunteering what actually happened, which is the raw material the review needs. Run them as nothing-happened debriefs and the same gaps survive to the next incident.

The method that holds: examine decisions, not people. Every action gets assessed against what the actor knew, the authority they had, and what the plan said. A responder who improvised outside the plan is not the finding; the plan's failure to authorize or forbid the action is the finding. The exceptions are process violations: someone bypassed evidence handling, or deleted data against counsel's instruction. Those get named, because a review that cannot name them protects the wrong thing.

This is the same principle site reliability engineers formalized after outages: the system that let a mistake matter is the system to fix. It translates to incident response with one addition, the legal layer. Under privilege, honesty is cheap. Without it, every written sentence is discoverable. That is why the privilege decision comes first.

The deliverables

Three documents leave the room.

• The action list. Every finding with an owner and a due date, tracked like the project it is. This is the only deliverable that changes anything.
• The board or executive summary. One page: what happened in business terms, what it cost, what changes now. For public companies this feeds the disclosure record that Item 1.05 and the annual cyber governance disclosure stand on.
• The plan update. The incident response plan gets its revisions, with a new version date. The review is also the natural moment to revisit retainer terms and panel access, while the gaps are fresh and specific.

The next drill should test at least one change the review produced. That closes the loop: incident, review, change, drill, and a plan that is measurably harder to break than it was in the last cycle.

Frequently asked questions

When should the post-incident review happen? Within two weeks of closure. The tension is real: run it too early and recovery work pulls people out of the room; run it too late and the timeline becomes negotiated memory.

Who should lead the review? Whoever can keep it factual without a stake in the outcome. Internal for smaller incidents, external for significant ones, and under breach counsel's direction when privilege matters. Decide before the invitations, not in the meeting.

What is the difference between a post-incident review and a root cause analysis? Scope. RCA answers why the incident technically happened: the vector, the control gap, the sequence. The post-incident review answers how the organization responded and what changes now. RCA is usually an input to the review, not a substitute for it.

What do we do with the findings nobody wants to fund? Prioritize honestly. The action list is a risk decision like any other, and the executive summary exists so the trade-offs are made above the team, not silently inside it. An unfunded finding is a decision; an unfaced one is a liability.