Home / Guides / Root Cause Analysis in Risk Management
Guide

Root Cause Analysis in Risk Management

How to examine causes after incidents or recurring weaknesses and turn findings into better controls.

By Adrian M. FenwickReviewed August 3, 2026

Root cause analysis seeks the conditions and system factors that allowed an event to occur or recur. It should move beyond assigning blame to one person and examine process, incentives, information, design, supervision, workload, and control performance.

Start with a clear problem statement

Describe what happened, where and when, the expected condition, the actual consequence, and the evidence available. Avoid embedding an untested cause in the statement.

Map the sequence

Build a timeline of relevant events, decisions, signals, handoffs, and control actions. Separate confirmed facts from assumptions and missing information.

Use more than one technique

  • Five Whys for a simple causal chain
  • Cause-and-effect diagram for categories
  • Barrier or control analysis
  • Change analysis comparing expected and actual conditions
  • Fault or event trees where appropriate

Distinguish immediate and systemic causes

An immediate error may explain the final action, but deeper conditions may include ambiguous procedures, conflicting incentives, poor interface design, missing review, or unrealistic workload.

Turn findings into action

Recommendations should address verified causes, name owners, include dates and evidence, and avoid relying only on retraining when the process or design remains weak. Update risk assessments and controls based on the lesson.

Use with judgmentRisk methods support decisions; they do not remove uncertainty. Record assumptions, limits, and acceptance authority.

Do not stop at the first explanation

“Human error,” “supplier failure,” or “system issue” often labels the final visible event rather than explaining why it occurred. Root cause analysis examines conditions, decisions, controls, interfaces, workload, incentives, design, and prior warnings. The aim is to identify changeable contributing factors, not to force every event into one simple cause.

Connect learning back to risk records

After an incident or near miss, review related risk statements, control assumptions, indicators, and treatment plans. The event may reveal that a risk was missing, a likelihood estimate was weak, a control existed only on paper, or escalation thresholds were ineffective. Corrective actions should be tracked like other treatments.

Analysis checks

  • Is evidence preserved before conclusions are fixed?
  • Are people closest to the work involved?
  • Have organizational and technical factors both been considered?
  • Will actions address causes rather than only consequences?
  • Is effectiveness checked after implementation?