Common ISO 27001 Nonconformities and How to Address Them

Priya Nair found out about the problem on a Tuesday afternoon, in the fifteen minutes between the closing meeting of her Year 2 surveillance audit and a call with the customer whose contract depended on it.

Priya is the CISO of Vantage Health Analytics, a 210-person company that processes claims data and risk-scoring analytics for regional hospital networks. Eighteen months earlier, Vantage had closed a $4.2 million multi-year agreement with a hospital system in the Midwest, and the agreement had one non-negotiable clause: continuous ISO/IEC 27001 certification, with a 30-day cure period if certification lapsed or was suspended. It was the kind of clause Priya's team had built the whole compliance calendar around.

The surveillance audit closing meeting did not go the way she expected. The auditor, a methodical veteran named Marcus Webb from Vantage's certification body, raised three findings. One was major: Vantage's Statement of Applicability listed control 8.16 (Monitoring activities) as implemented, but the SIEM contract that was supposed to provide that monitoring had lapsed four months earlier and nobody had escalated it — the control existed on paper and nowhere else. Two were minor: privileged access rights hadn't been reviewed in the prior two quarters (control 8.2), and the last internal audit report was six weeks late and had been conducted by the same manager whose function it audited (Clause 9.2). None of these were exotic. All three were avoidable. And under the terms of Vantage's certificate, a major nonconformity left open past the corrective action deadline could trigger a certificate suspension — which, under the hospital contract's cure clause, would put $4.2 million of annual revenue on a 30-day countdown.

Priya's team closed all three within five weeks, with root-cause corrective actions the auditor accepted without a follow-up visit. But the five weeks were expensive, stressful, and entirely preventable — and that's the pattern I've watched play out, with different numbers attached, across roughly 200 ISMS engagements in fifteen-plus years of doing this work. The nonconformities that put certifications and contracts at risk are almost never novel. They cluster around the same dozen or so clauses and controls, year after year, company after company. This article is the list — what auditors actually write up, why it keeps happening, whether it's typically major or minor, and exactly how to close it in a way that holds up.

Who this is for

This is written for ISMS managers, CISOs, compliance leads, and internal auditors who are either preparing for a Stage 2 or surveillance audit and want to pre-empt the findings, or who are staring at a nonconformity report right now and need to write a correction and corrective action that an external auditor will actually accept. You'll walk away with a clause-by-clause and control-by-control map of the most common findings, a working definition of major versus minor and correction versus corrective action that you can apply immediately, a self-check you can run before an auditor ever shows up, and templates for the language that turns a nonconformity into a closed file rather than a recurring one.

Nonconformity Basics: Major, Minor, Correction, and Corrective Action

Before you can fix nonconformities well, you need the vocabulary right — auditors use these terms precisely, and sloppy responses that blur the distinctions are themselves a common reason corrective actions get rejected. If any of the terminology below is unfamiliar, our ISO 27001 glossary of terms is worth keeping open alongside this section.

A nonconformity is a finding that a requirement — from Clauses 4 through 10 of ISO/IEC 27001:2022, from your own ISMS documentation, or from an applicable control listed as implemented in your Statement of Applicability — is not being met. Auditors (and most certification bodies, following IAF and accreditation guidance) classify nonconformities as major or minor, and the distinction drives both the deadline you're given and whether your certificate is at risk.

A minor nonconformity is typically an isolated lapse: a single missed review, one control operating inconsistently, a document that's out of date in one place. It doesn't, by itself, suggest the management system has broken down. A major nonconformity is different in kind, not just degree: it's a systemic failure, the complete absence of a required process, a control that exists on paper but isn't operating at all, or — critically — an accumulation of related minor findings that together demonstrate the ISMS isn't functioning as a system. Vantage's monitoring gap was major precisely because the control had stopped operating entirely and nobody had noticed for four months; the privileged access review lapse was minor because it was a single missed cycle, not evidence the access-review process didn't exist.

The consequence differs sharply. A major nonconformity generally must be corrected and the corrective action verified — often through evidence review or a focused revisit — before a certificate can be issued or maintained; left unresolved past the deadline (commonly 90 days, though certification bodies vary), it can suspend or block certification. A minor nonconformity is usually tracked and verified at the next scheduled audit, with more room to demonstrate the fix is working before anyone re-checks.

