How to create a CAPA process
How to design a CAPA process: separate correction from corrective action, gate full investigations on risk, require a verified root cause, and check effectiveness before closing.
A worked example, stage by stage
Log it, then contain it
Describe the problem with evidence, log it in the register, assess scope and grade the risk, then contain and correct. Containment is drawn as its own step so it cannot be mistaken for the fix — which is the most common way CAPA systems fool themselves.
The gate that keeps the process credible
"Full CAPA required?" routes low-impact issues to closure as correction only. Without this gate the queue fills with trivia and the serious investigations wait behind it. The grading criteria belong on the decision.
No cause, no action
Evidence collected, root cause determined, and an explicit decision that widens the investigation when the cause is not identified. Proceeding to actions without a verified cause is how organisations end up retraining people for a design defect.
Corrective, then preventive
A corrective plan, a preventive extension to similar processes, an approval gate for resources, implementation, then document updates and retraining. Preventive action asks where else this same cause exists, which is a narrower and more answerable question than it is usually given.
Verify before you close
Effectiveness checked after an agreed period, with failure routing back to root cause rather than to closure. A CAPA closed without an effectiveness check is an action item, not a corrective action.
How it works
Define what triggers a CAPA
Write down which sources feed it — nonconformities, complaints, audit findings, deviations, incidents — and what threshold each has to cross. A CAPA system fed by everything becomes a backlog, and one fed by nothing becomes a formality. Both are common and both are visible in the register.
Separate correction from corrective action in the record
Give containment and correction their own step and their own field. When they share a field with corrective action, the register cannot tell you how many issues were actually resolved at the cause, and neither can an auditor.
Grade the risk and gate the investigation
Write the grading criteria — impact, recurrence, detectability, regulatory exposure — and use them to decide what gets a full investigation. Put the criteria on the decision node so the routing is repeatable rather than dependent on who picks the record up.
Require a verified root cause
Make the root cause step a gate, not a field. If the cause is not identified, the process should widen the investigation rather than proceed. Actions written against an unverified cause are why retraining is the most common corrective action and why it so rarely works.
Make preventive action a specific question
Ask where else this same cause exists — which other lines, sites, products or processes share it — rather than asking what else might go wrong. The narrow version is answerable and produces real actions; the broad version produces a paragraph.
Set the effectiveness check when you set the action
Decide at planning time what evidence will show the action worked and after how long. Then hold the record open until that check happens, with failure routing back to the analysis. Closing on implementation rather than on effect is the single most common CAPA audit finding.
Frequently asked questions
What is the difference between corrective and preventive action?
Corrective action removes the cause of a problem that has occurred so it cannot recur. Preventive action addresses a cause that has not yet produced a problem here — typically the same cause found in another line, site or product. In practice most CAPA records are corrective, with preventive action being the deliberate step of asking where else this cause exists. ISO 9001:2015 dropped preventive action as a separate clause in favour of risk-based thinking, but the question remains worth asking explicitly.
What should trigger a CAPA?
Sources vary by sector, but typically: nonconformities and deviations, customer complaints above a severity, internal and external audit findings, out-of-specification results, and recurring incidents. What matters more than the list is the threshold on each source and the risk gate afterwards, because a CAPA process fed by every minor issue produces a queue in which the important records wait behind the trivial ones.
How do you verify CAPA effectiveness?
Decide the evidence and the period when you plan the action, not when you close it. Effectiveness evidence is usually a measure over time — the defect rate at the affected step, the recurrence count, an audit of the changed control — collected over enough cycles to be meaningful. Closing a CAPA when the action was implemented rather than when it demonstrably worked is the most frequently cited CAPA audit finding.
How long should a CAPA take to close?
The investigation and action planning are usually measured in weeks; the effectiveness check adds however long is needed for a real signal, which for a low-frequency defect may be months. That is why a good CAPA process tracks two dates: actions complete, and record closed. Compressing the second to meet a metric is how effectiveness checks become a formality.