Learning from Incidents Without Blame
How to run an incident review that finds real causes and real fixes, without turning the review into a search for someone to blame, and why blame free review finds more.
The short answer
Learning without blame means reviewing an incident to understand what happened, why the defences did not prevent it, and what should change, without making the review a judgement on individuals. The review asks about the system, the process, the tools, and the information available at the time, rather than about who made a mistake. That approach finds more causes, because people speak candidly when they do not fear punishment, and it produces better fixes, because it addresses the conditions that allowed an error to cause harm rather than merely telling a person to be more careful next time.
Why does a blame focused review fail?
A review focused on blame fails for a practical reason, which is that it stops the flow of information. Once staff believe that the review will single out a person, they will describe events cautiously, omit awkward details, and agree with the simplest explanation that ends the discussion. The review then records a cause that is tidy but wrong, and the firm fixes the wrong thing. Blame also misleads about how incidents happen. Most major incidents involve several contributing factors, such as a design weakness, a monitoring gap, and a decision taken under pressure with incomplete information. Naming one person as the cause hides the other factors, and leaves them in place for the next incident.
What does a good review look like?
A good review starts from the incident log and reconstructs the sequence of events in order, including the decisions taken and the information available at each point. It then asks, for each stage, what would have needed to be different for the outcome to change. That question points to systemic fixes, such as better monitoring, clearer escalation criteria, or a change to a process that set staff up to fail. The review should involve the people who handled the incident, because they hold the detail, and it should be facilitated by someone who was not directly involved, so that the discussion stays open. The output should be a short list of actions, each with an owner and a completion date, rather than a long report that nobody tracks.
Does without blame mean without accountability?
Learning without blame does not mean that nobody is accountable. It means that accountability is placed where it belongs, which is usually on the owner of the process, the control, or the follow up action, rather than on the person closest to the failure. A person who deliberately bypassed a control, or who repeatedly ignored a known risk, raises a different question from a person who made an understandable error in a poorly designed process, and the firm should be able to tell those cases apart. The distinction is best made outside the incident review, through the firm's normal people processes, so that the review itself can stay focused on learning. Conflating the two discussions harms both, because the review becomes guarded and the people process becomes driven by incident emotion.
How are lessons tracked to completion?
Lessons are only learned when the actions they generate are completed, and completion needs tracking. Each action from a review should have a named owner, a date, and a way of checking that it actually changed something, rather than merely producing a document. A later review should check whether earlier actions were completed and whether they worked, because an action that was closed without effect is a lesson that was not learned. Firms that track actions in a simple, visible list usually do better than firms with elaborate lesson databases that nobody opens. The discipline is not in the tool, but in the habit of returning to the list until each item is done or formally reconsidered.
Should lessons be shared beyond the incident team?
Lessons should be shared beyond the incident team, in a form that other teams can use, because the weakness found in one service may exist in others. Sharing does not mean circulating the full incident log, which may contain sensitive detail. It means extracting the general lesson, such as a monitoring gap or a provider dependency, and sharing that lesson with the teams that could face the same problem. Anonymising the account, where that helps candour, can make sharing easier, provided the anonymisation does not hide a lesson that depends on the specific context. A firm that learns only within the team that suffered the incident will pay for the same lesson several times over.
Primary sources on the record
- Regulation (EU) 2022/2554, EUR-Lex text.
- EBA operational resilience, EBA operational resilience pages.
- EIOPA, EIOPA website.
Legal status: Regulation (EU) 2022/2554 in force; applies from 17 January 2025, with technical standards applying on the dates stated in each standard. Application position for this topic: Applies from 17 January 2025. Technical standards apply on their own stated dates.