Since December 6, 2025, the NIS2 Implementation Act (NIS2UmsuCG) has been in force in Germany, without a transitional period. Around 29,500 companies in 18 sectors are covered by it, significantly more than the approximately 4,500 companies that previously fell under the old KRITIS regulation.
In November 2025, shortly after its adoption by the Bundestag, we already summarized the basic requirements of NIS2 in this article. Six months later, it became clear how far implementation had actually progressed in practice: By the registration deadline in March 2026, around 11,500 companies had registered with the BSI, just under 40 percent.
Registration is a form, not preparation
Anyone who has registered has taken an important first step. However, registration does not mean that a company is NIS2-compliant. The law demands significantly more: state-of-the-art risk management measures, reporting of significant security incidents within 24 hours, and personal liability of management for implementation.
Fines of up to 10 million euros or 2 percent of global annual turnover are at stake, regardless of whether a security incident has ever occurred. The mere lack of registration is already subject to fines.
The real gap: present versus proven
Discussions with German companies reveal a recurring pattern. The basics are there: a firewall, a backup solution, an incident response plan on paper. Auditors check the documentation, and often the measure is considered fulfilled.
However, NIS2 asks a different question: Can you prove that the measure actually works in an emergency? Not as a statement of intent, but as a tested, documented, and repeatable result.
It is precisely at this point that a silent gap often becomes apparent in practice. Many companies know exactly what they have set up. However, when the question arises as to when a full or partial recovery was last tested, and whether the result is documented, it often remains silent.
What an auditor, insurer, or supervisory board really wants to see
After a security incident, neither a supervisory authority nor an insurer will accept an architectural drawing as proof. What is required is evidence that the recovery has been tested, with a documented result and a date for the next test.
This shifts data resilience from a purely technical matter to a question of corporate governance and accountability, with direct personal responsibility for management according to § 38 NIS2UmsuCG.
Three questions that matter now
For companies that want to check their NIS2 preparation beyond mere registration, three questions are a good starting point:
- When was the recovery last fully tested, and is the result documented?
- Is there a fixed next test date, or will it be tested “again sometime”?
- Are backup, disaster recovery, and cyber recovery organized as a continuous chain, or is responsibility fragmented across different tools and teams?
Anyone who cannot clearly answer these three questions probably still has a gap between what is on paper and what actually works in an emergency.
If you are still at the beginning, our handout on preparing a disaster recovery concept provides a practical basis: a recommended document structure, checklists for project start, and templates for recovery plans and tests.
How Pink Elephant helps
Pink Elephant helps companies close precisely this gap: from assessing current resilience to tested disaster recovery and cyber recovery environments, and documentation that stands up to scrutiny.
