Skip to content
S
StayEvident
← All articles
Audits··6 min read

Nonconformity root cause: beyond "human error"

Five whys done honestly, a worked example, and corrective actions that don't recur next cycle.

StayEvidentISO compliance, in practice

“Human error” as a root cause is almost never the end of the analysis — it is where organisations stop because stopping feels complete. The corrective action that follows human error as root cause is reliably some version of retraining, which reliably produces the same nonconformity in the next audit cycle. The five whys technique is not complicated, but it requires the discipline to keep asking past the first uncomfortable answer. When you reach an answer that implicates a system, a process, or a management decision rather than an individual, you have probably found the actual root cause.

What 10.2 asks for

Clause 10.2 of ISO 9001:2015 sets out what happens when a nonconformity occurs, including one arising from a complaint. Paraphrased, you are expected to:

  1. react to it — take action to control and correct it, and deal with the consequences;
  2. evaluate whether action is needed to remove the cause, so it does not happen again or elsewhere — by reviewing it, determining its causes, and checking whether similar nonconformities exist or could occur;
  3. implement whatever action is needed;
  4. review the effectiveness of the corrective action;
  5. update the risks and opportunities you determined during planning (clause 6.1), if necessary;
  6. make changes to the management system, if necessary.

Corrective actions should be appropriate to the effects of the nonconformity, and you retain documented information on the nature of the nonconformity, the actions taken, and the results. ISO/IEC 27001:2022 has an equivalent requirement, also at clause 10.2, with the same basic shape.

Two things in that list are routinely skipped. The first is the “or elsewhere” part of step 2: if the cause is a weak procedure, the same weakness may exist in a sister process that has not failed yet. The second is step 4, which is covered further down.

It is also worth separating 10.2 from clause 8.7, control of nonconforming outputs. Clause 8.7 deals with the product or service itself — segregating it, correcting it, returning it, getting a concession, telling the customer — and with recording what was decided and who authorised it. That is the disposition. Clause 10.2 deals with why it happened. A nonconforming batch can be fully dispositioned under 8.7 and still need a corrective action under 10.2. Keep the two on the same record, but do not let finishing one feel like finishing the other.

The replacement test

A useful test: if you removed the individual involved and replaced them with a competent person who had never seen this process, would the nonconformity recur? If yes, the root cause is systemic. Common systemic causes that hide behind “human error”:

  • a procedure that describes the ideal-case path without addressing exceptions;
  • a control that depends on tribal knowledge that was never documented;
  • a workload distribution that makes the compliant path slower than the non-compliant one.

Corrective actions that address these causes — rewriting the procedure, documenting the exception handling, redesigning the process flow — are far more likely to prevent recurrence than another training session.

None of this means people never make mistakes. It means that in a working management system, a single person’s slip should be caught or made difficult. If one slip was enough to produce the nonconformity, the question is why the system allowed it.

A worked example

Here is a hypothetical case. A small machining shop ships a batch of brackets to a customer. The customer rejects the batch because a critical bore is out of tolerance. The shop raises an NCR, quarantines the remaining stock, and agrees a rework with the customer — that is the 8.7 side done. Now the 10.2 side.

Why? Answer
1. Why was the bore out of tolerance? The operator set up the machine using the previous revision of the drawing.
2. Why did they use the previous revision? A printed copy of the old revision was in the job folder at the machine.
3. Why was an old revision in the job folder? Job folders are reused between repeat orders, and nobody removes superseded drawings.
4. Why does nobody remove them? The document control procedure covers issuing new revisions to the system, but says nothing about printed copies on the shop floor.
5. Why doesn’t it? The procedure was written when all drawings were viewed on screen; printing at the machine started later and the procedure was never updated.

The tempting stop is at why 1: operator error, retrain the operator. The operator did exactly what the job folder told them to do. A competent replacement would have done the same thing.

The real root cause is at why 4 and 5: the document control procedure does not cover printed copies, and nobody reviewed it when the way drawings were used changed. That suggests a corrective action along these lines:

  • update the document control procedure to cover printed copies — mark them uncontrolled, or date-stamp them with a short validity;
  • add a step to job folder preparation to remove superseded drawings;
  • check other job folders for the same problem (the “elsewhere” in 10.2);
  • add “changes to how documents are used” to the triggers for procedure review.

It also suggests a risk register entry, if one did not already exist, for uncontrolled document copies — which is the 6.1 update the clause asks you to consider.

Five whys is not always five. Sometimes you reach a systemic cause at three; sometimes the chain branches and you need to follow two lines. The number matters less than the stopping rule: stop when the answer is something the organisation controls and can change, not something a person did.

Writing the corrective action record

For the corrective action record itself, the minimum effective content is: the root cause statement, the corrective action taken, who verified the action was implemented, and the date of verification. A few habits make those records hold up better at audit:

  • Write the root cause as a statement about the system. “The document control procedure does not address printed copies at point of use” is a root cause. “Operator used wrong drawing” is a description of the event.
  • Link the action to the cause. Each action should obviously address the stated root cause. If you cannot see the connection, neither will the auditor.
  • Record the extent check. Even a one-line note — “checked 12 other active job folders, two had superseded drawings, removed” — shows you considered whether the problem existed elsewhere.
  • Keep the containment and the correction separate from the corrective action. Reworking the batch fixes this nonconformity; changing the procedure prevents the next one. Both belong on the record, labelled for what they are.

Effectiveness: schedule it when you close

Effectiveness reviews are required by clause 10.2. Scheduling the effectiveness check at the time you close the corrective action, rather than leaving it open-ended, is the single habit change that most reliably produces follow-through.

Decide what “effective” means before you check. For the machining shop, that might be: no recurrence of wrong-revision setups across the next three months of repeat orders, and a spot check of job folders finding no superseded drawings. Set the date, assign an owner, and when the date arrives, look at the evidence. If the problem has recurred, the corrective action was not effective — reopen it and go back to the analysis rather than raising a fresh NCR that hides the link.

An effectiveness check that simply says “no recurrence noted” with no indication of what was looked at is weak evidence. One that says what was checked, over what period, and what was found is strong.

In StayEvident, NCRs sit in a register with a managed list of sources and a recorded disposition trail, and corrective actions are tracked as CAPAs through a lifecycle to closure, so the line from event to cause to verified action stays in one place. The registers documentation has the details.