NIS2 Compliance Dashboard: 18 Indicators to Track After Go-Live — and Where Each Number Comes From

Most post-go-live NIS2 dashboards fail the same way. Every number on them is true, and not one of them can be traced. The board sees “94% patch compliance”, nobody in the room can say which system produced it, who refreshed it, or when — and the moment a competent authority asks for the underlying evidence, the dashboard becomes a liability instead of a defence.

The fix is not more metrics. It is treating each indicator as a record with a fixed set of fields, and Commission Implementing Regulation (EU) 2024/2690 has already written down what those fields are. Point 7 of its Annex names six things an entity must determine about every measurement it performs [5]. Those six determinations are your dashboard’s columns. Everything below builds outwards from them.

Does this apply to you, and how much of it is binding?

Two different obligations get conflated here. Article 21(2)(f) of Directive (EU) 2022/2555 requires “policies and procedures to assess the effectiveness of cybersecurity risk-management measures” from every essential and important entity, through national transposition [1]. CIR 2024/2690, which spells out what that means in practice, binds a much narrower group.

Your entity	Is CIR 2024/2690 binding?	What that means for the dashboard
DNS providers, TLD registries, cloud, data centre and CDN providers, managed service and managed security service providers, online marketplaces, search engines, social platforms, trust service providers	Yes, directly. Article 1 names exactly these categories as “the relevant entities” [5]	Annex point 7 is a legal requirement, not a template. The indicators, methods, timing and named owners must exist in writing
Any other essential or important entity — energy, health, transport, water, waste, manufacturing, public administration, digital providers outside the list	No. The CIR does not extend to you	Article 21(2)(f) still binds you through national law. The CIR Annex remains the only Commission-adopted specification of what “assess effectiveness” means, and ENISA’s guidance mirrors it — which is why auditors reach for it anyway
German entities of either kind	Separate national anchor	The BSI ties the duty to Section 30(2) of the BSIG and tells entities to define Kennzahlen und Grenzwerte — metrics and thresholds, not metrics alone [7]

If you sit in the second row, treat the CIR Annex as a specification you have chosen to adopt, and say so in your policy. That sentence costs nothing and turns “we copied a regulation that does not apply to us” into a documented methodology decision. Our guide to CIR 2024/2690 covers the full scoping question.

The dashboard’s columns are already written down

Annex point 7.2 does not ask for a dashboard. It says the entity “shall determine” six things, and each one maps cleanly onto a column [5]. Read them as a schema rather than a checklist and the design work mostly disappears.

Annex 7.2	Column	What a failed column looks like
(a) what measures are to be monitored and measured	Indicator name and the Article 21(2) point it evidences	A metric nobody can map back to a requirement
(b) the methods for monitoring, measurement, analysis and evaluation	Source system and calculation	“From the SIEM” with no query and no denominator
(c) when the monitoring and measuring is to be performed	Refresh frequency and the “as at” date of the current value	A number with no date, silently months old
(d) who is responsible for monitoring and measuring	Data owner (a named role)	“IT”
(e) when results are to be analysed and evaluated	Review cadence	Refresh and review treated as the same event
(f) who has to analyse and evaluate these results	Reviewer (a different named role)	The person who produced the number also signs it off

Two columns the regulation implies rather than lists are worth adding, because they are the ones that survive contact with a supervisor.

An evidence pointer. Article 32(2) lets authorities demand “evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor and the respective underlying evidence” from essential entities; Article 33(2) gives materially the same powers over important entities, exercised ex post [3][8]. A number is not evidence. The export, ticket, review record or signed minute behind it is. Put the location of that artefact in the row, and the dashboard stops being a summary of things you would then have to go and find.

A reasoning field for what does not apply. Article 2(2) of the CIR says that where a requirement is framed “where appropriate”, “where applicable” or “to the extent feasible” and the entity judges it inapplicable, it “shall in a comprehensible manner document its reasoning to that effect” [5]. Multi-factor authentication under Article 21(2)(j) carries exactly that qualifier. So the correct dashboard treatment of an inapplicable requirement is a row with a reason, never a deleted row.

