A-R-C Consulting

Security Governance & Resilience

KRITIS-Dachgesetz: Cyber- und physische Resilienz gemeinsam steuern

Der Stromausfall startet physisch, die Fernwirktechnik verliert die Verbindung, der Bereitschaftsdienst kommt wegen einer gesperrten Zufahrt nicht an – und drei Teams führen drei verschiedene Vorfälle. Genau an solchen Übergängen scheitert Resilienz. Das KRITIS-Dachgesetz gilt seit dem 17. März 2026 und schafft Pflichten für Betreiber kritischer Anlagen. In der Praxis müssen Cyber-, physische, personelle und lieferkettenbezogene Risiken gemeinsam gesteuert werden, ohne unterschiedliche Rechtsregime in einen Topf zu werfen.

Von Andreas Rühl · 1. August 2026 · Quellen geprüft am 2. August 2026

Hinweis: Allgemeine fachliche Einordnung; keine Rechtsberatung, Zertifizierungs- oder Auditgarantie.

Dafür braucht es ein gemeinsames betriebliches Resilienzmodell und zugleich getrennte Feststellungen von Anwendbarkeit und Meldepflichten. Nicht jedes Unternehmen im NIS2- beziehungsweise BSIG-Kontext ist automatisch Betreiber einer kritischen Anlage nach dem KRITIS-Dachgesetz. Ebenso darf eine physische Vorfallsmeldung nicht einfach als Cybermeldung umetikettiert werden. Governance darf verbinden; die juristische Einordnung muss sauber trennen.

Die gesetzlichen Übergänge knüpfen nicht pauschal an ein einziges Kalenderdatum an. Nach § 8 Absatz 1 muss sich ein Betreiber spätestens drei Monate registrieren, nachdem seine Anlage als kritische Anlage gilt. Nach § 8 Absatz 7 sind die Pflichten aus § 12 erstmals neun Monate nach der Registrierung zu erfüllen; für die Pflichten aus §§ 13, 18 und 20 gilt eine Frist von zehn Monaten nach der Registrierung. Für Planung und Nachweisführung sind daher der individuelle Status der Anlage und das tatsächliche Registrierungsdatum maßgeblich. Eine pauschale Frist zum 17. Juli lässt sich aus der amtlichen konsolidierten Fassung nicht ableiten.

Der eigentliche Engpass ist nicht die nächste Risikoanalyse

Viele Organisationen besitzen bereits Business-Continuity-Pläne, Informationssicherheitsrisiken, Notfallhandbücher, Objektschutzkonzepte und Lieferantenbewertungen. Trotzdem fehlt häufig ein gemeinsames Bild davon, welche kritische Dienstleistung von welchen Ressourcen abhängt und wer bei einem gekoppelten Ereignis entscheidet.

Stellen wir uns eine klar hypothetische Lage in einem Versorgungsbetrieb vor. Ein technischer Standort verliert nach einem Unwetter die reguläre Stromversorgung. Das Notstromsystem startet, doch die externe Kommunikation ist instabil. Gleichzeitig fällt ein Dienstleister aus, der für eine Vor-Ort-Prüfung benötigt wird, weil die Zufahrt gesperrt ist. Das BCM-Team betrachtet die Ausfallzeit, die Informationssicherheit die gestörten Verbindungen und der Objektschutz den Standortzugang. Alle drei Bewertungen können fachlich richtig sein. Ohne gemeinsame Dienstleistungs- und Abhängigkeitslogik bleibt jedoch offen, ab welchem Punkt das Mindestniveau unterschritten wird und wer über eine Betriebsbegrenzung entscheidet.

Der Mechanismus hinter dem Engpass ist organisatorisch, nicht dokumentarisch. Bereichsregister ordnen Risiken nach Zuständigkeit. Ein reales Ereignis hält sich nicht an diese Ordnung. Es nutzt gemeinsame Ressourcen, verändert Annahmen gleichzeitig und erzeugt Entscheidungen an Schnittstellen. Ein gemeinsames Modell ersetzt die Fachregister nicht. Es gibt ihnen eine verbindende Grammatik, damit aus mehreren Teilbildern ein entscheidungsfähiges Lagebild entsteht.

Das Gesetz setzt bei der kritischen Anlage und der Versorgung der Allgemeinheit an. Es definiert Resilienz als Fähigkeit, Vorfälle zu verhindern, abzuwehren, ihre Folgen zu begrenzen, sie zu bewältigen und sich zu erholen. Betreiber müssen mindestens alle vier Jahre sowie bei Bedarf Risikoanalyse und Risikobewertung durchführen. Die daraus abgeleiteten Maßnahmen sind in einem anzuwendenden Resilienzplan darzustellen; die Erwägungen hinter den Maßnahmen müssen erkennbar sein.

