After an incident: a short, blameless review.

Why blameless

People report sooner, and fix more, when they are not afraid of the review.

• Look at systems and conditions, not people. Ask what made the mistake easy and the response slow: a missing check, an unclear step, a contact nobody had. The NCSC suggests asking about people, process and technology: were the data and tools there, did the processes and communications work, were the right people involved and able to decide?
• Blame stops reporting. The NCSC explains that people need to feel safe from negative repercussions before they speak up; without that, they cover up mistakes. Its guidance is that incidents are investigated to learn and improve, not to blame, and that people involved are treated fairly, with no punishment for innocent mistakes.
• The organization owns the incident. In its toolkit for boards, the NCSC says responsibility for incidents sits with the organization, not an individual, and that a useful review needs people to be honest and objective about what happened.

Blameless does not mean nothing changes. It means the changes are to how you work, so the same thing is less likely to happen to whoever is in that seat next time.

When to hold it

Soon after, once things are stable.

• Once things are stable. The emergency is over, accounts are back under control, and nobody is still firefighting. NIST describes “lessons learned” meetings being held when an incident’s recovery is concluding.
• Soon, while memories are fresh. Pick a date within a couple of weeks and put it in calendars before the incident is closed.
• Do not save every lesson for the meeting. NIST notes that lessons learned during a response should often be shared as soon as they are identified. Note them in the incident log as they come up.
• Small incidents count too. A near miss, such as a phishing email someone reported before anyone clicked, can be a 20-minute version of the same review.

Who joins

The people who were there, and the person who can say yes to changes.

• The people who were involved, including whoever first noticed or reported it. NIST describes the meeting as a chance to hear from all parties involved.
• Whoever looks after your systems: a staff member, a volunteer or your IT provider.
• The person who decides, usually the director or manager, so actions can be agreed in the room.
• A facilitator who keeps time and the tone, ideally someone who did not lead the response, and someone to take notes.

Keep it small. If outside parties were involved (your bank, insurer or a supplier), ask them for what they know beforehand rather than inviting everyone.

A 60-minute agenda

Enough time to learn something; short enough that it happens.

Send the incident log and the agenda the day before. This running order is our suggested format; adjust it to the incident.

Questions to ask

About the incident, and about the response.

The NCSC splits a post-incident review into lessons from the incident itself and lessons from the response. CISA’s playbook adds roles, training and tools. In plain words:

1. What happened, and when?Build the timeline from the incident log: when it started, when it was noticed, what was done, when it ended.
2. What helped?A quick report, a phone number that worked, a backup that restored, a clear decision.
3. What got in the way?Information that was hard or impossible to get, missing logs, a password nobody had, an unclear owner.
4. What could have prevented it, or spotted it sooner?Both quick fixes and longer-term changes, as the NCSC suggests.
5. Were roles, decisions and contacts clear?Did people know who decides and who to call? CISA lists reviewing roles and responsibilities.
6. What do people need to learn?Training or a short briefing, for staff or for whoever responds next time.
7. What will we change?Three to five actions you can actually do.
8. Who owns each action, and by when?One named person and a date for each. “Everyone” and “soon” are not owners or dates.

Writing it up on one page

Short enough to read, specific enough to act on.

Keep the write-up to one page, with these parts:

1. What happened. Two or three sentences: what happened, when it was noticed, and how it ended.
2. Timeline. The main moments, oldest first, taken from the incident log.
3. Impact. What was affected: systems, money, people, services, information. Say what is still unknown.
4. What helped. The things that worked and should be kept.
5. What got in the way. Missing information, tools, access, contacts or decisions, and unclear steps.
6. What we will change. Three to five actions, each with one owner and a date.
7. Updates to our plan and self-assessment. What changes in the incident plan, and which self-assessment answers change.
8. What we will share, and with whom. What staff, the board and anyone else will be told, and by whom.

Use plain language and no names next to mistakes: write “the finance mailbox password was entered on a fake page”, not who entered it. The Canadian Centre for Cyber Security calls this a lessons learned document: how you will adjust and improve your plan for future incidents.

Following up on actions

A review with no follow-up is just a meeting.

• Put the actions where you will see them: a shared list, the next team meeting’s agenda, or the board report.
• Check them on a set date, written on the review page. Mark each one done, moved (with a new date) or dropped (with a reason).
• Close the loop with the person who reported. The NCSC suggests following up with reporters to thank them and tell them what was done.
• Test the fix. CISA’s ransomware guide says to use lessons learned to refine policies, plans and procedures and to guide future exercises. A short tabletop run-through of the same scenario shows whether the change worked.

What to share with staff and the board

Enough to learn from, without naming anyone.

• Staff: what happened in general terms, what is changing, and thanks to the person who reported. The NCSC recommends sharing the lessons learned and the improvements made. Do not name the person who clicked, and do not share details still under investigation.
• The board or trustees: the one-page review, the actions with owners and dates, and anything that needs their decision or money. The NCSC’s toolkit for boards says the board is ultimately responsible for any cyber security incident, and that organizations should have processes for post-incident analysis.
• Others: your insurer, bank or a regulator may ask for the review or the log. If personal information may have been involved, check your duties in privacy duties, country by country. CISA also invites organizations to share lessons learned with it or their sector’s information sharing body, to help others.

How it feeds your plan and self-assessment

Each review should leave you better prepared for the next incident.

• The incident plan. Update contacts, decision-makers and first steps in your one-page incident plan. NIST recommends reviewing plans periodically or when significant improvements are identified, and the Canadian Centre for Cyber Security says to test, revisit and revise your plan annually.
• The self-assessment. Retake the security self-assessment with the review in hand. NIST lists self-assessments as one way to find improvements, and the answers that changed show where to start.
• Templates and guides. The templates include an incident contact sheet and a device and account inventory; the security basics field guide explains each area.
• Help with the fixes. Eligible organizations can apply for Shield, Moraph for Good’s security program. A person reads every application; it is not an emergency service.