CAPA Effectiveness Verification: How to Prove a Corrective Action Actually Worked
A corrective action that is implemented is not a corrective action that worked. The gap between those two statements is where most CAPAs die quietly. The team identifies a root cause, writes a permanent corrective action, implements it, collects three signatures, and closes the record. Nobody goes back to the floor sixty days later to confirm the defect stopped happening. Then it comes back, and the closed CAPA is worth less than the paper it printed on.
Effectiveness verification is the step that closes that gap. It is also the single most common place a CAPA gets graded down in an audit, because it is the one step that cannot be faked with a well-worded paragraph. You either have data showing the failure mode stopped, or you have a check box and a date.
This post is about how to do it properly: what the standards actually require, how to write acceptance criteria that mean something, how long to keep the record open, and what an auditor looks for when they decide whether your verification was real.
If you want the full closure walkthrough from defect to sign off, How to Close a CAPA So It Actually Stays Closed covers the end-to-end flow. This post zooms in on the verification step specifically.
What the Standard Actually Requires
The requirement is short and most people skim past it. ISO 9001:2015 clause 10.2.1 lists the steps an organization must take when a nonconformity occurs. Step (f) is the one that matters here: "review the effectiveness of any corrective action taken." AS9100D carries the same clause 10.2.1 wording verbatim, and IATF 16949 inherits it and then sharpens it through clause 10.2.3 on problem solving and the customer-specific requirements most OEMs layer on top.
Read step (f) carefully. It does not say implement the corrective action. That is step (d). Step (f) is a separate, later activity: a review of whether the action that was implemented actually removed the cause. The standard treats implementation and effectiveness as two different obligations on purpose, because an action can be fully implemented and still not work.
In 8D terms, the validation lives in D6, where you implement and validate the permanent corrective action, and gets locked at D7 when you confirm recurrence has been prevented. Teams routinely collapse D5, D6, and D7 into a single afternoon, which is exactly how an unvalidated action ends up marked complete. If your discipline organizes around the 8D rather than the bare ISO clause, the mapping between the two is worth getting straight, and 8D vs CAPA lays out where the response format and the management system diverge.
The practical reading of all of this: a CAPA is not eligible to close on the day the corrective action is implemented. It becomes eligible only after a defined observation window produces evidence that the failure mode did not return.
Why D7 Is Usually a Signature Instead of a Number
There is a structural reason effectiveness verification is weak almost everywhere, and it is not laziness.
The engineer who wrote the corrective action is usually the same engineer asked to verify it worked, on the same form, the same week the customer wants the 8D back. That is a conflict of interest baked into the process. The person most invested in the action being correct is the person grading whether it was. When the verification is a free-text field that says "corrective action confirmed effective" with a signature, you are reading the author's confidence, not evidence.
The second reason is timing. Real verification requires the process to run. If the failure mode shows up once every few thousand parts, a meaningful observation window might be three production runs or thirty production days. The 8D is due in ten. So the verification gets written before the data that would justify it exists, and the record closes on a prediction dressed up as a conclusion.
Both problems have the same fix: define the verification as objective acceptance criteria up front, attach it to data the production system generates on its own, and do not let the close happen until the criteria are met. The verification stops depending on who signs it.
Effectiveness Verification Criteria That Mean Something
Good acceptance criteria share three properties. They are quantitative, they are tied to the specific failure mode, and they are measured over a window long enough for the failure mode to recur if the fix did not hold.
A weak criterion looks like this: "Monitor the process to confirm the issue is resolved." There is no number, no window, and no threshold. It cannot pass or fail. It can only be asserted.
A strong set of criteria for a dimensional drift on a machined feature, for example, looks like four measurable conditions evaluated against the affected operation over a defined window:
- Recurrence of the failure mode: zero occurrences of the specific defect across the next three production runs of the part number. The CAPA stays open until that data exists.
- Process capability on the affected characteristic: Cpk at or above the customer requirement, commonly 1.33, across those same runs, using subgroup data pulled from the SPC log rather than a one-time capability study.
- Control input compliance: the process variable the root cause pointed to, recorded at the required frequency with zero out-of-limit readings over the window. If the root cause was coolant concentration, that means every shift reading logged and in spec.
- Training and document coverage: every operator on the affected machine signed off on the revised work instruction within the defined window, and the corrective action propagated into the control plan and PFMEA.
Each one is a number with a threshold and a deadline. Each one can fail. That is the point.
Two cautions on the capability criterion specifically. First, a capability number is only as trustworthy as the gauge that produced it. If your measurement system eats a large share of the tolerance, a Cpk of 1.33 might be measurement noise rather than process truth. Confirm the measurement system is capable before you lean on capability data as verification evidence; Gauge R&R Acceptance Criteria covers what %GRR and NDC have to clear first. Second, use the right index. A short verification window is closer to a Ppk situation than a long-term Cpk one, and conflating them inflates the number you report. Cpk vs Ppk explains which one belongs in a PPAP-grade verification.
How Long Do You Keep the CAPA Open
The honest answer is: long enough for the failure mode to have had a fair chance to come back, and not a day shorter because a due date arrived.
The observation window is a function of failure frequency, not the calendar. For a defect tied to a setup, the window has to span enough setups that a bad setup would have surfaced. For a defect that appears once per several thousand parts, the window has to cover enough volume that the rate would show. A common and defensible default in automotive supplier quality is three consecutive production runs of the affected part, which exercises the setup, the tooling, and the operator handoffs that the corrective action touched.
This collides with the reality that customers want the 8D closed fast. The way to satisfy both is to split the record cleanly. The interim containment and the implementation of the permanent corrective action can be reported and accepted quickly. The effectiveness verification stays open against its acceptance criteria, with a defined review date, until the data lands. The customer sees a corrective action in place; the CAPA system holds the close until the proof exists. Closing the verification early to hit a date is the precise move that produces the repeat 8D three months later.
The Verification Has to Reach the Cascade, Not Just the Symptom
A corrective action that fixes the symptom but never reaches the controlling documents is not effective, even if the symptom stops for a while. This is where verification and document control meet.
If the root cause was a missing reaction step in the control plan, the verification is not complete until the control plan carries that reaction step and the operators are working to the revised version. If the corrective action changed a torque value, the verification confirms the torque value moved in the work instruction, the setup sheet, the control plan reaction column, and that the PFMEA detection or occurrence rating was reassessed to reflect the new control. A change that lives only in a shared drive revision and never propagates is a finding waiting to happen, because the next audit will pull the controlled document and find the old value.
This is the difference between verifying that a defect stopped and verifying that the system that produced the defect was actually changed. The first can be luck. The second is the thing the standard is asking for when it says review effectiveness. A verification that checks recurrence but never confirms the cascade is half a verification.
What an Auditor Actually Checks
An auditor reviewing effectiveness verification is looking for a small, specific set of things, and they find the gaps fast.
- Is there objective evidence, or a signature? They will ask to see the data the verification relied on: the SPC records, the recurrence count, the inspection results across the window. A free-text confirmation with no attached data is the most common downgrade.
- Was the window real? They check the implementation date against the verification date. If the corrective action was implemented and the CAPA closed the same week, they know the verification could not have observed the process running. That timing alone is a finding.
- Did the verification match the failure mode? They confirm the data measures the specific defect, not a general "process looks fine." Verifying overall yield when the failure mode was a specific feature drift does not demonstrate the cause was removed.
- Did the corrective action reach the controlled documents? They pull the current control plan, work instruction, and PFMEA and check that the change is in the controlled version, not just described in the 8D.
- Who verified it, and could they? They look at whether the verification had any independence from the person who wrote the action, especially on higher-risk or repeat findings.
A verification survives all five checks when it is built from production data against criteria defined before the window opened. It fails when it was assembled after the fact to close a record that a due date demanded.
Where the Tooling Helps
The reason effectiveness verification degrades into a signature is almost always that the data lives in four systems and the person closing the CAPA does not have time to assemble it. The SPC log is in one place, the training records in another, the control plan revision in a third, the recurrence count in the engineer's memory. Pulling all of it together at close is real work, so it gets skipped.
The fix is to make the verification draw from the data the production system already holds and to refuse the close until the criteria are met. The Correct module runs the 5 Why, Fishbone, and Decision Tree analyses, links the corrective action to the affected control plan, PFMEA, and work instructions so the cascade is enforced rather than remembered, and holds the effectiveness verification against its acceptance criteria until the data clears. The capability and SPC evidence comes from the statistical tools rather than a separate study, so the Cpk number on the verification is the same number the process is actually running. For supplier-side corrective actions, the same discipline applies across the supplier quality workflow, where a verification that holds up is the difference between closing a SCAR and reopening it next quarter.
None of this removes the engineering judgment. It removes the excuse that the data was too scattered to verify properly.
The One Thing to Change This Week
If you do nothing else, stop writing the effectiveness verification as the last paragraph of the 8D on the day you implement the action. Write the acceptance criteria first, before the window opens, as numbers with thresholds and a review date. Then let the data decide whether the CAPA closes.
That single change moves the verification from an assertion to a measurement, and a measurement is the only thing that survives both the next production run and the next audit. A CAPA that closes on a number stays closed. A CAPA that closes on a signature closes twice.
