258 auditors voted. Only 11% got it right.
From the “Test Your Auditor IQ” series
Last week I posted a scenario on LinkedIn and asked my network a deceptively simple question: how would you rate this finding?
The poll drew 258 votes, and the split was telling:
A plurality reached for “major.” A meaningful minority saw no problem at all. That spread is the whole point — because with the information given, every one of those answers can be correct. What separates them is context, and context is exactly what the scenario withholds.
This article walks through when each verdict is the right one.
First, a reminder about the auditor’s job
Before we rate anything, it’s worth restating what we are actually there to do — because a lot of the “major nonconformity” reflexes come from forgetting it.
It is not the auditor’s ISMS. Our ob is to assess whether the system complies with the requirements of the standard. We are not the risk owner. We do not decide whether a risk is acceptable — clause 6.1.3 f) places the approval of the risk treatment plan and the acceptance of the residual information security risks squarely with the risk owner. Our job is to evaluate whether the organization has established a system capable of achieving its intended outcome(s) — the exact language of clause 4.1 and of 6.1.1 a) — that meets the needs and expectations of interested parties (4.2) and reaches its information security objectives (6.2), and then to communicate our findings so that top management can determine appropriate action.
So the real question is not “has this server been patched?” It is the one clause 6.1.1 a) puts to us: can the ISMS still achieve its intended outcome(s), or does this situation show that it can’t?
And to answer that, you have to understand the context. The scenario doesn’t give it to us, so a good auditor would ask:
Which systems are unpatched?
What do those systems do?
How important are they to the core business?
What patches are missing — and what do they fix?
How would this affect the organization’s ability to meet its information security objectives?
The answers to those questions move the finding across all four categories. Here’s how.
When it’s a Conformity (11% of voters)
This is the answer most people dismiss too quickly — but it’s defensible, and here’s the reasoning.
ISO/IEC 27001:2022 builds risk acceptance into the system by design. Clause 6.1.2 a) 1) requires the organization to establish risk acceptance criteria as part of its risk assessment process, and clause 6.1.3 f) requires the risk owner to approve the risk treatment plan and accept the residual information security risks. Acceptance is therefore a legitimate, anticipated outcome of the process — not a failure of it.
In this scenario:
The risk owner has approved each extension — consistent with the approval role assigned in 6.1.3 f).
Top management is aware: clause 9.3.2 f) makes the status of the risk treatment plan a required input to management review, and that is exactly where the extensions are being discussed.
Residual risk is visible, tracked, and consciously carried.
If the system in question is, say, an obsolete internal tool with no business criticality, no exposure to customer data, and no bearing on the information security objectives set under 6.2, then the ISMS is behaving exactly as 4.1 and 6.1.1 a) intend. It identified a risk, the right people are aware of it, and they have made an informed, documented decision — within their stated acceptance criteria — to defer treatment.
That is a functioning risk management process operating within its own defined criteria. Demonstrated, ongoing awareness of a knowingly accepted residual risk is conformity — even if the auditor personally would have patched the box months ago.
Remember: controls lose effectiveness, acquisitions get delayed, suppliers slip. Nothing in Clauses 4 to 10 requires every identified risk to be closed on a fixed date. A standard that punished organizations for every open risk would be a standard no organization could ever pass.
When it’s an Opportunity for Improvement (24%)
An OFI is appropriate when the requirements are met — no clause has been breached — but the auditor sees something that could work better. It is a suggestion, not a finding against a “shall.”
Even if treatment was legitimately deferred, three formal extensions over 14 months should make any auditor curious. Some things worth surfacing as an OFI:
The extension process works, but is it too easy to extend? Clause 10.1 obliges the organization to continually improve the suitability, adequacy and effectiveness of the ISMS — a recurring deferral that is never escalated or re-evaluated is a natural improvement target.
The risk acceptance may be appropriate now, but is it being treated as a permanent state by default rather than a conscious, time-boxed decision against the acceptance criteria of 6.1.2 a)?
The risk assessment might warrant a fresh look. Clause 8.2 calls for risk assessments at planned intervals or when significant changes occur; 14 months is long enough for the threat landscape around “unpatched servers” to have shifted, and the auditor can note that without it being a nonconformity.
None of these are breaches of a requirement. They are nudges toward a more robust system — exactly what an OFI is for, and often the most useful thing an auditor can leave behind in this scenario.
When it’s a Minor Nonconformity (22%)
A minor nonconformity is a single lapse, or an isolated failure to meet a requirement, that does not raise doubt about the ISMS’s overall ability to achieve its outcomes.
Here, the issue isn’t the deferral itself — it’s how it was handled. A minor surfaces when a specific “shall” has been missed, but the system is still fundamentally sound. For example:
The extensions are approved, but the risk treatment plan was never updated to reflect the new deadlines. Clause 8.3 requires the organization to implement the information security risk treatment plan and to retain documented information of the results; a plan that no longer matches reality is an isolated failure against 8.3 (and the documented-information control in 7.5).
A corrective action was raised to fix the servers, the deadline passed without effect, and no one verified whether it worked or launched a revised attempt. Clause 10.2 d) requires the organization to review the effectiveness of any corrective action taken — and corrective actions can fail. The requirement isn’t that they always succeed; it’s that you check, and act again if they didn’t. Skipping that review is a clean 10.2 d) gap.
Risk acceptance is happening in practice but the acceptance was never formally made or recorded under 6.1.3 f) — it’s drifting along as an open-but-ignored item rather than a deliberate, risk-owner-approved decision.
In each case there’s a real, evidenced failure against a specific clause — but it’s contained. The machinery of the ISMS is working; one part of it needs tightening. That’s a minor.
When it’s a Major Nonconformity (43% — the plurality)
A major nonconformity is appropriate when the finding shows the ISMS is not capable of achieving its intended outcome(s) — the test set by 4.1 and 6.1.1 a) — or when it otherwise undermines confidence in the management system as a whole.
Now change one fact in the scenario. Suppose the organization is operating a large data center and providing SaaS as its core business, and the unpatched, high-rated servers are part of that production environment.
Suddenly the picture is very different:
The risk strikes directly at the core business. Per the NOTE to clause 5.1, “business” means the activities core to the purpose of the organization’s existence — here, the SaaS platform itself — so the information security objectives established under 6.2 are directly in the line of fire.
“Going to be fixed soon” for 14 months, across three extensions, on a high-rated risk to the primary service suggests clause 8.3 — implement the risk treatment plan — is not actually being met. The plan exists and is being re-dated, but the treatment is never implemented. The process is cataloguing risk, not treating it.
The interested parties identified under 4.2 — customers trusting their data to this SaaS — have requirements the ISMS committed to address. If those are exposed, the system is failing the very test of 4.1: it cannot achieve its intended outcome(s).
This is no longer “an accepted risk on a low-criticality box.” It is evidence that the ISMS cannot deliver its intended outcome(s), and that the risk-acceptance mechanism of 6.1.3 f) is being used to paper over a sustained failure to implement treatment (8.3) on something central to the business. The repeated, normalized deferral — surfacing at management review under 9.3.2 f) without ever driving action under 9.3.3 — is itself the systemic signal.
That’s a major.
The point of the exercise
Look again at the four sections above. The facts in the scenario never changed — what changed was the context we assumed around them. Same unpatched servers, same three extensions, same management review minutes:
Obsolete internal tool, no criticality, deliberate acceptance → Conformity
Sound process, but the extension habit deserves scrutiny → OFI
Acceptance is real but a specific clause was mishandled → Minor
Core SaaS production environment, intended outcomes at risk → Major
This is why “what’s the right answer?” is the wrong question. The right question is the one we ask the auditee: tell me what these systems are, what they do, how much the business depends on them, and what these missing patches would mean for your security objectives.
The standard doesn’t ask us to enforce our own risk appetite. It asks us to judge whether the organization has built a system capable of meeting its intended outcome(s) — and to report what we find so that management can decide. Everything else follows from context.
The clauses that decide it
For reference, here are the requirements that do the work across the four verdicts:
4.1 / 6.1.1 a) — the ISMS must be capable of achieving its intended outcome(s). This is the master test that separates a major from everything else.
4.2 — interested parties’ requirements the ISMS has committed to address.
6.1.2 a) — the organization’s own risk acceptance criteria.
6.1.3 f) — risk owner approval of the treatment plan and acceptance of residual risk (the basis for conformity).
6.2 — information security objectives the risk is measured against.
8.2 / 8.3 — perform assessments when significant changes occur; implement the risk treatment plan.
9.3.2 f) / 9.3.3 — status of the risk treatment plan as a required management review input, and the decisions that review must produce.
10.1 / 10.2 d) — continual improvement, and the duty to review the effectiveness of corrective action taken.
From ZERO to AUDIT-READY in 12 Steps
If you are responsible for an ISO 27001 implementation project, you are fighting a battle against the clock.
The standard tells you WHAT must be done,
but it leaves the HOW entirely to your imagination.
This leaves you staring at a blank map, forced to build an ISMS from scratch while the deadline approaches.
Our ISO 27001 Lead Implementer Framework gives you the Roadmap, Project Plan, Templates and Training to be audit-ready in months, not years.
