Nonconformity and corrective action

In plain words

When something goes wrong, this clause demands two separate movements. First: control the consequences — block the bad part, inform the customer, limit the damage. That is the correction, and in production it is already the handling of nonconforming outputs (8.7). Second, and here lies the core of 10.2: remove the cause, so it does not come back. That is the corrective action.

The difference is the whole clause. Reworking a part repairs the symptom; asking “why did it arise in the first place?” repairs the process. The standard gives a clear sequence for it (10.2.1): react, analyse the cause, implement the action, check effectiveness — and, where necessary, update risks and objectives. And it demands (10.2.2) that this be documented: the nonconformity, the actions taken, the result.

Two things are expressly left open. The effort follows the impact — not every trifle needs a deep cause analysis. And the old “preventive action” no longer exists as a chapter of its own; preventing now lives in risk-based thinking (6.1).

Why this requirement exists

An error whose cause is never removed comes back — more expensively and with the same customer. Whoever only reworks pays the same error over and over. 10.2 forces the one step that breaks the repetition: moving the gaze from the effect to the cause.

The demanded effectiveness check (10.2.1e) is the heart, and the reason auditors look most closely here. “Action implemented” means nothing if nobody checks whether it worked. A corrective action closed before the proof of effect is in is a pious wish — and the error returns while the file says “done”.

What good looks like

Not every deviation becomes a big corrective action — that would be bureaucracy. The art is the selection: if something repeats, if the impact is large, or if it reaches the customer, then the cause-work is worth it. For the rest the correction suffices. Where a corrective action runs, it is honestly conducted: a recognisable cause analysis, an action with an owner and a date, and — the decisive step — an effectiveness check at a later point that only then closes the case.

The cause analysis need not be elaborate. In small companies the simplest method there is suffices — the “five whys”: you simply ask “why?” several times in a row (rule of thumb: about five times), until you get from the visible effect to the actual cause, and hold the result on one sheet. An elaborate cause-and-effect diagram — the “Ishikawa” or fishbone diagram common in the quality world — is not needed for it.

You recognise a good solution by closed chains: nonconformity → cause → action → implemented → effectiveness evidenced → closed. A single complete chain convinces more than twenty open points. And the cases do not stand alone: they are an input to the management review (9.3) and raw material for improvement (10.1).

What changes as you grow: From around 50 people the flow gets a simple form with defect types and a rule from which severity a cause analysis is mandatory. From 100–250 people, where customers or industry demand it, formal methods (8D, Ishikawa, 5-Why as standard) and a trend evaluation of recurring causes arrive. The core stays: cause instead of symptom, effectiveness instead of intention.

The minimum to pass

• On a nonconformity, the consequence is controlled first (correction) — the link to 8.7 is lived.
• Where the impact justifies it, there is a corrective action with a recognisable cause analysis.
• Every corrective action has an effectiveness check — and is closed only after it.
• Nonconformity, action and result are documented (10.2.2).
• The effort is appropriate to the impact — no 8D analysis for a scratch.

What an auditor asks for

• Two or three corrective actions followed lengthwise — from the nonconformity to the evidenced effectiveness. The closed chain is the standard’s strongest proof.
• The difference in a concrete case: what was the correction, what the corrective action? Whoever confuses the two has not understood 10.2.
• An effectiveness check that really took place — and, ideally, a case where it came out “not effective” and the action was sharpened.
• The origin of the cases: from complaints, from internal audits (9.2), from nonconforming outputs (8.7) — do they flow together?
• The treatment of recurring causes in the management review (9.3).

Common traps

• Correction confused with corrective action. The part reworked, the box ticked, the cause never touched — the most common and most expensive error of the clause. The symptom is gone, the process unchanged.
• The sham cause. “Employee error” as the cause and “reprimanded again” as the action. Almost never is the person the cause; almost always it is the process that let the error through. The “five whys” lead past the reprimand.
• Closed without effectiveness. The file says “done” because the action was implemented — not because it worked. Exactly this gap the auditor checks first.
• The permanent concession as a substitute. Releasing the same deviation “as an exception” again and again (8.7) instead of removing the cause once. Convenient and expensive.
• Everything becomes a corrective action. The other extreme: bureaucracy for every scratch suffocates the system. The standard wants appropriateness, not completeness.
• The orphaned prevention. Because 10.2 no longer names the old preventive action, preventing gets forgotten entirely — yet it has only moved, into risks and opportunities (6.1).

Worked example

At Berger Präzisionsteile GmbH the teaching case begins where 8.7 ended: the blocked milled lot — eleven parts out of tolerance — was the correction; the question after it is the corrective action. Lea runs the “five whys”: why out of tolerance? Tool wear. Why unnoticed? The inspection rhythm was wider spaced than the wear was fast. Why? The inspection interval dated from a time with a different tool. The cause is not “the worker” but an inspection interval that no longer fit. The action: tool-life monitoring for this tool, the inspection interval coupled to the real tool life — owner Marco, date three weeks. The effectiveness check came six weeks later: in the lots made since, not a single borderline case. Only with that was the case closed.

The second case came not from production but from the internal audit (9.2): the outdated setup sheets of the 5-axis machine. Here too two movements — update the sheets at once (correction) and establish a change service, who releases changed sheets in future (corrective action against the cause: there was none). The effectiveness was checked in the next audit and the chain reported as closed in the management review — the same setup-sheet story that runs through the whole manual, here at its factual end. In the certification audit it was exactly this complete chain that convinced the auditor: not that Berger makes no errors, but that every error leaves the process a little better.

← All ISO 9001 topics · To the knowledge hub