CAPA corrective and preventive action: example and effectiveness review

Hypothetical examples. The scenarios and outcomes explain a workflow; they are not a customer audit report or a guaranteed result. Check the current offer for feature scope, CrewShift workflows and service terms.

ISO 9001:2026 update (29 September 2026). The final edition was published on 16 September 2026. Use a lawful copy of the applicable version and review effects on requirements, risks and opportunities, controls and evidence. Historical 2015 references, including IATF references, retain their context; do not automatically replace clause numbers. Agree the certification schedule with your certification body. Update guide · ISO source.

What is CAPA? A concise definition

CAPA stands for Corrective and Preventive Action. Corrective action removes the cause of a detected nonconformity so it does not recur. Preventive action reduces the risk of a problem that has not happened yet. In ISO 9001:2015, prevention is integrated into risk-based thinking rather than expressed as a separate preventive-action clause.

CAPA is not an audit task list. It connects the problem, cause, decision, implementation and outcome. Completing a task — updating a form, training a team or changing an instruction — is not yet evidence of effectiveness. The record should show whether the problem actually stopped recurring.

A minimum workflow covers:

1. an unambiguous description of the nonconformity or risk,
2. immediate containment,
3. evidence-based root cause analysis,
4. a corrective action with an owner and deadline,
5. implementation evidence,
6. a planned effectiveness review,
7. a decision to close, extend observation, or reopen the CAPA.

CAPA example: missing pre-dispatch review

An internal audit found that 4 of 25 sampled orders were dispatched without the required second-person review. The table separates immediate containment from a change whose effectiveness can be evaluated.

CAPA element	Example record
Nonconformity	4 of 25 orders lacked the required pre-dispatch confirmation
Immediate containment	Held unresolved orders and completed the missing review
Root cause	The form allowed completion without a mandatory field or a system block
Corrective action	Add validation, name the review owner and revise the instruction
Preventive action	Review comparable forms in other processes for the same control gap
Implementation evidence	Approved change, validation test, revised instruction and affected-person confirmations
Effectiveness criterion	100% complete confirmations in the next 30 orders and no technical path to dispatch without review

1. Separate the problem from its effect

“An employee made a mistake” is not a useful problem statement. It does not identify the expected condition, the observed condition, or the evidence supporting the gap. Record the process, requirement, event, time, scope, and impact.

Contain the situation before searching for the cause. Containment may block a batch, correct data, add a temporary control, or notify the process owner. It limits further impact but does not replace corrective action.

2. Analyse the mechanism, not the person

Methods such as 5 Why, cause diagrams, or barrier analysis help only when each question follows the previous answer and is supported by data. Mark a hypothesis as a hypothesis until it is tested.

Root causes usually sit in the process mechanism: an unclear criterion, missing validation, unavailable information, an ineffective control, or a mismatch between the instruction and real work. Naming a person without examining the system often allows the problem to recur.

3. Plan a change that can be verified

A corrective action needs an owner, due date, intended result, and implementation evidence. “Train the team” is incomplete. Identify the material version, affected people, knowledge check, and pass criterion.

The action plan should record:

• the CAPA identifier and linked finding,
• the verified root cause,
• action, owner, and deadline,
• dependencies,
• implementation evidence,
• effectiveness measure,
• review date and reviewer.

4. Do not confuse completion with effectiveness

Publishing a document does not prove that a process improved. Review effectiveness after a period appropriate to the risk and process frequency. Use a record sample, a later audit, complaints, an error metric, or observation of the control.

Set the criterion before collecting results. For example: “the next 30 orders have all mandatory fields complete, and the second-person control catches a missing field before publication.” A positive decision needs evidence. A negative result leads back to analysis instead of a cosmetic status change.

Review question	Evidence	Decision
Was the change implemented?	validation test, approved instruction version and team confirmations	start the observation period or complete implementation
Was the cause removed?	sample of the next 30 orders and a record of the blocking control	evaluate against the agreed criterion
Did the problem recur?	complaints, exceptions, audit results and error trend	close, extend observation or reopen the CAPA

5. Build a closure pack

An auditable CAPA closure pack contains the problem statement, containment, root cause analysis, approved plan, implementation evidence, effectiveness result, and an authorised decision. The change history remains available after closure.

The Pulsar GRC audits and CAPA module can connect a finding, risk, control, owner, deadline and evidence in one trace. The process demo shows the path from a requirement to an action and evidence pack. Pulsar GRC does not choose the root cause or approve effectiveness on behalf of the organization.

When does a spreadsheet stop being enough?

