Home / Knowledge hub / Post-incident review
Knowledge hub
Post-incident review
A blameless look back at an incident to improve the plan and the system.
What it means
A post-incident review is a meeting and a written record, held after an incident is over, that asks what happened, how well the team responded, and what should change. It is sometimes called a post-mortem or a lessons-learned session. It is held once the fire is out, not during it.
The word that matters is blameless. The review looks at conditions, decisions and gaps in the system, not at who to punish. People only share what they actually saw and thought if they trust that honesty will not be held against them.
Why it matters
Incidents are expensive lessons, and a review is how you collect the value. Without one, the same mistake happens twice, the same alert is ignored again, and the same contact is missing from the call list. A review is cheap compared with a second, identical incident.
It also gives leaders and customers something concrete. A short written summary with dated actions shows that the problem was understood. Several standards and some customer contracts expect lessons to be recorded after serious events, as part of an incident response plan.
How it shows up
A useful review has a timeline, the impact, the root causes, what went well, what did not, and a short list of actions with named owners and due dates. Hold it within days, while details are fresh. Include the people who responded, not just managers.
The common failure is the actions that never happen. The document is filed, and three months on nothing has changed. Track the actions like any other work, review them at a fixed point, and check at the end whether a repeat would now be caught. Update the playbook with what you learned.
Questions people ask
Post-incident review, answered
What does blameless mean in practice?
It means the review asks what made the error possible, not who made it. People are named for their roles and actions only to describe what happened.
The test is whether participants speak freely about their own mistakes.
Who should attend?
The responders, the owners of affected systems, someone from support or communications if customers were involved, and a facilitator who was not central to the incident.
Keep it small enough to stay honest.
How soon after an incident should we hold it?
Within a few days, once the immediate work is done and people have rested. Waiting weeks lets memory fade and logs expire.
For a long incident, hold an interim review as well.
Do we need one for small incidents?
A short version is worth it. Even a half-page note on a near miss can show a gap early.
Save the full meeting for incidents with real impact or surprises.
Should we publish the review?
Internally, yes, to everyone who might learn from it. Externally, many companies publish a shorter summary after major events, as it builds trust.
Remove secrets and sensitive details before sharing.
Sources
Where this comes from
Related
Terms that sit next to this one
Root cause analysis
Working out why an incident happened, so the real cause is fixed.
Incident response plan
A written plan for who does what in the first hours after a security incident.
Incident playbook
A step-by-step guide for handling one type of incident the same way each time.
Tabletop exercise
A talk-through of an incident scenario to test the plan without touching systems.
Security incident
An event that actually harms, or threatens to harm, your data or systems.
Did the lesson reach the code?
We retest the exact exploit against the new code, so a review's action to fix a flaw can be checked rather than assumed. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.