BCM als Rückgrat der KRITIS-Resilienz

Problem in der Praxis

In vielen Organisationen existiert BCM auf Papier, aber nicht im Betrieb. Es gibt einen Notfallordner, vielleicht eine IT-Wiederanlaufplanung, eventuell eine alte Risikoliste. Was fehlt, ist die belastbare Verbindung zwischen kritischem Geschäftsprozess, zugrunde liegender Ressource und konkreter Wiederherstellungsvorgabe. Wird eine Anlage durch Hochwasser, Stromausfall, Sabotage oder den Ausfall eines Schlüssellieferanten getroffen, zeigt sich, dass niemand verbindlich festgelegt hat, welcher Dienst in welcher Zeit wieder laufen muss.

Ein zweites Muster: BCM wird als reine IT-Disaster-Recovery verstanden. Dann sind Server und Daten abgesichert, aber Personal, Standort, Versorgung und Lieferkette bleiben außen vor. Genau das widerspricht dem All-Gefahren-Anspruch der CER-Logik. Drittens fehlt oft die Verbindung zur Risikoanalyse: Notfallpläne entstehen unabhängig davon, welche Szenarien die Risikobewertung als wesentlich identifiziert hat. So entstehen Pläne für unwahrscheinliche Fälle und Lücken bei den realen Bedrohungen einer konkreten kritischen Anlage.

CISO-Einordnung

BCM ist aus CISO-Sicht zuerst eine Frage der Priorität, dann eine Frage der Technik. Der Ausgangspunkt ist nicht die Maßnahme, sondern die Business Impact Analyse (BIA): die systematische Bewertung, welche Geschäftsprozesse und Dienste zeitkritisch sind, wovon sie abhängen und wie sich ein Ausfall über die Zeit auf Versorgung, Sicherheit und Verpflichtungen auswirkt. Die BIA liefert die Begründung dafür, wo Redundanz, Ersatzversorgung und Wiederanlaufkapazität zuerst aufgebaut werden.

Aus der BIA leiten sich die zentralen Steuerungsgrößen ab. Die Recovery Time Objective (RTO) beschreibt die maximal tolerierbare Zeit bis zur Wiederherstellung eines Prozesses oder Dienstes nach einer Störung. Die Recovery Point Objective (RPO) beschreibt den maximal tolerierbaren Datenverlust, gemessen als Zeitspanne bis zum letzten verwertbaren Stand; sie ist vor allem dort relevant, wo Datenbestände den Dienst tragen. Beide Größen sind Management-Vorgaben, keine technischen Automatismen: Sie drücken aus, welches Ausfall- und Verlustniveau die Organisation für einen kritischen Dienst akzeptiert, und sie bestimmen, welche Investitionen in Redundanz und Wiederanlauf gerechtfertigt sind.

KRITIS-Dachgesetz und CER-Richtlinie sind regulatorische Pflicht und kein Zertifizierungsschema. ISO 22301 strukturiert das Business-Continuity-Managementsystem als Regelkreis, der BSI-Standard 200-4 beschreibt einen praxisnahen BCM-Aufbau im Kontext des IT-Grundschutzes. Diese Referenzen liefern die Methode, nicht den Rechtsinhalt, und werden ausschließlich als Referenz herangezogen.

Umsetzungsperspektive

Ein tragfähiges BCM lässt sich entlang weniger ineinandergreifender Bausteine aufbauen, die als laufender Regelkreis betrieben werden:

• Geltungsbereich und kritische Dienste. Festlegen, welche Anlagen und Versorgungsprozesse erfasst sind und welche Dienste die regulatorische Kritikalität tragen.
• Business Impact Analyse. Zeitkritische Prozesse, ihre Abhängigkeiten (Personal, Standort, Technik, Lieferanten) und die Auswirkung eines Ausfalls über die Zeit bewerten.
• Wiederherstellungsvorgaben. Je kritischem Dienst RTO und, wo datengetrieben, RPO festlegen und mit der Leitung abstimmen; daraus die nötige Wiederanlaufkapazität ableiten.
• Kontinuitätsstrategien und Notfallpläne. Redundanz, Ersatzversorgung, Ausweichstandorte, manuelle Notbetriebsverfahren und definierte Wiederanlaufschritte hinterlegen.
• Krisen- und Notfallorganisation. Krisenstab, Alarmierungs- und Eskalationswege sowie die Meldekette zur zuständigen Behörde verbindlich regeln.
• Übung, Test und Verbesserung. Pläne regelmäßig üben und testen, Lehren dokumentieren und in die nächste Iteration zurückführen.

Sinnvoll ist, BCM mit der All-Gefahren-Risikoanalyse zu verzahnen statt es getrennt zu führen: Die Risikobewertung liefert die Szenarien, die BIA die Prioritäten, das BCM die Antworten. Wer bereits ein ISMS oder ein Notfallmanagement betreibt, kann Rollen, Taktung und Nachweislogik wiederverwenden.

