Skip to main content
    QHSEtech
    Updated
    All glossary terms
    Content date: · No individual check logged· AI use

    Root Cause AnalysisRCA

    Also known as: Root cause investigation

    Definition

    Root Cause Analysis — a method for finding the underlying causes of an incident or nonconformance, using techniques such as 5-Why, fishbone or fault trees.

    Editorial definition: The QHSE Standard, updated 3 October 2026 · https://qhsetech.com/glossary/root-cause-analysis

    How HSE and OSHA describe root causes

    HSE's HSG245, Investigating accidents and incidents (published 2004), separates three levels of cause. An immediate cause is the most obvious reason an adverse event happens, such as a missing guard. An underlying cause is the less obvious system or organisational reason, for example pre-start checks not being carried out or production pressure being too great. A root cause is an initiating event or failing from which the other causes spring, which HSE says is generally a management, planning or organisational failing. Its advice is to provide risk control measures that address the immediate, underlying and root causes, because dealing only with the immediate cause may give a short-term fix.

    Both regulators warn against stopping at the person. HSG245 says that investigations concluding operator error was the sole cause are rarely acceptable, and that apportioning blame before an investigation starts is counterproductive. OSHA's incident investigation page says it is far too easy, and often misleading, to conclude that carelessness or failure to follow a procedure alone was the cause, and it suggests asking why a rule was not followed, whether production pressure played a part, and whether the procedure or the training was out of date.

    Neither body prescribes a technique. HSG245 states that HSE does not endorse any one method and that techniques are tools, not an end in themselves. It adds that for large, complex or technically demanding investigations such techniques may be essential, while a methodical approach with full employee participation can be enough for simpler cases. Common methods such as 5 whys, fishbone diagrams and fault tree analysis are listed in the QHSE glossary; none guarantees a correct answer, because each depends on the evidence and on the people in the room.

    Sources opened :

    What a root cause analysis record holds in software

    • The event or problem statement, written from facts and kept separate from the conclusion.
    • A timeline of what happened, with the source of each entry (witness, log, photograph, system data) marked.
    • The method used and the causal chain it produced, shown as a diagram or a structured table, with immediate, underlying and root causes labelled apart.
    • For each cause, the evidence that supports it and any evidence that was sought but not found, so a reviewer can see how firm the conclusion is.
    • Links to the corrective actions that address each cause, so a cause without an action, or an action without a cause, is visible.

    Root cause analysis, investigation and 5 whys

    An investigation is the whole effort: securing the scene, gathering evidence, interviewing, analysing, deciding actions and following up. Root cause analysis is the analysis step inside it, and 5 whys, fishbone diagrams and fault trees are techniques used within that step. A tool that offers a 5 whys template supports one technique; it does not by itself show that an investigation was thorough or that the stated cause is correct. The phrase also hides an assumption that there is a single root cause, whereas HSE's own wording is plural.

    A hypothetical example: a guard taped open on a packing machine

    This case is invented to show the shape of the analysis and describes no real site. During a routine inspection a supervisor finds the guard on a carton sealer taped open. Nobody was hurt. The first answer on the form is that an operator removed the guard, which is the immediate cause, and an investigation that ended there would end with a reminder to the team.

    The investigator asks why, with two operators and a maintenance fitter in the room. The guard is removed to clear jams. Jams are frequent because a feed guide is worn. The guide has sat on the maintenance backlog for months because the planned maintenance schedule was cut when the shift pattern changed, and nobody reviewed the effect. Those are underlying causes. The root causes the team records are that changes to the shift pattern are not assessed for their effect on maintenance, and that the jam-clearing method was never risk-assessed. Actions follow at each level: an interlocked guard and a written jam-clearing method (immediate), the guide replaced and the schedule restored (underlying), and a rule that shift changes go through a review (root). The record lists the evidence for each step, such as the maintenance log and the operators' accounts, and notes where it relied on memory. A check after six weeks counts jams and guard-defeat observations.

    Common misunderstandings about root cause analysis

    • A root cause is not always a single thing. Events usually have several contributing causes, and a method that forces one answer can leave real contributors untouched.
    • The fifth 'why' is not magic. The number of questions depends on where the chain leads, and a chain that stops at a person, such as 'lack of care', has usually stopped too early.
    • A completed diagram does not validate a cause. A fishbone shows possible causes put forward by a team; each still needs evidence before it is treated as a finding.
    • Root cause analysis is not only for serious events. HSG245 says the level of investigation should follow the potential consequences and the likelihood of recurrence, so a near miss with serious potential can deserve more effort than a minor injury.

    How root cause analysis relates to other glossary terms

    Root cause analysis connects the report of an event to the actions that follow it, so its neighbours are the terms on either side.

    • CAPA: the process that takes the causes found here and turns them into owned actions with an effectiveness check.
    • Near miss: events with no harm that can still justify a full analysis when the potential outcome was serious.
    • Serious injury or fatality: a classification by actual or potential severity that can decide how deep an analysis should go.
    • PSM: for covered chemical processes, investigation of an incident that could reasonably have led to a catastrophic release is mandatory and the report must cover contributing factors.

    Records and evidence that usually exist for root cause analysis

    • The investigation procedure: who investigates, how the depth is chosen, what must be preserved and how workers take part.
    • The original report, the photographs, logs or data captured soon after the event and the witness accounts.
    • The timeline and the analysis itself, with the method named.
    • A statement of the immediate, underlying and root causes, each tied to evidence.
    • The actions raised, their owners and dates, and proof of completion.
    • A check, some time later, that the actions held and that no similar event occurred.

    What a software tool needs to capture for root cause analysis

    • A structured record that keeps the event description, the timeline, the causal analysis and the actions in separate fields.
    • Support for more than one method, or free attachment of a diagram, so that the technique fits the event rather than the product.
    • Cause categories that separate immediate, underlying and root causes, with a way to attach evidence to each.
    • A link from each cause to the actions that address it, with a flag for any cause that has none.
    • Depth settings that follow actual and potential severity, with the reasoning recorded.

    Catalog profiles documenting root cause analysis

    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. Documented and conditional capabilities qualify; check the linked scope before treating a module as included.

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

    All 48 matching profiles are shown. Documentation review, not hands-on testing or a claim of compliance.

    Related software

    Frequently asked questions

    How many whys are enough?

    There is no fixed number. Continue until the answer points to something the organisation can change and the evidence supports each step; stopping at an individual's behaviour is usually too early.

    Who should take part in the analysis?

    The people who do the work, a supervisor or manager and someone with the technical knowledge. OSHA's guidance says investigations are most effective when managers and employees work together.

    Is a fishbone diagram a root cause analysis?

    It is one technique. It organises possible causes for discussion, and each still needs evidence before it is treated as a finding.

    More safety terms

    Related guides