Root cause analysis in OSH

What is root cause analysis in OSH

Every accident has an immediate cause, the event that directly produces the injury: contact with a moving part, a fall from a platform, inhalation of fumes. Behind that immediate cause are factors that made it possible: a removed guard, a platform without a railing, a malfunctioning extraction system. And behind those factors are decisions and organizational shortcomings: insufficient maintenance resources, procedures that penalize safe behavior, outdated assessments, inadequate supervision. Root cause analysis traces this chain backward to identify the causes that the organization can address in a lasting way.

In Spain, there is no regulation that mandates a specific method of analysis. Law 31/1995 requires the investigation of health hazards and the identification of their causes, and the INSST (National Institute for Safety and Health at Work) has developed reference methods, particularly the fault tree analysis (NTP 274) and the accident cause classification (NTP 924), which the INSST itself uses in the investigation of workplace accidents. The term “root cause” originates from quality management and process safety and has become widespread in occupational safety and health management.

The ILO-OSH 2001 guidelines state that investigations of accidents, illnesses, and incidents should identify deficiencies in the management system and that their findings should be translated into corrective actions. This is precisely the purpose of root cause analysis.

Usual methods

The most commonly used prevention methods share the idea of ​​not stopping at the first level of explanation:

• Fault tree. This method reconstructs the sequence of events backward from the injury, asking what was necessary for each event to occur, and represents the chains and conjunctions of events in a diagram. It is the INSST’s reference method and does not presuppose a typology of causes.
• Five Whys. This method involves asking successive questions about why each event occurred until an organizational failure is identified. It’s simple and quick, suitable for straightforward incidents, but tends to follow only one causal line.
• Cause and effect diagram (Ishikawa). It organizes possible causes into categories (person, machine, method, material, environment, management) to ensure no family is overlooked; it is useful for structuring collected information before analysis.
• Barrier analysis. Identifies what barriers (technical, organizational, human) should have prevented the event and why they failed or did not exist; it relates to the hierarchy of controls.
• Latent failure models. They distinguish active failures caused by the operator from latent conditions created by previous design, organizational, or management decisions.

No method is mandatory, and none guarantees the result on its own. What is crucial is that the team has verified facts, applies the method down to the organizational level, and compares the conclusions with those familiar with the actual work.

How to apply: steps

1. Define the event precisely: what happened, where, when, to whom, and with what real and potential consequences.
2. Gather facts, not opinions: site observation, documents, maintenance and training records, interviews.
3. Order the facts in sequence and separate what is proven from what is assumed.
4. Apply the chosen method until the organizational causes are identified; verify that each proposed cause is supported by a fact.
5. Verify the root causes with a control question: if this cause had been eliminated, would the event have been avoided or its severity reduced?
6. Define measures for each root cause, prioritizing elimination and technical and organizational measures that depend on behavior.
7. Assign responsibility and deadline, integrate the measures into the preventive planning and check their effectiveness after a certain time.

Organizational application

Root cause analysis is applied proportionally. A minor incident can be resolved with five “whys” in the same shift; a serious accident or a high-potential incident requires a team, a full root cause tree, and management review. The company’s investigation procedure should define the appropriate level of analysis for each type of event and who is involved.

• Team. Direct management, prevention service, people who perform the task and, where appropriate, maintenance and engineering; worker safety representatives have the right to be informed and contribute knowledge of the actual work.
• Wait a minute. The sooner the better; facts are lost and stories are reconstructed.
• Record. Diagram or table of causes, associated measures and follow-up, kept with the investigation report.
• Cross-functional learning. Root causes often affect more positions and centers than just the one where the incident occurred; measures should be extended to all of them.

Digital management tools allow you to link each cause with its measures, maintain traceability of the monitoring and analyze recurring causes among events, turning isolated investigations into information about the system.

Limits and common mistakes

1. Confusing the immediate cause with the root cause and concluding “human error” or “lack of attention” as the final explanation.
2. Looking for a single cause: almost all accidents result from the combination of several factors.
3. Stop the analysis at a level that is comfortable for the organization, avoiding questioning management, budget, or staffing decisions.
4. Accepting causes without supporting facts, or building the diagram from unproven hypotheses.
5. Producing lists of causes without associated measures, or measures without responsible party or deadline.
6. Using the analysis to assign blame degrades the quality of information in subsequent investigations.

Root cause analysis is also not a legal instrument: it does not determine administrative, civil or criminal liability, although its report may be used as evidence in those proceedings.

Regulatory framework and technical references

• Law 31/1995, article 16.3 . Obligation to investigate health damages in order to detect their causes.
• NTP 274: Accident investigation: cause tree (INSST) . Description of the reference method in Spain.
• NTP 924: Causes of accidents: classification and coding (INSST, 2011) . Classification of causes used by the INSST for the analysis of accidents, with blocks of material conditions, environment, organization and individual factors.
• ILO-OSH 2001, section 3.12 . The investigation should identify deficiencies in the management system and lead to corrective actions.

ISO 45001 requires organizations that adopt it to investigate incidents and nonconformities and determine their causes, without prescribing a method. In the process industry, process safety has developed its own methods for analyzing incidents that share the principles described.