CAPA Action Plan Troubleshooting: Causes, Tests and Fixes

 

Feature image: the seven steps of a CAPA and where each commonly breaks. Conceptual illustration, not a regulatory flow chart.

A CAPA action plan is the part of a corrective and preventive action (CAPA) record that says what will be done, by whom, by when, and how you will know it worked. It is also the part that fails most often. Records get opened, actions get assigned and closed on schedule, and the same problem comes back at the next audit, the next batch or the next shutdown. The NSF white paper on why CAPA keeps failing puts it plainly: the issue is not a lack of CAPA activity, it is a lack of CAPA effectiveness (NSF).

This guide shows how to troubleshoot a CAPA action plan that is not working, or that you suspect will not work: the causes that show up in the sources, the tests that expose each one, and the fixes. It is written for engineers, quality staff and plant teams who raise, review or approve CAPAs in regulated and non-regulated manufacturing. It covers the problem statement, the difference between correction and corrective action, root cause, scope, action strength, plan completeness, effectiveness checks and metrics, and it includes an animation, two calculations for sizing an effectiveness check, and a short Python script.

What you will be able to do after reading

• Say what a complete CAPA action plan contains and test a draft plan against eight questions.
• Separate a correction from a corrective action and a corrective action from a preventive action.
• Recognise the signs that root cause analysis stopped too early, including "human error" and retraining as the answer.
• Rank proposed actions by strength and spot a plan that relies on the weakest ones.
• Design an effectiveness check with a predefined criterion, enough data and a long enough window, and calculate how much data a zero-failure check needs.
• Fix the metrics and deadlines that reward fast closure instead of lasting results.

About the numbers. Definitions, regulatory text and failure patterns come from the cited sources and are labelled SOURCE. The monthly recurrence counts, the quarterly metrics and the audit of 25 actions are ILLUSTRATIVE and are not company data. The sample sizes and probabilities are CALCULATED with standard statistics and my own arithmetic, with the equations shown; they are not from a source and are not regulatory requirements. This article is general education, not legal or regulatory advice.

Table of contents

1. The short answer: a CAPA plan works when it removes the cause and proves it
2. Where the requirements come from, and what changed in 2026
3. Symptoms: how to tell a CAPA plan is failing
4. See it: the animation of a failed CAPA and an effective one
5. Cause 1: the problem statement does not define the problem
6. Cause 2: a correction is closed as a corrective action
7. Cause 3: root cause analysis stopped at the first plausible answer
8. Cause 4: the scope is too narrow
9. Cause 5: the actions are weak
10. Cause 6: the plan is incomplete or not controlled
11. Cause 7: no one proves it worked
12. Cause 8: the metrics, deadlines and culture reward closing, not fixing
13. Eight tests to run on a draft CAPA plan
14. Worked example: rewriting a plan for the resin pipe failure
15. A short script for sizing an effectiveness check
16. Records, links and management review
17. Prevention: building CAPA plans that survive review
18. Common mistakes
19. Safety notes and limitations
20. Frequently asked questions
21. Conclusion: what to do with the next CAPA plan
22. Related reading on this site
23. Sources and further reading

The short answer: a CAPA plan works when it removes the cause and proves it

Across the sources the same chain keeps appearing. A CAPA fails when the problem is not defined well enough to investigate, when the investigation stops at the first plausible cause, when the actions treat the symptom or rely on people remembering, when no one defines success in advance, and when the record is closed on implementation instead of on evidence. Ideagen puts the last point sharply: closing an action when the measure has been implemented, instead of when it has been verified as effective, is structurally equivalent to not completing the process, because the record looks closed while the risk remains open (Ideagen).

Table 1. Weak versus strong plan elements (SOURCE: NSF, Ideagen, Atlas Compliance, Avendium; author synthesis)

Plan element	Weak version	Strong version
Problem statement	Copies the audit observation or says "defect found"	What happened, when, how often, under what conditions, and what good looks like (NSF)
Containment and correction	Fixes the one unit or record that was found	Contains affected product or work, and is labelled as a correction, separate from the corrective action
Root cause	"Human error" or the first plausible cause	A cause that explains the frequency, variability and conditions, tested against the data
Corrective action	"Retrain staff" or "review procedure"	A specific change that removes or blocks the cause, with a named owner and a date (Ideagen)
Preventive action	Not considered	Asks where else the same cause could act and extends the fix there
Effectiveness check	"Monitor for recurrence"	A predefined success criterion, a data source, a time window and a reviewer
Closure	When the action is done	When the criterion is met, and the record shows the evidence

Rule of thumb. If the plan would still make sense after you replace the problem with a different one, it is not a plan. A real action plan names a mechanism, and the mechanism is why it should work for this problem and not for others.

Where the requirements come from, and what changed in 2026

CAPA is a core requirement in quality management systems for regulated industries. Ideagen names ISO 9001, GMP frameworks, 21 CFR Part 820 and most other quality management standards (Ideagen). A QMII article places the ISO 9001 requirement in Clause 10.2 (QMII), and a Scilife article cites ISO 13485 Clauses 8.5.2 and 8.5.3 (Scilife). I have not read the ISO standards, so treat the clause numbers as secondary-source citations and check the standard.

The US medical device change

