12 NIS2 Security Metrics Auditors Expect Even Though CIR Section 7 Names None

Search for “the official NIS2 KPI list” and you’ll find dozens of vendor blog posts confidently naming one. There isn’t one. We read the actual text of Commission Implementing Regulation (EU) 2024/2690 — the technical rulebook behind NIS2’s Article 21(2) risk-management measures — and its Section 7, the part that covers effectiveness assessment, does not name a single metric [1]. What it does is something more useful once you understand it: it tells you exactly what a defensible measurement program has to contain, and leaves the specific numbers to you.

That gap between “the law requires a process” and “auditors expect numbers” is where most compliance teams get stuck. This guide closes it: the verbatim Section 7 requirement, who it legally binds, and 12 practitioner-standard KPIs — each with a measurement method, an evidence artifact, and the specific control it demonstrates — that satisfy what Section 7 actually asks for.

Who CIR 2024/2690 Section 7 Actually Binds

This matters before anything else, because most articles skip it. CIR 2024/2690 is not a rulebook for every NIS2 essential or important entity — its Article 1 limits it to eleven categories of digital-infrastructure and digital-service providers [1]:

Bound by CIR 2024/2690 Section 7 directly	Governed by Article 21(2)(f) generally, not this CIR
DNS service providers · TLD name registries · cloud computing service providers · data centre service providers · content delivery network providers · managed service providers · managed security service providers · online marketplaces · online search engines · social networking platforms · trust service providers	Energy, transport, health, water, banking, manufacturing, public administration, and every other NIS2 sector under Annex I/II not listed at left

If your entity sits in the right-hand column, Article 21(2)(f) of the Directive still requires you to have “policies and procedures to assess the effectiveness of cybersecurity risk-management measures” [2] — you’re just not bound by this specific CIR’s granular methodology. In practice, most national competent authorities and most auditors treat Section 7’s structure (what/how/when/who) as the reference model for that obligation regardless of sector, because no equivalent implementing act exists yet for other entity types. Confirm your own entity tier and sector against our full Article 21(2) breakdown before assuming which regime applies.

What CIR Section 7 Actually Requires

Here is the operative text, not a paraphrase. Section 7.1 requires bound entities to “establish, implement and apply a policy and procedures to assess whether the cybersecurity risk-management measures taken by the relevant entity are effectively implemented and maintained.” Section 7.2 then requires that policy to determine six things [1]:

Section 7.2 point	Plain-language translation
(a) What is monitored and measured	Which controls and processes get a number attached to them
(b) The methods	How each measurement is taken, so results are valid and repeatable
(c) When measurement happens	A fixed cadence, not “whenever someone remembers”
(d) Who is responsible for measuring	A named owner per metric, not “the security team”
(e) When results get analysed	A review date, separate from the collection date
(f) Who analyses and evaluates the results	A named reviewer with the authority to act on what they find

Section 7.3 adds that this policy must be reviewed and updated at planned intervals, and after significant incidents or significant operational changes [1]. Read together, an auditor checking Section 7 compliance isn’t checking whether you track “the right 12 metrics” — there’s no such list to check against. They’re checking whether every metric you do track has an owner, a method, a cadence, and a reviewer who can show what they did when a number went the wrong way. A dashboard with no named reviewer fails Section 7 even if every chart on it looks healthy.

Why Auditors Still Ask for Specific Numbers

If Section 7 doesn’t name a KPI, why does an auditor still sit down and ask “what’s your patch compliance rate?” Because Section 7.2(a) obliges you to have already decided what gets measured — the question is really “show me the answer you were required to write down.” ENISA’s technical implementation guidance translates this same what/how/when/who structure into worked evidence examples across all 13 Annex sections, and it’s worth reading alongside the regulation itself if you’re building a program from scratch (see our summary of ENISA’s implementation guidance).

This is also why a metrics program built to “look good” fails Section 7 even when every number is green. An auditor testing 7.2(b) through (f) isn’t grading your patch rate against a pass/fail threshold the regulation never set — they’re testing whether the methodology behind it is real: does the named owner exist, did the named reviewer actually meet on the date the policy says they would, and is there a record of what happened the last time a number went red. A missed review cycle is a more serious finding than one quarter of below-target patch coverage, because it breaks the process Section 7 actually requires, not just a number inside it.

