Corrective Action vs Preventive Action

Ask ten people in a maintenance or quality function to define corrective action and preventive action, and you will get ten answers that mostly agree and slightly differ, which is worse than disagreeing outright. The reason is structural. Almost every system I have configured or audited offers the user two categories, while the work being logged actually falls into three: fixing the thing that broke, stopping the same problem happening again on that thing, and stopping it happening at all on the dozen similar things that have not broken yet. Collapse three into two and the labels stop carrying information. This article is about pulling them apart again.

The message up front: most corrective-versus-preventive confusion is not a corrective-versus-preventive problem at all. It is a correction-versus-corrective action problem. Separate the immediate fix from the recurrence fix and roughly three quarters of the ambiguity disappears. What remains is a genuinely blurry fleet-level boundary that deserves an honest answer rather than a clean-looking one.

1. The three things that get collapsed into two

Start here, because nothing else in this article makes sense until this separation is clear. There are three distinct responses to a problem, and only the last two are actions in the management-system sense of the word.

• Correction (also called containment, immediate action, or the remedial fix). You deal with the instance in front of you. The bearing failed, so you replace the bearing. Oil is on the floor, so you clean the spill and put down absorbent. A batch is out of specification, so you quarantine it. Correction restores the situation. It changes nothing about why the situation arose, and it makes recurrence neither more nor less likely. Correction is necessary, usually urgent, and frequently the only thing that actually gets done.
• Corrective action. You address the cause of a problem that has already occurred, so that it does not occur again. The bearing failed because the lubrication route skipped that asset for eight months, so you fix the route, the schedule and the reason it was skippable. The work is aimed at the cause, not the symptom, and the test of success is the absence of recurrence, not the restoration of function.
• Preventive action. You address the cause of a problem that has not occurred, on the basis of a risk you have identified. The same lubrication gap exists on the other twelve identical pumps, none of which has failed yet, so you close the gap across all twelve before any of them does. Or a trend, a near miss, an inspection finding or another site's failure tells you a failure mechanism is credible here, and you act on it in advance.

Written out like that, the distinction looks obvious. The problem is that the first two share a word and the last two share a word, and the form in front of the user almost never has three buttons. So correction gets logged as corrective action, which then makes corrective action look identical to what everybody already does, which in turn makes preventive action look like the only category with any real content in it. That is how a system ends up full of entries reading "replaced faulty sensor" under a heading that promised to explain why sensors keep failing.

2. The three side by side, with one scenario worked through all of them

The table below contrasts the three across the dimensions that actually differ: what triggers them, what question they answer, how wide their scope is, what evidence they need, and how you verify them. The worked examples all come from a single illustrative scenario so the contrast is not muddied by changing the situation: a chilled-water pump in a commercial building trips on high motor temperature and is found to have a seized bearing.

Two things are worth noticing in that last row. First, the corrective action is not "replace the bearing" and it is not "grease the pump": it is a change to how the task is specified and confirmed. Second, the preventive action is not a different idea from the corrective one. It is the same idea applied to assets that have not failed. That similarity is exactly where the boundary starts to blur, which is the next section.

3. Why the line is blurrier than textbooks admit

Most explanations of this topic present a clean binary: already happened equals corrective, has not happened equals preventive. Then they give an example that quietly breaks their own rule, and move on. The honest position is that the boundary is genuinely contested in one specific and very common situation: extending a corrective action to similar equipment or similar processes.

Go back to the twelve pumps. From the point of view of the eleven that have not failed, the route change is unambiguously preventive: no problem has occurred on them, and you are acting on an inferred risk. From the point of view of the organisation, the problem is a defective route design that has already manifested, and fixing every instance of that defective design is straightforwardly corrective, because the problem being corrected is the route, not the pump. Both readings are defensible, and which one you choose depends on how you have drawn the boundary of "the problem".

I do not think this ambiguity can be argued away, and I would be suspicious of anyone who claims to have resolved it with a rule. What I would insist on is this: name it accurately and deliberately, rather than logging it under whichever category the form makes easier. That second behaviour is the real failure, and it is extremely common. If the corrective-action workflow demands a root cause, a verification plan and a sign-off, while the preventive-action workflow needs a paragraph and a tick, then fleet-wide extensions will migrate into the preventive box regardless of what anyone believes about the definitions. The classification then records the path of least resistance through the software, not the nature of the work.

4. How to classify in practice: a two-question test

For the large majority of entries, you do not need a philosophy. You need two questions asked in order.

Question one: has this specific problem already occurred on this specific item?

• Yes, and I am fixing the instance → correction. Restoring, replacing, cleaning, quarantining, reworking, resetting.
• Yes, and I am addressing recurrence → corrective action. The work targets a cause, and success looks like the problem not coming back.
• No → go to question two.

