If you've just received an audit finding, or you're bracing for one, the next ninety days will decide whether it stays a footnote in your certificate history or becomes the reason your certification gets suspended — and the difference almost never comes down to the severity of the original problem.
I've spent more than fifteen years running ISMS implementations and sitting across the table from certification auditors at over 200 organizations, and if there's one clause in ISO/IEC 27001 that gets treated as an afterthought and then blows up in someone's face six months later, it's Clause 10. Everyone obsesses over the Annex A controls. Almost nobody rehearses what happens the day after an auditor writes up a finding. That's a mistake, because Clause 10 — Improvement — is where certifications are actually won or lost on the second and third audit cycles.
Who This Is For
This article is for the person who just got handed a nonconformity report and doesn't know whether to panic, and for the ISMS manager, compliance lead, or CISO who wants to build a corrective action process that holds up under scrutiny before an auditor ever shows up. It assumes you already have some familiarity with ISO 27001 basics and have been through — or are about to go through — Clause 9 performance evaluation and internal audit.
What You'll Walk Away With
A precise, auditor-defensible understanding of the difference between correction and corrective action — the single most common way organizations sabotage themselves
Clear criteria for distinguishing a minor nonconformity, a major nonconformity, and an observation or opportunity for improvement (OFI)
A working root cause analysis method you can apply the same day a finding lands
A corrective action plan (CAPA) template that satisfies what certification bodies actually check for
An understanding of why "preventive action" disappeared from the standard, and what replaced it
A model for running continual improvement as an ongoing discipline rather than a pre-audit fire drill
The Story That Should Scare You Straight
Daniela Cruz ran information security for Halcyon Freight Systems, a mid-sized logistics SaaS platform with about 240 employees and a customer base that included three Fortune 500 shippers who required ISO 27001 certification as a contract precondition. At her Stage 2 audit, the certification body's lead auditor, sampling access reviews, found that one business unit — customer support — hadn't completed its quarterly access recertification for two consecutive quarters. It was written up as a minor nonconformity: an isolated lapse in an otherwise functioning control.
Daniela's team did what a lot of teams do under deadline pressure. They ran the overdue access review, cleared the backlog, attached the completed spreadsheet as evidence, and closed the finding. That's a correction — it fixes the immediate symptom. It is not a corrective action, because nobody asked why the review had been skipped twice in a row.
The answer, had anyone looked, was mundane: the person responsible for scheduling the review had left the company, and the task lived only in her personal calendar, not in any system of record. Nobody reassigned it. Eight months later, at surveillance audit, the same auditor sampled the same control area — because auditors always resample previously nonconforming areas — and found the exact same gap, this time affecting two departments instead of one, over three quarters instead of two. A recurring, unaddressed root cause after a documented corrective action is close to the textbook definition of a systemic failure. The finding escalated to a major nonconformity, Halcyon was given 90 days to remediate or face certificate suspension, and two of those Fortune 500 customers put a compliance hold on contract renewal pending resolution — a hold that cost Halcyon roughly $340,000 in delayed revenue recognition and no small amount of executive credibility.
Nothing about the original problem was catastrophic. What escalated it was a corrective action that was cosmetic instead of structural. That is the entire subject of this article.
"The auditors don't fail you for having problems. Every organization has problems. They fail you for having the same problem twice after you told them, in writing, that you fixed it." — Tomasz Wieczorek, Lead Auditor, accredited certification body
Clause 10, As Written — And the Reorder Nobody Warns You About
Before we go further, get the actual text straight, because a surprising number of consultants and even some auditors still cite the 2013 clause order from memory.
In ISO/IEC 27001:2013, the improvement clause was structured as: - 10.1 Nonconformity and corrective action - 10.2 Continual improvement
In ISO/IEC 27001:2022, the sub-clauses were reordered — not reworded in any substantive way, but flipped in sequence: - 10.1 Continual improvement - 10.2 Nonconformity and corrective action
Aspect | ISO 27001:2013 | ISO 27001:2022 |
|---|---|---|
First sub-clause | 10.1 Nonconformity and corrective action | 10.1 Continual improvement |
Second sub-clause | 10.2 Continual improvement | 10.2 Nonconformity and corrective action |
Substantive requirements | Same core requirements | Same core requirements, reordered presentation |
Rationale for change | — | Aligns with Annex SL harmonized structure used across ISO management system standards |
Practical impact on you | — | None on what you must do; matters for document references and audit checklists |
If you're maintaining a document map, a clause-to-control crosswalk, or training material inherited from a 2013-era implementation, this is exactly the kind of detail that quietly goes stale and then makes you look sloppy in front of an auditor when your internal documentation says "10.1 Nonconformity" and the standard says otherwise. If you want the fuller picture of what else moved between versions, see our dedicated comparison of ISO 27001:2013 vs ISO 27001:2022.
The reorder is also a philosophical signal, not just a cosmetic one — the 2022 structure puts continual improvement first, as the standing, always-on obligation, and treats nonconformity handling as one specific mechanism that feeds into it. We'll come back to that framing later, because it matters for how you talk about Clause 10 with your leadership team.
The Vocabulary You Need to Get Exactly Right
Clause 10 conversations go sideways constantly because people use "nonconformity," "finding," "observation," "correction," and "corrective action" as if they're interchangeable. An auditor will not let you get away with that, and neither should you.
Term | Definition | Is it a nonconformity? |
|---|---|---|
Nonconformity | A requirement — from the standard, from a regulator, or from your own documented ISMS — that is not met | Yes, by definition |
Major nonconformity | A systemic failure, absence, or breakdown of a required process, or multiple related minor NCs indicating a pattern | Yes — the most serious tier |
Minor nonconformity | An isolated lapse that does not indicate the process itself has broken down | Yes — lower severity |
Observation | An auditor's note flagging a risk or weakness that hasn't yet caused a breach of requirements | No |
Opportunity for improvement (OFI) | A suggestion for doing something better than the minimum the standard requires | No |
Correction | Immediate action to fix the specific instance of the problem | N/A — a response, not a classification |
Corrective action | Action taken to eliminate the root cause so the nonconformity does not recur or occur elsewhere | N/A — a response, not a classification |
Get this glossary internalized across your team before your next audit — our full ISO 27001 terminology and glossary is a good shared reference to hand to anyone who'll be in the audit room.
Major vs Minor Nonconformity: The Distinction That Determines Your Fate
Neither "major" nor "minor" appears as a defined term inside Clause 10 itself — this classification comes from the audit world (IAF and certification body practice), but it governs everything about how a finding plays out, so you need to understand it cold.
Criterion | Minor Nonconformity | Major Nonconformity |
|---|---|---|
Nature of the failure | Isolated instance; the process itself is generally sound | Systemic breakdown, or the required process/control is effectively absent |
Typical trigger | One missed review, one outdated document, one skipped step | A whole control area failing (e.g., no access reviews conducted anywhere, ever) |
Pattern | A single occurrence, first time seen | Recurrence of an unresolved minor NC, or multiple related minors clustering around one weakness |
Effect on certification | None immediately; requires a corrective action plan and evidence, usually reviewed at next visit | Can block initial certification or suspend/withdraw an existing certificate |
Typical response window | Often reviewed at the next scheduled audit | Certification body typically requires evidence within 90 days, sometimes with a follow-up visit |
Example | A single employee's security awareness training was three weeks late | No security awareness training program exists at all |
A cluster of minor nonconformities in the same area is the classic escalation path — exactly what happened to Daniela's team at Halcyon. Auditors are trained to look for patterns, not just count instances. Three unrelated minor NCs across different clauses is a mild problem. Two minor NCs, six months apart, in the same control, both "corrected" without addressing the cause, reads to an auditor as one major nonconformity that you've simply been patching over.
It's also worth being honest with yourself about why the major/minor distinction matters beyond the audit report itself. A suspended certificate isn't just a compliance paperwork problem — it routinely trips procurement clauses, cyber insurance renewal terms, and vendor risk questionnaires that reference "current, valid ISO 27001 certification" as a binary condition. Insurers and enterprise customers rarely distinguish between "certificate suspended for 45 days while we fix something" and "certificate suspended, full stop" — the practical business consequence tends to look the same from the outside, which is exactly why the certification benefits and ROI case you built to justify the program in the first place is the same case that erodes fastest when a major nonconformity goes unmanaged.
"I don't classify severity based on how bad the individual gap looks on the day I find it. I classify it based on what it tells me about whether the process will still be broken the next time I look." — Grace Okonkwo, Compliance Director, quoted from an internal audit debrief
Correction vs. Corrective Action: The Difference That Sank Halcyon
This is worth its own table because it is, without exaggeration, the most common way organizations fail their own remediation.
Dimension | Correction | Corrective Action |
|---|---|---|
What it targets | The symptom — this specific instance | The cause — why this happened at all |
Time horizon | Immediate, often same day or same week | Structural; may take weeks to design and implement |
Example (Halcyon case) | Completing the overdue access review | Reassigning ownership of the review task to a role, not a person, inside the ticketing system, with automated reminders and an escalation path if missed |
Required by Clause 10? | Required as part of 10.2(a) — "react... to control and correct it" | Required as part of 10.2(b)–(e) — evaluate cause, implement action, review effectiveness |
Does it prevent recurrence? | No | That's the entire point |
Auditor's evidence expectation | Proof the immediate issue is closed | Proof of root cause analysis, the action taken, and a later check that it worked |
Both are mandatory. Skipping correction and jumping straight to a long-term fix leaves you noncompliant right now. Skipping corrective action and stopping at correction is what causes recurrence — and recurrence is what turns a minor nonconformity into a major one. You need both, every time, and you need to be able to show an auditor which is which in your documentation.
Where Nonconformities Actually Come From
Findings don't only arrive via a certification body. In a mature ISMS, most nonconformities should be caught internally, well before an external auditor ever sees them.
Source | Typical Trigger | How Formal Is the Trail? |
|---|---|---|
Internal audit | Sampling against your own documented ISMS during a scheduled internal audit cycle | High — internal audit reports are formal, retained records |
External certification audit | Surveillance or recertification audit by your certification body | Highest — external, contractual consequences |
Security incident | A breach, near-miss, or control failure identified during incident response | Variable — depends on how well incident closure is tied back to the ISMS |
Management review | Leadership identifies a gap while reviewing ISMS performance | Medium — depends on how well action items are tracked |
Customer or supplier complaint | A client audit, questionnaire, or contractual review surfaces a gap | Medium |
Self-identified / staff report | An employee notices and reports a process isn't being followed | Low unless you actively encourage and log it |
This is exactly why Clause 9 performance evaluation and internal audit sits immediately upstream of Clause 10 in every practical sense, even though the standard doesn't explicitly draw the arrow. Your internal audit program is your early warning system. If the only time you ever generate a nonconformity is during the external audit, you don't have a functioning ISMS — you have an annual performance for the auditor.
If you don't yet have a repeatable internal audit cadence, that's a separate deep dive — How to Run an ISO 27001 Internal Audit walks through building a sampling plan and audit schedule that reliably surfaces findings before your certification body does. In the meantime, a solid starting point is to standardize how findings get captured the moment they're identified: our internal audit report template is built to feed directly into the NC register structure described later in this article, and pairing it with an internal audit checklist keeps sampling consistent auditor-to-auditor, cycle-to-cycle.
It's also worth distinguishing internal nonconformities from adjacent but different records. An NC is a failure against a stated requirement. An incident is an event with an actual or potential security impact. A risk is a forward-looking exposure you haven't yet decided to formally treat. The three overlap constantly — an incident can reveal a nonconformity (the control that should have prevented it wasn't operating), and a nonconformity can reveal an untreated risk (the gap existed because nobody assessed it) — but they're not interchangeable records, and auditors will ask you to show the connective tissue between them, not just three unrelated logs.
Record Type | What Triggers an Entry | Primary Question It Answers | Where It Lives |
|---|---|---|---|
Nonconformity | A stated requirement wasn't met | "What broke, and why?" | NC/CAPA register |
Security incident | An event with actual/potential impact occurred | "What happened, and how bad was it?" | Incident log |
Risk register entry | A potential future exposure is identified | "What could go wrong, and how likely/severe is it?" | Risk register, feeding Clause 6 risk assessment |
A mature ISMS cross-references these three registers rather than treating them as silos — an incident post-mortem that identifies a control gap should generate an NC entry, and an NC's root cause analysis should prompt a check of whether the risk register already reflected that exposure at an appropriate rating.
The Full Nonconformity-to-Improvement Loop
Here's the loop that Clause 10 actually describes, end to end. Every step maps directly to the 10.2(a)–(e) requirements, plus the 10.1 continual improvement layer that wraps around the whole thing.
flowchart TD
A[Nonconformity Occurs] --> B["10.2(a) React:\nControl & Correct the Symptom"]
B --> C["10.2(a) Deal with\nConsequences"]
C --> D["10.2(b) Evaluate Need for Action:\nReview the Nonconformity"]
D --> E["Determine Root Cause(s)\n(5 Whys, Fishbone, etc.)"]
E --> F["Check for Similar NCs\nElsewhere in the ISMS"]
F --> G["10.2(c) Implement\nCorrective Action"]
G --> H["10.2(d) Review\nEffectiveness of Action"]
H -->|Effective| I["10.2(e) Update ISMS\nDocumentation if Needed"]
H -->|Not Effective| E
I --> J["10.1 Feeds Continual\nImprovement of ISMS"]
J -->|Ongoing Monitoring| ANotice the feedback arrow from "effectiveness review" back to "root cause" — that's not decorative. If your effectiveness review finds the action didn't work, you don't close the nonconformity; you go back and re-diagnose. That loop, sustained over years, is what "continual improvement" means in practice. It isn't a slogan. It's this diagram, running constantly, across every corner of your ISMS.
Root Cause Analysis: Tools the Standard Doesn't Mandate but Auditors Expect to See
Here's a detail that trips people up: ISO 27001 does not prescribe a specific root cause analysis (RCA) methodology. Clause 10.2(b) only requires that you "determine the causes" of the nonconformity. It doesn't say you must use 5 Whys, a fishbone diagram, or any named technique. These are practitioner tools — good practice, borrowed largely from quality management traditions — not clause requirements. That said, an auditor who asks "how did you determine this was the root cause?" and gets "we just knew" as an answer is not going to be satisfied. You need some defensible method, documented.
Technique | Best Used For | How It Works | Limitation |
|---|---|---|---|
5 Whys | Simple, single-thread process failures | Ask "why" repeatedly (typically 5 times) until you reach a systemic cause rather than a symptom | Can miss causes with multiple contributing factors; relies on the facilitator's discipline |
Fishbone (Ishikawa) diagram | Complex failures with multiple potential contributing categories (people, process, technology, environment) | Branches the problem into categories, then brainstorms causes within each | Takes longer; needs a workshop format with the right people in the room |
Fault tree analysis | Safety-critical or high-impact technical failures | Works backward from the failure through logical AND/OR conditions to identify combinations of causes | Overkill for routine administrative NCs |
Pareto analysis | Recurring NCs across a large dataset (e.g., many similar helpdesk tickets) | Ranks causes by frequency to find the 20% driving 80% of occurrences | Needs enough historical data to be meaningful |
Change analysis | Failures that appeared after some known change (new tool, new hire, process update) | Compares "before" and "after" states to isolate what changed | Only works when a clear change event exists |
Pick a technique that fits the complexity of the finding — a missed access review doesn't need a fault tree, and a cascading multi-system outage after a change window probably needs more than 5 Whys. What matters to the auditor is evidence that you asked "why" more than once and didn't stop at the first plausible-sounding answer. If you want a step-by-step walkthrough of facilitating these techniques with a cross-functional group rather than solo, Root Cause Analysis for ISO 27001 is a dedicated companion piece worth building out alongside this one.
If your organization is comparing how this maps to frameworks outside ISO 27001, the logic is broadly similar to how SOC 2 exception remediation works during a Type II audit period, or how the "Improve" function operates under NIST CSF's continuous improvement expectations — the terminology differs, but the underlying discipline of correcting the symptom while separately eliminating the cause is consistent across frameworks.
Case Study 1: Running 5 Whys on a Real Finding
To make this concrete, here's a walkthrough I ran with a mid-market health-tech client (I'll call the company Verdant Health Analytics, since the actual name is under NDA) after an internal audit flagged that quarterly vulnerability scan results weren't being reviewed and signed off within the 10-business-day SLA the ISMS documentation committed to.
Why did the sign-off happen 19 days late instead of within 10? Because the security engineer responsible was on leave for two of those weeks.
Why did nobody cover the task while he was out? Because there was no documented backup owner for scan review.
Why was there no backup owner? Because the RACI matrix for vulnerability management listed only one named individual, not a role.
Why did the RACI matrix name an individual instead of a role? Because it was drafted quickly during the original ISMS build-out and never revisited once the team grew.
Why was it never revisited? Because there was no periodic review cycle for RACI ownership documents tied to the annual ISMS document review.
The correction was simple: get the overdue scan reviewed and signed off immediately. The corrective action was structural: rewrite the RACI matrix to assign vulnerability review to a role (backed by two named deputies), and add ownership documents explicitly to the annual document review checklist so this class of drift gets caught automatically going forward. Verdant's next two audit cycles showed zero recurrence in that control area, and the auditor specifically noted the RCA trail as "well-evidenced" in the surveillance audit report.
"The five-whys exercise took forty minutes. The alternative was writing the same corrective action plan every eight months forever. I'll take the forty minutes." — Aaron Fitch, Internal Auditor, Verdant Health Analytics
Writing a Corrective Action Plan an Auditor Will Actually Accept
A CAPA (Corrective and Preventive Action, though as we'll cover shortly, the "preventive" language is a holdover term many organizations still use informally) document needs specific components to survive scrutiny. Auditors have seen thousands of these; vague ones get bounced back immediately. If you're standardizing this across a larger organization with multiple business units generating their own CAPAs, a CAPA process guide with worked templates per department is worth building as a standalone reference rather than re-explaining the format each time a new finding lands.
Field | What Auditors Are Checking For | Common Failure |
|---|---|---|
NC description | Specific, factual, references the exact requirement not met | Vague restatement of the audit report language |
Correction taken | Dated, evidenced, closes the immediate instance | Missing entirely — teams jump straight to long-term fix |
Root cause | Names a systemic factor, not just "human error" | "Employee forgot" with no further analysis |
Corrective action | Specific, assigned, dated, addresses the root cause directly | Repeats the correction in different words |
Scope check | Confirms whether the same root cause affects other areas/departments | Skipped — the #1 reason NCs recur elsewhere |
Owner | Named individual accountable for delivery | Left blank, or assigned to "the team" |
Target completion date | Realistic, tied to actual resourcing | Set arbitrarily to satisfy a deadline, then missed |
Effectiveness review date | A future date, separate from implementation, to check the fix held | Frequently omitted entirely |
Evidence attached | Documents, screenshots, logs, tickets proving each step | "Will provide upon request" |
Sample Filled CAPA Entry
Field | Entry |
|---|---|
NC ID | NC-2026-014 |
NC description | Access recertification for customer support (12 accounts) not completed for Q1 and Q2 2026, contrary to documented quarterly review requirement |
Classification | Minor nonconformity |
Correction | Access review completed and signed off 2026-07-15; two inappropriate access grants revoked |
Root cause | Task ownership tied to an individual role holder who departed; no reassignment mechanism existed |
Corrective action | Access review ownership moved to IT Ops queue in ticketing system with automated quarterly trigger and 5-day escalation to manager if unactioned |
Scope check | Confirmed same ownership model used in Finance and Engineering access reviews; both reassigned to the same queue model preemptively |
Owner | IT Operations Manager |
Target completion date | 2026-08-15 |
Effectiveness review date | 2026-11-15 (after next scheduled cycle runs automatically) |
Evidence | Ticketing system screenshots, updated RACI, signed access review reports for Q1–Q3 |
That "scope check" row is what separates a CAPA that impresses an auditor from one that merely satisfies the letter of the requirement — it's the direct answer to 10.2(b)'s instruction to determine "whether similar nonconformities exist, or could potentially occur."
Reviewing Effectiveness: The Step Everyone Skips
Clause 10.2(d) requires you to "review the effectiveness of any corrective action taken." This is the step I see skipped more than any other, because by the time the target completion date passes, the team has moved on to the next fire. But an unreviewed corrective action is an unproven one, and "we implemented a fix" is not the same claim as "we implemented a fix and confirmed it worked."
Effectiveness Review Question | What "Pass" Looks Like | What "Fail" Looks Like |
|---|---|---|
Did the specific instance recur? | No recurrence through at least one full subsequent cycle | Same or similar gap reappears |
Did the underlying condition change measurably? | Metric/evidence shows the root cause factor is gone (e.g., ownership now role-based, not person-based) | Root cause condition technically still exists, just hasn't triggered yet |
Did the fix create new risk elsewhere? | No new gaps introduced | New process creates a different control weakness |
Is there durable evidence of the review itself? | Dated review record, signed off by someone other than the implementer | No record the review ever happened |
Was the review done at an appropriate interval? | Enough time elapsed for the process to run at least once under new conditions | Reviewed the same day as implementation — too soon to mean anything |
A good rule of thumb: don't schedule your effectiveness review before the corrected process has had a chance to run through at least one full natural cycle. If it's a quarterly control, review effectiveness after the next quarter closes, not the week after you changed the procedure document.
Building a Nonconformity Register That Auditors Trust on Sight
Every organization I've worked with eventually converges on some version of a central nonconformity/CAPA log. The ones that make audits smooth share a common structure.
Column | Purpose |
|---|---|
NC ID | Unique reference, sortable/searchable |
Date raised | Establishes timeline for SLA tracking |
Source | Internal audit / external audit / incident / complaint / self-reported |
Classification | Major / minor / observation / OFI |
Clause or control affected | Ties directly to the ISMS structure being tested |
Description | Factual, specific |
Correction summary + date closed | Immediate fix evidence |
Root cause summary | One or two sentences, RCA method used |
Corrective action summary | What structural change was made |
Owner | Named accountable individual |
Target date | For corrective action completion |
Effectiveness review date + outcome | Pass/fail, with evidence link |
Status | Open / Correction complete / Corrective action in progress / Closed / Reopened |
Keep this register as a living document reviewed at every management review meeting, not something reconstructed from memory the week before an audit. Auditors will ask to see the full register, not just the entries related to the specific finding they're following up on — a thin or freshly-created-looking register is itself a red flag.
You don't need a dedicated GRC platform to do this well — I've seen a disciplined spreadsheet with version history outperform an expensive, half-configured GRC tool more times than I can count. What matters is not the software, it's whether the register is a single source of truth that gets updated the same day something changes, rather than a document three people maintain slightly differently. If you're scaling past a handful of nonconformities a quarter, or you're running the register across multiple business units or subsidiaries under one certificate, a dedicated tool starts to earn its cost by enforcing consistent fields and automatic reminders for target dates and effectiveness reviews — the two fields that get missed most often when tracked manually. Whichever route you choose, the acid test is the same: could someone outside your team open the register cold and understand, within five minutes, exactly where every open nonconformity stands?
How Much Time Do You Actually Have?
Certification bodies vary somewhat in their exact procedures, but the general pattern across accredited bodies is consistent enough to plan around.
Nonconformity Type | Typical Response Deadline | Typical Verification Method |
|---|---|---|
Minor NC | Corrective action plan due within a defined window (commonly 30–90 days depending on the body); can sometimes be verified at next scheduled audit | Documentary evidence review, sometimes remote |
Major NC (initial certification) | Must be resolved before the certificate can be issued at all | Follow-up audit, often on-site, before certification decision |
Major NC (surveillance/recertification) | Typically 90 days maximum to provide evidence of correction and corrective action, or certification is suspended | Follow-up audit or, in some cases, documented evidence review |
Suspended certificate, unresolved | Certification body may withdraw the certificate entirely after a further defined period (commonly up to 6 months from suspension) | Full re-audit likely required to reinstate |
Repeated/unaddressed minor NCs | Can be escalated to major at the auditor's discretion | Same as major NC handling |
These are illustrative, general patterns — your specific certification body's rules will be in your certification agreement, and you should know those numbers cold rather than estimating them under pressure. What every practitioner I've worked with agrees on: don't wait until week 10 of a 90-day window to start root cause analysis. The clock includes time for the corrective action itself to run and show evidence of effectiveness, not just time to write the plan.
"Ninety days sounds like a lot until you subtract the two weeks it takes to even schedule the root cause workshop with the right people in the room." — Priya Ramaswamy, CISO, financial services SaaS provider
How Certification Bodies Resample Closed Corrective Actions
The detail that surprises first-time certified organizations most is that closing a nonconformity is never really "closed" in the sense of forgotten. Certification bodies operate on a rule of thumb that previously nonconforming areas get resampled at the next scheduled visit, specifically to check whether the corrective action held. This is exactly what happened to Daniela's team at Halcyon, and it's the mechanism by which a poorly-addressed minor NC becomes a major one.
Audit Stage | What Gets Resampled | What Auditors Look For |
|---|---|---|
Next surveillance audit after a minor NC | The specific control area previously flagged | Whether the gap recurred; whether the corrective action evidence matches what was submitted |
Recertification audit (typically every 3 years) | All previously nonconforming areas across the certification cycle, plus a full-scope resample | Sustained effectiveness across multiple cycles, not just the immediate fix |
Follow-up audit after a major NC | The specific failed process, often company-wide if root cause was systemic | Whether the fix was scoped broadly enough to address the true cause |
Any audit, generally | Areas with a history of near-misses or observations, even without a formal NC | Whether unaddressed weak signals have progressed toward a nonconformity |
If you want a deeper walkthrough of what a Stage 2 or surveillance visit actually looks like from the inside — including how auditors structure their sampling plan across a multi-day visit — Surviving Your Stage 2 Audit covers that in detail. In the meantime, our certification readiness checklist is a useful way to sanity-check whether previously closed findings would hold up if resampled tomorrow, not just whether the paperwork exists.
Where Did Preventive Action Go?
If you learned ISO 27001 from 2013-vintage material, or you've worked in other management-system standards, you may be looking for a "preventive action" clause and not finding one. This isn't an oversight — it was deliberately removed.
Older versions of ISO management standards, including ISO 27001:2005, treated preventive action as a distinct clause: identify potential nonconformities before they happen and act on them separately from corrective action. When ISO restructured its management system standards under the Annex SL harmonized framework (which is why Clauses 4–10 look structurally similar across ISO 27001, ISO 9001, ISO 22301, and others), the concept of "prevent problems before they occur" was absorbed into the standard's foundational risk-based thinking, expressed primarily through Clause 6 planning and risk assessment. The logic: if your entire ISMS is built around continuously identifying and treating risk, a standalone "preventive action" clause is redundant — prevention is supposed to be what the whole management system does, not an isolated activity bolted onto the back end.
In practice, this means: don't go looking for a "preventive action register" as a Clause 10 deliverable. Your risk register, risk treatment plan, and risk assessment cycle are where forward-looking prevention lives. Clause 10 is reactive by design — it deals with things that have already gone wrong. If you want to argue you're doing genuine "prevention," point to your risk assessment methodology and risk treatment decisions, not a corrective action log.
Documented Information: What Clause 10 Actually Requires You to Keep
Clause 10.2's closing requirement is easy to skim past: retain documented information as evidence of the nature of the nonconformities and any subsequent action taken, and the results of any corrective action. It doesn't mandate a specific template or system, but it does mandate that the trail exists and is retrievable — which is the whole reason the NC register structure covered earlier in this article matters.
Evidence Type | What It Must Show | Where It Typically Lives |
|---|---|---|
Nature of the nonconformity | What requirement was breached, when, and how it was identified | NC register entry, linked to the audit report or incident record that surfaced it |
Correction taken | The immediate fix, dated and evidenced | Attached tickets, screenshots, sign-offs |
Root cause analysis | The method used and the conclusion reached | RCA worksheet or workshop notes, referenced in the NC entry |
Corrective action taken | The structural change implemented | Change records, updated procedures, policy revisions |
Effectiveness review results | Whether the action worked, checked after a real operating cycle | Dated review record, independent sign-off |
A practical tip: don't let this evidence live scattered across email threads and personal drives. If your organization already maintains a mandatory documents checklist for the ISMS as a whole, add the NC register and CAPA evidence trail to it explicitly, and cross-reference it against your Statement of Applicability so that any corrective action which changes a control's implementation is reflected consistently in both places. Auditors specifically check that a corrective action affecting a control doesn't quietly drift out of sync with what your SoA says you actually do.
This matters more than it sounds, because corrective actions frequently touch Annex A controls directly. Annex A in the 2022 revision organizes 93 controls across four themes — 37 organizational, 8 people, 14 physical, and 34 technological. A corrective action born out of an access-review nonconformity, for instance, typically lands squarely inside the organizational controls theme (access control policy and review), but a corrective action addressing a physical tailgating incident lands in the physical controls theme, and one addressing a missed patching cycle lands in technological controls. Whichever theme is touched, your SoA needs to reflect the corrected implementation detail, not just the original one — otherwise you've created a second, smaller nonconformity in the act of fixing the first.
Auditor Interview Prep: What They'll Actually Ask You
Whoever ends up in the room with the auditor when a previous corrective action gets resampled should be ready for a fairly predictable set of questions. I coach clients through this the same way ahead of every surveillance visit, because a confident, specific answer closes the topic in two minutes, while a vague one invites the auditor to dig further.
Question the Auditor Will Ask | What a Strong Answer Sounds Like |
|---|---|
"Walk me through what happened when this nonconformity was raised." | A clear timeline: date raised, who reacted, what the correction was, when it was done |
"How did you determine the root cause?" | Names the RCA method used and the specific conclusion reached, not a vague summary |
"Did you check whether this affected any other area?" | A specific answer about what was checked and what was found, even if the answer is "nothing else" |
"How do you know the corrective action actually worked?" | Points to the effectiveness review record and the evidence behind it |
"Who owns this now, going forward?" | Names a role or individual, with a description of the ongoing control (not just "we fixed it") |
"Has anything like this happened elsewhere in the organization since?" | Draws on the NC register's classification and source fields to answer with data, not memory |
If your team tends to freeze under structured questioning like this, rehearsing with a formal internal audit interview question script ahead of the real audit is a cheap way to build the muscle memory — the goal isn't a scripted answer, it's the habit of always having the timeline, the cause, and the evidence ready before someone asks.
The Mistakes That Turn Minor Findings Into Major Ones
I've now reviewed corrective action plans from well over a hundred organizations across surveillance cycles, and the failure modes repeat with remarkable consistency.
Mistake | Why It Backfires | Fix |
|---|---|---|
Correction submitted as if it were corrective action | Auditor resamples next cycle, finds the same gap, treats it as unaddressed | Always document both steps separately, even when correction feels sufficient in the moment |
Root cause listed as "human error" | Tells the auditor you didn't actually investigate | Push at least two levels deeper — why did the human have the opportunity to err? |
No scope check across other teams/systems | Same root cause resurfaces in a different department, reads as a new pattern | Explicitly document what else you checked, even if the answer is "nothing else affected" |
Owner listed as a department, not a person | Accountability diffuses; nothing gets done | Name an individual, even if a team executes the work |
Effectiveness review skipped or done too early | Fix declared successful before it's actually been tested by real conditions | Set the review date after at least one full operating cycle |
CAPA closed by the same person who implemented it | Creates a self-grading appearance | Have someone independent — internal audit, a manager, a peer — sign off on closure |
Evidence promised but not attached | Slows down verification, looks evasive | Attach everything at submission; don't make the auditor chase it |
Treating an OFI or observation as a formal NC in your tracking | Wastes remediation cycles on non-mandatory items while real NCs age | Keep OFIs and observations in a separate, lower-priority backlog |
Case Study 2: How the Halcyon Escalation Actually Resolved
Returning to Daniela's story: once the finding escalated to major, her leadership team finally treated it with the seriousness it deserved from the start. Within two weeks they'd run a proper fishbone analysis involving IT, HR, and the support department manager, and found the root cause went beyond the individual departure — Halcyon had no formal offboarding checklist step for reassigning "orphaned" recurring compliance tasks at all, in any department. The corrective action was organization-wide: every recurring compliance task was moved into a ticketing system with role-based (not person-based) ownership, and offboarding checklists were updated to require an explicit handoff review for any departing employee holding a compliance task.
The certification body required a focused follow-up audit at day 75 of the 90-day window. Daniela's team passed it — with the auditor specifically noting the organization-wide scope of the fix as evidence the root cause had been genuinely addressed, not patched. The certificate suspension was lifted, and — six months later, at the next scheduled surveillance audit — the auditor resampled the same control area again (as expected) and found it fully embedded, with three full cycles of clean evidence. The two customers who'd placed compliance holds lifted them within a month of certificate reinstatement, though Halcyon's finance team still logged the episode as a $340,000 revenue delay in that year's audit committee report — a number Daniela now uses internally every time someone suggests cutting a corrective action corner to save time.
The episode also reshaped how Halcyon handled interested parties and their stakeholder requirements — Daniela's team now maintains a standing list of which customers have contractual compliance-notification clauses, so that a major nonconformity triggers a proactive, controlled disclosure conversation instead of a customer discovering the compliance hold risk on their own.
"We didn't lose the certificate. We lost three months of trust with two of our biggest customers, and trust is slower to rebuild than a compliance record." — Daniela Cruz, ISMS Manager, Halcyon Freight Systems
Case Study 3: Getting It Right the First Time
Contrast that with a smaller case: a 60-person managed service provider I'll call Ferro Systems Group underwent its first-ever internal audit ahead of initial ISO 27001 certification. The internal auditor found that incident response tickets for three low-severity events over the prior quarter hadn't been formally closed with a documented lessons-learned entry, even though the incidents themselves had been handled fine operationally.
Instead of treating it as paperwork cleanup, the security lead ran a quick 5 Whys with the on-call engineers: the incident response procedure required a lessons-learned entry, but the ticketing template didn't include a field for it, so it was easy to forget under time pressure. Correction: the three tickets were retroactively completed. Corrective action: the ticketing template itself was changed to make the lessons-learned field mandatory before a ticket could be marked resolved, closing the gap at the tooling level rather than relying on individual diligence. Effectiveness review six weeks later, after eleven more incidents had passed through the new template, showed 100% completion with zero reminders needed. At Stage 2 certification audit two months later, the lead auditor sampled the same control area, found it fully compliant, and the finding never resurfaced as an issue at all — it became, in the auditor's own words, "a clean example of a team that understood the difference between fixing the ticket and fixing the process."
"The cheapest corrective action is usually the one that removes the chance for a human to forget, not the one that reminds them to remember." — Lars Bergström, Risk Manager, Ferro Systems Group
Continual Improvement (10.1): The Obligation That Never Closes
Everything above has been about 10.2 — reacting to specific nonconformities. But the 2022 reorder puts 10.1, continual improvement, first for a reason: it's the standing, always-on obligation that corrective action feeds into, not a separate program you run once a year. The requirement is simple to state and genuinely hard to institutionalize: the organization shall continually improve the suitability, adequacy, and effectiveness of the ISMS.
Those three words matter individually:
Suitability — does the ISMS still fit the organization as it exists today? A scope, risk assessment, or control set designed for a 50-person company doesn't automatically stay suitable at 500 people, or after a merger, or after moving from on-prem to multi-cloud. This is exactly why revisiting how you defined your ISMS scope periodically is itself a continual improvement activity, not a one-time exercise you complete during initial implementation.
Adequacy — is the ISMS resourced and detailed enough to actually do the job, not just exist on paper? A policy that nobody has time to follow isn't adequate, even if it's well-written.
Effectiveness — is the ISMS actually reducing risk and meeting objectives in practice, as measured by the metrics, audits, and incident trends you're tracking under Clause 9?
Corrective actions are one input into continual improvement, but they're not the only one. Management review outputs, risk assessment updates, changing regulatory requirements, new threat intelligence, and even successful projects that revealed a better way of doing something all feed the same continual improvement obligation. If your only evidence of "continual improvement" in front of an auditor is a folder of closed nonconformities, you're underselling what you've actually done — and probably under-doing what the clause expects.
Improvement Input | Where It Typically Surfaces | Feeds Into |
|---|---|---|
Closed corrective actions | NC register | Direct evidence of reactive improvement |
Management review decisions | Management review minutes | Strategic/resourcing changes to the ISMS |
Risk assessment updates | Risk register revisions | Forward-looking prevention (replacing old "preventive action") |
Internal audit trends | Internal audit reports over multiple cycles | Identifies systemic weak spots before they become NCs |
Metrics and KPIs | Security dashboards, objective tracking | Quantifies whether effectiveness is actually trending up |
Incident post-mortems | Incident response records | Process and control refinement |
External context changes | Regulatory/legal register, threat intel | Scope, control, and objective adjustments |
Metrics That Prove Continual Improvement Is Real
"We're continually improving" is a claim; a trend line is evidence. The organizations that handle management review well track a small number of metrics over time and bring them to every review meeting, rather than reconstructing a narrative from memory.
Metric | What It Tells You | Good Trend Direction |
|---|---|---|
Number of open NCs older than target close date | Whether corrective action discipline is keeping pace with findings | Flat or declining |
Recurrence rate (NCs reopened after "closure") | Whether corrective actions are addressing root cause vs. symptom | Declining toward zero |
Average time from NC identification to correction | Responsiveness of the immediate reaction step | Stable or improving |
Average time from correction to verified effectiveness | Whether corrective action and verification are being rushed or skipped | Consistent with defined cycle length, not artificially short |
Ratio of self-identified to externally identified NCs | Maturity of internal audit and monitoring | Increasing (more self-identified over time) |
Number of OFIs actioned voluntarily | Whether improvement culture extends beyond mandatory findings | Increasing |
None of these are ISO-mandated metrics — the standard doesn't name a single one of them — but every organization I've helped through a second or third certification cycle ends up tracking some version of this list, because "prove you're improving" is fundamentally a data question, not a narrative one.
Running Improvement as a Discipline, Not a Fire Drill
The organizations that handle Clause 10 well don't treat it as an audit-response function. They run it as an operating rhythm, structured around the same Plan-Do-Check-Act logic that underlies the whole Annex SL framework.
PDCA Stage | Clause 10 Activity | Cadence |
|---|---|---|
Plan | Define how NCs will be logged, classified, and assigned; set RCA expectations | Set once, reviewed annually |
Do | React to nonconformities as they arise; implement corrective actions | Continuous, as findings occur |
Check | Review effectiveness of corrective actions; track NC register at management review | Per NC, plus quarterly/at each management review |
Act | Update ISMS documentation, policies, or resourcing based on patterns observed | As needed, formally captured in management review outputs |
Building this rhythm into your ISMS core concepts rather than bolting it on as an audit-week activity is what actually prevents the Halcyon scenario. It also quietly debunks one of the more persistent myths about ISO 27001 — that certification is a one-time gate you pass and then coast on. It isn't; see our breakdown of ISO 27001 myths and misconceptions for more on that specific misunderstanding.
Who Owns What: Roles in the Corrective Action Process
Ambiguity about ownership is itself a common root cause — as both Halcyon and Verdant discovered — so don't let the same ambiguity infect your CAPA process itself.
Role | Responsibility in the NC/CAPA Process |
|---|---|
ISMS Manager / CISO | Owns the overall NC register; ensures process is followed; reports trends to leadership |
Internal Auditor | Identifies NCs during internal audits; verifies closure evidence independently |
Process/Control Owner | Performs root cause analysis for NCs in their area; proposes and implements corrective action |
Department Manager | Approves resourcing for corrective action; accountable for timely completion |
Top Management | Reviews significant NCs and improvement trends at management review; approves ISMS changes where needed |
Certification Body Auditor | Classifies severity; verifies evidence at surveillance/recertification; decides on escalation |
Document this ownership model explicitly — even a simple RACI — because an auditor asking "who decided this was the root cause, and who verified the fix worked?" should get a clean, immediate answer, not a shrug.
"The fastest way to spot an ISMS that's about to have a bad audit cycle is to ask who owns the nonconformity register. If the answer takes more than five seconds, that's already the finding." — Tomasz Wieczorek, Lead Auditor
Common Pitfalls, Consolidated
Pulling together everything above, here's the condensed version I give clients as a pre-audit checklist.
Pitfall | One-Line Fix |
|---|---|
Confusing correction with corrective action | Document both, separately, every time |
Treating "human error" as a root cause | Ask why the human had the chance to err |
Skipping the scope check across other teams | Explicitly state what else you checked |
No effectiveness review scheduled | Set a future date after a full operating cycle |
CAPA register reconstructed only before audits | Maintain it continuously; review at every management review |
Treating OFIs/observations as formal NCs | Separate lower-priority backlog |
Assuming "preventive action" is a missing requirement | Point to your risk treatment process instead |
No named individual owner on any NC | Always name a person, even for team-executed fixes |
The Strategic Close
If you take one thing from this article back to your own ISMS, make it this: Clause 10 is not the clause where you clean up mistakes. It's the clause that proves whether your management system actually learns. An auditor sampling the same control area two cycles in a row isn't being unfair — they're testing the one thing that separates a real ISMS from a certificate on the wall: does this organization get better at the thing it just failed at, or does it just get better at explaining why it failed?
Daniela's team at Halcyon eventually got there, but they paid a $340,000 tuition for a lesson that a properly built root cause analysis habit would have taught them for free. Verdant and Ferro got the same lesson at a fraction of the cost, because they built the habit before the auditor forced it on them. The corrective action process you design today is either an insurance policy against escalation or a liability waiting for its second occurrence — there isn't a neutral option.
If you're building this discipline from scratch, our Complete ISO 27001 Implementation Guide walks through where nonconformity handling fits alongside the rest of ISMS build-out, end to end, rather than in isolation.
Whether you're staring at your first nonconformity report or trying to build a CAPA process that never has to be tested the hard way, PentesterWorld's ISO 27001 practitioners can pressure-test your root cause analysis, your CAPA templates, and your internal audit program before your certification body does it for you — get in touch for an ISO 27001 gap assessment or a mock internal audit ahead of your next certification cycle.