For US medical devices there is a recent change that affects every older training deck. The FDA states that the Quality Management System Regulation (QMSR) became effective on February 2, 2026, amending 21 CFR Part 820 and incorporating ISO 13485:2016 by reference (FDA, QMSR). The current Part 820 text in the eCFR contains the scope, definitions, incorporation by reference, the requirement to document a quality management system that complies with ISO 13485, supplemental record controls and labeling and packaging controls, and it has no separate CAPA section (eCFR, 21 CFR Part 820). OpenRegulatory says most of the detailed process requirements now come from ISO 13485, not from the old Quality System Regulation subparts (OpenRegulatory). An SGS summary adds that the FDA stopped using the old inspection technique on the effective date and that inspectors can now review records they previously could not, including management reviews, internal audits and supplier audits (SGS).

The old 21 CFR 820.100 text is still the clearest checklist of what a CAPA procedure must cover, and many quality systems still follow it. Table 2 lists its seven elements as they appeared in the pre-QMSR regulation and in an FDA training presentation (21 CFR 820.100, pre-QMSR text, FDA, CAPA basics). Use it as a tool for thinking, and check the current requirements that apply to you.

Table 2. The seven elements of the legacy CAPA requirement (SOURCE: 21 CFR 820.100 pre-QMSR text and FDA CAPA basics presentation; legacy, check current rules)

Legacy element (820.100(a))	What it asked for	What to ask of your plan
(1)	Analyse sources of quality data to find existing and potential causes; use appropriate statistical methods to detect recurring problems	Did the CAPA come from trended data, and is the recurrence real?
(2)	Investigate the cause of nonconformities in product, processes and the quality system	Is the root cause supported by evidence?
(3)	Identify the actions needed to correct and prevent recurrence	Do the actions address the cause, not the symptom?
(4)	Verify or validate the action to ensure it is effective and does not adversely affect the finished device	Is there an effectiveness check and a side-effect check?
(5)	Implement and record changes in methods and procedures	Are the document and process changes controlled?
(6)	Disseminate information to those responsible for quality of the product or prevention of the problem	Did the people who need to know, know?
(7)	Submit relevant information for management review	Is management seeing the right data?

Two points from the FDA presentation are worth keeping because they are about proportion. The preamble says the degree of corrective and preventive action must be appropriate to the magnitude of the problem and commensurate with the risks encountered, and it says preventive as well as corrective action must be verified or validated. It also gives an example of when a process nonconformity needs investigating: if a molding process with a known normal rejection rate of 5 percent rises to 10 percent, an investigation must be performed (FDA, CAPA basics).

Correction, corrective action and preventive action

The FDA presentation quotes the ISO 9000 definitions. A correction is action to eliminate a detected nonconformity, for example rework or regrade. A corrective action is action to eliminate the cause of a detected nonconformity and is taken to prevent recurrence. A preventive action is action to eliminate the cause of a potential nonconformity and is taken to prevent occurrence. There is a difference between a correction and a corrective action, and there can be more than one cause for a nonconformity (FDA, CAPA basics). The Scilife article cites ISO 13485 Clauses 8.5.2 and 8.5.3 for these requirements, and I did not read the standard to confirm which clause covers which (Scilife).

Limitation. I did not read ISO 13485 or the FDA inspection manual. The regulatory summary here comes from the FDA QMSR page, the eCFR Part 820 text, a pre-QMSR FDA presentation and secondary sources, and it covers US medical devices only. Drug, food, aerospace, automotive and other sectors have their own rules. Confirm what applies to you with your regulatory or quality function.

Symptoms: how to tell a CAPA plan is failing

Pharma.Tips lists the signals on the floor of an ineffective CAPA system: repeated deviations, prolonged investigation times, frequent recurrence of similar quality issues across batches or lines, low effectiveness metrics and regulatory citations (Pharma.Tips). Atlas Compliance lists the findings that regulators commonly cite: procedures without enough detail on investigations and effectiveness checks, investigations that stop at human error or operator training, narrow scope, no objective evidence that actions were effective, and backlog and poor trending that hide recurring problems (Atlas Compliance). The table pairs each symptom with the test that locates the cause.

Table 3. Symptom to cause to test (SOURCE-informed: Pharma.Tips, Atlas Compliance, NSF, Ideagen; author synthesis)

Symptom	Likely failure	Test that finds it	First fix
The same problem returns after closure	Root cause missed, or action weak, or effect wore off	Compare the recurrence data with the root cause; was the criterion met over a long enough window?	Reopen; retest the cause; strengthen the action
A repeat CAPA on the same subject within a year	Correction treated as corrective action	Ask why the failure happened, not just what failed	Link records; investigate the cause of the failure
Many actions are retraining, reminders or procedure edits	Symptom-level actions	Action strength ladder and audit (Tables 8 and 9)	Replace with design, error-proofing or detection where possible
Root cause reads "human error" or "operator did not follow"	Investigation stopped early	Ask why the error was possible, why it was not prevented and why it was not detected	Investigate the system conditions behind the error
Problem statement copies the audit finding	The finding describes evidence, not cause	Does it say what, when, how often, where, what good looks like?	Rewrite and approve before root cause analysis
Closure dates are met but recurrence is not falling	Metrics reward speed	Compare on-time closure with the repeat rate	Add recurrence and effectiveness metrics
Effectiveness check says "monitor"	No success criterion	Is there a number, a data source, a window and a reviewer?	Define them before approval
The fix works at one site and the problem appears at another	Scope too narrow	Where else could the same cause act?	Extend the investigation and the action
Actions are overdue or reassigned repeatedly	No owner, no resources or unrealistic dates	Plan completeness test	Name an owner, protect time, set risk-based dates

See it: the animation of a failed CAPA and an effective one

