Risikoanalyse und Störungsmeldungen unter dem KRITIS-Dachgesetz

Problem in der Praxis

Viele Betreiber behandeln Resilienz als Anhängsel ihrer Cyber-Compliance. Das erzeugt eine doppelte Lücke: Physische und organisatorische Gefahren werden unterschätzt, weil die Risikoanalyse faktisch eine IT-Risikoanalyse bleibt; und es entstehen zwei getrennte Meldeprozesse, die kollidieren, wenn ein Cyber-Vorfall zugleich eine physische Versorgungsstörung auslöst.

Hinzu kommt Unsicherheit über Zuständigkeiten. Im physischen Regime arbeiten zwei Behörden zusammen: das BBK (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe) federführend für physische Resilienz und Aufsicht, das BSI als gemeinsame Registrierungs- und Meldestelle über ein gemeinsames Portal beider Häuser. Wer das mit der BSI-Meldelinie des Cyber-Regimes verwechselt, meldet falsch oder doppelt. Das ist kein Formular-, sondern ein Steuerungsproblem.

CISO-Einordnung

Der CISO sollte vier Fragen trennen und dann zusammenführen:

• Welche Anlagen sind kritisch? Primäres Quantitätskriterium ist der Regel-Schwellenwert von 500.000 versorgten Personen je Anlage; ergänzend gibt es qualitative Einzelfall-Einstufungen über Interdependenzen, Marktanteil und Versorgungsbedeutung. Sektorale Detailschwellen darunter regelt untergesetzliches Recht und sind dort zu verifizieren.
• Welche Gefahren sind relevant? Der All-Gefahren-Ansatz, nicht nur das Cyber-Spektrum.
• Wer ist Adressat? Betreiber kritischer Anlagen, mit besonderer Verantwortung der Leitungsebene.
• Wie wird gemeldet? Erhebliche Störungen an die zuständige Stelle, nicht in den IT-Störungsprozess.

KRITIS hat in Deutschland zwei Ebenen: Cyber-Sicherheit über BSIG und NIS2 sowie physische Resilienz über CER und KRITIS-DachG. Viele Betreiber sind beidseitig pflichtig; daraus entsteht der Hebel eines gemeinsamen Risiko- und Meldeframeworks statt zweier Silos. Das KRITIS-DachG ist regulatorische Pflicht, kein Zertifizierungsschema: das Wie liefern Normen.

Umsetzungsperspektive

Sinnvoll ist ein schlanker, betreibbarer Kern statt eines maximalen Dokumentenwerks. Vier Bausteine tragen ihn:

Risikoanalyse: eine All-Gefahren-Risikobewertung je kritischer Anlage, im Turnus von mindestens alle vier Jahre, bei Bedarf häufiger. In Sekundärquellen kursierende Erst- und Umsetzungsfristen von rund neun bzw. zehn Monaten nach Einstufung stehen so nicht zwingend im Gesetzeswortlaut und sind am Gesetzestext zu prüfen. Aus ihr leiten sich Resilienzmaßnahmen ab, etwa Objekt- und Zutrittsschutz, Notfall- und Krisenmanagement, Redundanz und Personalsicherheit samt Zuverlässigkeitsüberprüfungen.

Registrierung: Eintrag über die gemeinsame Stelle BBK/BSI, spätestens drei Monate nach Einstufung und frühestens ab dem 17.07.2026.

Meldung erheblicher Störungen: der operative Kern. Nach derzeitigem Stand ist unverzüglich zu melden, die Erstmeldung spätestens binnen 24 Stunden, ein ausführlicher Bericht binnen eines Monats. Sinnvoll ist ein einziger Störungsprozess, der erhebliche Störungen erkennt, klassifiziert und in die richtige Behördenlinie steuert.

Synchronisation mit NIS2: Auch das Cyber-Regime kennt gestufte Meldefristen. Ein gemeinsames Incident-Management mit einheitlicher Schwere-Klassifizierung und einem Verteiler, der die physische Linie (BBK/BSI) und die Cyber-Linie (BSIG) parallel bedient, vermeidet doppelte Meldungen. Synergie entsteht auch beim Nachweis: Behörden können auf Teile bereits vorgelegter Cyber-Nachweise zurückgreifen, etwa auf Nachweise nach Paragraf 39 BSIG oder auf branchenspezifische Sicherheitsstandards (B3S).

Typische Fehler

