Information Security Management
ISO 27001 Clause 10: Improvement
Clause 10 of ISO 27001 is the final clause, focusing on how you handle problems and drive continuous improvement in the ISMS.
Even with the best planning and checking, there will be times when you need to correct issues (nonconformities) and opportunities to improve the ISMS (continual improvement).
Explore Each ISO 27001 Clause in More Detail by Selecting One to View
Table of Contents
My 3-minute summary video of ISO 27001 Clause 10
Clause 10 — Improvement
The ACT phase of the PDCA cycle — fixing what goes wrong and driving continual improvement
The organisation must continually improve the suitability, adequacy, and effectiveness of the ISMS. This is not a one-time activity — it is an ongoing obligation to use the outputs from Clause 9 (monitoring, audits, management review) to make the ISMS better over time. Clause 10.1 does not prescribe how improvement happens; it requires that it does, and that the evidence supports it.
Clause 10.1 – Continual Improvement
ISO 27001 Clause 10.1 is a general requirement that you continually improve the ISMS’s suitability, adequacy, and effectiveness. This is somewhat abstract – it doesn’t specify how, just that you should always be looking to enhance the ISMS.
In practice, continual improvement can be achieved by:
- Addressing any findings from audits or reviews (this overlaps with 10.2 since those are nonconformities or at least opportunities).
- Enhancing controls proactively: If you find a new technology that could reduce risk, you implement it even if it is not required by a specific incident.
- Streamlining ISMS processes: making risk assessment easier, or awareness training more engaging, etc.
- Benchmarking and adopting best practices: You might have seen a neighbouring company’s ISMS and had ideas for improving yours.
- Employee suggestions: Perhaps users suggest a better way to enforce a policy—you consider and implement it if it is beneficial.
A simple way to show continual improvement is through your management review action items and subsequent completion of them.
Also, documenting the version history can show that they were updated to be better.
Each cycle of PDCA (Plan-Do-Check-Act) inherently implies improvement; Plan your improvement, Do it, Check how it went, Act upon any feedback. Simple.
Auditors will look for an improvement mindset. They might ask, “How do you drive continual improvement in your ISMS?” and expect answers like “We use findings from audits and incidents to make changes; plus, annually, we set new objectives or raise the bar.”
Clause 10.1 itself might not generate a specific document, but improvement actions are documented via Clause 10.2 or management review outputs.
Clause 10.2 – Nonconformity and Corrective Action
Clause 10.2 is very specific about handling nonconformities (including incidents, audit findings, and failures to meet requirements) and taking corrective actions. It mirrors the corrective action process outlined in standards such as ISO 9001.
The Process
The steps are:
Identify & Respond
React to the nonconformity, take action to control and correct it, and deal with the consequences.
In information security, a “nonconformity” could be a security incident (e.g., a breach of a control) or failure to follow a procedure (e.g., backups weren’t done).
First, you fix the immediate problem (contain the incident, get the backups running, etc.) – that’s the “control and correct” part.
Also, mitigate any consequences (e.g., data leaked? Notify as required, recover data, etc.)
Evaluate the need for action to eliminate causes
We should investigate the cause of the nonconformity so it doesn’t recur. This is the root cause analysis. Ask why this happened.
For example, if an employee clicked a phishing email (incident) – cause might be insufficient awareness or a missing email filter. Or if an internal audit found “no risk assessment was done for a new system” – cause might be lack of a process to trigger risk assessments on new projects.
Determine any necessary corrective actions.
Work out a plan of action to plug that root cause: who, what, when.
Implement the actions
The corrective action should be implemented and its effectiveness reviewed.
So if you decide the “root cause of phishing click is lack of training,” an action could be to provide targeted phishing training or implement simulated phishing tests. After implementing, you might later check “did clicks reduce?” to see if it is effective.
Review the impact
Keep track of the corrective action and its performance. Is it having the desired effect?
Update the nonconformities
This could mean updating procedures, modifying risk assessments, and adding controls (Annex A) – whatever is needed to prevent this issue in the future.
Maintain a log of any nonconformities and any actions taken.
ISO 27001 requires you to have a formal process for handling corrective actions. Usually, companies use a Corrective Action Plan or a Corrective Action Log. Each nonconformity (be it from an internal/external audit or an incident) is logged with details:
- Description of nonconformity,
- Date found,
- Owner,
- Root cause analysis summary,
- Corrective action planned,
- Target date,
- Status,
- Close date and verification of effectiveness.
Some treat incidents and audit findings separately (with incident reports), but it’s better to unify tracking because both require corrective actions.
Nonconformity in ISO terms is broad: it can include failing to meet an ISO requirement or an ISMS requirement. A security incident often indicates a non-fulfilment (like “policy says no tailgating, but tailgating happened” is nonconformance to policy).
So yes, treat incidents as nonconformities for ISO’s corrective action tracking (in addition to your immediate incident response).
Outputs
Corrective Action Records
Document each nonconformity and how it was resolved. ISO 27001 requires the recording of corrective actions. This could be completed with corrective action forms, an Excel log, or entries in a ticket system.
Updated procedures or policies
If a corrective action required changing documentation or implementing new controls, those updated documents are outputs (with new version numbers).
Preventive changes
Though ISO no longer has a separate “preventive action” clause (since the whole risk management is preventive), your corrective actions often double as preventive for the future.
If no nonconformities occurred in a period, there might be no records — but that’s unlikely (there’s always something to improve, even if it’s small).
Auditors will definitely examine how you handle corrective actions, especially those arising from:
- Internal audits, previous external audits: They will follow up on past findings to ensure you addressed them.
- Incidents: They will see if you documented what happened and what you did to prevent recurrence.
- Management review actions: If any actions were set in management review, they are essentially improvements—they’ll check those, too, possibly under Clause 10 or Clause 9.
Corrections vs Corrective Actions
I think it’s worth pausing on the terminology because it’s a common point of confusion at audit.
A correction fixes the immediate problem – resetting a compromised password, ending a session, restoring a failed backup.
A corrective action addresses the root cause so the same thing doesn’t happen again – rolling out MFA across the affected system, because the underlying issue is single-factor authentication, not this one user.
Most Clause 10.2 findings in audits are actually about corrections being mistaken for corrective actions. The action is taken, the ticket is closed, but the root cause hasn’t been touched – so the same nonconformity reappears six months later.
Grab all the documents you need for Clause 10 in my ISO 27001 Information Security Toolkit below.
ISO 27001 Full Document Toolkit
Every document your auditor
expects to see.
130+ Word & Excel templates, ready to edit. Policies, risk register, Statement of Applicability, audit pack, staff communications — all updated for ISO 27001:2022.
130 templates
Instant download
Written by practising consultant
ISO 27001:2022
Documentation and Outputs for Clause 10
Clause 10 — What Evidence Is Required?
Documents and records an auditor will expect to see at certification and surveillance audits
Clause 10.1 does not explicitly require a named document, but auditors will look for evidence that improvement is genuinely happening — not just being stated. This evidence typically lives in other records: management review minutes noting decisions to improve a process, updated policies or procedures reflecting lessons learned, or a register of improvement initiatives with outcomes recorded.
A record of each nonconformity that has occurred — what it was, when it was identified, and where it came from (internal audit, incident, management review, etc.). The standard explicitly requires this as documented information. A simple log or register is sufficient; what matters is that nonconformities are captured consistently, not just the significant ones.
For each nonconformity, documented evidence of: the actions taken to react and contain the problem; the root cause evaluation; the corrective action implemented; and the result of reviewing whether the action was effective. This is the most scrutinised Clause 10 document at audit — it must show the full cycle from problem identification to verified resolution, not just that an action was logged and closed.
A documented process describing how nonconformities are identified, recorded, assessed for root cause, treated, and closed out. Not explicitly required by the standard, but auditors at certification stage will typically expect to see that the organisation has a defined process — not just an informal expectation that someone will deal with problems when they arise.
A running log of all open and closed corrective actions showing owner, due date, current status, and outcome. Satisfies the mandatory record-keeping requirement while also giving auditors a single view of how well the organisation is managing its nonconformities over time. Overdue actions with no documented reason or revised date are a common surveillance audit finding.
What Auditors Look For in ISO 27001 Clause 10
Clause 10 — What Auditors Look For
Four areas where auditors test whether improvement is real — not just recorded
Example:
During an audit, an auditor might find that a company experienced an unexpected email outage that wasn’t a direct security incident but affected the availability of information (relevant to ISMS). The auditor could then ask how they handled it.
The company could provide an incident report: the root cause was a misconfiguration; corrective action was taken (fix config); and they updated their change management process to include a peer review for email server changes (improvement). The auditor would give this clearance because, even though it wasn’t a required ISO control, the company demonstrated the spirit of continual improvement by learning from an IT incident to strengthen the ISMS (availability control).
Another example:
If the internal audit found that some employees weren’t aware of the clean desk policy (a minor issue). A corrective action should be something like sending out a reminder and including it in onboarding training. By the time of the external audit, the auditor would see that training had taken place, might even observe desks, and would indeed find a much cleaner environment. This closes the NC/OFI on a small improvement. The auditor would then likely note it as a positive outcome of your corrective action process.
Common Clause 10 pitfalls I see in SME audits
Clause 10 looks straightforward on paper – find problems, fix them, learn from them – but in practice it’s where many SME ISMSs quietly go off the rails. These are the four patterns I see most often when I’m doing internal audits or supporting clients through their certification audits.
The recurring nonconformity
The clearest sign that Clause 10.2 isn’t working is the same finding turning up year after year. Staff keep clicking phishing emails, so you run more training. Backups keep failing, so you remind the IT team. Access reviews keep finding stale accounts, so you tell HR to be quicker with leavers. Each individual “fix” is reasonable, but if the same finding lands on the corrective action log three years running, the corrective action isn’t actually corrective – it’s just a recurring correction. Auditors notice this immediately. The fix is usually one level deeper than where you’ve been looking: not more training but better email filtering and MFA, not reminders but an automated leaver workflow.
The empty corrective action log
“We had no nonconformities this year” is one of the few statements that will reliably make a certification auditor more suspicious, not less. A working ISMS surfaces small issues constantly: missing evidence, near-misses, process drift, staff confusion. A log that records none of this isn’t proof of perfection – it’s usually proof that nobody is looking, or that minor issues are being quietly resolved without being recorded. It’s better to log five small things and close them all than to log nothing.
The closed-but-unverified action
A corrective action isn’t closed when the fix is implemented; it’s closed when the fix has been verified to actually work. This is the clause requirement that gets dropped most often. A typical pattern: the audit finds that staff aren’t completing security training, the action is “send reminder emails”, and the action is closed when the emails go out. But did completion rates actually improve? If you can’t answer that question with evidence, the action wasn’t verified, and the auditor will reopen it.
The 10.1 drought
Clause 10.1 – continual improvement – is the easiest sub-clause to forget because nothing is broken. There are no incidents to react to, no audit findings demanding attention. So nothing happens, and a year later the management review minutes look identical to last year’s. Auditors read this as a static ISMS. A simple fix is to set one or two genuine improvement objectives each year that aren’t tied to a specific finding – something like “reduce mean time to detect security incidents from 4 hours to 2” or “raise phishing test reporting rate from 60% to 80%”. These give you something to point at when the auditor asks “how have you improved this year?”
The 5 ‘Whys?’ Root Cause Technique
Root cause analysis can quietly become theatre – five lines of “why?” written after the corrective action has already been decided, working backwards to justify it. ~
The point of 5 Whys is to keep going beyond the first obvious answer. The first “why” usually surfaces the symptom; the third or fourth tends to surface the actual control gap; only the last one is genuinely systemic.
Here’s a realistic SME example.
💡 Worked 5 Whys example: a missed offboarding
Finding: A leaver still had access to the production environment three weeks after leaving the business.
- Why did the ex-employee still have access? Their accounts weren’t disabled when they left.
- Why weren’t they disabled? IT didn’t know the person had left.
- Why didn’t IT know? HR didn’t notify IT – the leaver was processed in the HR system but no ticket was raised.
- Why didn’t HR raise a ticket? There’s no defined process; HR notifies IT informally over email and the email was missed.
- Why is there no defined process? Root cause – the joiners-movers-leavers process was never documented or owned after the company doubled in headcount.
The fix here is not “remind HR to email IT” – that’s still a correction, and it will fail again the next time HR has a busy week. The corrective action is to define and document the joiners-movers-leavers process with a named owner, build the HR-to-IT handoff into the HR system as a required step, and review for any other ex-employees who may still have access. The first fix solves this leaver. The corrective action solves all future leavers.
🔗 How Clause 9 and Clause 10 connect
Clause 10 doesn’t operate in isolation. Everything in this clause is driven by what comes out of Clause 9 – your monitoring data, your internal audit findings, and your management review decisions. If Clause 9 isn’t producing anything, Clause 10 will be empty by definition.
The handoff works like this:
Monitoring and metrics (9.1) surface trends and anomalies that become improvement opportunities under 10.1, or nonconformities under 10.2 if a control is failing.
Internal audit findings (9.2) are the most direct source of nonconformities – every internal audit finding should land in the corrective action register.
Management review (9.3) sets improvement objectives and approves resources, which become the proactive improvement work under 10.1.
If your corrective action register is thin, the issue is rarely Clause 10 itself – it’s usually that Clause 9 isn’t generating enough signal. If you’re not finding things, you can’t fix them.
ISO 27001 Clause 10 FAQs
Do we need a separate document for ISO 27001 Clause 10.1 (Continual Improvement)?
No, Clause 10.1 doesn’t require a standalone document. What’s important is that you can show improvement is happening over time. This might be captured through updated procedures, management review outputs, or project plans for enhancements. If you do keep a “Continual Improvement Register” – great! But it’s not mandatory.
What counts as a nonconformity under Clause 10.2?
A nonconformity is any failure to meet ISO 27001 requirements, your internal policies, or procedures. It could be a missed backup, a breach of physical access controls, a policy violation, or even an unclear process. Security incidents often highlight nonconformities, but audit findings or staff feedback can uncover them too.
Are incidents and nonconformities the same thing?
Not exactly – but they often overlap. An incident is an event that compromises information security. A nonconformity is a failure to meet a requirement. Many incidents reveal nonconformities and should therefore trigger corrective actions. For ISO purposes, treat incidents as nonconformities unless it’s clear they didn’t breach any requirement.
Do I need to document root cause analysis?
Yes – ISO 27001 clause 10 expects you to evaluate the cause of each nonconformity before deciding on corrective action. The root cause doesn’t need to be pages long – a short summary will do – but it should show you’ve thought beyond the surface issue. Using techniques like “5 Whys” or “fishbone” diagrams can help, especially for recurring issues.
Can I track corrective actions in a spreadsheet?
Absolutely. A well-structured Excel log is fine – as long as it’s controlled, updated, and includes the required fields: issue, root cause, corrective action, owner, due date, status, and verification of effectiveness. Some organisations use helpdesk/ticket systems or Confluence pages – format doesn’t matter, process does.
What if we had no nonconformities this year – is that a problem?
It’s not automatically a red flag, but auditors might raise an eyebrow. Even well-run ISMSs usually have at least minor issues or improvement opportunities. If your records are completely empty, it could suggest the system isn’t being critically assessed. It’s better to log and fix small things than pretend everything’s perfect.
How do I show continual improvement to an auditor?
Auditors will look for evidence of change and maturity over time. Examples include:
Updated risk treatments or SoA changes
Enhanced training or awareness programmes
New controls implemented (even if not triggered by an incident)
Lessons learned applied after incidents or audits
Objectives set and reviewed as part of Clause 6.2
Version control, meeting minutes, and your corrective action log can all help demonstrate this.
Does Clause 10 require a “Corrective Action Procedure”?
Not explicitly – but having one helps ensure consistency. Many organisations document how they raise, analyse, implement, and verify corrective actions. If you don’t have a procedure, be ready to explain your process clearly during an audit and show that it’s consistently followed.
Who should own corrective actions?
Each action should have a clear owner – usually someone who understands the issue and has the authority to fix it. The ISMS lead or security team might oversee the process, but actions could be assigned across departments (IT, HR, facilities, etc.). Ownership and accountability are key to driving completion.
Can we treat customer complaints as nonconformities?
Ooo… It overlaps with ISO 9001. Yes, if the complaint points to a failure to meet an internal requirement or control. For example, if a customer reports receiving another client’s data, that’s not just a complaint – it’s a security incident and a nonconformity that must be investigated and corrected.
Further Reading
Get the ISO 27001 Standard
Includes all the mandatory document templates — free, no commitment
Author Background
This article was written by Alan Parker, an ISO 27001 consultant and founder of Iseo Blue Limited. He helps UK SMEs achieve certification in 90 days or less, often without a dedicated security team or a large budget.
With over 30 years in IT governance and information security, Alan works with software companies, IT service providers, managed service providers, and professional services firms across the UK, Europe, and internationally.
Qualifications: Certified ISO 27001 Lead Auditor (ANAB-accredited certification),
ITIL v3 Expert, ITIL v4 Bridge, PRINCE2 Practitioner. Named IT Project Expert of the Year (2024, UK). Alan writes in plain English for busy teams who need to get things done.
Connect on LinkedIn or Bluesky, or explore his free ISO 27001 tools and templates at iseoblue.com. B.Sc (Hons) Information Systems, CISMP certified.
