ISO 9001 corrective action: building an NCR/CAPA process that actually closes the loop

What clause 10.2 actually asks for

ISO 9001:2015 clause 10.2 (Nonconformity and corrective action) is short, but it packs in more steps than most registers actually complete. When a nonconformity occurs — a failed test, a customer complaint, an internal audit finding — the standard requires an organisation to:

1. React to the nonconformity: take action to control and correct it, and deal with the consequences.
2. Evaluate whether corrective action is needed to eliminate the cause, so it doesn't recur elsewhere or happen again.
3. Implement any action needed.
4. Review the effectiveness of the corrective action taken.
5. Update risks and opportunities determined during planning, if needed.
6. Make changes to the quality management system, if needed.

The two words that separate a real corrective action process from a glorified to-do list are containment and verification — the standard explicitly wants the immediate fix separated from the systemic fix, and it wants proof the systemic fix actually worked, not just a closed ticket.

Correction vs corrective action — the distinction that gets lost

These two terms are used precisely in the standard and casually everywhere else:

• Correction — the immediate fix. The failed batch is scrapped or reworked, the wrong part is replaced, the customer's shipment is corrected. This deals with the symptom, now.
• Corrective action — the fix that stops it happening again. This requires root cause analysis and addresses the underlying cause, not the individual failure.

A register that only logs correction ("reworked the batch, closed") technically responds to the nonconformity but does nothing clause 10.2 actually requires. The giveaway that a QMS is stuck at correction-only is a register where the same failure mode reappears every few months under a new NCR number — each one "resolved," none of them actually fixed at the cause.

Root cause analysis — proportionate, not theatrical

The standard doesn't mandate a specific method, and a full fishbone diagram for every minor nonconformity is overkill. A proportionate approach:

• Minor, low-risk, one-off nonconformities — a simple "5 Whys" run, recorded in a couple of sentences, is usually enough.
• Recurring, major, or safety-relevant nonconformities — justify a structured method (fishbone/Ishikawa, fault tree, or a formal 8D) and should involve more than one person, since a single investigator's first guess is often the symptom one level down, not the true cause.

Whichever method is used, the record should show the reasoning, not just the conclusion — "operator error" as a root cause is almost always incomplete; the useful question is why the error was possible (missing training, an ambiguous work instruction, a fixture that allows incorrect assembly) and what makes it structurally less likely to happen again.

Severity, escalation and KPIs

Not every nonconformity deserves the same process weight. A workable severity scheme:

A register that tracks these consistently earns useful KPIs for management review: open vs closed count, average time to close, percentage overdue, and — the metric that actually indicates whether the system is working — recurrence rate for the same failure mode. A falling recurrence rate is the only honest evidence that corrective action, not just correction, is happening.

Verification of effectiveness — the step everyone skips

This is where most NCR registers actually fail clause 10.2, even when every earlier step was done properly. Verification means checking, after enough time has passed for the fix to be tested by real production, that the failure mode has genuinely stopped — not just that the action item was completed. A corrective action "closed" the day the new work instruction was issued has verified nothing; the work instruction might not be followed, might not address the real cause, or might introduce a new problem. A credible process:

• Sets a verification date meaningfully after the action was implemented — enough production cycles to know if it worked.
• Requires a named person, ideally not the one who implemented the fix, to check and record the result.
• Only then allows the NCR to move to Closed — gating the status change on that verification note, not on the action being marked "done."

Software that lets a record move straight from "action implemented" to "closed" without forcing a separate verification step, dated after the fact, quietly removes the one part of clause 10.2 that actually distinguishes a real quality system from a paperwork exercise. Tools like InspectIQ gate close-out on that verification note being entered — the record simply can't reach Closed without it.

Linking NCRs to the rest of the QMS

A corrective action register earns its keep when it's connected to where nonconformities actually originate — raised directly from a failed inspection or test result rather than re-keyed from a separate spreadsheet, so the traceability from failure to root cause to fix is never broken by a copy-paste step. It should also feed management review: a Pareto of failure modes by product, process step and root cause category turns individual NCRs into a picture of where the process actually needs investment, rather than a pile of closed tickets nobody re-reads.

Common failures to avoid

1. Logging correction only, and calling it corrective action.
2. Root cause recorded as a symptom ("operator error", "material fault") with no "why" behind it.
3. Closing on action-completed rather than action-verified-effective.
4. No severity tiering — every NCR gets the same shallow (or the same excessive) treatment.
5. No recurrence tracking, so the same failure mode reappears under a fresh number every quarter and nobody notices the pattern.
6. Numbers that can be skipped or reused, so an auditor can't confirm the register is complete.

This guide is general information, not legal, tax or compliance advice. Rules change — always check the current official guidance for your situation.