Anatomy of a Corrective Action

One verb dominates most improvement registers, and sorting on the first word makes it obvious. Review the change process. Review the escalation matrix. Review our approach to major incident communications. Each carries an owner and most carry a date, and not one of them could ever be objectively closed.

Looking at something is not a corrective action, and this is where improvement work stops moving — not for want of analysis, but because what got written down was an intention rather than an instruction. A corrective action is a falsifiable claim about causality: this condition produces that failure, this change will stop it. A record that cannot be wrong cannot be closed.

Correction Is Not Corrective Action

What the standards oblige, and what they leave entirely to you

The trigger has a name: nonconformity, the non-fulfilment of a requirement — the standard’s, your management system’s, or the customer’s — rather than a bad day. ISO 9001:2015 clause 10.2.1 and ISO/IEC 20000-1:2018 clause 10.1 both ask first for a reaction: control it, correct it, deal with the consequences. That is correction. Only then do they ask whether action is needed to eliminate the cause. The evaluation is obligatory and the action is not, which is why a documented “evaluated, none needed” is a legitimate outcome rather than a confession.

Older practitioners will notice a missing term: ISO 9001:2015 withdrew the standalone preventive action clause and folded its intent into risk-based thinking, as Annex A.4 says plainly. Anticipatory work belongs in risk treatment. Read 10.2.1 in its own order — react, evaluate the need, implement, review effectiveness — and the closure test sits in the same clause as the action. Who performs that review comes later in this series.

• Correction restores the required state — it eliminates the failure in front of you, and is judged on speed.
• Corrective action changes the conditions — it acts on the cause so those circumstances stop producing the failure.
• The evaluation is required, the action is conditional — and the symptom vanishing is not the evaluation.

None of this tells you what a well-formed entry contains. ITIL describes the register and the standards the obligation; neither says how an action should read. The tooling fills the gap badly: one field marked “resolution” teaches that restoring service and eliminating a cause are one event.

The Cause Statement Does the Work

A record that describes the symptom will only ever fix the symptom

The field that decides whether a corrective action succeeds describes what you are acting on. Most registers put the symptom there. “Payroll interface failed” is a symptom. “Credentials are rotated manually with no expiry tracking, so the interface fails whenever a rotation is missed” is a cause statement: a condition that exists, will exist tomorrow, and can be changed. Producing it is problem management’s job, and I have argued elsewhere that most root cause analysis is performed rather than done.

One case the rule must survive: sometimes the symptom is all there is — a single failure with no standing condition, a supplier since replaced, hardware since decommissioned — and recording it plainly is right. It still cannot carry a corrective action, because nothing remains that could be found untrue, so the entry closes on the observation that the failure has not returned — evidence of nothing but the passage of time.

• Write the cause in the present tense — a persisting condition can be found untrue; an event that happened cannot.
• Name a mechanism, not a person — a record naming an individual means nothing to a stranger reading it in two years.
• Stop short of the remedy — argue the cause before you argue the fix.

Reading somebody else’s register, the cause statements are the only fields worth the time: a remedy attached to the wrong condition just makes the mistake tidier.

The Test That Closes It

Name what will be different, then name what proves it

The cause statement says what is wrong; the next says what will be true instead, which separates an action you can close from one you can only abandon. Write it as a completed condition somebody could check: “introduce quarterly certificate reviews” is a meeting series; “no public-facing certificate reaches expiry without renewal or an alert” is either true or false when you look. Acceptance criteria are that sentence from the far side: agreed beforehand, a contract rather than a description of whatever got built.

Some worthwhile work honestly cannot state its finished condition in advance. Rebuilding a fragile deployment path teaches you the answer’s shape as you go, and criteria demanded up front are a sentence written to fill a field. Such work is not lesser, only a different instrument, judged on what it produced. Filed as a corrective action it borrows a closure test it cannot pass, then fails it slowly and in public for two years.

• A finished condition, not a project — the state of the system afterwards, specific enough to be costed and refused.
• Bounded to the estate, not the instance — one renewed certificate is a correction; every certificate covered is a change of state.
• Criteria agreed before anybody starts — they make “done” a matter of fact rather than of mood.

I am always conscious that this reads as a stylistic preference, and it is not one. ISO 9001:2015 clause 10.2.2 requires documented information on the nature of the nonconformity and the actions taken, and ISO/IEC 20000-1:2018 asks the same in clause 10.1. Naming the closure artefact when you raise the entry is the cheapest way to have it later.

The Same Action, Written Twice

The same thinking behind both, and only one of them can turn out wrong