The animation shows monthly recurrences of one problem over 36 months. The counts are ILLUSTRATIVE and hand-set so the story can be reproduced from the table below. A retraining and procedure-reminder CAPA closes on time at month 12 and passes a 3-month check, then the effect wears off. A second CAPA that removes the cause by design change brings the rate down and keeps it there.

V01 (animated GIF): the same problem under a retraining-only CAPA and then a design-level CAPA. ILLUSTRATIVE monthly counts, not company data.

The GIF contains no script and works anywhere an image does. Table 4 lists the numbers behind each scene.

Table 4. Monthly recurrences in the animation (ILLUSTRATIVE counts, CALCULATED means)

Scene	Period	Events	Mean per month	What happened
1	Months 1 to 12	38	3.17	Baseline, before any CAPA
2	Months 13 to 15	2	0.67	CAPA 1 (retraining) closed on time; a 3-month check looks like a pass
3	Months 16 to 24	27	3.00	The effect wears off; recurrence is back at baseline
3 (whole year)	Months 13 to 24	29	2.42	Only a 24 % reduction over the whole year
4	Months 25 to 36	3	0.25	CAPA 2 (design change); 92 % below baseline

What the animation teaches

• A good first quarter proves little. The first 3 months after CAPA 1 showed 79 % fewer events than baseline (2 against about 10 expected). A 3-month check would have called it a pass.
• The dip was real, and it was temporary. If nothing had changed, at most 2 events in 3 months would occur with probability about 0.6 % (CALCULATED, Poisson, mean 3 per month). So the retraining did something. What it did not do was remove the cause, and the effect decayed within the year.
• The window has to cover the way the failure shows up. A check should run long enough to include the decay of reminder effects, seasonal factors and the usual interval between occurrences.
• A design-level action changed the baseline. After CAPA 2 the mean fell to 0.25 per month and stayed there over 12 months.

Limitation. The counts are not data from any company. They illustrate how a short effectiveness window can mislead. Real data have noise, trends and changing production volumes, and the check should be normalised for volume.

Cause 1: the problem statement does not define the problem

NSF finds that the most common failure point is the investigation itself, and it starts earlier than the investigation: problem statements are vague or incomplete, and audit observations are copied straight into the CAPA record and treated as the problem even though they describe evidence, not cause. When the problem is poorly defined, root cause analysis becomes guesswork and the corrective actions address symptoms (NSF). Qualityze names vague CAPA descriptions, and unrelated issues grouped under one record, as the first of its reasons CAPA plans fail, and suggests the SMART framework (specific, measurable, achievable, relevant, time-bound) for describing the problem and actions (Qualityze).

The test

NSF says a strong problem statement describes what happened, when it occurred, how often it occurred and under what conditions, and defines what good looks like. Without a defined success state, investigations drift: teams collect data without direction, debate causes without alignment and cannot tell when analysis is complete. It recommends that the problem statement be reviewed and approved before root cause analysis begins (NSF).

Table 5. Rewriting a problem statement (ILLUSTRATIVE examples)

Weak problem statement	Stronger problem statement (ILLUSTRATIVE)
Seal leak found on line 3	Between March and May, 11 of 480 sealed units (2.3 percent) on line 3 leaked at the end-of-line test, up from a stable 0.4 percent. Leaks occur on the second shift only and on three of five tool cavities. Good is 0.5 percent or less over a rolling month.
Audit finding: training records incomplete	In 6 of 20 sampled files for the filling area, the signed training record for the current procedure revision was missing at the time of the task. The same gap was found in 2 of 20 files for packaging. Good is 20 of 20.
Customer complaint: contamination	Four complaints in 8 weeks report dark particles in lot family A. All four lots were filled on mixer 2 within 10 days of a gasket replacement. No complaints on lots from mixer 1.

Quick test. If two investigators could read the statement and look for different problems, it is not ready. If it does not say how you will know when it is solved, it is not ready.

Cause 2: a correction is closed as a corrective action

NSF calls confusing correction with corrective action a common CAPA failure and gives an example. A manufacturer found water contamination in resin caused by a hole in a pipe. The pipe was replaced and the CAPA was closed. The investigation stopped early because no one asked why the hole formed in the first place: material selection, installation stress, cleaning chemicals, maintenance practices? Replacing the pipe was a correction. Understanding why the pipe failed and preventing similar failures was the corrective action (NSF).

Avendium lists the same confusion in its six CAPA mistakes in FDA Form 483 responses. Corrections include completing a missing review, retraining one employee, replacing a damaged component, revising one record or repeating a test. A corrective action addresses the cause so that it does not recur. It suggests separating a response into immediate corrections and containment, product-impact or patient-risk assessment, investigation and root cause, corrective actions, preventive or systemic actions and effectiveness verification (Avendium). That structure protects the current operation while the underlying weakness is addressed.

Table 6. Five layers of a response (SOURCE: NSF, Avendium, FDA CAPA basics; author synthesis)

Layer	Question it answers	Example (resin pipe, from NSF)
Correction	What do we do about this unit, batch or record now?	Replace the pipe; assess and handle the affected resin
Containment	How do we stop more affected product or work reaching the next stage?	Hold or inspect affected lots; check similar pipes
Corrective action	What removes the cause so it does not recur?	Whatever the investigation finds behind the hole: material, installation, chemicals, maintenance
Preventive action	Where else could the same cause act?	Review other lines and sites for the same pipe, service and failure mode
Effectiveness check	How do we know the cause is gone?	No recurrence of pipe failures in the defined window; inspection results; measured condition

Cause 3: root cause analysis stopped at the first plausible answer