Das ist keine Einladung zu einem weiteren isolierten Register. Eine Tabellenzeile namens „Hochwasser“ macht noch keine Pumpstation resilient.

Die organisatorische Schwierigkeit liegt darin, dass jede Fachfunktion mit einer anderen Einheit steuert. Das BCM denkt in Prozessen und Wiederanlaufzeiten, der Objektschutz in Standorten und Schutzzonen, die Informationssicherheit in Informationen, Anwendungen und Bedrohungen, der Einkauf in Verträgen und Lieferanten. Diese Einheiten sind jeweils sinnvoll. Sie werden problematisch, wenn ihre Übergänge nicht benannt sind. Dann kann eine Maßnahme in einem Register abgeschlossen sein, obwohl die zugehörige Annahme in einem anderen Register nie geprüft wurde. Ein verlängerter Liefervertrag sagt beispielsweise noch nichts darüber aus, ob der Dienstleister bei einer großräumigen Lage tatsächlich Personal am priorisierten Standort bereitstellen kann.

Typische Fehlsteuerung beginnt deshalb mit dem Wunsch nach einer einzigen Risikozahl. Unterschiedliche Szenarien werden in eine aggregierte Farbe oder Punktzahl überführt, bis das Dashboard vergleichbar aussieht. Dabei verschwinden Zeitverlauf, Kaskaden und Schwellenwerte – genau die Informationen, die eine Betriebsentscheidung tragen. Ein gekoppelter Ausfall mit niedriger Eintrittseinschätzung kann nach Eintritt sehr schnell das Mindestniveau unterschreiten; eine häufigere Störung kann dagegen durch vorhandene Reserven beherrschbar bleiben. Management braucht keine mathematische Einheitlichkeit um jeden Preis, sondern nachvollziehbare Aussagen zur bedrohten Leistung, zur unsicheren Annahme, zur Reichweite der Reserve und zur Entscheidungsbefugnis für die nächste Betriebsstufe.

Ein gemeinsames Modell mit fünf verbindenden Objekten

Aus Governance-Sicht lässt sich die Arbeit auf fünf Objekte reduzieren. Dieses Modell ist eine fachliche Synthese, kein gesetzlich vorgeschriebenes Format.

1. Kritische Dienstleistung und tolerierbarer Ausfall

Am Anfang steht nicht das Gebäude und nicht der Server, sondern die Leistung, deren erhebliche Beeinträchtigung die Versorgung trifft. Für jede Leistung braucht das Management ein gemeinsames Verständnis von Mindestniveau, tolerierbarer Unterbrechung, Wiederanlaufpriorität und betroffenen Bevölkerungs- oder Kundengruppen.

Diese Festlegung ist keine rein technische Kennzahl. Hypothetisch kann ein Prozess nominell weiterlaufen, während seine Leistung nur noch für einen Teil der vorgesehenen Empfänger verfügbar ist. Umgekehrt kann ein technisches Teilsystem ausfallen, ohne dass das vereinbarte Mindestniveau sofort unterschritten wird. Management und Betrieb müssen deshalb vor dem Ereignis klären, welche Einschränkung noch beherrschbar ist, wann eine Eskalation beginnt und welche Wiederherstellung Vorrang erhält. Sonst wird im Krisenstab über Begriffe verhandelt, während die Uhr bereits läuft.

2. Abhängigkeiten über Domänen hinweg

Eine Dependency Map verbindet Anlagen, OT und IT, Energie, Kommunikation, Personal, Gebäude, Logistik und wesentliche Dritte. Sie zeigt auch gemeinsame Fehlerursachen: ein Technikraum, ein Dienstleister oder eine Identitätsplattform kann mehrere scheinbar unabhängige Prozesse gleichzeitig treffen.

Die Karte ist nur dann nützlich, wenn sie Entscheidungen verändert. Ein hypothetischer Betreiber entdeckt beispielsweise, dass zwei getrennt dokumentierte Wiederanlaufverfahren denselben externen Spezialisten benötigen. Beide Verfahren sind für sich plausibel; gemeinsam können sie bei parallelem Bedarf nicht funktionieren. Die Entscheidung kann nun lauten, eine zweite Bezugsquelle vorzubereiten, interne Fähigkeiten aufzubauen oder die Wiederanlaufprioritäten ausdrücklich zu ändern. Eine Linie im Diagramm ist damit kein Dekor, sondern der Auslöser einer Ressourcenentscheidung.

