Why Review at All
When an incident is over, the temptation is to move on. People are tired, the backlog has grown and the immediate pressure is gone. But the period right after an incident is when a team can learn the most. A review captures what happened while memories are fresh, and turns an unpleasant event into improvements that make the next one smaller or easier.
A review is also how you find out whether your response plan matched reality. Plans written in calm conditions often have gaps that only show up when real people use them under stress.
The Blameless Principle
The goal is to understand how the situation came about, not to decide who is at fault. Someone clicked a phishing link, someone misconfigured a setting, someone delayed a patch. If the review ends with “the person should have been more careful,” it has probably stopped too early. Asking why the system allowed one mistake to cause serious harm leads to better answers: no second check, a confusing process, a missing alert, too much access, a team too stretched to keep up.
Blaming individuals has a practical cost. People who expect punishment hide mistakes, delay reporting and tidy up evidence, which makes future incidents worse. Blame-free does not mean consequence-free for deliberate misconduct or repeated disregard of clear rules, but those are handled separately and not in the learning review.
When to Hold One
Hold a review after any significant incident, and after minor ones that revealed a surprise or a near miss. Many teams set a rule of thumb, such as a review for anything above a certain severity level in their plan, plus anything the incident lead requests. Aim to hold it within a week or two of resolution, early enough that details are remembered but late enough that people have rested.
Before the Meeting
Preparation makes the meeting short and productive.
- Gather the record. Collect the timeline, relevant logs, tickets, chat transcripts and any messages sent to staff or customers. If a record keeper was assigned during the incident, their notes are the starting point.
- Draft a timeline. List key moments in order with approximate times: when the activity began (as best known), when it was detected, who was told, what was contained and when, when service returned.
- Invite the right people. Include those who responded, representatives from affected teams, and someone from management who can approve changes. Keep the group small enough for everyone to speak.
- Appoint a facilitator. Ideally this is someone who was not leading the response, so the lead can participate as a witness rather than defend decisions.
Running the Meeting
A workable structure, often fitting in an hour or so for a modest incident:
- Set ground rules. State that the aim is learning, that people will be treated as acting reasonably on what they knew at the time, and that the notes will focus on systems and processes.
- Walk through the timeline. Ask participants to correct and add detail. Differences between people’s memories are useful information.
- Discuss decision points. At each key moment ask what was known, what options were considered and why one was chosen. Avoid hindsight: it is easy to judge decisions once the outcome is clear.
- Identify contributing factors. Rarely does one cause explain an incident. Look at several layers: how the attacker or fault got in, why it was not caught sooner, why it spread, why recovery took as long as it did.
- Note what went well. Something that worked, like a fast report from a user or a backup that restored cleanly, deserves to be repeated deliberately.
- Agree on actions. Finish with concrete improvements, not general intentions.
Techniques like asking “why” several times in a row can help reach the underlying issue, though they should be used with care, because a chain of whys can drift toward a single person if the facilitator is not watching.
Writing Actions That Happen
The most common failure of a review is a list of ideas that nobody carries out. Each action should have:
- a clear description of the change
- a named owner (a person, not “the team”)
- a realistic due date
- a way to tell when it is done
Keep the list short and prioritized. Five completed improvements are worth more than twenty abandoned ones. Track them where other work is tracked, such as in the help desk or project system, and revisit them at a regular meeting. Some actions will change process, like clearer escalation steps, and others will be technical, such as better monitoring or tighter permissions.
The Written Report
Summarize the review in a short document: what happened, impact, timeline, contributing factors, what went well, and actions with owners. Write it in plain language so non-specialists can follow it. Decide who may read it, bearing in mind that sensitive technical detail may need limited distribution. Where personal data was involved, consult those responsible for privacy before sharing details widely.
Feeding Back Into Preparation
The review is the bridge back to the start of the response cycle. Update the response plan, contact lists and checklists with what you learned. Add new detections for the signs you missed. Consider whether the lessons belong in security awareness material, so staff benefit too.
Over time, a habit of honest, blame-free reviews tends to make people more willing to report problems early. That willingness is often the most valuable result of all, and it cannot be guaranteed, but it grows when people see that speaking up leads to improvement rather than punishment.