Why most post-incident reviews change nothing
Three failure modes. The review is written by the team that ran the response, so it becomes a defence. It is written from memory a month later, so the timeline is wrong. And it ends with lessons but no actions, so "we need better communication" is still true at the next incident. The template fixes each: a facilitator who was not in the response, a timeline built from logs within ten days, and a lessons table where a row without an action cannot be saved with a straight face.
Seven sections
| Section | Content | Rule |
|---|---|---|
| 1 Summary | What, when, how long, services affected against tolerance, impact in numbers | Numbers from logs and finance, not estimates |
| 2 Timeline | Key events and decisions with time, who, deviation from plan | Built from logs and messages before interviews |
| 3 What worked | Specific, with the plan element that made it work | Keep it: this is what the next exercise must not break |
| 4 What did not | Observation, root cause ("why" five times), category | System causes, not names |
| 5 Lessons and actions | Lesson, corrective action, owner, due date, verification method, status | No action, no lesson |
| 6 Document changes | Which plan or procedure changes, version, date | Plans are amended, not annotated |
| 7 Sign-off | Facilitator, crisis team leader, observer | Review is closed only when actions are logged |
Download the template
Download the template. Seven sections with tables, a worked example row and four facilitation rules. Docx, three pages. One document per incident or exercise.
Download docx (lessons-learned-template.docx)
The same template is used after tabletop exercises; the exercise pack on the tabletop page feeds section 2 directly. No registration, no forms. Need it adapted to your organisation or a full programme: see how we work.
Running the review
- Schedule it within ten working days of stand-down; memory decays faster than that.
- Build the timeline first from the incident log, messages and system records; circulate it before the meeting.
- Open with what worked. It sets the tone and protects the things that must survive the next change.
- For every failure ask "why" until the answer is a process, a tool, a contract or a plan, never a person.
- Close with the actions table filled in the room, owners present, due dates agreed.
- Report open actions to management monthly until closed; verification is a test, not a tick.
What regulators expect
Both AE/SCNS/NCEMA 7000 and ISO 22301 require evaluation after incidents and exercises with results documented and improvement actions tracked; the CBUAE operational resilience framework expects lessons learned to feed back into plans and tolerances. A reviewer will ask for the review, the action log and the amended plan version, in that order. The internal audit checklist includes that trail as a criterion.
Frequently asked questions
What is a lessons learned review?
A structured review after an incident or exercise that establishes what happened from records, separates what worked from what did not, finds root causes and turns each lesson into a corrective action with an owner, due date and verification method.
Who should facilitate the post-incident review?
Someone who was not part of the response: the BCM manager if the crisis team ran the incident, internal audit or risk if the BCM manager did. The crisis team leader signs off but does not facilitate.
When should the review take place?
Within ten working days of stand-down. The timeline is built from logs before the meeting; the meeting itself takes one to two hours.
How is a lessons learned review different from an incident report?
The incident report describes the event; the review changes the system. Its output is a tracked set of corrective actions and amended plans, not a narrative.