NIS2 Section 30 BSIG: All 10 Obligations in One Overview

All 10 obligations in 1 table

This page is the entry point: § 30(2) BSIG names ten areas of measures that every particularly important and every important entity must cover — the following table lists all ten with the German and the Austrian legal reference and a short status, and each row leads to the matching section of the in-depth guide. The basic rule is set out in § 30(1) BSIG: appropriate, proportionate and effective technical and organisational measures to prevent disruptions to the availability, integrity and confidentiality of IT systems and to keep the impact of security incidents low; compliance must be documented. Added to this is the quality benchmark of § 30(2) sentence 1 BSIG: 'Measures under subsection 1 should comply with the state of the art, take account of the relevant European and international standards, and must be based on an all-hazards approach.' The Act therefore does not contain a rigid minimum list — but each of the ten areas must be addressed, and the depth of implementation scales with the risk.

Overview or in-depth guide? This article is the overview with a short explanation and the key actions per area; the in-depth guide with ISO 27001 mapping (Annex A) and the 22 templates from implementation practice is Section 30 BSIG: 10 NIS2 Mandatory Measures for Companies Explained.

Practitioner reading of the all-hazards approach: the catalogue is not exhausted by defending against attacks — business continuity and crisis management (area 3) as well as personnel security and access control (area 9) rank equally alongside cryptography (area 8) and authentication (area 10). A risk analysis from area 1 that only considers attack scenarios leaves these areas unevidenced.

On how to read the columns: the Austrian references follow the same order as the German numbering ((a) to (j) correspond to no. 1 to 10). The short status indicates where, experience shows, a company certified to ISO 27001 still has to improve — it is an assessment, not a legal statement. Which topics of ISO/IEC 27001:2022 Annex A apply per area is shown in the ISO 27001 mapping in the in-depth guide; it does not replace a review of your own certification scope.

Who has to meet the 10 obligations — and what happens in case of breaches

In brief: in Germany, Section 30 BSIG applies to particularly important and important entities; which organisation falls into these categories is determined by § 28 BSIG through the combination of type of entity (Annex 1, or Annex 1 or 2) and size, and operators of critical installations, among others, are covered irrespective of size. According to the BSI, the scope covers around 29,500 entities. Registration takes place at the latest three months after first classification via the joint registration facility of the BSI and the BBK (§ 33(1) BSIG); the BSI points out that the statutory registration deadline has already expired, and there is no official date for the start of supervisory and fining practice. Breaches of the risk management and reporting obligations may be sanctioned with a fine of up to EUR 10 million (particularly important) or EUR 7 million (important entity) (§ 65(5) sentence 1 no. 1 BSIG); the management body must implement the measures, supervise their implementation and is liable to its own entity for culpably caused damage (§ 38(1) and (2) BSIG). Thresholds and classification pitfalls, the turnover variant of the fines and the liability details are covered in the in-depth guide: who has to implement the 10 areas, sanctions and management.

1. Risk management system

Area 1 requires policies on risk analysis and on the security of information systems (§ 30(2) no. 1 BSIG) — in practice the ISMS foundation on which the other nine areas build. Specifically, this includes: a defined methodology (e.g. ISO 27005), a risk register with assessed risks, a risk treatment plan and an ISMS policy. It is common practice to have the policy approved by the management body. Why this comes first: § 30(1) BSIG requires proportionate measures and their documentation — without a documented risk analysis, it is impossible to justify to the supervisory authority why the depth of implementation in area 4 or 10 was chosen as it was. This responsibility cannot be delegated: under § 38(1) BSIG, the management body must implement the measures and supervise their implementation. Practitioner recommendation (rhythm from implementation practice): an annual update of the risk analysis and a documented treatment decision for every risk. In Austria, the obligation is set out in § 32(4)(a) NISG 2026 (applicable from 1 October 2026).

2. Incident response