Typische Fehler

1. BCM wird mit IT-Disaster-Recovery gleichgesetzt; Personal, Standort, Versorgung und Lieferkette fehlen.
2. RTO und RPO werden technisch gesetzt statt als Management-Entscheidung aus der BIA abgeleitet.
3. Die BIA wird einmalig erstellt und nicht fortgeschrieben, obwohl sich Prozesse und Abhängigkeiten ändern.
4. Notfallpläne existieren, werden aber nicht geübt; im Ernstfall greift niemand zu ihnen.
5. BCM und Risikoanalyse laufen getrennt, sodass Pläne nicht zu den real wesentlichen Szenarien passen.
6. Nachweise zur Wirksamkeit entstehen erst auf Nachfrage der Behörde statt aus dem laufenden Betrieb.

Risiken und Trade-offs

Ehrgeizige Wiederherstellungsvorgaben erhöhen die Resilienz, kosten aber Geld und Komplexität. Eine sehr kurze RTO verlangt Redundanz, Ersatzkapazität und eingeübte Verfahren; das ist eine Investitions- und damit Managemententscheidung, keine rein technische. Werden RTO und RPO dagegen zu großzügig gesetzt, ist der Plan billig, aber im Ernstfall wertlos.

Ein zweiter Trade-off betrifft Tiefe gegen Betreibbarkeit. Eine sehr detaillierte BIA und ein umfangreiches Planwerk wirken vollständig, werden aber selten gepflegt und veralten. Ein schlankes, regelmäßig geübtes BCM ist im Krisenfall meist wertvoller als ein dickes Handbuch. Drittens droht regulatorische Doppelarbeit: Cyber-Regime (BSIG im NIS2-Kontext) und physisches Regime (CER-Richtlinie und KRITIS-Dachgesetz) überschneiden sich bei Governance, Notfallorganisation und Nachweisen. Wer beide Welten getrennt managt, erzeugt Lücken und Mehraufwand zugleich.

Entscheidungspunkte

• Welche Dienste sind so kritisch, dass eine kurze RTO ihre Kosten rechtfertigt, und welche können länger ausfallen?
• Werden RTO und RPO als verbindliche Management-Vorgaben durch die Leitung freigegeben oder dem Fachbereich überlassen?
• Wird BCM in bestehende Managementsysteme (ISMS, Risikomanagement, Notfallmanagement) integriert oder separat geführt?
• Welche Übungs- und Testtiefe ist angemessen, und in welchem Turnus wird geübt?
• Wie wird die 24-Stunden-Meldefähigkeit für erhebliche Störungen organisatorisch in die Notfallorganisation eingebettet?

Praktische Empfehlungen

1. Beginnen Sie mit einer BIA der wenigen wirklich zeitkritischen Dienste und erweitern Sie schrittweise, statt alles zugleich zu erfassen.
2. Lassen Sie RTO und RPO je kritischem Dienst durch die Leitung freigeben und dokumentieren Sie die Begründung; so werden Wiederherstellungsvorgaben zu nachvollziehbaren Entscheidungen.
3. Verzahnen Sie BCM mit der All-Gefahren-Risikoanalyse, damit Notfallpläne zu den wesentlichen Szenarien passen; das KRITIS-Dachgesetz sieht eine wiederkehrende Risikobewertung vor (mindestens alle vier Jahre, bei Bedarf häufiger).
4. Üben und testen Sie Wiederanlauf- und Krisenszenarien regelmäßig und führen Sie die Lehren in die Pläne zurück.
5. Machen Sie Wirksamkeitsnachweise zum Nebenprodukt des Betriebs (BIA-Stand, Übungsprotokolle, Wiederanlaufzeiten) statt sie kurz vor Prüfungen zu erzeugen.
6. Nutzen Sie Synergien beider Regime: Wo zulässig, können Behörden auf Nachweise nach BSIG oder branchenspezifische Sicherheitsstandards (B3S) zurückgreifen, um Doppelnachweise zu vermeiden.

Relevante Normreferenzen

• Richtlinie (EU) 2022/2557 (CER-Richtlinie) vom 14. Dezember 2022 über die Resilienz kritischer Einrichtungen, zur Aufhebung der Richtlinie 2008/114/EG; ABl. L 333 vom 27.12.2022. Das exakte Inkrafttretensdatum ist an der amtlichen Quelle (EUR-Lex) zu verifizieren.
• KRITIS-Dachgesetz (nationale Umsetzung der CER-Richtlinie, physische Resilienz kritischer Anlagen); 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: Referenz für Business-Continuity-Managementsysteme (reference-only).
• BSI-Standard 200-4: Referenz für Business Continuity Management im Kontext des IT-Grundschutzes (reference-only).
• ISO 31000: Referenz für Risikomanagement (reference-only).
• IT-Grundschutz (BSI): Referenz für Bausteine zu Notfallmanagement (BCM) sowie physischer Sicherheit und Infrastruktur (INF).