Keeping (d) and (f) as separate people is not bureaucratic decoration. ENISA’s guidance says internal assessors “should not come from the department or division whose systems are being inspected”, and Annex point 2.3.2 bars internal reviewers from sitting in the line of authority of the area under review, with alternative impartiality measures where an entity is too small to separate them [6][5].

The 18 indicators, and where each number comes from

Five categories, eighteen rows. The anchor column is what makes each one defensible — it is the Annex point or directive article the indicator exists to evidence.

Risk posture (4)

Indicator	Source	Anchor	Refresh
Open risks above stated tolerance	Risk register	Annex 2.1	Monthly
Overdue risk treatment actions, with the age of the oldest	Risk treatment plan	Annex 2.1	Monthly
Critical and high vulnerabilities past remediation SLA	Vulnerability scanner	Art 21(2)(e); ENISA names both “vulnerabilities detected” and “time to remediation”	Monthly
Days since the risk assessment was last refreshed	Risk register metadata	Annex 2.1 — at least annually	Calculated

Incident metrics (4)

Indicator	Source	Anchor	Refresh
Incidents opened and closed, by severity	Incident register	Art 21(2)(b); ENISA names “number of incidents”	Monthly
Incidents that met or approached the significance threshold, including recurring clusters	Incident register plus finance	Art 23(3); CIR Art 3(1)(a) sets a loss criterion of EUR 500 000 or 5% of prior-year turnover, whichever is lower; CIR Art 4 clusters repeats [5]	Monthly, cluster check quarterly
Reporting-clock adherence: 24-hour early warning, 72-hour notification, one-month final report	Incident register timestamps	Art 23(4) [4]	Per incident
Incidents attributable to a change	Incident register joined to change records	ENISA names “number of incidents related to a change” [6]	Monthly

That second row carries a duty most incident registers are not built for. CIR Article 4 says incidents that individually are not significant “shall be considered collectively as one significant incident” where they have occurred at least twice in six months, share the same apparent root cause, and collectively meet the financial-loss criterion [5]. Annex point 3.4.2(b) then requires entities to assess the existence of such recurring incidents on a quarterly basis. So the indicator is not a count of incidents — it is a root-cause clustering job with a four-times-a-year clock on it, and it is the reason a severity-only incident table is insufficient. Our guide to NIS2 incident reporting covers the notification chain that follows.

Supplier health (3)

Indicator	Source	Anchor	Refresh
Registry coverage: direct suppliers recorded versus contracts held	Supplier registry versus procurement	Annex 5.2 — registry with contact points and the ICT products and services supplied	Quarterly
Suppliers overdue for their scheduled review	Supplier registry	Annex 5.1.6	Monthly
Supplier-originating incidents and SLA report exceptions	Incident register; SLA reports	Annex 5.1.7(a) and (b)	Monthly

Access and identity hygiene (4)

Indicator	Source	Anchor	Refresh
Access-rights reviews completed versus due	IAM or review records	Annex 11.2.3 — review at planned intervals, document the results	Quarterly
Privileged and system administration accounts: count, and reviews overdue	Directory service	Annex 11.3.3	Monthly
Leaver revocation lag: median days, and count exceeding SLA	HR joined to IAM	Annex 11.2.2(b)	Monthly
In-scope accounts without MFA, plus the documented reason where it is deemed inapplicable	Identity provider	Art 21(2)(j), read with CIR Art 2(2)	Monthly

Policy and documentation currency (3)

Indicator	Source	Anchor	Refresh
Mandatory topic-specific policies past their review date	Document register	ENISA lists ten required topic-specific policies [6]	Monthly
Days since the management body last approved or reviewed the security policy	Board minutes	Annex 1.1.2 — at least annually, results documented	Calculated
Open non-compliances from compliance monitoring, and assets still unclassified	Compliance review log; asset register	Annex 2.2 and 12.1.3; ENISA names “number of non-compliances” [6]	Monthly

