Cybersecurity Maturity Model: Benchmark Before a NIS2 Audit — One Rule Names It, No Rule Scores It

Run a word search over the two instruments that actually bind you. Directive (EU) 2022/2555 uses the word “maturity” twice, and neither time is about your organisation: once in Recital 75, about Member States’ levels of maturity, and once in Article 18(1)(e), where the Union’s maturity is reported at sector level [1]. Commission Implementing Regulation (EU) 2024/2690 uses it three times, and exactly one of those creates an obligation [2]. Neither instrument contains the words score, scoring, rating, weighted or weighting. Not once.

So nobody is going to fail you for being “Level 2”. But a security policy with no indicators in it misses a shall.

That gap is what this guide closes: which line of law your maturity model has to satisfy, which parts of it a supervisor can genuinely test, how to choose between the four model families on regulatory grounds instead of brand recognition, and what external data you can honestly benchmark against.

Does this apply to you, and which rule is actually binding?

In plain terms: every entity in scope of NIS2 has to manage cybersecurity risk and be able to show it. Only a subset has a rule that names your maturity level in writing — and even that rule tells you to have indicators, not to reach a number.

Your position	What binds you on maturity	What it actually says
An essential or important entity, under the Directive alone	Nothing, at entity level	The Directive never asks an entity to have a maturity level. Article 21(1) requires measures that are “appropriate and proportionate”; Article 21(2)(a) requires policies on risk analysis and information system security [1].
One of the eleven entity types in Article 1 of CIR 2024/2690 — DNS providers, TLD registries, cloud and data centre providers, CDNs, managed service and managed security service providers, online marketplaces, search engines, social networking platforms, trust service providers	Annex point 1.1.1(j) — binding	Your policy on the security of network and information systems shall “lay down indicators and measures to monitor its implementation and the current status of relevant entities’ maturity level of network and information security” [2].
Everyone else in scope	Your national technical rules	Article 21(5) lets the Commission extend technical and methodological requirements to entity types beyond those in the CIR by a further implementing act [1]. Until one covers your sector, what binds you is your Member State’s own technical rules — check them, because transpositions differ.

The binding-versus-interpretive split matters here, because three of the five “maturity” mentions across both instruments sit in recitals. CIR Recital 9 explains why the indicators exist — to “facilitate the oversight of the implementation of the cybersecurity risk-management measures through the management bodies”. Recital 40 observes that recurring incidents can indicate weaknesses in “their level of cybersecurity maturity”. Recital 75 of the Directive concerns peer review between Member States [1][2]. Recitals explain intent; they create no obligations. If someone tells you the regulation mandates a maturity assessment, ask which article. There is one candidate, and it is a policy-content requirement.

The four model families, and what each was built to do

Choose on what you have to prove, not on which acronym your consultant knows. The four families in circulation measure genuinely different objects, and only one was designed for NIS2.

Model	Scale	What it rates	Watch-out
The generic 0–5 ladder (ad hoc → optimising)	Six levels, usually applied per control or requirement point	How institutionalised a process is	No owner, no published definitions — so two assessors score identical evidence differently. Survivable internally; awkward once an independent reviewer arrives.
NIST CSF 2.0 Tiers	Tier 1 Partial, Tier 2 Risk Informed, Tier 3 Repeatable, Tier 4 Adaptive	“The rigor of an organization’s cybersecurity risk governance and management outcomes” [4]	Not a control score, and NIST says so: Tiers “should be used to guide and inform an organization’s cybersecurity risk governance and management methodologies rather than take their place” [4].
DOE C2M2 v2.1	MIL0–MIL3, applied independently to each of 10 domains across 356 practices	Whether practices are performed, and how institutionalised they are, domain by domain	Cumulative within a domain, independent between domains — so “we are MIL2” is not a sentence the model supports.
CyFun (CyberFundamentals)	Assurance levels, with a maturity assessment inside	Conformance to a NIST-CSF-derived control set, assessed “at various levels of maturity” [7]	The only family designed against NIS2 — but the certification infrastructure behind it is not yet in place in most Member States.

Two warnings from the model authors are ignored almost universally in vendor material. NIST states that selecting Tiers “overall or at the Function or Category level will provide a better sense of the organization’s current cybersecurity risk management practices than selecting Tiers at the lower Subcategory level”, and that progression to higher Tiers “is encouraged when needed to address risks or mandates” — not as a default ambition [4]. The US Department of Energy is blunter in C2M2 v2.1: “Striving to achieve the highest MIL in all domains may not be optimal.” The same document notes the model was built so that “all companies, regardless of size, should be able to achieve MIL1 across all domains” [5].

