CAPA: Corrective and Preventive Action Explained

CAPA stands for corrective and preventive action. In its strictest form it is a formal, documented, inspectable element of a quality system: a defined route by which a problem is recorded, investigated, acted on, verified and closed, with evidence retained for an auditor to read years later. In its looser form, which is how most maintenance and facilities teams encounter it, CAPA is simply the habit of doing something durable about a problem rather than just making it go away today. Both are legitimate uses of the term. Confusing them, or applying the loose version in a setting that demands the strict one, is where people get into trouble.

The message up front: a CAPA system lives or dies on two things that have nothing to do with the software it runs in. First, triage, because treating every finding as a full CAPA guarantees collapse. Second, effectiveness verification, because without it you have a filing cabinet of good intentions rather than an improvement engine. Everything else in this guide is detail around those two points.

1. What CAPA is, and which CAPA this article covers

The term CAPA is most strongly associated with regulated manufacture: pharmaceutical, medical device and food production. In those sectors CAPA is not a good habit, it is a formal quality-system process with defined records, defined responsibilities and defined retention, and it is inspected. An inspector can and will pull a CAPA file, read the investigation, look at the actions, and ask what evidence shows the action worked. The consequences of a weak CAPA record there are regulatory, not just operational.

The same acronym is also used far more loosely across general industry, engineering services, construction, utilities and facilities management, where it usually means a structured follow-up on an audit finding, an incident, a customer complaint or a recurring equipment problem. There is no inspector coming, and the rigour is whatever the organisation chooses to apply.

This article covers both, because the underlying logic is the same and the loose version benefits enormously from borrowing the discipline of the strict one. But the regulated context is genuinely stricter and genuinely inspected, and that distinction should be named honestly rather than blurred. If you work in a regulated sector, build your CAPA process from your own applicable regulatory framework and your own quality system documentation, with your quality and regulatory affairs function, not from a general article like this one. Use what follows to think with, not to comply with.

With that said, the vast majority of readers here sit in the second camp: maintenance planners, reliability engineers, facilities managers and operations leads who have inherited a CAPA register, or an audit action log that behaves like one, and want it to produce actual improvement rather than administrative volume.

2. The two halves, and why the split is applied inconsistently

The acronym contains two distinct ideas that are frequently collapsed into one.

• Corrective action addresses a problem that has occurred. Something went wrong, you understand why, and you change something so that cause cannot produce that outcome again. The trigger is real and documented.
• Preventive action addresses a problem that has not occurred but could. Nothing has gone wrong yet. You have identified a plausible failure or nonconformance from a trend, a near miss, a risk assessment, an observation elsewhere in the business, or an industry warning, and you act before it happens.

That is the textbook distinction and it is clean on paper. In practice it is applied inconsistently, and it is worth being honest about why. The overwhelming majority of entries in real CAPA registers are corrective. Genuinely preventive action, arising from analysis rather than from an event, is comparatively rare, because organisations are far better at reacting than at anticipating.

What often gets logged as preventive action is something else: a corrective action extended to similar equipment, similar sites or similar processes. A bearing fails on chiller 3, you investigate, you change the lubrication specification, and you then apply that same change to chillers 1, 2 and 4, which have not failed. The extension to the other three units is frequently recorded as preventive action.

That is a completely defensible practice. It is, in fact, one of the highest-value things a CAPA system does, because the read-across from one failure to a population of similar assets is where a single investigation pays for itself several times over. The only problem is the label. It is corrective action applied more widely, driven by an event that did occur, and calling it preventive inflates your preventive-action count while your organisation remains entirely reactive. If your CAPA metrics are supposed to tell you whether you are getting better at anticipating problems, mislabelling read-across as prevention destroys that signal.

My recommendation is simple. Log read-across explicitly as a scope extension of the corrective action, on the same record or as a linked child record, and reserve the preventive-action label for actions with no originating event at all. Then your register tells you the truth about your own maturity. For the full two-way comparison, including where each one belongs in a management system and how the terminology has shifted over time, see the dedicated corrective action vs preventive action guide, which owns that comparison in depth.

3. Correction, corrective action and preventive action: worked examples