Be honest with yourself about provenance. ENISA’s chapter 7 KPI list is explicitly indicative and non-exhaustive, and it names eight items: cost of implementation and maintenance, employees who attended training, vulnerabilities detected, time to remediation, number of incidents, incidents related to a change, incident response times, and number of non-compliances [6]. Four of the eighteen above trace directly to that list. ENISA names nothing at all for supplier health or access and identity hygiene — those seven indicators are practitioner constructions, and their defence is not a KPI list but the review-and-document duties at Annex 5.1.6, 5.1.7, 11.2.3 and 11.3.3.

Three of ENISA’s eight are deliberately absent. Training completion and the CAPEX/OPEX cost of implementation are programme measures, and they belong in the board reporting pack. Incident response time is a security-operations measure; it sits in the wider KPI menu covered in our piece on the security metrics auditors expect. Leaving them out is a scoping choice, not an oversight — say so in your methodology and the omission stops looking like a gap.

What actually changes month to month

Here is the uncomfortable part: the word “monthly” does not appear anywhere in CIR 2024/2690, and it does not appear in ENISA’s frequency ladder for effectiveness assessment. That ladder runs continuous for measures addressing real-time threats such as firewalls and intrusion detection, biannual for threat-landscape measures such as vulnerability management and incident response plans, annual for the overall effectiveness of all measures, plus event-driven assessments after a specific incident or a significant system change [6]. ENISA does prescribe monthly cadences elsewhere in the same document — reviewing firewall rules and checking configurations, for instance — but never for the point 7 cycle. The one cadence the Annex fixes by name is quarterly, for the recurring-incident assessment at point 3.4.2(b) [5]. A monthly review cycle is an operating convention, not a legal one.

That convention still earns its place, for one reason: it is the shortest interval at which an overdue item surfaces early enough to be fixed before an annual clock runs out. Recital 9 of the CIR indicates that the indicators exist in particular to facilitate management-body oversight — a recital, so interpretive rather than binding, but it tells you what the drafters had in mind [5]. Article 20 makes that oversight a duty management bodies can be held liable for [2].

Movement	Indicators	What the monthly review does with them
Genuinely moves monthly	Open risks above tolerance; overdue treatments; vulnerabilities past SLA; incidents by severity; incidents from a change; supplier incidents and SLA exceptions; leaver revocation lag; privileged account count	Read the trend, not the value. A single month’s number is noise
Moves quarterly at best	Recurring-incident clustering (the one cadence the Annex fixes by name); access-rights reviews completed; supplier registry coverage; suppliers overdue; policies past review date; open non-compliances; unclassified assets	Confirm the schedule is on track. Escalate slippage, do not re-litigate the number
Annual or event-driven	Days since risk assessment refresh; days since management-body approval; reporting-clock adherence	Watch the countdown. These are the rows that quietly expire

Which makes the “as at” date the most important column on the board. A number that moves annually, re-displayed in month seven with no date attached, is the single most common way a dashboard misleads the people relying on it. And it has legal weight: Article 21(4) requires an entity that finds it is not compliant to take corrective measures “without undue delay” [1]. A stale cell delays the finding, and the clock starts from when you should have known. This is a different question from whether a given control is monitored continuously or periodically, which we work through in continuous versus periodic monitoring.

Excel, Power BI, or a GRC platform

Pick the tool from the column requirements, not the vendor demo. Three questions settle it: how many source systems feed the eighteen rows, whether evidence artefacts must be linked from the dashboard itself, and whether anyone other than the person who built it has to maintain it.

Tool	Where it holds up	Where it breaks	Choose it when
Excel	All eight columns fit natively, including the two free-text ones. Owners edit it without training	Overwriting in place destroys last month’s value — and ENISA lists “logs or records from previous effectiveness assessments” among the expected evidence [6]. Fix it with an append-only history sheet and never edit a prior month’s row	Three or fewer source systems, manual entry, one maintainer
Power BI or an equivalent BI layer	Scheduled refresh, visible data lineage, and an automatic “as at” timestamp — the column people most often forget	The evidence pointer and the applicability reasoning have nowhere natural to live; they end up in the source system, out of the reviewer’s sight	Four or more source systems and the refresh burden is the bottleneck
GRC platform	Control-to-evidence mapping and review workflow are the product, not a bolt-on	Cost and configuration effort scale with the control set, not with your eighteen indicators	Linking evidence to controls is the bottleneck — not counting metrics