There is a mechanism behind those warnings, and it explains why a per-domain scale survives a NIS2 audit better than one organisation-wide number. Article 21(1) does not ask whether your measures are advanced. It asks whether they are appropriate to the risk, naming the factors: state-of-the-art, relevant standards, cost of implementation, your exposure, your size, and the likelihood and severity of incidents including their societal and economic impact [1]. Those factors vary between your domains, and a single aggregate averages away exactly the variation the proportionality test exists to examine — which is how a strong number in a low-risk domain masks an unmitigated gap in a high-risk one. For the scoring mechanics, see our 0–5 risk-weighted gap analysis method; for what each framework proves, the framework comparison. On CSF 2.0 itself, keep its own framing: “The CSF does not prescribe how outcomes should be achieved” [8].

The three things about your model an auditor can actually test

Your scale is unfalsifiable. Nobody can prove your Level 3 should have been a Level 2, because no instrument defines either. Three things around the scale are entirely falsifiable, and those are what a supervisor reaches for.

1. Does the policy lay down indicators at all? The binding test, and it is binary. CIR Annex 1.1.1(j) requires indicators and measures inside the policy document itself — not in a slide deck or a consultant’s report. Point 1.1.1(k) requires the policy to “indicate the date of the formal approval by the management bodies”, and 1.1.2 requires those bodies to review it at least annually and after significant incidents or changes, with the result documented [2]. An assessment living outside that document satisfies none of the three.

2. Does the reporting carry a current state to the board? Annex 2.2.2 requires a compliance reporting system “capable to provide to the management bodies an informed view of the current state of the relevant entities’ management of risks”, and 2.2.3 requires monitoring at planned intervals and on significant change [2]. A maturity score is a legitimate way to deliver that view. A score that arrives once at the end of a consulting engagement and never moves is not a reporting system. Our guide to the metrics auditors expect covers what the numbers should be.

3. Who signed the assessment? Annex 2.3.1 requires an independent review of your approach to managing network and information system security; 2.3.2 requires “individuals with appropriate audit competence”, and internal reviewers “shall not be in the line of authority of the personnel of the area under review” [2]. A self-score signed off by the person who owns the control is the most common finding waiting to happen. The regulation allows alternative impartiality measures where entity size prevents full separation — but it asks you to have thought about it.

What a supervisor actually requests is narrower than most preparation assumes. Article 32(2)(e) covers requests for information “including documented cybersecurity policies”; 32(2)(g) covers “requests for evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor and the respective underlying evidence” [1]. Evidence of implementation — not a number. Your maturity level is a navigation aid for finding that evidence fast; it is never the evidence itself, a distinction our piece on objective evidence in a NIS2 audit takes further.

One reversal inverts the premise of every “benchmark your programme” pitch in the market. The Directive mentions benchmarks exactly once, in Recital 124, and it is describing what the authority does to you: supervisory methodologies “could include criteria or benchmarks for the classification of essential entities into risk categories and corresponding supervisory measures and means recommended per risk category, such as the use, frequency or types of on-site inspections, targeted security audits or security scans” [1]. As a recital it obliges nobody and permits a range of national approaches — but it shows where classification pressure comes from, and your self-assigned level does not feed it. Your incident history and risk assessment do: Article 32(2) states that targeted security audits “shall be based on risk assessments conducted by the competent authority or the audited entity, or on other risk-related available information” [1].

What you can honestly benchmark against

Very little — and the two things that look like benchmarks measure something other than your organisation. Say that plainly in the board paper rather than discovering it in the questions afterwards.

The ENISA NIS360 is a sector instrument by design. The 2026 edition, the third, is explicit: “Unlike other maturity assessment tools that focus mainly on individual companies, the NIS360 assesses the cybersecurity maturity of entire sector ecosystem, including relevant actors (i.e., national authorities, entities, EU bodies) and applicable rules (EU legislation)” [6]. Its “risk zone” holds sectors “with lower-than-average maturity and criticality that exceeds their maturity” — in 2026, health, railway, maritime, ICT service management, space, public administrations, and drinking and waste water, with gas beginning to move out [6]. Read it as context for how much scrutiny your sector attracts, never as a target: ENISA notes the zone’s composition “changes over time as overall maturity improves across sectors”, so a sector can enter because the average moved rather than because anything deteriorated.