Before the process, one distinction that causes more confusion than the corrective-versus-preventive split: correction is not corrective action. Correction is what you do to the affected item or situation right now. Corrective action is what you do to the system so the cause cannot recur. A very large proportion of closed CAPAs are corrections wearing a corrective-action label, which is precisely why the same problem keeps coming back.

The clearest way to teach this is to run one scenario through all three. The scenario below is hypothetical and illustrative.

Scenario: a monthly fire damper inspection on a hospital ward is found, during an internal audit, never to have been carried out for the past four months. The work orders were generated by the maintenance system and auto-closed by a bulk-closure action taken by a supervisor clearing an overdue list.

4. How a CAPA gets triggered

A CAPA process needs defined entry points, or it becomes whatever anyone feels like raising. The usual sources, and they are worth writing down explicitly in your procedure:

• Nonconformance: output, work or a condition that fails to meet a specified requirement. In maintenance terms, a job done outside specification, a calibration out of tolerance, a plant condition outside its design envelope.
• Complaint: from a customer, a tenant, a clinical department, an operations team. Complaints are underused as a CAPA source because they arrive as irritation rather than as data.
• Audit finding: internal or external, first, second or third party. This is the single largest source in most organisations, and the one most likely to be processed as paperwork.
• Incident: safety, environmental, asset damage, service outage. Incident investigation and CAPA are two halves of the same loop, and they are frequently run by different departments with different systems, which is how findings get lost. See the incident investigation guide for the front half of that loop.
• Near miss: an event with no consequence that easily could have had one. Near misses are the closest thing to free information an organisation gets, and they are the most legitimate source of genuinely preventive action. The near miss reporting guide covers how to get them reported at all.
• Trend: no single event crosses a threshold, but the aggregate does. Repeat failures on an asset class, rising reactive work, a drift in a measured parameter. Trend-triggered CAPA is the most mature entry point and the least commonly implemented, because it requires someone to be looking.

A practical note: define who may raise a CAPA and make it wide. A system that only accepts CAPAs from the quality function or from auditors will miss most of what the people doing the work already know. Then define who decides whether it becomes a CAPA, and make that narrow. Wide intake, narrow triage.

5. Triage and risk-based prioritisation

This is the section to read if you read only one. Treating every finding as a full CAPA is the fastest way to make a CAPA system collapse under its own weight, and it is one of the most common real-world failure modes. It is common to find registers with hundreds of open items where nobody could name the five that mattered, because a stripped thread on an access hatch and a repeated failure of a life-safety system occupied the same queue with the same template and the same fields.

The fix is a triage step with genuine authority to route findings to something other than a full CAPA. Three outcomes are usually enough:

• Correction only. Fix the thing, record that you fixed it, close it. Appropriate where the consequence is low, the cause is obvious and local, and there is no pattern. Most findings land here and that is correct.
• Correction plus a logged observation. Fix it and record it in a way that will aggregate. If the same observation appears five more times, the trend trigger fires and it becomes a CAPA on evidence rather than on instinct.
• Full CAPA. Investigation, root cause, action plan, effectiveness verification, documented closure. Reserved for findings where the consequence is significant, the cause is not understood, or the problem is recurring.

The prioritisation itself should be risk-based rather than first-in-first-out. Two dimensions carry most of the weight: the severity of the consequence if the problem recurs, and the likelihood of recurrence given what is currently in place. A high-severity, high-likelihood finding outranks everything else regardless of when it was raised. Risk management guidance such as ISO 31000:2018 sets out the general principles here; note that it is guidance rather than a certifiable requirements standard, so there is no accredited certification against it. For a catalogue of assessment techniques you might use inside the triage step, IEC 31010:2019 is the reference, and it is IEC 31010, not ISO 31010.

Keep the triage criteria written and keep them short. If the criteria run to three pages, people will bypass them. A single-page matrix that a supervisor can apply in two minutes, with a named escalation route for anything ambiguous, will be used. Anything longer will be decorated rather than followed.

6. Investigation and root cause

Once a finding is accepted as a full CAPA, the investigation establishes what happened and why. The depth should match the risk established at triage: a structured half-hour conversation for a modest recurring problem, a formal multi-day analysis for a significant incident.

