CAPA effectiveness

CAPA effectiveness is the planned, evidence-based check that proves a corrective or preventive action you implemented actually eliminated the cause it was designed to address — not just that you did the work, but that the work worked. It is the difference between 'we wrote a new SOP and trained eight people' and 'six months later the deviation has not recurred, the trend chart is flat, and an independent reviewer signed that off'.

Regulators do not treat effectiveness as a nice-to-have step at the end. It is the act that closes the regulatory cycle. 21 CFR 820.100(a)(4) names it directly: 'verifying or validating the corrective and preventive action to ensure that such action is effective and does not adversely affect the finished device.' ICH Q10 §3.2.2 frames it as the loop closer in the Pharmaceutical Quality System. ISO 13485 §8.5.2(f) and §8.5.3(f) require reviewing the effectiveness of any corrective or preventive action taken. ISO 9001 §10.2.1(e) is the same. EU GMP Chapter 1 lists CAPA effectiveness as a PQS element that must be reviewed at management review.

Year after year, CAPA is the single most-cited subsystem in FDA inspections, and within CAPA the most-cited individual failure mode is effectiveness. FDA's annual inspection observation summaries put CAPA in the top three for medical devices and top five for drugs every year between 2015 and 2024. The wording is consistent: 'failure to establish procedures for verifying that corrective and preventive action is effective', 'CAPA was closed without effectiveness check', 'effectiveness check was performed but criteria for success were not pre-defined', 'effectiveness check relied on the same data that triggered the CAPA'.

The reason is structural. Implementing a CAPA is satisfying — you write the SOP, you re-train the operators, you re-validate the equipment, you can declare the work done. Verifying effectiveness happens 30, 60, 90 days later, against criteria you should have agreed before the implementation. By the time the verification is due, the original problem may have receded from memory and the original team may have moved on. Without an operational forcing function — a scheduled task, an unmissable alert, a closure gate — the verification slips, the CAPA is closed administratively, and the next time the same defect recurs, the inspector pulls the original CAPA file and finds no effectiveness evidence.

Warning-letter reading reinforces this. The 'failure to verify effectiveness' citation almost always appears in clusters with 'repeat deviation' and 'inadequate root-cause analysis' — three symptoms of the same underlying disease, where the system implements actions without proving they fixed anything.

Effectiveness is one of the most universally-required steps in any QMS regime. The wording varies, but every framework names it explicitly.

Effectiveness is the last phase of a five-phase CAPA. Compressing it into 'we did the action' is the classic failure mode.

1. Identify — non-conformity, deviation, complaint, audit finding, trend signal, internal report.
2. Investigate — root cause analysis (5-whys, fishbone, fault tree, FMEA) reaching a stable underlying cause, not the proximate symptom.
3. Plan — corrective and/or preventive actions, with named owners, dates, risk classification, and (this is critical) the effectiveness-verification plan written and approved at the same time as the action plan.
4. Implement — execute the actions, capture evidence, run any required validation or re-training, close out interim controls.
5. Verify effectiveness — wait for the agreed observation window, gather the agreed evidence against the pre-agreed criteria, independent reviewer signs whether the action worked.

If the verification fails — if the original defect recurs, if the trend chart does not improve, if the audit finding repeats — the CAPA is reopened, root cause is revisited, and a new action plan is drafted. The CAPA does not 'fail closed'; it cycles. This is the loop ICH Q10 calls 'continual improvement of the PQS'.

21 CFR 820.100(a)(4) uses the phrase 'verifying or validating'. The two words are not interchangeable, and getting them right is one of the easiest scoring wins in an FDA inspection.

Verification is the lighter check: confirm that the action was performed as designed and that it produced the expected immediate effect. Re-trained operator? Confirm the training record exists, the operator's quiz score crossed the pass threshold, and the next batch they ran used the new procedure. Verification is appropriate for low-risk CAPAs and for the implementation step of any CAPA.

Validation is the heavier check: with statistical confidence over time, the underlying problem does not recur. The same retrained operator's last 20 batches show no recurrence of the deviation. The trend chart of the parameter that triggered the OOS is back inside Cp/Cpk 1.33 and stays there. Validation is required for any CAPA that changes a validated process, a critical control parameter, a software-controlled function, a sterilisation cycle, or any risk-control measure tied to patient safety.

The criteria must be defined and approved before implementation, not invented at the verification step. Inspectors routinely ask to see the approval timestamp on the effectiveness plan and compare it with the implementation timestamp; any criterion approved after implementation is suspect because it could have been reverse-engineered to a passing answer.

Good criteria share five properties.

