ISO 27001 Clause 10: Improvement, Nonconformities, and Corrective Action
Clause 10 of ISO 27001:2022 has two parts — reordered in the 2022 revision so that 10.1 is now continual improvement (the ISMS must keep getting more suitable, adequate and effective) and 10.2 is nonconformity and corrective action. When a nonconformity occurs, 10.2 requires you to react (correct it and deal with consequences), then evaluate whether action is needed to eliminate the cause so it doesn't recur or occur elsewhere — reviewing the nonconformity, determining causes, checking for similar cases — then implement the action, review whether it worked, and change the ISMS if needed. You must retain records of the nonconformity's nature, actions taken, and their results. The key distinction: correction fixes the instance (re-enable MFA for the account), corrective action fixes the cause (make MFA enforcement automatic at provisioning); audits test whether you know the difference. And the counterintuitive audit reality: an empty nonconformity log doesn't read as excellence — it reads as an ISMS that isn't looking. A handful of honestly logged, root-caused, closed findings is among the strongest evidence a management system actually works.
Clause 10 is the shortest of ISO 27001's management-system clauses — two subclauses, a few paragraphs — and it's the one startups most often fake. Not out of malice: out of a misunderstanding about what auditors want to see. Teams arrive at certification with a spotless, empty nonconformity log, believing it signals excellence. To an experienced auditor it signals the opposite: a management system that has never caught itself making a mistake isn't clean — it isn't looking. This is the final clause post in our 4–10 series (hub, Clause 9 previous).
A small 2022 note first
The 2022 revision flipped the order of this clause: 10.1 is now Continual improvement and 10.2 is Nonconformity and corrective action (in the 2013 edition it was the other way around). Cosmetic, but worth knowing so your documentation references the right numbers — and mildly symbolic: improvement is the headline, corrective action is one mechanism serving it.
10.1 — Continual improvement
What it requires: continually improve the suitability, adequacy and effectiveness of the ISMS. One sentence.
There's no mandated improvement register, but the auditor needs to see the property somewhere: an ISMS that looks different — better — than it did a year ago, with evidence of why. In practice, improvement enters through every loop the previous clauses built: metrics from 9.1 triggering changes, internal audit findings from 9.2, management review outputs from 9.3 (whose required output is literally "decisions on continual improvement opportunities"), corrective actions from 10.2, and treatment of new risks from Clause 8.2. If those mechanisms run honestly, 10.1 satisfies itself; if they don't, no improvement register will save it.
A useful habit: when something gets better for security reasons — you tightened a process, automated a control, raised a standard — leave a one-line trace (a management review note, a changelog entry). Improvement that leaves no record is invisible at audit time.
10.2 — Nonconformity and corrective action
First, the definition, because it's broader than people assume: a nonconformity is any failure to fulfil a requirement — of the standard or of your own ISMS. The access review that didn't happen on schedule. The policy exception granted informally. The backup that silently failed for a month. The onboarding that skipped the security briefing. Internal audit findings are the obvious source, but monitoring results, incidents, staff reports, and external audit findings all feed the same process.
What the clause requires when a nonconformity occurs — and this sequence is the audit script:
- React: take action to control and correct it, and deal with the consequences. This is the correction — the immediate fix.
- Evaluate the need to eliminate the cause, so it doesn't recur or occur elsewhere: review the nonconformity, determine its causes, and determine whether similar nonconformities exist or could potentially occur. That last check is the most-skipped step in the whole clause — if one offboarded contractor kept access, who else did?
- Implement whatever action is needed — corrective action, proportionate to the effects of the nonconformity (the standard says so explicitly; not every hiccup needs a root-cause ceremony).
- Review the effectiveness of the corrective action — did it actually prevent recurrence?
- Change the ISMS itself if necessary — sometimes the cause is a bad policy, not a bad execution.
Records required: the nature of the nonconformities and actions taken, and the results of the corrective actions. A simple log or your existing ticket tracker works — each entry showing what happened, the correction, the cause, the corrective action, the owner, and the effectiveness check with a date.
Correction vs. corrective action — the distinction that decides findings
Auditors test this pair relentlessly because it separates process from theater:
- Correction: the account without MFA gets MFA enabled today.
- Corrective action: provisioning is changed so accounts can't be created without MFA, because the cause was a manual step people skipped.
A log full of corrections with no causal analysis means the same failures will cycle forever — and the auditor will pull last year's findings to prove it. Conversely, honest cause analysis doesn't require a formal methodology; asking "why" a few times and writing down the answer meets the bar at startup scale.
Why faking it fails
The empty-log strategy fails on contact for a predictable reason: the auditor doesn't read your log first — they find a discrepancy somewhere else (a missed review in Clause 8's records, a metric breach in 9.1, an audit finding in 9.2) and then ask how your 10.2 process handled it. If the answer is that it never entered the process, the finding is no longer the missed review; it's that your improvement loop doesn't function. One nonconformity becomes two.
The inverse is just as true and much happier: a handful of self-identified nonconformities, root-caused, fixed, verified, and visible in management review is among the strongest evidence an ISMS genuinely works. Auditors say this openly. Certification doesn't require perfection; it requires a system that notices and corrects.
Common Clause 10 nonconformities (yes, meta)
- The empty log — no recorded nonconformities in a year of operation, contradicted by the rest of the audit trail.
- Corrections dressed as corrective actions — instance fixed, cause untouched, recurrence guaranteed.
- No effectiveness review — actions closed on implementation, never checked for whether they worked.
- No "could this happen elsewhere?" check — the explicitly required similar-cases step, silently skipped.
- Findings that never reach management review — breaking the loop between 10.2 and 9.3's required input on nonconformity trends.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
The bottom line
Clause 10 asks for a working confession-and-repair loop, and rewards honesty over polish. Log what goes wrong, fix the instance, chase the cause, check the fix took, and let management review see the trend line. Do that and the shortest clause in the standard becomes the easiest — and your audit story changes from "nothing ever goes wrong here" to the far more credible "here's what went wrong and here's the system that caught it." That completes the seven clauses — the series hub ties them together, and the Annex A guide covers the controls those clauses put to work.
Frequently asked questions
What is the difference between correction and corrective action in ISO 27001? +
A correction fixes the instance; a corrective action fixes the cause. Example: an account is found without MFA — enabling MFA on that account today is the correction; changing provisioning so accounts can't be created without MFA (because the cause was a skippable manual step) is the corrective action. Clause 10.2 requires both moves: react to the nonconformity and deal with consequences, then evaluate whether action is needed to eliminate the cause so it doesn't recur or occur elsewhere — including checking whether similar nonconformities exist. Auditors test the distinction relentlessly because it separates a working improvement process from theater: a log full of corrections with no causal analysis means the same failures recur, and last year's findings will prove it.
Is having zero nonconformities good for an ISO 27001 audit? +
Counterintuitively, no. An empty nonconformity log doesn't read as excellence to an experienced auditor — it reads as a management system that isn't looking, because a year of real operation always produces some failures to fulfil requirements: a missed access review, an informal policy exception, a silently failing backup. The strategy also fails on contact: the auditor typically finds a discrepancy elsewhere (in operating records, metrics, or internal audit results) and then asks how your Clause 10.2 process handled it — and if it never entered the process, the finding becomes that your improvement loop doesn't function. A handful of self-identified, root-caused, verified-closed nonconformities visible in management review is among the strongest evidence an ISMS genuinely works. Certification requires a system that notices and corrects, not perfection.
What records does ISO 27001 Clause 10.2 require? +
Two kinds of documented information: evidence of the nature of the nonconformities and any subsequent actions taken, and evidence of the results of any corrective action. In practice a simple log or your existing ticket tracker satisfies this, as long as each entry shows the full sequence Clause 10.2 requires: what happened, the immediate correction, the cause analysis, whether similar cases were checked for, the corrective action with an owner, and the effectiveness review confirming the fix actually prevented recurrence — with dates throughout. The most commonly missing pieces are the last two: actions closed on implementation without anyone verifying they worked, and the explicitly required "could this exist elsewhere?" check silently skipped.
