NIS2 Risk Management Template: 10 Mandatory Measures Art. 21

Main article: NIS2 Guide 2026 — obligations, fines and roadmap at a glance. This page goes deeper into risk management: methodology, template and evidence.

Article 21 of the NIS2 Directive is the centrepiece of the regulation. It requires essential and important entities to take "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems". Germany has transposed this in § 30(1) and (2) of the BSIG, Austria in § 32 NISG 2026. This page shows how a risk management template should be structured so that it is traceable in an audit, which methodology lends itself to the task and which risks are typical per sector. The implementation plan for Germany can be found under NIS2 Implementation Germany.

1. What does Article 21 NIS2 Directive actually require?

Paragraph 1 sets out the principle: the measures must be appropriate and proportionate and, taking into account the state of the art, ensure a level of security appropriate to the existing risk. Proportionality is measured by risk exposure, the size of the entity, the likelihood of occurrence and the severity of incidents, including their societal and economic impact. That is a test of appropriateness, not a maximum standard.

German transposition: § 30(1) BSIG obliges particularly important and important entities to take appropriate, proportionate and effective technical and organisational measures; when assessing proportionality, the implementation costs must also be taken into account, and compliance must be documented. Under § 30(2) sentence 1 BSIG, the measures should comply with the state of the art and take the relevant European and international standards into account. In terms of terminology: what the Directive calls "essential" entities are called "particularly important entities" in the BSIG.

Paragraph 2 names the catalogue that every risk management template must cover: the measures are based on an all-hazards approach that also includes the physical environment of the systems, and comprise "at least" the ten areas of points (a) to (j). The all-hazards approach is also required by § 30(2) sentence 1 BSIG, the minimum catalogue ("at least") by § 30(2) sentence 2 BSIG. The catalogue is a minimum content, not an exhaustive list. For operators of critical installations (KRITIS), the special requirements of § 31 BSIG are added, including systems for attack detection (§ 31(2) BSIG).

Paragraph 3 specifies the supply chain: the specific vulnerabilities of the direct suppliers, the overall quality of their products and their cybersecurity practices must be taken into account. Paragraph 4 requires corrective measures without undue delay as soon as an entity finds that it does not comply with the measures under paragraph 2. The improvement cycle that a template maps through review dates and measure status ties in with this.

Special case of digital entity types: for DNS service providers, TLD name registries, cloud computing and data centre services, content delivery networks, managed (security) service providers, online marketplaces, search engines, social networks and trust service providers, Commission Implementing Regulation (EU) 2024/2690 lays down the technical and methodological requirements; for these entity types it takes precedence (§ 30(3) BSIG).

2. The 10 measure areas (a) to (j) at a glance

The ten areas are explained in detail on § 30 BSIG: 10 mandatory NIS2 measures (with ISO 27001 mapping) and in the overview table on § 30 BSIG. This page therefore only gives the mapping: Directive, German and Austrian law, the corresponding template in the NIS2 Kit and further reading. Point (a), the risk analysis, is the core of this page and follows in detail from section 3.

Two points on the legal position that a template should reflect correctly (audits and evidence for point (f): section 7):

• Reporting scheme (point b): early initial report within 24 hours, report within 72 hours, final report no later than one month after the 72-hour report, each to the joint reporting office of the Federal Office for Information Security (BSI) and the Federal Office of Civil Protection and Disaster Assistance (BBK) (§ 32(1) BSIG); the obligation applies at the earliest from the time the reporting channel has been set up. 24/7 availability of the crisis team is not a statutory obligation, but a practice recommendation so that the deadline running from awareness can be met.
• Training records (point g): the BSIG sets no retention period for training records. What is regulated by law is the regular training participation of management (§ 38(3) BSIG). How long you retain records is something you determine internally and justify.

3. Risk analysis methodology: BSI 200-3 vs. ISO/IEC 27005

Neither Article 21 NIS2 Directive nor § 30 BSIG prescribes a specific methodology. What is required is a risk-based, all-hazards approach that complies with the state of the art and takes the relevant European and international standards into account (§ 30(2) sentence 1 BSIG). In practice, two routes have become established:

