Clause 10 of ISO/IEC 27001:2022 is the last of the mandatory clauses, and it asks for two things. First, you must keep improving the suitability, adequacy and effectiveness of your ISMS (10.1). Second, when something goes wrong or falls short of a requirement, you must fix it properly, not just patch it (10.2). Auditors check both by looking for a trail: what you found, what you decided, who did it, and whether it worked.
This guide explains what each sub-clause requires in practice, how to run a single improvement log that serves both, which evidence auditors tend to ask for, and how to plan the people and time behind it.
TL;DR
- Clause 10.1 requires continual improvement of the ISMS’s suitability, adequacy and effectiveness. It is proactive and never “finished”.
- Clause 10.2 is the reactive side: react, correct, find the root cause, act, then review whether the action worked.
- Inputs come mostly from Clause 9: internal audits, management review and monitoring results, plus incidents and risk assessment changes.
- One tracked log, with owners, due dates and an effectiveness check, is the simplest evidence an auditor can follow.
- Budget recurring time for audits, reviews and follow-up, not only the initial implementation.
Table of Contents
- What Clause 10 requires
- Clause 10.1: continual improvement in practice
- Clause 10.2: nonconformity and corrective action
- How 10.1 and 10.2 differ
- Running one improvement log
- Prioritizing improvement actions
- Evidence auditors accept for Clause 10
- Our perspective
- Planning the people and time behind Clause 10
- Estimate the effort before you commit
- Common failure patterns
- FAQ
- Sources
What Clause 10 requires
The 2022 edition of the standard has two sub-clauses. Clause 10.1 requires the organization to continually improve the suitability, adequacy and effectiveness of the ISMS. Clause 10.2 covers nonconformity and corrective action. Older guides may show these in the opposite order, because the 2013 edition numbered them differently. If you are reading a pre-2022 article, check the numbering before you copy a procedure title into your own documents.
The three words in 10.1 are worth separating:
- Suitability: does the ISMS still fit the business, its context, its customers and its risk appetite?
- Adequacy: does it cover enough, in scope, controls and resources, to meet the requirements and your objectives?
- Effectiveness: do the controls and processes actually deliver the results you set for them?
A static ISMS can pass its first certification audit and still drift. Systems change, staff turn over, suppliers are swapped, and the risk picture moves. Clause 10 is where the standard says the management system must move with them.
Clause 10.1: continual improvement in practice
The clause does not prescribe a method. It does not require a named procedure or a particular tool. What it requires is that improvement actually happens, and that you can show it. That is why auditors look at the outputs of other clauses for proof.
Where improvement ideas come from
Improvement does not start in Clause 10. It starts in the clauses that measure the system. Internal audits and management reviews under Clause 9 are the main way to identify weaknesses or opportunities, and ISACA’s guidance on the 2022 transition also notes that management review can show where controls need to line up better with business objectives. Typical inputs include:
- Internal audit findings, including observations that are not formal nonconformities
- Management review decisions and actions
- Security incidents and near misses, and the lessons from them
- Results of monitoring and measurement against your security objectives
- Changes to the risk assessment, new threats or new suppliers
- Feedback from customers, regulators and external audits
If you want a practical view of how the review step feeds improvement, our guides on management review in an ISMS and on the management review agenda mapped to Clause 9.3 inputs show what to bring to the room.
Using PDCA as the structure
Many teams organize improvement around Plan-Do-Check-Act. It maps neatly: risk assessment and objectives are Plan, the controls in Clause 8 and Annex A are Do, Clause 9 is Check, and Clause 10 is Act. The point is that the cycle closes: what you learn in Check changes what you Plan next. For a plain-language explanation, see our article on what continual improvement means in an ISMS.
What counts as an improvement
Improvement is not only fixing failures. Examples that auditors accept as genuine include:
- Reducing the time to revoke access after an employee leaves, with a measured before and after
- Replacing a manual quarterly access review with a tool-supported one
- Narrowing a risk treatment plan after a supplier is retired
- Rewriting a policy that staff repeatedly misunderstood, based on training feedback
- Adding a security objective once a previous one has been met consistently
What these share is a stated reason, a change, an owner and a result. A change nobody can explain is activity, not improvement.
Clause 10.2: nonconformity and corrective action
A nonconformity is a failure to meet a requirement, whether in the standard, your own documented ISMS or a legal obligation you have committed to. When one occurs, the standard requires you to react to it, take action to control and correct it, and deal with the consequences. Then you go further than the symptom.
The sequence the clause expects
- React. Contain the problem. Revoke the credential, restore the backup, stop the data flow.
- Correct and deal with consequences. Repair the immediate damage, and notify whoever needs to know.
- Evaluate the cause. The standard requires you to evaluate the need for action to eliminate the causes, so the issue does not recur or happen elsewhere. This is the root cause step.
- Implement the corrective action. Assign an owner and a date.
- Review effectiveness. Check that the action worked, and keep the result as documented information.
- Change the ISMS if needed. If the root cause points to a gap in a policy, process or control, update it.
The step teams skip most often is the fifth. Closing a ticket is not the same as showing the fix held. Our guide on the five steps auditors accept for corrective action goes through a worked example, and the non-conformity examples guide shows what typical findings look like.
A worked example
Suppose an internal audit finds that three leavers kept VPN access for more than a week. A weak response disables the three accounts and closes the finding. A response that satisfies Clause 10.2 looks like this:
- Correction: disable the three accounts and review logs for use after departure.
- Cause: HR sends leaver notices by email to one person, who was on leave during two of the cases, and the VPN is outside the identity provider’s automated offboarding.
- Corrective action: connect HR system events to the offboarding workflow and add the VPN to the identity provider. Name a backup for the manual step in the meantime.
- Effectiveness check: after 90 days, sample every leaver and confirm access was removed within the target time. Record the sample and the result.
- ISMS change: update the joiners, movers and leavers procedure to reflect the new flow.
Every step produces something a reader can verify, and the sample at the end is what turns an intention into evidence.
How 10.1 and 10.2 differ
The two sub-clauses overlap in the records they produce, but they differ in what triggers them.
| Clause 10.1 Continual improvement | Clause 10.2 Nonconformity and corrective action | |
|---|---|---|
| Nature | Proactive, ongoing | Reactive, event-driven |
| Trigger | Audit and review outputs, metrics, risk changes, ideas | A failure to meet a requirement |
| Core question | Can the ISMS be more suitable, adequate or effective? | Why did this fail, and how do we stop it recurring? |
| Typical output | Improvement actions, updated objectives and controls | Correction, root cause, corrective action, effectiveness review |
| Evidence | Reviews, change records, trend data | Nonconformity records, action results |
Because the evidence overlaps, many organizations keep one register for both and tag each entry by type. That keeps the audit trail in one place and avoids two lists that fall out of sync.
Running one improvement log
The clause says nothing about spreadsheets or tools, but auditors repeatedly need the same facts. A log with the following columns is enough for most small and mid-sized organizations:
| Field | What to record |
|---|---|
| ID and date | When the item was raised |
| Source | Internal audit, management review, incident, risk review, customer |
| Type | Nonconformity, improvement opportunity, observation |
| Description | What was found, in plain language |
| Root cause | For nonconformities, the cause, not the symptom |
| Action and owner | What will change, and who is accountable |
| Due date | A real date, with a revised date if it moves |
| Effectiveness check | How and when you will confirm it worked, and the result |
| Status | Open, in progress, verified, closed |
One caution: do not close an item until the effectiveness check is recorded. An item closed on the due date, without a result, is a very common finding in surveillance audits.
Prioritizing improvement actions
No team can act on everything at once. ISACA’s guidance suggests prioritizing issues by severity and risk, assigning clear responsibilities and using a tracking mechanism to monitor progress. In practice, rank by three questions:
- Risk: how much does this item reduce a risk you have rated high in your risk assessment?
- Business impact: does it affect a customer commitment, a contract or a regulatory duty?
- Effort: can it be done this quarter, or does it need budget and a project?
A consistent scale makes the ranking defensible. If your risk criteria are loosely defined, start there: our guide to risk criteria templates from 3x3 to 5x5 and the risk assessment methodology guide cover the scoring side, and the remediation priority examples show how scores turn into an ordered backlog.
For U.S. readers, a useful comparison is the federal approach. NIST’s Program Review for Information Security Assistance (PRISMA) documents identified issues and provides prioritized corrective actions with projected resource impact. ISO 27001 does not require that format, but the habit of pairing every issue with a priority and a resource estimate is worth borrowing.
Evidence auditors accept for Clause 10
Clause 10 does not demand a specific document for continual improvement, but 10.2 is explicit about records: documented information must be kept as evidence of the nature of the nonconformities, the actions taken and the results of corrective action. For 10.1, the evidence is indirect, and an auditor will typically sample the following:
- The improvement log, showing items from several sources and at different stages, including closed items with effectiveness results
- Management review minutes, with decisions and actions that connect to log entries
- Internal audit reports, with findings that trace to corrective actions
- Security objectives and metrics, showing trends over more than one period
- Change records, such as an updated policy or risk treatment plan, with a stated reason
- Incident records, with lessons learned and the resulting changes
The test an auditor applies is traceability. Pick any entry and follow it: from where it came from, to the decision, to the change, to the check. If the chain breaks, the finding is usually about the process, not the single item.
Avoid assembling this trail in the weeks before an audit. Records created after the fact tend to look uniform, and sampling exposes the gaps. Update the log as work happens, and the evidence builds itself.
Our perspective
We see Clause 10 treated as the paperwork at the end of an implementation, when it is better understood as the part that decides whether the investment keeps paying back. Organizations budget carefully for the first certification and then underestimate the recurring effort of audits, reviews and follow-up. That is the gap a good estimate should close.
Our view is simple. Plan the improvement cycle at the same moment you plan the implementation, with named owners and recurring time on calendars. Keep assumptions visible so they can be challenged. And measure improvement by results, such as faster access removal or fewer repeated audit findings, not by the number of log entries. A short log with verified outcomes beats a long one full of open items.
— Martin
Planning the people and time behind Clause 10
Improvement is a standing workload. Plan for three recurring pieces of work: internal audits, management reviews, and the follow-up work from both. ISACA recommends planning internal audits and management reviews, and setting up a cross-functional steering committee with clear roles and responsibilities. A steering group with representatives from each part of the business keeps improvement from becoming one person’s job.
Practical points to settle early:
- Ownership: name an ISMS manager who owns the log, and an owner per action in the business area concerned.
- Cadence: decide how often the log is reviewed. Many teams review it monthly and take a summary to management review.
- Capacity: reserve engineering and IT time for corrective actions. If every fix competes with product work, closure dates slip.
- Training: staff need to know how to raise an issue. Keeping training material aligned with changes is part of the job, and cross-functional governance for ISMS training is worth thinking about once the program covers a large enterprise.
- Project risk: delays and resourcing shortfalls are common; see types of ISO 27001 project risks.
If you are still scoping the whole program, the ISO 27001 certification checklist shows where improvement work sits among the other steps.
Estimate the effort before you commit
The recurring cost of Clause 10 is the part budgets most often miss. Our ISO 27001 cost calculator gives a real-time estimate based on company size, industry and security maturity, with editable assumptions and model reference comparisons. You do not need to sign up for the first calculation, and the methodology is traceable so you can challenge any figure.
If you want to know where you stand first, take the free 2-minute readiness check, or run the fuller readiness assessment across the four Annex A control themes. You can save and compare estimates, plan phases on a Gantt timeline and export a PDF report to share with finance or leadership.
Common failure patterns
These are the patterns that most often turn Clause 10 into an audit finding:
- Closing without checking. The action is complete but nobody confirmed that it worked.
- Fixing symptoms. The same type of finding returns because the root cause was never examined.
- Disconnected records. Management review minutes mention improvements that never appear in the log.
- Stale items. Open actions pass their due dates with no revised date or explanation.
- Improvement limited to IT. Clause 10 applies to the whole scope, including HR, procurement, facilities and suppliers.
- Last-minute evidence. The log is built the month before the audit.
Each has the same cure: a living log, an owner for every item, and a recorded check at the end.
FAQ
What is the difference between Clause 10.1 and Clause 10.2?
Clause 10.1 is about continually improving the ISMS’s suitability, adequacy and effectiveness, whether or not anything has failed. Clause 10.2 applies when a nonconformity occurs and requires correction, root cause evaluation, corrective action and an effectiveness review. In short, 10.1 is proactive and 10.2 is reactive.
Does Clause 10 require a documented procedure?
The standard does not name a mandatory procedure for continual improvement. Clause 10.2 does require documented information as evidence of nonconformities, actions taken and corrective action results. Most organizations meet both with a short procedure and a single log.
How often should we review improvement actions?
The standard sets no frequency. A monthly review by the ISMS owner, with a summary at each management review, is a common and defensible rhythm. Choose a cadence you can sustain and record that you kept to it.
Is an internal audit observation a nonconformity?
Not necessarily. A nonconformity is a failure to meet a requirement. An observation points to a weakness or opportunity, and can be tracked as an improvement item under 10.1. Define both categories in your audit procedure so findings are classified consistently.
Sources
- ISO/IEC 27001:2022 standard, full text
- ISACA Journal: Navigating the ISO/IEC 27001:2022 Transition, a 90-Day Challenge
- NIST CSRC: Program Review for Information Security Assistance