Scilife reports that in a survey of more than 300 QA professionals in the life sciences industry, the most commonly cited CAPA issue was poor root cause analysis (Scilife). It is a vendor survey, so treat the ranking as indicative. The other sources agree on the pattern. QMII says that when corrective actions are only retraining, procedure updates, reminders or more inspections, skilled auditors suspect the real cause has not been identified (QMII). Atlas Compliance says investigations stop at the immediate cause (an operator, a machine setting) rather than the system cause: process design, maintenance, qualification, supplier controls or change control (Atlas Compliance).

"Human error" is where analysis starts

Avendium points out that human error describes what happened and rarely explains why the quality system allowed it. An employee may have missed a step because the procedure was unclear, the form did not prompt it, training was ineffective, workload or staffing was inadequate, the software allowed an inappropriate action, supervisory review failed, similar errors were not trended or management had accepted a workaround. It suggests asking why the error was possible, why it was not prevented, why it was not detected earlier, whether similar errors occurred and what management or quality-system controls failed (Avendium). The same source notes that, as it reports it, a March 2026 FDA draft guidance for drug CGMP inspections cautions that addressing only the most obvious causal factor is often insufficient. I did not read that guidance.

The test: does the cause explain the pattern?

NSF gives a sharp test. In an injector pen investigation an engineer attributed high push force to a spring, which seemed reasonable until variability was examined: only 25 percent of devices showed the issue, and the assumed cause could not explain that distribution. The investigation advanced when the team combined "why" with "how" analysis and questioned its assumptions. NSF advises explicitly testing whether proposed causes explain all observed behaviour, including frequency, variability and conditions of occurrence (NSF).

• Frequency. If the cause were true, how often would the failure occur? Does that match what you saw?
• Variability. Why some units, shifts, lines or lots and not others?
• Conditions. What was different when it happened? If you cannot say, you have not found the cause.
• Timing. When did it start, and what changed shortly before?
• Reversibility. If you remove the cause, can you predict the failure would stop? If you reintroduce it, would it come back?

The tools matter less than the thinking. NSF warns that teams apply tools mechanically: the "five whys" is limited to what the team already knows and stops when an answer needs knowledge outside the group. Oversimplified tools encourage a single cause chosen because it fits the timeline, not because it explains the behaviour (NSF). Structured tools help: fishbone (Ishikawa) diagrams, 5 whys and failure mode and effects analysis are the ones named by Qualityze, and Pharma.Tips organises causes into the six categories of materials, method, machine, man, measurement and environment (Qualityze, Pharma.Tips). NSF also recommends observation of the process, equipment set-up and operator behaviour, which reveals variation that documents cannot (NSF).

Practical tip. Give the high-risk investigations a facilitator and protected time. NSF notes that CAPA teams are rarely dedicated investigators and are expected to complete complex analyses under tight deadlines, so the result is a shallow investigation by necessity (NSF).

Cause 4: the scope is too narrow

Avendium lists treating an observation as an isolated incident as the first CAPA mistake. An incomplete cleaning record, for example, could indicate problems with the cleaning procedure, training, supervisory review, record design, quality-unit oversight, similar equipment or areas, or data-integrity controls. Correcting only the cited example does not establish that the organisation understands the full scope. It recommends determining where the same or a similar failure could have occurred across related products, processes, departments, records, facilities, equipment and suppliers, and explaining how the scope was set (Avendium). The FDA presentation says the same in older words: the procedures must provide for action on devices distributed and those not yet distributed that are suspected of having potential nonconformities (FDA, CAPA basics).

Table 7. Scope questions (SOURCE-informed: Avendium, FDA CAPA basics; author synthesis)

Scope question	Examples
Where else is the same product, material or design used?	Other lots, other product families, other customers
Where else is the same process or equipment used?	Other lines, other shifts, other sites, contract manufacturers
Where else does the same procedure, form or training apply?	Other departments with the same document
Where else could the same cause act in the past?	Look-back at records, complaints, audit findings
Which suppliers contribute?	Incoming material, calibration, outsourced steps

Cause 5: the actions are weak

QMII lists the typical quick-fix responses: retraining employees, updating procedures, reminding staff to follow the process and increasing inspections. They may appear reasonable but rarely remove the reason the problem occurred. If a procedure was unclear, retraining will not help unless the procedure is corrected, and reminding operators to be more careful does not fix inconsistent calibration (QMII). Avendium says retraining may be appropriate as an interim action but is rarely sufficient where the underlying issue is an inadequate process, an unclear procedure, poor system design or ineffective oversight (Avendium).

A ladder of action strength

Safety engineering has long ranked controls from eliminating a hazard to relying on people. The same idea helps with CAPA actions. The ladder below is my own synthesis for review purposes. It is not a standard, and a strong action is not always possible or cost-justified, but a plan whose actions all sit on the bottom two rungs deserves a second look.

Table 8. Action strength ladder (author synthesis, not a standard)

Rung (strongest first)	What it does	Example
Eliminate or redesign	Removes the cause	Change the design so the wrong assembly is impossible
Replace or substitute	Swaps the cause for a lower-risk alternative	Different material, supplier or method
Error-proof or automate	Makes the error hard or impossible to make	Fixture that blocks the wrong orientation; system-enforced step
Detect or interlock	Catches the failure before it escapes	Automated check, interlock, hold point
Procedure change	Changes what people are told to do	Revised work instruction
Training or reminder	Relies on memory and attention	Retraining, toolbox talk, signage

Table 9. An audit of 25 actions from 10 CAPAs (ILLUSTRATIVE counts, CALCULATED share)

