What a CAPA tracker has to track — and what most logs skip

As of February 2026, the requirement most people still call “CAPA” runs through ISO 13485:2016, incorporated by reference into 21 CFR 820 under FDA's Quality Management System Regulation. The standard's clause 8.5.2 covers corrective action; 8.5.3 covers preventive action. They're adjacent in the standard and adjacent in most people's thinking, which is exactly why trackers routinely collapse them into one undifferentiated bucket — and lose the distinction that made the two-clause structure useful in the first place.

Corrective and preventive are not one bucket

Clause 8.5.2 responds to a nonconformity that already happened — a complaint, a failed test, an audit finding. Clause 8.5.3 responds to a potential nonconformity — a trend, a near-miss, a risk signal, where nothing has gone wrong yet. A tracker that files both under a single “CAPA” row type can't answer a question every competent auditor eventually asks: show me your preventive actions, separately from your corrective ones. If the log can't separate them, the team probably isn't running preventive action as its own discipline — it's running reactive correction and calling some of it preventive after the fact.

The root-cause field is where trackers lie to themselves

“Operator retrained” and “human error” are two of the most common entries in a root-cause column, and neither is a root cause — they're containment, restated. A retrained operator working under the same unclear work instruction will make the same mistake again; the instruction was the cause, the person was the mechanism. The same rule that makes a checklist item trustworthy applies here: one row, one verifiable claim, tied to something that can actually be fixed. If the fix in the “action taken” column wouldn't have prevented the specific failure described in the root-cause column, the root cause is wrong, not the action.

Verification of effectiveness is the column that closes the loop

Completing an action is not the same as verifying it worked, and a tracker that treats “action taken” as the closing event is recording activity, not effectiveness. A working verification-of-effectiveness field needs three things decided in advance, not filled in retroactively: the method (a re-audit, a retest, a recheck of the trend that triggered the record), a date far enough past the action for that trend to actually show something, and a place to record what was found — not a checkbox agreeing the fix seems fine. An empty or perfunctory VOE field is the single most common way a CAPA log understates its own risk.

Aging that means something

A tracker's overdue calculation should start from the trigger — the complaint date, the finding date — not from whenever someone got around to opening the record, or the aging column quietly rewards slow intake. Corrective and preventive actions also age on different clocks: corrective actions typically carry a bounded closure target set by the quality system's own procedures, while preventive actions usually don't have a forcing deadline at all — they need a standing review cadence instead, commonly a recurring management-review agenda item, so they don't just sit open indefinitely for lack of a due date to miss.

None of this is exotic; it's the difference between a log that records that work happened and one that can prove a problem is actually gone. A CAPA tracker built to this structure is in the launch catalog now in preview. If your team has learned the hard way what a tracker needs that this one is still missing, the shelf takes that kind of correction directly.