# A CAPA is not closed. It is evidenced. In most systems we open, "closing a CAPA" means: the announced action was carried out, somebody signed, the record moves to closed. **The regulation asks for one more step** — and it is the one that is almost always missing. Verify the effect ISO 13485 asks you to verify that the action produced the intended effect and did not degrade device conformity. 21 CFR 820.100 requires the action to be verified or validated before implementation. Both texts aim at the same thing. The four CAPA steps: the fourth, evidence of effect, is nearly always missing.1Cause2Need to act3Verify4Evidence effectThe step almost nobody completes. Converging requirements of ISO 13485:2016 and the US quality system regulation. A CAPA without evidence of effectiveness is an administrative record, not a corrective action. **And it shows: the recurrence indicator does not come down.** That is the most reliable symptom of a system handling its deviations on the surface — more reliable, in fact, than the share of CAPAs closed on time, which mainly measures your administrative discipline. "A good CAPA is one closed within the deadline." That is what your dashboard measures, so that is what your organisation optimises. The result is predictable: you pick the actions that close quickly. **Reinforce an instruction, add a double check, run the training again** — three actions that take a few weeks, document easily, and correct almost nothing. The cause is still there. ## Four requirements, in this order. ### 1\. Determine the cause Not "identify who is responsible". The cause is what, once removed, prevents recurrence. If the proposed action does not remove what you wrote in the root cause field, one of the two is wrong — and it is almost always the cause. ### 2\. Evaluate the need to act This step explicitly allows you **not to open a CAPA** when the risk does not warrant it. Most organisations skip it and open by reflex. They then end up with a portfolio of actions they have no means of running seriously. ### 3\. Verify before deploying The regulation asks you to make sure the action **does not degrade something else**. Adding an end-of-line control lengthens cycle time, shifts attention and sometimes manufactures the next error. This check is not a formality: it is the safeguard against stacking. ### 4\. Evidence the effect With a criterion set _before_ implementation and an observation window. "No recurrence observed" is not a criterion if nobody was watching. A properly built CAPA states at opening what it will have to demonstrate, and by when. ## An investigation that changes nothing is not an investigation. It is paperwork. And "human error" is not a root cause: it is an observation. The question that follows is always the same — **what, in the workstation, the procedure or the workload of that moment, made this error likely?** No regulatory text accepts stopping before that question. We are the ones who stop, because the answer costs more than a refresher course. ## Fewer CAPAs, and ones that really close. Recurrence It is the only indicator that judges the quality of your investigations. When it falls, the backlog stops rebuilding itself and the workload drops for good. Inspection The heaviest findings rarely concern an isolated deviation. They concern a failing investigation system — that is, a series of CAPAs closed without evidence. Workload Opening fewer CAPAs and running them properly takes fewer people than opening many and handling them superficially. The trade-off happens at step 2, and it is explicitly permitted. The turning point is nearly always the same: accepting that **some deviations call for no corrective action at all**, so that real time can go to the ones that do. That is a quality management decision, not a regulatory concession. ## Go further. [ ### Five whys are not enough Why the analysis stops too early. Read →](/en/blog/root-cause-5-whys-not-enough/)[ ### The backlog is a symptom More people is never enough. Read →](/en/blog/deviation-backlog-symptom/)[ ### ISO 13485 Evidence of effectiveness, not volume. Read →](/en/blog/iso-13485-what-it-asks-of-teams/) ## CAPA, plainly. Correction, corrective action, preventive action: what is the difference? + A correction deals with the observed effect — you withdraw the batch, you fix the entry. A corrective action deals with the cause of a deviation that occurred, so that it does not return. A preventive action deals with the cause of a deviation that has not occurred but could. Confusing correction with corrective action is the most common error: it produces closed records with nothing changed. Must every deviation lead to a CAPA? + No, and the regulation explicitly provides for the step of evaluating the need to act. Opening systematically dilutes the effort and produces an unmanageable portfolio. What must be systematic is the traced decision: why a CAPA here, and why not there. How do you define an effectiveness criterion? + In three elements, set at opening: an observable indicator, a target value, a time window. For instance: zero recurrence of this deviation over the next sixty batches, against a history of four in sixty. Without a baseline, no demonstration is possible. Can training be a corrective action? + Yes, on one condition: that the investigation demonstrated a competence gap, and not a design flaw in the workstation or the procedure. Retraining someone who already knew how corrects nothing, and the deviation will come back. It is the most frequent answer in the files, and the least often justified. ## How many of your closed CAPAs evidenced their effect? Give us your history. Two days is enough to measure the real recurrence rate and to name the causes that were never addressed.