Share this
by Christian Reyes on September 08, 2026
A companion piece to the latest Compliance Lab episode on the QT9 Q-Cast.
Today’s regulatory environment urges close attention to mitigating risk. That’s why root cause analysis cannot simply be the form a quality team completes after the fire is out. Root cause analysis (RCA) must prove something: what happened, why it happened, why the system did not catch it sooner and what changed to reduce future risk. If your root cause investigations still conclude with "operator retrained," the tools and techniques below are for you.
There are a variety of root cause analysis techniques that give quality teams a structured way to move beyond the first explanation for a problem, which is what auditors now look for. Methods, such as Five Whys, fishbone diagrams and Pareto analysis, help organize an investigation, but completing a method does not automatically establish the root cause.
Compliance standards require manufacturers to show that the RCA method used led to a supported conclusion with a clear evidence trail. An auditor should be able to move from the original issue to the investigation, from the investigation to the cause, from the cause to an appropriate corrective action, and from that action to evidence that it worked.
Contents
What are the most common root cause analysis techniques?
Occurrence cause vs. escape cause
How to go from cause statement to verified closure
What are common root cause analysis mistakes?
A real-world root cause analysis example
Root cause analysis and compliance
How QT9 QMS supports root cause analysis and CAPA
WATCH: Root Cause Analysis in 2026
What is root cause analysis?
Root cause analysis is a structured way to identify the underlying reasons a problem occurred. The word “underlying” is important, because the first explanation is rarely the whole answer.
Say a manufactured batch is built using the wrong drawing revision. The surface explanation is "someone used the wrong drawing." That may be true, but it is not enough.
A better investigation asks why the obsolete revision was still available, why the work order did not point to the current revision, why document control allowed two active versions of the same document and why inspection did not catch the mismatch. Now you have moved from a people problem to a process problem, which is the entire point. Root cause analysis is not about assigning blame. It is about understanding how the process let the issue happen.
What are the most common root cause analysis techniques?
Teams can overcomplicate root cause analysis by using a technique that is too broad for the problem, or miss critical information by selecting a familiar tool without thinking through the problem. The goal is to choose one or two techniques that fit the problem and support the conclusion with evidence.
Five Whys
Five Whys is a simple, practical technique best used for a focused issue with a reasonably clear cause-and-effect chain. The team begins with the problem and continues asking why until the investigation moves beyond the surface answer.
For example, if the chain ends with an employee failing to follow a procedure, the investigation should continue. Why didn’t the employee follow procedure? Was the procedure outdated or unavailable? Was competency verified? Did the workflow make the wrong step easier than the right one?
Fishbone diagram
A fishbone diagram, or Ishikawa, is useful when several contributing factors may be involved. It prompts the investigating team to examine people, process, equipment, materials, measurement, environment and management systems rather than settling on the first explanation. Its value is not the completed drawing, it is the discipline of looking beyond the first explanation.
Pareto analysis
A pareto analysis is used to prioritize which problems to fix first based on frequency or cost. It helps a team address the defect or complaint categories creating the most impact.
Process mapping
Process mapping is a visual method that uses flowcharts or diagrams to show each step of a workflow. It is most helpful when the failure happened at a handoff between steps, functions or systems.
Fault tree analysis
Fault tree analysis is a top-down deductive method that uses logic and diagrams to trace system failures to root cause. It is most useful when several conditions may have combined to produce the event.
8D
8D, or Eight Disciplines, method provides a structured, team-oriented problem-solving framework for higher-risk, cross-functional problems.
FMEA
Failure modes and effects analysis (FMEA) is primarily a forward-looking risk tool rather than a root cause analysis method. After an investigation, it can help the team consider where the same failure mode could apply elsewhere and which controls should be strengthened.
Occurrence cause vs. escape cause
One framework sharpens almost any root cause investigation: separate the occurrence cause from the escape cause.
-
The occurrence cause answers why did the problem happen?
-
The escape cause answers why did the system fail to detect it before it created risk?
Picture a machining process where a dimension drifts out of tolerance. The occurrence cause might be a worn fixture that lets the part shift. The escape cause might be an inspection plan that checks the dimension only once per shift, so the drift runs unseen between checks.
Replace the fixture and you have addressed the occurrence cause — good — but if you do nothing about the detection gap, the next problem escapes the same way. The logic travels well beyond the shop floor: a training issue can occur because a procedure changed and escape because nothing required retraining before the next job; a documentation error can occur because an obsolete form stayed accessible and escape because approval routing never verified the current revision.
How to go from cause statement to verified closure
A strong investigation produces a cause statement that is specific, testable, tied to the process and directly connected to the corrective action. That is where modern root cause analysis parts ways with older paper-based habits, where closure meant a simple status update, such as open, assigned, completed or closed. That trail shows someone responded. It does not show that risk decreased.
Verified closure needs evidence that the action matched the cause and was implemented, that affected people were retrained and their competency confirmed, that the relevant documents, specifications or inspection plans were updated and that over a defined period or sample the issue did not recur or the process metric improved.
No root cause analysis tool produces the answer on its own. A strong investigation establishes the scope of the problem, explains why it occurred and escaped existing controls, connects each corrective action to a supported cause, and defines the evidence required for closure.
Records, observations, measurements and process data should support the reasoning. The method organizes the investigation, but the evidence determines whether the cause is defensible.
What makes a root cause statement defensible?
A root cause statement should be specific enough to test and precise enough to guide action. It should identify the process condition that produced the failure, not simply repeat the symptom or assign fault to a person.
For example, ‘the procedure was not followed’ describes what happened. It does not explain why. A stronger investigation may establish that the current procedure was unavailable at the point of use, the approval workflow did not remove the obsolete version and the training requirement was not triggered before the revision became effective. Those conclusions point to controls that can be changed and verified.
What are common root cause analysis mistakes?
Certain conclusions should prompt another round of questions before an investigation is approved.
-
Operator error Human error may describe the final event, but it rarely explains the system conditions that made the error possible. Reviewers should ask whether instructions were current and accessible, competency was verified, responsibilities were clear and the workflow made the correct action easier to complete.
-
The employee was retrained Retraining may be part of the response, but it is not a default corrective action. The investigation should first determine whether the original training was inadequate, the document changed, competency was never demonstrated or the process itself remained difficult to follow. The effectiveness check should measure more than attendance.
-
The procedure was not followed This statement identifies a deviation from the expected process, not its cause. The investigation still needs to explain whether the procedure was unclear, outdated, unavailable, inconsistent with actual work or unsupported by an effective verification step.
-
We added 100 percent inspection Additional inspection may be suitable containment when the potential impact is high. As a permanent corrective action, however, it often detects defects after they occur rather than preventing the cause. The team should explain whether inspection is temporary, what condition it controls and what process change will reduce occurrence.
A real-world root cause analysis example
Let's say final inspection discovers surface defects on molded plastic parts that are outside specification across several lots. A weak response might be: the operator failed to control the process, inspectors were retrained, extra inspection was added. It sounds like action, but it answers almost nothing.
A more thorough RCA investigation finds that a restricted cooling channel let the mold temperature drift outside the approved range, and that the preventive maintenance plan never checked for cooling-flow degradation. That is the occurrence cause. The escape cause is separate: the process log was reviewed only at end of shift, and the visual inspection standard had no clear examples of unacceptable defects.
In this scenario, the techniques earn their place. A fishbone diagram can map the contributors — mold settings, material variation, equipment condition, inspection criteria, environment. A Five Whys method narrows in on the cooling restriction, the maintenance gap and the delayed log review. Still, the tools do not replace evidence. The team must supply maintenance records, process data and inspection results to support the cause.
Now the corrective actions mean something: the cooling circuit is cleaned and the maintenance plan updated to include flow verification. Machine monitoring triggers an immediate alert when temperature leaves the approved range. The visual standard is revised with real defect examples, and inspectors are retrained with verified competency. Recent lots are reviewed for affected material, and effectiveness is measured over a defined number of runs.
The final response explains how the process failed, how detection failed, and here is what changed so the risk is lower going forward.
Root cause analysis and compliance
From a compliance standpoint, root cause analysis is about far more than fixing one issue. It demonstrates whether an organization understands process risk, investigates consistently, ties corrective actions to real causes and verifies effectiveness with objective evidence. The practical expectation is remarkably consistent across ISO 9001, ISO 13485, AS9100 and FDA regulations: identify the cause, address it, implement the change and confirm the risk was reduced.
An auditor, customer or executive tends to ask the same chain of questions. What was the issue? How was it evaluated and which method was used? What containment was required? What cause was identified, what corrective actions were taken, what changed and how was effectiveness verified? If that trail is scattered across emails, spreadsheets, shared folders and tribal knowledge, control is genuinely hard to show.
It is why quality teams are consolidating into connected quality management systems, where nonconformances, corrective actions, complaints, audits, controlled documents, training records, risk controls and effectiveness checks share one audit trail.
That is the model behind QT9: the issue, the investigation, the action, the evidence and the follow-up are all connected, so proving control is a matter of pulling a record rather than reconstructing a story.
How QT9 QMS supports root cause analysis and CAPA
QT9 QMS connects root cause analysis with the quality processes that supply evidence and carry corrective actions forward. Nonconforming Products, CAPA, complaints, audits, controlled documents, training, approvals, risk controls and effectiveness checks remain linked within one audit trail.
The issue, investigation, action, evidence and follow-up stay connected, making it easier to show what happened, what changed and how the organization verified that the risk went down.
See how QT9 QMS connects root cause analysis, CAPA and effectiveness verification across one traceable quality record. Request a demo.
Want the full walkthrough? Host Christian Reyes breaks this scenario down step by step in the companion Compliance Lab episode on the QT9 Q-Cast.