Question two: on what basis am I acting, if nothing has happened? If the answer is a risk identified by analysis, by a trend, by an inspection or audit finding, by a near miss, or by another asset's or site's failure, then it is a preventive action. If you cannot state the basis, you do not have a preventive action. You have an improvement idea, which is a perfectly good thing to have but should not be logged as a risk response, because it will not survive anyone asking why it was raised.

The following test cases are my own clearly hypothetical examples, written to exercise the awkward edges rather than the easy middle.

5. Why the distinction matters at all

Plenty of articles explain the difference and never answer the obvious follow-up: so what? If the work gets done, who cares what box it sat in? The answer is that the two are not administratively interchangeable, for four reasons.

• Different triggers, so different intake. Corrective action arrives from failures, complaints, nonconformities and incidents. Preventive action arrives from analysis: trends, risk assessments, audits, near misses, external intelligence. A system that only has failure-shaped intake routes will never generate preventive actions, because nothing can raise one. That is an intake design problem masquerading as a cultural one.
• Different evidence requirements. Corrective action needs a causal argument connecting the action to an event that actually happened, which is why root cause analysis belongs to it. Preventive action needs a risk argument, which is a different kind of reasoning: plausibility, exposure, consequence. Demanding a root cause for a preventive action is a category error, and it is one of the most common reasons preventive actions stall in review.
• Different verification approaches. Corrective action can be verified by watching for recurrence. Preventive action cannot, because you cannot observe the absence of an event that was never going to be observed in the first place. Preventive verification has to fall back on confirming that the control exists, is used, and that a leading indicator moved. Treating both with the same closure test either lets preventive actions close on nothing, or blocks them forever.
• Different documentation expectations. In many management systems, and more sharply in regulated contexts, the two carry different record expectations. I am not going to state what yours are, because that depends entirely on your applicable regulatory framework and the standards you are certified against. Work from your own; do not work from a generic article, including this one.

There is a fifth reason, and organisationally it may be the most useful. The mix tells you something real. A register composed almost entirely of corrective actions describes an organisation that responds well and anticipates poorly, which is precisely the profile of a reactive operation no matter what its maintenance strategy documents claim. A register with a meaningful stream of preventive actions, each traceable to a stated risk basis, describes an organisation whose analysis is actually feeding its decisions. I would not publish a target ratio, and I would distrust anyone who does, because the right mix depends on asset age, sector, risk profile and maturity, and a ratio target is trivially gamed by relabelling. But the direction of travel over time, read alongside where the actions come from and whether they close with real evidence, is genuinely informative.

For the process mechanics of running all of this, raising, triaging, investigating, verifying, closing and managing the backlog, that ground is covered separately in the CAPA explained guide. This article is deliberately about the distinction, not the workflow.

6. Preventive action is not preventive maintenance

This is the confusion that costs maintenance and facilities readers the most, because both terms are in daily use in the same room and they share a word while meaning entirely different things.

Preventive maintenance is a task type. It is scheduled work performed at predetermined intervals or on condition, to retain an item in a functioning state, regardless of whether anything is wrong with it. Greasing a bearing monthly is preventive maintenance. So is an annual statutory inspection and a 500-hour oil change. In European maintenance terminology, standardised in EN 13306:2017 ("Maintenance - Maintenance terminology", a CEN standard with no ISO twin), preventive maintenance is defined as subdividing into predetermined and condition-based maintenance, with predictive maintenance treated as a form of condition-based maintenance; corrective maintenance, its counterpart, is defined separately and split into immediate and deferred. That vocabulary is worth having, because it makes clear that "preventive" in the maintenance sense names a scheduling basis for routine work.

Preventive action is a management-system response. It is a one-off, non-routine intervention raised because a specific risk has been identified, and it closes when the risk has been addressed. It is not scheduled, it does not recur, and it is not a task on a plan.

The practical consequence: creating a monthly PM route is not a preventive action, and it should not be logged as one. Changing how PM routes are designed, because you have identified that the current design permits unverifiable completion, is a preventive action, and the route it produces is preventive maintenance. One is the intervention, the other is the output. Notice also, and this catches people out, that corrective maintenance and corrective action are similarly unrelated: corrective maintenance is the repair, which in this article's vocabulary is a correction. For the task-type material, see the complete guide to preventive maintenance and the preventive versus predictive versus reactive comparison.

7. What makes each kind of action strong or weak

Classifying correctly is not the point in itself. The point is that each category has its own failure mode, and knowing the category tells you which weakness to look for.

