ISO 27001 Clause 10.1: proving continual improvement at audit

Your surveillance audit is weeks away, and the ISO 27001 Clause 10.1 improvement log is a blank page. The auditor will ask what has got better since certification, and an ISMS identical to last year's answers that badly.

This guide is for information security managers, heads of compliance and IT directors at firms of 25–250 staff. It sets out what the clause requires, how to run one improvement log, and the evidence and questions you will meet in the room.

What does ISO 27001 Clause 10.1 require?

ISO 27001 Clause 10.1 requires the organisation to continually improve the ISMS's suitability, adequacy and effectiveness. Suitability asks whether the system still fits how the business operates; adequacy, whether it covers current risks and obligations; effectiveness, whether controls deliver their intended outcomes. Certification rewards a system that improves, not a snapshot.

The clause is one sentence long, but its reach is the whole standard. Monitoring under Clause 9.1, internal audit findings and the decisions recorded at management review all feed it. Clause 10.1 is where those inputs become change.

Auditors sample against three operational definitions:

• Suitability: does the ISMS still fit how the business works today? A new product line, a cloud migration or a doubling of headcount can leave a once-suitable scope out of date.
• Adequacy: does it cover current risks and obligations? A new customer contract, a regulatory change or a fresh threat pattern should surface in the risk assessment and the controls that answer it.
• Effectiveness: do the controls achieve what they exist to achieve? A control that operates but never reduces the incidents it targets is not effective.

Auditors expect improvement evidence that touches all three over time. A year spent tuning controls, with no look at whether the scope still fits the business, leaves a visible gap.

Take a 50-person SaaS firm that moves customer data into a new cloud region. Suitability prompts a scope and asset register update, adequacy a risk reassessment for the new location, and effectiveness a test that backup restores still work there. One business change produces three log entries, each on a different axis.

How does Clause 10.1 differ from Clause 10.2?

Clause 10.1 is the standing engine: the ongoing obligation to improve the ISMS from every input, whether or not anything has failed. Clause 10.2 is the reactive machinery for a specific nonconformity: contain it, find the cause, fix it and verify. In ISO 27001:2022, 10.1 is continual improvement and 10.2 is nonconformity and corrective action.

Think of the pair as proactive and reactive. Clause 10.1 asks what could be better while nothing is broken, drawing on monitoring results, audit observations, staff suggestions and changes in the business. Clause 10.2 starts only once a nonconformity exists.

Numbering invites mistakes. ISO 27001:2013 ran the two the other way round, with corrective action at 10.1 and continual improvement at 10.2, and ISO 9001 puts continual improvement at 10.3. Check which edition a source describes before quoting a clause number to an auditor.

In practice, one log serves both clauses. A nonconformity from an audit enters the log and runs through containment, cause, fix and verification. The lessons it teaches, such as a control gap elsewhere or a process that needs redesign, then spawn further improvement entries.

Keeping the distinction visible matters at audit. If every entry in your log is a fix for something that broke, you are evidencing Clause 10.2, and the auditor can fairly ask what drives improvement when nothing breaks.

A supplier's annual security report with no critical findings triggers no corrective action. It can still prompt an improvement entry to tighten how often you review that supplier.

Why do static ISMS installations fail surveillance audits?

A static ISMS decays because the business, the threats and regulator expectations keep moving while the controls stay frozen at certification day. Surveillance auditors look for exactly that, and "no evidence of improvement activity" is one of the most common findings in years two and three, when the certificate is genuinely at stake.

At initial certification the auditor judges a system in prospect. At surveillance, the question shifts from whether the ISMS exists to what has changed since the last visit.

Drift is quiet. The business adds technology, staff and customers, attackers change techniques and regulators change expectations, while the risk assessment still describes certification day. The expensive version is the repeat incident, caused by a problem that was patched but never fixed.

UK governance guidance expects the same loop. The Cyber Governance Code of Practice from DSIT and the NCSC asks boards to gain assurance that a post-incident review process feeds lessons into future risk assessments, response and recovery plans, and exercising. It also asks for regular risk assessments and metrics reported at least quarterly, which an improvement log produces as a by-product.