Rung	Actions in the illustrative audit
Eliminate or redesign	3
Replace or substitute	2
Error-proof or automate	4
Detect or interlock	3
Procedure change	6
Training or reminder	7
Total	25
Procedure change plus training or reminder	13 (52 %)

In this made-up audit, 13 of 25 actions (52 %) are procedure changes or training. That is not automatically wrong: some causes really are unclear procedures or missing skills. It is a prompt to ask of each such action whether the root cause analysis really ends at a person or a document, and whether a stronger action is possible.

Cause 6: the plan is incomplete or not controlled

Ideagen says a corrective action should be specific, assigned to a named owner and time-bound, and that vague actions such as "retrain staff" or "review procedure" are themselves a common audit finding. It adds that when a CAPA shows a procedure was unclear or not fit for purpose, the action should trigger a document review and update, and that where CAPA is siloed from document control the link breaks (Ideagen). Scilife says action plans should be clear and concise with specific details on the problem, the corrective action, the person responsible and the timeline (Scilife).

Table 10. A complete action row (SOURCE-informed: Ideagen, Scilife, FDA CAPA basics; author synthesis)

Field	What a complete plan says	Common gap
Action	One verb, one object, one deliverable	"Review", "improve", "ensure"
Owner	A named person with authority and time	A department or "QA"
Due date	Dated, with a reason, risk-based	A default 30 or 45 days
Dependencies	Change control, validation, supplier, training, tooling	Not listed, so the date slips
Controlled documents	Which documents, forms and systems change	CAPA siloed from document control
Side-effect check	What could this action break?	Not asked (legacy requirement: does not adversely affect the finished device)
Effectiveness check	Criterion, data source, window, reviewer, date	"Monitor"
Evidence	Where the proof will be stored	Statements without records

Avendium adds a point about commitments: statements like "the procedure has been revised" or "employees have been retrained" are weak without supporting evidence, and a response that cannot show the revised document or the training records does not demonstrate the action was done (Avendium).

Cause 7: no one proves it worked

The legacy requirement was to verify or validate the corrective and preventive action to ensure that it is effective and does not adversely affect the finished device, and the preamble extended this to preventive actions (FDA, CAPA basics). Ideagen says verification requires defined criteria for success and a defined review point, not just closing the action when implementation is complete (Ideagen). Scilife ranks insufficient follow-up on effectiveness second among the problems reported in its survey, after poor root cause analysis (Scilife). Atlas Compliance lists the regulator view: actions that are implemented but not measured, with no objective evidence that they worked (Atlas Compliance).

Four decisions to make before the plan is approved

• Criterion. A number and a direction, linked to the problem statement: for example a defect rate at or below 0.5 percent over a rolling month, or no recurrence in a stated period, or a measured parameter inside a limit.
• Data. Which system, which records, normalised for volume, collected by whom.
• Window. How long and how much data, chosen from how the failure appears and how often it occurred at baseline (see the two calculations below).
• Reviewer and date. A named person, ideally not the action owner, with a date to review and the authority to reopen.

Verification and effectiveness are different questions

Verification asks whether the action was implemented as designed: the document was revised and released, the fixture was installed, the setting was changed. Effectiveness asks whether the problem went away. Both are needed. A plan that stops at verification closes records while the risk stays open. A plan that jumps to effectiveness without verification cannot tell whether a lack of recurrence came from the action.

Calculation 1: how much data does a zero-failure check need?

Suppose the problem was a defect with a baseline rate of 2 % (ILLUSTRATIVE). You want to show that the rate is now at or below a target p with confidence C, using a check that ends with zero failures. If the true rate were exactly p, the chance of seeing zero failures in n independent units is (1 - p) to the power n. Setting that chance to 1 - C gives the sample size. This is the standard success-run argument and an approximation for a constant, independent failure rate. It is general statistics, not a source and not a regulatory requirement.

n = ln(1 - C) / ln(1 - p)

Quick rule (rule of three, C = 95 %): n is about 3 / p

Table 11. Sample size for a zero-failure effectiveness check (CALCULATED, standard statistics)

Target rate p (at or below)	Units with zero failures (C = 95 %)	Rule of three (3 / p)
2.0 %	149	150
1.0 %	299	300
0.5 %	598	600

The other side of the coin is what a small check can and cannot show. If the fix did nothing and the rate is still 2 %, the chance of seeing no failures in 30 units is 0.98 to the power 30, about 54.5 % (CALCULATED). In 100 units it is about 13.3 %. A short, clean run can happen by luck, so a small check should not be treated as proof. Choose the size from the risk, and for severe consequences use stronger evidence than a small count.

Calculation 2: how long a quiet period proves anything?

Now suppose the problem shows up as events with a baseline mean of 3 per month (ILLUSTRATIVE). If the number of events in a month follows a Poisson distribution with mean m, the chance of a month with none is e to the power minus m, and of k consecutive months with none is e to the power minus m times k. Table 12 compares what a quiet period looks like when the fix did nothing against when it cut the rate in half.

P(no events in k months) = exp(-rate x k)

No effect: rate = 3.0 per month; halved: rate = 1.5 per month

Table 12. How surprising a quiet period is (CALCULATED, Poisson model, ILLUSTRATIVE baseline of 3 events per month)

Quiet period	Chance if the fix did nothing	Chance if the rate was halved
1 month	5.0 %	22.3 %
3 months	0.012 %	1.11 %
6 months	about 2e-08	0.012 %

