Updated 1 October 2026

Root cause analysis buying guide

Root cause analysis software: record how each cause was tested

A maintenance crew replaces the same pump seal three times in a year, and each work order names a different reason. Can the software show which explanations were tried, which were rejected and why, which evidence is still missing, and which action was aimed at the cause that survived? Use that question to judge the analysis step itself, not just the incident form that precedes it.

Jump to the 32 products

Editorial responsibility: Dimitris Mitsios (Founder of The QHSE Standard; product marketing at Tekmon) · Tekmon pays for sponsored placements on this site (disclosure) · How pages are made · LinkedIn

Sources reviewed 1 October 2026. This is a documentation review and proposed software demonstration, not hands-on product testing, an investigation procedure or legal advice. It is buyer context only. For statement handling and evidence custody, read the incident investigation guide; this page starts where that one stops. Existing profiles retain their separately dated pricing and connectivity evidence. Evaluation methodology.

TekmonAd

Explore its published safety, quality and maintenance workflows. Confirm modules and pricing in a scoped proposal.

Six analysis methods and what the record must hold

Method	What the guidance says	What the record must hold	Boundary to preserve
Repeated why (5 Whys)	HSE's workbook asks why repeatedly until an answer no longer means anything, and notes that some lines end quickly.	Each answer as its own node, linked to evidence, with several branches per event.	One chain implies one cause; OSHA's fact sheet says there are often several root causes.
Fishbone (cause-and-effect diagram)	The official sources reviewed here do not prescribe it; several vendor records in this guide name it.	Team-chosen categories, candidate causes under each, and a status per candidate: open, supported or rejected.	A filled branch is a candidate, not a finding; a heading supplies no evidence.
Logic or event tree	OSHA's fact sheet suggests logic and event trees for more complicated incidents, supported by timelines.	Branches linked to their evidence, with a way to mark one unresolved.	A tidy tree can hide a branch that nobody tested.
Timeline and causal-factor chart	DOE uses events and causal-factor charts for multi-faceted problems with long causal chains; HSE's workbook points to the same method.	Events in time order, kept apart from surrounding conditions, with source, time basis and uncertainty.	An earlier event is a candidate cause, not a proven one.
Barrier analysis and bow-tie	DOE describes identifying the physical, administrative and procedural controls that should have prevented the event, then asking why they failed.	Each barrier with its function, the failure observed, the evidence and a link to the risk-register control.	A diagram colour is not proof the barrier worked in the field.
Change analysis	DOE uses it when the cause is obscure: compare earlier trouble-free activity with the event.	The baseline, the differences found, and the reviewer's view of each.	A difference is not automatically a cause.

Documented root-cause scopes to compare

These are documented scopes, not a ranking or a claim that any product has passed the exercise below. Each note rests on vendor pages in that product's record and the status the record gives it. Existing profile prices, offline fields and evidence dates describe broader products and do not establish an equivalent analysis package; a conditional scope still needs confirming in your quote.

Tekmon pays for a sponsored placement (above); its place in this list follows the same rule as every entry. How lists are ordered

Same rule for every product: tagged “Root Cause & Investigation”, “Incident Management”, “Incident Reporting”, “CAPA Management”, “Quality Management”, “Safety Management”, “EHS Management”, “Occupational Health”, “Risk Assessment”, “Risk Management”, “Food Safety”, “Audits & Inspections” or “Barrier Management”, with a sourced root cause analysis capability in its record, or one the vendor stated to us, labelled as vendor-stated. 32 qualify; the first 8 are shown, then the other 24.

EASE
Documented: Formal Action Plans and root-cause analysis (conditional). Source: ease.io
Effivity
Documented: Customer complaint lifecycle. Source: effivity.com
EHS Insight
Documented: Quality management and CAPA. Source: ehsinsight.com
Emex
Documented: Incident investigations. Source: emex.com
Intelex
Documented: Nonconformance, action plans and corrective action. Source: intelex.com
SoterAI and SoterCoach
SoterAI guided investigation: the workflow page guides the investigator through evidence and witness accounts, then contributing factors, root cause, CAPA and a management review step. The record asks buyers to confirm jurisdiction, the RCA method, approvals and sign-off, and to treat AI output as a draft rather than a conclusion. Its corrective action records carry a root-cause field with owner, evidence and verifier acceptance. Source: soter.com
Tekmon
Documented: Incident root cause analysis. Source: tekmon.com
HSI Donesafe
HSI Donesafe incident module: the module page names RCA, 5 Whys and ICAM among its stages, followed by investigation review, corrective actions and an actions review. The stages are configurable. Ask who may review, what a rejection does to the analysis, and whether the author can be kept out of the review stage. Source: donesafe.com

