NIS2 Cybersecurity Maturity Assessment: A 4-Step Guide

A NIS2 cybersecurity maturity assessment is a structured evaluation of how effectively an organisation implements and operates the risk management measures required under Article 21 of the NIS2 Directive. It asks whether a control is consistently applied, clearly owned, regularly tested, and capable of producing evidence a competent authority would accept, well beyond a simple yes-or-no on whether it exists.

ENISA, the EU Agency for Cybersecurity, defines maturity in similar terms: how effectively and consistently a sector manages cybersecurity risks and capabilities over time, in its NIS360 report. The same principle applies at the level of a single organisation: maturity is a measure of operational reliability, built from evidence gathered over time.

The assessment baseline starts with Article 21 itself. Commission Implementing Regulation (EU) 2024/2690 adds binding technical detail for a defined set of digital infrastructure and service providers, covering DNS providers, cloud and data centre services, managed service and security providers, and trust services, among others. For the wider population of NIS2 entities, ENISA's Technical Implementation Guidance provides the equivalent practical detail on a non-binding basis, and both are worth reading alongside Article 21 when you set your scoring criteria.

A maturity assessment sits above the compliance register, showing whether that register reflects what's actually happening day to day.

Article 21 sets out ten categories of cybersecurity risk management measures, spanning policies on risk analysis, incident handling, business continuity, supply chain security, and access control, through to encryption, HR security, and multi-factor authentication. A yes-or-no checklist confirms each category is addressed. That's the extent of what it can tell you.

The Implementing Regulation is explicit that measures must be appropriate and proportionate, and that entities must monitor and review their effectiveness. A policy document shows intent. An operational record shows the control actually working.

The real risk is false confidence. A team that has ticked every box on a NIS2 checklist can genuinely believe the programme is ready, right up until an incident response plan that was never tested, a supplier assessment that's overdue, or an access review completed once and never repeated proves otherwise. The programme looked ready on paper, and the gap only showed once something was actually tested.

1. Consistency: Is the control applied every time, across every system and site, or only in the areas that were reviewed?
2. Ownership: Is there a named person accountable for the control, with the authority and resource to maintain it?
3. Evidence quality: Are records current, complete, and approved, in a form that would satisfy an auditor who wasn't in the room?
4. Systemic gaps: Do weaknesses cluster around a particular domain, team, or supplier relationship in a way that creates material exposure?

ENISA's NIS360 report tracks exactly this gap at a sector level. Its current risk zone, where criticality outpaces maturity, includes health, railway, maritime, ICT management services, space, public administrations, and drinking and waste water: sectors where documented measures haven’t yet translated into operational capability, precisely the gap a maturity assessment is built to expose.

Article 21 reads as a list of obligations. Running an assessment straight against the raw list keeps you at compliance-register depth. Grouping the ten measures into domains that mirror how cybersecurity actually operates inside a business makes scoring manageable and remediation easier to prioritise.

1. Governance and risk management policy (Article 21(2)(a)): Assess whether a board-approved cybersecurity risk framework exists, is reviewed on a defined cycle, and sets a communicated risk appetite.
2. Incident handling (Article 21(2)(b)): Confirm the incident response plan is tested, roles and escalation paths are defined, and notification timelines to competent authorities are rehearsed.
3. Business continuity and crisis management (Article 21(2)(c)): Check that recovery time objectives are defined and tested against a real scenario.
4. Supply chain and third-party security (Article 21(2)(d)): Score the completeness of the supplier inventory and whether contractual security requirements are enforced and reviewed.
5. Secure acquisition, development, and maintenance (Article 21(2)(e)): Assess whether secure development standards are applied and vulnerability management covers the full asset estate.
6. Effectiveness testing and cyber hygiene (Article 21(2)(f) and (g)): Look for penetration testing, vulnerability scanning, phishing simulation, and training completion records.
7. Cryptography and encryption (Article 21(2)(h)): Confirm an encryption policy covers data at rest and in transit, with documented key management.
8. HR security and access control (Article 21(2)(i)): Review joiner-mover-leaver processes, privileged access governance, and whether access reviews run on schedule.
9. MFA and secure communications (Article 21(2)(j)): Score coverage across systems, since partial MFA deployment is a common finding that carries disproportionate risk.

Use one scoring model across every domain. Inconsistent criteria between teams or business units is the most common reason an assessment can't be compared over time.

Step 1: Define Scope, Entity Type, and Owners

Before scoring anything, settle three questions. What's in scope: the whole organisation, a regulated service, or a specific business unit? Scope too narrow and you miss material exposure; scope too broad and the assessment becomes unmanageable.

Are you essential or important? Annex I lists sectors of high criticality (energy, transport, banking, health, water, digital infrastructure, and public administration among them) and Annex II lists other critical sectors, but the annex alone doesn't decide your status. Size and specific sector criteria determine whether you land as essential or important, so check the classification rules for your sector directly.

If you're a UK organisation, NIS2 doesn't apply to you directly since the UK left the EU, though an EU subsidiary or a contract with an EU customer can still pull you into scope. The UK's own Cyber Security and Resilience Bill is moving through Parliament along similar lines, so it's worth tracking both where relevant.

