CER-Richtlinie und KRITIS: Physische Resilienz kritischer Einrichtungen

Problem in der Praxis

Viele Betreiber haben stark in Cybersicherheit investiert und behandeln KRITIS faktisch als IT-Thema. Die CER-Richtlinie verschiebt den Blick zurück auf das physische Objekt und die Versorgungsleistung. Die relevanten Themen liegen oft verstreut bei Werkschutz, Facility Management, BCM, HR und Technik, ohne gemeinsames Risikobild und ohne klaren Owner. Bei Vorfall oder Aufsichtsanfrage fehlt der Faden zwischen Risikoanalyse, Maßnahmen, Nachweisen und Entscheidungen. Erschwerend: Die CER-Richtlinie war bis Oktober 2024 national umzusetzen, Deutschland hat das KRITIS-DachG aber erst verspätet erlassen (Gesetz vom 11.03.2026, in Kraft seit 17.03.2026).

CISO-Einordnung

CER und NIS2 sind komplementär, nicht deckungsgleich: NIS2 und BSIG adressieren Cyber, CER und KRITIS-DachG die physische und organisatorische All-Gefahren-Resilienz. Viele Betreiber sind von beiden Regimen erfasst und brauchen kein zweites paralleles Programm, sondern ein gemeinsames Modell mit zwei Ausprägungen.

• Adressat sind Betreiber kritischer Anlagen sowie kritische Einrichtungen von besonderer europäischer Bedeutung.
• Primäres Quantitätskriterium ist ein Regel-Schwellenwert von 500.000 versorgten Personen je Anlage, ergänzt um qualitative Kriterien. Sektorspezifische Detailschwellen folgen aus untergesetzlichen Regelungen und sind zu verifizieren.
• Die CER-Richtlinie benennt elf Sektoren (Energie, Verkehr, Gesundheit, Wasser, digitale Infrastruktur u. a.). Der deutsche Sektor-Zuschnitt im KRITIS-DachG ist am Gesetzestext und der Rechtsverordnung zu prüfen.
• Für den Finanzsektor gilt DORA (VO (EU) 2022/2554) als lex specialis für die digitale operationale Resilienz.

Zuständig sind das BBK (physische Resilienz und Aufsicht) und das BSI (gemeinsame Registrierungs- und Meldestelle). Das KRITIS-DachG ist 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 tritt erst am 01.01.2030 in Kraft; Quelle: gesetze-im-internet.de/kritisdachg). Verbindlich ist allein das nationale Recht samt Verordnungen, nicht die Richtlinie.

Umsetzungsperspektive

Ein belastbares CER-Programm lässt sich auf einen kleinen Steuerungskern reduzieren:

• Betroffenheit klären und die Registrierung über die gemeinsame Stelle von BBK und BSI vorbereiten.
• All-Gefahren-Risikoanalyse über das gesamte Gefahrenspektrum, in einem gesetzlichen Mindestturnus (mindestens alle vier Jahre, bedarfsweise häufiger).
• Resilienzmaßnahmen und Resilienzplan: Objekt- und Zutrittsschutz, Notfall- und Krisenmanagement, Redundanz und Ersatzversorgung, Personalsicherheit inklusive Zuverlässigkeitsüberprüfungen, Wiederanlauf.
• Melde- und Berichtswesen: erhebliche Störungen unverzüglich, Erstmeldung binnen 24 Stunden, ausführlicher Bericht innerhalb eines Monats.
• Nachweis- und Leitungsverantwortung der Geschäftsleitung, vergleichbar mit der NIS2-Governance.

Vorlauffristen nach der Einstufung sind am Gesetzestext zu verifizieren; kursierende Werte von rund neun Monaten (Risikoanalyse) und zehn Monaten (Maßnahmen) stehen so nicht zwingend im Gesetz und sind nicht als gesichert zu planen. Behörden können auf vorhandene Nachweise zurückgreifen, etwa nach Paragraf 39 BSIG oder B3S (branchenspezifische Sicherheitsstandards).

Typische Fehler

1. KRITIS wird als reines Cyberthema behandelt, der physische All-Gefahren-Schutz bleibt unbesetzt.
2. CER und NIS2 werden als getrennte Projekte aufgesetzt statt als zwei Ausprägungen eines Modells.
3. Fristen werden aus Sekundärquellen abgeleitet statt aus dem amtlichen Gesetzestext.
4. Verantwortung für Objektschutz, BCM und Personalsicherheit bleibt verteilt, ohne klaren Owner.
5. Die verspätete Umsetzung wird als Aufschub missverstanden statt als aufzuholende Vorlaufzeit.

Risiken und Trade-offs

Ein zu eng auf Cyber fokussiertes Programm übersieht physische Einzelpunkte des Versagens und Versorgungsabhängigkeiten; ein zu schwer aufgesetztes bindet Ressourcen ohne messbaren Resilienzgewinn. Ein Trade-off liegt zwischen Standardisierung (erleichtert Aufsicht und Nachweis) und Standortrealität (nicht jede Anlage passt ins Schema). Vorsicht vor Scheinsicherheit: Ein Resilienzplan, der nicht geübt und nicht aktuell gehalten wird, schafft Nachweise, aber keine Resilienz.

Entscheidungspunkte

• Welche Anlagen sind nach Schwellenwert und qualitativen Kriterien betroffen, und wer prüft das verbindlich?
• Führen wir CER und NIS2 unter einem gemeinsamen Governance- und Nachweismodell oder getrennt?
• Wer verantwortet die physische Resilienz end-to-end, und mit welchem Mandat?
• Welche Nachweise aus Cyber- und BCM-Prozessen lassen sich für die CER-Pflichten wiederverwenden?

Praktische Empfehlungen

1. Verifizieren Sie Anwendungsbereich, Sektor-Zuschnitt und Fristen am amtlichen Gesetzestext und an der Rechtsverordnung, bevor Sie planen.
2. Etablieren Sie ein gemeinsames Risikobild für Cyber und physische All-Gefahren.
3. Benennen Sie einen Owner für physische Resilienz mit Mandat und Berichtslinie zur Geschäftsleitung.
4. Bauen Sie das Meldewesen so, dass die 24-Stunden-Erstmeldung organisatorisch sicher gelingt.
5. Nutzen Sie bestehende Nachweise (Paragraf 39 BSIG, B3S), um Doppelnachweise zu vermeiden.

Relevante Normreferenzen

• CER-Richtlinie (EU) 2022/2557 vom 14. Dezember 2022 über die Resilienz kritischer Einrichtungen, zur Aufhebung der Richtlinie 2008/114/EG; veröffentlicht im Amtsblatt L 333 vom 27.12.2022. Inkrafttretensdatum an der amtlichen Quelle (EUR-Lex) verifizieren.
• KRITIS-Dachgesetz (KRITIS-DachG) als nationale Umsetzung der Richtlinie (EU) 2022/2557; 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 Quelle gesetze-im-internet.de/kritisdachg).
• ISO 22301 (Business Continuity) und ISO 31000 (Risikomanagement) als Referenzen für das "Wie"; ISO/IEC 27001 an der Schnittstelle physisch/organisatorisch (deckt den All-Gefahren-Objektschutz nicht vollständig ab).
• NIST Cybersecurity Framework als Mapping-Brücke ohne direkten Rechtsbezug.