The commercial side is as concrete. An enterprise buyer's security team can see in five minutes of diligence whether your improvement trail is a living record or a one-off. Firms that treat compliance as an annual scramble look different from those whose security posture compounds, and procurement notices.

How do you run a single improvement log for Clause 10.1?

Run one improvement log for the whole ISMS. Every entry records its trigger, root cause where relevant, a named owner and a target date. Audit findings, incidents, near-misses, staff suggestions, risk updates and management review decisions all route into it. A shared tracker or ticketing project is fine; the discipline matters, not the tool.

Put the log where the people who act on it already work. A tracker nobody opens fails regardless of how well it is designed, and every mandatory field should earn its place.

Keep the fields few and mandatory:

• Trigger: the feed that created the entry, so the variety of intake is visible.
• Root cause: for anything non-trivial; one sentence is enough.
• Owner: one named person, not a team.
• Target date: the date the owner agreed to, not a placeholder.
• Status and evidence: open, in progress, verified or closed, with a link to the artefact that proves it.

Work Plan-Do-Check-Act without ceremony: pick the change, make it, check it landed, then keep or adjust. At 25–250 staff that is a habit inside existing stand-ups and monthly reviews, not a framework deployment.

Attach a number where you can. A handful of objectives and KPIs, such as repeat-incident rate, time to remediate and training completion, turn "we improved" from an assertion into a trend line.

Stand the log up once monitoring under Clause 9.1 and internal audit start producing findings, because before then there is little to improve from. At steady state it takes an hour or two a month of triage and tracking, folded into your existing operational rhythm.

The ICO Data Protection Audit Framework offers audit trackers that help you assess your own compliance and track the actions you plan where improvement is needed. That is the shape your log should take.

Three habits turn the log into a liability, and each is cheap to avoid:

• Informal fixes. The change shipped with no record, so it cannot be shown later.
• Ownerless entries. Items without a name or a date drift open indefinitely.
• Over-engineering. A documented methodology with committees and cadences that a 40-person team never executes. Auditors test practice against paper, and the gap is itself a finding.

A log that fills up in the fortnight before the audit and sleeps the rest of the year doesn't show improvement. Its timestamps show the sprint.

How do you find root causes and confirm a fix worked?

For anything non-trivial, ask why it happened before deciding what to change; a lightweight 5 Whys pass is enough at this scale. Then close the loop deliberately: after the change ships, check it worked, and record the evidence, before marking the item done. An unverified fix is a future repeat finding.

Root cause analysis at this scale needs a whiteboard, not a methodology. State the problem, ask why, and repeat until the answer is something you can change. The last answer is usually a process or ownership gap rather than a person.

A worked example: a phishing click led to stolen credentials. Why did the attacker get in? The mailbox had no MFA. Why? It was created outside the onboarding checklist. Why? Contractors are onboarded by a different team. The fix is one onboarding path for everyone, not another awareness email.

Choose the check that fits the fix, and file its result in the entry's evidence field:

• Configuration change: a re-scan or settings export showing the new state.
• Process change: a sample of the next cases showing the new process was followed.
• Training change: a simulation or quiz result in the following quarter.
• Metric-led change: the number that should move, read after a fair interval.

If you cannot say how you would know a fix worked, the fix is not yet specific enough to ship.

Does continual improvement stop at the IT estate?

No. Supplier management, HR processes, physical security and business workflows all sit inside the ISMS, so they all need improvement activity. An improvement log made up entirely of technical tickets signals a narrow system. Leaving supplier, people and physical processes untouched lets them fossilise while the technical estate moves on.

Technical tickets are the easiest to generate, because scanners and alerts produce them on their own, so they dominate unless intake is deliberately widened. Four areas usually go quiet:

• Supplier management: a vendor review that finds no exit plan leads to a standard exit clause and an updated onboarding questionnaire.
• HR processes: a leaver whose access lingered leads to a joiner-mover-leaver checklist with HR sign-off.
• Physical security: a visitor sign-in found bypassed leads to a spot-check routine and a revised reception procedure.
• Business workflows: a sales team sharing customer files through personal accounts leads to an approved transfer route.

Auditors read the mix of entries. Areas outside IT rarely improve unprompted, since nobody's day job is watching them age. A simple habit fixes a lopsided log: ask each function lead for one candidate improvement at every management review.