1. Compliance/GRC: overall coordination, scoring consistency, and output reporting.
2. Information security/CISO function: technical domain scoring and evidence collection.
3. IT operations: system and infrastructure evidence, backup and recovery records.
4. Procurement/vendor management: supply chain security evidence.
5. HR: joiner-mover-leaver records and training completion data.
6. Business continuity: continuity plan testing records and crisis management documentation.

Document scope and ownership in writing before the assessment begins. It's the first artefact in your evidence pack.

Step 2: Build a Maturity Scale and Score Four Dimensions

A maturity scale gives every assessor the same language for the same observation. Without one, a person's ‘partially implemented’ becomes someone else's ‘mostly in place,’ and the scores stop meaning anything once you compare results across teams or over time.

Score each domain across four dimensions instead of a single overall rating, since a strong policy can mask weak execution. Design asks whether the control addresses the Article 21 requirement appropriately. Implementation asks whether it's applied consistently across scope. Evidence asks whether records are current, complete, and independently verifiable, and review asks whether a defined cycle exists and has actually been followed.

The domain's overall score is the lowest of the four dimensions. No averaging. A control that's well-designed but never tested is a Level 1 control, whatever the policy document looks like.

Step 3: Collect Evidence That Shows the Control Operating

The goal is evidence that a control operated in practice, going beyond a written description of intent.

1. Is it current? Evidence older than 12 months for a dynamic control, such as access reviews or penetration tests, is unlikely to satisfy a regulator.
2. Is it complete? A penetration test covering 30% of in-scope systems doesn't evidence the full estate.
3. Is it approved? Unsigned drafts and informal records carry less weight than formally approved documents.
4. Does it show the control operating? A policy shows intent. A test record shows execution, and an assessment needs both.

Pair document review with interviews and walkthroughs. Ask a system owner to walk you through how a control actually works day to day. The gap between what the documentation says and what people actually do is usually where the most useful finding sits.

Step 4: Score, Spot Systemic Weakness, and Build the Roadmap

Score each domain against your pre

defined criteria and record the reasoning behind every rating. A regulator or auditor reviewing the assessment cares more about why you reached a conclusion than which number you assigned.

1. Ownership gaps: Multiple domains scoring low on the review dimension usually means nobody has clear accountability for keeping controls current.
2. Asset visibility gaps: Weaknesses clustering across secure development, access control, and effectiveness testing often trace back to an incomplete asset inventory.
3. Supplier governance gaps: Low supply chain scores paired with weak contractual evidence usually point to a structural problem across the supplier programme.
4. Testing cadence gaps: Controls that score well on design and implementation but poorly on evidence usually mean testing has lapsed, the most common finding in programmes that ran an initial gap analysis and never maintained it.

Prioritise remediation on two axes: how directly a domain maps to an Article 21 obligation a competent authority is likely to scrutinise, and how much a weakness increases the likelihood or severity of a significant incident.

1. Immediate actions (0-90 days): High-exposure, low-maturity findings where evidence can be produced or controls tightened quickly, such as overdue access reviews or lapsed incident exercises.
2. Structured remediation (90 days to 12 months): Findings that need process redesign, new tooling, or cross-functional coordination, such as a supply chain security framework.
3. Continuous improvement (ongoing): Controls that are functioning but not yet managed or optimised, which feed into the next assessment cycle.

Assign a named owner and a target date to every action. A roadmap without owners is a wish list.

1. Treating policy completeness as maturity: A full library of approved policies with no evidence of operational execution scores as a Level 2 programme at best.
2. Running the assessment inside compliance alone: Without input from IT operations, security, procurement, HR, and business continuity, the scores reflect what compliance knows, and miss what is actually happening elsewhere in the business.
3. Using vague scoring criteria: If assessors interpret the same evidence differently, the results stop being comparable across teams or time. Define scoring rules before you start.
4. Producing findings without owners or deadlines: A findings report with no remediation plan attached has consumed real effort for limited return.
5. Assessing once and filing it away: NIS2 expects ongoing monitoring of risk management effectiveness, so build the next assessment date into the output from day one.

A NIS2 maturity assessment is the mechanism that proves a compliance programme works: to the board, to the competent authority, and to the organisation itself when an incident tests everything at once. Run it once and you get a snapshot. Run it on a defined cycle and you get proof the programme keeps working.

The score matters less than what it enables: a clear view of where the programme is strong, a credible case for prioritising remediation spend, and evidence that leadership is actively monitoring risk management effectiveness, exactly what Article 21 requires.

SureCloud's Continuous Controls Monitoring keeps the review dimension from lapsing between formal assessments, the exact gap that turns a Level 3 control into a Level 1 finding by the next audit. Gracie AI Agents with Personas and Skills, run through a dedicated Compliance Lead Persona, tracks control evidence, ownership, and review cycles inside the platform instead of a static template that ages the moment it’s filled in, and teams using it report a 75% reduction in audit preparation time. Run alongside SureCloud's NIS2 compliance workspace, the same evidence maps to DORA and ISO 27001 without duplicating the work.

Teams that run a structured assessment now walk into scrutiny already knowing where the gaps are, instead of finding out when something goes wrong