BCM-Leitfaden: Business Continuity Management aufbauen

Was leistet BCM, und wo beginnt es?

Jede Schutzmaßnahme kann versagen. Business Continuity Management setzt genau dort an, wo Prävention endet: Es beantwortet nicht die Frage, wie ein Ausfall verhindert wird, sondern wie lange die Organisation ihn aushält, welche Leistungen sie in dieser Zeit trotzdem erbringt und wie sie in den Normalbetrieb zurückkehrt. Bezugspunkt sind Geschäftsprozesse und die Leistungen, die Kunden, Aufsicht und Lieferkette erwarten, nicht einzelne Systeme.

Diese Unterscheidung klingt akademisch und ist es nicht. Ein IT-Wiederanlaufplan beschreibt, wie ein Server wieder startet. Ein Kontinuitätsplan beschreibt, wie die Auftragsannahme weiterläuft, während der Server nicht startet. Disaster Recovery ist deshalb ein Teilergebnis des BCM, nicht sein Zweck. Wer beides gleichsetzt, erlebt in der ersten realistischen Übung den typischen Befund: Das System läuft wieder, der Geschäftsprozess steht trotzdem, weil Papierformulare, Freigabeberechtigungen oder ein Dienstleister fehlen.

Ebenso wenig ist BCM ein Unterkapitel des Informationssicherheits-Managementsystems. Ein ISMS steuert Risiken für Vertraulichkeit, Integrität und Verfügbarkeit und arbeitet überwiegend vorbeugend; BCM übernimmt den Fall, der trotzdem eintritt. Beide nutzen dieselben Vorarbeiten, nämlich Prozesslandkarte, Asset- und Dienstleisterinventar und den Schutzbedarf im Bereich Verfügbarkeit, und liefern einander Eingaben, ersetzen sich aber nicht.

Der Zyklus folgt der Logik anderer Managementsysteme. Anders ist die letzte Phase: Sie ist nicht optional. Ein Plan, der nie geübt wurde, ist eine Vermutung.

Warum ist die Business-Impact-Analyse das Fundament?

Die Business-Impact-Analyse (BIA) ist der Schritt, an dem sich entscheidet, ob ein Kontinuitätskonzept trägt. Sie fragt nicht, wodurch ein Ausfall entsteht (das leistet die Risikoanalyse), sondern was er kostet, ab wann er untragbar wird und welche Ressourcen wieder verfügbar sein müssen, damit der Prozess weiterläuft. Alles Weitere baut auf ihrem Ergebnis auf: Ohne BIA ist jede Strategie eine Vermutung und jeder Zielwert eine Zahl ohne Herkunft.

Der Ablauf ist in allen gängigen Vorgehensweisen im Kern derselbe:

1. Geschäftsprozesse erfassen und abgrenzen, ausgehend von den Leistungen gegenüber Kunden, Aufsicht und Lieferkette, nicht von der Systemlandschaft.
2. Den Schadensverlauf je Prozess über eine Zeitachse bewerten, gestaffelt nach Ausfalldauer statt als einzelner Wert.
3. Zeitvorgaben ableiten und mit den Prozessverantwortlichen abstimmen.
4. Benötigte Ressourcen und Abhängigkeiten erheben, einschließlich der externen.
5. Ergebnisse konsolidieren, Widersprüche auflösen und durch die Leitung freigeben lassen.

Der letzte Schritt wird am häufigsten übersprungen und ist der wichtigste. Die BIA enthält Zusagen, deren Einhaltung Geld kostet: Redundanz, Ersatzkapazität, Bereitschaftsdienste, vertraglich zugesicherte Wiederanlaufzeiten von Dienstleistern. Wer diese Zusagen nicht durch die Geschäftsleitung freigeben lässt, hat kein Konzept, sondern eine Wunschliste.

