How-to · Template
How to run a post-incident review (with a template)
A practical, blameless way to learn from incidents and turn lessons into owned, tracked actions.
A post-incident review (also called a post-mortem or after-action review) turns an incident into lasting improvements. NIST SP 800-61 Rev. 3 treats lessons learned as part of continuous improvement across the whole incident response lifecycle, and Google’s SRE practice made the blameless post-mortem widely known.
When to hold one
- After every significant incident, and after near misses that could have been significant.
- Within about one to two weeks, while memories and logs are fresh.
- After major exercises and tabletop tests too, not only real incidents.
How to run it
- Collect the facts first. Tickets, logs, chat history and the incident timeline.
- Invite the right people. Responders, system owners, the service desk, communications and, where needed, legal and suppliers.
- Keep it blameless. Ask how the system allowed the mistake, not who made it. People share more when they are not afraid.
- Find the root causes. Use “5 whys” and look for several contributing factors, not one.
- Agree actions. Each with one owner, a date and the evidence that will show it is done.
- Track to closure. Put actions in the risk or issue register and report overdue ones to leadership.
Template
Copy this structure into your own document or ticket.
1. Summary
Two or three sentences: what happened, impact, current status.
2. Impact
Who and what was affected, for how long, data involved, customers, money, regulatory duties.
3. Timeline
Times (with time zone) from first sign to detection, containment, recovery and closure. Facts only.
4. Detection
How it was found, by whom, and how long it went unnoticed.
5. Root cause and contributing factors
Use “5 whys” or a fishbone. Look for process and control causes, not a person to blame.
6. What went well
Controls and decisions that limited the damage. Keep them.
7. What did not go well
Gaps in prevention, detection, response, communication and recovery.
8. Control failures mapped
Each failed or missing control, mapped to your framework (for example ISO 27001 Annex A or NIST CSF).
9. Actions
Each action with one owner, a due date, a priority and how completion will be evidenced.
10. Notifications
Regulators, customers, insurers and law enforcement contacted, when and by whom.
11. Sign-off and follow-up
Who approved the review, and the date actions will be checked for completion.
What auditors look for
- A review exists for each major incident, with a timeline and root cause.
- Actions are owned, dated and closed with evidence.
- Lessons fed back into risk assessments, controls, playbooks and training.
- Repeat incidents are spotted and escalated.