1. Die Risikoanalyse bleibt faktisch eine IT-Risikoanalyse und ignoriert physische All-Gefahren.
2. Cyber- und physisches Regime werden vermischt, inklusive falscher Meldeadresse.
3. Die 24-Stunden-Erstmeldung scheitert, weil Eskalation und Bereitschaft nicht geklärt sind.
4. Registrierungs- und Turnusfristen werden verpasst, weil niemand sie verbindlich verantwortet.
5. Kursierende Fristenwerte werden ungeprüft übernommen statt am Gesetzestext verifiziert.

Risiken und Trade-offs

Zu schlanke Steuerung übersieht Gefahren oder liefert im Melde- und Prüffall zu wenig Nachweisbarkeit. Zu schwere Strukturen überfordern die Organisation, gerade weil physische Resilienz viele Fachbereiche jenseits der IT betrifft.

Ein zweiter Trade-off liegt zwischen Geschwindigkeit und Genauigkeit: Die kurze Erstmeldefrist zwingt zur Meldung unter Unsicherheit. Wer auf Vollständigkeit wartet, verfehlt die Frist; wer vorschnell meldet, riskiert Korrekturbedarf. Der Prozess muss schnell erstmelden und sauber nachberichten können. Im Finanzsektor ist zudem DORA (Verordnung (EU) 2022/2554) als vorrangiges Spezialregime für die digitale operationale Resilienz zu beachten.

Entscheidungspunkte

• Welche Anlagen überschreiten den Regel-Schwellenwert oder fallen über qualitative Kriterien in den Anwendungsbereich?
• Wer verantwortet Risikoanalyse, Registrierung und Meldung verbindlich auf Leitungsebene?
• Ein gemeinsames Incident- und Meldeframework für NIS2 und KRITIS-DachG oder zwei getrennte Prozesse?
• Welche Schwere-Schwelle definiert eine erhebliche Störung, und wer entscheidet sie im Ernstfall?
• Welche Detailfristen und Nachweispflichten müssen vorab am Gesetzestext verifiziert werden?

Praktische Empfehlungen

1. Prüfen Sie die Betroffenheit je Anlage und dokumentieren Sie die Einstufungslogik nachvollziehbar.
2. Bauen Sie eine All-Gefahren-Risikoanalyse über das Cyber-Spektrum hinaus auf und fixieren Sie den Turnus von mindestens vier Jahren.
3. Etablieren Sie einen einzigen Störungsprozess mit klarer Schwere-Klassifizierung, der erhebliche Störungen in die richtige Behördenlinie steuert.
4. Trainieren Sie die 24-Stunden-Erstmeldung als Bereitschaftsfall und verankern Sie die Nachberichterstattung.
5. Synchronisieren Sie Meldewege und Nachweise mit dem NIS2-Regime gegen Doppelarbeit.
6. Das KRITIS-Dachgesetz ist in Kraft seit 17.03.2026 (Gesetz vom 11.03.2026, BGBl. 2026 I Nr. 66; Ausnahme Paragraf 14 Absatz 3 bis 5 ab 01.01.2030); verifizieren Sie verbleibende exakte Detailfristen und Schwellen an der amtlichen Quelle (gesetze-im-internet.de) und am EUR-Lex-Text der CER-Richtlinie.

Relevante Normreferenzen

• Richtlinie (EU) 2022/2557 (CER-Richtlinie): EU-Rechtsrahmen für physische All-Gefahren-Resilienz; verbindlich ist die nationale Umsetzung.
• KRITIS-Dachgesetz (KRITIS-DachG): nationale Umsetzung der CER-Richtlinie; geltendes Bundesrecht (Gesetz vom 11.03.2026, BGBl. 2026 I Nr. 66, in Kraft seit 17.03.2026; Ausnahme: Paragraf 14 Absatz 3 bis 5 ab 01.01.2030; amtliche Fundstelle gesetze-im-internet.de/kritisdachg).
• BSIG (NIS2-Umsetzung): komplementäres Cyber-Regime; Synergie bei Nachweisen (Paragraf 39 BSIG, B3S).
• ISO 22301, ISO 31000 und ISO/IEC 27001: konzeptionelle Wie-Referenzen für Kontinuitäts-, Risiko- und ISMS-Management; decken den All-Gefahren-Objektschutz nicht vollständig ab (reference-only).
• NIST Cybersecurity Framework: konzeptionelle Mapping-Brücke (Govern, Identify, Protect, Detect, Respond, Recover).