Bewertet wird der Schaden mehrdimensional. Üblich sind finanzielle Folgen wie Umsatzausfall, Vertragsstrafen und Mehrkosten des Notbetriebs, rechtliche und regulatorische Folgen wie verletzte Melde- oder Aufbewahrungspflichten, die Beeinträchtigung der Leistungserbringung, Reputationsschäden gegenüber Kunden, Aufsicht und Öffentlichkeit sowie Gefährdungen von Personen und Umwelt. Es kommt auf die Zeitachse an: erst nach wenigen Stunden, dann nach einem Tag, nach mehreren Tagen, nach einer Woche. Erst dieser Verlauf zeigt, an welcher Stelle der Schaden sprunghaft ansteigt; dort liegt die Grenze der Tolerierbarkeit.

Die fachliche Bewertung kommt zwingend aus den Fachbereichen. Wird die Erhebung von der IT ausgefüllt, entsteht eine Systemliste statt einer Prozessanalyse. Ebenso verliert die Analyse ihren Zweck, wenn am Ende alle Prozesse zeitkritisch sind: Eine Priorisierung, die nichts ausschließt, priorisiert nicht.

Ein fester Aktualisierungsturnus ist nirgends vorgegeben. Bewährt hat sich eine regelmäßige Überprüfung in festgelegtem Abstand, ergänzt um anlassbezogene Aktualisierungen bei wesentlichen Änderungen: neue oder umgebaute Prozesse, ein Standortwechsel, der Wechsel eines kritischen Dienstleisters, Zukäufe oder größere Umstellungen in der IT. Eine BIA, die nach der Ersterhebung liegen bleibt, beschreibt nach zwei Jahren ein Unternehmen, das es so nicht mehr gibt, und trägt trotzdem die Zeitvorgaben, an denen im Ereignisfall gemessen wird.

Was bedeuten MTA, Wiederanlaufzeit und maximaler Datenverlust?

Aus der BIA entstehen die Kennzahlen, an denen später alles gemessen wird. Die deutschen und englischen Begriffe stehen nebeneinander im Gebrauch und werden regelmäßig verwechselt.

Das Mindestbetriebsniveau (international MBCO, Minimum Business Continuity Objective) ist dabei die am häufigsten ausgelassene Größe und zugleich die, die eine Kontinuitätsstrategie überhaupt erst bezahlbar macht. Ohne sie wird stillschweigend der volle Leistungsumfang zum Wiederanlaufziel, und die Vorsorge wird für einen Zustand ausgelegt, den im Notbetrieb niemand verlangt. Die Festlegung gehört fachlich zum Prozessverantwortlichen, nicht zur IT.

Normative Zielwerte gibt es für keine dieser Größen. Weder ISO 22301 noch der BSI-Standard 200-4 geben Zahlen vor; beide verlangen, dass die Organisation ihre Werte herleitet, begründet und einhält. Jeder Wert, der aus einer Vorlage übernommen wird, erzeugt eine Zusage ohne Deckung.

Drei Konsistenzprüfungen entscheiden über die Belastbarkeit:

• Die Wiederanlaufzeit muss mit Abstand unterhalb der maximal tolerierbaren Ausfallzeit liegen. Sind beide gleich, ist jede Verzögerung in der Bewältigung bereits ein untragbarer Schaden.
• Jeder Wert muss technisch und personell hinterlegt sein. Backup-Frequenz, Redundanz, Ersatzbeschaffungszeit, Bereitschaft und Qualifikation des Personals müssen den Wert tragen. Der maximal tolerierbare Datenverlust ist unmittelbar eine Anforderung an die Sicherungsfrequenz.
• Abhängige Dienste erben die strengste Anforderung. Ein gemeinsam genutzter Basisdienst muss den Wert des kritischsten Prozesses erfüllen, der auf ihm aufsetzt.

Der dritte Punkt fällt in Übungen am häufigsten auf. Eine Fachanwendung mit kurzer Wiederanlaufzeit ist wertlos, wenn der Verzeichnisdienst, an dem ihre Anmeldung hängt, deutlich länger braucht, oder wenn die Netzanbindung an den Ausweichstandort erst am zweiten Tag verfügbar ist. Die Zeitvorgaben eines Prozesses sind deshalb entlang seiner gesamten Kette zu prüfen, nicht nur an der Anwendungsgrenze.

Welche Ressourcen und Abhängigkeiten muss BCM erfassen?