• Specific to the root cause — not to the symptom. If the root cause was 'training material did not cover the contamination scenario', the criterion is about contamination-incident frequency, not about training-pass rates.
• Quantitative — a number, a count, a rate, a trend chart inside control limits. 'No further complaints' on its own is weak; 'zero complaints of subtype X over a 90-day observation window with batch volume ≥ 12 lots' is strong.
• Independent of the action — using the same data source that triggered the CAPA as the only effectiveness evidence is circular. Pull data from a different process step, a different batch, an independent audit, customer feedback.
• Time-boxed — observation window stated in days or production batches, with a defined start point after implementation completes.
• Pre-agreed pass/fail thresholds — what counts as success, what counts as failure, what counts as inconclusive (and triggers a longer observation window or supplementary evidence).

A workable template: 'Effectiveness will be evaluated 90 days after implementation completion, on at least 15 production lots. Pass criterion: zero recurrences of deviation code D-247 across those lots, and trend chart for parameter X remains within ±2σ of mean. Fail criterion: one or more recurrences, OR trend chart breaches ±3σ. Inconclusive (extend observation): <15 lots produced, OR data quality issues on the parameter monitor. Reviewer: QA Manager + Operations Director, two-person e-signature.'

Choosing the window is a risk-based decision. Too short and you cannot detect intermittent recurrences; too long and the CAPA stays open through audits and complicates trending. The standard heuristic is to scale window length to the original event's rate of occurrence.

Some events justify a permanent monitoring metric rather than a fixed window — for example, sterility-test failures or critical-supplier quality scores. In those cases the CAPA closes when initial verification passes, but the metric stays on the management-review dashboard indefinitely with a pre-agreed reopen trigger.

The evidence pack assembled for the effectiveness review should pull from at least two of these sources — drawing all evidence from one source is fragile and looks weak in audit.

• Process data — SPC charts, parameter trends from the historian, in-process control results across the observation window.
• QC data — release results, OOS rate, OOT rate, retest rate, on the product lines affected by the original event.
• Deviation / non-conformity data — recurrence count of the original event code; recurrence of related event codes that may indicate the root cause migrated.
• Complaint / market data — complaint rate for the affected product family, with categorisation against the original event symptom.
• Audit data — internal audit findings against the changed SOP / equipment / supplier; regulatory inspection observations if any occurred in the window.
• Training / operator data — proficiency assessments, on-the-floor observation reports, supervisor sign-offs.
• Supplier data — incoming inspection results, CoA accuracy, supplier scorecard movements (where the CAPA targeted supplier-driven causes).
• Customer / clinical data — for devices, post-market surveillance signals; for drugs, ADR rates against the relevant product.

The evidence pack is a controlled record. It carries the effectiveness criteria at the top, the raw evidence inline (or hyperlinked to the source system), the reviewer's interpretation, and the two-person sign-off at the bottom. It is attached to the CAPA record and surfaced in any inspection of that CAPA.

These are the wordings that actually appear in 483s and warning letters. Designing your CAPA system to make any of them impossible is the cheapest compliance investment you can make.

• 'CAPA was closed without an effectiveness check' — no record exists at all. Usually because the closure gate did not enforce one.
• 'Effectiveness criteria were not defined prior to implementation' — the criteria appear in the file but their approval date is after implementation. Audit trail catches this immediately.
• 'Effectiveness check relied on the same data that triggered the CAPA' — circular evidence. Reviewer should have insisted on independent data source.
• 'Effectiveness check was qualitative when the original event was a quantitative deviation' — 'no further issues observed' against an OOS that has numeric specs is not adequate.
• 'Effectiveness review was performed by the same person who implemented the CAPA' — fails the independence requirement that all major QMS regimes enforce.
• 'Observation window was insufficient given the rate of occurrence of the original event' — closing a CAPA on a monthly-recurring event after 30 days is the most-cited variant.
• 'Effectiveness check passed but the deviation recurred within 12 months' — the post-closure recurrence is itself the audit finding, and the inspector reads it as proof the original effectiveness check was not rigorous.
• 'No documented trigger for reopening if the underlying metric degrades' — the CAPA closed, the metric is no longer being watched, the next recurrence had no early warning.
• 'Repeat CAPA' — the same root cause has now triggered three CAPAs in two years; the issue is not the third CAPA, it is the absence of escalation when CAPA #2's effectiveness clearly failed.
• 'CAPA closure date precedes the end of the observation window' — administrative closure to clear an ageing list. One of the easiest things for inspectors to find via date arithmetic.

If the same root cause triggers a second CAPA within 12 months, you do not simply open a third CAPA. You escalate. Repeat CAPAs are themselves a quality signal, and your CAPA-management SOP should name the escalation path.

Industry standard escalation pattern:

1. Second CAPA on the same root cause within 12 months → automatic management-review item at the next quarterly review.
2. Third CAPA on the same root cause within 12 months → halt-production-area review by a cross-functional team including QA leadership, regulatory affairs and operations; output is either a fundamentally redesigned CAPA, a process-redesign change-control, or a permanent monitoring metric.
3. Repeat CAPAs spanning multiple sites or multiple product lines → corporate quality-council review; the issue is no longer local.