Area 2 requires incident handling (§ 30(2) no. 2 BSIG) — and because the reporting obligations hang on it, it is the most time-critical of the ten. The reporting trigger is the significant security incident under § 2 no. 11 BSIG: an incident that has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or that has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. In Germany, a three-stage mandatory scheme then applies vis-à-vis the joint reporting office of the BSI and the BBK, plus an intermediate report upon request (§ 32(1) no. 1 to 4 BSIG): an early warning without undue delay, at the latest within 24 hours of becoming aware; a report with an initial assessment at the latest within 72 hours; an intermediate report at the request of the BSI; a final report at the latest one month after the 72-hour notification. If the incident is still ongoing at that point, a progress report initially takes its place; the final report then follows after the incident has been finally handled (§ 32(2) BSIG). The 24 hours run from becoming aware, not from the start of the incident — organisational consequence: the reporting chain should also be reachable outside business hours so that the deadline can be met. Practitioner recommendation: an incident response plan, a designated crisis team, prepared reporting templates and tabletop exercises. In Austria: § 32(4)(b) NISG 2026, reporting to the competent sector-specific CSIRT, otherwise to the national CSIRT (§ 34(1)), deadlines under § 34(2) no. 1 to 5 NISG 2026.

3. BCM + DR

Area 3 requires 'business continuity, such as backup management and disaster recovery, and crisis management' (§ 30(2) no. 3 BSIG). Five artefacts carry this area in practice: a business impact analysis as the basis, a business continuity plan with RTO and RPO per business process, a backup strategy following the 3-2-1 principle or equivalent, a disaster recovery plan with a tested restoration routine, and a crisis management plan including internal and external communication. Why the test counts: § 30(1) BSIG requires effective measures — in practice, a recovery plan that has never been tried out can hardly be evidenced as effective vis-à-vis a supervisory authority, and RTO/RPO remain figures without backing in the absence of a test run. Practitioner recommendation (rhythm from implementation practice): at least annual DR tests with a documented result; the recovery time from the test is also suitable as a KPI for area 6. In Austria, the obligation is set out in § 32(4)(c) NISG 2026.

4. Supply chain security

Area 4 requires supply chain security (§ 30(2) no. 4 BSIG) — that is, documented due diligence towards service providers and suppliers. Four building blocks: a supplier inventory with risk classification, cybersecurity clauses in the standard contracts, a right to audit for critical suppliers, and a contractual obligation on the supplier to report security incidents to you as the client (practitioner recommendation: a contractual deadline of no more than 24 hours, so that your own 24-hour notification under § 32(1) no. 1 BSIG remains tenable). What belongs in the cybersecurity clause (practice): the security requirements imposed on the supplier, its obligation to report security incidents including the deadline, and the audit right for critical suppliers — without these three points, the supplier's risk classification remains without consequence. Where the supplier additionally processes personal data on your behalf, the data processing agreement under Art. 28(3) GDPR with its statutory minimum content applies in addition; it governs data protection, and in practice the four building blocks of this area are to be kept separate from it. Practitioner recommendation: concentrate audits on the top 20 suppliers by criticality instead of a full survey; what audits in this area typically start from is set out in the FAQ on the most frequent audit findings. In Austria: § 32(4)(d) NISG 2026.

5. Secure system acquisition + maintenance

Area 5 requires security in the acquisition, development and maintenance of IT systems (§ 30(2) no. 5 BSIG) — it therefore covers the entire lifecycle, not just operation. Operationally, this means: patch management with defined deadlines per criticality, regular vulnerability scans (regular vulnerability scans at a frequency laid down in the patch policy), documented hardening standards for servers, clients and network components, and a vulnerability management process following the CVD model (Coordinated Vulnerability Disclosure) with a published vulnerability disclosure policy. The entity itself lays down the deadlines per criticality level in the patch policy and derives them from the risk analysis in area 1. Compliance with the measures must be documented under § 30(1) BSIG — without documented deadlines, proportionality cannot be justified to the supervisory authority. Those who develop in-house typically work along OWASP lines and anchor the security requirements as a requirements catalogue as early as procurement — as a specification in the requirements document and as a checklist in code review; requirements missing from the contract can, experience shows, hardly be demanded later. Why this counts: under § 30(2) sentence 1 BSIG, the measures should comply with the state of the art and take account of relevant European and international standards; this is precisely where that benchmark becomes operationally measurable. In Austria: § 32(4)(e) NISG 2026.