Je zeitkritischem Prozess wird erhoben, was er tatsächlich benötigt. Sechs Klassen haben sich als Raster bewährt: Personal mit bestimmten Qualifikationen und Berechtigungen, Gebäude und Arbeitsplätze, Anwendungen und die darunterliegende Infrastruktur, Betriebsmittel und Vorprodukte, Informationen und Datenbestände sowie interne und externe Dienstleister.

Bei den Dienstleistern liegt die größte Lücke zwischen Plan und Vertrag. Notfallpläne planen Dienstleister regelmäßig fest ein, ohne dass diese vertraglich zu etwas verpflichtet wären. Ein Servicevertrag mit Reaktionszeiten ist keine Zusage über eine Wiederanlaufzeit, und eine Zusage im Normalbetrieb ist keine Zusage im großflächigen Störungsfall. Zu prüfen sind deshalb drei Dinge: was vertraglich zugesichert ist, ob der Dienstleister die Zusage im eigenen Kontinuitätskonzept hinterlegt hat und was geschieht, wenn er selbst betroffen ist. Wo mehrere kritische Prozesse an demselben Anbieter hängen, entsteht ein Konzentrationsrisiko, das gesondert zu bewerten ist.

Welche Kontinuitätsstrategien gibt es?

Die häufigste Abkürzung besteht darin, sofort Pläne zu schreiben. Die umgekehrte Reihenfolge trägt weiter. Zuerst wird je Ressourcenklasse entschieden, mit welcher Option ein Ausfall überbrückt wird. Erst danach lohnt sich ein Plan, denn ein Plan ist die Ausformulierung einer bereits getroffenen Entscheidung.

Die letzte Zeile ist keine Kapitulation, sondern eine legitime und dokumentierte Entscheidung. Sie gehört zur Restrisikobetrachtung und muss durch die Leitung getragen sein – sonst wird sie im Ereignisfall zur Überraschung.

Bewertet werden die Optionen an vier Kriterien: Erreicht die Option die Zeitvorgabe aus der BIA? Was kostet sie im Aufbau und im Betrieb? Lässt sie sich mit dem vorhandenen Personal tatsächlich betreiben? Und welches Restrisiko bleibt? Das Ergebnis ist eine begründete Auswahl je Ressourcenklasse, nicht eine Sammlung von Maßnahmen.

Was gehört in einen Notfallplan?

Aus den Strategien entstehen die Pläne. Üblich ist eine Dreiteilung: der Geschäftsfortführungsplan beschreibt den Notbetrieb, der Wiederanlaufplan die Rückkehr in einen definierten Betriebszustand und der Wiederherstellungsplan die Rückkehr in den Normalbetrieb. Dazu kommt die Notfallorganisation mit Alarmierung, Eskalationswegen, Krisenstab, benannten Rollen samt Vertretung sowie Kommunikationswegen nach innen, zu Kunden, zu Dienstleistern und, wo einschlägig, zur Aufsicht. Die Anleitung Business Continuity Plan erstellen führt von den Zeitvorgaben der Business-Impact-Analyse bis zur geübten und freigegebenen Fassung.

Für die Qualität eines Plans sind weniger sein Umfang als fünf nüchterne Eigenschaften entscheidend:

• Handlungsanleitend statt beschreibend. Wer im Ereignisfall liest, braucht Schritte, Entscheidungspunkte und Namen, keine Prosa über Ziele des Kontinuitätsmanagements.
• Aktuelle Kontaktdaten. Veraltete Rufnummern sind der banalste und häufigste Grund, weshalb eine Alarmierung scheitert.
• Verfügbar außerhalb der betroffenen Umgebung. Notfalldokumentation, die ausschließlich in dem System liegt, dessen Ausfall sie behandelt, existiert im Ereignisfall nicht.
• Auf Vertretungen ausgelegt. Pläne, die nur die Stammbesetzung tragen kann, versagen bei Krankheitswellen und in der Urlaubszeit. Szenarien, die Personalausfall zum Auslöser haben, sind ausdrücklich mitzudenken.
• Nachgeführt bei Änderungen. Standortwechsel, neue Anwendungen, ein neuer kritischer Dienstleister oder ein umgebauter Prozess machen Pläne stillschweigend unbrauchbar.

