Root cause analysis for corrective actions is one of the most misunderstood skills in ISO auditing. Auditors raise nonconformities. Auditees submit corrective action responses. And then, three months later, the same problem appears again. That cycle happens because the corrective action addressed the symptom, not the cause. This article breaks down how to conduct root cause analysis properly, which tools to use, and how auditors should evaluate whether a root cause investigation is credible.
On this page
Why Root Cause Analysis Matters in ISO Auditing
Every major ISO management system standard, including ISO 9001, ISO 14001, and ISO 45001, requires organisations to investigate nonconformities and take corrective action. The requirement is not simply to fix what went wrong. It is to understand why it went wrong and prevent it from happening again.
ISO 9001 Clause 10.2 is explicit about this. When a nonconformity occurs, the organisation must determine its causes and implement action to prevent recurrence. The same logic runs through ISO 14001 Clause 10.2 and ISO 45001 Clause 10.2. Across all three standards, corrective action without genuine root cause analysis does not satisfy the requirement.
From an auditor's perspective, this matters at every stage. Internal auditors need to evaluate whether the corrective actions raised from previous audits have actually addressed root causes. Lead auditors conducting certification or surveillance audits look for the same thing. A corrective action response that says
staff have been retrainedwithout explaining why the failure occurred in the first place is not a root cause analysis. It is a guess dressed up as a solution.
The Difference Between a Symptom, a Cause, and a Root Cause
Before choosing a root cause tool, it helps to be clear about what you are actually looking for. Most people conflate three different things.
A symptom is what you observed. A calibrated measuring device was used beyond its due date. A contractor was inducted without completing the required safety induction. An environmental aspect was missing from the register.
A cause is the immediate reason the symptom occurred. The technician did not check the calibration status before use. The site supervisor approved contractor access without verifying induction records. The register had not been reviewed since the new process was introduced.
A root cause is the underlying systemic reason that allowed the cause to occur. There was no system to flag overdue calibration items at the point of use. Supervisor responsibilities for contractor verification were not defined in the procedure. No trigger existed to prompt a review of the aspects register when processes changed.
The distinction matters because corrective actions aimed at symptoms or immediate causes tend to fail. Retraining a technician does not fix the absence of a calibration status check at the point of use. The next technician will make the same error.
Common Root Cause Analysis Tools
There is no single method that works in every situation. The right tool depends on the complexity of the nonconformity and the resources available. Here are the methods that appear most often in ISO corrective action processes.
The 5 Whys
The 5 Whys is the most widely used root cause tool in management system contexts. The approach is straightforward. You take the observed problem and ask why it occurred. Then you take that answer and ask why again. You repeat this process until you reach a cause that is systemic and actionable, typically after three to five iterations.
For example, a nonconformity is raised because a batch of product was released without completing the required inspection record.
- Why was the product released without an inspection record? Because the operator did not complete the form.
- Why did the operator not complete the form? Because they were not aware it was required for this product type.
- Why were they not aware? Because the work instruction did not specify which products required the form.
- Why did the work instruction not specify this? Because it had not been updated when the new product line was introduced.
- Why had it not been updated? Because there was no process for reviewing work instructions when new products are added.
The root cause is the absence of a change management trigger for work instruction review. Retraining the operator would not have fixed this. Updating the change management process will.
The 5 Whys works well for relatively contained problems. It is fast, requires no special tools, and produces clear, traceable logic. Its weakness is that it can lead down a single path and miss contributing causes. For more complex failures, a broader tool is needed.
We have a dedicated article on the 5 Whys method for root cause analysis if you want to go deeper on the technique.
Fishbone Diagrams (Ishikawa)
The fishbone diagram, also called a cause and effect diagram or Ishikawa diagram, is useful when a nonconformity has multiple potential contributing causes. The problem is placed at the head of the fish. The main bones represent categories of potential causes, commonly people, process, equipment, environment, materials, and management.
For each category, the team brainstorms what could have contributed to the problem. This structured approach helps avoid the tunnel vision that the 5 Whys can produce. It is particularly useful when the nonconformity involves several departments or process steps.
The fishbone diagram is a discovery tool, not a conclusion tool. Once you have identified the most likely causes through the diagram, you still need to verify them with evidence before determining the actual root cause. A well completed fishbone diagram that has not been validated against evidence is just a hypothesis map.
For a full walkthrough of this method, see our article on fishbone diagrams for root cause analysis.
Fault Tree Analysis
Fault tree analysis works from the top down. You start with the undesired event and map out the logical combinations of failures that could have produced it. This method is common in safety and engineering contexts and is well suited to ISO 45001 incident investigations where multiple failures combined to cause harm.
Fault tree analysis is more resource intensive than the 5 Whys or fishbone approach. It is best reserved for significant incidents or major nonconformities where understanding the full combination of contributing factors is critical.
FMEA as a Proactive Tool
Failure Mode and Effects Analysis is primarily a proactive risk tool rather than a reactive investigation method. However, it is worth mentioning because some organisations use FMEA outputs to inform their corrective actions. If an FMEA already identified the failure mode that led to a nonconformity, the corrective action should address why the control identified in the FMEA was not effective.
How to Evaluate a Root Cause Analysis as an Auditor
When you are reviewing a corrective action response, whether as an internal auditor verifying closure or as a lead auditor during a surveillance audit, you are not just checking that something was done. You are evaluating whether the root cause investigation was credible and whether the actions taken are likely to prevent recurrence.
Here is what to look for.
Is the Root Cause Specific Enough to Act On?
Vague root causes produce vague actions. If the root cause is stated as
lack of awarenessor
human error, that is a symptom, not a root cause. Why was there a lack of awareness? Why did the human error occur? Push for specificity. A credible root cause names the system or process failure that allowed the problem to occur.
Does the Corrective Action Address the Root Cause?
This sounds obvious but it is frequently where corrective actions fall apart. Check whether there is a logical connection between the stated root cause and the actions taken. If the root cause is that the procedure did not include a specific control, the corrective action should be to update the procedure, verify the update, and communicate it to affected staff. Retraining staff on a procedure that has not been updated does not address the root cause.
Is There Evidence the Action Was Implemented?
A corrective action is not closed just because someone wrote down what they planned to do. Look for objective evidence. Updated procedures with revision history. Training records showing the updated procedure was communicated. Monitoring data showing the problem has not recurred. This is particularly important during surveillance audits where you are verifying effectiveness, not just implementation.
Has the Organisation Considered Whether the Problem Exists Elsewhere?
ISO 9001 Clause 10.2 specifically requires organisations to determine whether similar nonconformities exist or could potentially occur in other areas. This is often overlooked. If a work instruction was not updated when a new product was introduced, the organisation should check whether other work instructions have the same gap. A corrective action that only fixes the specific instance without checking for systemic spread is incomplete.
Common Mistakes in Corrective Action Root Cause Analysis
After conducting hundreds of external audits, certain patterns of poor root cause analysis appear repeatedly. Being aware of them helps you identify them quickly.
Jumping to Retraining
Retraining is the most common corrective action and often the least effective. It treats every failure as a knowledge problem. Many failures are system or process problems. Before accepting retraining as a corrective action, ask what specifically will be different after the training. If the answer is that staff will know the procedure better, ask why the procedure was not being followed in the first place. That answer is usually the real root cause.
Confusing Correction with Corrective Action
A correction is the immediate fix. You calibrate the overdue instrument. You re inspect the released product. You update the incomplete record. These are necessary but they are not corrective actions. A corrective action addresses the system failure that allowed the problem to occur. Auditors should verify that both a correction and a corrective action have been completed, not just one or the other.
This distinction is explained in more detail in our article on correction vs corrective action.
Stopping Too Early in the Why Chain
The 5 Whys requires discipline. It is tempting to stop at the second or third why because you have found a plausible cause. But plausible is not the same as root. Keep asking until you reach a cause that is systemic, something in the design of the process, the management system, or the organisational structure. If you can fix the cause by updating a system or process rather than by telling an individual to do better, you are probably at the right level.
Treating Root Cause Analysis as a Documentation Exercise
Some organisations complete root cause analysis forms because the auditor asked for one, not because they genuinely want to understand the failure. You can usually tell. The analysis is superficial. The actions are generic. There is no evidence of investigation, just conclusions. When you see this pattern, probe deeper. Ask who was involved in the investigation. Ask what evidence was reviewed. Ask how the organisation verified that the root cause was correct before implementing the action.
Practical Tips for Auditors Reviewing Corrective Actions
When you are following up corrective actions, whether in an internal audit or an external one, a few practical habits will sharpen your evaluation.
- Read the original nonconformity report first. Understand exactly what was found and what clause was raised before looking at the corrective action response. This gives you a baseline to assess whether the response actually addresses the finding.
- Ask to see the investigation records, not just the summary. The corrective action form may state a root cause, but the investigation records will show whether the organisation actually did the work to get there.
- Sample for recurrence. If the corrective action was implemented three months ago, look for evidence that the problem has not recurred. Pull records from the period after implementation and check.
- Ask who owns the action. Corrective actions without a named owner and a due date tend not to get done. Verify that accountability was assigned.
- Check the management review inputs. Corrective action status should be a standing item in management review. If management has not been reviewing corrective action progress, that is itself a finding.
Linking Root Cause Analysis to Continual Improvement
Root cause analysis is not just about closing out nonconformities. Done well, it feeds directly into continual improvement. When you systematically identify the systemic causes behind recurring problems, you build a picture of where the management system has gaps. That picture informs priorities for improvement, training, process redesign, and resource allocation.
This is why the corrective action process sits in Clause 10 of all three major ISO standards, alongside continual improvement. The intent is that organisations learn from failures, not just fix them. An organisation that consistently produces shallow root cause analyses is not learning. It is cycling through the same problems indefinitely.
For internal auditors who want to add real value to their organisations, root cause analysis is one of the highest leverage skills you can develop. It is also one of the skills that separates competent auditors from those who simply check boxes.
If you want to build these skills in a structured way, Audit Workshop offers Internal Auditor and Lead Auditor training across ISO 9001, ISO 14001, and ISO 45001. The courses are built around practical audit scenarios, including corrective action evaluation and root cause investigation, so you can apply what you learn from the first audit you conduct after completing the training.