One quiet month happens about 1 time in 20 with no change at all, and about 1 time in 4.5 even when the rate was only halved, so it cannot tell a good fix from a poor one. Six quiet months at a baseline of 3 per month would be overwhelming evidence that the rate fell. Rare problems need a different design. If the baseline is a few events per year, a count over a few months proves nothing, and the check should rely on direct verification of the mechanism, inspection or measurement of a parameter that predicts the failure, or a longer and repeated review.

Limitation. Both calculations assume independent events and a constant rate. Real processes drift, have batch effects and change with volume. Use them to see how much evidence a check can give, then consult a statistician for high-risk decisions.

Cause 8: the metrics, deadlines and culture reward closing, not fixing

NSF observes that many organisations assess CAPA performance almost entirely through timelines for managing the record, so on-time closure becomes the primary indicator. Teams focus on meeting deadlines instead of resolving the problem, and if recurrence rates, systemic impact and risk reduction are not tracked, the system incentivises the wrong behaviour (NSF). QMII describes the same pressure from the audit side: findings are measured by how quickly they close (QMII).

Table 13. On-time closure versus results (ILLUSTRATIVE counts, CALCULATED percentages)

Metric (ILLUSTRATIVE quarter)	Value	What it hides or shows
CAPAs closed	40	Activity
Closed on time	36 (90 %)	Looks healthy
Repeats of an earlier CAPA	12 (30 %)	Nearly a third of the work was repeat work
Closed with a predefined effectiveness criterion	14 (35 %)	Most closures cannot prove anything

Fixed deadlines

NSF says many organisations impose fixed CAPA timelines, often 30 or 45 days, regardless of complexity. Complex problems need observation, data collection and iteration, and when time is constrained teams default to the simplest explanation that fits the schedule. It recommends differentiating timeline expectations by risk and complexity and allowing justified extensions (NSF). Table 14 is an illustration of a risk-based approach, not a regulatory requirement.

Table 14. Risk-based investigation targets (ILLUSTRATIVE, not a requirement)

Risk tier (ILLUSTRATIVE)	Investigation target (days)	Notes
Low	30	Often handled by a preliminary investigation and a simple action
Medium	45	Cross-functional team; justified extension allowed
High	90	Dedicated investigator or facilitator; interim containment from day one; justified extension allowed

Containment should not wait for the investigation. Pharma.Tips recommends containment actions in the first hour of a signal: isolate affected batches, gather the logs and records, notify the relevant functions and do a quick risk assessment (Pharma.Tips).

Culture and risk

• Probability is not severity. NSF warns that reducing probability does not reduce severity, and that effectiveness assessments should consider both where required (NSF).
• Challenge is part of the job. NSF reports that strong CAPA outcomes are consistently associated with respectful cross-functional communication and psychological safety, and that teams that avoid disagreement or rush to closure signal deeper cultural constraints (NSF).
• Train on real CAPAs. NSF recommends masterclass-style sessions in which existing CAPAs are reviewed, problem statements rewritten and investigation logic challenged (NSF).
• Not every issue is a CAPA. Preliminary investigation before opening a CAPA can save effort and raise quality (NSF).

Eight tests to run on a draft CAPA plan

The tests below turn the causes into pass or fail questions you can apply in a review meeting. They are my synthesis from the sources, not a standard. V02 summarises them with the action-strength audit and the effectiveness sample sizes.

V02: eight tests to run on a draft CAPA plan, an action-strength audit and the sample size for an effectiveness check. A heuristic plus ILLUSTRATIVE and CALCULATED numbers, not a standard.

Table 15. Eight tests for a CAPA action plan (author synthesis from the sources)

Test	Pass when	Fail means
1. Problem statement	States what, when, how often, where and what good looks like; approved before root cause work	Vague or copied finding; investigation will drift
2. Correction versus corrective action	The immediate fix and the cause fix are separate items	Correction closed as corrective action
3. Causal chain	The cause explains frequency, variability and conditions, and is supported by data or observation	Plausible cause not tested; human error accepted
4. Scope	Where else the cause could act has been assessed and documented	Only the cited example fixed
5. Action strength	At least one action removes or blocks the cause, or a reason is given why not	Plan is all retraining and reminders
6. Plan completeness	Each action has an owner, date, deliverable, dependencies and controlled-document links	Vague verbs, no owner or date
7. Side effects	Possible adverse effects have been considered and checked	Action could cause a new problem unnoticed
8. Effectiveness	Criterion, data, window and reviewer defined before approval, with enough data to mean something	Closure on implementation

Worked example: rewriting a plan for the resin pipe failure

NSF's resin example stops at the lesson. To show what a rewrite looks like, I extend it with an ILLUSTRATIVE investigation result. Suppose the investigation finds that the failed section is a plastic pipe in a line that is washed with a chemical that attacks the pipe material, that the section was installed under bending stress, and that 13 other sections on the site have the same material, the same cleaning chemical and the same installation. None of this is from the source; it is an invented continuation for teaching.

Table 16. Weak versus strong plan for the same failure (ILLUSTRATIVE, extending the NSF example)