Separately, and just as important, Clause 10 requires you to distinguish a correction from a corrective action. A correction is the immediate fix — you run the overdue access review, you re-enable the SIEM feed, you reissue the policy with the current version number. It addresses the symptom. A corrective action addresses the cause — why did the review lapse, why did nobody notice the monitoring feed had died, why was the audit not independent — and changes something structural (a calendar trigger, an escalation rule, an audit rotation policy) so the same failure can't quietly recur. Clause 10.2 requires both: react and correct, then evaluate the cause, implement action to eliminate it, and verify the action actually worked. Auditors reject corrective actions constantly for exactly one reason: the organization did the correction and stopped there, treating "we fixed it" as equivalent to "we fixed why it happened."

"The single fastest way to turn a minor finding into a major one at the next audit is to submit a corrective action that's really just a correction wearing a corrective-action label. I can tell within thirty seconds of reading the response whether root cause was actually investigated." — Marcus Webb, Lead Auditor, Meridian Assurance Certification Body

The 14 Nonconformities I See Most Often

What follows is drawn from patterns across roughly two hundred ISMS engagements, weighted toward the findings that recur most consistently across Stage 2 and surveillance audits, regardless of industry or certification body. I've grouped them by the clause or Annex A theme they most commonly attach to, though in practice many findings straddle two or three requirements at once — a scope problem, for instance, almost always drags a risk assessment problem behind it.

1. Scope Doesn't Match Operational Reality (Clause 4.3)

What it looks like: The ISMS scope statement names three business units and two data centers, but the organization has since launched a fourth product line, migrated to a cloud provider, or acquired a subsidiary — and the scope document was never updated. Auditors catch this by cross-referencing the scope against the asset inventory, the org chart, or simply asking what the company does now versus what the scope says it does.

Why it happens: Scope is usually written once, early, under deadline pressure to get to Stage 1, and then treated as a fixed artifact rather than a living one. Nobody owns the trigger to revisit it when the business changes.

Severity: Usually major when the gap is substantial — an entire product line or data flow is processing information the ISMS was never designed to protect. Minor when it's a narrow drift, like a single new office location not yet reflected.

The fix: Correction is straightforward — update the scope statement to reflect current operations, interfaces, and dependencies, referencing Clause 4: Context of the Organization and its requirement to consider internal/external issues and interested-party requirements. The corrective action is what prevents recurrence: tie scope review to your change-management process and your management review agenda, so that "did anything change that affects scope?" is a standing question rather than an annual afterthought.

2. Leadership Commitment and Management Review Aren't Evidenced (Clauses 5.1 and 9.3)

What it looks like: The organization can describe management's commitment to information security in interviews, but there's no documented management review — or the review happened but skipped required inputs like the status of corrective actions, audit results, or risk assessment outcomes. Auditors ask for review minutes and check them against the Clause 9.3 input list; a review that's really just a fifteen-minute slide deck with no discussion of nonconformity trends is a common target.

Why it happens: Leadership genuinely supports the ISMS, but the documented, structured review that Clause 9.3 requires gets folded into a broader ops meeting and loses its required inputs and outputs (decisions, resource needs, opportunities for improvement).

Severity: Minor if reviews happen but are thin on required inputs; major if no management review occurred at all during the audit period, since it signals leadership isn't actually steering the ISMS.

The fix: Correction: hold (or properly document) the missed review with all required inputs and outputs captured. Corrective action: build a management review template mapped directly to the Clause 9.3 input list — audit results, feedback from interested parties, risk assessment/treatment status, nonconformities and corrective actions, monitoring results, opportunities for improvement — so gaps are structurally impossible to skip. This is distinct from Annex A control 5.1 (Policies for information security), which governs the policy document itself rather than the leadership review process; auditors do sometimes conflate the two in conversation, and it's worth clarifying the difference when you respond, since they're addressed by different evidence.

"I've stopped accepting 'leadership is very supportive' as evidence. Show me the minutes, show me the inputs, show me a decision that came out of it. If the review didn't produce a decision, it wasn't a management review — it was a meeting." — Grace Lindqvist, Head of Compliance, NordPeak Financial

3. Risk Assessment Is Inconsistent or Not Kept Current (Clause 6.1.2)

What it looks like: The risk register exists, but scoring is inconsistent between assessors (one rates "likelihood" on a 1–5 scale, another uses high/medium/low with no defined mapping), new assets or systems introduced since the last assessment cycle never got risk-assessed, or the methodology described in the risk assessment procedure doesn't match what the register actually shows.

Why it happens: Risk assessment is often done as an annual sprint by one or two people rather than a continuous, criteria-driven process baked into change management. When ownership moves between people or teams, methodology drifts.