The 12 KPIs That Satisfy the What/How/When/Who Test

None of these 12 are named in the regulation. They’re the practitioner-standard set that, in our reading, gives a Section 7 policy something real to point at for each of the ten Article 21(2) control areas — each one calibrated as a recommended practice, not a legal minimum. Every KPI includes what it measures, the evidence artifact an auditor would ask to see, and which control area it demonstrates.

KPI	Measurement method	Evidences
1. Vulnerability scan coverage %	Assets under active recurring scanning ÷ total assets in the register	Art. 21(2)(e) — NIS acquisition/maintenance
2. Patch coverage % by severity	Critical/high findings remediated ÷ total critical/high findings open, tracked separately per tier	Art. 21(2)(e)
3. Mean-time-to-patch (MTTP) by severity	Median days from disclosure/detection to remediation, per severity tier	Art. 21(2)(e)
4. MFA coverage % (privileged vs. standard)	Accounts with MFA enforced ÷ total accounts, reported as two separate figures	Art. 21(2)(i)/(j)
5. Access review completion % (on time)	Recertifications completed by deadline ÷ recertifications scheduled	Art. 21(2)(i)
6. Security awareness training completion %	Staff completed ÷ staff required, plus assessment pass rate	Art. 21(2)(g)
7. Phishing-simulation report rate	Simulated phishing emails reported ÷ simulated emails delivered	Art. 21(2)(g)
8. Mean-time-to-detect (MTTD)	Median time from compromise to internal detection, from SIEM/EDR timestamps	Art. 21(2)(b)
9. Mean-time-to-respond/contain (MTTR)	Median time from detection to containment, from incident-log timestamps	Art. 21(2)(b)
10. Log retention & monitoring coverage %	In-scope systems sending logs to the central monitoring capability ÷ total in-scope systems, retained per your documented policy period	Art. 21(2)(b)/(f)
11. Supplier risk-assessment coverage %	Critical/direct suppliers with a current, completed risk assessment ÷ total critical suppliers	Art. 21(2)(d)
12. Backup/restore test success rate	Successful test-restores ÷ scheduled test-restores in the period	Art. 21(2)(c)

Four of these deserve a closer look, because the number alone can mislead as easily as it informs.

Patch coverage and MTTP only mean something split by severity. A single blended “92% patch compliance” figure can hide a critical, internet-facing CVE that’s sat open for four months while a hundred low-severity desktop patches padded the average. Verizon’s 2026 Data Breach Investigations Report found the median time to fully patch a vulnerability had risen to 43 days, up from 32 the year before, and that only 26% of flaws on CISA’s Known Exploited Vulnerabilities catalog were fully remediated across the organisations studied [3]. Roughly 31% of breaches in the same report traced back to an unpatched, exploited vulnerability [3]. Some regulators are moving toward risk-tiered patch windows rather than blanket deadlines — the U.S. CISA’s 2026 directive to federal agencies, for context (not an EU requirement), sets a 3-day window for the highest-risk combination of public exposure, known exploitation, and automatable attack, stepping out to two weeks for lower-risk cases [4]. Whatever windows you set, Section 7.2(a) wants you tracking MTTP as a distribution by severity, not one number.

MFA coverage on privileged accounts is the number that actually predicts breach risk — “98% MFA coverage” overall can still mean every service and admin account is exempt. Those are exactly the accounts attackers target for lateral movement once they’re past the perimeter, so a Section 7 policy that reports one blended MFA figure hasn’t measured the thing that matters.

Phishing report rate is a better leading indicator than click rate. Click rates fall over time partly through habituation to the same simulation format, which looks like improvement but isn’t. Report rate — the percentage of staff who flag the simulated email — measures the behaviour that actually shortens MTTD on a real phishing incident, because it determines how fast your security team hears about it.