Whichever you choose, apply the BSI’s acceptance test. It splits effectiveness into three dimensions: whether the measure is conceptually suitable, whether it is implemented faithfully in day-to-day operation, and whether it produces the intended result [7]. Most dashboards only ever show the third. Tag each indicator with the dimension it actually evidences and the gaps become visible immediately — a count of privileged accounts speaks to implementation fidelity, not to whether privileged access management was the right control in the first place.

What each role does with it

CISO or IT security manager. Own columns (b) and (d) — the calculation and the data owner for every row. The most common defect is a calculation that lives in one person’s head. Write the query or the counting rule into the row itself.

Compliance officer. Own the anchor column and the evidence pointer. Before each review, spot-check three rows by opening the artefact the pointer names. If it is missing or does not support the number, that row is a finding, not a metric.

SME owner without a security team. Start with the eight monthly-moving indicators and the two countdown rows. Ten rows in a spreadsheet with dates and named owners beats eighteen rows nobody refreshes. Add the rest as the underlying registers come into existence.

Management body. Read the review cadence column, not the values. Under Annex 2.3.3, the results of compliance monitoring and of the point 7 monitoring must be reported to you, and corrective action taken or residual risk formally accepted [5]. If a row has been red for three consecutive reviews with no accepted-risk decision recorded, that is the item to raise. The twelve-month NIS2 programme sets out how the reporting chain gets built.

Frequently Asked Questions

Is a compliance dashboard actually required by NIS2?
No. Article 21(2)(f) requires policies and procedures to assess effectiveness [1], and CIR Annex point 1.1.1(j) requires the security policy to “lay down indicators and measures to monitor its implementation and the current status of relevant entities’ maturity level” [5]. Neither names a dashboard. A dashboard is simply the most practical way most entities discharge both, and it is the artefact auditors ask to see.

How many indicators should we track?
Fewer than you think. ENISA advises taking the cost of measurement into account and using the same KPIs for each assessment so results stay comparable [6]. In practice, eighteen is about the ceiling for a single monthly review — past roughly thirty rows, the tail stops getting refreshed and the dashboard starts reporting yesterday’s programme.

Can the same person own an indicator and evaluate it?
Points 7.2(d) and 7.2(f) are separate determinations for a reason. ENISA’s guidance says internal assessors should not come from the department whose systems are inspected, and Annex 2.3.2 keeps independent reviewers outside the reviewed area’s line of authority — with alternative impartiality measures allowed where an entity is too small to separate them [6][5].

What do we do with requirements that do not apply to us?
Keep the row and fill in the reasoning. Where a CIR requirement is qualified by “where appropriate”, “where applicable” or “to the extent feasible” and you judge it inapplicable, Article 2(2) requires you to document that reasoning comprehensibly [5]. A deleted row looks like an oversight; a row with a dated justification looks like a decision. The same logic applies to supplier reviews you defer — our supply chain monitoring calendar covers that case in detail.

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, Article 21 — Cybersecurity risk-management measures
2. Directive (EU) 2022/2555, Article 20 — Governance
3. Directive (EU) 2022/2555, Article 32 — Supervisory and enforcement measures for essential entities
4. Directive (EU) 2022/2555, Article 23 — Reporting obligations
5. Commission Implementing Regulation (EU) 2024/2690, including Article 4 and the Annex — EUR-Lex
6. ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 (June 2025)
7. BSI, Bewertung der Wirksamkeit von Massnahmen (#nis2know)
8. Directive (EU) 2022/2555, Article 33 — Supervisory and enforcement measures for important entities