The Post-Incident Review Nobody Follows Through On
The incident is over. The attacker is out, or at least you are reasonably confident they are. The affected systems are back online. People slept. The postmortem meeting is on the calendar for Thursday, and the general vibe in the channel has shifted from "crisis" to "let's please not talk about this anymore."
Thursday's meeting will last ninety minutes. Most of it will be a timeline recap that everyone already lived through. The last twenty minutes will produce five action items. Three of them will be assigned to the same person because they were the most engaged in the conversation. None of them will have a deadline more specific than "Q3." By the time Q3 arrives, two will be marked complete in a status that does not reflect reality, one will have quietly moved to Q4, and one will not be mentioned again.
This is not dysfunction. This is the median post-incident review, and organizations that think they are learning from their incidents are, in most cases, collecting documentation of what happened rather than actually improving what they do.
The Blame Problem Is Subtler Than You Think
Blameless post-mortems are a well-understood concept. The idea is to analyze what happened from a systemic perspective rather than asking who made the mistake, because "who made the mistake" is both usually the wrong question and produces the wrong incentives. People who know they might be blamed for an incident do not surface information that might implicate them.
Most organizations that have adopted the blameless format still run blame-focused reviews. They just do it implicitly. The tone of the room changes when you reach the part of the timeline where a human made a decision that made things worse. The phrasing gets careful. People who were in the room know who is being discussed even when names are not used. The individual still learns, informally, that the decision they made during a high-stress crisis was the focus of the postmortem, and they adjust their behavior accordingly - and not always in ways that help you.
True blameless review is not about avoiding accountability. It is about directing accountability toward the systems, processes, and conditions that produced the failure. The person who deployed the misconfigured change without a review did so because there was no process requiring review, or because the review process had become a rubber stamp under deadline pressure, or because the tooling made the safe path harder than the fast path. Fix those. The individual is a data point in a pattern, not the pattern itself.
The Timeline Is Not the Lesson
In a typical postmortem, the majority of time goes to reconstructing what happened. This makes sense emotionally. Everyone wants to agree on a shared account of reality before moving forward. But the timeline is not the lesson. The lesson lives in the questions you ask about the timeline, and those questions need time to breathe.
Why did the initial alert take four hours to escalate? Not "who was on call" but what is the escalation criterion and does it match what that alert was actually indicating. Why was the logging gap there? Not "nobody turned logging on" but what is the process for ensuring logging is configured before a system goes to production. What made the attacker's lateral movement so easy? Not "the firewall rule was too permissive" but why that rule existed, how long it had been there, and what process would have caught it.
These are harder questions. They take longer. They sometimes point to problems that are uncomfortable to name because fixing them requires either resources or changes to how influential people work. That is exactly why they need to be asked explicitly rather than left to the margins of a timeline discussion.
The Action Item Is Not a Plan
The standard output of a postmortem is a list of action items. Action items are not a remediation plan. They are a list of intentions. The distance between an intention and a change in your security posture is filled with priority decisions, competing demands, and the passage of time, all of which work against the postmortem ever producing a material improvement.
Effective postmortem follow-through requires a few things that are almost never present. Named single owners, not teams and not shared responsibilities. Deadlines specific enough to know on a given day whether they are missed. A mechanism to track completion that is not the honor system. And a check-in at the next postmortem to report what was actually done.
The organizations that consistently improve after incidents have usually built exactly this process, and they protect it from the pressures that typically kill it. Product roadmaps do not automatically displace postmortem action items just because they were documented after the incident. The leadership team that sponsored the incident response also follows up on whether the remediations happened.
What Good Looks Like
A well-run postmortem is structured around a different set of questions than the ones most reviews ask. Not just what happened, but what conditions made it possible. Not just what we will do, but how we will know it was done. Not just what failed, but what worked - because identifying what held up under pressure is at least as useful as identifying what did not.
Run it soon enough that memory is fresh but not so soon that people are still in crisis mode. Forty-eight to seventy-two hours after resolution is often about right. Include the people who were actually in the incident, not the managers of the people who were in the incident.
Keep the culture honest by measuring whether your past postmortem recommendations were actually implemented. If they were not, that is a finding. Not for Thursday's meeting, but for whatever owns your security improvement program.
The incident is over. The work that determines whether it happens again in the same way - or worse - starts on Thursday. Make Thursday count.