What matters is the documented choice and its consistent application. Hybrid approaches are possible but must be justified. BSI Standard 200-3 itself stresses that its example matrix serves only as an illustration and is to be adapted to one's own needs. Anyone already certified under ISO/IEC 27001 will find the alignment with the NIS2 obligations under NIS2 + ISO 27001 certification.

4. Template structure: protection-needs analysis → threat analysis → risk matrix → action plan

Step 1: protection-needs analysis

For every material asset (system, data, business process), the protection need is classified in the dimensions confidentiality, integrity and availability — precisely the protection goals named in § 30(1) BSIG. BSI Standard 200-2 works with three protection-needs categories (normal, high, very high); anyone working under ISO/IEC 27005 determines the methodology and scales themselves. The result is a protection-needs matrix with one classification per asset and dimension. The basis is a complete asset inventory.

Step 2: threat and vulnerability analysis

For every asset with high or very high protection need, threats are identified (e.g. ransomware, insiders, compromised suppliers, natural events) and existing vulnerabilities recorded (e.g. missing MFA, outdated software, inadequate backups). The elementary threats of IT-Grundschutz are suitable as a starting catalogue. Ongoing sources for the threat analysis: the BSI situation report, the ENISA Threat Landscape, sector-specific CERT reports and your own incident history.

Step 3: risk assessment and risk matrix

For every combination of threat and vulnerability, the likelihood of occurrence and the extent of damage are rated; the product gives the risk score. The template works with a 5×5 matrix (five levels per axis); BSI Standard 200-3 recommends no more than five categories per dimension. The euro classes in the table are a practical example and must be adapted to the turnover and size of the entity.

The zones of the matrix are colour-coded:

• Green (very low/low): acceptance possible, keep monitoring the threat
• Yellow (medium): documented acceptance by management or treatment
• Red (high/very high): treatment required

Step 4: risk treatment plan (action plan)

Per risk: treatment option (avoid, reduce, transfer, accept), concrete measures, responsible persons, deadline, expected residual risk and an effectiveness indicator. The indicator links the plan to point (f): it shows that the measure is not merely planned but effective, as § 30(1) BSIG requires.

Step 5: residual-risk acceptance

After implementation, the residual risk is documented per risk. Accepted residual risks are recorded with reasons and a review date. Written acceptance by management is a practice recommendation; in legal terms, under § 38(1) BSIG management bears the obligation to implement the measures and to supervise their implementation.

In the NIS2 Kit: Module 03 contains the information security policy, the risk analysis methodology, the risk assessment matrix (Excel) and the risk treatment plan, Module 10 the asset inventory. The NIS2 Kit is available as a version for Germany or Austria, in the Basic package (66 documents) for EUR 990, Plus with training pack for EUR 1,390, Complete with e-learning for EUR 1,690, each net and one-off, with 12 months of legal-status updates, for businesses only.

5. Sample risks per sector

The following examples are an editorial selection as a starting point for step 2, not an exhaustive list.

IT service providers and SaaS providers

• Supply chain attack via a compromised open-source library
• Account takeover through phishing of privileged accounts
• Data exfiltration by insiders
• Cloud misconfiguration, such as publicly accessible storage
• Loss of availability through DDoS

For cloud, data centre and managed service providers, the technical and methodological requirements of Implementing Regulation (EU) 2024/2690 apply with precedence (§ 30(3) BSIG). Further reading: NIS2 for cloud providers and SaaS providers.

Energy supply (municipal utilities, grid operators)

• Attacks on SCADA and control systems
• Manipulation of smart meter communication
• Insider risks at remote maintenance access points
• Supply chain risks, for example with switchgear manufacturers
• Physical attacks on substations combined with cyberattacks

Further reading: NIS2 in energy supply.

Healthcare (hospitals, practices)

• Ransomware encrypting patient records and imaging
• Manipulation of medical devices
• Exfiltration of health data (special categories under Art. 9(1) GDPR)
• Outage of the telematics infrastructure
• Phishing via fake letters from billing offices

Further reading: NIS2 in healthcare.

Transport and logistics

• Attacks on telematics and fleet management systems
• Manipulation of traffic control systems
• GPS spoofing in logistics chains
• Supply chain disruption through ransomware at sub-suppliers
• Insiders in port logistics

Further reading: NIS2 in transport and logistics. Other sectors: mechanical engineering and OT security, water and waste, banks and financial services (DORA).

