The System
That Was Supposed to Prevent Everything
Corrective and Preventive Action — CAPA — is supposed to be the
beating heart of your quality management system. It is the mechanism by
which an organization learns from its failures and ensures they never
happen again. The concept is elegant in its simplicity: something goes
wrong, you investigate why, you fix the root cause, you verify the fix
worked, and you look for similar risks before they materialize.
Corrective deals with problems that already occurred. Preventive deals
with problems that haven’t happened yet but could. Together, they form a
closed loop of organizational learning.
The FDA considers CAPA so critical that it is consistently one of the
most cited areas in medical device inspections. ISO 9001:2015 devotes
significant attention to nonconformity and corrective action. IATF
16949, AS9100, ISO 13485 — every major quality standard demands a robust
CAPA system. The message is clear: if you cannot demonstrate systematic
problem elimination, you cannot demonstrate quality.
And yet, walk into most manufacturing organizations and ask to see
their CAPA system. What you will find is not a learning engine. You will
find a closure machine — a bureaucratic process optimized for one thing:
shutting open records as quickly as possible so the audit binder looks
clean.
What CAPA Was Designed to Do
A well-functioning CAPA system operates in five phases. First, you
identify a problem — through a complaint, an audit finding, a
nonconformance, a trend in data, or a near-miss report. Second, you
contain it — immediate actions to stop the bleeding, isolate affected
product, protect the customer. Third, you investigate root causes — not
the symptoms, not the convenient explanations, but the actual underlying
conditions that allowed the failure to occur. Fourth, you implement
corrective actions — process changes, training updates, design
modifications, or system improvements that address those root causes.
Fifth, you verify effectiveness — you confirm, with evidence, that the
actions actually worked and that the problem will not recur.
The preventive side follows the same logic but starts earlier.
Instead of waiting for a failure, you proactively analyze trends, review
risk assessments, monitor leading indicators, and identify potential
failure modes before they become real failures. You close the gap before
the gap causes harm.
The distinction between corrective and preventive is meaningful.
Corrective is reactive — something broke, fix it properly. Preventive is
proactive — something could break, strengthen it now. A mature quality
organization spends more effort on prevention than on correction. An
immature one doesn’t do prevention at all and calls its correction
“preventive” because it sounds better in the audit report.
What CAPA Has Actually
Become
Here is what happens in practice. An audit finding triggers a CAPA.
Or a customer complaint escalates to the point where someone decides a
CAPA is warranted. A quality engineer is assigned. They open a form in
the QMS software — TrackWise, MasterControl, Greenlight Guru, or
whatever system the company has invested in. The form has sections:
Problem Description, Containment Actions, Root Cause Investigation,
Corrective Action Plan, Preventive Action Plan, Effectiveness
Verification, Closure.
The engineer fills in the problem description by copying text from
the nonconformance report. Containment actions are listed — usually
“inspected remaining inventory” or “notified customer.” Then comes the
root cause section, and this is where the system begins to break
down.
Root cause investigation is hard. It requires going to the floor,
talking to operators, understanding the process, analyzing data, asking
uncomfortable questions. It takes time — sometimes days, sometimes
weeks. The quality engineer has eleven other CAPAs open, a production
line that needs support, and a manager asking why the closure rate is
below target this month. So the root cause becomes something plausible
and quick: “operator error” or “inadequate training” or “procedure not
followed.” These are not root causes. They are symptoms dressed up in
root cause language. But they are easy to document, easy to close, and
hard to challenge in an audit because they sound reasonable.
Corrective actions then follow logically from the fake root cause. If
the root cause was “operator error,” the corrective action is “retrained
the operator.” If it was “procedure not followed,” the corrective action
is “reissued the procedure with a cover letter emphasizing compliance.”
Training records are updated. Procedure revision numbers are
incremented. The CAPA moves to effectiveness verification.
Effectiveness verification is supposed to be the proof — data showing
the problem disappeared. But here is what actually happens: the engineer
waits three months (because the QMS template says “review after 90
days”), checks whether the same problem has been reported again in that
window, and if it hasn’t, marks the CAPA effective and closes it. This
is not verification. This is the absence of evidence being used as
evidence of absence. The problem may not have recurred because the
volume was low, or because a different shift was running, or because the
customer stopped reporting it, or because three months isn’t long enough
to see the pattern.
The CAPA is closed. The audit binder gains another green checkmark.
And six months later, the same problem surfaces in a slightly different
form — different product, different line, different customer — and
nobody connects it to the original CAPA because the root cause was never
actually identified the first time.
The Preventive Action Myth
If corrective action is often theater, preventive action is
frequently fiction. Most CAPA systems I have audited have a preventive
action section that is almost always one of three statements:
-
“Updated the risk assessment to reflect this failure mode.”
(Which means someone added a row to an FMEA spreadsheet and never
changed the process.) -
“Reviewed similar processes for comparable risks.” (Which means
someone thought about it for twenty minutes and concluded everything
else was fine.) -
“Enhanced training program to include this scenario.” (Which
means someone added a bullet point to a PowerPoint deck that operators
will click through without reading.)
Real preventive action means changing the system so that the
conditions that allowed the failure cannot exist anywhere else. It means
looking at the root cause — the real one — and asking: where else does
this condition exist? What other processes, products, or lines share the
same vulnerability? What systemic change would eliminate this class of
failure, not just this specific instance?
Almost nobody does this. Not because they can’t, but because the
system doesn’t reward it. The CAPA closure metric measures speed, not
depth. The audit measures whether the form is complete, not whether the
problem was actually solved. The organization tracks closure rates and
aging reports, not recurrence rates and systemic learning.
The Metric That Corrupted
the System
Every QMS dashboard I have ever seen tracks two CAPA metrics: number
of open CAPAs and average time to closure. These are the metrics that
get reported in monthly quality reviews. These are the numbers the
quality director is judged on. And these metrics have corrupted the
system.
When you measure closure speed, you create an incentive to close
CAPAs quickly. Quick closure is achieved by shallow investigation,
convenient root causes, easy corrective actions, and minimal
effectiveness verification. The system optimizes for what is measured —
and what is measured is not learning, not prevention, not problem
elimination. What is measured is paperwork throughput.
Meanwhile, the metric that actually matters — recurrence rate — is
almost never tracked. How often do the same root causes appear in
different CAPAs across different products and time periods? If your CAPA
system were working, your recurrence rate should trend toward zero. If
it is flat or rising, your CAPA system is a closure factory, not a
learning system. But almost no organization tracks this, because
tracking it would reveal that the emperor has no clothes.
I have seen organizations with hundreds of CAPAs closed per year,
boasting about their closure rates and audit readiness, while the same
five root causes appear in every single one of them. “Operator error” in
January. “Operator error” in March. “Operator error” in June. Different
products, different lines, different operators — same root cause, same
corrective action (“retrained the operator”), same closure. The system
is not learning. The system is transcribing.
The Five Failures That Break
CAPA
After twenty-five years of building and auditing quality systems, I
have identified five structural failures that turn CAPA from a learning
engine into a paperwork exercise:
Failure One: Conflating symptoms with root causes.
“The part was out of tolerance” is a symptom. “The operator didn’t
follow the procedure” is a symptom. “The fixture allowed misalignment”
is getting closer. The root cause is the answer to the question “why?”
that you cannot ask “why?” about again. Most CAPAs stop at the second or
third why and call it root cause. It isn’t.
Failure Two: Treating effectiveness verification as a
checkbox. Checking whether the problem recurred within ninety
days is not verification. Verification means defining what evidence
would prove the corrective action worked — reduced variation, eliminated
failure mode, improved process capability — and collecting that evidence
systematically. If you cannot articulate what “effective” looks like in
measurable terms before you implement the corrective action, you are not
verifying anything.
Failure Three: Isolating CAPAs instead of connecting
them. Every CAPA is treated as a standalone event. No one steps
back and asks: what pattern do these thirty CAPAs from the last year
reveal? Are we fighting the same root cause in different disguises?
Without cross-CAPA analysis, your system learns nothing from its
collective experience.
Failure Four: No distinction between correction and
corrective action. Correction is fixing the specific instance —
reworking the part, replacing the batch. Corrective action is
eliminating the cause so it doesn’t happen again. Too many CAPAs
document a correction and call it a corrective action. “We reinspected
the lot” is a correction. “We redesigned the fixture so the part cannot
be loaded backward” is a corrective action.
Failure Five: Prevention is optional because it’s
unmeasured. Preventive actions are the first thing cut when the
team is busy. They are the hardest to justify because they address
problems that haven’t happened yet. But they are also where the highest
value lives. A single preventive action that eliminates a class of
failure is worth ten corrective actions that address individual
instances.
What a Real CAPA System
Looks Like
A CAPA system that actually works looks fundamentally different from
what most organizations have. Here is what it requires:
Time and authority for investigation. Root cause
investigation is not a side task. It requires dedicated time, access to
the floor, authority to question processes, and the freedom to follow
evidence wherever it leads. If your quality engineer is simultaneously
supporting production, preparing for an audit, and closing five CAPAs,
the investigation will be shallow.
Cross-CAPA trend analysis. Someone — quality
manager, data analyst, or a designated CAPA board — should review all
closed CAPAs quarterly and look for patterns. Same root causes appearing
across different products. Same failure modes recurring in different
processes. This meta-analysis is where organizational learning actually
happens.
Recurrence tracking as a primary metric. Replace
closure rate with recurrence rate as the headline CAPA metric. If the
same root cause appears in a new CAPA within twelve months of a previous
closure, that is a failed CAPA — regardless of how beautifully the
paperwork was completed.
Effectiveness criteria defined before
implementation. Before you implement a corrective action,
define exactly what evidence will prove it worked. “No recurrence in
ninety days” is not effectiveness criteria. “Process capability index
improved from 0.8 to 1.33” is. “Defect rate dropped from 2.5% to below
0.1% and held for three months” is. Define the proof before you act.
Preventive action tied to risk, not to triggers.
Instead of waiting for failures and then asking “what else could fail,”
build preventive analysis into your periodic risk review. Use your FMEA,
your process hazard analysis, your customer feedback trends, and your
near-miss reports to identify preventive actions proactively. Prevention
should be continuous, not reactive to a specific CAPA trigger.
The Leadership Question
CAPA systems fail because leadership allows them to fail. Not through
malice — through benign neglect. When leadership reviews CAPA metrics,
they see closure rates and aging reports. They do not see recurrence
patterns or effectiveness evidence. They do not ask “are we learning?”
They ask “are we closing?” And the system responds accordingly.
If you are a quality leader, here is the question you should be
asking your team every month: how many of the root causes we identified
last year have appeared again this year? If the answer is more than
zero, your CAPA system is not working — no matter what the closure rate
says.
The goal of a CAPA system is not to close CAPAs. The goal is to make
CAPAs unnecessary. Every closed CAPA should represent a problem that has
been permanently eliminated from your organization. If you are opening
the same types of CAPAs year after year, you are not solving problems.
You are cataloging them.
The Bottom Line
CAPA is not a form. It is not a QMS workflow. It is not an audit
deliverable. CAPA is the institutional memory of your quality system —
the mechanism by which your organization accumulates learning,
eliminates failure modes, and builds the capability to prevent problems
before they occur.
If your CAPA system has become a closure factory — optimized for
speed, measured on throughput, and disconnected from actual problem
elimination — then you do not have a CAPA system. You have a
documentation process that consumes resources, generates records, and
creates the illusion of quality while the same problems continue to
occur in slightly different forms across slightly different
products.
The fix is not a new software system, a revised form, or a training
module. The fix is a fundamental shift in what you measure and what you
reward. Stop celebrating closure rates. Start celebrating elimination.
Stop asking “how fast did we close it?” Start asking “did the problem
actually go away — and how do we know?”
The organizations that answer those questions honestly are the ones
where CAPA works. The ones that don’t are the ones where it doesn’t. It
really is that simple.
Peter Stasko is a Quality Architect with over 25
years of experience building, auditing, and rescuing quality management
systems across automotive, aerospace, medical device, and electronics
manufacturing. He has led CAPA system implementations, conducted
hundreds of supplier audits, and helped organizations transform their
corrective action processes from paperwork exercises into genuine
engines of continuous improvement.