A spreadsheet can work for a simple register maintained by one person. It becomes harder to follow when actions have different owners, evidence is stored in several places and a completion date does not show whether effectiveness was checked. Before choosing a tool, check whether you can trace who made a decision, the evidence behind it and what happened after the action was implemented.

Choose one typical case and follow it from the problem statement to the closure decision. Use sample data in a demonstration. See the workflow in Pulsar GRC — this is a general process presentation. Check the current scope on the features page and the offer.

Closure checklist

Download the CAPA closure checklist (CSV). No form or email address is required. The file also has blank columns for the result, owner, deadline and notes. The table below is the browser-readable version.

Stage	Question	Evidence to check
Problem	Does the record identify the expected and observed condition?	Nonconformity record with date and scope
Containment	Have the immediate effects been limited?	Immediate action record
Cause	Was the cause verified rather than only proposed?	Root cause analysis evidence
Plan	Does each action have an owner and deadline?	Approved action plan and intended result
Implementation	Is there verifiable evidence of the action?	Implementation record and correct change version
Effectiveness	Were criteria set before the review?	Measure and justified observation period
Review	Do the results address the agreed criteria?	Observations or a checked sample
Decision	Did an authorised person make and justify the decision?	Closure or further-action decision and residual risk
History	Can changes and linked evidence be traced?	Consistent case history

A supporting resource from Brillnet, not a standard or a certificate of compliance. Use criteria appropriate to your own process.

Feed the result into the ISO 9001 audit evidence pack. If the action concerns cybersecurity obligations in Poland, also use the NIS2 self-identification guide for SMEs.

Test alternative causes before choosing an action

The following investigation technique is a practical recommendation. It does not replace the organisation’s applicable procedure. In the dispatch example, a missing review field may explain the failure, but it is not the only plausible cause. The reviewer might have lacked access, the role might have been unassigned during absence, or a rushed order might have used a different dispatch route. Test the alternatives against the four affected orders and a few unaffected ones.

Record what would support or reject each hypothesis. If all affected orders used the same alternate route, inspect that route. If normal orders also bypass the field, the weakness is broader. If the technical control works but the reviewer account was unavailable, adding another field will not solve the access problem. This prevents a plausible story from becoming an expensive change before it has been checked.

Preserve contradictory evidence. A record showing that an order failed despite complete training is useful: it limits the explanation that employees simply did not know the instruction. Mark unresolved uncertainty instead of forcing every case into the first cause diagram. A short investigation with visible limitations is stronger than a polished diagram built from guesses.

Design the effectiveness test against the failure path

Thirty correctly reviewed orders can show that the process was followed during observation. They do not prove that the bypass is impossible. Add a controlled negative test using demonstration data: try to proceed without the second-person approval through each permitted dispatch route. Confirm that the system blocks or routes the attempt as designed. Retain the test conditions and results without creating a real unsafe shipment.

Include absence and workload in the test where they contributed to the failure. Name an authorised substitute and verify that the substitute can perform the review. Test the alternate route if urgent orders use it. The purpose is to challenge the mechanism that failed, not to collect a large number of easy successful cases.

Choose the observation period before results arrive. A daily dispatch process can yield enough opportunities quickly. A quarterly supplier reassessment cannot demonstrate sustained performance after one week. Define the number of meaningful opportunities and the expected conditions. If those opportunities have not occurred, leave effectiveness pending instead of closing the record to meet a calendar target.

Reopen without erasing the first decision

Suppose the next review finds an urgent order dispatched through a newly added interface without the approval. Reopen the linked case or create a linked recurrence according to your procedure. Retain the original closure evidence and explain why it did not cover the new route. The new analysis may reveal an inadequate change-management control rather than the original dispatch field alone.

An honest reopening is information about the process. Hiding recurrence in a separate task makes repeat problems disappear from the metric while they continue in operations. Define recurrence consistently: same cause, same failure mechanism or another criterion suitable for the organisation. Review doubtful cases with the process owner and record the reason for the classification.

Decide whether the action introduced another problem

A stronger block can delay legitimate shipments if the substitute role is unavailable or the validation rejects valid orders. During effectiveness review, inspect exceptions and operational delays as well as missing approvals. A solution that reduces one failure by making the normal process unusable will invite workarounds.

If a temporary workaround is necessary, authorise it explicitly, limit its scope and set a review date. It needs evidence and a responsible person. Do not let a temporary exemption become the routine route that eventually recreates the same nonconformity. The closure decision should address both the original problem and material new risks introduced by the action.

Pulsar GRC can organise the case and its evidence, while the organisation defines the test and approves the decision. A convincing closure is therefore a checked causal argument supported by records, not a green status selected at the end of the month.