Measuring Your ISMS Maturity: From Beginner to Optimized

Why Maturity Matters

ISO 27001 is binary: You are certified or you are not. You have a policy or you do not. You have a risk register or you do not. This yes/no logic has its place for certification. But it does not answer the question that truly concerns you in daily operations: How well does my ISMS actually work?

Two companies can both be ISO 27001 certified and still be miles apart. One has an incident response process defined on paper that has never been tested. The other has a process that is exercised quarterly, improved after every incident, and supported by automated alerting. Both meet the ISO 27001 requirement for incident management. But their actual security level is fundamentally different.

A maturity model closes this gap. It assesses not only whether you have something, but how well it works, how consistently it is applied, and whether it is continuously improving.

The CMMI-Based Maturity Model for ISMS

The Capability Maturity Model Integration (CMMI) was originally developed for assessing software development processes. Its basic structure is well-suited for assessing ISMS processes because it is universal enough to be applied to different domains and simultaneously precise enough to derive concrete improvement targets.

The Five Maturity Levels

Level 1: Initial (Ad Hoc)

Description: Processes exist, but they are not documented, not standardized, and depend on individual people. If the employee who "always does it" is sick, it does not work.

Typical characteristics:

• Security measures are taken reactively when a problem occurs
• No or rudimentary documentation
• Success depends on individual competence and initiative
• No uniform processes across departments
• Knowledge resides in people's heads, not in documents

Example — Risk Management: Risks are discussed informally when someone notices a problem. There is no risk register. Risk assessments do not take place. Measures are decided ad hoc.

Example — Incident Response: When an incident occurs, whoever is available responds. There is no defined process, no escalation paths, and no documentation.

Level 2: Repeatable (Managed)

Description: Basic processes are defined and performed regularly. There are responsibilities and basic documentation. But processes are not standardized across all areas.

Typical characteristics:

• Core processes are documented and performed regularly
• Responsibilities are assigned
• Basic documentation exists (policies, procedures)
• Processes are performed consistently within a team, but differently between teams
• Reactive elements still outweigh proactive ones

Example — Risk Management: A risk register exists and is updated annually. The risk assessment follows a defined methodology. But measures tracking is irregular, and there is no reporting to executive management.

Example — Incident Response: An incident response plan exists on paper. Roles are defined. But the plan has never been tested, and during the last incident, nobody knew what to do anyway.

Level 3: Defined (Standardized)

Description: Processes are standardized organization-wide, documented, and applied consistently. There are defined training programs, regular reviews, and active management.

Typical characteristics:

• All ISMS processes are standardized and documented organization-wide
• Regular training for all participants
• Processes are actively managed and monitored
• Metrics are collected and reported
• Internal audits take place regularly and findings are addressed
• Management review is conducted and leads to actions
• Proactive and reactive elements are balanced

Example — Risk Management: The risk register is reviewed quarterly. Risk assessments follow a standardized methodology. Measures are tracked and progress is reported to executive management. New risks are actively identified.

Example — Incident Response: The incident response plan is tested annually (tabletop exercise). Incidents are documented and debriefed (lessons learned). Escalation paths work. Mean response time is measured.

This is the target level for most mid-market companies. Level 3 means your ISMS works, is consistently applied, and measurably improves. For ISO 27001 certification and NIS2 compliance, Level 3 is sufficient.

Level 4: Managed (Quantitative)

Description: Processes are managed quantitatively. Decisions are based on data, not on gut feeling. There are defined target values, statistical process control, and data-driven optimization.

Typical characteristics:

• Detailed metrics for all processes
• Target values and thresholds are defined
• Deviations are analyzed and root causes are addressed
• Decisions are based on quantitative analysis
• Benchmarking against industry values
• Predictive elements (trend analyses, risk forecasts)
• Automated data collection and reporting

Example — Risk Management: Risks are quantitatively assessed (monetary expected value). Risk appetite and risk tolerance are formally defined and adhered to. Risk trends are analyzed and feed into strategy.

Example — Incident Response: MTTD and MTTR are systematically measured and tracked against targets. Incident patterns are analyzed to identify recurring root causes. Measure effectiveness is quantitatively demonstrated.

Level 5: Optimized (Continuously Improving)

Description: The ISMS optimizes itself continuously and proactively. Innovation and adaptability are built into the processes. Improvements are systematically identified and implemented.

Typical characteristics:

• Continuous, systematic process improvement
• Proactive adaptation to new threats and technologies
• Lessons learned are used organization-wide
• Automation where sensible
• Security culture is anchored throughout the entire organization
• The ISMS drives business innovation rather than hindering it