Element	Weak plan	Strong plan (ILLUSTRATIVE)
Problem statement	Water found in resin	Resin lot R-214 contained water above the limit; traced to a hole in pipe section P-7. One event, but the same pipe, service and cleaning method exist at 14 sections. Good is no wall failure in any of the 14 over 12 months.
Correction	Replace the pipe; close the CAPA	Replace the pipe; quarantine and test the affected lots; check the other 13 sections now (containment)
Root cause	Pipe defect	Cleaning chemical incompatible with the pipe material, accelerated by installation stress; supported by the failure surface, the cleaning records and the sections inspected
Corrective action	Retrain maintenance on pipe inspection	Replace the cleaning chemical or the pipe material at all 14 sections; revise the installation method to remove bending stress; change control for both
Preventive action	None	Add a material compatibility check to the cleaning-agent change procedure; review other lines for the same pairing
Owner and date	Maintenance, 30 days	Named engineer for materials, named supervisor for installation; dates by risk, with the high-risk sections first
Effectiveness check	Monitor	Inspection of wall condition at 3, 6 and 12 months; no wall failure at any of the 14 sections over 12 months; independent review by quality at each point
Closure	When the pipe is replaced	When the 12-month criterion is met and the evidence is filed

A short script for sizing an effectiveness check

The two calculations above fit in a few lines of Python. It is an ILLUSTRATIVE aid, and it uses the same assumptions: independent events and a constant rate. It is not a validated tool and it does not replace a statistician for high-risk decisions.

import math

 

def zero_failure_units(p_target, confidence=0.95):

"""Units with zero failures needed to show a rate at or below p_target."""

return math.ceil(math.log(1 - confidence) / math.log(1 - p_target))

 

def p_quiet(rate_per_month, months):

"""Chance of no events in the window, Poisson model."""

return math.exp(-rate_per_month * months)

 

print(zero_failure_units(0.005)) # 598

print(round(0.98 ** 30, 3)) # 0.545: clean run of 30 at a 2 percent rate

print(round(p_quiet(3.0, 1), 4)) # 0.0498

print(round(p_quiet(1.5, 3), 4)) # 0.0111

Run on the illustrative inputs, it returns 598 units for a 0.5 percent target, 54.5 percent for a clean run of 30 units at a 2 percent rate, 4.98 percent for a quiet month at 3 events per month and 1.11 percent for three quiet months at 1.5 per month, matching Tables 11 and 12.

Records, links and management review

The legacy requirement was that all CAPA activities and their results be documented, and the FDA presentation notes that manufacturers must make this information readily available to an investigator (FDA, CAPA basics). Qualityze names poor documentation as a failure cause and recommends a centralised, version-controlled system (Qualityze).

Table 17. CAPA record set (author synthesis; legacy requirement text and Qualityze)

Record	What it should show
Problem statement and approval	What the problem is and who agreed
Containment and correction log	What was done now, to which product or records
Investigation file	Data, observations, hypotheses tested, the evidence for the cause and for the causes ruled out
Scope assessment	Where else it could occur and what was checked
Action plan	Actions, owners, dates, dependencies, side-effect check
Change records	Document changes, validations, training linked to the actions
Effectiveness plan and results	Criterion, data, window, reviewer, the results and the decision
Management review input	Trends, repeats, overdue actions, effectiveness results

Prevention: building CAPA plans that survive review

• Require an approved problem statement before root cause work starts (NSF).
• Use a plan template with the eight tests built in, and make the effectiveness criterion a required field.
• Trend data so recurring problems are found early; the legacy requirement called for appropriate statistical methods to detect recurring quality problems (FDA, CAPA basics).
• Report recurrence, repeats and effectiveness alongside on-time closure.
• Link CAPA to document control, change control, training and risk management.
• Review closed CAPAs after a set period to confirm the problem stayed solved.
• Train investigators on real records and give high-risk investigations time and facilitation (NSF).

Common mistakes

Table 18. Common mistakes (author synthesis of the sources)

Mistake	Why it hurts	Better practice
Copying the audit finding into the problem statement	It describes evidence, not cause	Write what, when, how often, conditions and success state
Replacing the part and closing	A correction does not remove the cause	Ask why it failed
Accepting human error	It rarely explains why the system allowed it	Investigate the conditions behind the error
Retraining as the main action	Relies on memory; wears off	Prefer design, error-proofing and detection
Fixing only the cited example	The same cause acts elsewhere	Assess scope and extend the action
Setting no criterion	Success cannot be shown	Define criterion, data, window and reviewer first
Using a short clean period as proof	It can happen by luck	Size the check from the baseline rate
Closing on implementation	Risk stays open	Close on evidence of effectiveness
Measuring only on-time closure	Rewards speed, not results	Track recurrence and repeats
Making commitments without records	Cannot be demonstrated	File the revised document, training and change records

Safety notes and limitations

• Not legal or regulatory advice. This is general education. The regulatory summary covers US medical devices and comes from the FDA QMSR page, the eCFR Part 820 text, a pre-QMSR FDA presentation and secondary sources. Other sectors have other rules. Confirm with your regulatory or quality function.
• Standards not accessed. I did not read ISO 9001, ISO 13485, ISO 9000 or the FDA inspection manual. Clause numbers are quoted only as cited by secondary sources.
• Source authority. Apart from the FDA and eCFR pages, the sources are consultancies, software vendors and training providers, several of which sell CAPA software or services. Survey results (for example the Scilife survey) are vendor surveys. Failure patterns are consistent across sources but are not measurements of frequency.
• Reported guidance. A March 2026 FDA draft guidance is mentioned only as reported by Avendium, and I did not read it.
• Illustrative numbers. Monthly counts, the quarterly metrics, the 25-action audit, the risk tiers and the resin example continuation are invented for teaching. The sample-size and probability calculations are standard statistics with stated assumptions.
• Safety and quality. Where a CAPA concerns patient or worker safety, follow your safety and regulatory procedures, including any reporting obligations, without waiting for the CAPA to finish.
• Visuals. The images are conceptual or illustrative and should be reviewed by a qualified quality professional before being used in training or procedures.

Frequently asked questions