Also meet the rule, in the same order (24)

Keep cause levels apart in the record

Level	How the guidance words it	What the software should store
Direct or immediate cause	HSE: the most obvious reason an event happened. DOE: the cause that directly produced it. There may be several.	The condition or action, its evidence, and room for more than one per case.
Contributing cause	DOE: a cause that played a part but would not by itself have produced the event.	A classification separate from root cause, with the reviewer's reason.
Underlying cause	HSE: the less obvious system or organisational reason that allowed the immediate cause to exist.	A link to the immediate cause it allowed.
Root cause	DOE: the most fundamental cause that can logically be identified and corrected, so that fixing it prevents recurrence. HSE: generally management, planning or organisational failings.	A statement written for this event, linked to evidence and at least one action, moving from proposed to approved.

Demo case: a repeated seal failure and a revised hypothesis

Create fictional case RCA-031: transfer pump PMP-031 has needed its mechanical seal replaced three times in one year, and each work order gives a different reason. A reliability engineer opens HYP-031 version 1: dry running damaged the seal faces. Record it as a candidate sourced only to the three work orders, with a stated prediction: if dry running were the cause, level history should show an empty suction before each failure. All records are invented for a purchasing demonstration.

Add EVD-031a, the level history, which shows normal suction before all three failures. Mark HYP-031 version 1 rejected, link the evidence that contradicted it and keep it retrievable. Open version 2: shaft misalignment after a coupling change. Add EVD-031b, the maintenance record: alignment readings exist for the first replacement and not the other two. That partly supports version 2, but the missing readings are an evidence gap, not a confirmation. Assign a task to measure alignment now.

A parallel branch asks about the seal itself. Stores records show a substitute seal type on two replacements and the original type on the third. The failure with the original type conflicts with this branch as a sole explanation, so the reviewer classes it as a possible contributing cause pending a comparison of seal life. The analysis now has two live branches and one rejected one, which a single linear why-field cannot show.

Now ask why the alignment check was missing. In the demo, the seal replacement procedure never required one, and the last procedure review did not cover this pump class. Record that as a proposed root cause that explains the direct cause rather than repeating it, as DOE asks. Keep it proposed until alignment readings are attached, then let a reviewer with authority over the maintenance system approve it.

Link ACT-031, adding a required alignment check to the procedure, and ACT-032, reviewing other pumps of the same class. Complete ACT-031 with the revised procedure attached. Leave EFF-031 pending: the team defined the check as comparing the next seal's run time with earlier ones. Completing ACT-031 must not close the analysis.

Make the reasoning reviewable

Both OSHA and HSE warn against stopping at a person. OSHA's employer guide says conclusions such as carelessness do not reach root causes and tells investigators to keep asking why, and HSE's human-factors page says the question is why a human failure occurred. HSE's workbook adds that the management-level part of an analysis belongs with people who have both responsibility for health and safety and authority to change the management system. Test whether permissions can reflect that.

Definitions differ between bodies. The US Chemical Safety Board describes root causes as usually deficiencies in safety management systems, though any factor whose absence would have prevented the accident can qualify. Ask whether your organisation can set its own definitions and cause categories and show them on the form.

Depth should fit the event. DOE says analytical effort should match the significance of the occurrence, and a low-level effort may use no formal method at all. Configure one lightweight and one full template, and see who chooses between them and whether the choice is recorded.

If the configuration proposes causes using AI or rules, keep the input, the proposal and the analyst's accept, edit or reject decision as separate entries. The vendor pages describe assistance and automation; none establishes that a proposed cause is correct for your event.

Six demonstrations to request before buying

Choose the method and the depth

Create one minor and one serious case. Show the lightweight and full templates, who chooses, and whether the choice is saved. Name every method, licence and facilitator in the quote.

Build a branching analysis

On RCA-031 enter the dry-running, misalignment and substitute-seal lines of enquiry together. Show two live branches at once and which have supporting evidence.

Reject a hypothesis without deleting it

