Use Maturity Models to Improve an ISO 27001 ISMS

A maturity model can help an organisation describe how reliably an information security process is defined, governed and improved. It cannot decide ISO 27001 conformity, replace risk assessment or prove that controls are effective.

Used carefully, maturity assessment turns vague ambitions such as “improve access management” into a current-state finding, a target capability, accountable actions and evidence of progress. Used poorly, it produces attractive scores that hide material control failure.

This guide provides an AuditPrepared method for applying maturity models to an ISO/IEC 27001 information security management system without confusing different assurance questions.

Separate four questions

Before scoring anything, distinguish:

1. Conformity: Are applicable ISO 27001 requirements fulfilled?
2. Control effectiveness: Does the control achieve its intended outcome under relevant conditions?
3. Risk: Is residual risk understood and within approved criteria?
4. Maturity: How consistently and sustainably is the process performed, managed and improved?

A process can be documented and repeatable yet ineffective against a changed threat. It can also operate effectively through expert effort while remaining fragile because knowledge is not shared and monitoring is weak.

Certification audits evaluate conformity within a defined scope. A maturity score is an internal management instrument unless a separate assurance arrangement says otherwise.

The post-certification maintenance guide explains why certification should begin, not end, the operating cycle.

Define the assessment object

Do not assign one maturity number to “cybersecurity.” Choose assessable processes with clear outcomes, such as:

• identity lifecycle management;
• vulnerability management;
• incident response;
• supplier assurance;
• backup and restoration;
• information classification;
• security awareness;
• secure development;
• risk treatment; or
• internal audit and corrective action.

For each process, define scope, owner, customers, inputs, outputs, dependencies and expected outcome. A score without a defined object cannot be compared across time.

Use levels with observable criteria

A five-level model can be practical if every level has evidence-based criteria. The names are less important than the distinctions.

Level	Working description	Typical evidence
1 — Reactive	Activity depends on individual response and is inconsistent	Isolated tickets, expert knowledge, irregular records
2 — Repeatable	Basic steps recur, but ownership and coverage vary	Local procedures, recurring activity, incomplete populations
3 — Defined	Process, roles, scope and records are standardised	Approved process, trained owners, complete workflow
4 — Measured	Performance and control outcomes are monitored using reliable data	Defined measures, thresholds, trend analysis, response records
5 — Adaptive	Learning, prediction and structured improvement change the process	Proactive changes, validated benefits, cross-process learning

These are AuditPrepared working levels, not ISO wording and not a claim that ISO 27001 requires the highest level for every process. The target should reflect risk, obligations, resources and business need.

Do not borrow level names from another framework while changing their meaning. NIST states that Cybersecurity Framework implementation Tiers are not intended to be maturity levels. If an organisation uses CSF Tiers, it should follow NIST’s purpose and guidance rather than relabel them.

Set evidence rules before scoring

For every process and level, specify what assessors must verify. Use several evidence types:

• design: approved process, roles, criteria and technical configuration;
• coverage: systems, users, suppliers or transactions included;
• operation: records showing repeated execution;
• performance: measures, thresholds and response;
• outcomes: reduced exposure, timely recovery or fewer repeat failures;
• governance: risk decisions, escalation and management review; and
• improvement: completed actions with verified effect.

A policy alone should not support a high score. Nor should one successful transaction prove population-wide operation.

Define the scoring period and treatment of gaps. For example, a process may meet most level-three criteria but remain at level two because high-risk business units are excluded. Avoid averaging away a critical weakness.

Choose targets based on risk

Not every process needs the same target. A small internal knowledge site may tolerate a repeatable access review. Privileged access to a critical payment platform may require defined, measured and rapidly adaptive operation.

Set the target by considering:

• information and service criticality;
• threat and vulnerability exposure;
• legal and contractual duties;
• control failure history;
• process complexity;
• reliance on key people;
• supplier concentration;
• pace of technology change; and
• cost and feasibility.

Record why the target is appropriate. “All processes must reach level five” encourages inflated scoring and waste. A lower approved target can be reasonable where risk is low and other safeguards are effective.

Use the risk score calculator to inform prioritisation, while keeping maturity and risk as distinct records.

Conduct the assessment

A credible assessment uses more than an owner interview.

1. Confirm the process boundary and population.
2. Review documented design and assigned accountability.
3. Walk through one recent transaction from start to finish.
4. Sample records across the assessment period.
5. Inspect technical settings where relevant.
6. Compare measures with source data.
7. Review incidents, exceptions and failed cases.
8. Test whether corrective actions changed operation.
9. record criteria met, criteria missed and evidence references.
10. obtain owner confirmation without allowing unsupported self-scoring.

Independent challenge improves credibility. The assessor need not always be internal audit, but should have enough competence and distance to question optimistic claims.

Convert gaps into an improvement backlog

A maturity assessment has value only when it changes priorities. Each gap should identify:

• the unmet criterion;
• risk or business consequence;
• proposed outcome;
• responsible owner;
• dependencies and resources;
• due date;
• success measure; and
• verification method.

Prioritise improvements that remove dangerous failure modes, improve evidence reliability or enable several processes. An authoritative asset inventory, for example, may improve vulnerability, access, backup and supplier processes at once.

The ISO 27001 KPI guide explains how to design measures that support decisions rather than reward activity counts.

Integrate with the ISMS cycle

Maturity results can inform risk assessment, objectives, resource planning, operational changes, internal audit and management review. They should not become a separate improvement programme disconnected from ISO 27001.

Use management review to consider:

• processes below approved targets;
• risks created by capability gaps;
• trends and stalled improvement;
• inconsistent scoring between units;
• resources needed;
• incidents that challenge the score; and
• whether the model remains useful.

The management review evidence guide shows how to record decisions and follow-through.

Audit the maturity model itself

Internal auditors should test whether:

• process definitions are stable and clear;
• criteria are observable;
• assessors apply them consistently;
• evidence supports scores;
• scope gaps are disclosed;
• risk influences targets;
• actions address root causes;
• reported progress matches source data; and
• score changes reflect operating change, not altered wording.

Pass, partial and fail examples

Pass: Criteria are defined before assessment, evidence supports each rating, targets reflect risk, gaps become owned actions and management evaluates progress and outcomes.

Partial: Processes are scored regularly, but evidence is inconsistent, targets are arbitrary or improvement completion is accepted without effectiveness review.

Fail: Owners choose unsupported scores, averages conceal critical gaps, maturity is presented as certification evidence, or high scores override known incidents and risk.

Improvement is the outcome, not the number

The official ISO 27001 overview describes establishing, implementing, maintaining and continually improving an ISMS. A maturity model can support that cycle by making capability gaps visible and priorities comparable.

The most useful result is not a higher score. It is a more reliable process, a clearer risk decision and evidence that the change produced the intended security outcome. Use the ISO 27001 readiness checker for a separate preliminary readiness baseline, and keep its indicative result distinct from a maturity assessment or audit conclusion.