Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 62740:2015 – Root Cause Analysis (RCA) – Principles and Process
💡 Key Insight: RCA is fundamentally about distinguishing symptoms from causes. The standard provides a structured framework to systematically trace focus events back to their root causes, enabling preventive action rather than band-aid fixes.
1. Scope and Principles
IEC 62740 describes the basic principles of root cause analysis (RCA) and specifies the steps that a process for RCA should include. It identifies a number of attributes for RCA techniques which assist with the selection of an appropriate technique, describing each technique and its relative strengths and weaknesses. RCA is used to analyse focus events with both positive and negative outcomes, but is most commonly employed for the analysis of failures and incidents.
The standard emphasizes that RCA is fundamentally a posteriori analysis — it investigates events that have already occurred. Causes for such events can span design processes, organizational characteristics, human aspects, and external events. A critical distinction is made between immediate causal factors (surface-level triggers) and root causes (causal factors with no predecessor that are relevant for the purpose of the analysis). The standard explicitly states that RCA is not designed to assign responsibility or liability, focusing instead on systemic improvement.
✅ Core Philosophy: Events are addressed by understanding the root causes, rather than the immediately obvious symptoms. Addressing symptoms without root cause identification leads to recurrent failures and wasted resources.
2. The Five-Step RCA Process
2.1 Initiation
The RCA process begins by evaluating the need for analysis based on criteria such as events with large effects, multiple similar undesirable events, parameters moving out of tolerance, or failures involving critical equipment. The focus event is described, and the purpose and scope of the analysis are determined. A crucial element is defining the “stopping rule” — the point at which action can be defined or additional proof of cause is no longer necessary.
2.2 Establishing Facts
Data collection must occur before evidence is lost. Sources include physical evidence (failed components), photographs/videos, operational data from monitoring systems, and personal testimony through interviews. The standard stresses that interviews should focus on data collection rather than premature cause discussion, and that evidence preservation is paramount.
2.3 Analysis
This step establishes “how” and “why” the focus event occurred by structuring collected data to systematically derive root causes. Analysis involves organizing evidence, seeking explanations using causation models (barrier analysis, Reason’s Swiss cheese model, systems models), and continuing until the stopping rule is invoked. The standard identifies that causal factors may involve technical issues, human aspects, and environmental factors.
| RCA Technique | Best Application | Key Strength |
|---|---|---|
| Events & Causal Factors (ECF) Charting | Complex events with time sequence | Visual cause-effect timeline |
| Fault Tree Analysis (FTA) | Safety-critical system failures | Deductive logic, quantified probabilities |
| Fishbone (Ishikawa) Diagram | Manufacturing quality issues | Intuitive, minimal training needed |
| Why Method (5 Whys) | Simple, single-cause events | Quick, no tool support needed |
| Barrier Analysis | Safety/accident investigation | Identifies missing/inadequate controls |
2.4 Validation
Review activities throughout the process test whether identified causes can be substantiated. Independent review assesses completeness and correctness. Where appropriate, experiments, simulation, or statistical methods confirm causal hypotheses.
2.5 Corrective Action
Recommended actions must be evaluated for effectiveness and realism. Corrective actions aim to change the likelihood or consequence of focus events without introducing new unacceptable risks. The standard emphasizes monitoring reoccurrence to evaluate action effectiveness.
⚠️ Engineering Pitfall: A common mistake is stopping analysis at the first plausible cause (the “5 Whys trap”). The standard’s emphasis on the stopping rule prevents premature termination of the analysis before genuine root causes are identified.
3. RCA Models and Techniques
3.1 Barrier Analysis
Based on the hypothesis that focus events result from missing, failed, or ineffective barriers between a source of harm and a target. Barriers are classified as physical (engineered safety features, shielding, alarms) or administrative (procedures, training, supervision). The barrier analysis worksheet systematically documents undesired outcomes, sources of harm, barriers that should have precluded the event, and barrier failure mechanisms.
3.2 Reason’s Swiss Cheese Model
This model views organizational defenses as slices of Swiss cheese with holes (weaknesses). An event occurs when holes in all layers align — representing the convergence of latent failures (hidden system weaknesses) and active failures (immediate operator errors). The model encourages exploring causal factors beyond operator error to include organizational and systemic issues.
3.3 Systems Models
Systems theory approaches (including STAMP/CAST) consider human interaction with technology within complex social structures, influenced by organizational goals, policy, culture, and external pressures. These models are particularly suitable for analyzing events in highly complex socio-technical systems where traditional linear causality models are insufficient.
| Model | Core Hypothesis | Typical Output |
|---|---|---|
| Barrier Analysis | Missing/failed barriers cause events | Barrier analysis worksheet |
| Swiss Cheese Model | Aligning latent + active failures | Causal factor hierarchy |
| Systems Theory (STAMP) | Inadequate control constraints | Socio-technical control structure |
4. Engineering Design Insights
💡 Practical Takeaways for Engineers:
- Technique selection is critical: The standard provides a comprehensive attribute matrix (Table A.3) scoring 12 techniques across 9 criteria. Use this matrix to select the technique that best matches your event complexity, available expertise, and required rigor.
- Human factors integration: Annex E provides taxonomies (TRACEr, HFACS) for analyzing human performance. In our experience, 70-80% of industrial incidents involve human factors — these tools transform subjective blame assignment into objective causal analysis.
- Data mining potential: The standard highlights modern cluster analysis for identifying deviating data (outliers) across multi-dimensional datasets. For organizations with extensive operational data, this can reveal emerging failure patterns before they cause significant events.
- Documentation matters: The standard emphasizes that conclusions must be backed by documented evidence. A well-structured RCA report with clear causal chains, evidence references, and traceable conclusions is defensible and actionable.
5. Frequently Asked Questions
Q1: How does IEC 62740 differ from ISO 31010 risk assessment standards?
IEC 62740 focuses on a posteriori analysis — investigating events that have already occurred. ISO 31010 and risk assessment standards focus on prospective identification and evaluation of risks before events occur. RCA techniques identify root causes of past events to prevent future occurrences, while risk assessment evaluates potential future events and their consequences.
Q2: Can RCA be applied to positive events (successes)?
Yes. The standard explicitly states RCA can analyse focus events with both positive and negative outcomes. Analysing successful outcomes helps identify what went right so successful practices can be replicated. This is particularly valuable in project management and process optimization contexts.
Q3: What is the recommended team composition for an RCA?
The standard recommends appointing a team leader responsible for preparatory work (technique selection, analysis plan, room facilities). Team members should bring diverse expertise covering technical, human factors, and organizational aspects relevant to the focus event. Independence from the event being investigated is important to avoid bias.
Q4: How do you determine when to stop the analysis (stopping rule)?
The stopping rule defines the point at which corrective action can be identified before reaching factors that cannot be influenced (e.g., weather, government policy). It should be defined during the initiation phase and may be refined during review points throughout the analysis. The key criterion is: have we reached a point where we can take meaningful action to prevent recurrence?