Severity: Typically minor for isolated inconsistency; major if the risk assessment clearly hasn't been updated to reflect known changes (new cloud provider, new data type, post-incident reassessment) and the register is stale enough that it's no longer a credible basis for the Statement of Applicability.

The fix: Correction: reassess the affected assets or scenarios using the documented methodology and update the register. Corrective action: tie risk (re)assessment to defined triggers — new system onboarding, significant incidents, M&A, annual cycle — and require a documented consistency check (a second reviewer, a scoring rubric) so scoring doesn't silently drift between assessors. For a deeper look at where risk assessments typically go wrong, see common ISO 27001 risk assessment mistakes — scope drift and inconsistent scoring are two of the most frequent.

4. The Statement of Applicability Doesn't Match Risk Treatment, or Justifications Are Missing (Clause 6.1.3)

What it looks like: A control is marked "applicable, implemented" in the SoA, but there's no corresponding entry in the risk treatment plan explaining why it was selected, or the inclusion/exclusion justification column is copy-pasted boilerplate ("applicable to our environment") rather than a reasoned statement tied to actual risk. Sometimes it runs the other way: the risk treatment plan calls for a control the SoA doesn't list at all.

Why it happens: The SoA is frequently built as a compliance checklist against the 93 Annex A controls rather than as the direct output of the Clause 6.1.3 risk treatment process it's supposed to document. Once the two documents are created by different people at different times, they drift apart.

Severity: Usually minor if the mismatch is a documentation gap with the control genuinely in place; major if it reveals a control claimed as implemented that isn't actually addressing the risk it's meant to treat — which shades into the "controls that don't operate" finding covered later in this list.

The fix: Correction: reconcile the SoA against the current risk treatment plan, entry by entry, and write specific justifications tied to identified risks rather than generic language. Corrective action: establish a single source of truth — the risk treatment plan drives the SoA, not the reverse — with a change-control step that updates both documents together whenever either changes. Our earlier guide to building the Statement of Applicability walks through structuring justifications so they hold up under audit scrutiny.

5. Information Security Objectives Aren't Measurable (Clause 6.2)

What it looks like: Objectives read like aspirations — "improve security awareness," "reduce risk exposure" — with no defined metric, target, timeframe, or owner. Clause 6.2 requires objectives to be measurable (where practicable), monitored, communicated, and updated, and auditors will ask directly: "how do you know if you've met this objective?"

Why it happens: Objectives get written once during initial certification to satisfy a checklist requirement, then never revisited or connected to actual monitoring data.

Severity: Almost always minor on its own, but it compounds quickly with the Clause 9.1 monitoring gap described below, since unmeasurable objectives usually mean there's nothing being tracked against them.

The fix: Correction: rewrite objectives with a specific metric, numeric or dated target, and named owner — e.g., "95% of staff complete security awareness training within 30 days of hire, tracked monthly by HR/Security" rather than "improve awareness." Corrective action: require every new objective proposed at management review to pass a simple test before adoption — can it be measured, by whom, and how often — so vague objectives never make it into the ISMS in the first place.

6. Competence and Awareness Evidence Is Missing (Clauses 7.2 and 7.3)

What it looks like: The organization can describe its security training program, but can't produce records showing who completed it, when, or with what result. Or, more specifically for Clause 7.2, roles with defined security responsibilities (developers, system admins, the ISMS manager) have no documented competence criteria or evidence they meet them — no certifications, no role-specific training records, nothing beyond "they've been doing this for years."

Why it happens: Awareness training is frequently delivered (a lunch-and-learn, an onboarding video) without a tracking system that ties completion to individuals, and competence is treated as self-evident from job title rather than documented against defined criteria.

Severity: Typically minor when training happens but records are incomplete; can become major if entire categories of staff (e.g., all contractors, or an entire department) have no awareness evidence at all, since it suggests the process doesn't reach a meaningful population.

The fix: Correction: pull together whatever completion evidence exists (LMS exports, sign-in sheets, quiz scores) and backfill gaps with makeup sessions. Corrective action: move training tracking into a system that automatically flags non-completion (an LMS with manager escalation, or even a simple tracked spreadsheet with calendar triggers), and define explicit competence criteria for security-relevant roles so evidence of meeting them can be produced on demand, not reconstructed after the fact.

7. Document and Version Control Failures (Clause 7.5)

What it looks like: Two versions of the same policy circulating with different content, a procedure referenced in the risk treatment plan that was superseded six months ago but never withdrawn, documents with no approval date or owner, or documented information that isn't "available and suitable for use" — for instance, a policy stored somewhere staff can't actually access. Clause 7.5 requires documented information to be controlled: identified, formatted, reviewed, approved, and protected from unintended change.

