A CAPA isn't finished when the fix ships

This blog has already covered what a complaint record has to decide before it becomes a CAPA, and what a CAPA tracker has to track once it does. Both essays stop at the point where a corrective action gets implemented. FDA's own regulation and the standard behind it don't stop there: both name a further step, checking whether the action actually worked, as its own distinct requirement — and a tracker that treats implementation as the finish line has closed the record one step early.

Two different verbs, two different clauses

21 CFR 820.100(a) lists what a manufacturer's corrective and preventive action procedures have to cover, and implementing the action is only one item on that list. Section 820.100(a)(4) separately requires verifying or validating the corrective and preventive action taken, to make sure it's actually effective and doesn't create some new adverse effect on the finished device. ISO 13485:2016's own Clause 8.5.2 runs the same structure for corrective action: identify the nonconformity, determine its cause, evaluate the need for action, take the action, and then review the effectiveness of the action that was taken — five distinct steps, with the review sitting last and separate from the action itself. A record that stops at “action taken” has completed four of the five things either the regulation or the standard actually asks for.

Preventive action's own check has less to measure against

Clause 8.5.3 asks the same review-of-effectiveness question about preventive action, and it's a harder one to answer well. A corrective action closes against a nonconformity that already happened, so its effectiveness check has a concrete before-and-after to compare — did the same failure recur. A preventive action closes against a nonconformity that hasn't happened yet, so there's no recurrence to watch for and no incident to compare against; the check has to rely on a leading indicator the team defines up front, like a trend line moving in the right direction over a set period, rather than a clean yes-or-no recurrence question. A preventive-action record that borrows the corrective action's own recurrence check as its effectiveness measure has picked a test that structurally can't answer the question it's supposed to.

Effective has to be defined before the action is taken, not after

An effectiveness check written after the fact tends to grade the action against whatever result actually happened, which makes almost any outcome look sufficient in hindsight. The more defensible order runs the other way: the CAPA record states, at the time the action is approved, what result would count as evidence the action worked — a specific metric, a specific threshold, and a specific date by which that evidence has to exist — before anyone knows how the action will actually perform. A field for “effectiveness criteria” that gets filled in on the same day as “effectiveness result” has answered a different, easier question than the one 820.100(a)(4) is actually asking.

A failed check reopens the same record, not a new one

Neither the regulation nor the standard treats the effectiveness check as a formality that a corrective action is presumed to pass. When the check comes back negative — the same failure recurs, or the trend line the preventive action was supposed to bend never moves — the honest path is back into the same CAPA record: a new root-cause pass, informed by the fact that the first action didn't work, not a fresh CAPA opened with no link back to the one that failed. A tracker that closes the original record regardless of the check's outcome, and opens an unrelated new number when the same problem resurfaces, has broken the very history a repeat failure is supposed to make visible.

Where this meets the file

A CAPA record built around this structure carries the effectiveness criteria and its due date as fields set at approval, not at closure; a distinct field for the preventive-action leading indicator where no recurrence event exists to check against; and a reopening path back into the same record on a failed check, rather than a disconnected new one. A tracker built around that structure, alongside the intake logic this blog has already covered, is previewed in the launch catalog. If your program measures effectiveness differently, the shelf takes that correction directly.