I am deliberately not going deep on method here, because the methods have their own homes. The important points for CAPA purposes are these. A real international standard for root cause analysis exists, IEC 62740:2015 "Root cause analysis (RCA)", which sets out principles and process steps and describes a range of recognised techniques, and which deals with analysis after the event and explicitly stays out of assigning blame. That last point matters more than it sounds: a CAPA investigation that becomes an exercise in identifying who to discipline will stop producing useful information within about two cycles, because people will stop telling you things.

For the methods themselves, see the root cause analysis methods guide, which covers technique selection and the step-by-step process, and the 5 Whys guide for the simplest usable technique and its limits. If your organisation runs 8D, note that D5 through D7 are essentially the CAPA process embedded inside a problem-solving discipline, and the 8D guide walks through how those steps interlock.

Two failure patterns to watch in the investigation step. The first is stopping at the first plausible cause, which is commonly a human action rather than a system condition. The second is the opposite: an investigation that expands until it has indicted the organisation's entire culture, producing a cause so broad that no specific action follows from it. A usable root cause is specific enough that an action against it is obvious, and systemic enough that the action changes something other than one person's memory.

7. Action planning and implementation

An action plan needs four things, and the absence of any one of them is a reliable predictor that nothing will happen.

• A named owner. One person, not a department. "Maintenance" does not own anything. If the action requires several functions, one person owns the action and coordinates the others.
• A specific action. Described concretely enough that a third party could tell whether it had been done. "Improve the handover process" fails this test. "Add a completion-evidence field to the statutory work order template and make it mandatory before closure" passes it.
• A date. A real one, negotiated with the owner, not assigned to them. Dates imposed without conversation are the raw material of a backlog.
• A defined effectiveness check. Written now, not later. What evidence would show this worked, who will look at it, and when? This is the field most CAPA forms either lack entirely or leave blank, and it is the one that separates a working system from a paper one.

On implementation, the only advice that consistently helps is to prefer actions that change a system, a permission, a default or a physical arrangement over actions that change what people are expected to remember. A control that is built into the workflow survives staff turnover, shift pressure and the gradual erosion of attention. A briefing does not.

Where the action concerns a safety hazard, the hierarchy of controls is the right lens: eliminate, substitute, engineering controls and reorganisation of work, administrative controls including training, then adequate personal protective equipment, in that order of preference. It is a principle rather than a standalone standard, and it is required by ISO 45001:2018 (as amended by Amd 1:2024) at clause 8.1.2 and described by NIOSH. The CAPA relevance is direct: a corrective action that sits at the bottom of that hierarchy when a higher option was available is a weak action, and a reviewer should say so.

8. Effectiveness verification: the step that makes CAPA real

If I had to identify the single feature that distinguishes a functioning CAPA system from a documentation exercise, it is this one. Implementation verification asks "was the action done?" Effectiveness verification asks "did it work?" They are not the same question, and most registers only answer the first.

Doing it properly requires two disciplines that are uncomfortable in different ways.

Define the evidence in advance. At the point of action planning, before implementation, write down what observation would demonstrate that the cause has been removed. Not "monitor the situation". Something checkable: no recurrence of this failure mode on this asset class over the next defined period; audit of the next batch of statutory closures shows completion evidence present in every case; the recurring defect that generated four work orders in six months generates none in the following six. The reason to write it in advance is that after the fact, everyone will accept whatever happened as proof that the action worked.

Check it after enough time has passed. Enough time means long enough for the problem to have had a fair opportunity to recur. For a monthly inspection failure, that is several monthly cycles. For an annual statutory activity, a verification check a fortnight after implementation is meaningless. This is why effectiveness verification cannot be a box ticked on the day of closure, and why a CAPA process needs a mechanism to hold a record open, or reopen it, for a verification check scheduled well after the action itself.

I am deliberately not offering a number of days here. The right interval is a function of the failure frequency and the exposure period, and any generic figure would be worse than no figure. Derive it from the cycle of the thing you are verifying.