Take an outage caused by a public-facing certificate expiring unnoticed. The record reads: “Review the certificate management process. Owner: Infrastructure Team. Due: end of quarter.” It will survive three quarterly reviews and close as “reviewed”. Written properly it starts from a cause — expiry dates live only in personal calendar reminders, so a renewal is missed whenever their holder is away — and names a change of state: every certificate renews automatically, anything unrenewed thirty days out alerts the operations queue, and closure evidence is a reconciliation showing full coverage.

Nothing was discovered between those two records: whoever wrote the first knew the reminders sat in one calendar and did not write it down. Precision cost no extra analysis, only an argument, and the argument is cheapest at the point of raising. That is why the second record can be wrong: thirty days may be too short, and automatic renewal may not suit the certificates that matter most. The first cannot be wrong about anything, which is precisely why it lasts three quarters.

• It can be refused before work starts — a bounded proposal invites a no, and a no in November beats a review closed in August.
• It can be costed — a defined finished state carries a price; an intention carries only a due date.
• It survives its author — a stranger reading it in two years is told what finished looks like.

The serious objection is that most real improvement never enters a register. Somebody notices a fragility and fixes it on a Thursday, and formalism of this kind is what drained a generation of registers. I concede nearly all of it. The instrument is not for improvement in general, but for failures that will outlive the person who noticed them — a far smaller set than most registers hold. Being small, its few entries can afford to be written so they might fail, and bureaucracy is the manufacture of records that cannot.

Two Ways an Action Is Not an Action

Activities in disguise, and corrections wearing a lanyard

The first is the action phrased as an activity — review, consider, explore, monitor, raise awareness of. They describe effort rather than outcome, so they close on fatigue rather than evidence. If you cannot name what will be done differently once this closes, there is nothing here to close.

The second is subtler and does more harm. The certificate was renewed, the disk extended, the service restarted, and that work is logged as the corrective action — a correction with a lanyard on. The tell is the timeline: it finished while the incident was still open, because it was the incident resolution.

• Test the verb — review, monitor and consider describe effort; implement, replace and automate describe a change of state.
• Ask what changed beyond the instance — if only the one certificate is different afterwards, nothing was corrected at the cause.
• Check when it finished — work completed before service was restored is the resolution relabelled, unless the record says it was both.

The second mode does the greater damage, because it closes on perfectly genuine evidence: the work was done, the change record exists, and the condition that produced the failure sits where it was. Both share one thing: neither record has a state in which it could come out false. “Review the process” cannot be contradicted, and “we renewed the certificate” was true the moment it was typed. A claim nobody can test is a claim nobody can fault, and that is why both survive.

Why Bad Actions Get Written On Purpose

Vagueness is frequently a drafting decision, not a drafting failure

If precision costs only an argument, why do so many decline to have it? Everything above treats a bad action as an accident of craft; often it is a decision. “Review the change process” clears a governance forum without incident. “Change approval is delegated to a board that has not been quorate since March” does not, because it names a decision somebody senior took. The vague version survives the room for the reason it can never be closed: nothing in it could be proved wrong.

The route through is to negotiate only half the record. The cause statement is a factual claim about the system and should be written honestly: it is the half an assessor and your successor will read. The change of state is a proposal, and proposals can be trimmed, phased or deferred with a reason. A reduced remedy against an accurate cause leaves a trail; a confident remedy against a euphemism leaves nothing.

• Write the cause honestly, negotiate the scope — they sit in different fields for a reason.
• Name the constraint, not the culprit — “renewal is manual because the automation was descoped” is a fact about the system, and facts are harder to take personally.
• Record what you were refused — an action closed as “not funded this year” is a better artefact than one closed as “reviewed”.

The honest version is accepted more often than people fear; the fear does most of the work here. Where a cause genuinely cannot be written down, that is itself the finding: a mechanism unable to describe its own causes has a governance problem no drafting will reach.

Where I Would Start

Rewrite what is already there before rebuilding anything around it

If your register is long, old and vaguely depressing, I would not rebuild the process but rewrite what is in it, then refuse anything new written the old way.

• Rewrite the cause statement on your five oldest actions — age is a symptom of vagueness, and two usually describe the same condition.
• Query for actions that closed before the incident did — completion before service restoration means a correction filed as corrective action.
• Make acceptance criteria a condition of entry — nothing joins the register until somebody writes what evidence closes it.
• Read the newest cause statements aloud — euphemism is audible in a way it never is on a screen.

Judge an improvement capability by how many of its closed actions could have failed — how many named a condition that might have proved untrue and a finished state that might never have arrived. A register in which nothing could have gone wrong has recorded no claims about the service, only intentions that were never at risk.

Writing them properly only changes the nature of the difficulty, mind you. A backlog of well-formed actions still ages, still changes hands, and still has to be made to move.

Hopefully this has been useful to you and I wish you well on your ITSM journey…