Wie weist man die Wirksamkeit eines BCM nach?

Geübt wird abgestuft. Jedes Format hat einen eigenen Zweck, und der Aufwand steigt mit der Aussagekraft.

Eine Übung ohne definiertes Ziel ist eine Veranstaltung. Vorbereitet gehören: das Übungsziel, ein realistisches Szenario, ein Drehbuch mit Einspielungen, benannte Beobachter, festgelegte Abbruchkriterien und die Frage, welche Annahme genau widerlegt werden soll. Der Erkenntniswert liegt im Scheitern einzelner Annahmen, nicht im reibungslosen Ablauf; eine Übung, in der alles funktioniert, war meist zu einfach angelegt. Wie Rollen, Einspielungen und erwartete Entscheidungen zusammenpassen, zeigt das Drehbuch für eine Tabletop-Notfallübung an einem durchgespielten Szenario bis zur Nachbereitung.

Ebenso wichtig ist die Auswertung. Aus jeder Übung entstehen ein Bericht, benannte Abweichungen, Maßnahmen mit Verantwortlichem und Termin sowie die Nachverfolgung bis zum Abschluss. Ergibt eine Übung, dass eine zugesagte Wiederanlaufzeit nicht erreichbar ist, gibt es zwei zulässige Reaktionen: die Auslegung verbessern oder den Zielwert korrigieren und die geänderte Zusage in der BIA nachziehen. Den Wert unverändert stehen zu lassen, ist keine.

Einen normativ vorgegebenen Übungsturnus gibt es nicht. Üblich ist ein Übungsprogramm, das Formate kombiniert und den Turnus nach Kritikalität des Prozesses und Änderungshäufigkeit festlegt. Für Prüfungen zählt nicht der gewählte Abstand, sondern dass er begründet, dokumentiert und tatsächlich eingehalten wird.

ISO 22301 oder BSI-Standard 200-4: welcher Weg passt?

Zwei Bezugspunkte prägen die Praxis in Deutschland. Beide verlangen dieselben Kernelemente aus Analyse, Strategie, Plänen und Übungen; sie unterscheiden sich im Einstieg und in der Nachweisform.

Die Schreibweise lautet ISO 22301, nicht ISO/IEC 22301: Anders als bei ISO/IEC 27001 ist die IEC hier nicht Mitherausgeber. Die höchste Ausbaustufe des BSI-Standards ist inhaltlich auf das Anspruchsniveau von ISO 22301 ausgelegt; zum jeweils aktuellen Prüf- und Testierungsangebot ist das BSI die verbindliche Quelle.

Die Entscheidung fällt entlang der Frage, wer den Nachweis verlangt. Wo Kunden oder Aufsicht einen international anerkannten Nachweis der Kontinuitätsfähigkeit erwarten, führt der Weg über ISO 22301; das gilt in der Lieferkette großer Industrie- und Finanzkunden und bei vertraglich zugesagten Verfügbarkeiten. Organisationen, die überwiegend im deutschen Behörden- und Aufsichtsumfeld arbeiten oder bereits nach IT-Grundschutz vorgehen, wählen häufiger den BSI-Standard, nicht zuletzt wegen des gestuften Einstiegs.

Welche Kontinuitätspflichten stellen NIS2 und DORA?

Kontinuitätsvorsorge ist längst nicht mehr nur eine Frage guter Praxis. Mehrere Rechtsakte verlangen sie ausdrücklich, ohne dabei ein bestimmtes Rahmenwerk vorzuschreiben.

