Seit dem 6. Dezember 2025 ist das NIS2-Umsetzungsgesetz (NIS2UmsuCG) in Deutschland in Kraft, ohne Übergangsfrist. Rund 29.500 Unternehmen in 18 Sektoren fallen darunter, deutlich mehr als die etwa 4.500 Unternehmen, die bislang unter die alte KRITIS-Regulierung fielen.
Im November 2025, kurz nach der Verabschiedung durch den Bundestag, haben wir die grundlegenden Anforderungen von NIS2 bereits in diesem Artikel zusammengefasst. Sechs Monate später zeigt sich, wie weit die Umsetzung in der Praxis tatsächlich fortgeschritten ist: Bis zur Registrierungsfrist im März 2026 hatten sich rund 11.500 Unternehmen beim BSI registriert, knapp 40 Prozent.
Registrierung ist ein Formular, keine Vorbereitung
Wer sich registriert hat, hat einen wichtigen ersten Schritt gemacht. Registrierung bedeutet aber nicht, dass ein Unternehmen NIS2-konform ist. Das Gesetz verlangt deutlich mehr: Risikomanagementmaßnahmen nach dem Stand der Technik, die Meldung erheblicher Sicherheitsvorfälle innerhalb von 24 Stunden, und persönliche Haftung der Geschäftsleitung für die Umsetzung.
Bußgelder von bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes stehen im Raum, unabhängig davon, ob jemals ein Sicherheitsvorfall stattgefunden hat. Allein die fehlende Registrierung ist bereits bußgeldbewehrt.
Die eigentliche Lücke: vorhanden versus bewiesen
In Gesprächen mit deutschen Unternehmen zeigt sich ein wiederkehrendes Muster. Die Grundlagen sind da: eine Firewall, eine Backup-Lösung, ein Incident-Response-Plan auf Papier. Auditoren prüfen die Dokumentation, und häufig gilt die Maßnahme damit als erfüllt.
NIS2 stellt jedoch eine andere Frage: Können Sie nachweisen, dass die Maßnahme im Ernstfall tatsächlich funktioniert? Nicht als Absichtserklärung, sondern als getestetes, dokumentiertes und wiederholbares Ergebnis.
Genau an dieser Stelle zeigt sich in der Praxis häufig eine stille Lücke. Viele Unternehmen wissen genau, was sie eingerichtet haben. Wenn jedoch die Frage kommt, wann zuletzt eine vollständige oder teilweise Wiederherstellung getestet wurde, und ob das Ergebnis dokumentiert ist, bleibt es häufig still.
Was ein Prüfer, Versicherer oder Aufsichtsgremium wirklich sehen will
Nach einem Sicherheitsvorfall akzeptiert weder eine Aufsichtsbehörde noch ein Versicherer eine Architekturzeichnung als Nachweis. Verlangt wird der Beleg, dass die Wiederherstellung getestet wurde, mit einem dokumentierten Ergebnis und einem Termin für den nächsten Test.
Das verschiebt Data Resilience von einer rein technischen Angelegenheit zu einer Frage der Unternehmensführung und Rechenschaftspflicht, mit direkter persönlicher Verantwortung für die Geschäftsleitung nach § 38 NIS2UmsuCG.
Drei Fragen, die jetzt zählen
Für Unternehmen, die ihre NIS2-Vorbereitung über die reine Registrierung hinaus prüfen wollen, sind drei Fragen ein guter Startpunkt:
- Wann wurde die Wiederherstellung zuletzt vollständig getestet, und ist das Ergebnis dokumentiert?
- Gibt es einen festen nächsten Testtermin, oder wird „irgendwann wieder“ getestet?
- Sind Backup, Disaster Recovery und Cyber Recovery als eine durchgängige Kette organisiert, oder liegt die Verantwortung fragmentiert bei verschiedenen Tools und Teams?
Wer diese drei Fragen nicht klar beantworten kann, hat wahrscheinlich noch eine Lücke zwischen dem, was auf dem Papier steht, und dem, was im Ernstfall tatsächlich funktioniert.
Wer noch am Anfang steht, findet in unserem Handout zur Vorbereitung eines Disaster-Recovery-Konzepts eine praktische Grundlage: eine empfohlene Dokumentenstruktur, Checklisten für den Projektstart und Vorlagen für Wiederanlaufpläne und Tests.
Wie Pink Elephant unterstützt
Pink Elephant hilft Unternehmen dabei, genau diese Lücke zu schließen: von der Bewertung der aktuellen Resilienz über getestete Disaster-Recovery- und Cyber-Recovery-Umgebungen bis hin zur Dokumentation, die bei einer Prüfung tatsächlich Bestand hat.