Vollständigkeit ist dabei kein realistisches erstes Ziel. Der Startpunkt sind die Abhängigkeiten, deren Ausfall mehrere Leistungen trifft oder deren Ersatz besonders schwierig ist. Danach wird die Karte durch Übungen, Vorfälle und Änderungen fortgeschrieben. Ein Architekturdiagramm mit Owner und letztem Prüftermin ist belastbarer als ein statisches Gesamtbild ohne Pflegeverantwortung.

3. Szenarien statt Abteilungsrisiken

Szenarien sollten Ursache, betroffene Abhängigkeiten, mögliche Kaskade und Auswirkung auf die kritische Dienstleistung beschreiben. „Ransomware“, „Sabotage“ oder „Extremwetter“ allein sind Überschriften. Steuerbar wird ein Szenario erst, wenn klar ist, welche Leistung wann unter welches Mindestniveau fällt und welche Annahmen diese Aussage tragen.

Im hypothetischen Versorgungsfall lässt sich die Lage als zeitlicher Verlauf durchspielen. In den ersten Minuten übernimmt die Notstromversorgung; die Leistung bleibt oberhalb des Mindestniveaus. Nach einer Stunde erschwert die instabile Kommunikation die Fernsteuerung, während die Zufahrt blockiert ist. Nach mehreren Stunden wird nicht der Kraftstoff allein zum Engpass, sondern die Kombination aus Kühlung, Bedienpersonal und fehlender Vor-Ort-Prüfung. Das Szenario verbindet vier Fachperspektiven über dieselbe Dienstleistung und Zeitlinie. Es sagt den tatsächlichen Verlauf nicht voraus, sondern zeigt, an welcher Annahme eine verantwortete Entscheidung hängt.

Der Krisenstab kann nun vorab Schwellen definieren: Solange Fernsteuerung und Kühlung nachgewiesen stabil bleiben, wird der Betrieb fortgeführt. Fällt eine der Annahmen weg, prüft eine benannte Rolle die Betriebsbegrenzung; erreicht die Personalreserve einen festgelegten internen Schwellenwert, wird eine priorisierte Ablösung organisiert. Die konkreten Werte gehören in die betriebliche Ausgestaltung, nicht in eine allgemeine Vorlage. Entscheidend ist der Mechanismus: Beobachtung, Schwelle, Entscheidung und Folge müssen verbunden sein. Ohne diese Verbindung bleibt ein Szenario eine anschauliche Geschichte. Mit ihr wird es zu einem Instrument für Übungen, Investitionen und Eskalation.

4. Maßnahmen mit Ziel und Nachweis

Jede priorisierte Maßnahme braucht ein Resilienzziel, einen Owner, eine Frist und einen erwarteten Nachweis. Ein Notstromaggregat ist nicht schon deshalb wirksam, weil es im Anlagenverzeichnis steht. Belastbar sind etwa Testprotokolle unter realistischer Last, geklärte Kraftstofflogistik, dokumentierte Umschaltzeiten und behandelte Abweichungen.

In einer hypothetischen Übung startet das Aggregat ordnungsgemäß, doch ein abhängiges Kühlsystem wird beim Umschalten nicht versorgt. Der Test ist damit nicht „bestanden“ oder „nicht bestanden“ im abstrakten Sinn. Er hat eine konkrete Annahme widerlegt. Betrieb und Management müssen entscheiden, ob die Lastverteilung geändert, eine zusätzliche Versorgung aufgebaut oder die tolerierbare Betriebsdauer neu bewertet wird. Nachweis bedeutet hier nicht, dass ein Protokoll existiert, sondern dass aus dem beobachteten Ergebnis eine verantwortete Folgemaßnahme entsteht.

Diese Logik schützt auch vor Maßnahmenkatalogen, die Aktivität mit Wirkung verwechseln. Eine Schulung, ein Vertrag oder eine technische Redundanz kann sinnvoll sein. Belastbar wird die Maßnahme erst durch die Verbindung zum Szenario und zum angestrebten Dienstleistungsniveau. Andernfalls besitzt die Organisation viele erledigte Punkte und weiterhin dieselbe offene Ausfallwirkung. Das ist administrativ ordentlich, betrieblich aber ein eher bescheidener Trost.

5. Entscheidungen und Restunsicherheit

