Last updated: 2026-11-06
Risk analysis and security policy are the first of the ten measures in Section 30(2) of the German BSI Act (BSIG), which transposes Article 21 of the NIS2 Directive (EU) 2022/2555 for essential entities (in Germany: besonders wichtige Einrichtungen) and important entities (wichtige Einrichtungen). All ten measures at a glance are on the Section 30 BSIG page, the order of implementation in the action plan. Legal status: BSIG as amended on 22 October 2026. This page is general information, not legal advice.
What does Section 30(2) no. 1 BSIG require?
The act requires “policies on risk analysis and on the security of information technology” (Section 30(2) sentence 2 no. 1, our translation). The NIS2 Directive uses almost the same words in Article 21(2)(a): “policies on risk analysis and information system security”.
The point does not stand alone. It puts into concrete terms the basic duty in Section 30(1): appropriate, proportionate and effective technical and organisational measures to prevent disruption to the availability, integrity and confidentiality of the IT systems, components and processes the entity uses to provide its services. Three further requirements of Section 30 determine what the risk analysis must look like:
- Proportionality (subsection 1 sentence 2): account must be taken of risk exposure, the size of the entity, implementation costs, the likelihood and severity of security incidents and their societal and economic impact. A risk analysis supplies exactly these figures.
- Documentation (subsection 1 sentence 3): compliance must be documented.
- All-hazards (subsection 2 sentence 1): the measures must be based on an all-hazards approach; they should reflect the state of the art and take relevant standards into account.
The duty has applied since 6 December 2025 with no general transition period, whether or not the entity has registered with the BSI.
How should the duty be interpreted?
The method is free. The BSI states that entities are free to choose their risk analysis methodology. It recommends following existing standards, such as BSI Standard 200-3 or ISO 27001. IT-Grundschutz is not mandatory for NIS2 implementation.
According to the BSI info package, a risk analysis in the sense of NIS2 includes:
- Understand the context: company, scope, stakeholders and their requirements.
- Record assets and identify risks: business processes, information, applications, systems and rooms that need protection; threats and vulnerabilities.
- Assess risks: categories for likelihood and impact, assessment criteria, acceptance criteria, risk owners.
- Treat risks: avoid, reduce, transfer or accept; each measure has a responsible person.
- Document: record the results in a traceable way.
- Review regularly: after organisational changes, after security incidents and at fixed intervals.
Two points set the NIS2 risk analysis apart from a pure ISO exercise. First, Section 30 applies to the entire entity; a freely chosen, narrow scope is not enough. Second, the BSI points out that ISO 27001 allows risk acceptance or transfer, while the BSIG requires appropriate, effective and proportionate measures to be implemented. Merely accepting a risk should therefore be the exception, reasoned and decided by management.
On the second part of the point, the security policy: this means the overarching information security policy. It sets objectives, responsibilities and resources, and the risk analysis shows where it needs to apply.
What does Implementing Regulation (EU) 2024/2690 add?
For eleven digital entity types, such as cloud providers, data centres and managed service providers, Implementing Regulation (EU) 2024/2690 takes precedence under Section 30(3) BSIG; which types these are is listed in the sector directory. Its annex covers no. 1 in two chapters:
| Annex point | Content (summarised) |
|---|---|
| 1.1.1 | Security policy with approach, objectives, commitment to improvement and resources, roles, documents to be kept, topic-specific policies, indicators and the date of approval by the management bodies |
| 1.1.2 | Review of the policy by the management bodies at least annually and after significant incidents or major changes |
| 2.1.1 | Risk management framework; document the risk assessment; draw up, implement and monitor a risk treatment plan; results and residual risks are accepted by the management bodies or authorised persons |
| 2.1.2 | Methodology, risk tolerance threshold, risk criteria; identify risks on an all-hazards basis, including risks relating to third parties and single points of failure; analyse, assess and treat them; owners and deadlines; explain the reasons for residual risks |
| 2.1.4 | Review the risk assessment and treatment plan at least annually and after major changes or significant incidents |
According to the recitals of the regulation, accepting a risk should only be considered in exceptional cases. An entity that does not apply a requirement that only applies “where appropriate” must document the reasons in an understandable way (Article 2(2)). For all other entities the regulation is voluntary; it still describes well what a traceable risk analysis contains. The example below therefore follows it.
Which ISO 27001 requirements correspond to no. 1?
In ISO/IEC 27001:2022, risk assessment sits in the main body of the standard, not in Annex A. The following mapping is our own assessment; so far the BSI has only published an official mapping for the supply chain. The comparison of ISO 27001 and NIS2 as a whole is on the page NIS2 and ISO 27001.
| Element of no. 1 | ISO/IEC 27001:2022 | Note for NIS2 |
|---|---|---|
| Risk assessment | clauses 6.1.2, 8.2 | scope must cover the whole entity |
| Risk treatment | clauses 6.1.3, 8.3 | acceptance only with reasons and as an exception |
| Security policy | clause 5.2; A.5.1 (policies) | approval and review by management |
| Roles and responsibilities | clause 5.3; A.5.2 (roles) | direct reporting line to management |
| Recording and classifying assets | A.5.9 (inventory), A.5.12 (classification) | include production equipment and OT |
| Threats and vulnerabilities | A.5.7 (threat intelligence), A.8.8 (technical vulnerabilities) | take BSI warnings into account |
| Review | clause 9.3; A.5.35 (independent review) | at least annually for entities under the Implementing Regulation |
If you work with IT-Grundschutz: how NIS2 and Grundschutz++ relate is explained on the sister site NIS2 and Grundschutz++ on grundschutz-readiness.de (German).
Which evidence is suitable?
There is no prescribed evidence package, and evidence is only due when the BSI orders it. Suitable evidence examples, by origin:
| Origin | suitable evidence examples |
|---|---|
| Legal obligation (Section 30(1) sentence 3) | documentation that the measures have been taken; the form is not prescribed |
| Obligation only for entities under the Implementing Regulation | security policy with approval date; documented risk assessment; risk treatment plan with owners and deadlines; reasons for residual risks; evidence of the annual review |
| Professional recommendation (BSI info package) | described method with assessment and acceptance criteria; list of assets and processes; risk register; assignment of risk owners |
| Blackfort example | the completed risk analysis below with management approval and a date for the next review |
Example: risk analysis of an industrial bakery
Fictitious example, not a client. An industrial bakery with 220 employees supplies retail chains. As a food business in industrial production, it falls under Annex 2 and is an important entity. Three production lines are controlled from a control room, orders from retail customers arrive via EDI through a service provider, and the cold stores are monitored electronically. IT consists of two people, payroll is handled by an external provider, and the machine manufacturers maintain the lines via remote access.
Assumptions for the assessment: a supply outage of more than 24 hours puts contracts with the retail chains at risk. Recipes are trade secrets.
Work product: completed risk analysis
1. Method and criteria (based on BSI Standard 200-3, simplified)
| Level | Likelihood (L) | Impact (I) |
|---|---|---|
| 1 | rare: less than once every five years | minor: disruption under 4 hours, no customer impact |
| 2 | possible: every one to five years | noticeable: disruption up to 24 hours or rework |
| 3 | likely: about once a year | severe: supply outage over 24 hours, loss of trade secrets |
| 4 | frequent: several times a year | threatening the business: outage over one week, loss of key customers |
Risk = L × I. Levels: 1-3 low, 4-6 medium, 8-9 high, 12-16 very high. Risk tolerance: residual risks up to “medium” are accepted by the head of IT with reasons; residual risks “high” and “very high” are decided by management, only for a limited period and with interim measures.
2. Risk register and treatment plan
| No. | Asset or process | Threat and vulnerability | L × I = risk | Treatment (Section 30(2) point) | owner, deadline | Residual risk |
|---|---|---|---|---|---|---|
| R1 | ERP and merchandise management | ransomware via phishing; no MFA for email, backups in the same network | 3 × 4 = 12 very high | reduce: MFA (no. 10), separate backup and recovery test (no. 3), training (no. 7) | head of IT, 31 March 2027 | 2 × 3 = 6 medium |
| R2 | control room and line control | malware from the office network; office and production networks not separated | 2 × 4 = 8 high | reduce: network separation with firewall (no. 9), practise emergency operation without control room (no. 3) | head of production with IT, 30 June 2027 | 1 × 4 = 4 medium |
| R3 | remote maintenance by machine manufacturers | misuse of access; VPN permanently open, without MFA, without logging | 3 × 3 = 9 high | reduce: access only on request, MFA, logging, contract clause (nos. 4, 10) | head of IT, 31 January 2027 | 1 × 3 = 3 low |
| R4 | recipe database | leak by former employees; permissions not revoked on departure | 2 × 3 = 6 medium | reduce: leaver process, access review every six months (no. 9) | head of HR with IT, 31 December 2026 | 1 × 3 = 3 low |
| R5 | cold store monitoring | failure of the monitoring server; no redundancy, alarm only on screen | 2 × 3 = 6 medium | reduce: additional alarm via mobile network, spare device (no. 3) | engineering, 28 February 2027 | 1 × 2 = 2 low |
| R6 | EDI orders from retail customers | outage of the EDI provider; no fallback, no reporting duty in the contract | 2 × 3 = 6 medium | reduce: fallback via customer portals, contract with reporting duty (nos. 3, 4) | sales with IT, 31 March 2027 | 2 × 2 = 4 medium |
| R7 | payroll at the service provider | data leak at the provider; security level unknown | 2 × 2 = 4 medium | reduce: supplier questionnaire, contract review (no. 4) | head of HR, 31 December 2026 | 1 × 2 = 2 low |
| R8 | line 3 control computer | malware; operating system without security updates, replacement only possible in 2027 | 3 × 3 = 9 high | reduce: isolate the computer from the network, block USB (nos. 5, 9); order the replacement | head of production, replacement 30 September 2027 | 2 × 3 = 6 medium until replacement |
3. Approval and review
| Field | Sample value |
|---|---|
| Prepared | information security officer with head of IT and head of production, 30 September 2026 |
| Approval of residual risks | management, 12 October 2026; R8 limited until replacement, interim measures adopted |
| Next review | 30 September 2027, earlier after a significant incident, a new line or a new service provider |
| Storage | ISMS folder, version 1.0, changes dated |
The register shows why the analysis should start from the business process: two of the three highest risks lie in remote maintenance and a legacy machine in production, with ransomware via the office network as the third. A view limited to office IT would have missed two of them. R3 and R6 concern service providers; how to assess them is shown on the page supply chain security.
Three typical gaps
| Gap | Cause | Effect | Remedy |
|---|---|---|---|
| Analysis covers office IT only | The analysis is approached from IT; production and service providers are missing. | The largest risks remain unassessed; Section 30 applies to the entire entity. | start from business processes, include production and service providers |
| Risks accepted instead of treated | Habit from ISO projects of simply accepting risks that are costly to treat. | The BSIG requires measures; acceptance without reasons is hard to defend. | acceptance only time-limited, reasoned, with an interim measure and a management decision |
| Prepared once, never updated | The analysis was a project deliverable without a review date. | After incidents or changes it no longer fits, and measures address the wrong points. | fixed review date, define additional triggers, keep version and date |
How Blackfort Technology helps
We carry out the risk analysis with your departments in workshops, assess production, IT and service providers together and deliver the register, treatment plan and a decision paper for management. The starting point is the NIS2 gap analysis.
Frequently asked questions
Does NIS2 prescribe a specific method for the risk analysis?+
How often does the risk analysis have to be updated?+
Is the risk assessment from our ISO 27001 ISMS enough?+
Who has to approve the risk analysis?+
Do we have to include production equipment and OT in the risk analysis?+
Read more
Sources
- Section 30 BSIG: risk management measures (gesetze-im-internet.de, German) (retrieved 2026-11-06)
- NIS2 Directive (EU) 2022/2555, Article 21 (retrieved 2026-11-06)
- Implementing Regulation (EU) 2024/2690, Article 2 and Annex points 1 and 2 (retrieved 2026-11-06)
- BSI: info package “NIS‑2 Risikoanalyse” (German) (retrieved 2026-11-06)
- BSI: one-pager “ISO/IEC 27001 im Kontext NIS‑2/BSIG”, version 1.0 of 1 April 2026 (German) (retrieved 2026-11-06)
- BSI: general NIS‑2 FAQ (IT-Grundschutz not mandatory, evidence on order; German) (retrieved 2026-11-06)
This content provides general technical and organisational information and does not constitute legal advice (no legal services within the meaning of the German RDG).