Example — Risk Management: Risk management is integrated into all business processes. New projects, products, and partnerships are automatically subjected to a risk assessment. The risk model is regularly validated and improved based on new insights.

Example — Incident Response: Incidents are proactively prevented through threat intelligence and anomaly detection. Red team exercises test resilience. Automated playbooks accelerate response. Every incident leads to measurable improvements.

Level 5 is not a realistic target for most organizations. It describes a state typically achieved only by organizations whose core business is information security, or by organizations with very high protection requirements (military, intelligence agencies, critical infrastructure).

The 12 ISMS Domains

To assess the maturity of your ISMS, you break it down into domains and assess each domain individually. The result is not a single value but a profile that shows where you are strong and where improvement is needed.

Domain 1: Governance and Leadership

Assessment questions:

• Is the information security policy documented and approved by executive management?
• Are roles and responsibilities clearly defined?
• Does executive management actively support the ISMS (resources, participation in management review)?
• Is there regular reporting to executive management?

Domain 2: Risk Management

Assessment questions:

• Is there a documented risk management methodology?
• Are risks regularly identified, assessed, and treated?
• Is there a maintained risk register?
• Are measures tracked and their effectiveness verified?
• Is the organization's risk appetite defined?

Domain 3: Asset Management

Assessment questions:

• Is there a complete inventory of all IT and OT assets?
• Are responsibilities assigned for each asset?
• Are assets classified (criticality, protection requirements)?
• Are dependencies between assets documented?
• Is the inventory kept current?

Domain 4: Access Control

Assessment questions:

• Is there an access policy?
• Are access rights granted according to the least privilege principle?
• Are access rights regularly reviewed (access reviews)?
• Is MFA activated for critical systems and external access?
• Is there a process for onboarding/offboarding?

Domain 5: Cryptography and Data Protection

Assessment questions:

• Are encryption standards defined (data in transit, data at rest)?
• Are encryption standards being followed?
• Is there key management?
• Are personal data protected in accordance with DSGVO (GDPR)?

Domain 6: Physical Security

Assessment questions:

• Are security zones defined (server room, production hall, office)?
• Are there access controls to critical areas?
• Are access rights regularly reviewed?
• Are protection mechanisms against environmental influences in place (fire protection, UPS, air conditioning)?

Domain 7: Operations Security

Assessment questions:

• Are there documented operating procedures for critical systems?
• Is a change management process defined and followed?
• Are backups regularly created and tested?
• Is there patch management (IT and OT)?
• Are logs collected and monitored?

Domain 8: Network Security

Assessment questions:

• Is the network segmented?
• Is there a firewall architecture with documented rules?
• Are network changes managed through a change management process?
• Is there network monitoring?
• Are IT and OT networks separated?

Domain 9: Incident Management

Assessment questions:

• Is there an incident response plan?
• Are escalation paths defined?
• Are incidents documented and debriefed (lessons learned)?
• Is the plan regularly tested (exercises, simulations)?
• Are incident metrics collected (MTTD, MTTR)?

Domain 10: Business Continuity

Assessment questions:

• Is there a business continuity plan?
• Have critical business processes been identified (BIA)?
• Are there recovery plans for critical systems?
• Are the plans regularly tested?
• Are recovery time objectives (RTO/RPO) defined and achievable?

Domain 11: Compliance and Audit

Assessment questions:

• Are the relevant regulatory requirements identified (NIS2, GDPR, industry-specific)?
• Are internal audits conducted regularly?
• Are audit findings tracked and resolved?
• Is there a management review?
• Is compliance regularly verified?

Domain 12: Awareness and Training

Assessment questions:

• Is there a security awareness program?
• Are all employees regularly trained?
• Are there role-specific training programs (admins, developers, executive management)?
• Is the effectiveness of training measured (e.g., phishing simulation)?
• Is there a security culture that goes beyond mandatory training?

Assessment Methodology

Assessment Scale per Domain

Assess each domain on the five-level scale (1 = Initial to 5 = Optimized). Use the maturity level descriptions as reference and address the specific assessment questions for each domain.

The assessment should be evidence-based. Not "I think we're at 3," but: "We have a documented process (that points to 3), but it was only reviewed once last year instead of quarterly (that points more to 2). Assessment: 2.5, rounded to 2."

Assessment Matrix

Create an assessment matrix that defines concrete criteria for each domain and each maturity level. An excerpt as an example for the Risk Management domain:

Execution

Who assesses? The information security officer leads the assessment, but they should not assess alone. Involve IT management, executive management, and if possible an external consultant. Different perspectives prevent operational blindness.