Log retention has a specific myth worth correcting. Several compliance guides describe an “18-month EU-wide log retention floor” under NIS2 [5]. Neither the NIS2 Directive nor CIR 2024/2690’s text sets a specific minimum retention duration [1] — Section 7 requires you to document your own method and cadence, not follow a number that isn’t in the regulation. A 12-month retention window (commonly split 6 months “hot”/searchable and 6 months archived) is a widely used practitioner baseline, and some national or sector authorities may set stricter floors in their own guidance — check yours directly rather than relying on a figure a vendor blog quotes as EU law — our own breakdown of what CIR 2024/2690 actually requires for logging walks through that decision in full.

What Each Role Should Take From This

Reader	What matters to you here
CISO / IT Security Manager	Own the measurement methods and cadences for KPIs 1–3 and 8–10; these require SIEM/EDR/scanner data you control directly
Compliance Officer / Legal	Own the Section 7.2(d)/(f) ownership trail — who measured, who reviewed, and the dated evidence an auditor will ask for first
Board / C-Suite	Ask for the KPI set at least quarterly with the reviewer’s sign-off attached, not raw charts — Section 7.3 expects a documented review cycle you can point to

Mistakes That Turn a Metrics Program Into an Audit Finding

1. Tracking a metric with no named owner. Section 7.2(d) requires a responsible party for every measurement. “IT” is not a name.
2. Collecting numbers nobody reviews on a schedule. Section 7.2(e)/(f) is a review requirement, not a storage requirement — a dashboard that updates automatically but that no one signs off on monthly fails this half of Section 7 even with perfect data underneath it.
3. Reporting blended averages instead of severity or account-tier splits. As shown above with patch coverage and MFA, a single aggregate number can look excellent while hiding the exact gap an attacker would use.
4. Treating a vendor-quoted number as law. The 18-month retention example is the clearest case: verify any specific figure against the Directive or CIR text itself before building a policy around it.
5. Never updating the measurement policy after an incident. Section 7.3 explicitly requires review after significant incidents, not just on a calendar schedule.

None of these are abstract. A Section 7 finding during a supervisory review compounds with any other Article 21 gap the same audit turns up, and enforcement bodies increasingly treat a missing measurement trail as evidence the underlying controls were never verified — see our breakdown of NIS2 penalty tiers and what triggers them for what’s actually at stake.

Frequently Asked Questions

Does CIR 2024/2690 require exactly these 12 KPIs?
No. Section 7 requires a documented what/method/cadence/owner/review structure and does not name specific metrics [1]. These 12 are a practitioner-standard set that fills that structure across the ten Article 21(2) control areas.

My entity isn’t a cloud provider, MSP, or one of the other 11 categories — does any of this apply to me?
CIR 2024/2690’s specific text binds only those 11 categories [1], but Article 21(2)(f) of the Directive itself requires every essential and important entity to have effectiveness-assessment policies and procedures [2]. Most auditors reference Section 7’s structure as the practical model regardless of sector, since no equivalent implementing act exists yet for other entities.

What evidence should I have ready before an audit?
For each KPI: the measurement method documented in writing, dated collection records, a named owner and reviewer, and evidence of at least one review cycle where a result was analysed and, where needed, acted on.

Do these KPIs replace a full risk assessment?
No. They’re the ongoing measurement layer that sits on top of your risk assessment under Article 21(2)(a) — they tell you whether the measures your risk assessment called for are actually working, not what those measures should be in the first place.

Sources

• [1] Commission Implementing Regulation (EU) 2024/2690, Annex point 7 and Article 1 — eur-lex.europa.eu
• [2] NIS2 Directive (EU) 2022/2555, Article 21(2) — nis-2-directive.com
• [3] Verizon 2026 Data Breach Investigations Report, as reported by SecurityWeek — securityweek.com
• [4] CISA Binding Operational Directive 26-04, as reported by BleepingComputer (U.S. federal directive, cited for context only) — bleepingcomputer.com
• [5] ISMS.online, NIS2 logging & retention guidance (cited to correct its “18-month floor” claim against the primary text in [1]) — isms.online

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.