NIS2. Die Richtlinie (EU) 2022/2555 ist in Deutschland über das BSI-Gesetz umgesetzt. Der Maßnahmenkatalog des § 30 Absatz 2 BSIG nennt in Nummer 3 die Aufrechterhaltung des Betriebs mit Backup-Management, Wiederherstellung und Krisenmanagement; die Nummern 1 bis 10 entsprechen dabei den Buchstaben a bis j des Artikels 21 Absatz 2 der Richtlinie. Der Katalog ist ausdrücklich als Mindestumfang formuliert. Für betroffene Einrichtungen heißt das: Kontinuitätsvorsorge ist Gegenstand der Aufsicht, und die Geschäftsleitung hat die Maßnahmen umzusetzen und ihre Umsetzung zu überwachen. Welches Vorgehen dafür gewählt wird, gibt das Gesetz nicht vor: Ein BCMS nach ISO 22301 oder BSI-Standard 200-4 ist ein Weg dorthin, keine Pflicht.

DORA. Die Verordnung (EU) 2022/2554 richtet sich an Finanzunternehmen und ist unmittelbar anwendbar. Sie behandelt die Betriebskontinuität als Bestandteil des IKT-Risikomanagements in Kapitel II (Artikel 5 bis 16) und wird dort an zwei Stellen konkret: Artikel 11 verlangt eine umfassende IKT-Geschäftsfortführungsleitlinie – sie darf eigenständig sein oder fester Bestandteil der allgemeinen Geschäftsfortführungsleitlinie – samt Regelungen, Plänen und Verfahren, die die Fortführung kritischer oder wichtiger Funktionen sichern, Schäden begrenzen, Eindämmungspläne unverzüglich aktivieren, vorläufige Auswirkungen einschätzen und Krisenkommunikation festlegen. Artikel 12 verlangt Richtlinien und Verfahren zur Datensicherung mit festgelegtem Umfang und einer Mindesthäufigkeit nach Kritikalität, dazu Wiedergewinnungs- und Wiederherstellungsverfahren, die regelmäßig zu testen sind. In Kapitel IV (Artikel 24 bis 27) tritt das Programm zum Testen der digitalen operationalen Resilienz hinzu. Der Unterschied zur allgemeinen BCM-Praxis liegt weniger im Inhalt als im Nachweisdruck: Erprobung ist hier kein empfohlener Turnus, sondern regulatorisch verankert, und die Ergebnisse sind gegenüber der Aufsicht darstellbar zu halten.

Beide Regelwerke setzen kein bestimmtes Rahmenwerk voraus und formulieren ihre Anforderungen risiko- und verhältnismäßigkeitsbezogen. Wer bereits ein BCMS betreibt, erfüllt damit einen erheblichen Teil der Substanz. Was regelmäßig fehlt, ist nicht die Vorsorge, sondern deren Darstellbarkeit: der Nachweis, dass die Maßnahmen beschlossen, umgesetzt, geprüft und wirksam sind.

Nachweise mehrfach nutzen

BCM erzeugt Belege, die weit über das eigene Managementsystem hinaus verwendbar sind. Der Aufwand entsteht ohnehin; ob er sich mehrfach auszahlt, entscheidet die Struktur der Ablage.

Damit ein Nachweis mehrfach trägt, braucht er wenige, aber verlässliche Metadaten: Gegenstand, Geltungsbereich, Stand und Gültigkeit, Verantwortlicher und der Bezug zu der Anforderung, die er belegt. Fehlen sie, entsteht das übliche Muster: je Regelwerk eine eigene Ablage, dieselbe Übung dreimal beschrieben, und bei der nächsten Prüfung die Frage, welche Fassung gilt.

Der zweite Hebel ist ein gemeinsamer Bestand. Prozesse, Systeme, Dienstleister und Verantwortliche sind für BCM, ISMS und Risikomanagement dieselben; unterschiedlich sind nur die Bewertungsachsen. Wer sie getrennt führt, pflegt dieselbe Änderung mehrfach und hat nach dem ersten Jahr drei Wahrheiten.

Woran scheitern Kontinuitätskonzepte?

Die Befunde ähneln sich über Branchen hinweg. Sechs davon sind so verbreitet, dass sich eine gezielte Prüfung lohnt:

