The 10 minimum measures under Section 30 BSIG

Section 30 of the BSIG is the operational core of German NIS2 law. It sets out exactly which measures affected organisations must implement as a minimum – not as recommendations, but as statutory obligations with direct implications for the fine framework under Section 65 BSIG. If you want to implement NIS2 in your organisation, this is where you start.

Section 30 BSIG at a Glance: Purpose, Structure, and Scope

Section 30(1) BSIG establishes the fundamental principle: affected organisations must implement "appropriate, proportionate and effective technical and organisational measures" to prevent disruptions to their network and information systems and to minimise the impact of security incidents. This transposes Article 21(1) NIS2 Directive into German law.

Section 30(2) nos. 1–10 lists the ten minimum measures. The word "minimum" (mindestens) is critical: the catalogue defines the statutory floor, not the ceiling. Depending on the sector, risk profile, and organisation type, the BSI may specify additional requirements through sectoral guidance documents.

The section applies to both organisation types – essential entities (bwE) and important entities (wE) – but with different supervisory intensity. The BSI audits essential entities proactively and without specific cause (§ 61 BSIG); important entities are monitored reactively upon incidents or indications (§ 62 BSIG).

The Proportionality Principle: What "Appropriate" Actually Means

Proportionality is not a blank cheque for smaller organisations to do nothing. It means the effort must match the actual risk. An organisation with 60 employees and straightforward IT infrastructure does not need the same measures as a critical infrastructure operator – but it must document a coherent, risk-based approach.

Practical rule: the proportionality principle only protects those who actively apply it. Without a risk analysis, you cannot justify your choice of measures as proportionate. No risk register – no basis for a proportionality argument when the BSI comes to audit.

How the BSI Frames the Ten Measures

At its April 2026 #nis2know webinar, the BSI presented the ten measures as a coherent catalogue with an explicitly stated common purpose. This matters because it shows how the supervisory authority itself reads Section 30(2) BSIG – as a bundle of measures serving a clearly defined protective objective, not as a checklist to be ticked off.

