Major and minor nonconformities, and the six-month clock behind one of them

A major nonconformity is one that affects the capability of the management system to achieve its intended results. A minor is one that does not. That is the whole distinction, and it is more precise than the informal version people carry around — that majors are big problems and minors are small ones.

The difference matters because it explains gradings that otherwise look inconsistent. A single missed access review is a minor even though unauthorised access is a serious risk, because one lapse does not mean the system cannot work. An internal audit programme that was never run is a major even though nothing has gone wrong yet, because without it the management system has no mechanism to find its own failures. Severity of the underlying risk is not the test; capability of the system is.

ISO/IEC 17021-1 also gives auditors grounds to classify something as major where there is significant doubt that effective process control is in place, or that outputs will meet requirements. That is a judgement, and it is one accreditation exists to keep honest.

This is the provision most worth knowing in advance, because it changes how you should react to a list of small findings.

A number of minor nonconformities against the same requirement or issue can demonstrate a systemic failure, and on that basis be raised as a major. Four separate records missing from four different months is not really four independent lapses — it is evidence that the process for producing that record does not reliably run.

So the instinct to fix each minor in isolation and move on is the wrong one. When several findings cluster on one requirement, the useful response is to treat them as one problem with a common cause and say so, because an auditor looking at the same cluster is asking whether it is systemic. Arriving with that analysis already done is considerably better than having it proposed to you.

Here is the consequence of a major that is rarely spelled out. If the certification body cannot verify that corrections and corrective actions for a major nonconformity have been implemented within six months after the last day of Stage 2, it must conduct another Stage 2 audit before it can recommend certification.

Not another look at the finding — another Stage 2. The full second-stage audit again, with its fees and its scheduling, because too much time has passed for the original evidence to still describe the system.

In practice six months is generous for most majors and tight for the ones that require a process to run before it can be evidenced. If your major is "no internal audit programme", closing it means actually conducting an internal audit, acting on what it finds, and holding a management review — a sequence with real elapsed time in it. Start that immediately rather than after the report arrives.

At recertification the timing works differently and is stricter in one respect: time limits for correcting a major are defined and must be completed before the existing certification expires. The clock is your certificate’s expiry date rather than a six-month window.

Almost never the technical controls. Auditors find misconfigured things, incomplete asset inventories and patching gaps constantly, and those are usually minors — they are lapses within a system that is otherwise working.

The majors cluster in the mandatory clauses, and the same three come up repeatedly: no internal audit performed, no management review held, and a risk assessment that exists as a document but was never actually run as a process. Each one removes a mechanism the management system needs in order to function, which is exactly what the definition of a major describes.

The pattern is worth internalising because it inverts where most teams put their preparation effort. The technical work feels like the real work and produces minors. The governance work feels like paperwork and is where the certificate-blocking findings live.

Every nonconformity needs two things that are easy to conflate: the fix, and the reason it happened. Repairing the instance without addressing the cause is the most common reason a closure is rejected and a finding reappears at the next audit — which is the point at which a recurring minor starts looking systemic.

Practically: correct the specific instance, work out why the process allowed it, change the process, and keep evidence of all three with dates. An auditor verifying closure is checking whether the system now prevents recurrence, not only whether the symptom is gone.

And treat the dates as part of the evidence. Closure verification is about what happened and when, so a corrective action with no record of when it was implemented is difficult to accept however genuinely it was done.