6. How often to update?

§ 30 BSIG does not set a fixed update cycle for the risk analysis. But because the measures should follow the state of the art (§ 30(2) sentence 1 BSIG) and the Member States must ensure that entities correct identified gaps without undue delay (Article 21(4) NIS2 Directive), the risk analysis is a living document. The following triggers are practice recommendations, not statutory deadlines:

• Annually: standard review as part of the ISMS management review (ISO 27001 practice)
• Material IT changes: new systems, cloud migration, architecture redesign
• New threats: BSI warnings, new attack techniques, sector-specific situation reports
• After incidents: transfer findings from the follow-up into the risk register
• Personnel changes: especially for privileged roles, in the crisis team and in management
• Regulatory changes: new supervisory requirements, changed thresholds, sector-specific regulations
• Supplier changes: especially for critical services (cloud, outsourcing, IT and telecommunications)

Every update is versioned, approved and archived; document control is part of the ISMS. How the cycle, internal audits and management review fit into a project plan is shown in Building an ISMS under NIS2.

7. Evidence in the audit

The basis for every audit is the documentation obligation of § 30(1) BSIG: all particularly important and important entities must document compliance with the measures. When the BSI audits depends on the class of entity:

• Particularly important entities: the BSI can order audits, inspections or certifications to be carried out by independent bodies (§ 61(1) BSIG).
• Important entities: the BSI acts on an event-driven basis where facts justify the assumption that obligations are not being implemented or not implemented correctly (§ 62 BSIG).
• Operators of critical installations: evidence at a point in time set by the BSI, at the earliest three years after the initial classification and every three years thereafter, through security audits, inspections or certifications (§ 39(1) BSIG).

For the risk analysis, the following evidence has proved its worth (practice recommendation):

1. Methodology document: which methodology (BSI 200-3 or ISO/IEC 27005), why it was chosen, who approves
2. Protection-needs analysis: current, covering all material assets
3. Threat and vulnerability analysis: current threat sources referenced
4. Risk register: versioned, linked to assessments and measures
5. Action plan: implementation status per measure
6. Residual-risk acceptance: approval by management for each medium residual risk
7. Management review minutes: documented engagement of management, at least annually
8. Effectiveness indicators: measurable indicators with trend development

Breaches of the risk management obligations can be sanctioned with fines of up to EUR 10 million for particularly important entities and up to EUR 7 million for important entities (§ 65(5) sentence 1 no. 1 BSIG); 2 % or 1.4 % of total worldwide turnover come into consideration only where total turnover exceeds EUR 500 million (§ 65(6) to (8) BSIG). The details and the Austrian values (§ 45(2) and (3) NISG 2026) can be found under Sanctions for breaches of § 30 BSIG; on the personal responsibility of management, see § 38 BSIG management liability.

Austria: § 32 NISG 2026 instead of § 30 BSIG

Austria (AT): for Austrian entities, it is not the BSIG that applies but the NISG 2026 (Federal Law Gazette (BGBl.) I No. 94/2025), whose §§ 2 to 45 have been applicable since 1 October 2026 (§ 51(2) NISG 2026). Essential and important entities must implement appropriate and proportionate risk management measures of a technical, operational and organisational nature (§ 32(1) NISG 2026); the minimum catalogue is set out in § 32(4)(a) to (j) and corresponds to the points of the Directive. The Austrian wording does not contain the criterion "effective" from § 30(1) BSIG. The management bodies must ensure and oversee compliance (§ 31(1) NISG 2026) and must take part in specifically designed cybersecurity training (§ 31(2) NISG 2026).

Particularly important for the template is the self-declaration: within twelve months of the registration obligation arising, entities submit structured information on the measures implemented to the Cybersecurity Authority (Federal Office for Cybersecurity), expressly including the results of the risk analysis carried out (§ 33(1) NISG 2026). On request, implementation must be demonstrated within two years by an independent body; essential entities must evidence the operational and organisational implementation within two months (§ 33(2) NISG 2026). The first such request is permissible at the earliest after two years have elapsed from the entry into force of the NISG 2026 (§ 33(2) last sentence NISG 2026). Significant cybersecurity incidents go to the competent CSIRT (§ 34(1) NISG 2026). More under NIS2 Austria (NISG 2026).