Swiss Cheese Model
Accidents happen when holes in several imperfect defences line up at the same moment.
“In an ideal world each defensive layer would be intact. In reality, however, they are more like slices of Swiss cheese, having many holes”
To an executive
Serious incidents rarely have one cause. They happen when several imperfect safeguards fail together, so blaming one person misses the weaknesses that let the error through.
To an engineer
Add independent layers of defence and hunt for latent weaknesses in design, tooling and process. After an incident, ask why the defences let the mistake pass.
The idea
James Reason, a psychologist who studied human error, pictured an organisation's defences as slices of Swiss cheese stacked in a row. Every slice has holes, and the holes move and change size. Usually a hazard is stopped by one slice or another. An accident happens when, for a moment, the holes in every slice line up.
Reason distinguished two kinds of hole. Active failures are the unsafe acts of people at the sharp end: the mistyped command, the skipped step. Latent conditions are weaknesses built into the system by earlier decisions about design, staffing, tooling and procedure. They can lie dormant for years until an active failure exposes them.
He contrasted a person approach, which blames individuals for forgetfulness or carelessness, with a system approach, which accepts that people will make errors and asks why the defences let them through.
Why it works
It moves attention from the last person to the whole system. The engineer who ran the command is the most visible hole, but rarely the only one. The model makes every other layer part of the investigation.
Latent conditions can be fixed before they cause harm. Active failures are hard to predict, but latent ones, such as missing safeguards or unclear runbooks, can be found and removed in advance.
Blame hides information. If people expect punishment, they stop reporting near misses, and the organisation loses the signals it needs to find holes early.
Where it applies
- Post-incident reviews, to find every layer that failed rather than one root cause.
- Change and release processes, to see which checks are doing real work.
- Data and access management, where mistakes and safeguards stack in the same way.
- Risk assessments, to ask which holes are already open and waiting.
How to apply
- List every defence that could have stopped the incident: design, testing, review, access control, monitoring, backup, process.
- For each, ask why it did not. Describe the hole without naming a culprit.
- Separate active failures from latent conditions, and focus most actions on the latent ones.
- Shrink holes rather than adding slices. A well-tested backup is worth more than three new approval steps.
- Track near misses, which show holes lining up partially, before the day they line up completely.
Example scenario
A data-deletion incident looked at first like one engineer's mistake: they ran a clean-up script against production instead of staging. The first draft of the review recommended "more care when running scripts".
Walking through the layers told a different story. The script had no dry-run mode, the code review had been skipped under deadline pressure, production credentials were stored on the engineer's laptop, and the backup had never been restored. Fixing any one of these would have prevented the incident. The team fixed all four, and the engineer helped write the new runbook.
Questions to ask
- Which defences should have caught this, and why didn't each of them?
- What latent conditions are sitting in our system, waiting for a trigger?
- Are our actions fixing the trigger, or the holes that let it through?
When not to use it
- Single, simple failures with an obvious technical cause and no protective layers to examine, such as a typo in a configuration file caught by tests.
- As a full causal model of complex systems. The slices imply a linear path; for tightly coupled systems, pair it with Normal Accidents and look at interactions too.
How it misleads you
Adding more slices instead of shrinking holes. Layers that are each ineffective still add cost and complacency, and people start relying on the next slice to catch them. The model can also be used to spread responsibility so thinly that nothing changes; every review should end with named owners for specific holes.
In the wild
Further reading
Last reviewed · Suggest an improvement