• Zeitvorgaben aus dem Wunschdenken. Die Fachbereiche nennen kurze Wiederanlaufzeiten, weil kurz besser klingt; technisch hinterlegt ist keine davon.
• Pläne für Systeme statt für Prozesse. Der Wiederanlauf der Anwendung ist beschrieben, die Fortführung des Geschäftsprozesses ohne sie nicht.
• Dienstleister ohne Verpflichtung. Der Plan rechnet fest mit externer Unterstützung, der Vertrag sieht sie nicht vor.
• Notfalldokumentation im betroffenen System. Pläne, Kontaktlisten und Zugangsdaten liegen ausschließlich dort, wo der Ausfall stattfindet.
• Übungen ohne Auswertung. Es wird geübt, aber es entstehen keine benannten Abweichungen, keine Maßnahmen und keine Nachverfolgung.
• Keine Nachpflege nach Änderungen. Neue Standorte, Anwendungen oder Dienstleister ziehen keine Aktualisierung von BIA, Strategie und Plänen nach sich.

Wie Sie vorgehen

1. Geltungsbereich und Mandat klären. Legen Sie fest, welche Standorte, Leistungen und Gesellschaften einbezogen sind, und holen Sie ein schriftliches Mandat der Geschäftsleitung ein.
2. Mit einer schlanken BIA beginnen. Erfassen Sie zunächst die Prozesse mit erkennbarer Zeitkritikalität, statt die gesamte Prozesslandkarte in einem Zug zu bewerten.
3. Zeitvorgaben gegen die Realität prüfen. Jeder Wert braucht eine technische und personelle Hinterlegung. Werte ohne Deckung streichen oder korrigieren Sie sofort.
4. Abhängigkeitsketten aufnehmen, insbesondere gemeinsam genutzte Basisdienste und externe Dienstleister.
5. Strategien entscheiden und freigeben lassen, je Ressourcenklasse, mit ausgewiesenen Kosten und ausgewiesenem Restrisiko.
6. Pläne und Notfallorganisation aufsetzen, knapp, handlungsanleitend und außerhalb der betroffenen Umgebung verfügbar.
7. Ein Übungsprogramm festlegen und mit dem einfachsten Format beginnen. Eine Plandurchsprache in diesem Quartal ist mehr wert als eine Vollübung, die im nächsten Jahr geplant bleibt.
8. Nachweise strukturiert ablegen und mit den Anforderungen verknüpfen, gegenüber denen sie später vorgelegt werden.

Für Finanzunternehmen, die dieselben Analysen, Maßnahmen und Belege zugleich gegenüber der Aufsicht führen müssen, beschreibt unsere Seite zu DORA, wie sich das auf einem gemeinsamen Datenmodell abbilden lässt.

Dieser Beitrag ist eine allgemeine Einordnung und ersetzt keine Rechtsberatung. Maßgeblich sind ISO 22301, der BSI-Standard 200-4 sowie das jeweils geltende Aufsichtsrecht, insbesondere das BSI-Gesetz und die Verordnung (EU) 2022/2554.

Wie sich die Abhängigkeiten dauerhaft führen lassen

Der Leitfaden macht die Business-Impact-Analyse zum Fundament, und genau dort entsteht das Folgeproblem: Die Ressourcenliste eines Prozesses ist der Teil der BIA, der am schnellsten veraltet, und die nächste Erhebung ist ein Jahr entfernt. In Rizzqo wird diese Liste nicht erhoben, sondern gelesen.

Ein zeitkritischer Prozess ist ein primärer Wert, und die Anwendungen, Systeme, Standorte, Dienstleister und Personalfunktionen, die ihn tragen, hängen als unterstützende Werte darunter, mit benannten Verantwortlichen. Die Abhängigkeit reicht über mehrere Stufen, sodass auch ein Vorlieferant sichtbar wird, der drei formal unabhängige Anbieter trägt. Der Anspruch des Prozesses an die Verfügbarkeit wird entlang derselben Kette vererbt, was die Ableitung von Wiederanlaufvorgaben begründbar macht: Der Betreiber eines Zwischensystems sieht, welcher Prozess am Ende von ihm abhängt.

Rizzqo trägt diese Struktur, die auch die Informationssicherheit braucht, und die Nacharbeit: Feststellungen aus einer Übung laufen als Maßnahmen mit hinterlegter Risikominderung weiter, die erst mit dem Abschluss wirksam wird.