The five whys is a useful way to move from a symptom to a process or system fact, but one chain rarely covers a security incident. Run it for each contributing factor, stop at something you can change, and do not stop at a person. Treat the number five as a guide, not a rule.
What it is
The five whys is a root cause technique: you ask why something happened, then why that happened, and continue until you reach a cause you can act on. Atlassian's postmortem handbook tells the postmortem owner to use the Five Whys technique to traverse the causal chain until they find a good, true root cause. Google's SRE book takes a broader line: teams use a variety of root cause techniques and choose the one best suited to their service, and the goal is that all contributing causes are understood.
A worked example
An invented example, to show the shape:
| Why | Answer |
|---|---|
| Why did a malicious package version run in our build? | The build installed the newest version on every run. |
| Why did it install the newest version? | The dependency range allowed it and no lockfile was enforced. |
| Why was the lockfile not enforced? | The pipeline template did not require it. |
| Why did the template not require it? | No owner had been assigned to the shared template. |
| Why no owner? | Platform ownership was never defined after a reorganisation. |
The last answer is a process fact you can change. Notice that no answer says "the developer made a mistake".
Where one chain falls short
This is our view, based on how security incidents usually unfold. A single linear chain tends to hide that:
- Several things had to go wrong at once. One chain follows one path. Google's guidance speaks of contributing causes in the plural.
- Detection is a separate question. Why it happened and why you did not see it sooner are two chains.
- Chains can end at a person. Asking "why did she do that?" invites blame. Ask "what made that the easy path?" See human error is not a root cause.
- Different people will give different answers. Capture them all, and let the group decide which are supported by evidence.
Steps to use it well
- List the contributing factors first: the trigger, the missing control, the missed detection and the slow response.
- Run a short why chain on each one.
- Stop when you reach something you can change with an action, not when you reach a count.
- Write each answer as a fact with a source, not as an opinion.
- Check every chain end. If it names a person, ask one more why about the system around them.
- Convert each end point to an action of type prevent, detect or mitigate. See prevent, detect, mitigate.
Alternatives
Some teams use a diagram with branches for each contributing factor, or simply a table of "factor, evidence, action". The technique matters less than the habit of reaching system level causes and keeping the discussion blameless. Google's book leaves the method open for exactly that reason.
How Safeguard fits
In supply chain incidents, answers to the early whys often involve version ranges and unpinned dependencies. Safeguard's policies and gates can enforce dependency rules, and its SBOM scanning shows what was installed. Try a free scan at https://gold.safeguard.sh/scan.
Quick check
Do I need exactly five whys?
No. Stop when you reach a cause you can change, which may be three whys or seven.
Can one incident have several root causes?
Yes. Google's guidance refers to contributing root causes in the plural, so record each one.
Sources
Last reviewed: 19 October 2026.
