Root Cause Analysis for Incidents: 7 Methods Compared
By Dimitris Mitsios · Dimitris works at Tekmon, which pays for sponsored placements on this site. Disclosure · AI-assisted (how pages are made)
A practical guide to incident investigation and root cause analysis — 7 techniques compared, a worked manufacturing example, the CAPA loop, how to write testable cause statements and what to ask a software vendor.

A serious incident investigation that stops at "operator error" is a wasted incident. Where a regulator or a certification body reviews an investigation, the useful evidence is a defensible root cause analysis (RCA) that traces the failure back to systemic causes, and a CAPA loop that shows what was done to stop a repeat. OSHA warns that it is "far too easy, and often misleading" to conclude that carelessness or a failure to follow procedure alone caused an incident, and HSE's investigation guidance, HSG245, says investigations that conclude operator error was the sole cause are rarely acceptable.
This guide compares 7 RCA techniques used in QHSE programs, with worked examples and a decision tree for when to use which.
Audience: QHSE managers, HSE leads, plant supervisors and continuous-improvement teams.
Why RCA matters more in 2026
Three forces shape incident investigation:
- ISO 45001 certification audits assess how you handle incidents under clause 10.2, headed "Incident, nonconformity and corrective action" in the contents of ISO's own handbook. ISO 45001:2018 is voluntary and its requirement text is sold rather than published, so check with your certification body what it expects to see. The 2018 edition is still the published one: a revision reached the Draft International Standard stage in 2026, with publication expected in 2027, according to DNV's note of 3 July 2026.
- Regulators set investigation duties for some operations. OSHA's process safety management standard, 29 CFR 1910.119(m), requires an investigation of each incident that resulted in, or could reasonably have resulted in, a catastrophic release of a highly hazardous chemical, started no later than 48 hours after the incident, with a report that sets out the factors that contributed to it.
- QHSE platforms (Incident Management software): some products document 5-Why, Fishbone or CAPA templates inside the incident workflow. Confirm each against the vendor's own pages, because the documented scope differs between products.
The 7 RCA techniques compared
| Technique | Best for | Complexity | Rough time (our estimate) |
|---|---|---|---|
| 5-Why | Simple incidents, near-misses | Low | 30–60 min |
| Fishbone (Ishikawa) | Multi-factor incidents, brainstorming | Low–Medium | 1–2 hrs |
| TapRooT | Serious incidents with regulatory exposure | High | 1–3 days |
| Bowtie | High-hazard risks (oil & gas, chemicals) | High | 1–2 days |
| FTA (Fault Tree Analysis) | Quantitative reliability/safety | High | 2–5 days |
| ICAM (Incident Cause Analysis Method) | Multi-causal incidents, organisational factors | Medium–High | 1–3 days |
| Apollo RCA | Cause-and-effect chains, evidence-based | Medium | 1–2 days |
1. 5-Why
The simplest technique (see the glossary entry on 5 Whys): ask "why?" five times to drill from symptom to systemic cause.
Worked example (warehouse near-miss):
- Why did the operator slip? → Spilled oil on the floor.
- Why was there oil? → Forklift hydraulic leak.
- Why the leak? → Hose past service life.
- Why still in service? → No preventive maintenance schedule for hoses.
- Why no schedule? → Maintenance plan didn't list consumables.
→ Root cause: maintenance plan gap. → CAPA: add consumables to maintenance plan, audit quarterly.
2. Fishbone (Ishikawa) diagram
Group causes into 6 M's: Man, Machine, Method, Material, Measurement, Mother Nature (the glossary entry on the fishbone diagram describes the layout). Best when multiple contributing factors exist. Pairs well with a CAPA software workflow.
Worked example (illustrative, recurring weld defects):
- Man: welder turnover, inconsistent training across shifts.
- Machine: ageing welding sets with no calibration programme.
- Method: welding procedure specification not consistently followed, no in-process inspection.
- Material: inconsistent filler-metal supply.
- Measurement: no quality indicator tracked per welder, so no feedback loop.
- Mother Nature: draughty work area.
The diagram exposes six families of contributing factors, not one root cause. It is a brainstorm, not a conclusion: check each branch against data, then prioritise which to address first.
3. TapRooT®
A proprietary structured method with a "Root Cause Tree" and human-performance categories. Time-intensive; confirm whether your regulator or client specifies a method before choosing one.
4. Bowtie analysis
Visualises (the bow-tie glossary entry has the vocabulary) a top event in the middle, threats on the left and consequences on the right, with preventive and mitigative barriers between. Widely used in major-hazard industries; see Process Safety Management software and bowtie and barrier management software.
5. Fault Tree Analysis (FTA)
Top-down deductive method (see fault tree analysis) using Boolean logic to calculate probability of failure. Used in nuclear, aerospace and high-reliability manufacturing.
6. ICAM (Incident Cause Analysis Method)
Built on James Reason's model of organisational accidents and developed from work in aviation and mining, as in De Landre, Gibb and Walters' application to an aviation accident. It sorts findings into four elements: absent or failed defences, individual or team actions, task and environmental conditions, organisational factors. Suited to incidents with several causes, because it looks beyond the individual's actions.
7. Apollo RCA
Evidence-based cause-and-effect charts. Every cause must have evidence; every "why" branches into actions and conditions.
How to pick the right technique
┌─ Simple, single cause? ────────→ 5-Why
│
├─ Multi-factor brainstorm? ─────→ Fishbone
│
Incident ──┬────┼─ Serious, regulator scrutiny? ─→ TapRooT or Apollo
│ │
│ ├─ Major hazard, barriers? ──────→ Bowtie
│ │
│ ├─ Quantitative reliability? ────→ FTA
│ │
│ └─ Multi-causal, ops + culture? ─→ ICAM
For getting near-misses reported in the first place, see the near-miss reporting guide. One workable standard: 5-Why for near-misses, Fishbone for recordables, ICAM or TapRooT for LTIs and serious injuries. HSE's HSG245 adds a caution: set the depth of an investigation by the potential consequences and the likelihood of recurrence, not only by the harm suffered this time, so a high-potential near miss may deserve one of the deeper methods.
An example matrix built on that working rule (our suggestion, not a requirement):
| Incident type | Starting method |
|---|---|
| Near miss, low potential | 5-Why |
| First-aid case, single cause | 5-Why |
| Recordable, several factors | Fishbone, then 5-Why on each branch |
| Recurring quality problem | Fishbone |
| Lost-time injury | ICAM or TapRooT (Fishbone to brainstorm causes first) |
| Process safety event | A structured method such as ICAM, TapRooT or Tripod Beta, with the 29 CFR 1910.119(m) report where that standard applies |
| Fatality or environmental release | A structured method such as ICAM, TapRooT or Tripod Beta |
The CAPA loop (Corrective & Preventive Actions)
RCA without CAPA closure is theatre. Whether on paper or in software, the loop needs these steps:
- Identify corrective actions (immediate fix) and preventive actions (systemic fix).
- Assign owners with SMART deadlines.
- Verify effectiveness after 30/60/90 days.
- Close with evidence — and ensure the lesson is shared across sites.
See the ISO 45001 internal audit checklist for clause-by-clause CAPA evidence requirements.
Worked example — manufacturing LTI
Incident: Operator's hand caught between conveyor and guard during cleaning. 7-day LTI.
Technique: ICAM (multi-causal, regulatory exposure).
Findings:
- Absent/failed defences: interlock bypassed for productivity, LOTO procedure not enforced for cleaning task.
- Individual actions: operator skipped step 4 of cleaning SOP under shift-end time pressure.
- Task/environmental: poor lighting, awkward access angle.
- Organisational: cleaning task missing from LOTO procedure list; shift-end production pressure rewarded over safety.
CAPA:
- Add cleaning to LOTO procedure register (30 days). See LOTO software and the LOTO program guide.
- Engineering review of guard interlock bypass capability (60 days).
- Revise shift-end KPIs to weigh safety equally with throughput (90 days).
- Cross-site lesson-learned bulletin and toolbox talk (14 days). See Toolbox Talks software.
Writing cause statements that can be tested
A finding such as "poor communication" cannot be checked, so it cannot be closed. Write each cause as a statement that links a condition to an effect and names the evidence that supports it. The rewrites below use the conveyor example above.
| Weak finding | Testable cause statement | Evidence to attach |
|---|---|---|
| Operator rushed | Cleaning was scheduled in the last 20 minutes of the shift, so the full sequence did not fit in the time allowed. | Shift plan, cleaning SOP time allowance, interview notes |
| Guard was bypassed | The interlock could be defeated with a tool kept in the production office, and no check looked for it. | Interlock design record, tool location, inspection checklist |
| LOTO not followed | The cleaning task was missing from the lockout procedure register, so no isolation point existed for it. | Procedure register, task list, training records |
Two checks help. Ask whether removing the cause would have prevented or reduced the event; if not, it is a contributing detail rather than a cause. Then ask whether the corrective action would still be needed if you had never met the people involved; if so, it addresses the system.
What to ask a vendor about RCA features
Use one of your own closed investigations as the demonstration case, and ask each vendor the same questions.
- Which methods does the product document, and can one investigation hold more than one?
- Can each cause be linked to evidence and to the corrective action that addresses it?
- Can an action stay open until a separate effectiveness check is recorded?
- Can trend reports group findings by cause category across sites, and who can see them?
The capability map shows which capability families the product records document, the root cause analysis software page covers method and evidence review, and the glossary explains root cause analysis and the hierarchy of controls. For the wider process, see incident investigation best practices.
Common RCA pitfalls
- Stopping at human error. "Operator didn't follow the procedure" is a symptom, not a cause.
- Single-technique dogma. Use the right tool for the incident; don't 5-Why a major hazard.
- No evidence. Every causal claim needs witness statements, photos, machine logs or training records.
- CAPA without verification. 30-day actions that nobody checks at day 60 don't prevent recurrence.
- Investigation team bias. Include someone outside the affected department.
- One weak action. "Add it to the toolbox talk" rarely changes behaviour on its own; pair it with an engineering or procedural control.
- Investigating only what is cheap to fix. The analysis should expose systemic causes even when the fix is hard.
- Five whys in one straight line. When several causes existed, a single chain hides them; branch the analysis or switch to Fishbone.
How software automates the workflow
Features that some products document, each to be verified against the vendor's pages:
- Mobile incident capture with photo, GPS, witness, machine ID.
- Built-in 5-Why and Fishbone templates linked to the incident.
- CAPA workflow with owners, deadlines, escalations and verification.
- Trend dashboards that surface repeat root causes across sites.
- Lessons-learned distribution to other sites and contractors.
Ask each vendor you shortlist to demonstrate these features on one of your own past incidents.
Correction, 23 September 2026: an earlier version of this section named four "leading platforms", with a commercial partner of this site first. We do not rank platforms, and our profile of that product does not document built-in 5-Why and Fishbone templates, so the names have been removed.
For manufacturing-specific RCA depth see the EHS Software for Manufacturing 2026 guide.
FAQ
Which RCA technique do auditors prefer?
No single technique is mandated. HSE's HSG245 says it does not endorse any one method and leaves the choice to you. What an auditor can check is whether you used a method consistently and whether CAPA closed the loop with evidence.
Can I combine techniques?
Yes — many investigations start with 5-Why for scoping, then Fishbone for breadth, then ICAM for systemic analysis. The combination is fine if documented.
How long should an investigation take?
These are our suggested working timelines, not legal requirements: near-miss 1–3 days; recordable injury 5–10 days; LTI/serious injury 14–30 days; regulator-notifiable incident as long as needed, with interim reports. Some rules set a start rather than a duration: OSHA's process safety standard requires an investigation to begin as promptly as possible and no later than 48 hours after the incident. HSG245 advises investigating as soon as possible, while memory is best and motivation greatest.
Who should lead the investigation?
Our preference is a trained investigator from outside the affected department, with the supervisor as a participant, not the lead, and we would avoid having the line manager investigate their own team's incident. HSE's HSG245 scales this with the level of investigation: the relevant supervisor or line manager for minimal and low-level investigations, and for high-level investigations a team including health and safety advisers and employee representatives, supervised by senior management or directors.
Do I need separate software for RCA?
No. RCA should live inside your Incident Management and CAPA Management workflow. Standalone RCA tools create reconciliation work.
What's the difference between TapRooT and Apollo?
TapRooT uses a fixed root-cause tree taxonomy; Apollo builds an evidence-based cause-and-effect chart per incident. Which suits you depends on whether your investigators are trained in the method and how often your incidents fall outside a fixed taxonomy; trial both on a past incident.
Should contractors do their own RCA?
Yes for their own incidents, but you should review their RCA and CAPA as the principal contractor. Some products document contractor portals for this; check what a contractor can see and submit.
How does RCA feed continuous improvement?
Trended root causes across 6–12 months reveal systemic gaps — culture, design, training, procurement — that single incidents don't surface. This is some of the most valuable QHSE data you produce.
Next steps
- Shortlist platforms: Incident Management Software and CAPA Management Software.
- Map clause-by-clause: ISO 45001 Internal Audit Checklist.
- Industry deep-dive: EHS Software for Manufacturing 2026.
Editorial guide from The QHSE Standard, based on the linked sources. This article does not claim an independent expert review or a comparative test of these methods.
Sources
- US OSHA: Incident investigation
- HSE: Investigating accidents and incidents (HSG245)
- De Landre, Gibb and Walters: Using incident investigation tools proactively (ICAM applied to an aviation accident)
- eCFR: 29 CFR 1910.119, process safety management of highly hazardous chemicals
- DNV: Draft Version of ISO 45001:2027 Released (3 July 2026)
- ISO: ISO 45001:2018, a practical guide for small organizations, preview with contents and the ISO 45001:2018 standard page
Updated 4 October 2026: the OSHA and HSG245 quotations, the 29 CFR 1910.119(m) summary and the ISO 45001 clause heading were re-checked against the sources; the ICAM description was corrected to match its published source, the status of the ISO 45001 revision was added, statements about what software "ships" were hedged, and a section on testable cause statements and vendor questions was added.
Corrected 23 September 2026: claims about named vendors that no source we could check supported were removed or reworded to match each product's researched profile.
Corrected 23 September 2026: statistics without a primary source were sourced, labelled as examples or removed, and the regulations cited now link to their official texts.
Updated 24 September 2026: merged the sourced sections of 5-Whys vs Fishbone vs TapRoot: Which RCA Method?
Founder of The QHSE Standard; product marketing at Tekmon
Dimitris Mitsios is the founder of The QHSE Standard and works in product marketing at Tekmon. His professional focus includes software positioning, digital workflows and user adoption.
Dimitris works at Tekmon, which pays for sponsored placements on this site.
Researched and drafted with AI assistance and published under the author's editorial responsibility (how pages are made). Found an error? Send a correction with a source.
Related software
Browse all platforms →Ordered by how closely our sources document this process, not by quality. Sponsored placements are labelled. How lists are ordered
- QHSE Management
EHS Insight
QHSE Management
Read the profile - Audits & Inspections
EASE
Audits & Inspections
Read the profile - Quality Management
Effivity
Quality Management
Read the profile

