NIS 2 risk management under Article 21(2)(a)
NIS 2 says you must manage cybersecurity risk in a structured way. Article 21(2)(a) is where the duty lives, CIR (EU) 2024/2690 §2 spells out the specifics, and your national regulator (in Germany: the BSI) is who you answer to.
The short version
Risk management sits at the top of Article 21(2)'s list of ten cybersecurity duties. If NIS 2 applies to you, you have to spot the risks to your systems, judge how bad they could be, and do something about them. The same rule applies across the EU.
CIR (EU) 2024/2690 fills in the detail. Annex §2 says your risk management framework needs three pieces. Set one up. Check that people actually use it. Have someone independent review it. That is the floor. If you run DNS, cloud, a data centre, an MSP, trust services or any other sector listed in the CIR Annex, this binds you directly.
Germany puts the same rule into national law through §30(2)(1) BSIG. The wording is almost word for word the EU text. This page walks the directive, the EU follow-up regulation, and the German transposition in that order.
Article 21(2)(a) NIS 2 Directive (2022/2555)
Policies on risk analysis and information system security.
This is point (a) on the list of ten cybersecurity measures every essential and important entity has to put in place.
CIR (EU) 2024/2690, Annex §2
For the purposes of Article 21(2)(a) of Directive (EU) 2022/2555, the relevant entities shall establish an appropriate risk management framework to identify and address the risks to the security of network and information systems.
Because this is a regulation (not a directive), it is directly binding EU law. No national transposition needed. It applies to DNS providers, TLD registries, cloud providers, data centres, managed service providers and the other sectors listed in its Annex.
§30(2)(1) BSIG (Germany)
Policies on risk analysis and on information technology security.
Germany copies the EU text almost word for word. The small change ('information technology security' instead of 'information system security') is wording, not meaning.
Set up a risk management framework
Write down how you spot risks, how you score them, what you do with them, and which risks you are willing to live with. Cover every system that matters for your business. Whoever decides what risks you accept has to sign for it, by name.
Check that people actually follow it
Review on a regular cadence whether your team is doing what the framework says. If they are not, write down the gap and fix it. A framework no one follows is not a framework.
Get an independent pair of eyes on it
Once in a while, someone who does not run the framework should look at it. Independent means structurally separate, not necessarily external. Your internal audit team can do it. A hired consultant can do it. The point is fresh eyes.
All-hazards approach (Article 21(2))
Cyberattacks are not the only thing on the list. Fire, flood, power loss, a key person leaving, a supplier going bust, all of it counts. If your risk register only has malware and phishing, you have not met the standard.
Proportionality (Article 21(1), second subparagraph)
You match what you do to the risk you actually face. The text says it must be 'appropriate to the risk posed'. Six things go into the call: how exposed you are, how big you are, how likely an incident is, how bad it would be (including the wider economic and social impact), the state of the art, and what it costs to put in place. A 60-person Stadtwerk does not need to spend like a bank.
BSI / §30 BSIG
The BSI lists the ten Article 21(2) measures in its Infopakete and calls them 'at least the following ten measures (see § 30(2) BSIG)'. The German transposition follows the directive wording closely and points at IT-Grundschutz as the practical route to implementation.
ENISA Technical Implementation Guidance
ENISA, the EU cybersecurity agency, publishes a Technical Implementation Guidance (TIG) that takes the abstract CIR text and shows you what to do in practice. It also maps the requirements onto established standards like ISO/IEC 27001:2022 and NIST CSF 2.0, so existing certifications give you a head start.
National transposition laws
Every member state has its own transposition law (Netherlands: Cyberbeveiligingswet, Austria: NISG, Belgium: NIS2-Wet). The duties are the same because the directive sets one EU-wide standard. What differs: deadlines, reporting channels, which agency you talk to.
We have cyber insurance, so we are covered.
The BSI is blunt: 'A blanket risk transfer or general risk acceptance is therefore excluded.' Insurance is something you add on top of risk treatment, not a replacement. You also cannot just 'accept' every risk you do not want to deal with. That argument will not survive an audit.
We can do the risk analysis without listing our assets.
You cannot. CIR §2.1 does not work without a written list of what you actually have. Applications, systems, sites, data, suppliers. IT-Grundschutz lets you bundle identical assets together (45 office laptops count as one entry with a quantity), so the list does not have to be huge. But it has to exist.
We decide what we accept case by case.
An auditor needs to see the criteria you set before the incident, not after. Decide in advance: at what threshold do you accept a risk, at what threshold do you fix it, at what threshold do you transfer it (e.g. via insurance). Those criteria belong in the framework, not in a post-hoc email.
Article 21(1) gives you room with the proportionality clause: what you do must match your size, your risk exposure, and what it costs. The directive itself does not expect you to do everything at maximum depth on day one.
What we see practitioners do in the German Mittelstand: a gap assessment first, then the twelve to fifteen most urgent measures inside the first year, then the rest spread over the next year or two. That holds up under Article 21(1) as long as the phasing is written down, justified by your risk picture, and signed off by the management body. It will not hold up if the phasing is undocumented or if you skipped the highest risks.
We built the §2 CIR framework into the platform as a module. You record risks against assets, score likelihood and impact, route each one into a treatment plan, and capture the acceptance criteria with a signed sign-off. No spreadsheet pile. No second tool.
The §2.2 monitoring part falls out of using the platform: sign-offs, task status, audit trail. You do not maintain a separate compliance log. The §2.3 independent review can run internally (a colleague who is not in the chain) or externally (a hired auditor). Either way, we give them the read-only view they need.
- Directive (EU) 2022/2555 (NIS 2), Article 21 — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex §1 and §2 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI Act (BSIG), §30 as amended by the NIS2 Implementation and Cybersecurity Strengthening Act
- BSI Infopakete 'NIS 2 Pflichten' — bsi.bund.de/dok/nis-2-infopakete
- ENISA Technical Implementation Guidance for CIR (EU) 2024/2690 (as of May 2026)