One national framework in the EU pools comparable data. ENISA’s Technical Implementation Guidance annexes the national frameworks Member States submitted during its consultation. Five states appear — Belgium, Finland, Germany, Greece and Spain — and exactly one of the five entries describes data being pooled. Finland’s Kybermittari (Cybermeter), built by NCSC-FI on the Cybersecurity Capability Maturity Model and the NIST framework, is the instrument the national recommended measures are mapped to, and uniquely: “voluntarily sharing quantitative self-assessment data to NCSC-FI enables the creation of benchmarking data” [3]. Belgium reserves a special role for CyFun, itself assessed at various levels of maturity [7], but ENISA’s entry records no equivalent pooling; Germany points to a state-of-the-art advisory and IT-Grundschutz; Greece supplies a handbook and self-assessment tool built on CIS Controls, ISO 27002, NIST 800-53 and OWASP; Spain applies Royal Decree 311/2022 [3]. One dataset, four instruments without one. If cross-entity benchmark data is what you want, there is a single place in Europe it is being assembled — voluntary, and national.

The equivalence route exists, and it has a waiting time. ENISA states that entities “can use national frameworks, guidance, standards or other mechanisms equivalent to the requirements of the regulation to demonstrate their compliance to national competent authorities” [3] — that is how a maturity framework becomes audit currency instead of an internal habit. The ceiling is timing. Ireland joined CyFun as a scheme co-owner and calls it “a pathway to certification or formal assurance”, while stating that “a national certification system will take 18-24 months to establish … In the meantime, entities are encouraged to use the framework internally and begin preparations” [7]. In most Member States there is no certificate to benchmark to yet — which is why the three internal tests above carry the weight. See our summary of the guidance and the post-go-live indicator dashboard.

One observation from reading that guidance line by line, offered as our reading rather than ENISA’s position: across 170 pages, point 1.1.1(j) is left almost entirely unelaborated. The bullets under 1.1.1 cover scope, acknowledgement, awareness, board approval, topic-specific policies and exception handling; none addresses indicators or maturity level. The examples of evidence ask only for a “documented policy … which contains the elements required by points 1.1.1 (a) to 1.1.1 (k)” [3]. The one binding line naming your maturity level is the one with no implementation guidance behind it — which hands you the pen, and makes the model yours to justify.

What each role should do before the audit

Role	Do this before the audit	Effort
CISO / IT security manager	Score per domain, not per organisation, and attach a named artefact to every indicator. A domain with a level but no artefact behind it is the gap an assessor finds first.	Medium
Compliance officer	Move the indicators into the policy document, get the board approval date onto it, and book the independent review with someone outside the line of authority of the area reviewed.	Low
SME owner / non-technical	Basic evidenced coverage everywhere beats advanced coverage anywhere. C2M2’s designers built their entry level to be reachable by any company regardless of size [5]; copy that shape.	Low
Board / management body	You are the addressee of both rules that matter here. Ask for current state and what changed, not a trophy number, and record the annual review decision.	Low

Urgency depends on your classification, and the split is sharper than most summaries admit. Essential entities face ex ante supervision: Article 32(2) lets competent authorities impose “regular and targeted security audits”, inspections and off-site supervision with no allegation of wrongdoing required. Important entities are supervised ex post only — Article 33(1) opens “when provided with evidence, indication or information that an important entity allegedly does not comply” [1]. If you are an important entity, nobody is scheduled to look. That does not make the assessment optional; it changes what it is for, from passing a booked inspection to finding your own gaps before an incident does.

Which is the strongest legal argument for running one, and not the one usually made. Article 21(4) requires that “an entity that finds that it does not comply with the measures provided for in paragraph 2 takes, without undue delay, all necessary, appropriate and proportionate corrective measures” [1]. The trigger is self-detection — so a programme with no assessment mechanism has almost nothing to fire that obligation, and an entity that never looks is not thereby compliant, only uninformed. Our five-level self-assessment and 47-question CIR Annex checklist exist to produce that detection; the implementation roadmap sequences what follows.

Mistakes that turn a maturity score into an audit finding

