Root cause analysis and corrective action is the loop that stops a problem from coming back. First contain the bad product and record the problem with measured facts. Then lay out possible causes, test them against data, and prove the root cause by showing you can turn the problem on and off. Fix that cause, plus the reason the problem escaped detection, and update the documents that control the process. Close the CAPA only when data collected after the fix shows the problem is gone.
Three words get mixed up all the time. A correction fixes the nonconforming item itself: rework the part, re-label the box, scrap the lot. A corrective action removes the cause of a nonconformity that has happened, so it does not happen again. A preventive action removes the cause of a problem that has not happened yet but could.
ISO 9001 clause 10.2, in paraphrase, asks you to react to the nonconformity, evaluate whether action is needed to remove its causes, find those causes, check whether similar problems exist or could occur elsewhere, act, review whether the action worked and update your risks and system as needed. The 2015 edition dropped the separate preventive action clause and handles prevention through risk-based planning instead. ISO 13485, which the FDA Quality Management System Regulation now incorporates by reference for medical devices, keeps separate corrective and preventive action requirements.
Most plants still call the whole loop CAPA. That is fine as long as your procedure separates the correction, which is urgent, from the corrective action, which needs analysis. The CAPA process guide goes deeper on running the system, and the NCR guide covers the nonconformance report that usually starts it.
Not every nonconformance needs a full corrective action. A single scratched part with an obvious one-off cause can be dispositioned on the NCR and trended. If you open a CAPA for everything, the system clogs and the important ones get the same thin treatment as the trivial ones.
Write triggers into your procedure. Common triggers are a repeat of the same defect within a set period, any customer complaint or returned product, anything touching safety or regulatory requirements, nonconformities found in internal or external audits, and failures above a cost threshold. A customer may also ask for a supplier corrective action request, which you answer with your own analysis on the SCAR template or an 8D report.
Planned, temporary departures from a requirement are a different thing. If you need to run product outside a requirement on purpose, use a deviation request form approved before the work starts, not a CAPA after the fact.
A weak problem statement produces a weak analysis. "Parts failing" gives the team nothing to test. A good statement names the part and feature, the requirement, the measured result, where and when it was found and how many are affected. The nonconformance report example shows the level of detail to aim for.
Add the is and is-not. Which machines, shifts, lots, operators and dates show the problem, and which comparable ones do not? If the defect shows up on press 2 but not press 1 running the same die, the cause is almost certainly in whatever differs between them. This simple comparison, popularized by Kepner and Tregoe, eliminates more candidate causes than any brainstorm.
The method is a tool for organizing evidence, not a form to fill in. Match it to the problem.
A root cause is only a hypothesis until you have tested it. The strongest proof is to turn the problem on and off: put the suspected cause back under controlled conditions and the defect returns, take it away and the defect goes. When that is not safe or affordable, look for converging evidence. The cause should explain every fact in the is and is-not, line up in time with when the problem started, and leave no fact unexplained.
Run two analyses. The occurrence cause explains why the defect was made. The escape or detection cause explains why it was not caught where it should have been. A plant that fixes only occurrence will meet the next unrelated defect with the same weak inspection.
Watch out for causes that are really symptoms or people. "Operator error" and "lack of training" almost never stand up. Ask why the process let the error happen and why it was not detected. Very often the honest answer is that the instruction was missing, unclear or wrong, a pattern explored in why NCRs trace back to poor work instructions.
Actions differ a lot in strength. From strongest to weakest, roughly: remove the cause by design, error-proof it so the mistake cannot be made, detect it automatically before the part leaves the station, add a standard and visual control, and finally train and remind. Retraining alone is the weakest action and should never be the only one when the cause is in the process.
Every action needs an owner and a date. Then update the system around it: the work instruction, the PFMEA ratings, the control plan, the gauge plan and the training records. If the change is not in the documents, it will fade within a few months as people rotate. Check whether the same cause could affect other parts, lines or sites, and extend the action there. ISO 9001 asks for this check explicitly.
Decide how you will judge success before you implement the fix. Write the measure (defect rate, complaint count, capability), the period or quantity, and the threshold. Then collect the data and compare. Agreeing the criterion up front stops the team from moving the goalposts later.
Make the period long enough to be meaningful. If the defect used to show up about once a week, two days without it proves nothing. A few production lots or a few weeks is typical, and for rare defects you may need longer or a stress test. Only when the criterion is met does the CAPA close, with the evidence attached. Repeats after closure are a signal that the root cause was not the real one, so reopen rather than start a new record.
Root cause and corrective action also feed the rest of the quality system: audit findings from your internal audit program become CAPAs, and CAPA trends belong in management review.
An auditor reading a CAPA months later should be able to follow the whole story without asking anyone. That means the record has to carry the evidence, not just the conclusions. Keep it in one place, whether that is a form, a database or a CAPA form template, and link the NCRs, complaints or audit findings that triggered it.
A CAPA system can fail even when each record looks fine. The usual signs are a growing backlog, actions that sit overdue for months, the same problem reopened under a new number, and root causes that all read "operator error". Watch a few simple measures each month: how many CAPAs are open, how many are past their due date, the average age of open ones, and how many problems came back after closure.
Review these numbers in management review alongside the CAPAs themselves. A rising repeat rate means the analysis is too shallow. A large backlog usually means the triggers are too broad, so too many minor issues become full CAPAs, or that owners lack the time and authority to finish them. Fix the system, not just the records.
Customers judge you on this too. A customer that issues a supplier corrective action request will look at how fast you contain, how well you prove the cause and whether the problem recurs. A clear record built on the steps above answers all three.
Example: Is / is-not narrowing the search (fictional stamping cell). Problem: burr height over 0.10 mm on bracket hole edges, found at assembly. Two presses run the same part with identical dies.
Result: The root cause is the resharpening procedure, which has no clearance check. The detection cause is that burr height is only checked at assembly. Actions: add a clearance check to the die maintenance instruction and a burr check to the first piece inspection.
Example: Effectiveness check with a pre-set criterion (same fictional cell). Criterion agreed before the fix: zero burr rejects in the next 3,000 brackets, and a defect rate below the pre-fix rate.
Result: The CAPA closes with the before and after data attached. The PFMEA occurrence rating for this failure mode is reviewed, and the PFMEA vs DFMEA guide explains where that update lives.
Root cause analysis is the investigation that finds why a problem happened. CAPA is the wider process around it: containment, analysis, action, documentation and an effectiveness check.
None is best for everything. Use 5 Whys for a single likely chain, a fishbone to lay out many causes, is / is-not to narrow the search, and 8D or A3 as the report format your customer or plant expects.
You can turn the problem on and off with it, it explains every fact in the is / is-not, and the problem stops after you remove it.
Long enough to implement the fix and collect effectiveness data. Set target dates in your procedure for each phase, but do not close before the data is in.
The 2015 edition has no separate preventive action clause. Prevention is handled through risk-based thinking and planning. ISO 13485 and the FDA QMSR still require preventive action for medical devices.
Only as part of a fix. If the cause is in the process, such as an unclear instruction or a missing error-proof, retraining alone will not stop recurrence.
COPLAIN AI PLATFORM
Upload your existing procedures and Coplain AI drafts audit-ready work instructions, job aids and forms from them.
Generate yours automatically with Coplain →