The server is rebooted, the customer is appeased, the ticket is closed, and three weeks later the exact same incident happens again. That cycle is the signature of treating symptoms instead of causes. Root cause analysis (RCA) is the discipline of digging past the obvious failure to the underlying reason, so the corrective action you take actually prevents recurrence rather than just clearing today's smoke. This guide explains what RCA is, the main techniques, how to distinguish a root cause from a symptom, and how to turn findings into action.
What You'll Learn
You will learn what root cause analysis is and why it matters, how to tell a root cause from a symptom, three practical techniques (5 Whys, fishbone, fault tree), how to document an RCA, and how to convert root causes into corrective actions that hold.
What Root Cause Analysis Is
Root cause analysis is a structured method for identifying the fundamental reason an incident occurred, as opposed to its immediate or visible symptoms. The premise is simple: most failures have a chain of causes, and if you fix only the last link in the chain, the rest of it stays primed to fail again.
RCA usually sits in the middle of the incident lifecycle, after the immediate response has contained the problem and before you finalise the incident report and corrective actions. It is also a central input to a post-incident review, where the team reflects on what the analysis revealed.
A genuine root cause has three properties:
- It explains the incident. Remove it and the incident would not have happened.
- It is within your control to address. "Bad luck" is not a root cause you can act on; "no automated test for failover" is.
- It points to a corrective action. If a finding does not suggest something you can change, you have not gone deep enough.
Root Cause vs Symptom
The hardest part of RCA is knowing when to stop digging, and most teams stop too early, at a symptom that merely looks like a cause. A symptom is an effect; a root cause is something that, had it been different, would have prevented the chain.
| Incident | Symptom (looks like a cause) | Plausible root cause |
|---|---|---|
| Customer data emailed to wrong recipient | "Employee made a mistake" | No recipient confirmation step and auto-complete enabled on a high-risk mailbox |
| Payment batch failed overnight | "The job crashed" | No alerting on job failure, so an earlier silent error went unnoticed |
| Server ran out of disk | "Disk filled up" | Log rotation was never configured and no capacity monitoring existed |
Important
"Human error" is almost never a true root cause. When you land on it, ask why the system allowed a single human mistake to cause harm. Robust systems are designed so that one slip is caught before it becomes an incident, and the absence of that safeguard is usually the real cause.
Want the full framework with worked examples?
Technique 1: The 5 Whys
The 5 Whys is the simplest and most widely used RCA technique. You state the problem and repeatedly ask "why?" Each answer becomes the subject of the next question, until you reach a cause you can act on. "Five" is a guideline, not a rule; sometimes it is three, sometimes seven.
Worked 5 Whys: customer portal outage
Problem: The customer portal was down for four hours overnight.
Why? The primary database failed and the standby never took over.
Why didn't the standby take over? The automatic failover did not trigger.
Why didn't failover trigger? The health check timed out before marking the primary as failed.
Why did the health check time out? Its timeout was set far too low for a loaded database and had never been tested under load.
Why was it never tested under load? Failover is not part of the release-testing pipeline.
Root cause: Failover behaviour is not validated by automated testing, so a misconfigured timeout went undetected. Corrective action: Add an automated failover test under realistic load to the release pipeline, and correct the timeout.
Notice how the early answers ("the database failed") are symptoms. The useful, actionable cause only appears once you push past them. A common refinement is to allow more than one answer to a "why," which naturally turns the analysis into a tree, and that leads to the next two techniques.
Technique 2: Fishbone (Ishikawa) Diagram
The 5 Whys works well for a single causal chain but struggles when an incident has multiple contributing factors. A fishbone diagram (also called an Ishikawa or cause-and-effect diagram) maps causes across several categories so you do not fixate on the first plausible answer.
You draw the problem as the fish's head and branch off "bones," each one a category of cause. A common set of categories:
- People: skills, staffing, communication, fatigue.
- Process: missing steps, unclear procedures, no checks.
- Technology: bugs, configuration, capacity, tooling.
- Environment: external dependencies, supplier failures, conditions.
- Materials / inputs: bad data, faulty components.
- Measurement: missing monitoring, wrong metrics, no alerting.
For each category you brainstorm contributing factors, then test which ones genuinely contributed. The strength of the fishbone is breadth: it forces the team to consider categories they would otherwise skip, which is exactly where overlooked causes hide.
Pro Tip
Combine techniques. Use a fishbone diagram to surface the full set of contributing factors, then run a focused 5 Whys down the one or two branches that look most significant. Breadth first, then depth.
Technique 3: Fault Tree Analysis
Fault tree analysis (FTA) is the most rigorous of the three. It starts from the undesired event at the top and works downward, using logic gates to show how combinations of lower-level failures produce it. An AND gate means all the inputs must occur together; an OR gate means any one of them is enough.
FTA shines for incidents where several things had to fail at once, exactly the situation where multiple controls were supposed to provide defence in depth. It makes the logic explicit: if your portal outage required both the primary to fail (likely) AND the failover to not trigger (the real surprise), the tree shows that your resilience depended entirely on the failover, and that single dependency is where to invest.
FTA is more effort than the 5 Whys, so reserve it for high-severity incidents, safety-critical systems, or cases where you need to understand how layered controls interacted. For most everyday incidents, 5 Whys or a fishbone is proportionate.
Documenting the RCA
An analysis that lives only in someone's head is worthless six months later. Document each RCA with enough structure that a future reader can follow the reasoning:
- Problem statement: the incident, factually, with its impact.
- Method used: 5 Whys, fishbone, fault tree, or a combination.
- Causal chain or diagram: the actual analysis, not just the conclusion.
- Root cause(s): stated clearly, distinguished from contributing factors.
- Evidence: logs, timelines, data that support the conclusion.
- Corrective and preventive actions: what changes, who owns it, by when.
Store this against the incident in your register so the root cause and its actions are visible and trackable. This is the field that turns your incident register from a log of events into a record of learning.
Turning Root Causes Into Corrective Actions
RCA only pays off if it changes something. Each root cause should produce one or more corrective actions, and good ones share a few traits:
- They address the cause, not the symptom. "Restart the service" is a symptom fix; "add alerting and capacity monitoring" addresses the cause.
- They are specific and owned. A named owner and a due date, tracked to completion, beats "the team will look into it."
- They prefer stronger controls. Where you can, replace a procedural reminder with an engineered safeguard. A control that cannot be skipped beats one that relies on people remembering. The hierarchy of risk controls is a useful lens here.
- They feed risk. If the incident revealed a control gap, update the corresponding risk in your register so the analysis improves your forward-looking view, not just this one case.
Distinguish corrective actions (fix what happened) from preventive actions (stop similar things happening elsewhere). The portal outage's corrective action fixes the timeout; the preventive action, adding failover testing to the pipeline, protects every other system that relies on the same pattern.
Common Mistakes to Avoid
1. Stopping at the first plausible cause
The first answer is usually a symptom. Keep asking why until you reach something actionable.
2. Blaming people
"Human error" hides the real cause: a system that let one mistake become an incident. Ask why the safeguard was missing.
3. Confusing contributing factors with the root cause
Many factors contribute; the root cause is the one whose removal breaks the chain. Document both, but be clear which is which.
4. No corrective action
An RCA that ends with a finding but no owned, dated action is an essay, not a fix.
5. Over-engineering the method
Not every incident needs a fault tree. Match the technique to the severity; a 5 Whys is enough for most.
Summary
- Root cause analysis finds the underlying reason for an incident, not just the visible symptom, so fixes prevent recurrence.
- A true root cause explains the incident, is within your control, and points to a corrective action.
- The 5 Whys suits single causal chains; fishbone diagrams map multiple contributing factors; fault trees handle combinations of failures.
- "Human error" is rarely the real cause. Ask why the system allowed one mistake to cause harm.
- Document the analysis and convert each root cause into specific, owned corrective and preventive actions that feed back into your risk register.
Frequently Asked Questions
Do I always have to ask exactly five whys?
No. Five is a guideline. You stop when you reach a cause that is within your control and points to a clear corrective action. Sometimes that is three whys, sometimes seven. Stopping at a symptom is the real error, not the count.
When should I use a fishbone instead of 5 Whys?
Use a fishbone when an incident likely has several contributing factors across different categories, such as people, process, technology and environment, rather than a single chain. Many teams use the fishbone for breadth, then run a 5 Whys down the most significant branches.
Can an incident have more than one root cause?
Yes. Complex incidents often have multiple root causes, especially when several controls fail together. Document each one and assign corrective actions to all of them, because fixing only one may leave the incident able to recur through another path.
Why is "human error" not a good root cause?
Because people will always make occasional mistakes. The real question is why the system let a single mistake cause harm. A missing confirmation step, absent alerting, or no second check is usually the true cause, and unlike "be more careful," those are fixable.
What is the difference between corrective and preventive actions?
Corrective actions fix the specific issue that caused this incident. Preventive actions stop similar incidents happening elsewhere, for example by applying the same fix across every comparable system. Strong RCA produces both.
How does root cause analysis connect to the risk register?
A root cause usually reveals a failed or missing control. Updating the related risk in your register, and the controls attached to it, means each incident sharpens your forward-looking risk view. See how incidents connect to your risk register.
Save this guide for later
Download the PDF version to read offline or share with your team.
