Root cause analysis process flowchart

What the root cause analysis process is

Root cause analysis is what happens between a problem being noticed and a corrective action being agreed. All of the value is in the middle: a problem statement written before anyone has a theory, evidence collected while it still exists, a timeline that shows what actually happened in what order, and a cause that survived being tested rather than one that sounded right in the room.

Most investigations fail in one of three ways. The problem statement already contains a cause, usually some version of operator error, so the analysis only confirms it. Containment gets mistaken for the fix, the symptom disappears and nobody comes back. Or the team stops at the first plausible answer because the evidence needed to rule out the alternatives was never collected, and by the time anyone asks the logs have rotated and the affected units have shipped.

The chart below runs from a raised problem to a closed RCA record handed into CAPA, across five lanes and five phases. It keeps the two routes that most process maps leave out: the insufficient-data branch, where the investigation either extends collection or closes with a documented limitation instead of inventing a cause, and the loop back from the cause verification decision when the hypothesis does not hold against the evidence.

What this flowchart covers

In this template

• Five swimlanes (Facilitator, Process owner, Investigation team, Quality, Management) across five phases: Problem and containment, Evidence, Cause analysis, Verification and Corrective action.
• Problem definition in the first phase: the process owner describes the problem as observed, the facilitator agrees a written problem statement, immediate containment is applied and recorded separately from the fix, and only then is the investigation team assembled.
• An "Evidence sufficient to proceed?" decision with three branches: proceed to the timeline, extend sampling and interviews then re-assess, or close the investigation with a documented data limitation when the evidence is genuinely gone.
• The analysis sequence in the Investigation team lane: reconstruct the event timeline, generate cause hypotheses using 5 Whys or a fishbone, then test each hypothesis against the evidence actually collected.
• A "Cause verified by evidence?" decision that proceeds only on a verified cause and otherwise loops back, either to re-analyse the hypotheses or to gather more data, before root cause and contributing factors are separated as an explicit step.
• The close-out path: Quality reviews and challenges the conclusion, the facilitator records the RCA findings, the process owner proposes corrective actions, management approves and resources them or returns them for rework, and Quality opens the CAPA record before the RCA is closed.

When to use this template

• A problem keeps being fixed and keeps coming back, and you need the investigation to reach a cause rather than produce another workaround.
• You are writing or revising an RCA or problem management procedure and need one picture of who facilitates, who investigates, who reviews and who authorises the actions.
• Investigations vary depending on who runs them, and you want the same evidence, verification and review steps applied every time.
• A customer, regulator or certification auditor has asked how your organisation determines the causes of nonconformities and what evidence supports the conclusion.
• Your CAPA queue is full of actions with no traceable cause behind them, and you need a defined handover point between the analysis and the action.

How it works

1. Rename the lanes to your real roles

   Replace Facilitator, Process owner, Investigation team, Quality and Management with the functions you actually have. Keep the facilitator separate from the process owner where you can: an investigation run by the person accountable for the process tends to stop at causes that are comfortable to state. Merge lanes rather than leaving one that appears only once.

2. Set the trigger and the threshold

   Write down what raises an RCA in your organisation — a deviation, a repeat incident, a customer complaint above a severity, a failed audit — and just as importantly what does not. An RCA on everything means a real one on nothing. Put the threshold next to the Start node so the entry criteria travel with the diagram.

3. Define what counts as sufficient evidence

   The "Evidence sufficient to proceed?" decision only works if someone has written down what evidence is expected: retained samples, logs and their retention window, batch or shift records, interview notes, photographs. Flag the perishable items, because those set how quickly containment and collection have to happen.

4. Choose the analysis method deliberately

   Replace "Generate cause hypotheses" with the methods your team will actually run and note when each applies: 5 Whys for a linear chain, a fishbone for a problem with several plausible categories, fault tree analysis where failures combine. Naming them on the node stops the choice defaulting to whatever the facilitator used last time.

5. Say what verification means, and who challenges it

   Define the test behind "Cause verified by evidence?" — the cause explains the whole timeline, the evidence is consistent with it, and removing it would have prevented the problem. Then name the reviewer in the Quality lane. Independent challenge is what separates a verified conclusion from a shared assumption.

6. Define the CAPA handover and keep the map versioned

   Be explicit about where this process ends and CAPA begins, usually at an approved action with an owner, a due date and an effectiveness check defined. If you work to ISO 9001, this is the boundary between clause 10.2's requirement to determine the causes of a nonconformity and the corrective action that follows; the standard does not prescribe an analysis method, so the one you pick is yours to document. Keep the diagram versioned and capture its approval, so investigators and reviewers work from the same version.

Frequently asked questions

What are the steps in a root cause analysis process?

Define the problem, contain it, collect evidence, reconstruct the timeline, generate cause hypotheses, test them against the evidence, verify the cause, separate it from contributing factors, then propose corrective actions and hand them into CAPA. The sequence matters more than the method: containment before analysis so the problem stops spreading, evidence before hypotheses so the team is not defending a theory formed on day one, and verification before any corrective action is written.

What is the difference between a root cause and a contributing factor?

A root cause is one you can remove so that this problem cannot recur. A contributing factor made the problem more likely, harder to detect or worse when it happened, but removing it alone would not have prevented it. Most real investigations produce one or two root causes and several contributing factors, and all of them can earn actions — but only the root cause justifies closing the investigation. It is a distinct step in this chart because teams that skip it tend to write actions against whichever factor is easiest to fix.

Should I use 5 Whys or a fishbone diagram?

5 Whys suits a linear causal chain owned by one team: each answer becomes the next question, and you stop when going further leaves what you control. A fishbone (Ishikawa) diagram is better when several categories could be involved — method, machine, material, people, measurement, environment — because it forces the team to consider branches it would otherwise walk past. Many investigations use both, generating candidates on a fishbone then running 5 Whys down the branch the evidence supports. Neither is a verification method, which is why hypothesis testing is a separate step here.

What should happen when there is not enough data to find the cause?

Decide explicitly and record the decision. This template puts three branches on "Evidence sufficient to proceed?": proceed, extend sampling and interviews then re-assess, or close with a documented data limitation. The third branch is the one most procedures omit, and its absence is why teams write a speculative cause rather than state that the evidence was gone. Closing with a stated limitation is a legitimate outcome, and it normally generates an action of its own: make the missing data available next time.