After a security incident or a near miss, run a retrospective that asks about systems and decisions, not people. A good one produces two or three concrete changes with owners and dates. The prompts below keep the conversation useful and keep it from turning into a search for someone to blame.
Set the ground rules first
State at the start that the goal is learning and that nobody will be punished for what they say. People who fear blame hide details, and hidden details are exactly what you need. If you want to build the habit, see reinforce blameless postmortem culture: a leader's guide.
The facilitator should not be the person most involved. A neutral facilitator can ask naive questions without defensiveness.
Prompts about what happened
- What was the first sign that something was wrong, and who saw it?
- How long between that sign and anyone acting on it? What filled that time?
- What did we know at each decision point, and what did we not know?
- What worked better than expected?
The last question matters. Naming what went well keeps people from concluding that everything was a failure and shows what to protect.
Prompts about causes
- What conditions made this possible? Ask why at least three times in a row.
- Was this a new kind of problem or a repeat of an old one?
- Which assumption turned out to be wrong?
- Where did our checks look right but not actually catch it?
Avoid the question "who made the mistake." Replace it with "what made the mistake easy to make and hard to notice."
Prompts about response
- Did the people on call have what they needed: access, runbooks, contacts?
- Was it clear who was in charge?
- Did communication to customers and leaders feel timely and accurate?
- What did we do manually that could be automated or rehearsed?
Prompts about the future
- If the same thing happened next month, what would we want to be different?
- What is the smallest change that would have prevented or shortened this?
- Which item would we regret not doing if it happened again?
- What are we choosing not to do, and are we comfortable with that?
Close with commitments
End with at most three actions. Each needs a named owner, a date, and a place in the tracker. More than three, and none get done. Everything else goes into a longer list with a decision about whether it belongs on the roadmap. For turning actions into scheduled work, see turn postmortem actions into sprint work.
Follow up
Put a short check on the calendar a month out: did the actions land, and did they help? Share the answer with the team. Retros that never report back teach people that the meeting is theater.
Quick check
Who should run a security retrospective?
Someone not deeply involved in the incident, so they can ask plain questions. The incident lead can contribute but should not facilitate.
How many actions should a retro produce?
Two or three with owners and dates. More dilutes attention and most will quietly stall.
Last reviewed: 19 October 2026.