A strong corrective action names a cause you can act on, changes something structural rather than something behavioural, and would have prevented the event had it been in place beforehand. That last test is the sharpest one available: replay the event with the action already implemented and ask honestly whether it still happens. A strong corrective action also sits as high as possible on the hierarchy of controls, which in the occupational health and safety context is required by ISO 45001:2018 (as amended by Amd 1:2024) at clause 8.1.2 and is described publicly by NIOSH: elimination and substitution first, engineering controls and reorganisation of work next, administrative controls including training after that, and personal protective equipment last. The same ordering is a good instinct for corrective actions generally, safety-related or not, because it tracks how durable a control is once attention moves elsewhere.

A weak corrective action is a control at the bottom of that hierarchy, offered as though it were at the top. Which brings us to one of the most common offenders.

"Retrain the operator" is usually neither corrective nor an action. It is not corrective, because in most cases the operator already knew what to do and something in the system made doing it difficult, ambiguous or skippable; retraining addresses a knowledge gap that was not the cause. It is not really an action, because as written it has no specified content, no acceptance criterion and nothing verifiable: there is no way to tell a completed retraining from an uncompleted one six months later, so verification defaults to a signature on an attendance sheet. And it is a bottom-of-hierarchy administrative control, so even when a genuine competence gap does exist, its durability is poor. Retraining is legitimate when the investigation has actually established that the person did not know, and it should then say precisely what content is being delivered, to whom, and how competence will be confirmed. What it should never be is the default entry when a cause has not been found. If a register is full of retraining actions, the useful conclusion is not that the workforce is undertrained. It is that the investigations are not reaching causes, which is a problem to take to your root cause analysis method. A real international standard exists here: IEC 62740:2015 "Root cause analysis (RCA)" describes RCA principles and process steps and covers named techniques including the Why method and the Ishikawa diagram, while explicitly excluding the assignment of blame. For structured event work, the 8D problem-solving guide keeps the correction and corrective-action stages formally separate, which is one of its underrated virtues.

A strong preventive action states its risk basis explicitly, defines the population it covers, and specifies what will be observed to show the risk has reduced. A weak preventive action is an unsourced good intention: no stated trigger, no defined scope, and a closure test of "done". Risk-management guidance is relevant here, and it is worth being precise about its status: ISO 31000:2018 "Risk management - Guidelines" is guidance and is not certifiable, so there is no accredited organisational certification against it, and IEC 31010:2019 (which is IEC, never "ISO 31010") catalogues risk assessment techniques. Both are useful references for constructing a defensible risk basis. Neither obliges anyone to do anything by itself.

8. A short word on where this gets recorded

The classification is recorded somewhere, and in maintenance and facilities operations that is usually the maintenance management system, sometimes alongside a separate quality or HSE register. Two generic points are worth making without getting into products.

First, if your system offers two categories, you will need a local convention for representing the three. The pattern I would recommend is to keep the correction on the work order that restored service, and raise the corrective or preventive action as a separate record that references it, rather than trying to carry both in one entry. It keeps the repair history clean and it stops the action register filling with repairs.

Second, this all depends on the failure data underneath it being usable. If completion comments read "fixed" and cause fields are blank, no classification scheme will produce anything analysable, because there is nothing to classify from. The problem-cause-action failure coding structure is the groundwork, and the CMMS introduction covers the system fundamentals. For the event-side inputs that feed the register, the incident investigation guide and the near miss reporting guide cover the two richest sources of corrective and preventive triggers respectively.

The idea to walk away with

There are three responses to a problem, not two. Correction restores the instance. Corrective action removes the cause of something that happened. Preventive action removes the cause of something that has not happened but credibly could. Most of the confusion in this area is the first two being conflated, and it resolves the moment you ask whether an action makes recurrence less likely or merely makes the present moment tolerable again.

What remains after that separation is one genuinely ambiguous case, extending a fix across similar assets, and the right response to ambiguity is a documented convention applied consistently, not a confident-sounding rule. The distinction earns its keep because the two categories have different triggers, different evidence, different verification and, in many contexts, different record expectations. And because the mix, read honestly, tells you whether your organisation is anticipating anything or simply responding well.

Final thoughts

If you take one operational step from this, audit a sample of your last fifty logged corrective actions and sort them into the three categories by hand. In most registers I have looked at, the majority turn out to be corrections, a minority are genuine corrective actions, and a handful are preventive actions that were filed as corrective because the form offered no better home. That distribution is not a reason for embarrassment. It is a precise, immediately actionable picture of where the process needs work, and it costs an afternoon to produce.

Then check the other direction: how many preventive actions exist, and where did they come from? If the answer is very few, and those few came from audits, the intake is the problem. Nothing in the definitions will help until there is a route by which a trend, an inspection finding or a near miss can raise an action before something breaks.

Related reading: CAPA: corrective and preventive action explained, Root cause analysis methods, 8D problem solving, Incident investigation, Near miss reporting, Preventive maintenance: the complete guide, Failure codes: problem, cause, action. Standards bodies referenced: ISO and IEC .