Somewhere in every incident response plan there’s a slide titled “Lessons Learned,” and somewhere in every organization there’s a folder where that slide goes to die. I’ve sat through enough of these reviews to know the pattern: the war room energy is gone, half the room is checking email, and the action items get assigned to “the team” instead of a person. Then, six months later, the same misconfigured firewall rule causes the same incident, and everyone acts surprised.

cover

That gap between what frameworks require and what organizations actually do is a discipline problem disguised as a documentation problem, and it’s worth taking apart properly.

In brief

  • The post-incident review has the highest value-to-cost ratio of any activity in the incident lifecycle, yet it’s the step most often reduced to a formality.
  • Both NIST SP 800-61 (2025 revision) and ISO/IEC 27035:2023 treat lessons learned as a mandatory, continuous input into preparation, not a closing ceremony.
  • Blameless review does not mean no accountability, it means asking what in the system allowed a reasonable person to make that error.
  • A finding only counts if it converts into an action with an owner, a deadline, and a closure criterion.
  • Reviews fail for three predictable reasons: no time once the pressure drops, no repeatable method, and a punitive culture that shuts down disclosure.
  • Near-misses deserve the same scrutiny as major incidents, because they’re cheaper to analyze and often more informative.

From closing an incident to actually learning from it

The idea that incident response ends with “systems restored” is a comfortable fiction. The current version of NIST’s incident response guidance folds what used to be a distinct post-incident activity phase into a continuous loop aligned with the Cybersecurity Framework 2.0, where lessons learned feed straight back into preparation rather than sitting in a separate document. ISO/IEC 27035:2023 makes the same point from a different angle, treating the lessons-learned step as an explicit, non-optional part of the incident management process, not an appendix.

The practical consequence is that a review which doesn’t change anything concrete, a detection rule, an access control, a training module, an escalation path, has failed regardless of how thorough the write-up looks. I made a version of this argument when writing about treating incident reports like well-constructed narratives: every artifact you mention in a report is a promise to the reader, and every finding in a review is a promise to the organization. Leave either unresolved and you’ve written fiction, not analysis.

Blameless is not the same as consequence-free

The single biggest reason reviews collapse is fear, and it predates cybersecurity by decades. Aviation and healthcare worked this out first: when an incident review turns into a hunt for who to blame, people stop talking. The person who made the mistake buries it, the person who noticed something odd stays quiet, and the resulting picture is clean, comfortable, and useless.

Blameless review, borrowed from site reliability engineering and now standard practice in mature IR programs, starts from a specific assumption: everyone involved acted in good faith with the information they had at the time. The question shifts from “who broke this” to “what in the system made this failure possible, and how do we make it structurally harder to repeat.” That’s not the same as removing accountability. If someone repeatedly ignores a documented process or acts with clear negligence, that’s a personnel conversation, not a systems one, and blameless culture was never meant to shield that. What it protects is the much larger category of honest mistakes made by people operating inside flawed processes, which is where most real risk actually lives.

I touched on a related dynamic in the “Total Football” piece on incident response as a team sport: teams that can shift roles fluidly under pressure only work if nobody’s afraid that admitting confusion mid-incident will be used against them later. The same trust has to survive into the review room, or the fluidity disappears the moment the pressure is off.

Findings are not the deliverable, actions are

Every review produces a document with a summary, a timeline, a root cause section, and an impact assessment. None of that changes anything by itself. The only output that matters is the action list, and an action only counts as real if it has three attributes: a named owner, a deadline, and a defined closure criterion. Miss any one of the three and the item quietly disappears. No owner means nobody does it, no deadline means it slides indefinitely, no closure criterion means someone marks it “done” without it being done.

Root cause analysis is where most reviews get lazy. “An employee clicked a phishing link” is not a root cause, it’s the first available explanation, and stopping there is how the same incident recurs with a different employee’s name attached. The useful version keeps asking why: why did that message reach the inbox, why didn’t the filter catch it, why did that click have the blast radius it had. Each answer should move one level closer to something the organization can actually fix, whether that’s a detection gap, a segmentation failure, or a training program that exists on paper but not in practice. This is the same discipline I described when writing about the operational resilience requirements under DORA, where the review isn’t the final step of a recovery runbook, it’s the mechanism that determines whether the next recovery goes any better.

Why reviews get skipped, and what actually fixes it

Organizations don’t abandon post-incident review out of laziness, usually. Three specific forces conspire against it.

  • Time pressure: once the emergency ends, teams return to backlog and the review meeting slides further into the calendar until nobody remembers the details accurately.
  • No repeatable method: without a structured agenda, defined roles, and a consistent format, even a solid incident response plan won’t stop the meeting from turning into an unstructured conversation that goes nowhere.
  • Punitive culture: this is the most corrosive one, because it doesn’t just weaken the review, it poisons the input data before the meeting even starts.

There’s also a scoping mistake worth naming directly: treating review as something reserved for major incidents. Near-misses, the events caught before they escalated, are cheap to analyze and often more informative than disasters, because they show what actually worked under stress. An organization that only reviews catastrophes learns slowly and expensively. I made a related point in the CrowdStrike Falcon retrospective, where the lesson wasn’t really about one vendor’s bad update, it was about how much a single point of failure can teach you if you’re willing to look at it honestly instead of filing it under “vendor problem, not ours.”

The organizations that come out stronger after an attack aren’t the ones with the cleanest incident, they’re the ones willing to sit with an uncomfortable timeline long enough to change something real about how they operate.

FAQ

What is a blameless post-incident review? It is a review process that treats errors as evidence of system weaknesses rather than personal failures, so people report what actually happened instead of what makes them look competent.

How is the 2025 NIST guidance different on lessons learned? The revised NIST SP 800-61 dissolves the old standalone “post-incident activity” phase into a continuous loop aligned with the Cybersecurity Framework 2.0, feeding lessons directly back into preparation.

Why do post-incident reviews usually fail? They fail for three predictable reasons, lack of time once the pressure drops, no repeatable method or agenda, and a punitive culture that makes people hide what they know.