The payoff reaches beyond the audit. A log entry that tightens supplier oversight also answers part of the next due-diligence questionnaire, because buyers in regulated sectors ask how you manage your own vendors.

What evidence do auditors accept for continual improvement?

Auditors accept the improvement log showing varied triggers driven to closure over time, root cause records for significant items, management review minutes showing resourced decisions, remediated audit findings, a metric trend that moves, and the artefacts changes leave behind, such as revised policies and updated configurations.

Have these ready, in whatever lightweight form your team actually used:

• The improvement log: dated, owned and statused, with entries from varied triggers.
• Root cause records: a short note or ticket comment is enough for significant items.
• Management review minutes: leaders weighing performance and committing resources, with each decision traceable to a log entry.
• Remediated audit reports: findings visibly fixed and verified.
• A metric trend: fewer repeat incidents, faster fixes, better training coverage.
• Change artefacts: revised policies with version history, updated configurations, amended registers.

Improvement nobody recorded is, at audit, improvement that never happened.

Version history does quiet work here. A policy with dated revisions, each tied to a log entry, answers the question "what changed?" without anyone speaking.

An export of the log without creation dates is a weak exhibit, because the auditor cannot see when the entries arrived. Keep the timestamps native to the tool.

Direction is what the auditor reads from a metric. A repeat-incident count that falls across the year, even from rough data, shows a system learning: imperfect numbers with a direction beat perfect numbers with none.

What will the auditor ask about Clause 10.1 in the room?

Expect five questions: where log entries come from and who drives them; what triggered a closed item and how the fix was confirmed; which way security objectives are moving; what the last management review produced; and how a staff suggestion becomes a change. Auditors trace two or three entries end-to-end from trigger to verification.

A good answer to each is short, specific and already open on screen:

• Where entries come from: name the feeds and who triages them, with the log already open.
• A closed item: choose one with trigger, action and verification evidence in one place.
• Objectives: show the KPI view with at least one trend and a reason for its direction.
• Management review: show minutes whose action items link to log entries and their current status.
• A staff suggestion: walk through the channel, the triage step and a real example.

Beyond the trace, the auditor checks that management review decisions actually reach the log. At surveillance visits especially, they also ask whether anything at all has improved since the last audit.

In certification-body practice, no demonstrable improvement mechanism at all, or a system visibly unchanged across audit cycles, grades as a major nonconformity. A thin patch on the log grades minor, and several minors can aggregate into a major as a pattern.

Choose your own trace candidates before the audit and walk them yourself. If you cannot go from trigger to verification in a few minutes, the auditor will not manage it either.

How does GRC engineering automate continual improvement?

Automation removes the dependence on memory. Audit findings, post-mortems, near-misses and suggestions create entries in one tracked backlog automatically; KPIs such as repeat-incident rate and remediation age compute live from source systems; tickets carry a verification step before closure; and "show me improvement since last year" becomes a filtered query.

Intake works through integrations. A finding raised in your audit tool, a post-mortem document and a near-miss form each create a ticket in the improvement project with the trigger field pre-filled. Staff suggestions arrive through a form or chat command that does the same, so nobody has to remember to log.

KPIs come from the systems of record: the incident tracker for repeat-incident rate, the ticketing system for remediation age and the learning platform for training coverage. The trend is the product. NIST makes the same point in SP 800-53 control CA-7, Continuous Monitoring: its trend-analysis enhancement, CA-7(3), uses empirical data to decide whether control implementations and monitoring activities need to change.

A workflow rule can block the move to Done until the evidence field holds a link or attachment. Verification stops being a reminder and becomes part of the tool.

The audit answer becomes a saved view: entries created or closed in the last twelve months, grouped by trigger and function, with timestamps and linked artefacts. The entries an auditor wants to trace are two clicks away.

This engineered loop is what our GRC Engineering service builds, while a Fractional CISO owns the human layer: running the root-cause discipline and keeping leadership resourcing the changes. Judgement stays with people, and capture, computation and enforcement belong to the pipeline.

At this scale, surveillance preparation collapses from days to minutes.

Frequently asked questions