How to Write a BRCGS CAPA That Survives Scrutiny: Root Cause, Prevention and Verification

By Robert Low, Director, Lead Auditor & BRCGS Approved Trainer

Corrective and preventive action is where a quality system shows its real character. Auditors read CAPAs. Customers increasingly review them, and as I argued in my piece on grade demands, reviewing CAPA is exactly what customers should be doing instead of fixating on grades. So your CAPA needs to survive scrutiny from people who read hundreds of them. Here is how to write one that does.

Root Cause Analysis: Operator Error Is Not a Root Cause

Let me be blunt about this, because it is the single most common failure I see in CAPA records across every standard I audit and train. Operator error is not a root cause. Lack of training is not a root cause. They are symptoms, and writing them in the root cause box tells the reader you stopped asking why at the first convenient answer.

Think about what those phrases actually claim. Operator error says a human made a mistake, which humans reliably do, so the real question is why the system allowed one predictable human mistake to become a non-conformity. Was the work instruction ambiguous? Was the check impossible to do properly in the time allowed? Was there no error-proofing on a step everyone knew was error-prone? Lack of training is the same dodge one layer up: why was an untrained person on that task? What failed in the competency system that put them there? Keep asking why, five whys if it helps, a fishbone if the problem has multiple contributing arms, until you reach something about the system that you can actually change. Retrain the operator and the same finding comes back next year with a different name on it. I have seen it a hundred times.

Preventive Action Must Anchor to the Root Cause

The second failure follows from the first. Preventive action that does not connect to the root cause is decoration. If your root cause is an ambiguous work instruction, the preventive action is fixing the instruction and checking every similar instruction for the same ambiguity, not a toolbox talk. Corrective action deals with the immediate issue and the affected product. Preventive action attacks the root cause so the issue cannot recur, and it should read as the logical consequence of your analysis. If a stranger cannot draw a straight line from your root cause to your preventive action, one of them is wrong.

Then Verify: Think CAPAVA, Not CAPA

Corrective action, preventive action, verification of actions. I use the term CAPAVA with sites because the verification step is the one everyone skips, and it is the step that makes the whole exercise real. Weeks or months after implementation, go back and check with evidence: has the finding recurred, is the new control being followed, did the fix actually work? A CAPA closed on the day the action was completed is a promise. A CAPA verified three months later is a fact. Auditors and customer reviewers know the difference on sight.

I deliver root cause analysis training and CAPA system reviews remotely, and it is some of the highest-value work I do with sites. Buttons below if your CAPA log is full of operator error.