Germany's NIS2 Act: The Board-Level Action Plan

No Future Deadline Left

Most compliance topics arrive with a comfortable lead time. For NIS2 in Germany, that is over. The NIS2 implementation act (NIS2UmsuCG) was promulgated on 06 December 2025 and has been in force since — without the transition period many organizations had planned around. The BSI registration deadline already passed on 06 March 2026. Anyone only starting to assess the topic now is assessing not a future obligation, but one that already applies.

According to the estimates underlying the legislation, around 29,500 organizations in Germany are covered by NIS2 — a multiple of the previous critical-infrastructure population. Many do not know they are affected, because NIS2 no longer addresses only classic critical infrastructure but broad economic sectors via size and revenue thresholds.

We deliberately approach NIS2 here not from the legal but from the delivery and IT governance perspective. Case-specific legal assessment belongs with a law firm. The question we hear most often from clients is different: what do these obligations mean concretely for our delivery pipeline, our processes, and the demonstrability of our decisions? That is what this roadmap answers.

The most important sentence up front: NIS2 is not a pure security topic to be handed to the CISO. Under the NIS2UmsuCG, liability for the risk management measures lies with management — personally and non-delegably. That fundamentally changes who must own this topic.

Self-Check: Am I Even Affected?

The first and most consequential mistake is the tacit assumption that NIS2 only affects energy utilities, hospitals, and telecom providers. The NIS2UmsuCG distinguishes two categories: essential entities and important entities. Classification follows from sector membership combined with company size — and the sector list is significantly broader than under the old NIS directive.

As rough orientation: organizations active in a covered sector that exceed the thresholds of a medium-sized enterprise (simplified: at least 50 employees, or more than EUR 10 million annual revenue and balance sheet total) are very likely covered by NIS2. For certain sectors, classification applies regardless of size. The authoritative test is a case-by-case assessment of the specific business model — the quick check below does not replace it, it prioritizes it.

1. 1Check sector membership: Are you active in energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, or space (essential sectors)? Or in postal/courier, waste management, chemicals, food, manufacturing, digital providers, or research (important sectors)?
2. 2Check the size threshold: Does your company employ 50 or more people, or generate more than EUR 10 million annual revenue with a balance sheet total above EUR 10 million? For some sectors, the size threshold drops entirely.
3. 3Check supply chain position: Are you a supplier or IT service provider to an affected entity? Then you may not be NIS2-obligated yourself, but you are de facto co-regulated through your customers' supply chain requirements — a growing source of contractual obligations.
4. 4Check registration status: Have you registered with the BSI? The 06 March 2026 deadline has passed. A missed registration does not remove the obligation; it worsens the starting position in an audit.
5. 5Check documentation status: Does a traceable, dated management decision on the NIS2 applicability assessment exist? If not, that is the first gap to close — regardless of the assessment's outcome.

The Non-Delegable Management Liability

The real leverage of NIS2 lies not in the technical requirements — most have been in every serious security standard for years. It lies in the liability construction. The NIS2UmsuCG obliges members of management to approve the risk management measures and to monitor their implementation. This duty is explicitly non-delegable.

Non-delegable means in practice: management can hand operational implementation to IT, security, or external providers — responsibility for it actually happening, and for having monitored it traceably, remains with them. "But we have a CISO for that" is not an effective defense in a liability case. We regularly see solid operational security maturity at clients, while the bridge to management — documented approval and oversight — is simply missing.

There is also a training obligation for the management bodies themselves: management must attend training sufficient to assess the risks and evaluate the measures. That is more than a one-off awareness webinar — the people approving the measures must also understand them.

From a governance perspective the consequence is unambiguous: NIS2 belongs on the management agenda with a fixed, documented cadence, not as an ad hoc topic after an incident. This is exactly the anchoring described by the GOVERN function we cover in detail in our NIST CSF 2.0 Assessment Guide — regular, documented board engagement is the common denominator of modern security governance.

The Ten Risk Management Areas as Delivery Practice

The NIS2UmsuCG requires appropriate, proportionate technical and organizational measures across ten areas. In statutory language these sound abstract. Their implementation value emerges only when they are translated into concrete delivery and operations practices — things teams actually do, measure, and can evidence. That is exactly what the following translation provides.

Important on the proportionality principle: NIS2 does not require every company to operate at the security level of a defense contractor. Measures must be appropriate to the risk, size, and exposure. That is both an opportunity and a trap — appropriateness must be justified and documented, otherwise it is worthless in a dispute.

The Reporting Obligations: 24 Hours, 72 Hours, One Month

No NIS2 requirement fails as reliably in practice as the reporting obligation — not because it is unknown, but because it presupposes a response capability many organizations only miss when it counts. The NIS2UmsuCG provides a tiered reporting procedure for significant security incidents. The deadlines are short and run from awareness of the incident, not from its full clarification.

This is precisely where a documented and rehearsed incident response process proves to be regulatory obligation, not optional polish. An organization that only clarifies during the incident who reports, to whom, with what information, and in which language will not meet the 24-hour deadline. We also describe this mechanism in our IT Governance Assessment Guide as a typical maturity indicator — in a reportable incident, the difference between a plan on paper and a rehearsed process is the difference between compliance and breach.