Das Management muss sehen, welche Szenarien akzeptiert, behandelt oder eskaliert werden, wo Abhängigkeiten ungeklärt bleiben und welche Investition welche Ausfallwirkung reduziert. Ein grüner Status ist ohne dokumentierte Schwellenwerte nicht belastbar.

Meldewege trennen, Lagebild verbinden

Das KRITIS-Dachgesetz schließt Ereignisse, die ausschließlich Sicherheitsvorfälle im Sinne des BSI-Gesetzes oder Telekommunikationsgesetzes sind, aus seinem Vorfallbegriff aus. Für Vorfälle nach dem Dachgesetz sieht § 18 eine unverzügliche Meldung, spätestens 24 Stunden nach Kenntnis, und grundsätzlich einen ausführlichen Bericht spätestens einen Monat nach Kenntnis vor. Die konkrete Einstufung eines Ereignisses und parallel einschlägige Pflichten müssen im Einzelfall geprüft werden.

Deshalb sollte das Incident Management nicht mit einem universellen „Meldebutton“ arbeiten, sondern mit einem gemeinsamen Triageprozess. Dieser hält den tatsächlichen Ereignisverlauf und die betroffene kritische Dienstleistung fest, ordnet den Sachverhalt als physisch, cyberbezogen oder gekoppelt ein und ermittelt die beteiligten Rechtsträger, Anlagen und Regime. Für jeden Meldeweg werden Behörde, Frist, Mindestinformation und Freigabe getrennt bestimmt. Eine gemeinsame, kontrollierte Faktenbasis hält die Angaben zwischen den Wegen konsistent.

So bleibt die rechtliche Meldelogik getrennt, während Einsatzleitung und Management auf ein gemeinsames Lagebild zugreifen. Das verhindert widersprüchliche Zeitlinien, doppelte Ursachenanalysen und Freigaben durch die falsche Rolle.

Praktisch sollte die gemeinsame Faktenbasis Ereigniszeit, Kenntniszeit, betroffene Leistungen, beobachtete Auswirkungen, Gegenmaßnahmen und offene Unsicherheiten festhalten. Die rechtliche Bewertung wird daran angehängt, nicht hineingemischt. Ändert sich ein Fakt, können die zuständigen Rollen prüfen, welche Meldung betroffen ist, ohne parallel mehrere Versionen der Wirklichkeit zu pflegen. Das gemeinsame Lagebild ist also kein gemeinsames Rechtsformular.

Nehmen wir hypothetisch einen gekoppelten Vorfall, bei dem ein physischer Zutrittsausfall und eine gestörte Fernadministration gleichzeitig auftreten. Die Einsatzleitung braucht eine konsistente Zeitlinie, auch wenn unterschiedliche Stellen getrennt beurteilen, welche Meldewege greifen. Eine vorab definierte Triage dokumentiert beide Bewertungen, ihre Freigaben und Fristen.

Von vorhandenen Nachweisen profitieren – ohne Gleichwertigkeit zu behaupten

§ 17 erlaubt, Risikoanalysen, Maßnahmen, Dokumente und Zertifikate aus anderen Pflichten oder freiwilligen Aktivitäten als Nachweis heranzuziehen. Das bedeutet nicht, dass ISO-27001-Zertifikat, BCM-Übung oder BSIG-Nachweis automatisch jede Pflicht des KRITIS-Dachgesetzes erfüllt. Wiederverwendung braucht ein begründetes Mapping von Feststellung, Resilienzziel, Anlage und Zeitraum sowie eine dokumentierte verbleibende Lücke.

Praktisch eignet sich ein Evidence Register mit Quelle, Scope, Zeitraum, verantwortlicher Stelle, Aussagekraft und letzter Prüfung. Es reduziert Doppelarbeit, ohne aus Ähnlichkeit rechtliche Gleichwertigkeit zu machen.

Wiederverwendung hat auch eine organisatorische Seite. Das ISMS kann einen Nachweis technisch und methodisch für belastbar halten, während der Betreiberbezug oder der betrachtete Zeitraum für den Resilienzplan nicht passt. Umgekehrt kann eine BCM-Übung wertvolle Beobachtungen zu Personal und Wiederanlauf liefern, aber keine Aussage über eine ungetestete physische Schutzmaßnahme tragen. Deshalb braucht jedes Mapping zwei Freigaben: Die fachlich verantwortliche Stelle bestätigt die Aussagekraft, die für das Resilienzziel verantwortliche Rolle bestätigt die Passung zum konkreten Scope. Das ist etwas aufwendiger als das Verschieben einer PDF in einen neuen Ordner, spart aber die spätere Entdeckung, dass derselbe Nachweis überall referenziert und nirgends ausreichend war.

