Root cause analysis process flowchart
Root cause analysis process flowchart covering problem statement, containment, evidence, 5 Whys and fishbone, cause verification and handover into CAPA.
How it works
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.
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.
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.
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.
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.
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.