Reject HYP-031 version 1 with its contradicting evidence and a reason. Reopen the case and show version 1 retrievable, marked rejected and still linked to that evidence.

Show a gap and a conflict

Enter the missing alignment readings as a gap and the original-type seal failure as conflicting evidence. Show that neither counts as support.

Classify and approve the causes

Label direct, contributing and proposed root causes with event-specific wording. Show who can approve the organisational cause and what happens if evidence arrives after approval.

Link to actions and test effectiveness

Link ACT-031 and ACT-032 to the cause they address, complete one and leave EFF-031 pending. Then log a fourth seal failure and show whether the earlier analysis opens beside it.

Questions to include in your RFP

Which named applications hold analysis, CAPA and action tracking, and which AI or add-on tools are separate items?

Which analysis methods and templates are included, with licences, training and any facilitator support?

Can one case hold several direct, contributing and root causes, and who may change the cause categories?

Is every version of a hypothesis or diagram kept, rejected ones included, and can the full history be exported?

How are evidence items linked to a cause, and how is a missing or conflicting item flagged?

Which roles approve a cause, can the author approve their own, and who signs off an organisational cause?

Can reports trend by cause category, equipment and site, and what happens to old records if categories change?

How does a cause link to an action and an effectiveness review, and what opens when a recurrence is logged?

Tie causes to actions, then check whether they worked

HSE's workbook asks for an action plan that deals with immediate, underlying and root causes, with arrangements to implement it and monitor progress. OSHA's guide says an investigation is not complete until corrective actions addressing the root causes are implemented. An action that links only to an incident cannot show which cause it was meant to address.

DOE separates follow-up from correction. Its guidance asks for tracking that actions were implemented and are working, a periodic structured review of the tracking system, and re-evaluation of the original occurrence if the same or a similar event recurs. It also treats trend analysis of occurrence information as an early sign of deteriorating conditions. Ask whether a repeat event can reopen the earlier analysis, and whether a cause-category trend survives later edits to the category list.

Connect confirmed causes to CAPA and action tracking, and to any resulting change in the risk assessment, bow-tie model or FMEA. Closure should say which cause was addressed, what evidence supports the action's effect and what remains open. This guide supplies no review interval; your responsible team sets the timing and acceptance criteria.

Use the same revised-hypothesis case in each demo

Record which tasks were demonstrated, the methods and licences used, and the analysis history exported. Keep untested behaviour visible before comparing proposals.

Open the software demo checklist

Official sources and scope

6 sources, checked 1 Oct 2026

Official guidance from HSE, OSHA, the US Chemical Safety Board and the US Department of Energy reviewed on 1 October 2026. They supply Great Britain and United States context and word definitions differently; this guide does not determine reporting duties, prescribe a method or guarantee prevention. Product scopes rest on vendor pages in each product's record, checked in late September 2026 and read as documentation, not tested. The synthetic case tests software records and review behaviour, not the cause of a real failure.

Frequently Asked Questions

Which root cause analysis method should the software support?

Whichever your investigation lead chooses for the event. HSE does not endorse one technique, OSHA suggests combining tools, and DOE matches method to the kind of problem, such as charts for long causal chains or barrier analysis for failed controls. Ask which methods are in the quote, with licences and templates, and see them used on a branching case.

Is a 5 Whys template enough?

It can organise a line of questioning, and HSE uses a version of it. But OSHA says there are often several root causes, and DOE uses charts for multi-faceted problems. Check for several branches, evidence links per answer and a way to mark a branch unresolved, not just five text boxes.

Can a root cause be recorded as human error?

The guidance reviewed here says to look further. OSHA states that carelessness or a missed procedure does not by itself reach the root cause, HSE asks why a human failure occurred, and DOE tells investigators to focus on programme and system deficiencies instead of blaming the employee. Test whether your configuration prompts another why or accepts a person's name as the answer.

How can software show a cause is supported by evidence?

It cannot judge that, but it can hold what a reviewer needs: a stated prediction, linked evidence for and against, flagged gaps, rejected alternatives and an approval history. DOE also asks that the root cause explain the direct cause, not restate it.

Does completing the corrective action show the cause was right?

No. Completion shows the action was carried out. DOE asks for follow-up on whether actions are working, with periodic review and re-evaluation if the event recurs, and HSE asks for progress to be monitored. Whether an effectiveness check can be required before closure depends on the package, so confirm it in the demo.