A useful refinement: if effectiveness verification fails, do not simply extend the action. A failed verification means the root cause analysis was probably wrong, or the action did not address the cause it was aimed at. Route it back to investigation rather than back to implementation. Extending the deadline on an action that has already been shown not to work is one of the purest forms of wasted effort in this field.

9. Closure, with documented rationale

Closure should be a decision someone makes and records, not a status that a record drifts into. The closure record needs to state what the problem was, what the investigation concluded, what was done, what evidence shows it worked, and who accepted that. In a regulated setting this is the artefact an inspector reads, and the standard to aim for is that a competent stranger could reconstruct the whole story from the file without speaking to anyone.

Two closure situations need explicit handling because they happen constantly and are usually fudged.

Closing without full implementation. Sometimes the ideal action turns out to be disproportionate, unaffordable or superseded by a wider project. That is a legitimate outcome, but it must be recorded as a decision with a rationale and an accepting authority, not quietly closed as complete. The rationale is the whole value: in two years, when the problem recurs, the file should show that the organisation consciously accepted the residual risk and on what basis.

Closing a CAPA that has been open a very long time. The temptation with an aged backlog is a clean-up exercise that bulk-closes anything nobody remembers. Resist it, or at least do it honestly: review each one, decide whether it is still relevant, and close it either as complete with evidence or as a recorded risk-acceptance decision. A bulk closure with no rationale converts a visible problem into an invisible one, which is worse.

10. Weak actions versus strong actions

The most common defect in CAPA registers is not a missing step, it is an action that restates the problem. "Operator to be more careful." "Remind staff of the procedure." "Technician counselled." These are not actions, they are descriptions of the failure with a verb attached, and they will be ineffective for the entirely predictable reason that they depend on the same human attention that has already been demonstrated to be insufficient.

Retraining deserves specific attention because it is the single most over-used corrective action in existence. Retraining is only a valid corrective action where the root cause was genuinely an absence of knowledge or skill: the person did not know, could not have known, and now will. That happens, but it is far rarer than the register suggests. In most cases the person knew perfectly well and the system made the wrong action easy, the right action slow, or the error invisible. Retraining someone who already knew is not a corrective action, it is a ritual.

The question I ask instead of accepting retraining: what made the wrong outcome possible for someone who knew better? Answer that and you usually get a real action.

A practical reviewer's habit: before accepting any action, read it aloud and ask whether it is a change or an exhortation. Exhortations go back. This single filter, applied consistently by whoever approves action plans, improves a CAPA system more than any software change will.

11. The open-CAPA backlog, and what it tells you

A large and ageing population of open CAPAs is the classic symptom of a system being used as a filing cabinet rather than an improvement engine. It is worth being precise about what the backlog actually indicates, because the instinctive response, pressure on owners to close things, usually makes it worse.

A growing backlog commonly means one of four things:

• Intake exceeds capacity because triage is absent. Everything becomes a full CAPA, the full process is expensive, and the arithmetic does not work. This is the most common cause by a wide margin, and the fix is triage, not effort.
• Actions are too large. A CAPA whose action is effectively a capital project will sit open for years. Split it: the CAPA action should be the specific change that removes the cause, with the wider project tracked separately and linked.
• Ownership is nominal. Actions assigned to people without the authority or the budget to complete them. The record shows an owner; the organisation has not actually allocated anything.
• The process has no closure discipline. Nobody is empowered to close a record as risk-accepted, so records that will never be actioned cannot leave the register and accumulate indefinitely.

Maintenance readers will recognise this shape immediately, because it is the same pathology as an uncontrolled maintenance backlog: demand exceeding capacity, no prioritisation discipline, and no honest mechanism for deciding what will not be done. The analysis in the maintenance backlog and downtime tracking guide transfers almost directly: measure the backlog in terms of the capacity required to clear it rather than as a count, understand its age profile, and separate the part that is a genuine queue from the part that is fiction.

I will not offer a target closure time, because a universal one does not exist and any figure would be arbitrary. What is defensible is a target derived from your own risk tiers and your own demonstrated capacity, reviewed against your own baseline. A tier-one finding should be resolved faster than a tier-three one, and you should know your own current distribution before setting any figure at all.

12. CAPA in maintenance: recurring failures, repeat work orders and contractors

