Most organisations treat continual improvement as the part of ISO 27001 that comes after the real work is done. You get certified, log a few corrective actions, note “continual improvement” in your management review, and move on.
The result is an ISMS that stays static, or even rolls backwards. Policies written at implementation sit unchanged three years later. Risks identified in year one are still the only risks on record. The internal audit raises the same observations every cycle because no one follows through.
This is not what ISO 27001 intends — and an experienced auditor will spot it quickly.
In ISO 27001 continual improvement is directly addressed by Clause 10 of the standard, but its inputs come from almost every other clause. Done properly, it is the mechanism that transforms ISO 27001 from a one-time certification project into a management system that improves over time.
This article explains what genuine improvement looks like, where it comes from, and how to build it into the rhythm of your ISMS rather than treating it as an afterthought.
What Continual Improvement Actually Means in ISO 27001
ISO/IEC 27001:2022 Clause 10.2 states simply that the organisation shall continually improve the suitability, adequacy, and effectiveness of the information security management system.
Three words matter here: suitability, adequacy, and effectiveness.
Suitability means the ISMS fits your organisation. As your business changes — new services, new staff, new technology, new suppliers — your ISMS should evolve to match. An ISMS designed for a ten-person team that has grown to eighty is no longer suitable, regardless of how well it was built originally.
Adequacy means the ISMS is comprehensive enough to address your risks. If new threats emerge — AI-assisted phishing, a new class of supply chain attack, a change in regulatory requirements — and your ISMS has nothing to say about them, it is inadequate.
Effectiveness means the controls you have in place are actually working. Having a password policy is not the same as having staff who follow it. Having a vulnerability management process is not the same as having vulnerabilities that get patched.
Improvement is not about adding more policies. It is about asking whether what you have is working, whether it still fits, and whether it is enough — then acting on the answers.
The PDCA Foundation
Continual improvement in ISO 27001 is built on the Plan-Do-Check-Act cycle, which runs through the entire standard:
- Plan (Clauses 4–6): Understand context, define scope, assess risks, set objectives
- Do (Clause 8): Implement controls and operational processes
- Check (Clause 9): Monitor, measure, audit, and review
- Act (Clause 10): Correct problems, improve the system
The critical insight is that PDCA is not a one-time loop. It runs continuously, at multiple timescales — daily operational decisions, quarterly metric reviews, annual management reviews, and the three-year recertification cycle all feed back into the same improvement engine.
Most organisations complete the Plan and Do phases during implementation, then stop. They forget that Check and Act are supposed to run on a regular cadence indefinitely.
Where Improvement Comes From: The Seven Inputs
I get asked quite frequently in my training sessions where improvements are supposed to come from. The answer is ‘everywhere’, but more specifically, there are several understood pathways which you should consider formalising.
What Feeds Into Continual Improvement
ISO 27001 builds improvement inputs into seven formal mechanisms across the standard
Revised policies
Closed risks
Better metrics
Stronger evidence
1. Nonconformities and Corrective Actions (Clause 10.1)
When something goes wrong — a control fails, a process is not followed, an audit raises a finding — that is a nonconformity. Basically, if your ISMS doesn’t do what you said it would do (either in terms of conforming to ISO 27001 or your own rules), then you have a nonconformity.
Clause 10.1 requires you to react to the nonconformity, investigate the root cause, take corrective action, and verify that the action worked.
The keyword is “root cause”. Many organisations log a nonconformity, write “staff will be reminded of the policy,” and close it. That is not corrective action — it is symptom treatment. If staff are not following the policy, the question is why: is the policy unclear? Is it impractical? Is training inadequate? Is there no consequence for non-compliance?
Fix the root cause, and the nonconformity does not recur. Fix the symptom, and it comes back at the next audit.
2. Internal Audit Results (Clause 9.2)
Internal audits are your primary mechanism for finding nonconformities before your certification body does. But they also surface something more valuable: observations and opportunities for improvement that have not yet become nonconformities. So, it’s not necessarily that something is broken, but just that people have identified suggestions for where things could be done a bit better.
A well-run internal audit programme does not just check whether procedures are followed. It asks whether the procedures are still fit for purpose, whether controls could be more efficient, and whether any areas pose risks that have not yet been formally assessed.
3. Management Review Outputs (Clause 9.3)
The management review is not simply a reporting exercise — it is a decision-making meeting. Its output should include decisions about improvement opportunities and any need to change the ISMS. If your management review minutes say “no changes required” every year, something is wrong.
Management review is the point at which leadership either drives improvement or signals that it is not a real priority. The agenda items prescribed by Clause 9.3 — changes in external and internal issues, security incident trends, audit results, risk assessment status, and performance against objectives — are specifically designed to surface areas for improvement.
If senior management excel at one thing, it’s standing back, making observations and expecting them to be dealt with, so we may as well harness that…
4. Security Incidents (Clause 6.1 / Annex A 5.26)
Every security incident is a data point… A phishing email that was clicked tells you something about training effectiveness… A misdirected email tells you something about your data handling procedures… A supplier breach tells you something about your supply chain due diligence — all of these things indicate something isn’t quite right and should lead to improvement.
Organisations that treat incidents purely as problems to be resolved and closed miss the signal for improvement. The better approach is to ask what each incident reveals about a gap in your ISMS and whether that gap requires formal corrective action or a policy update.
Trend analysis (back to root causes) should also be considered and slots right into the ITIL Problem Management process, if you have it, whereby you look at the bigger picture in terms of reporting and try to see if there are upward trends in incident types, etc. For example, you might note that phishing emails are notably on the rise, so you might ramp up efforts in that area for a period.
5. Risk Assessment Updates (Clause 6.1.2)
Your risk assessment is not a document you produce once for certification. It should be a live picture of your risk landscape, updated when your business changes, when new threats emerge, or on a defined periodic basis.
A risk that was rated low two years ago may be rated high today. A control that was adequate for a previous threat profile may now be insufficient. The risk assessment update process is a direct input to improvement planning.
It could also be that an external risk assessment is carried out by a third-party (for example, a security health-check, or vulnerability scan) which identifies areas of weakness and suggests improvements in your security. It’s down to you as to the level of granularity you go to, but I’d certainly use something like that as a meaningful source of input to the improvement cycle.
6. Monitoring and Measurement (Clause 9.1)
“You cannot improve what you do not measure,” goes the saying.
Clause 9.1 requires you to determine what needs to be monitored and measured, the methods for doing so, when the analysis will be performed, and who will evaluate the results.
Useful security metrics include patch compliance rates, mean time to resolve incidents, percentage of staff with current training, supplier assessment completion rates, and access review frequency.
Metrics that trend in the wrong direction are improvement inputs. Metrics that remain flat despite attempts to improve them suggest a deeper problem.
7. Interested Party Feedback (Clause 4.2)
Customers, regulators, certification bodies, and partners all generate information that should feed into your improvement cycle.
A customer security questionnaire that highlights a gap you had not considered, a regulatory update that changes your obligations, or a surveillance audit observation that is not quite a nonconformity — these are all legitimate improvement triggers.
Building the Improvement Cycle Into Your ISMS
Knowing the inputs is not enough. You need a mechanism that captures them, prioritises them, acts on them, and verifies the outcome. Here is a practical structure.
The Improvement Register
Maintain a simple log — a spreadsheet is sufficient, or Jira, or any other tool you have — that captures every improvement opportunity regardless of source. Each entry should record what triggered it, the root cause or underlying issue, the agreed-upon action, who owns it, the target date, and the outcome.
This is not the same as your risk register or your nonconformity log, though it may draw from both. Its purpose is to give your ISMS lead a single view of all open improvement actions, so nothing falls through the cracks.
Quarterly Review Rhythm
Between annual management reviews, I’d recommend you run a lightweight quarterly check.
This does not need to be a formal meeting — a 30-minute review by the ISMS lead is sufficient. The purpose is to check whether open improvement actions are progressing, whether any new inputs have come in since the last review, and whether any metrics are moving in the wrong direction. Just document decisions and review, and your auditor will love you for it.
Organisations that only look at improvement once a year tend to discover at the management review that six months’ worth of problems have accumulated. A quarterly rhythm catches issues while they are still manageable, shows constant progress, and helps build traction.
Objective-Led Improvement
ISO 27001 Clause 6.2 requires you to establish information security objectives. These should not be vague aspirations (“improve our security posture”) but specific, measurable targets with owners and timelines.
Objectives create a natural improvement mechanism: you set a target, measure against it, identify the gap, take action to close it, and set a new target. Done well, objectives drive improvement even in the absence of nonconformities.
Examples of useful objectives:
- Reduce the mean time to patch critical vulnerabilities from 14 days to 7 days by Q3
- Achieve 95% completion of annual security awareness training by December
- Complete formal security assessments of all Tier 1 suppliers by end of year
- Reduce phishing simulation click rate from 12% to below 5% over 12 months
The Corrective Action Process in Practice
When a nonconformity or significant improvement need is identified, the corrective action process should follow a consistent structure.
Contain it first.
If the nonconformity represents an active risk — a system is exposed, data may be at risk — take immediate containment action before you investigate the root cause. Document what you did and why.
Investigate the root cause.
Ask why the problem occurred, not just what happened. Common root cause categories include inadequate training, unclear procedures, insufficient resources, process design flaws, and technology failures. A simple “five whys” analysis is often sufficient.
Define the corrective action.
The action should address the root cause, not the symptom. Assign it to a named owner with a realistic target date.
Verify effectiveness.
After the action is complete, check whether it worked. For a training gap, this might mean a follow-up assessment or monitoring phishing simulation results. A process failure might mean re-auditing the process in the next audit cycle.
Document everything.
Clause 10.1 requires you to retain documented evidence of the nature of the nonconformities, the actions taken, and the results of the corrective actions. This documentation is what an auditor will review to assess whether your improvement process is real.
The Corrective Action Process
What Clause 10.1 actually requires — and where most organisations fall short
What Genuine Improvement Looks Like
The difference between an ISMS that is improving and one that is static is honestly really visible to auditors and people like myself that are coaching people through 27001. I know you’d like to pretend otherwise, but it’s like my kids not actually tidying their rooms properly and trying to convince me they have.
An improving ISMS has policies that have been updated in the last 12 months — not because they expired, but because something changed, necessitating an update. It has a corrective action log where actions are closed, not perpetually “in progress.” It has metrics that show movement. It has management review minutes that reference specific decisions, not just a record of the meeting.
An auditor looking at an ISMS will ask to see your corrective actions from the previous period and what happened to them. They will ask what changed in your ISMS since the last audit and why. They will assess whether your management review outputs led to concrete outcomes.
The organisations that struggle with surveillance audits are almost always those whose evidence of improvement is thin — a handful of corrective actions, all minor, all marked “completed” with no verification evidence.
The organisations that impress auditors are those where the ISMS lead can walk through a clear narrative: here is what our metrics showed, here is what our audit found, here is what we decided to do, and here is the evidence that it worked.
Common Mistakes to Avoid
Treating corrective actions as paperwork.
Logging a nonconformity and writing a generic response to close it quickly is not an improvement — it is compliance theatre. Root cause analysis takes time, but it is the only way to prevent recurrence.
Disconnecting improvement from risk.
Improvement actions should be prioritised based on risk, not administrative convenience. A corrective action addressing a high-risk finding should take priority over minor procedure updates.
Setting objectives and forgetting them.
Information security objectives that are set at the start of the year and never reviewed serve no purpose. Build objective progress into your quarterly rhythm.
Waiting for audits to find problems.
If the only nonconformities you ever see are ones your certification body raises, your internal audit programme is not working. Internal audit should find more than external audit — that is the point.
Conflating documentation updates with improvement.
Rewriting a policy document is not, by itself, an improvement unless the rewrite addresses a genuine gap. Document updates are sometimes necessary, but they should be the outcome of an improvement need, not the improvement itself.
FAQs
How many corrective actions should we expect to raise each year?
There is no right number, but very few is usually a sign that your monitoring is not sensitive enough rather than a sign that your ISMS is perfect. A mature ISMS with active internal audits, regular metrics review, and a functioning incident process will typically generate a handful of minor corrective actions and one or two more significant ones per year. If you are raising zero, it is worth asking whether your audit and monitoring processes are looking hard enough.
Does every security incident need to become a corrective action?
Not every incident requires a formal corrective action, but every incident should be reviewed for improvement signals. A one-off human error with no systemic cause may not warrant a corrective action. A pattern of similar incidents, or a single incident that reveals a significant control gap, almost certainly does. The test is whether the incident reveals something about your ISMS that needs to change.
How do we demonstrate continual improvement to our certification body?
The clearest way is through documented evidence: a corrective action log with closed actions and verification evidence, management review minutes that show decisions were made and acted upon, updated risk assessments, and metrics that show trend data over time. Auditors are looking for a narrative — what was the input, what decision was made, what changed, and how do you know it worked.
Can we use customer feedback as an improvement input?
Yes, and it is often underused. Customer security questionnaires frequently surface gaps — requirements your clients expect that your ISMS does not yet formally address. Regulatory updates, certification body observations, and supply chain assessments are also legitimate inputs. Clause 4.2 (interested parties) exists partly to formalise this.
What is the difference between a corrective action and a preventive action?
ISO 27001:2022 no longer uses the term “preventive action” as a distinct requirement — the 2022 revision merged it into risk assessment and improvement planning. In practice, corrective actions address existing nonconformities, while proactive improvement actions address risks or gaps before they become nonconformities. Both belong in your improvement register, and both should be driven by evidence rather than instinct.
Related Guides
- What Do ISO 27001 Auditors Actually Look For?
- ISO 27001 Internal Audit: A Practical Guide
- ISO 27001 Management Review: What It Is and How to Run It
- ISO 27001 Risk Assessment: A Step-by-Step Guide
Written by Alan Parker, ISO 27001 Lead Auditor. Iseo Blue helps organisations achieve and maintain ISO 27001 certification.