Das Management steuert Entscheidungen statt Dokumentmengen

Ein integriertes Modell verändert die Berichterstattung an die Geschäftsleitung. Statt die Zahl abgeschlossener Maßnahmen oder vorhandener Pläne isoliert zu melden, zeigt es die verbleibende Ausfallwirkung je priorisiertem Szenario, die belastbar getesteten Annahmen und die offenen Entscheidungsfristen. Eine überfällige Maßnahme wird dadurch nicht automatisch zum größten Risiko. Entscheidend ist, welches Dienstleistungsniveau von ihr abhängt, welche Kompensation besteht und wann die nächste Schwelle erreicht wird.

Auch Investitionskonflikte werden konkreter. Wenn dieselbe mobile Energieversorgung zwei Standorte absichern soll, kann das Management nicht beiden Bereichen abstrakt „Redundanz vorhanden“ bescheinigen. Es muss Priorität, Transportzeit, Personal und alternative Betriebsstufen gegeneinander abwägen. Wenn ein externer Spezialist in mehreren Wiederanlaufplänen vorkommt, ist nicht die Vollständigkeit der Pläne das Thema, sondern die knappe Fähigkeit. Das gemeinsame Modell übersetzt solche Konflikte in Entscheidungen über Ressourcen, Reihenfolge und akzeptierte Restunsicherheit.

Die Managementfolge ist nüchtern: Owner stehen nicht für Dokumente, sondern für wirksame Annahmen und rechtzeitige Eskalation ein. Übungen zeigen, welche Annahmen bestätigt oder widerlegt wurden. Ein grüner Status bleibt nur dann grün, wenn Schwellenwert, Evidenzzeitraum und nächste Prüfung sichtbar sind. Farbe allein ist noch keine Betriebsreserve.

Prüfkriterien für die nächsten 90 Tage

  • Gesellschaften und Anlagen sind getrennt von der NIS2-/BSIG-Einstufung einem belastbaren Scope zugeordnet.
  • Das Management hat kritische Dienstleistungen, Mindestniveaus und Wiederanlaufprioritäten bestätigt.
  • Eine domänenübergreifende Karte zeigt die technischen, physischen, personellen und externen Abhängigkeiten.
  • Gemeinsame Szenario-IDs verbinden Risikoanalyse, Resilienzplan, BCM, ISMS und Objektschutz.
  • Jede priorisierte Maßnahme besitzt Ziel, Owner, Termin, Betriebsnachweis und Eskalationsschwelle.
  • Der Triageprozess trennt Meldewege, Fristen und Freigaben nach Rechtsregime.
  • Übungen testen gekoppelte Ausfälle und Entscheidungsübergaben statt isolierter Fachabläufe.
  • Die Geschäftsleitung erkennt Restunsicherheit, überfällige Maßnahmen und nicht getestete Annahmen.

Fazit und A-R-C-Impuls

Das KRITIS-Dachgesetz sollte nicht als Projekt zur Produktion eines Resilienzplans behandelt werden. Der Plan ist die sichtbare Schicht; entscheidend ist das betriebene Modell darunter: kritische Leistung, Abhängigkeit, Szenario, Maßnahme, Nachweis und Entscheidung.

A-R-C unterstützt Organisationen dabei, Informationssicherheit und Resilienz steuerbar, prüfbar und managementfähig zu machen. Ein sinnvoller Einstieg ist ein fokussierter Resilience Governance Review: Scope-Hypothesen, bestehende Register, Meldewege und Nachweise werden in ein gemeinsames Steuerungsbild überführt und die größten Entscheidungs- und Evidenzlücken priorisiert.

Abgrenzung

Dieser Beitrag ist eine fachliche Einordnung zu Governance und Umsetzung. Er ist keine Rechtsberatung, keine Feststellung der individuellen KRITIS- oder NIS2-Anwendbarkeit und keine Audit-, Zertifizierungs- oder Resilienzgarantie. Konkretisierende Rechtsverordnungen, behördliche Festlegungen und sektorale Sonderregeln sind für den Einzelfall gesondert zu prüfen.

Primärquellen

Über den Autor

Andreas Rühl unterstützt Unternehmen als Interim CISO und ISMS/GRC-Berater. Sein Schwerpunkt liegt darauf, Informationssicherheit steuerbar, prüfbar und managementfähig zu machen.

Passende A-R-C-Leistung: NIS2-/KRITIS-Beratung