Why it happens: As the ISMS matures and documents multiply — policies, procedures, registers, records — informal version control (email attachments, shared drives with no checkout process) breaks down faster than most teams expect.

Severity: Minor in most cases (an isolated stale document); can become major if version confusion has led staff to actually follow outdated guidance in a way that created real exposure, or if it's systemic across most of the document set.

The fix: Correction: identify and retire or update every superseded document version in circulation, and confirm current versions are accessible to everyone who needs them. Corrective action: implement a single controlled repository with version numbering, mandatory review dates, and an approval workflow — even a disciplined SharePoint or Confluence structure with enforced check-in/check-out beats an uncontrolled shared drive. Our guide to ISO 27001 document control and records management covers the retention and versioning discipline auditors expect to see, and the ISO 27001 Mandatory Documents Checklist is a useful cross-check for what needs to exist in the first place.

"Document control findings are the ones people are most embarrassed by, because they feel so avoidable in hindsight. It's rarely one bad document — it's that nobody owns the repository as a whole." — Elena Cho, ISMS Manager, Bright Harbor Logistics

8. Internal Audits Aren't Conducted, Aren't Complete, or Aren't Independent (Clause 9.2)

What it looks like: The internal audit program has gaps in coverage (some clauses or controls haven't been audited within the certification cycle), audits run late against the planned schedule, or — the most common variant — the person conducting the internal audit of a function also manages or performs that function, violating the Clause 9.2 requirement for audits to be objective and impartial.

Why it happens: In small-to-mid-size organizations, the pool of people qualified to audit security processes overlaps heavily with the pool of people who run them. It's genuinely hard to find someone both competent and independent, so companies default to "close enough" — the IT manager audits IT operations, the security lead audits their own program.

Severity: Almost always major when independence is compromised or coverage has real gaps, because Clause 9.2 is a core mechanism the whole ISMS relies on for self-detection; a compromised internal audit function undermines the credibility of everything else in the system.

The fix: Correction: complete any missing audits and, where independence was compromised, have the affected area re-audited by someone genuinely independent (a peer from another department, a rotated auditor, or an external resource). Corrective action: build an audit program with cross-functional rotation (Team A audits Team B's area and vice versa) or bring in outside internal-audit support for smaller organizations where true internal independence isn't achievable; document the independence rule explicitly in the audit procedure so it can't be quietly waived under time pressure. Our ISO 27001 Internal Audit: Planning, Execution, and Reporting guide covers building a rotation model that holds up, and the Internal Audit Checklist and Internal Audit Report Template are worth building your program around directly.

9. Monitoring, Measurement, and Metrics Are Missing or Not Analyzed (Clause 9.1)

What it looks like: The organization collects some data (ticket counts, patch compliance percentages, login logs) but has never formally defined what needs to be monitored, how it will be measured, when, by whom, and how results will be analyzed and evaluated — the specific elements Clause 9.1 requires. Metrics exist in isolation without being tied back to the objectives set under Clause 6.2 or used to inform management review.

Why it happens: Teams collect operational data as a matter of course but never formalize it into the structured monitoring program the standard expects, so there's plenty of raw data and no analysis trail connecting it to ISMS performance.

Severity: Minor if some monitoring exists but is incomplete or informal; major if there's effectively no monitoring program at all connecting metrics to objectives and management review.

The fix: Correction: document the monitoring approach already happening informally, and fill obvious gaps against the objectives it should be measuring. Corrective action: build a formal monitoring plan — what's measured, method, frequency, responsible party, analysis approach — reviewed at each management review cycle, so metrics collection and objective-tracking are the same activity rather than two disconnected ones. This is a natural companion fix to the Clause 6.2 objectives finding above; fixing one without the other rarely satisfies an auditor.

10. Corrective Actions Aren't Closed, or Effectiveness Is Never Checked (Clause 10.2)

What it looks like: A corrective action log shows items opened months or years ago still marked "in progress," or items marked "closed" with only a correction on file and no evidence the underlying cause was addressed or that the fix actually worked. This is, fittingly, one of the most common findings of all — an organization's own nonconformity-handling process becoming a nonconformity in itself.

Why it happens: Corrective actions get logged in the heat of the moment but ownership and follow-up tracking fade once the immediate pressure (an audit, an incident) passes. Nobody schedules the effectiveness check that Clause 10.2 explicitly requires — the step where you go back after enough time has passed and confirm the problem hasn't recurred.

Severity: Minor for a handful of stale items with otherwise-functioning processes; major if the pattern is systemic — a backlog of unclosed items, or a habit of closing corrective actions without any effectiveness verification, since that failure undermines the entire improvement loop the standard is built around.

The fix: Correction: triage the backlog, close what's genuinely done, and reopen or escalate what isn't. Corrective action: assign every corrective action a due date, an owner, and a scheduled effectiveness-check date at the point it's logged — not as an afterthought — and report open/overdue corrective actions as a standing item at management review so the backlog can't quietly grow unnoticed. This full nonconformity-to-closure cycle is the subject of our Clause 10 guide referenced earlier in this article.

"A corrective action log full of 'in progress' items older than a year tells me more about the health of the ISMS than almost any other single document I ask for." — David Osei, Internal Audit Lead, Ferro Components Group

11. Access Rights Aren't Reviewed on Schedule (Controls 5.18 and 8.2)

What it looks like: The access control policy commits to quarterly (or some defined-frequency) access reviews, but the evidence trail shows gaps — a skipped quarter, reviews that only cover standard user access and never touch privileged/administrative accounts, or reviews that happen but produce no documented follow-up when excess access is found. This is one of the single most frequently cited findings in ISO 27001 audits generally, because it's a control that requires ongoing operational discipline rather than a one-time setup.

Why it happens: Access reviews are tedious, manual in many organizations, and easy to deprioritize when there's no automated reminder or accountable owner. Privileged accounts in particular often live outside the standard HR-driven joiner-mover-leaver process, so they're the ones most likely to be forgotten — which is exactly why control 8.2 exists as a distinct control from the general access rights requirement in 5.18.

Severity: Minor for a single missed cycle with no evidence of actual excess access; can shift toward major if privileged/admin accounts specifically are unreviewed for an extended period, or if a review failure is discovered to have left a departed employee with active access.

The fix: Correction: run the overdue review immediately, covering both standard and privileged access, and revoke anything that shouldn't still be active. Corrective action: automate the review cadence with calendar-triggered tickets assigned to a named owner, require sign-off evidence (not just "review completed" but who reviewed what and what changed), and separate the privileged-access review cycle from the standard-user cycle so it can't be silently absorbed and skipped. See our guides on access control under controls 5.15–5.18 and privileged access rights management under control 8.2 for the review-cadence models that hold up under audit.

12. Supplier and Third-Party Controls Are Weak or Unevidenced (Controls 5.19–5.22)

What it looks like: Vendor contracts don't contain the security requirements the organization claims to impose, there's no record of security due diligence before onboarding a new supplier with data access, or — most commonly — there's no ongoing monitoring of supplier security performance after the contract is signed. The initial due-diligence questionnaire exists, but nothing tracks whether that supplier's security posture has changed, whether they've had an incident, or whether their subcontractors (the ICT supply chain angle in control 5.21) introduce new exposure.

Why it happens: Supplier security is often owned by procurement or legal, who focus on commercial and legal terms, while the security team owns the technical controls but has limited visibility into contract renewals, new vendor onboarding, or supply-chain changes. The handoff between these functions is where evidence gaps open up.

Severity: Minor if due diligence happened but ongoing monitoring is thin; major if there's no evidence of security requirements in supplier agreements at all for suppliers with access to sensitive information, since that's a foundational gap in the supply chain.

The fix: Correction: retroactively document security terms for existing critical suppliers (via addendum if needed) and complete overdue due-diligence reviews. Corrective action: build a supplier security lifecycle that security, procurement, and legal jointly own — security requirements baked into contract templates from the start, a tiered review cadence based on supplier risk level, and a defined process for reassessing suppliers after security incidents or subcontractor changes. Our supplier relationship security guide covering controls 5.19–5.23 walks through building that lifecycle end to end.

"Supplier security findings are almost never about a bad contract clause. They're about nobody being able to tell me, on the spot, when the last time was that a critical vendor's security posture was actually re-checked." — Tom Alvarez, Principal Consultant, PentesterWorld Advisory Partners

13. Logging and Monitoring Have Gaps (Controls 8.15 and 8.16)

What it looks like: Logging is enabled on some systems but not others (often missing on newer cloud services or third-party SaaS platforms added after the original logging design), log retention doesn't match the policy's stated period, or — as in Priya's opening story — a monitoring capability is listed as active in the SoA when the underlying tool or feed has actually lapsed. Auditors will frequently ask to see a log sample and a monitoring alert from within the audit period as live evidence, not just a policy describing what should happen.

Why it happens: Logging and monitoring infrastructure is added incrementally as systems are adopted, and coverage silently falls behind as the environment grows; monitoring tool licenses lapse or configurations get quietly changed during unrelated IT projects, and nobody owns a check that confirms the feed is still live.

Severity: Minor if the gap is a small subset of low-risk systems; major if a core system lacks logging entirely, if log retention materially fails to meet policy or legal requirements, or if a control marked implemented in the SoA has actually stopped functioning — this last variant is one of the most serious findings an auditor can raise, because it points to a false representation of control status, not just an operational gap.

The fix: Correction: re-enable or extend logging/monitoring coverage to the affected systems immediately and confirm the fix with a live data sample. Corrective action: maintain a logging/monitoring coverage inventory that's reviewed alongside the asset inventory (so new systems can't go live without logging being part of the onboarding checklist), and set up a health-check alert on the monitoring tooling itself — monitoring the monitor — so a lapsed feed triggers its own alarm rather than being discovered four months later by an auditor. Our logging and monitoring guide for controls 8.15–8.16 covers the coverage-inventory approach in detail.

14. No Evidence the Controls Actually Operate (Cross-Cutting)

What it looks like: This is the finding that sits underneath many of the others above, and it deserves calling out on its own: a policy exists, a procedure describes a control, the SoA lists it as implemented — but when the auditor asks for a live example, a log entry, a ticket, a completed form, an actual instance of the control operating during the audit period, there isn't one. The control is designed but not demonstrably running.

Why it happens: Organizations build documentation to pass Stage 1 (which focuses heavily on design) and underinvest in the operational evidence trail Stage 2 and every surveillance audit afterward actually test. Documentation effort front-loads; evidence-generation habits don't get built at the same time.

Severity: Frequently major, because it undermines confidence not in one control but in the reliability of the SoA and risk treatment plan as a whole — if one claimed control turns out to be undemonstrated, an auditor will reasonably widen the sample and ask what else is undemonstrated.

The fix: Correction: for the specific control in question, generate and present current operating evidence immediately. Corrective action: run an internal exercise — sometimes called an evidence audit — well before any external audit, where for every control marked "implemented" in the SoA, someone confirms a real, current, retrievable piece of evidence exists and is stored somewhere retrievable on demand. This single practice, done quarterly, catches the majority of "control exists on paper only" findings before an external auditor ever does.

How to Respond to a Nonconformity So the Auditor Accepts It the First Time

The findings above are common enough that you should assume, going in, that you'll get at least one on any given audit — even mature, well-run ISMS programs do. What separates organizations that close a nonconformity in one cycle from those that get a repeat finding at the next audit is almost never the severity of the original problem. It's the quality of the response. Here's the sequence I walk clients through, mapped directly to what Clause 10.2 requires.

Step 1 — React and correct. Fix the immediate symptom and contain any consequence. If access was left open, revoke it. If a review was missed, run it. Document exactly what was done and when — this is your correction record, and it needs to stand on its own as evidence, separate from anything that follows.

Step 2 — Investigate root cause, not just the immediate trigger. This is where most corrective actions fail. "The reviewer forgot" is not a root cause — it's a restatement of the symptom. Ask why the reminder system didn't work, why there was no escalation when the deadline passed, why one person's memory was the only control preventing failure. A useful discipline here is asking "why" four or five times in sequence until you reach something structural — a missing process, a missing owner, a missing trigger — rather than stopping at "human error." A simple fishbone (cause-and-effect) breakdown across people, process, technology, and documentation categories is often enough to get there without overengineering it. We're planning a dedicated deep-dive on root cause analysis for ISO 27001 nonconformities with worked examples of the five-whys and fishbone methods side by side; until that's published, the discipline above covers the essentials.

Step 3 — Check for recurrence elsewhere. Clause 10.2 explicitly requires evaluating whether similar nonconformities exist or could occur in other parts of the ISMS. If privileged access reviews lapsed in one business unit, check every other unit using the same process. This step is frequently skipped, and auditors notice — a corrective action that only addresses the exact instance found, without checking for siblings, reads as incomplete.

Step 4 — Implement the corrective action. This is the structural fix identified in Step 2: the automated trigger, the ownership reassignment, the new checklist item, the process redesign. Document who owns it, what changed specifically, and when it went into effect.

Step 5 — Verify effectiveness. Set a specific date — weeks or a full cycle out, depending on how frequently the control operates — to confirm the fix actually worked. This is the step most commonly missing from corrective action files, and its absence is one of the most frequent reasons certification bodies push a corrective action back for rework. "We implemented the fix" is not the same claim as "we verified the fix is working," and auditors will ask for the latter.

Step 6 — Close, with the full record intact. A closed corrective action file should let a future auditor (or a future you) reconstruct the whole story: what happened, why, what was fixed immediately, what was fixed structurally, and how you confirmed it held. Keep the record even after closure — Clause 10.2 requires retained documented information as evidence of both the nonconformity and the actions taken.

Vantage Health Analytics' response to the SIEM monitoring gap followed exactly this arc: correction was re-establishing the monitoring feed within 48 hours; root cause turned out to be that the vendor invoice for the SIEM contract had been routed to a finance inbox nobody monitored after a personnel change, so the lapse was silent; the corrective action added the security monitoring stack to a critical-vendor list with dual ownership (finance and security both receive renewal alerts) and a quarterly "is every SoA-implemented technical control still licensed and active" check; effectiveness was verified at 60 and 90 days with a clean bill both times. Marcus Webb closed the finding without a follow-up site visit.

How to Pre-Empt Common Nonconformities: A Self-Check

The cheapest nonconformity is the one you never receive. Before any Stage 2, surveillance, or recertification audit, run this self-check against the fourteen areas above. It takes a half-day for a small ISMS, longer for a complex multi-site scope, and it reliably surfaces the majority of what an external auditor would otherwise find.

Running this self-check twice a year — once mid-cycle and once 60–90 days before any scheduled audit — is the single highest-leverage habit I recommend to clients. It converts nonconformities from surprises into a known, manageable backlog you close on your own schedule rather than an auditor's. Our Certification Readiness Checklist and ISO 27001 Gap Analysis Tool are built around exactly this kind of structured pre-audit review, and both are worth running alongside your internal audit program rather than only before an external visit.

What a Nonconformity Actually Costs

It's worth putting rough numbers next to all of this, because "close it fast" is a much easier priority to sell internally when the cost of not doing so is explicit rather than abstract. The figures below are illustrative — drawn from the range of engagements I've seen rather than any published study — but the relative proportions hold up consistently enough to be useful for budgeting a response.

A minor nonconformity closed cleanly within a normal cycle costs mostly staff time: the hours to correct the issue, investigate root cause, and document the file, typically somewhere in the range of a few days of a single person's time. A major nonconformity closed within the certification body's deadline but requiring a documentation-only verification adds the cost of that verification review, plus the organizational disruption of compressing weeks of structural change into a matter of days. Where costs escalate sharply is when a major nonconformity isn't closed in time and requires a follow-up on-site visit — that's a second audit day (or more) billed at the certification body's day rate, on top of the original engagement, plus the internal cost of preparing for a second audit under time pressure. The steepest cost of all, and the one Vantage Health Analytics was staring down in this article's opening story, is indirect: a certificate suspension tripping a customer contract's compliance clause, where the exposure isn't the audit cost at all but the commercial relationship sitting behind it.

The practical takeaway is that the cost curve isn't linear — it's closer to a step function, with the steepest jump sitting between "closed before the certification body's deadline" and "not closed before it." That's the argument for treating the fourteen-area self-check and the correction-to-effectiveness-check sequence in this article as a standing operational discipline rather than a once-a-year scramble: the cost of running it is small and predictable, while the cost of skipping it is backloaded and, occasionally, severe.

Case Studies

Vantage Health Analytics — from a major NC and a contract on the clock to closure without a follow-up visit. As described at the top of this article, Vantage's Year 2 surveillance audit produced one major finding (SIEM monitoring, control 8.16, marked implemented in the SoA but not operating) and two minor findings (privileged access review lapse, control 8.2; internal audit independence and timeliness, Clause 9.2). With a $4.2 million hospital contract carrying a 30-day cure clause tied to certification status, the team treated the certification body's ~45-day major-finding deadline as the real deadline and worked backward. Corrections were completed within 48–72 hours of the closing meeting for all three findings. Root-cause analysis on the monitoring gap (a mis-routed renewal invoice) led to a dual-ownership renewal-alert process and a quarterly active-license check across every SoA-implemented technical control — a corrective action that also surfaced two smaller licensing gaps nobody had flagged yet. Both minor findings' corrective actions (a calendar-triggered privileged access review with escalation, and an audit-rotation model bringing in a peer from a different department) were implemented within three weeks. All three nonconformities were closed within 35 days, ahead of the certification body's own deadline, and Marcus Webb verified closure through documentation review rather than requiring an on-site revisit — avoiding both the cost of a second audit trip and any risk to the contract's cure-period clock.

Ferro Components Group — a minor finding that recurred and became major because the corrective action addressed the symptom, not the cause. Ferro, a mid-size industrial parts manufacturer, received a minor finding at their first surveillance audit: a quarter's access review had been skipped for a subset of ERP users. Their corrective action, submitted and initially accepted, was "assign someone to run the review each quarter." No automated trigger, no escalation, no change to how the task was tracked — just a manual reassignment. Fourteen months later, at the next surveillance audit, the same gap recurred: the assigned person had left the company, and the responsibility was never formally handed off. Because it was now a repeat finding on the same underlying control with no structural change in between, the auditor classified it as major rather than minor, citing evidence that the prior corrective action had not addressed root cause and the ISMS had not demonstrably improved its ability to prevent recurrence. Ferro's second corrective action — the one that actually held — added the review to an HR offboarding/onboarding trigger list (so role handoffs couldn't silently drop the responsibility) and an automated ticketing system with a hard escalation to the ISMS manager if a review wasn't completed within five days of due date. The lesson Ferro's internal audit lead now repeats internally: a corrective action that depends entirely on one named person remembering is not a corrective action.

Bright Harbor Logistics — pre-emption cutting audit findings by more than half. Bright Harbor, a logistics and freight-visibility SaaS provider, had accumulated five to seven findings (a mix of major and minor) across each of its first two certification audits — consistent with, though on the higher end of, what we see industry-wide. Ahead of their first recertification audit, they adopted the fourteen-area self-check from this article as a standing quarterly exercise owned jointly by the ISMS manager and internal audit lead, rather than a one-time pre-audit scramble. The most valuable discovery from the very first run was that four Annex A controls marked "implemented" in their SoA had no current retrievable evidence — caught internally, months before any external auditor would have found the same gap and likely classified it as major. By the time of the recertification audit, Bright Harbor received two minor findings total, both closed within two weeks using the correction-then-root-cause sequence described above. Their ISMS manager attributes the improvement less to any single fix and more to converting nonconformity-hunting from a reactive, pre-audit fire drill into a routine operational habit.

"The organizations that stop having major findings aren't the ones with more mature technology. They're the ones who found a way to make the self-check boring — a routine quarterly item instead of a crisis exercise the week before an auditor arrives." — Elena Cho, ISMS Manager, Bright Harbor Logistics

The Strategic Close: Nonconformities as a Maturity Signal, Not Just a Compliance Risk

It's tempting to treat nonconformities purely as something to avoid — a box of risk to be minimized before an auditor arrives. I'd push back on that framing a little. How an organization handles a nonconformity is one of the clearest external signals of ISMS maturity there is, and it's a signal your customers, your board, and your own team are all reading, whether or not they use that language.

A company that receives zero findings for years running is not necessarily the most secure company in the room — sometimes it means the internal audit function isn't looking hard enough, or the self-check culture Bright Harbor built hasn't been established yet. A company that receives findings, closes them fast with real root-cause work, and can show a corrective action log with a clean effectiveness-check history is demonstrating exactly what Clause 9 and Clause 10 are actually designed to prove: that the management system detects its own problems and improves. That's a genuinely different, and more valuable, story to tell a hospital-network customer like Vantage's, a bank underwriting a partnership, or a board asking whether the security budget is working — and it's a stronger competitive position than a spotless-looking audit history that nobody has stress-tested.

The practical version of that argument is simple: build the self-check habit before you need it, treat every nonconformity as free information about where your ISMS's structural weak points actually are, and write corrective actions that would survive you explaining them, in plain language, to someone outside your team. Organizations running parallel frameworks see the same discipline pay off across the board — a mature root-cause habit built for ISO 27001 nonconformities is the same muscle that keeps a NIST CSF improvement cycle or a SOC 2 exception log from accumulating unaddressed repeat items. If you're heading into a Stage 2 certification audit for the first time, a surveillance audit in your second or third year, or preparing for your three-year recertification cycle, the fourteen findings in this article are the ones most likely to show up on your report — which means they're also the ones you now have a genuine head start on addressing before they do.

If you want a structured way to work through this before your next audit, PentesterWorld's Certification Readiness Checklist and ISO 27001 Gap Analysis Tool are built to surface exactly these gaps, our Internal Audit Checklist and Internal Audit Report Template are designed to make your internal audit function the toughest reviewer your ISMS ever faces, and The Complete ISO 27001 Implementation Guide walks through building the underlying processes — risk treatment, document control, management review — so that fewer of these findings ever get generated in the first place. Reach out to our team if you'd like a second set of eyes on your ISMS before your next audit finds the gaps for you.