I've sat on both sides of the audit table — walking auditors through my own corrective actions, and reviewing supplier CAPAs that made me wince. The pattern is always the same: corrective actions don't fail audits because the form was filled out wrong. They fail because the content can't survive five minutes of an auditor pulling on the thread. Learning how to write a corrective action that holds up isn't about better paperwork. It's about writing down a fix that actually connects to a cause.
Here's what that looks like in practice.
What auditors actually check
Whether it's a customer auditor, a registrar, or your own internal team, everyone reviewing a corrective action is walking the same five checkpoints:
- Is a root cause stated — and is it a real one? Not "operator error," not a restatement of the defect. A specific process condition, backed by an investigation they can read. This is where your 5 Why or other RCA gets attached — an audit-ready corrective action without an analysis behind it reads as a guess.
- Does the action address the cause, not the symptom? The auditor puts the root cause statement and the action side by side and checks that one removes the other. If the cause is a missing PM and the action is "increased inspection," they don't match, and the auditor knows it instantly.
- Is there an owner? A name — not a department. "Quality" owns nothing; a person with authority over the affected process owns something.
- Is there a due date — and was it met? Open corrective actions with due dates six months in the rearview are audit findings in themselves.
- Was effectiveness verified? Not "action complete" — did it work? Somebody checked, after enough time or volume, that the failure hasn't recurred and the new control is actually in use. This is the checkpoint most plants skip, and the first one experienced auditors go looking for.
Miss any one of the five and the corrective action is vulnerable. Miss two and it's a finding.
Weak vs strong: the same corrective action, rewritten
The fastest way to calibrate your writing is to see the same failure handled both ways. These are the patterns I've seen (and, early on, written) most often.
The retraining reflex
weak
"Root cause: operator did not follow work instruction. Corrective action: operator retrained on work instruction."
strong
"Root cause: work instruction requires a die-temperature check before first strike, but the pyrometer is mounted where the reading can't be seen from the press controls, so the check is routinely skipped during changeovers. Corrective action: relocate pyrometer display to the operator station and add die-temp confirmation to the changeover checklist; work instruction revised to Rev C. Owner: J. — cell lead. Due: 8/15. Effectiveness check: changeover audits for 60 days, zero skipped checks."
The weak version blames a person and prescribes a memory upgrade. The strong version explains why the instruction was being skipped, changes the condition that made skipping easy, and commits to a measurable check. Retraining is only a legitimate corrective action when the root cause is genuinely "this person was never trained" — and even then, the deeper cause is usually a broken training process.
The inspection band-aid
weak
"Root cause: defective parts shipped to customer. Corrective action: added 100% inspection before shipping."
strong
"Root cause: trim die clearance drifted out of spec because die wear is tracked by calendar time, not cycle count, and the affected die ran double volume last quarter. Corrective action: die maintenance interval converted to cycle-count basis in the CMMS; wear measurement added to die-change checklist. 100% inspection retained as containment until effectiveness is verified, then withdrawn. Owner: tooling supervisor. Due: 9/1."
Note what the strong version does with the inspection: it names it as containment, keeps it temporarily, and plans its removal. Auditors don't object to inspection — they object to inspection presented as the corrective action, because catching defects isn't preventing them. (The full distinction between correction, corrective, and preventive action is covered in RCA vs CAPA.)
The vague commitment
weak
"Corrective action: improve communication between shifts. Owner: production. Due: ongoing."
strong
"Corrective action: shift-handoff form revised to include open die-change status and any out-of-spec readings from the last four hours; handoff review added to shift-start meeting agenda. Owner: A. — production manager. Due: 8/1. Effectiveness check: handoff forms sampled weekly for one month; recurrence of handoff-related defects reviewed at 90 days."
"Improve," "reinforce," "emphasize," "ongoing" — an auditor reads these as "nothing specific will happen." If you can't say what physically changes on the floor, when, and who makes it happen, you don't have a corrective action yet. You have an intention.
Scope it honestly: one cause, one action
A subtler way corrective actions fail audits is scope creep in both directions. Too narrow, and the action fixes one die on one press while three sister dies carry the same wear-tracking gap — the auditor will ask "did you check the other presses?" and "no" is a bad answer with a name: you skipped the preventive-action question. Too broad, and the record turns into a five-item wish list — new software, a reorganized tool crib, a training overhaul — where nobody can say which item actually addressed the cause, half the items blow the due date, and the whole CAPA sits open for a year.
The discipline is one cause, one action that removes it, plus an explicit answer to "where else could this same cause bite us?" If the fix genuinely requires three changes, write three actions with three owners and three dates so each one can close on its own evidence. An auditor would rather see four small, closed, verified corrective actions than one sprawling epic that's 80% done forever.
The evidence trail
An audit-ready corrective action is a story with receipts. By the time it's closed, the record should contain, attached or referenced:
- The nonconformance that started it — NCR, customer complaint, or audit finding, with part numbers and dates.
- Containment records — what was quarantined, sorted, or recalled, and the disposition.
- The RCA itself — the why chain or fishbone, with the photos, readings, and work-order history that support each link, captured while the evidence was fresh.
- Proof of implementation — the revised work instruction with its revision number, the closed work order for the interlock install, the updated PM schedule. Documents an auditor can pull independently and find matching.
- Effectiveness evidence — the follow-up audit results, the scrap or defect data after the change, the tested interlock.
The standard I hold my own team to: a stranger should be able to reconstruct the whole event from the record alone, without hallway explanations. If closing the loop requires someone's memory, the record isn't done.
Closing the loop
The difference between "action complete" and "corrective action closed" is verification of effectiveness, and the difference matters. Complete means the work order was done. Closed means you waited — thirty, sixty, ninety days, or enough production volume to be meaningful — went back, and confirmed three things: the failure hasn't recurred, the new control is still being used (not quietly abandoned the week after the auditor left), and the fix didn't create a new problem somewhere downstream.
Put the verification date on the calendar the day you write the action, with a named owner. Corrective actions that rely on someone remembering to check back are corrective actions that never get verified — and an auditor who finds three unverified "closed" CAPAs stops trusting the whole system, which is when a records review becomes an excavation.
Write the cause honestly, fix the cause and not the symptom, name a person, set a date, and prove it worked. That's the entire trick. Everything else is formatting.
One more thing. The hardest part of a strong corrective action is the investigation underneath it. Root Cause AI walks your team through the root cause analysis conversationally at the machine, captures the evidence as you go, and hands you a structured, audit-ready record your corrective action can stand on.