How often? Once annually as a full assessment. The results feed into the management review. A quarterly quick-check of the most critical domains can be useful.

Documentation: For each domain, document the assessment, the justification (what evidence supports the assessment), the target maturity level, and the measures to achieve the target maturity level.

Interpreting Results

The Maturity Profile

The results of all 12 domains produce a profile that shows at a glance where your ISMS is strong and where it is weak. A typical profile of a mid-market company in its second year after ISMS implementation looks roughly like this:

This profile shows: Governance, access control, physical security, and awareness are at target level. The biggest gaps are in business continuity (Level 1), risk management, and operations security (Level 2).

Average Maturity Level

The average across all domains gives a rough overall value. In the example above: 2.25. But the average is less informative than the profile because it conceals weaknesses. An average of 3.0 can mean all domains are at 3 (good), or that half are at 4 and the other half at 2 (problematic). Use the average only as a rough orientation and focus on the individual domains.

Prioritizing Improvements

You cannot improve all domains simultaneously. Prioritize based on two criteria:

Criticality: Which domain has the greatest influence on your actual security level? Incident management at Level 1 is more critical than cryptography at Level 2, because a missing incident response process leaves you unable to act in an emergency.

Effort: Which improvement is achievable with reasonable effort? An improvement from Level 1 to Level 2 (introducing basic processes) is often faster to achieve than an improvement from Level 3 to Level 4 (introducing quantitative management).

The combination produces a matrix: High criticality and low effort = address immediately. High criticality and high effort = plan strategically. Low criticality = lower priority.

From Level to Level: The Improvement Roadmap

From Level 1 to Level 2: Establishing the Basics

Timeframe: 3-6 months per domain

Key measures:

• Document processes (even if they are simple)
• Assign responsibilities
• Create basic templates and forms
• Establish regular execution (calendar entries, reminders)
• Collect first metrics (even if still manually)

Typical effort: Low to medium. Primarily documentation work and organizational effort.

From Level 2 to Level 3: Standardize and Manage

Timeframe: 6-12 months per domain

Key measures:

• Unify processes organization-wide
• Conduct training for all participants
• Introduce regular reviews (audits, reviews)
• Systematically collect and report metrics
• Establish feedback loops (lessons learned, continuous improvement)
• Conduct management review with concrete results

Typical effort: Medium. Requires investment in training, tools, and time for standardization.

From Level 3 to Level 4: Data-Driven Management

Timeframe: 12-24 months per domain

Key measures:

• Define detailed KPIs with target values and thresholds
• Introduce automated data collection and reporting
• Statistical analysis of trends and deviations
• Benchmarking against industry values
• Introduce predictive elements (trend analyses, risk forecasts)
• Dashboard-based management

Typical effort: High. Requires investment in automation, data analysis, and specialized tools.

Maturity and Compliance

ISO 27001

For a successful ISO 27001 certification, you need at least Level 2 in most domains, ideally Level 3. A certification auditor will not expect every domain at Level 3, but they will expect that core processes (risk management, incident management, internal audit, management review) function at least at Level 2.

NIS2

NIS2 requires effective risk management. "Effective" means in practice at least Level 2 in all security-relevant domains and Level 3 in core domains (risk management, incident management, business continuity). The personal liability of executive management increases the pressure to demonstrate a functioning system.

Auditor Perspective

Auditors implicitly use maturity concepts, even if they do not call it that. When an auditor says "the process is defined, but is it actually being followed?", they are asking about maturity. If you proactively present a maturity assessment and show that you know your weaknesses and have an improvement plan, most auditors will view this positively.

Annual Maturity Assessment

The maturity assessment should be a fixed component of your ISMS cycle:

Q4 of the year: Conduct the maturity assessment. Document results. Compare with the previous year. In ISMS Lite, the maturity level can be captured across all domains, visualized, and compared across years.

Management review (Q1 of the following year): Present maturity results. Set target maturity levels for the new year. Plan resources and budget for improvement measures.

During the year: Implement measures. Quarterly quick-check of the most critical domains.

Q4 of the following year: Reassessment. Has the maturity level improved as planned? If not: Why not? What needs to be adjusted?

This cycle gives you a clear structure for the continuous improvement of your ISMS and corresponds to the PDCA principle. It makes progress visible (for you as well as for executive management and auditors) and provides an objective basis for investment decisions.

Further Reading

• ISMS Metrics: The 15 KPIs Your Management Review Needs
• Building a Security Dashboard: Which Metrics Belong on the Screen
• Building an ISMS: The Complete Guide for Companies with 50 to 500 Employees
• Defining Your ISMS Scope: Getting the Scope Right