ISO 27001 clause 10: corrective action
Clause 10 is two requirements and the shortest clause in the standard, and the corrective action register it produces is one of the first documents a surveillance auditor opens. A register full of one-line fixes tells them the improvement process is decorative.
Clause 10 of ISO/IEC 27001:2022 carries two requirements: 10.1 continual improvement and 10.2 nonconformity and corrective action. Between them they ask for one artifact, a corrective action register, and one discipline, which is distinguishing the fix from the cause. A management system with an empty register after twelve months of operation is not a clean system. It is a system whose assurance processes are not finding anything, and an auditor reads it that way.
This page covers nonconformities you raise against yourself, from internal audit, incidents, monitoring and management review. Findings raised by your certification body at stage 2, at surveillance or at recertification run on a different clock with contractual deadlines attached, and those are on the nonconformity page.
Correction is not corrective action
This is the whole clause in one distinction, and getting it wrong is the most common finding written against clause 10.
- Correction
- Fixing the thing in front of you. The offboarding was missed, so revoke the account. Required by 10.2 a), and on its own it closes nothing.
- Corrective action
- Removing the cause so it does not recur. Required by 10.2 b) and c). The offboarding was missed because HR notifies IT by email and the email went to a person on leave, so offboarding now triggers from the HR system with a checklist and an owner.
- Extent check
- Also 10.2 b): determine whether similar nonconformities exist or could occur elsewhere. If offboarding failed once, check the last six leavers. This is the step that separates a real corrective action from a plausible paragraph.
- Effectiveness review
- Required by 10.2 d). Come back later and confirm the cause is actually gone. It needs a second date, which is why registers with a single closed column fail this requirement structurally.
What root cause analysis an auditor accepts
No method is mandated. What is tested is whether the stated cause plausibly produced the finding and whether the action taken plausibly removes it. Three things get rejected consistently.
| Stated cause | Verdict | Why |
|---|---|---|
| "Human error" | Rejected | It names the person, not the cause. The question is why the process allowed the error to matter |
| "Oversight due to workload" | Rejected | Restates the symptom. If workload is genuinely the cause, the corrective action is a resourcing decision under clause 7.1, and it has to actually be made |
| "Policy not followed" | Weak | Usually true and never the whole answer. Why was it not followed: awareness, an unworkable step, or no way to tell it had been skipped |
| "Access review was manual and depended on one person who was on leave" | Accepted | Specific, testable, and it points at a change you can make |
| "Supplier agreements had no security schedule because procurement predates the ISMS" | Accepted | Names a systemic gap and implies both a correction for existing contracts and a control for new ones |
| "The control was designed for an office and the company went remote" | Accepted | Ties the failure to a change in context, which also feeds clause 4.1 at the next management review |
Five whys, fishbone or a written paragraph all work. What matters is that the finding, the cause and the action form a chain a stranger can follow. If the action does not obviously follow from the cause, the auditor will ask, and the answer is usually that the cause was written after the action was decided.
The corrective action register, column by column
| Column | Why it is there | Worked example |
|---|---|---|
| Reference | So the finding can be cited in minutes and audit reports | CA-2026-014 |
| Source | Internal audit, incident, monitoring, management review, external audit, staff report | Internal audit, June 2026 |
| Requirement failed | The clause or Annex A control. Without it the finding cannot be classified | A.5.18 access rights |
| Description and evidence | What was observed, with the sample | Two of six leavers retained SaaS access beyond the day of departure |
| Classification | Major, minor or observation. Drives urgency, not the amount of work | Minor |
| Correction | The immediate fix, with its date | Both accounts revoked, 14 June 2026 |
| Root cause | Why the process allowed it | Offboarding triggered by email to a shared inbox with no owner or tracking |
| Extent | Where else the same cause could apply | All twelve leavers in the last year reviewed, one further gap found |
| Corrective action and owner | The change that removes the cause | Offboarding moved to the HR system with a mandatory access revocation task, owner: Head of People |
| Target date and closure date | Two separate dates. A target that slipped repeatedly is itself a finding | Target 31 July 2026, closed 24 July 2026 |
| Effectiveness review | The second date, required by 10.2 d) | Reviewed 30 October 2026 against the next four leavers, no gaps |
Eleven columns looks heavy and it is the shape that survives a surveillance audit. The two that get dropped in practice are extent and effectiveness review, and they are precisely the two an experienced auditor checks first, because their absence proves the process stops at the fix.
What belongs in the register and what does not
A nonconformity is a failure to meet a requirement, meaning a clause of the standard, an applicable Annex A control, or a rule in your own documented system. That last category is wider than people expect. If your access review procedure says quarterly and you did three in a year, that is a nonconformity against your own management system even though the standard never mentions a frequency.
- Every internal audit finding, including the minor ones. Downgrading a finding to an observation to keep the register clean is visible, because the internal audit report says otherwise.
- Security incidents where a control did not work as designed. The incident record and the corrective action record are different documents and both are expected.
- Missed commitments in your own procedures, such as an overdue supplier review or a late risk reassessment.
- Findings from a customer audit or a security questionnaire that revealed a real gap.
- Certification body findings, cross-referenced to their own closure process, which has external deadlines the internal ones do not.
What does not belong: improvement ideas with no requirement behind them. Those go in a separate improvement log under 10.1, and mixing the two makes the nonconformity trend at management review unreadable.
What clause 10.1 asks for beyond the register
One sentence: continually improve the suitability, adequacy and effectiveness of the management system. There is no required document, which is why it is frequently treated as unauditable. It is not. An auditor tests it by asking what improved this year and expecting an answer that is not a corrective action, because fixing failures is 10.2 and improvement is meant to happen without one.
Reasonable answers look like this. The risk scoring scale was rewritten because the first version produced forty high risks and no way to prioritise them. Access reviews moved from a spreadsheet to an automated report, cutting the quarterly effort. Awareness training was rebuilt after the phishing failure rate stalled. The measurement set from clause 9.1 was changed because two of the metrics were never acted on. All of these are improvements with evidence, and all of them come out of running the system rather than out of an audit.
Why an empty register is worse than a full one
Zero nonconformities is a finding
A first-year management system that recorded no nonconformities has told the auditor one of three things: the internal audit was not real, the monitoring measures nothing that could fail, or findings are being resolved informally and not recorded. All three are problems with clause 9 or clause 10 rather than evidence of a well-run system. A register with fifteen items, twelve closed, three in progress with dates, and two effectiveness reviews completed reads as a working system. That is the target.
When the process gets heavier than the risk
The counter-case, since the argument above pushes toward recording more. A corrective action process with a formal review board, a mandatory five-whys template and a three-signature closure route will, in a thirty-person company, produce exactly one outcome: people will stop raising findings. The clause asks for a proportionate response, and 10.2 explicitly says corrective actions shall be appropriate to the effects of the nonconformities encountered.
For a small company, a shared table with the eleven columns above, reviewed at each management review, is proportionate and complete. A dedicated tool is worth it when the volume passes roughly thirty open items or when findings come from several sources that need to be reconciled. Buying one earlier is the same mistake as buying a compliance platform for document control, and the cost page puts both lines in context. The wider question of how much management system is proportionate at all is on the clause overview, and choosing the framework is the step before that.
Get the corrective action process reviewed
Tell us what your register looks like and we will match you with Canadian firms who will tell you how it will read at surveillance.
Get matchedCommon questions
What is the difference between correction and corrective action?
Correction is the immediate fix to the thing that went wrong, such as revoking an account that should have been removed. Corrective action is the change that removes the cause so it does not happen again, such as moving offboarding into the HR system with a tracked task. Clause 10.2 requires both, and a register that only records corrections has met about half the requirement.
How long do we have to close a nonconformity we raised ourselves?
Whatever your own procedure says, which is why the procedure should set realistic windows rather than aspirational ones. A common shape is 30 days for the plan and the correction, and a target closure date agreed with the owner. Certification body findings are different and carry externally set deadlines, covered on the nonconformity page.
Does every security incident become a corrective action?
No. An incident where the controls worked as designed and the outcome was contained is an incident record, not a nonconformity. It becomes a corrective action when a control failed, was absent, or did not do what your documentation said it would. Recording every incident as a nonconformity makes the trend data at management review meaningless.
Do we need a formal root cause analysis method?
No method is required by the standard. Five whys, a fishbone diagram or a written paragraph are all acceptable. What is tested is whether the cause you stated could plausibly have produced the finding, and whether the action you took removes that cause. Naming a person rather than a process is the version that gets rejected.
How many nonconformities should a first internal audit find?
Five to fifteen is a normal range for a young management system, mostly minor. Far fewer suggests the audit was narrow or the auditor was not independent. Far more usually means the system was audited before it had been running long enough to produce evidence, which is a scheduling problem rather than a quality one.
Who is allowed to close a corrective action?
Not the person who performed the action alone. Closure requires a review that the action was implemented and, separately under 10.2 d), a later review that it was effective. In a small company the ISMS owner reviews and closes, and the effectiveness review is confirmed at management review. What matters is that two moments exist and both are dated.