The objective of the risk management measures under Section 30 BSIG is "to prevent disruptions to the availability, integrity, and confidentiality of the information technology systems, components, and processes that affected entities use to deliver their services, and to keep the impact of security incidents as low as possible." (BSI #nis2know webinar, 7 April 2026, slide 8)

In practice, this has two consequences. First: all ten measures must work together towards this protective objective – cherry-picking individual items is incompatible with the BSI's reading of the law. Second: the objective frames proportionality. A measure may only be implemented at a low threshold if the shared objective – protecting confidentiality, integrity, and availability for service delivery – is not put at risk in the process.

A side note on terminology: the BSI uses both "cyber hygiene and training" (slide 8) and "training and awareness measures" (slide 19) for the same measure under Section 30(2) no. 7 BSIG. The legal text governs formal documentation; both BSI terms are acceptable synonyms.

The corresponding methodological framework – the PDCA cycle from BSI Standard 200-3, in which these ten measures take effect – is the subject of the in-depth article A-69 (The BSI PDCA Cycle in Practice).

The 10 Minimum Measures in Detail

No. 1 – Policies for Risk Analysis and Information Security

No. 1 is the foundation on which all other measures rest. It requires documented policies for risk analysis and information security: an information security policy formally approved and signed by management, and a defined process for regular risk analysis.

The most common mistake: an IS policy drafted internally by the IT team, without formal management sign-off. Section 38 BSIG explicitly requires management to approve security measures. An IS policy without a management resolution does not satisfy this requirement – and will not be accepted as evidence during a BSI audit.

No. 2 – Incident Handling

No. 2 requires a functioning incident management system: detection, classification, and response to security incidents, a documented escalation chain, defined communication processes, and systematic after-action review through post-mortem analyses.

The link to Section 32 BSIG is direct: without a functioning incident management system, no organisation can comply with the 24-hour early warning requirement. Article 21(2)(b) NIS2 Directive explicitly refers to "handling" of security incidents as a process – not as a document. An incident response plan that has never been exercised is worthless in a real incident.

No. 3 – Business Continuity, Backup Management, and Crisis Management

No. 3 is the broadest item in the catalogue: business continuity management, backup strategy, and crisis management. The most common implementation gaps:

• Backups without restoration testing: Backups are created but never tested for successful restoration.
• Missing recovery targets: RTOs and RPOs are not formally defined or documented.
• Conflating BCM and IT disaster recovery: Crisis management and IT recovery are treated as equivalent, even though BCM covers the entire organisation – not just IT.

The BSI expects that critical business processes have been identified through a business impact analysis, that concrete recovery targets have been set, and that these are regularly tested.

No. 4 – Supply Chain Security

No. 4 requires active engagement with the security of direct suppliers and service providers – one of the most consistently underestimated items in the catalogue, and one in which the BSI is showing increasing interest.

• Perimeter thinking: Security is defined only in terms of the organisation's own perimeter; suppliers are excluded from scope.
• No contractual requirements: Security requirements for suppliers are neither defined nor contractually anchored.
• Cloud as a black box: Cloud services are treated as the provider's sole responsibility, even though residual risk lies with the customer.

The law does not require real-time monitoring of all suppliers – but it does require documented assessments of critical suppliers with identified risks and defined minimum requirements.

No. 5 – Security in Procurement, Development, and Maintenance of Network and Information Systems

No. 5 covers vulnerability management and – where relevant – secure development and procurement requirements. For most SMEs this means: a documented patch management process with defined timelines based on CVSS severity, a complete asset inventory as the foundation, and a systematic process for handling known vulnerabilities.

"Procurement and development" also applies when acquiring new systems: security requirements should be part of every IT procurement process, from selection criteria to contractual obligations placed on vendors.

No. 6 – Assessment of the Effectiveness of Risk Management Measures

No. 6 is the qualitative link in the catalogue: organisations must regularly assess the effectiveness of their own measures. This does not mandate annual external audits – but it does require internal security reviews, penetration tests (where the risk profile justifies), and documented audit results.

Organisations that cannot produce effectiveness assessment results cannot demonstrate that their measures are working. The BSI specifically requests this evidence during audits.

No. 7 – Cyber Hygiene and Cybersecurity Training

No. 7 combines two requirements: basic cyber hygiene policies (password policies, secure use of endpoints, clean-desk rules, update processes) and training for the entire workforce.

The training obligation under No. 7 is broader than the mandatory management training under Section 38(3) BSIG. It covers the entire organisation. Cyber hygiene policies must be documented in writing – informally practised habits do not count in a regulatory context.

No. 8 – Policies and Procedures for the Use of Cryptography

No. 8 requires a documented cryptography policy: which algorithms are permitted, where encryption is mandatory (data in transit, data at rest for sensitive information), and how keys are managed.

Common mistake: TLS certificates exist, but there is no documented process for certificate management and key rotation. Outdated algorithms (MD5, SHA-1, TLS 1.0/1.1) are a concrete topic in BSI audits. The BSI aligns with its own cryptographic recommendations (BSI Technical Guideline TR-02102).

No. 9 – Personnel Security, Access Control, and Asset Management

No. 9 groups three related themes:

• Personnel security: Background checks for employees in sensitive positions, security commitments (NDAs, security declarations), and proper offboarding processes. The most common failure: former employees retain access – often for weeks or months after leaving.
• Access control: Identity management, the least-privilege principle, and regular access reviews. No organisation that intends to comply with Section 30 BSIG can operate without coherent access management.
• Asset management: A complete, current inventory of all IT assets. Without an inventory, there is no basis for patch management (No. 5), risk analysis (No. 1), or access control.

No. 10 – Multi-Factor Authentication and Secured Communication

No. 10 is the only item in the catalogue where the legislature specifies a concrete technology requirement: MFA or continuous authentication, plus secured communication channels within the organisation. MFA is therefore a statutory obligation, not an optional recommendation.

The phrasing "or continuous authentication" creates space for zero-trust approaches – risk-based, context-aware authentication – without excluding traditional MFA. In practice: privileged accounts, remote access, and critical systems require MFA in all cases. Low-risk internal systems have more flexibility – but that flexibility must be risk-justified.

What This Means in Practice

Three practical observations on implementing Section 30 BSIG:

First: the measures are not equivalent in priority. No. 1 (risk analysis) is the foundation – without it, there is no basis for any other decision. No. 6 (effectiveness assessment) is the link that turns a paper process into a living security system. Organisations that neglect these two will have a formal catalogue but no functioning security management.

Second: the BSI audits documentation, not intentions. Any measure that cannot be evidenced in writing is treated as not implemented. This is not bureaucratic overhead – it is the only way to demonstrate due diligence. Essential entities in particular should expect the BSI to actively request this evidence.

Third: implementation is a documented process, not a one-time investment. Section 30 BSIG does not require all ten measures to be fully implemented on day one – but it does require a coherent, progressing process with documented milestones. Organisations that begin today and document their progress systematically are in a substantially stronger position during a BSI audit than those who have done nothing.

For a structured self-assessment of which of the ten measures are implemented, in progress, or outstanding, the Gap Assessment Template (NIS2 Gap Assessment, Excel) is available. It includes an assessment column and evidence fields for each of the ten measures and is linked in the NIS2 Guide under Step 2-4.

Section 30 BSIG is the starting point for operational NIS2 implementation – but not the endpoint. The individual measures are explored in depth in the corresponding Knowledge Hub articles: risk analysis in A-03, B-03, and A-69 (the BSI PDCA cycle in practice), incident management in A-07 and B-09, BCM in A-13 and B-16, supply chain security in A-11, patch management in A-06, and MFA in A-05.

This article does not constitute legal advice. For questions about the specific legal classification of your situation, consult a lawyer specialising in IT law.