• Presenting a level as a compliance claim. “We are Level 3, therefore compliant” asserts an equivalence no instrument creates. Article 21(1) asks about appropriateness to risk [1].
• One number for the whole organisation. It averages away the variation the proportionality test exists to examine, and C2M2 applies its levels per domain [5].
• A self-score with no independent review. Annex 2.3.2 is specific about who may not sign it [2].
• A score that changes no decision. If no budget, risk acceptance or treatment plan moved because of it, it is not the “informed view of the current state” Annex 2.2.2 asks for [2].
• Chasing the top level everywhere. Both NIST and the Department of Energy warn against it in writing [4][5].
• Quoting your sector’s NIS360 band as your own maturity. It measures an ecosystem, regulator included [6].
• Keeping the assessment outside the policy. The indicators are a policy-content requirement; a brilliant assessment stored elsewhere still leaves 1.1.1(j) unmet [2].

Frequently Asked Questions

Does NIS2 require a cybersecurity maturity model?
No. The Directive never mentions entity maturity, and no provision requires a model, a scale or a score. The closest binding requirement is CIR Annex 1.1.1(j): the security policy of the eleven entity types in the CIR’s scope must lay down indicators and measures monitoring implementation and current maturity level [2]. The model producing those indicators is your design choice.

What maturity level do I need to pass a NIS2 audit?
There is no such level, because no instrument defines one. Under Article 32(2) a competent authority can demand documented policies and evidence of implementation with the underlying evidence behind it [1]. A level with no artefact behind it fails; a lower level with complete evidence and a documented, board-accepted reason does not have that problem.

Is NIST CSF Tier 4 the goal?
Not by default. NIST describes Tier selection as a leadership decision accounting for the threat environment, legal and regulatory requirements, business objectives and organisational constraints, and says progression “is encouraged when needed to address risks or mandates” [4]. Tier 4 in a low-exposure domain is spend without matching risk reduction — the reasoning Article 21(1) invites you to show anyway [1].

Can we use CyFun or Kybermittari instead of building our own model?
In principle yes: ENISA states entities can use national frameworks or equivalent mechanisms to demonstrate compliance to their national competent authority [3]. In practice it depends on whether your Member State recognises the framework and whether assurance infrastructure exists — NCSC Ireland puts a national certification system at 18-24 months and recommends internal use meanwhile [7].

How often should we re-run the assessment?
At minimum on the clocks the regulation already sets: policy review by the management bodies at least annually and after significant incidents or changes (Annex 1.1.2), risk assessment results and treatment plan at least annually (2.1.4), compliance monitoring at planned intervals and on significant change (2.2.3) [2]. Aligning the re-score with those dates means one evidence pack serves all three — cadence is worked through in our continuous improvement guide.

Key takeaways

One binding sentence about maturity and no scale to satisfy reads like a loophole, and is closer to the opposite: with nothing prescribed, every choice in your model is one you have to justify. Pick a per-domain scale so proportionality stays visible. Put the indicators in the policy, date the board approval, and have the review signed by someone outside the line of authority. Use NIS360 for sector context and nothing else. Then re-score on the clocks the regulation already sets — so the assessment becomes the mechanism that makes Article 21(4) fire, before a supervisor or an incident finds the gap for you.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Directive (EU) 2022/2555 (NIS2), Recitals 75 and 124, Articles 18, 21, 32 and 33 — EUR-Lex, official English text (linked above). Word counts in this article were derived from that text.
2. Commission Implementing Regulation (EU) 2024/2690, Recitals 9 and 40 and Annex points 1.1.1, 1.1.2, 2.1.4, 2.2 and 2.3 — EUR-Lex, official English text (linked above).
3. ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0, June 2025, including Annex I National Frameworks (linked above).
4. NIST, NIST Cybersecurity Framework 2.0: Quick-Start Guide for Using the CSF Tiers, NIST SP 1302, October 2024.
5. U.S. Department of Energy, Cybersecurity Capability Maturity Model (C2M2) Version 2.1, June 2022 (linked above).
6. ENISA, NIS360 2026, third edition, May 2026 (linked above).
7. National Cyber Security Centre Ireland, NIS2 Frequently Asked Questions.
8. NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, 26 February 2024 (linked above).
9. Centre for Cybersecurity Belgium, CyberFundamentals Framework (CyFun) — cyfun.eu. Characterised in this article via sources 3 and 7; the CCB domains block automated access.
10. Traficom / NCSC-FI, Kybermittari (Cybermeter) — described in source 3, ENISA Technical Implementation Guidance, Annex I.