NIS 2 effectiveness evaluation under Article 21(2)(f)
It is not enough to write down your cybersecurity measures. Article 21(2)(f) says you have to check whether they actually work, on an ongoing basis. CIR §7 turns that into named KPIs, owners and a review cadence.
The short version
Effectiveness evaluation is the proof loop. You spent a year setting up risk management, access control, cryptography, supplier reviews and the rest. Article 21(2)(f) asks the next question: do the measures you wrote down actually work? A documented control that no one tests is not the same as a working control.
CIR (EU) 2024/2690 §7 turns the abstract duty into a PDCA process. You pick what to measure. You pick how and how often. You name an owner for the measurement and an owner for the analysis. You review the results. You update the framework after every significant incident.
Germany puts the same rule into national law through §30(2)(6) BSIG. The wording follows the directive closely. This page walks the directive, the EU follow-up regulation, and the German transposition in that order.
Article 21(2)(f) NIS 2 Directive (2022/2555)
Policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
Point (f) on the list of ten cybersecurity measures every essential and important entity has to put in place. The directive does not say how often or with what KPIs. That is left to CIR §7.
CIR (EU) 2024/2690, Annex §7
For the purposes of Article 21(2)(f) of Directive (EU) 2022/2555, the relevant entities shall establish, implement and apply a policy and procedures to assess whether the cybersecurity risk-management measures are effectively implemented and maintained.
Directly binding EU law for the sectors named in the CIR Annex. §7 names the six things your policy must cover (what, how, when, who measures, when results are analysed, who analyses). It also requires a review on planned intervals or after every significant incident.
§30(2)(6) BSIG (Germany)
Policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
Germany copies the EU text almost word for word. The BSI expects you to point at a documented evaluation concept during an audit, not at an ad-hoc spreadsheet.
WHAT you measure
Name the cybersecurity risk-management measures you monitor. Procedures and controls both count. You do not have to measure everything. You do have to pick a set, write it down, and tie it back to the results of your risk assessment and to your prior significant incidents.
HOW and WHEN you measure
For each measure, name the monitoring and measurement method, the analysis approach, and the cadence. Quarterly metrics with an annual deep-dive is a common shape. The method has to produce valid results, so 'we have a feeling about it' does not pass.
WHO is responsible
Two named roles. One person owns the measurement (pulls the numbers, runs the test, exports the log). A second person owns the analysis (reads the data, judges whether the control is working, escalates). Same person can do both at small Mittelstand size, but the document has to name them.
Connect effectiveness to the risk register
CIR §7.2 says the policy must take account of risk assessment results and prior significant incidents. Free-floating KPIs do not count. If you measure patch compliance but your top three risks are supplier breaches, phishing and OT exposure, your KPIs miss the point. Pick KPIs that test the controls covering your highest risks.
Report up to the management body
Article 20(1) NIS 2 makes the management body approve the cybersecurity risk-management measures and oversee their implementation. They cannot oversee what they do not see. Effectiveness data has to land in front of them periodically. Quarterly is the common cadence. The format does not matter as long as it is documented.
BSI / IT-Grundschutz DER.1
The BSI lists effectiveness evaluation as point six of the ten Article 21(2) measures. IT-Grundschutz layer DER.1 'Detection' covers the operational monitoring side (log analysis, SIEM, anomaly detection). DER.1 alone does not satisfy §7, but it is one of the inputs your evaluation concept will reference.
ENISA Technical Implementation Guidance
The ENISA TIG for CIR (EU) 2024/2690 names the evidence auditors expect under §7: documented policy, KPI list with targets and actuals, named owners, review minutes, action items from analysis. ENISA also maps §7 onto ISO/IEC 27001:2022 controls 9.1 (monitoring) and 5.36 (compliance review).
National transposition laws
Every member state has its own transposition law (Netherlands: Cyberbeveiligingswet, Austria: NISG, Belgium: NIS2-Wet). The duty is the same because the directive sets one EU-wide standard. What differs: who you report to, what the audit cycle looks like, which sector regulator has the say in your country.
We run an annual audit, that is our effectiveness evaluation.
An audit is a point-in-time check. CIR §7 asks for ongoing monitoring and measurement, plus periodic analysis. The audit is one input, not the whole answer. If your only effectiveness evidence is a once-a-year audit report, you do not have a §7 concept.
We have a SIEM, so we have monitoring covered.
A SIEM is one tool among the inputs your evaluation concept references. §7 does not ask 'do you have a SIEM'. It asks 'which control are you testing, what KPI are you measuring against it, what target value defines effective'. SIEM dashboards on their own do not answer that.
Our CISO knows whether the measures work.
CIR §7.2(d) and §7.2(f) ask for named owners and documented analysis. Tribal knowledge in one person's head fails on two counts: no audit trail, no continuity if that person leaves. The concept has to be written, the analysis has to be recorded, and the management body has to see the results.
Most Mittelstand firms already measure two things: system uptime and patch compliance. Both are good KPIs, but they only cover two of the ten Article 21(2) measures. Article 21(2)(f) asks more of you: incident counts against targets, mean-time-to-detect, mean-time-to-respond, training completion rates, phishing test results, supplier review completion rates.
What we see in practice: pick six to eight KPIs that map onto your top risks. Quarterly readout to the management body. Annual deep-dive that reviews KPI selection against the updated risk register. After every significant incident, the §7.3 trigger fires and you review the relevant measures regardless of the calendar. That holds up under Article 21(1) proportionality for a 60 to 250-person operator.
We built the §7 evaluation concept into the platform as a module. You define KPIs, link each one to the risk-management measure it tests, set a measurement cadence and a target value, and name the owner for the measurement and the owner for the analysis. The platform reminds the owner when the next reading is due.
The management-body dashboard pulls every KPI into one quarterly view, ready for the Article 20(1) oversight meeting. After a significant incident, the §7.3 review trigger fires automatically: the relevant KPIs surface, the affected owners get a task, the analysis gets a sign-off. Audit trail is complete by default.
- Directive (EU) 2022/2555 (NIS 2), Article 21(2)(f) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex §7 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI Act (BSIG), §30(2)(6) as amended by the NIS2 Implementation and Cybersecurity Strengthening Act
- BSI IT-Grundschutz, layer DER.1 'Detection of security-relevant events' — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance for CIR (EU) 2024/2690 (as of May 2026)