Counting repeats is non-trivial. The same surface symptom can have different root causes (which is not a repeat); different surface symptoms can have the same root cause (which is a repeat). The trend has to be measured by root-cause code, not symptom code, which is one of the reasons your root-cause taxonomy needs to be controlled and standardised across the QMS.

Both ISO 13485 §5.6.2 and ISO 9001 §9.3.2 list CAPA outputs as a mandatory management-review input. In practice, the metric that matters most is not 'how many CAPAs were closed' but 'what was the effectiveness pass rate, and how is it trending'. An organisation with high closure volume and a falling effectiveness rate is in worse shape than one with low closure volume and a stable high pass rate.

Management-review pack should report, at minimum: CAPA effectiveness pass rate (this quarter vs last four quarters); CAPAs failed at effectiveness review and the disposition of each; repeat-CAPA count by root-cause family; average observation-window length vs. average original-event recurrence interval; CAPAs ageing past their effectiveness-review due date.

The management-review minutes that record this discussion are themselves an inspectable record. An inspector reading them looks for the leadership team engaging with the trend, not just receiving the report. The minute 'CAPA effectiveness pass rate declined from 92% to 78% this quarter — actions: deep-dive at next review, interim escalation of all open repeat-CAPAs to QA Director' is what good looks like.

When effectiveness evidence is captured in a computerised system, the evidence inherits the full data-integrity obligation: ALCOA+ at the record level, audit trail on every change to the criteria or the verdict, two-person e-signature where the action being verified was itself two-person-signed, locked-after-approval state, retention aligned with the parent CAPA's retention requirement.

Two specific traps: (1) effectiveness verdicts entered as free text without controlled-vocabulary choices are fragile — the trending across CAPAs becomes hand-parsable only. Use a controlled list (pass / fail / inconclusive-extend / inconclusive-reopen-root-cause); (2) effectiveness criteria changed after the verdict has been entered must be impossible at system level — once a verdict is signed, the criteria are immutable. Both are direct Annex 11 §9 'audit trails' and §12.1 'data integrity' requirements.

For CAPAs that affect a computerised system itself (a software fix, a configuration change, a new validation), effectiveness verification overlaps with revalidation and must reference the validation package. Showing inspectors the validation re-execution evidence inside the CAPA file, not just a pointer to a separate validation library, materially shortens the conversation.

• CAPA effectiveness pass rate (target ≥85%) — overall and by originating subsystem (NCR, audit, complaint, deviation, trend).
• Average effectiveness verification cycle time — implementation-complete date to verification-signed date. Should match the planned observation window ±10%.
• Repeat-CAPA rate (target ≤10%) — CAPAs raised against a root cause that has already had a CAPA closed effectively in the prior 12 months.
• CAPAs ageing past effectiveness due date — should be near zero; non-zero indicates the closure gate is leaking.
• Time to escalation on repeat root cause — second occurrence should reach management review within one cycle.
• Effectiveness-fail to action-plan-v2 cycle time — when a CAPA fails effectiveness, how long to a revised action plan? Target ≤15 days.
• Independence rate on effectiveness reviews — % of reviews signed by someone who was not the CAPA owner. Target 100%.
• % of CAPAs with effectiveness criteria approved before implementation start — should be 100%; system enforcement closes any gap.

Effectiveness is built into the CAPA workflow as a hard closure gate, not a downstream checkbox. The capabilities, end to end:

• Effectiveness plan is a mandatory section of the CAPA record before implementation can begin — criteria, observation window, data sources, reviewer, are all required fields and audit-trail-locked once the implementation phase opens.
• Implementation completion does not close the CAPA — it opens the 'awaiting effectiveness review' state, with the verification due date computed from the observation window and surfaced on every owner's dashboard until cleared.
• Independent reviewer is enforced — the system blocks the same user from signing both implementation and effectiveness, and warns when the proposed reviewer is in the same reporting line as the owner.
• Evidence pack assembly: the system pulls candidate evidence (recurrence count from deviation log, trend chart from SPC, complaint count from complaint module, audit findings against the changed SOP) automatically based on the original event's classification, so the reviewer starts from data rather than a blank form.
• Verdict is a controlled-vocabulary choice (pass / fail / inconclusive-extend / inconclusive-reopen-root-cause), and the criteria become immutable on first verdict signature — auditable at Annex 11 §9 level.
• Repeat-root-cause detection: when a CAPA is opened against a root-cause code that has a closed-effective CAPA in the trailing 12 months, the new CAPA is auto-flagged as 'repeat candidate' and the management-review queue gains an item.
• Management-review dashboard ships pre-built with the eight metrics above, with one-click drill-down to the underlying CAPAs.
• Post-closure monitoring: for CAPAs that defined a permanent monitoring metric, the metric persists on the dashboard with a pre-agreed reopen trigger; breach of the trigger opens a draft CAPA citing the original.
• All of the above runs under audit-trail-compliant, two-person-e-signature, Part 11 / Annex 11 controls — no separate compliance bolt-on.