What Clause 10.1 Requires
Clause 10.1 is one of the shortest requirements in ISO 27001:2022 — a single sentence carrying a single obligation: the organization must keep improving how suitable, how adequate, and how effective its ISMS is, for as long as the system exists. There is no prescribed method, no mandated meeting cadence, and no documented information explicitly required. The standard demands an outcome — an ISMS that is demonstrably better over time — and leaves the mechanism to you.
The three tests carry distinct meanings, and auditors use them deliberately. Suitability asks whether the ISMS still fits the organization it serves — its business model, size, technology stack, and threat profile. Adequacy asks whether the ISMS is sufficient for everything it must cover — legal, regulatory, contractual, and interested-party requirements included. Effectiveness asks whether the ISMS achieves what it set out to achieve — objectives met, risks genuinely reduced, controls performing as designed. Note also that the obligation is continual, not continuous: recurring, deliberate improvement at intervals rather than perpetual change — but an improvement engine that is never allowed to stall.
Why This Clause Exists
To stop the ISMS from fossilizing after certification. Clause 10.1 makes improvement itself a standing requirement, so the management system keeps pace with the organization, its risks, and its obligations across the full life of the certificate.
What This Really Means
Certification is a license to operate, not a finish line. The natural lifecycle of a management system without this clause is predictable: an intense build phase, a celebrated certificate, then slow decay as attention moves elsewhere. Clause 10.1 exists to make that decay a nonconformity. Think of the ISMS as a product with a roadmap, not a monument with a plaque — the standard expects version two to ship.
The three tests become concrete the moment you attach examples. Suitability: you certified as a 60-person on-premises company and you are now 200 people, cloud-native, and shipping an AI feature — the original ISMS may run perfectly and still no longer fit. Adequacy: a flagship customer writes 24-hour breach notification into a new contract, or a privacy law starts applying to you — an ISMS that does not absorb the new obligation is no longer enough. Effectiveness: your phishing simulation failure rate has been flat for four quarters despite annual training — the control operates, but it does not work. Each lens generates a different kind of improvement, and a healthy ISMS shows movement on all three.
Improvement is not just fixing what broke — that is Clause 10.2 territory. The strongest 10.1 inputs arrive while everything is nominally fine: metric trends from Clause 9.1 monitoring (rising patch latency, slipping access-review completion), opportunities for improvement raised by internal and certification auditors, lessons from incidents and near-misses, technology shifts that obsolete a control design (SSO and passkeys replacing password rules, automation replacing manual evidence collection), supplier changes, and plain maturity ambition — moving a control from ad hoc to managed to measured. Mechanically, most organizations run all of this through a continual improvement register: a simple log capturing each opportunity with its source, description, owner, priority, status, and outcome. Big-ticket items graduate into formal Clause 6.2 objectives with resources and deadlines; small ones close as routine actions.
What auditors treat as the heart of 10.1 is movement they can evidence across the three-year certificate cycle. At the year-one and year-two surveillance visits, the auditor is explicitly comparing this year's ISMS with last year's: register entries opened and closed, metric targets that tightened because the old ones were consistently met, controls that matured from manual to automated, observations from the previous visit that did not reappear. An ISMS that is identical to the one certified two years ago — same risks, same objectives, same documents at the same versions — is not read as stable. It is read as abandoned.
Why It Matters
An ISMS frozen at certification protects the organization you used to be. Businesses change faster than management systems by default — new products, new platforms, new hires, new attackers — and the gap between the paper system and the real organization is precisely where unmanaged risk accumulates. Clause 10.1 is the standard's mechanism for closing that gap on a schedule rather than after a breach. There is a hard economic angle too: you already pay for monitoring, internal audits, penetration tests, and incident post-mortems. Improvement discipline is what converts that spend from reporting overhead into compounding returns.
The certification stakes are asymmetric across the cycle. At Stage 1 and Stage 2 you can usually satisfy 10.1 by showing the mechanism exists — an improvement register, management review minutes with improvement decisions, objectives that move. The real exposure starts after the certificate is issued: certification bodies are required to verify at surveillance that the ISMS continues to improve, and a frozen system leaves the auditor little choice but to write findings.
Where weak continual improvement bites:
- •Surveillance findings for a frozen ISMS – Year-one and year-two surveillance audits specifically probe for movement; an unchanged risk register, untouched objectives, and an empty improvement log can draw a Clause 10.1 nonconformity even when no individual control has failed.
- •Paper-reality drift – The business adopts new platforms and processes while the ISMS keeps describing last year's organization; controls designed for the old world quietly stop protecting the new one.
- •Repeat observations that harden – Opportunities for improvement that resurface audit after audit erode auditor confidence, and what was a friendly observation in year one tends to return as a nonconformity by year three.
- •Wasted intelligence – Monitoring data, audit results, and incident lessons that never produce change mean the organization is paying for signals it refuses to act on.
- •Stalled maturity – Without a deliberate improvement loop the ISMS stays at the level certification demanded, while customer questionnaires, regulatory expectations, and attacker capability keep rising around it.
Documented Information Required
Continual improvement register
RecommendedClause 10.1 mandates no specific document, but this register is the de facto evidence pattern: a dated log of improvement opportunities with source, description, owner, priority, status, and outcome. A good one shows entries from multiple sources — metrics, audits, incidents, suggestions — and a believable mix of closed, active, and consciously parked items.
Management review minutes recording improvement decisions
RecommendedFormally required under Clause 9.3, but auditors trace 10.1 through them: improvement opportunities arriving as review inputs and leaving as resourced decisions. Minutes that never mention improvement suggest the register is decoration.
See the full ISO 27001 mandatory documents checklist for every document and record the standard requires.
How to Implement Clause 10.1
Define What Improvement Means for Your ISMS
Anchor the three tests — suitability, adequacy, effectiveness — in a one-page section of your ISMS manual or improvement procedure, with two or three concrete triggers for each (business or technology change, new obligations, underperforming metrics). This gives reviewers and auditors a shared definition and stops "improvement" from collapsing into "whatever we happened to fix this year".
Stand Up a Continual Improvement Register
A spreadsheet or a dedicated project in your ticketing system both work. Minimum fields: ID, date raised, source (metric trend, internal audit, certification audit, incident, suggestion, technology or regulatory change), description, owner, priority, target date, status, and the outcome or benefit recorded at closure. Classifying entries by suitability, adequacy, or effectiveness is optional but makes the audit conversation easy.
Wire In the Input Sources
Improvement entries should arrive automatically, not by inspiration. Add standing triggers: every Clause 9.1 metrics review ends by asking what the trends suggest changing; every internal audit report transfers its opportunities for improvement into the register; every incident post-mortem and near-miss review contributes at least a candidate entry; a quarterly regulatory and technology watch feeds in what changed around you.
Triage and Route by Size
Score entries on effort and impact in a monthly or quarterly security steering session. Small items close as routine actions with an owner and a date. Strategic items — new tooling, control redesign, scope expansion — graduate into formal Clause 6.2 information security objectives, planned properly with resources, responsibilities, and deadlines.
Assign Owners and Protect the Cadence
Every open entry needs a named owner and a target date — unowned improvements are wishes. Cap work in progress to what the team can genuinely move and consciously park the rest with a recorded rationale. A register showing eight closed, three active, and four parked items is far stronger audit evidence than forty open items untouched for a year.
Run Improvement Through Management Review
Clause 9.3 requires improvement opportunities as a review input and decisions about them as an output. Put the register on the management review agenda: top management confirms priorities, allocates resources, and formally accepts or defers items, with the decisions captured in the minutes. This is the link auditors follow between Clause 10.1 and leadership commitment.
Build the Evidence Narrative for Surveillance
Before each surveillance visit, assemble the year in movement: register entries closed with outcomes, before-and-after metric trends, version-history deltas in key documents showing substantive change, controls that matured, and prior audit observations that did not recur. Auditors at surveillance are looking for a trajectory — hand them one.
Audit Evidence
During Stage 1 and Stage 2 of your ISO 27001 certification audit, auditors will expect the following evidence to demonstrate conformity with Clause 10.1:
Documentation
- Continual improvement register with dated entries from multiple sources and a credible mix of open, closed, and parked items
- Management review minutes showing improvement opportunities as inputs and resourced decisions as outputs
- ISMS metric trend reports with evidence that flat or adverse trends triggered action
- Version histories of key ISMS documents (risk register, objectives, policies) showing substantive year-on-year change
- Closure evidence for opportunities for improvement raised at previous internal and certification audits
Interviews
- CISO or ISMS manager on how improvement opportunities are identified, prioritized, and resourced
- Top management on improvement decisions taken at management review and the resources committed to them
- Control or process owners on a specific improvement delivered in the last year and what triggered it
Observations
- Live walkthrough of the improvement register, including aging of open items and the quality of closure notes
- Comparison of current metric dashboards and targets against the previous year's baselines
- Sampling document version histories to confirm changes are substantive rather than cosmetic date bumps
Practitioner Insights
At recertification I compare the ISMS in front of me with the one certified three years earlier, and the strongest signal is movement, not polish: metric targets that tightened because the old ones were consistently met, controls that went from manual to automated, scope that grew with the business. A pattern I see across audits is the risk register whose only substantive edits cluster in the week before each annual visit — that tells its own story, and Clause 10.1 is where it gets written up.
Small teams over-engineer this clause. You do not need an improvement program with steering committees — a ten-row spreadsheet reviewed at management review beats one every time. The trap I see constantly is the inverse: startups genuinely improve all year — SSO rolled out, offboarding automated, alerts tuned — but log none of it, so at surveillance they have twelve months of real improvement and zero evidence. Write the register entry the week the change ships, not the week before the audit.
Common Challenges & Solutions
Challenge
Improvement genuinely happens all year, but nobody records it, so the audit sees an empty register.
Solution
Make logging part of the change itself: any security-relevant improvement gets a one-line register entry when it ships, written by whoever shipped it. Tie the habit to an existing ritual — sprint reviews, the change advisory board, monthly security syncs — and have the ISMS manager sweep recent changes monthly for anything missed. Reconstructing a year from memory before surveillance never produces credible evidence.
Challenge
The improvement register is a graveyard — dozens of open items, nothing closed in months.
Solution
Cap active items to what the team can actually move (three to five at a time is realistic for most SMBs), give each a named owner and target date, and consciously park the rest with a recorded rationale. Review aging at every steering meeting and close or re-decide anything stale. Auditors read a small, moving register as health and a large, static one as decoration.
Challenge
After certification the implementation team disbands and the ISMS freezes until the next audit panic.
Solution
Treat certification as a handover, not an ending: name the standing owner of the ISMS calendar — quarterly metrics reviews, annual risk reassessment, objectives refresh, internal audit — and budget post-certification effort explicitly (a few days a month is typical for a small organization). Put the full three-year cycle in the calendar on day one so surveillance visits arrive as checkpoints, not surprises.
Challenge
Everything in the register is reactive — fixes for things that broke — so there is no evidence of proactive improvement.
Solution
Tag each entry with its source and check the mix quarterly. If audits and incidents dominate, deliberately seed proactive entries: ask each metric owner for one improvement their trend suggests, harvest one item per quarter from technology and regulatory watch, and set at least one forward-looking Clause 6.2 objective per year — automation, maturity uplift, scope extension. A purely reactive register describes Clause 10.2, not 10.1.
Challenge
Metrics and dashboards exist, but nobody can point to an improvement that came from them.
Solution
Close the loop structurally: end every metrics review with a standing agenda item — what do these trends tell us to change? Require each metric owner to propose one action or explicitly record that none is needed, and capture the decision. Being able to trace even a few register entries back to specific metric movements is exactly what auditors test when checking that Clause 9.1 outputs feed Clause 10.1.
