What this is
What is root cause analysis?
What is root cause analysis?
Root cause analysis is a structured method for finding why something happened, far enough back that acting on the finding prevents recurrence rather than treating the symptom. It works from evidence through a causal chain to the organisational conditions that made the event possible, and it produces corrective actions that are verified as effective.
What is the difference between a correction and a corrective action?
A correction fixes the immediate problem: the product is scrapped, the machine is repaired, the spill is cleaned. A corrective action addresses the cause so the problem does not return. Most systems record both in the same field, which is why so many corrective actions are corrections wearing the wrong label.
Scope
When is a root cause analysis required?
Root cause analysis is expensive in time and attention, which is why it should be reserved for events where the answer will change something.
Use this template when
- A serious incident or high-potential near miss, regardless of the actual outcome
- A nonconformance that is significant, recurring, or reached a customer
- A repeat failure on an asset or in a process, where the previous fix did not hold
- An audit finding that recurs, which indicates the previous closure did not address the cause
- A trend in the data, where individually minor events share a pattern
Do not use it for
- Single minor events with an obvious and contained cause, where a correction is proportionate
- The incident report itself, which captures facts and should not lead the analysis toward a conclusion
- Performance management, which is a separate process and must not share a record with analysis
- Design reviews and FMEA, which look forward at what could happen rather than back at what did
- Routine variance investigation, which has its own lighter process
Compliance mapping
Which ICAM requirements does this satisfy?
Root cause analysis is required by implication rather than by name in most standards. What they require is that causes are determined and that action addressing them is verified effective.
| Clause | Requirement | Where it lands |
|---|---|---|
| ISO 45001 cl.10.2 | Investigate incidents, determine causes, evaluate need for action to eliminate causes, review effectiveness | Header |
| ISO 9001 cl.10.2 | Evaluate need for action to eliminate causes so nonconformity does not recur, review effectiveness | Causal analysis |
| ISO 45001 cl.10.2(d) | Assess existing OH&S risks and determine whether new hazards have arisen | Findings |
| IATF 16949 cl.10.2.3 | Documented problem solving process with defined methodology and containment | Investigation level |
| FDA 21 CFR 820.100 | CAPA procedures including investigating the cause of nonconformities and verifying effectiveness | Closure |
| OSHA 1910.119(m) | Incident investigation within 48 hours for PSM events, with findings resolved and documented | Closure |
| ISO 45001 cl.10.2(f) | Make changes to the management system where necessary | Findings |
| ISO 9001 cl.10.2.2 | Retain documented information on the nature of nonconformities and results of corrective action | Closure |
What it does not cover
- The incident report, which captures facts and should be kept separate so the analysis is not led by an early conclusion.
- Disciplinary process, which must not run through the same record, because an analysis conducted under threat produces accounts shaped for that threat.
- The corrective action tracker, which manages the actions arising rather than the reasoning that produced them.
- FMEA, which is prospective analysis of what could fail rather than retrospective analysis of what did.
- Risk assessment, which should be updated as an output of the analysis rather than replaced by it.
How to complete it
How to complete a root cause analysis, step by step
The structure of a root cause analysis matters less than the discipline applied to it. Any of the common methods will work; all of them fail the same way.
A problem stated as "operator injured" produces a different analysis from "guard was open during a jam clearance that occurs forty times per shift". Specify what, where, when, how much and how often. Most weak analyses trace to a problem statement that was too vague to analyse, and the vagueness usually conceals an assumption about the cause.
The chain answers how the event came about, step by step, each link necessary. Contributing factors made it more likely, harder to detect or worse in outcome. Both matter and they demand different actions: breaking a chain prevents recurrence, addressing a contributing factor reduces likelihood or severity.
For every candidate cause, ask whether removing it before the event would have prevented the event. If the answer is no, it is a contributing factor or a symptom. This single test eliminates most of what gets recorded as root causes, including nearly all findings of human error.
Both ISO 45001 and ISO 9001 require review of the effectiveness of corrective action. That means evidence, after enough time and enough occurrences, that the problem has not returned. Closing when the action is implemented records that something was done; it does not record that it worked, and repeat findings are the measure of the difference.
What auditors find
Most common root cause analysis findings
Audit findings on root cause analysis are strikingly consistent across industries and standards.
| Finding | Clause | What fixes it |
|---|---|---|
| Analysis concludes at human error with retraining as the corrective action. | ISO 45001 cl.10.2 | Continue past the person to why the method failed for a competent person doing the job normally. |
| Corrective action closed on implementation with no effectiveness review. | ISO 9001 cl.10.2 | Set a verification date and method when the action is raised, and close only after it. |
| Correction recorded as corrective action; the immediate fix is the whole response. | ISO 9001 cl.10.2 | Separate the fields; a repaired machine and a prevented recurrence are different things. |
| Repeat events with prior corrective actions closed, indicating cause was never addressed. | ISO 45001 cl.10.2 | Trend by cause code; repeat by cause is the honest measure of analysis quality. |
| Analysis performed by one person, usually the area supervisor. | ISO 45001 cl.5.4 | Include the people who do the work; they know the actual method and the usual workarounds. |
| Problem statement too vague to support analysis. | IATF 16949 cl.10.2.3 | Quantify what, where, when, how much, how often before starting. |
| Risk assessment not updated after the analysis identified a new hazard. | ISO 45001 cl.10.2(d) | Make assessment review a required output where a new hazard or control gap is found. |
| Actions raised without owner, date or verification method. | ISO 9001 cl.10.2 | Require all three at the point the action is created, not at review. |
| Containment not applied or not bounded while analysis proceeds. | IATF 16949 cl.10.2.3 | Contain first to the last known good point, then analyse. |
| Investigation conducted alongside a disciplinary process. | ISO 45001 cl.10.2 | Separate the processes and the records; concurrent discipline corrupts the account. |
Case in point
Case in point: the fifth why nobody asked
A packing operator was injured clearing a jam. The analysis ran: why was the operator injured, because they reached into the machine; why did they reach in, because the machine jammed; why did they reach in without isolating, because isolation takes four minutes; why does it take four minutes, because the isolation point is on the far side of the guard cage. The analysis stopped there and recorded the cause as failure to follow the isolation procedure, with retraining as the action.
The unasked fifth why was why the isolation point is on the far side of the cage. It had been moved during a layout change two years earlier to make room for a new conveyor, a change made without assessing its effect on the isolation procedure. Every operator on that line cleared jams without isolating, because the alternative was four minutes on a line paced at forty jams a shift.
The retraining was delivered to eleven people who already knew the procedure and had rational reasons for not following it. Nine months later a second operator was injured on the same machine, doing the same thing.
The template
The template, field by field
The form exactly as it installs. Every field, option, score and conditional rule is editable, and the links to other templates come with it.
9 sections
- Reference
- FDN-013
- Archetype
- Record
- Record ID
- RCA-2026-000
- Scoring
- Not scored, causes counted
- Direction
- n/a
- Singleton
- Yes
- Basis
- ICAM, TapRooT, ISO 9001 cl.10.2
- Links
- Linked from every workspace
- Tags
- Investigation
- Sections
- 9
- Fields
- 51
- Follow up fields
- 0
- Repeating sections
- 2
- Links out
- 6
Header
6 fieldsRCA ID*
Format RCA-2026-00000.
The record's own ID. Other templates point at this value.
Case ID*
Copied from the event that triggered this investigation.
Thread key. Carries the parent event through the whole chain
Parent Type*
Incident, finding, nonconformance, failure or complaint.
Parent ID*
Immediate predecessor record
Investigation Start Date*
Target Completion Date*
Investigation level
5 fieldsLevel Guidance
Explains that investigation depth is set by potential, not actual outcome. A first aid with fatality potential is a level 4.
Maximum Potential Loss*
The worst credible outcome had circumstances been slightly different.
- Minor4 pts
- Moderate3 pts
- Serious2 pts
- Fatal or catastrophic0 pts
Investigation Level*
Set by potential loss. Level 4 requires an independent lead and executive sponsor.
- None required3 pts
- Quick debrief2 pts
- 5 Why2 pts
- Full RCA1 pt
- Cross functional RCA0 pts
Method Required*
5 Why for level 1, ICAM or TapRooT for level 3 and above.
Recurrence In Last 24 Months*
If yes, the previous action failed and that is itself a finding.
- No2 pts
- Yes, one similar event1 pt
- Yes, two or more0 pts
Team
5 fieldsInvestigation Lead*
Must be independent of the area for level 3 and above.
Lead Person ID*
Links to FDN-003 Person ID
Lead Trained In Method*
An untrained lead invalidates a level 3 or 4 investigation.
Executive Sponsor
Required for level 4.
Team Members*
Cross functional for level 3 and above. Include someone who does the work.
Evidence preservation
7 fieldsEvidence Guidance
The five P's. People, position, parts, paper and recordings. Capture before the scene changes.
Scene Secured*
Scene Photographs*
Wide shots and close ups. Take more than you think you need.
Parts Retained
Records Collected
Which records were gathered as evidence.
Recordings Secured
CCTV, telematics and system logs overwrite quickly.
Chain of Custody Note
Who holds the physical evidence and where.
Timeline
Repeats6 fieldsTimeline Guidance
Build and validate the sequence before attempting any causal analysis.
Event Time*
One row per event or condition.
Event or Condition*
Events are things that happened. Conditions are things that were true.
Description*
Evidence Source*
How you know this. Witness, record, physical evidence or inference.
Validated*
Tick only where evidence supports this, not where it is assumed.
Causal analysis
Repeats6 fieldsCause Level*
Failed defence, individual action, task condition or organisational factor.
Cause Code*
Selected from the governed taxonomy so causes can be counted across investigations.
Cause Code ID*
Links to FDN-010 Cause Code
Related Control ID
Fill where a critical control failed.
Links to FDN-011 Control ID
Cause Explanation*
Why this cause was present, in your own words.
Evidence For This Cause*
What supports this. A cause without evidence is an opinion.
Human factors
4 fieldsAction Type
Skill based slip or lapse, rule based mistake, knowledge based mistake or violation.
Violation Type
Routine, situational or exceptional. Only complete where a violation occurred.
Substitution Test Result
Would another competent person in the same situation likely have done the same.
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Just Culture ID
Link to the Just Culture record where a person's actions are involved.
Links to FDN-017 Determination ID
Findings
5 fieldsRoot Cause Statement*
The underlying system weakness. If it names a person, go deeper.
Systemic Issue*
Tick if this could affect areas beyond where it occurred.
Extent of Condition ID
Required where a systemic issue is flagged.
Links to FDN-018 Review ID
Contributing Factors
What Went Well
Things that limited the outcome are worth protecting.
Closure
7 fieldsActions Raised*
Number of CAPA records opened from this investigation.
CAPA IDs*
Comma separated where several actions were raised.
Links to FDN-014 CAPA ID
Investigation Complete*
Completion Date*
Lead Signature*
Sponsor Signature
Required for level 4.
Report File
FDN-013 · record IDs look like RCA-2026-000 · Linked from every workspace
Open in KnowellaRun it with agents
From a document you fill in to a programme that runs itself
The analysis is a document. What fails around it is the containment boundary, the action that closed without verification, and the third occurrence nobody connected to the first two.
Watches incidents and nonconformances for repeat causes across areas and time, and surfaces the pattern before the third occurrence rather than after it.
Holds the analysis against the incident record while keeping facts and conclusions in separate documents, and reopens the risk assessment where a new hazard is found.
Manages containment scope and disposition on nonconformances, and blocks closure where effectiveness has not been verified.
Supplies asset history so a repeat failure can be seen as a pattern rather than as three separate repairs.
This template lives in General — control tower. The orchestration layer. Registries and engines every other workspace reads from.
Meet General→Glossary
Root Cause Analysis definitions and key terms
- Root cause
- A cause which, if removed before the event, would have prevented it, and which lies within the organisation's ability to control.
- Contributing factor
- A condition that made the event more likely, harder to detect, or worse in outcome, without being necessary to it.
- Correction
- Action eliminating the detected problem itself: repair, scrap, clean up. Necessary and not sufficient.
- Corrective action
- Action eliminating the cause so the problem does not recur, which is a different activity from the correction.
- Containment
- Bounding the affected population back to the last point at which the process was demonstrably in control, applied before analysis begins.
- Five whys
- An iterative questioning technique. Effective in disciplined hands, and prone to stopping at whichever answer is comfortable.
- Fishbone diagram
- Cause categorisation across method, machine, material, measurement, environment and people, useful for breadth before depth.
- Effectiveness verification
- Evidence gathered after implementation, over enough occurrences, that the corrective action worked.
FAQ
Frequently asked questions about root cause analysis
Is human error ever a root cause?+
Almost never as a stopping point. Error is a consequence of conditions: procedure design, time pressure, equipment layout, competence, fatigue, competing priorities. Recording human error as the cause identifies where the failure surfaced and leaves untouched everything that made it likely. The exception is deliberate violation, and even then the question of why the safe method was worth avoiding remains worth asking.
Which method should we use?+
Any structured one, applied with discipline. Five whys suits simple sequences, fishbone gives breadth before depth, fault tree suits complex systems with multiple failure paths, and 8D suits customer-facing problems needing containment. The method matters far less than whether the analysis is willing to reach findings that implicate decisions rather than individuals.
How do we know when we have reached the root cause?+
Apply the prevention test: would removing this, before the event, have prevented it? And the control test: is this within our ability to change? A cause passing both is actionable. Most analyses stop one or two levels above that point, at something true but not sufficient.
How long should we wait to verify effectiveness?+
Long enough for the problem to have recurred if the action failed. For a daily process that may be weeks; for a quarterly one it is quarters. Verifying too early is the most common way effectiveness review becomes a formality, because the absence of recurrence over two days proves nothing.
Should the analysis be blame-free?+
It has to be, and that requires structural separation rather than assurance. If discipline can result from the same process, people will construct accounts that protect them, and the account is the only raw material the analysis has. Run any performance process separately, on its own record, and make the separation visible to the people being asked to explain what happened.
Keep going
Related templates and programmes
Industries this is written for
Programmes this belongs to
Incident and Investigation
A single case thread from the event to a verified corrective action, with regulatory reporting handled.
Reliability and Predictive Maintenance
Intervals set by failure behaviour rather than by the calendar.
Master Data and Foundations
One place for each thing, so a change updates everywhere rather than in eight lists.
Nonconformance and Complaints
Product decisions made by quality, and complaints traced to a cause rather than answered politely.
Used together in Incident and Investigation
Corrective and Preventive Action
The single action record used everywhere
Finding
Records a single deficiency picked up during an audit, inspection or check
Effectiveness Verification
Checks whether an action actually worked, some time after it was put in place
Just Culture Determination
Separates a system problem from a genuine choice to take a risk, using a consistent set of questions
Extent of Condition Review
Asks two questions after an investigation: where else does this same condition exist, and where else could this same cause bite us
Witness Statement
Captures what one person saw, heard or did, in their own words
More in Engines
Risk Assessment
The single risk assessment used across the whole business
Corrective and Preventive Action
The single action record used everywhere
Finding
Records a single deficiency picked up during an audit, inspection or check
Effectiveness Verification
Checks whether an action actually worked, some time after it was put in place
Just Culture Determination
Separates a system problem from a genuine choice to take a risk, using a consistent set of questions
Extent of Condition Review
Asks two questions after an investigation: where else does this same condition exist, and where else could this same cause bite us
Written and reviewed by
Siddarth Singh
Founder & Chief Executive Officer, Knowella
Certified Safety Professional and industrial and systems engineer with more than a decade inside food supply chain, freight and manufacturing operations. This page was written against the current text of the standards it cites, not against secondary summaries of them.
- Certified Safety Professional (CSP), Board of Certified Safety Professionals
- MBA, University of Chicago Booth School of Business
- MS and BS, The Ohio State University, Industrial and Systems Engineering
- Six Sigma Black Belt
Sources and last review. Reviewed 16 August 2026 against:
- ISO 45001:2018 clause 10.2, incident, nonconformity and corrective action
- ISO 9001:2015 clause 10.2, nonconformity and corrective action
- IATF 16949:2016 clause 10.2.3, problem solving
- 21 CFR 820.100, corrective and preventive action, FDA
- 29 CFR 1910.119(m), incident investigation, OSHA
This page is general guidance, not legal advice. Confirm requirements with your jurisdiction’s regulator.