6. Effectiveness assessments for cybersecurity

Area 6 requires 'policies and procedures to assess the effectiveness of risk management measures in the field of information technology security' (§ 30(2) no. 6 BSIG) — that is, evidence that the measures from the other nine areas actually take effect. This becomes measurable through KPIs per area, such as the patch compliance rate, the phishing click rate and the actual recovery time from the DR test. Practitioner recommendations (rhythms from implementation practice): quarterly reporting to the management body, an annual penetration test, an annual internal audit and an external audit every two years; an ISO 27001 audit comes on top optionally. To be distinguished from this is the evidence provided to the supervisory authority. In Germany, the regular obligation to provide evidence primarily applies to operators of critical installations: they demonstrate implementation at a point in time determined by the BSI — at the earliest three years after they first qualify as an operator — and subsequently every three years by means of security audits, examinations or certifications, and transmit the results including any security deficiencies identified (§ 39(1) BSIG). Austria regulates this more broadly: all essential and important entities transmit a structured self-declaration within twelve months of the registration obligation arising; upon request, implementation must be evidenced within two years by an independent body, and essential entities must demonstrate operational and organisational implementation within as little as two months of the request (§ 33(1) and (2) NISG 2026). The area of measures itself is set out there in § 32(4)(f) NISG 2026.

7. Training + awareness

Area 7 requires 'basic training and awareness measures in the field of information technology security' (§ 30(2) no. 7 BSIG). The common term 'cyber hygiene' does not come from the BSIG but from Art. 21(2)(g) of the NIS2 Directive (Directive (EU) 2022/2555) ('basic cyber hygiene practices and cybersecurity training'). Practitioner recommendations (rhythms from implementation practice): annual cybersecurity training for all employees with a learning check, quarterly phishing simulation with click-rate monitoring as a metric for area 6, onboarding training for new employees within the first four weeks, and a sector-specific deep dive where the risk sits (for example SCADA training in industry). What works as evidence: a learning check in the form of a quiz at the end of the training, the result of which is recorded per participant — this documents both participation and understanding; which findings audits typically trigger here is set out in the FAQ on the most frequent audit findings. To be kept separate from this is the training obligation at management level: under § 38(3) BSIG, management bodies must themselves take part in training regularly; in Austria, § 31 NISG 2026 requires specifically designed cybersecurity training for the management bodies and regular training offers to employees. The area of measures itself is set out there in § 32(4)(g) NISG 2026.

8. Cryptography + encryption

§ 30(2) no. 8 BSIG requires 'policies and processes for the use of cryptographic methods' — that is, a cryptography policy that names the approved algorithms and key lengths (BSI TR-02102) and works through the use cases. The provision does not prescribe which standards the policy lays down for each use case. Common determinations from practice: data in transit with TLS 1.3 in accordance with BSI TR-02102 and end-to-end HTTPS; data at rest with AES-256 for storage media and backups; email security with S/MIME or PGP for sensitive communication; key management via an HSM or an equivalent key management system. Added to this is preparation for post-quantum methods on the basis of the 2024 NIST standards — a point that a cryptography policy today should at least name as a migration path. Why the effort pays off twice: under Art. 34(3) GDPR, notification of the data subjects in the event of a personal data breach may be dispensed with where appropriate technical protection measures — in particular encryption — have been applied; the notification to the supervisory authority under Art. 33 GDPR follows its own conditions. In Austria: § 32(4)(h) NISG 2026.

9. Personnel security, access control + asset management

§ 30(2) no. 9 BSIG combines three topics: 'security of personnel, access control and … the management of ICT systems, products and processes'. In practice, this means: reliability screening, confidentiality agreements and structured on-/offboarding (personnel); an authorisation concept based on least privilege, IAM, PAM for privileged access, conditional access and regular recertification (access control); asset inventory, classification, BYOD policy and EOL management (management of ICT systems).

