Home / Knowledge hub / Root cause analysis
Knowledge hub
Root cause analysis
Working out why an incident happened, so the real cause is fixed.
What it means
Root cause analysis is the habit of asking why until you reach a cause you can actually change. The first answer to an incident is usually the trigger: a password was guessed, a package was outdated, an engineer deployed a bad change.
The root cause sits behind it. Why was a guessable password allowed? Why did nothing flag the outdated package? Why could one change reach production without review? Fixing the trigger stops one repeat. Fixing the cause stops the family of them.
Why it matters
Without it, teams patch the symptom and meet the same incident in a new form. A leaked key is rotated, but the habit of keeping keys in code stays. Three months later another one leaks, and everyone is surprised. The cost of skipping the analysis is paid later, with interest.
It also protects people. When analysis stops at "an engineer made a mistake", the engineer takes the blame and the system stays the same. Asking why the system allowed the mistake leads to guardrails that help everyone, which is the spirit of a blameless post-incident review.
How it shows up
Methods are simple. The five whys: ask why repeatedly until you reach a process or design gap. A timeline of events with the decisions made at each point. A diagram of the contributing factors. Most real incidents have several causes, not one, so write down all of them.
Mistakes to avoid are stopping at a person, stopping at the first technical answer, and listing causes you cannot change. Good output is a short list of actions with owners and dates, such as adding a secret scan or a review rule. Link it to the root cause noted on each finding.
Questions people ask
Root cause analysis, answered
Is there always a single root cause?
No. Most incidents come from several things lining up: a weakness, a missing check, a delayed alert. Naming one cause is tidy and often wrong.
Look for the factors that, if changed, would have prevented or shortened the incident.
What are the five whys?
A simple technique: state the problem, ask why it happened, then ask why about each answer, usually about five times, until you reach something in your process or design that can be changed.
It is a prompt for thinking, not a rule. Stop when you reach a fix that matters.
Does root cause analysis mean finding someone to blame?
It should not. Blame makes people hide information, and you lose the facts you need. Focus on conditions and decisions, not on individuals.
Good teams ask what made the mistake easy to make.
When should we do it?
After any incident of real consequence, and after near misses that show a gap. Do it while memories and logs are fresh, but not in the middle of the fire.
Smaller incidents can have a short version.
How do we know the fix addressed the cause?
Check that the action changes the system, not just a document. Then test it. If the cause was a missing authorisation check, repeat the original exploit against the fixed code and confirm it fails.
That is a fix verification step.
Sources
Where this comes from
Related
Terms that sit next to this one
Root cause
The underlying mistake behind a flaw, which fixing prevents a whole class from returning.
Post-incident review
A blameless look back at an incident to improve the plan and the system.
Remediation
The actual work of fixing a finding: the change, the review, the release.
Fix verification
Proving a fix works by repeating the original exploit against the new code.
Incident response
The agreed plan for the hours after something has gone wrong.
Is the real cause fixed?
A fix is proven by re-running the exact exploit against the new code, not by a fresh scan. That shows whether the cause was closed or only the symptom. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.