Most readers of this article are not in a regulated quality function. They are running maintenance or facilities operations, and the question is what CAPA discipline adds to work they are already doing. Three applications are worth the effort.

Recurring equipment failures. The same asset generating the same corrective work order repeatedly is the clearest CAPA trigger in maintenance, and it is routinely missed because each individual work order is closed successfully. The work order system is doing its job; nobody is looking at the pattern. This is exactly where structured failure coding earns its keep: consistent problem, cause and action coding is what turns a pile of closed jobs into a detectable trend. The failure codes structure guide covers how to build coding that supports this rather than obstructing it. Without it, your trend trigger has nothing to fire on.

Repeat work orders and the callback pattern. A job done, closed, and reopened within days for the same fault is a quality signal about the work, not just about the asset. Tracked over time and by crew, trade or contractor, callback rate is one of the few maintenance measures that reliably surfaces workmanship and diagnosis problems. The corrective action is rarely about the asset; it is usually about the job plan content, the parts specification, the diagnostic step that was skipped, or the acceptance check at handover.

Contractor quality issues. CAPA gives you a structured, non-adversarial route to handle recurring contractor performance problems, which is far more productive than a performance meeting built on anecdote. A documented finding, an investigation the contractor participates in, an action with an owner on their side, and an effectiveness check at an agreed point, produces change in a way that a monthly complaint does not. It also produces a record, which matters at contract renewal.

Two relationships are worth drawing explicitly. First, CAPA and defect elimination are the same activity approached from different directions. Defect elimination starts from the population of recurring failures and works toward causes; CAPA starts from an individual finding and works toward a systemic change. A mature operation runs them as one process with two entry points, rather than as a quality register and a reliability initiative that never speak.

Second, a large proportion of maintenance corrective actions end up as a change to the preventive maintenance programme: a task added, a task removed, a frequency changed, a job plan rewritten, an acceptance criterion tightened. That is a good outcome, and it deserves a specific discipline. A PM change arising from a CAPA should be treated as a controlled change with a rationale recorded against it, not as a quiet edit to a task list. Otherwise the PM programme accretes tasks from years of forgotten investigations, nobody remembers why any of them exist, and the next review deletes something that was protecting you. Recording the originating CAPA reference against the PM change is a small discipline with a long payoff.

On tooling, keep expectations proportionate. Most maintenance management systems can hold a CAPA record adequately: a linked parent record, an owner, a due date, a status, attachments and a verification field. What they generally do not do on their own is enforce the triage decision or schedule the effectiveness check far enough in the future, so those tend to need deliberate configuration or a parallel review routine. If you are choosing or reviewing a system, the CMMS buyer's introduction covers what the category does and does not do. The software is not the hard part of CAPA; the triage discipline and the verification habit are, and neither is purchasable.

The idea to walk away with

CAPA is not paperwork, although it is very easy to turn it into paperwork. It is the mechanism by which an organisation converts problems it has already paid for into changes that stop it paying again. Two things decide whether it does that. Triage, which keeps the volume proportionate so that the significant few get real attention. And effectiveness verification, which is the only step that distinguishes an improvement from an intention.

The rest is honest bookkeeping: correction is not corrective action, read-across is not prevention, retraining is rarely a control, and a closure with no evidence is not a closure. Get those distinctions right and a modest CAPA process outperforms an elaborate one.

Final thoughts

If you have inherited a CAPA register in poor health, I would not start by trying to close the backlog. I would start by introducing a triage step so the inflow stops making it worse, then add a mandatory effectiveness-check definition to the action-planning stage so that new records are built correctly. Then work the existing backlog by risk, closing what can be closed with evidence and recording honest risk-acceptance decisions for what cannot. That sequence fixes the system first and the symptom second, which is, appropriately enough, the difference between corrective action and correction.

And if you are in a regulated sector, take the logic from this article and the requirements from your own framework and quality system. The thinking transfers. The compliance does not.

Related reading: Corrective action vs preventive action, Root cause analysis methods, 8D problem solving, Incident investigation, The 5 Whys method, Near miss reporting, Failure codes: Problem, Cause, Action, Maintenance backlog and downtime tracking.