Running a blameless post-incident review that produces real improvements

Purpose

A post-incident review asks what happened, why it was possible, how detection and response went, and what will change. Blameless means focusing on systems, processes, and decisions in context rather than punishing individuals, so people share what really happened.

An agenda

Hold the review within two weeks, while memories are fresh. Walk through the timeline, then discuss what went well, what was hard, and what was lucky. Identify contributing factors: missing logging, slow approvals, unclear ownership, unpatched systems. Agree on action items, each with an owner, a due date, and a way to verify completion.

• Timeline review
• What went well
• What was difficult
• Contributing factors
• Action items with owners and dates

Lab: write a review document

Use one of the scenarios from earlier lessons. Write a review document with these sections: summary in three sentences, impact, timeline, detection (how and when we found out), response (what we did and how long each stage took), contributing factors, and five action items. Make at least one action item about detection and one about preparation. Then check each item: is it specific, owned, dated, and verifiable?

Follow-through

Track action items in the same system the team uses for other work and review them in a monthly meeting. Reviews that produce no completed changes teach people that reviews do not matter. Update playbooks and run a tabletop that tests the changes.