Two artefacts carry this area: the authorisation concept based on the need-to-know principle and a maintained asset inventory — without an inventory, neither the scope of the ISMS from area 1 can be drawn cleanly nor the patch management from area 5 rolled out in full. Practitioner recommendation: implement privileged access (PAM) via separate admin accounts kept apart from the day-to-day user, with logged sessions and time-limited assignment of rights; recertify privileged authorisations every six months and all others annually, in each case with a documented result; in addition, an offboarding workflow that records the withdrawal of all access on the last working day.

Practitioner recommendation on the terms that most frequently remain without an artefact in audits: EOL management operationally means a list of systems with the manufacturer's end-of-support date and a decision per system before expiry — replacement, extension or a documented compensating measure. Conditional access ties access to device status, location or network segment and comes into play where external access from area 10 meets systems worth protecting. The BYOD policy should lay down which data classes are permissible on private devices at all — without this determination, the classification remains without consequence. Reliability screening, too, remains without consequence unless tied to roles — practitioner recommendation: name the roles with access to systems worth protecting in the risk analysis from area 1, clarify the permissible depth of screening per role in advance under employment law, and document the screening result with a date in the personnel file. In Austria: § 32(4)(i) NISG 2026.

10. Secure authentication + communication

§ 30(2) no. 10 BSIG requires 'multi-factor authentication or continuous authentication' as well as secured voice, video and text communication and — where necessary — secured emergency communication; the provision therefore allows both authentication routes, and the choice, together with its justification, belongs in the documentation under § 30(1) BSIG. Practitioner recommendation: expressly assign one of the two routes to each class of account instead of leaving the decision open — the assignment and its justification are the evidence. Common practice: MFA for all admin accounts and all external access such as VPN and cloud services — FIDO2/passkey, for instance, come into consideration as methods there; for pure employee office use, a risk-based gradation can be justified, provided the justification is documented in the risk analysis from area 1. The second part of the provision deserves attention of its own: emergency communication must hold up even when the primary environment is compromised. Practitioner recommendation: test emergency communication together with the crisis management plan from area 3, otherwise it remains on paper. In Austria: § 32(4)(j) NISG 2026.

Austria: the same catalogue, a different act

Note on Austria: the substantively identical catalogue of measures is set out there not in the BSIG but in § 32(4)(a) to (j) NISG 2026 (BGBl. I Nr. 94/2025); the supervisory authority is the Cybersecurity Authority (Cybersicherheitsbehörde, Austria). This article follows the German numbering of Section 30 BSIG.

Four differences are relevant for implementation. First, the timetable: the Austrian Network and Information Systems Security Act 2026 (NISG 2026) was promulgated on 23 December 2025 and becomes applicable on 1 October 2026 — nine months after promulgation, on the first day of the following month (§ 51(1) and (2) NISG 2026); from that day, the risk management obligations of § 32 apply. Second, registration: it takes place with the Cybersecurity Authority within three months of entry into force (§ 29(2) and (3) NISG 2026), that is by the end of 2026; changes to the core data must be reported within two weeks (§ 29(4)). Groups with German and Austrian companies must register separately in both countries. Third, the authority architecture: the competent body is the Federal Office for Cybersecurity (Cybersicherheitsbehörde, Austria), an authority directly subordinate to the Federal Minister of the Interior with nationwide competence and its seat in Vienna (§ 3a(1) and (2), § 3b(3) NISG 2026); administrative penalties, by contrast, are imposed by the district administrative authority (§ 44(1)) — for administrative offences under § 45(1) up to EUR 10 million or 2 % of worldwide annual turnover for essential entities and up to EUR 7 million or 1.4 % for important entities, whichever amount is higher (§ 45(2) and (3)), other offences up to EUR 50,000 and in the case of repetition up to EUR 100,000 (§ 45(4)). Fourth, management responsibility: § 31 NISG 2026 obliges the management bodies to ensure and supervise compliance with the risk management measures, but does not contain an express internal liability rule analogous to § 38(2) BSIG.