1. 1Early warning within 24 hours: Initial notification to the BSI after becoming aware of a significant security incident. Content: initial indication of whether an unlawful or malicious background is suspected and whether cross-border effects are possible. No full analysis required — speed before completeness.
2. 2Incident notification within 72 hours: Updated assessment with an initial evaluation of the incident, severity, impact, and where applicable indicators of compromise. The incident response process must already deliver reliable findings here.
3. 3Interim report on request: The BSI may request a status report during an ongoing incident. The organization must be able to deliver a consistent current state at any time — an argument for continuous incident documentation rather than after-the-fact reconstruction.
4. 4Final report within one month: Detailed final report with root cause analysis, remediation taken and planned, and impact assessment. This report is effectively a post-incident review under regulatory observation.
5. 5Informing affected recipients: Where appropriate, recipients of your own services must be informed about significant incidents and possible countermeasures — external communication capability therefore belongs firmly in the incident response plan.

Supply Chain: The Obligation Nobody Has on the Radar

Of all ten areas, organizations underestimate supply chain security most clearly. NIS2 explicitly requires that the security of the supply chain and supplier relationships be included in risk management. This is not a contract appendix but an ongoing governance task — with a flip side many mid-market firms notice only late.

The flip side: even companies not directly NIS2-obligated are co-regulated via the supply chain. Anyone supplying an essential entity is de facto bound to the same measures through that entity's supplier requirements — contractually rather than by statute, but practically equivalent. We increasingly see that the first concrete NIS2 requirement comes not from an authority but from the largest customer.

In delivery practice this means three things: a maintained supplier register with risk classification — which providers can cause what damage if they fail or are compromised; security clauses in critical-supplier contracts that make reporting obligations, audit rights, and minimum standards binding; and a software bill of materials for deployed software, so that at the next Log4Shell-style vulnerability the question "are we affected?" is answerable in hours rather than weeks.

These three practices are exactly what a structured delivery audit surfaces: not whether a supplier contract exists, but whether it addresses the NIS2-relevant obligations at all and whether the critical dependencies are documented.

Demonstrability: Why Documentation Is the Real Obligation

An uncomfortable truth from practice: most affected companies are technically closer to NIS2 conformance than they think — and further from demonstrability than they would like. Backups exist, MFA is largely rolled out, an incident process is described somewhere. What is missing is the continuous, dated trail that holds up to a supervisory audit.

NIS2 is an evidence regime. The decisive audit question is rarely "do you have MFA?" but "show me the documented management approval of the measures, the training record including the management bodies, the restore-test results of the last twelve months, and the record of the last incident exercise." Anyone who cannot show these artifacts is vulnerable even when the technology is solid.

Our recommendation to clients is consistently the same: build the evidence layer first, not the tenth technical measure. A NIS2 measures matrix mapping each of the ten areas to concrete practices, owners, review cycles, and evidence is worth more than another security tool — it is what management actually needs to fulfill its non-delegable oversight duty.

On how deep these measures must reach, the connection to NIST CSF 2.0 is helpful: the ten NIS2 areas map almost entirely to the six CSF functions. Anyone determining a structured cybersecurity maturity based on NIST CSF 2.0 — as described in our NIST CSF 2.0 Assessment Guide — covers the majority of NIS2 requirements while obtaining the documentation structure NIS2 demands.

What Non-Compliance Risks

The sanction architecture of the NIS2UmsuCG is deliberately designed to force board-level attention. It combines significant fines with supervisory powers and the personal responsibility of management bodies. The exact level is tiered by entity type and must be assessed case by case — but the order of magnitude follows the GDPR model: fines measured against group revenue that can quickly reach double-digit million amounts for large companies.

Equally relevant as the fine level are the supervisory instruments. The BSI receives ordering and audit powers, and in severe cases supervision can extend to temporarily barring management activities. The reputational and continuity damage of a publicized breach often exceeds the fine anyway.

From a governance perspective the message is unambiguous: the most cost-effective NIS2 measure is an honest, documented status assessment now. Every month without a documented measures status does not shift the risk into the future; it enlarges it in the present, because the obligation already applies.

The 90-Day Roadmap for Management

NIS2 cannot be fully implemented in one quarter — but the liability-relevant starting position can be decisively improved in 90 days. The following roadmap prioritizes by liability exposure, not technical elegance: what protects management in an audit or incident comes first.

1. 1Week 1–2 — Clarify applicability bindingly: Have the applicability assessment documented and formally acknowledged by management. A dated decision on whether and as which entity type you are affected is the foundation of every further measure.
2. 2Week 2–4 — BSI registration and gap analysis: Catch up a missed registration and conduct a structured gap analysis against the ten areas. Use an established framework as a grid — mapping the ten NIS2 areas onto NIST CSF 2.0 saves duplicate work.
3. 3Week 4–6 — Make incident reporting reliable: Define the reporting chain to the BSI with names, deputies, templates, and language. Run a tabletop exercise of the 24-hour early warning and record it. This single step closes the deadline most frequently missed in practice.
4. 4Week 6–9 — Verify supply chain and backups: Create or update the supplier register with risk classes, review the security clauses of critical contracts, and run a real restore test with a dated record. Verified backups are the single most effective measure against the most expensive damage scenario.
5. 5Week 9–12 — Evidence layer and management training: Consolidate all artifacts into a NIS2 measures matrix, have management formally approve the measures, and complete the mandatory management training with attendance evidence. With that, the non-delegable oversight duty is demonstrably fulfilled for the first time.