What is a CAPA action plan?

A CAPA action plan is the part of a corrective and preventive action record that states what will be done to remove the cause of a problem, who owns each action, when it is due, which documents or systems change, and how effectiveness will be checked. A complete plan also separates the immediate correction from the corrective action and considers where else the same cause could act.

What is the difference between correction, corrective action and preventive action?

A correction eliminates a detected nonconformity, for example rework of a unit. A corrective action eliminates the cause of a detected nonconformity to prevent recurrence. A preventive action eliminates the cause of a potential nonconformity to prevent occurrence. The FDA training presentation quotes these ISO 9000 definitions and stresses that a correction and a corrective action are not the same thing.

Why do CAPA plans fail?

The cited sources most often name vague problem statements, root cause analysis that stops at the first plausible cause or at human error, actions that rely on retraining and reminders, no success criterion, closure on implementation instead of on effectiveness, narrow scope, and metrics that reward on-time closure instead of fewer repeats.

Is retraining a valid corrective action?

Sometimes, but rarely on its own. Retraining fits when the root cause is a real skills or knowledge gap. If the cause is an unclear procedure, a poor design, workload or a system that allows the error, retraining does not remove it. The sources describe retraining as an acceptable interim step but rarely sufficient, and the illustrative animation shows a retraining-only CAPA whose effect wore off.

How long should an effectiveness check run?

Long enough to cover how the failure actually shows up, including the decay of reminder effects, seasonal factors and the usual interval between occurrences, and defined before the plan is approved. In the illustrative example a 3-month check looked like a pass but the problem returned within the year. With a baseline of 3 events a month, zero events over 6 months would be very strong evidence of improvement, while one quiet month would not.

How many units do I need to show a defect has been fixed?

If you plan to show that a defect rate is at or below a target with 95 percent confidence using a zero-failure check, the success-run calculation gives about 149 units for 2 percent, 299 for 1 percent and 598 for 0.5 percent, assuming independent units and a constant rate. This is general statistics, not a regulatory requirement, and some situations need a different design.

Does 21 CFR 820.100 still exist for medical devices?

The FDA says the Quality Management System Regulation became effective on February 2, 2026 and incorporates ISO 13485:2016 by reference. The current Part 820 text in the eCFR has no separate corrective and preventive action section. The legacy 820.100 text is still useful as a checklist, but you should confirm current requirements with your regulatory function.

Should every problem become a CAPA?

Not necessarily. NSF notes that not every issue warrants a full CAPA, that early exploration may show a problem is isolated or already understood, and that preliminary investigation can improve CAPA quality by letting only issues that need full analysis enter the system. Define when a preliminary investigation is appropriate and how it is documented.

Which CAPA metrics should I track?

Track results as well as timeliness: the recurrence rate of closed problems, repeat CAPAs on the same subject, the share of CAPAs with a predefined effectiveness criterion, the share that passed the check at first review, the mix of action strengths, and the age of open CAPAs by risk. In the illustrative quarter 90 percent of CAPAs closed on time while 30 percent were repeats of earlier ones, which on-time closure alone would never show.

Conclusion: what to do with the next CAPA plan

A CAPA action plan fails when it is a description of activity instead of a claim about a cause. To troubleshoot one, work along the chain: is the problem defined, is the correction separate from the corrective action, does the cause explain the pattern, has the scope been tested, is at least one action strong, is the plan complete and controlled, and is there a criterion, enough data and a window that can show it worked. The animation showed what happens when those last checks are weak: a plan that closed on time, passed a short check and failed within the year.

For your next CAPA, run the eight tests in the review meeting, size the effectiveness check before approval with the two calculations, report recurrence and repeats next to on-time closure, and keep the evidence in one place. Download the images, step through the animation against Table 4, and try the script with your own baseline rate.

Related reading on this site

• How to troubleshoot control valve hunting: causes, tests and solutions
• How to troubleshoot loop check vs function test: causes, tests and solutions
• How to troubleshoot proof test interval and PFDavg: causes, tests and solutions
• Root cause analysis for engineers: 5 whys, fishbone and fault tree compared

Sources and further reading

• U.S. FDA, Quality Management System Regulation (QMSR) (regulator page)
• eCFR, 21 CFR Part 820, Quality Management System Regulation (current regulation text)
• U.S. FDA CDRH, Corrective and Preventive Action Basics (Nov 2014 presentation, pre-QMSR) and 21 CFR 820.100, pre-QMSR text (LII)
• NSF, Why CAPA Keeps Failing and What Strong Organizations Do Differently (Feb 2026 white paper) (certification and consulting body)
• Avendium, Why FDA 483 responses fail: 6 CAPA mistakes (Sep 2026) (consultancy)
• Ideagen, CAPA management process: why corrective actions fail to stick (Jun 2026) (software vendor)
• Qualityze, Why CAPA plans fail and steps to correct them (Jun 2026) and Scilife, 11 common problems with your CAPA process (software vendors)
• Atlas Compliance, Why companies fail CAPA and investigation requirements (Apr 2026) (software vendor)
• QMII, Why most corrective actions fail (May 2026) and Pharma.Tips, Why CAPA fails when root cause analysis is weak (May 2026) (training and practitioner sites)
• SGS, ISO 13485 vs U.S. FDA QMSR (Jun 2026) and OpenRegulatory, ISO 13485 vs FDA QMSR: 2026 comparison (certification body and consultancy)

Educational content. Product and company names appear only as sources. Not a substitute for the applicable regulations, standards, company procedures or review by a qualified quality and regulatory professional.