Der BSI-Standard 200-4 beschreibt, wie eine Organisation ein Business Continuity Management System (BCMS) aufbaut und betreibt. Sein Ausgangspunkt ist eine praktische Frage: Welche Leistungen müssen nach einem schweren Ausfall weiterlaufen, welche Ressourcen brauchen sie, und wer entscheidet unter Zeitdruck? Die Antwort entsteht aus einer Business Impact Analyse (BIA), angemessenen Fortführungsstrategien, benutzbaren Plänen und Übungen. Der Standard ersetzt das ältere BSI-Dokument 100-4; die Webadresse dieses Artikels behält dessen Nummer zur Orientierung bei. Maßgeblich ist der BSI-Standard 200-4 im Original.
Ein BCMS verhindert nicht jeden Ausfall. Es sorgt dafür, dass sich die Organisation auf Unterbrechungen vorbereitet, Entscheidungen begründet und aus Tests lernt. Wer lediglich Backups besitzt, weiß noch nicht, ob Bestellungen, Patientenversorgung oder Lohnabrechnung während eines Ausfalls in akzeptabler Zeit fortgeführt werden können. Für die technische Perspektive ergänzen der Business-Continuity-Plan unter DSGVO und BSI und die BSI-Grundschutz-Methodik diesen Leitfaden.
Was 200-4 gegenüber 100-4 verändert
Das ältere Notfallmanagement nach BSI 100-4 war stark von einem umfassenden Zielbild geprägt. 200-4 bietet drei Stufen: Reaktiv-BCMS, Aufbau-BCMS und Standard-BCMS. Das erlaubt einen begrenzten Einstieg für Organisationen mit wenig Ressourcen und einen geregelten Ausbau. Die Stufen sind keine gesetzlich vorgeschriebene Reihenfolge. Entscheidend sind die tatsächlichen Auswirkungen eines Ausfalls, vorhandene Pflichten und das angestrebte Schutzniveau.
Beim Reaktiv-BCMS stehen existenzsichernde Sofortmaßnahmen im Vordergrund. Ein Aufbau-BCMS führt systematische Prozesse und regelmäßige Verbesserung ein. Das Standard-BCMS bildet nach Aussage des BSI die Anforderungen der ISO 22301:2019 ab; bei vollständiger Umsetzung kann eine Organisation die Reife für eine ISO-22301-Zertifizierung erreichen. Das ist weder ein Zertifikat durch bloße Verwendung der BSI-Vorlagen noch ein Nachweis, dass jede regulatorische Pflicht erfüllt ist. Der Standard betont ausdrücklich, dass Empfehlungen an die jeweilige Institution angepasst werden müssen.
Die BCMS-Stufe sollte nicht aus der Mitarbeiterzahl abgeleitet werden. Ein kleiner Betreiber einer regional unverzichtbaren Leistung kann strengere Wiederanlaufziele benötigen als ein größeres Unternehmen mit austauschbaren Tätigkeiten. Auch Auslagerungen, kritische Lieferanten und Arbeitszeiten beeinflussen den Aufwand. Halten Sie die Entscheidung schriftlich fest: Welche Prozesse sind im Geltungsbereich, warum wurde die Stufe gewählt, welche Risiken bleiben zunächst offen? So wird ein pragmatischer Einstieg nicht mit einem dauerhaft unvollständigen Sicherheitskonzept verwechselt.
Zuerst den Geltungsbereich und die Verantwortung bestimmen
Die Geschäftsleitung muss festlegen, für welche Produkte, Standorte und Leistungen das BCMS gilt und wer Entscheidungen treffen darf. Ein Prozessverzeichnis allein reicht nicht: Hinter einem Onlineshop stehen etwa Zahlungsabwicklung, Lager, Kundendienst, Identitätsverwaltung und externe Versanddienste. Für jede kritische Leistung braucht es einen fachlichen Eigentümer, einen technischen Ansprechpartner und einen Stellvertreter. Die BCM-Koordination organisiert die Methode, übernimmt aber nicht automatisch alle Geschäftsentscheidungen.
Praktisch beginnt die Erfassung mit wenigen durchgehenden Leistungsketten. Fragen Sie die Fachbereiche, was ohne ERP, Internetverbindung oder zentrale Anmeldefunktion noch möglich wäre. Erfassen Sie Abhängigkeiten in beide Richtungen: Welche Ressource braucht der Prozess, und welche anderen Prozesse hängen an derselben Ressource? Ein gemeinsam genutztes Rechenzentrum kann trotz scheinbar verschiedener Produkte einen einzigen Ausfallpunkt bilden. Diese Übersicht hilft später, das BSI-200-3-Risikomanagement mit den Folgen für den Betrieb zu verbinden.
Business Impact Analyse: Schaden über die Zeit verstehen
Die BIA bewertet die Folgen einer Unterbrechung, bevor einzelne Bedrohungen diskutiert werden. Ein Prozess kann nach zwei Stunden nur lästig, nach einem Tag vertragskritisch und nach drei Tagen existenzbedrohend sein. Bewerten Sie dafür mehrere Schadensarten: Versorgung und Sicherheit von Menschen, Rechts- und Vertragspflichten, finanzielle Verluste, Reputation sowie Folgeschäden bei Kunden. Wo Daten verarbeitet werden, gehört auch die Auswirkung auf betroffene Personen in die Betrachtung.
Erfassen Sie je Leistung eine maximal tolerierbare Unterbrechung, einen angestrebten Zeitpunkt für die Wiederaufnahme und den notwendigen Mindestbetrieb. Die Terminologie von BSI 200-4 und anderen Standards ist nicht immer deckungsgleich. Häufig verwendete Größen sind MTPD oder maximale tolerierbare Ausfallzeit, RTO als Ziel für die Wiederaufnahme, RPO als maximal akzeptierter Datenverlust bei IT-Systemen und MBCO als Mindestleistungsniveau. Ein RPO ist bei rein manuellen Abläufen nicht sinnvoll; bei einer Bestelldatenbank dagegen sehr wohl. Ziele sollten fachlich begründet sein und nicht aus dem vorhandenen Backup-Rhythmus abgeschrieben werden.
Ein Beispiel: Ein Händler kann Bestellungen vier Stunden lang telefonisch annehmen, aber erst nach Wiederherstellung des Warenbestands verbindlich zusagen. Dann unterscheidet die BIA zwischen Annahme, Zahlungsbestätigung und Lieferung. Ein IT-Team, das nur die Shop-Startseite wiederherstellt, erreicht womöglich keinen nutzbaren Geschäftsbetrieb. Legen Sie deshalb je Zeitfenster fest, welcher Teil der Leistung mindestens funktionieren muss. Prüfen Sie anschließend, ob Personal, Daten, Kommunikationskanäle und Dienstleister diese Zusage überhaupt tragen können.
Die BIA ist nicht die Risikoanalyse. Die BIA beschreibt, wie teuer oder gefährlich eine Unterbrechung wird; die Risikoanalyse prüft Ursachen und die Wahrscheinlichkeit beziehungsweise Plausibilität bestimmter Szenarien. Beide Sichtweisen gehören zusammen. Wer mit Ransomware beginnt, ohne die geschäftskritischen Leistungen zu kennen, schützt leicht das falsche System zuerst. Wer nur die BIA erstellt, übersieht dagegen, dass ein gemeinsamer Administratorzugang mehrere Prozesse gleichzeitig lahmlegen könnte.
Szenarien und Fortführungsstrategien auswählen
Untersuchen Sie realistische Szenarien für die priorisierten Ressourcen: Stromausfall, Brand, Ransomware, Netzstörung, Personalausfall und Ausfall eines Dienstleisters. Die Liste soll Entscheidungen auslösen, nicht möglichst lang werden. Für jeden kritischen Prozess beschreiben Sie eine Fortführungsstrategie. Das kann ein alternativer Standort, ein zweiter Lieferant, ein manueller Betrieb oder die priorisierte Wiederherstellung einer Anwendung sein. Das Konzept zur Hochverfügbarkeit im Rechenzentrum ist eine mögliche technische Maßnahme, ersetzt aber keine betriebliche Ersatzregelung.
Betrachten Sie in jeder Strategie die tatsächliche Durchführbarkeit. Ein Ersatzrechenzentrum hilft wenig, wenn beide Standorte denselben Identitätsdienst oder dieselbe Netzverbindung benötigen. Ein Zweitlieferant ist keine Ausweichmöglichkeit, wenn er keine kurzfristige Kapazität zugesagt hat. Ein Papierformular kann den Notbetrieb sichern, wenn anschließend festgelegt ist, wie Daten vollständig und fehlerarm ins Primärsystem zurückkehren. Solche Abhängigkeiten gehören in die Planung und später in die Übung.
Für Ransomware reicht die Zusage „Backup vorhanden“ besonders selten. Prüfen Sie, ob Sicherungen vom angegriffenen Umfeld getrennt sind, ob sich Schlüssel und Administratorzugänge ebenfalls wiederherstellen lassen und wie lange eine vollständige Rücksicherung dauert. Messen Sie den Zeitbedarf an der BIA, nicht am erfolgreichen Start eines einzelnen Servers. Bei hohem Schutzbedarf können unveränderliche oder offline verfügbare Kopien sinnvoll sein. Die konkrete Architektur hängt vom Bedrohungsbild und von den Wiederherstellungszielen ab.
Bei der Auswahl der Sicherungsstrategie hilft die 3-2-1-Regel mit Wiederherstellungstest als Ausgangspunkt. Entscheidend bleibt, welche Datenstände für einen brauchbaren Notbetrieb benötigt werden. Ein täglich gesicherter Produktkatalog kann ausreichen, während Zahlungs- und Auftragsdaten nur wenige Minuten Verlust vertragen. Auch die Reihenfolge ist wichtig: Wenn der Identitätsdienst erst nach der Bestelldatenbank wiederkommt, können Beschäftigte trotz intakter Daten nicht arbeiten. Notieren Sie deshalb nicht nur Backup-Ziele je System, sondern die Abhängigkeiten zwischen den Systemen und den Fachprozessen. Testen Sie nach der Rücksicherung stichprobenartig Vollständigkeit und Integrität der Daten. Das verhindert, dass ein scheinbar erfolgreicher Restore einen unbemerkten Fehler in den nächsten Betriebstag trägt.
Notfallorganisation und Alarmierung
Ein Plan funktioniert nur, wenn auch ohne normale Kommunikationsmittel klar ist, wer einen Notfall ausruft. Definieren Sie Schwellen für Eskalation, Vertretungen und Befugnisse: Wer darf den Betrieb eines betroffenen Systems stoppen, Kunden informieren oder einen Ersatzstandort aktivieren? Der Krisenstab trifft übergreifende Entscheidungen; Fach- und IT-Teams setzen abgestimmte Maßnahmen um. Ein Protokoll hält Lage, Annahmen, Beschlüsse und nächste Prüfpunkte fest. Es hilft später bei der Auswertung und verhindert widersprüchliche Anweisungen während eines längeren Vorfalls.
Kontaktdaten und Notfallhandbuch müssen auch dann erreichbar sein, wenn der zentrale Dateiablageort, E-Mail und Single Sign-on ausfallen. Eine gepflegte Offline-Kopie oder ein technisch getrenntes System kann dies ermöglichen. Prüfen Sie den Zugriff mit den tatsächlich vorgesehenen Personen. Ein ausgedruckter Plan mit veralteten Telefonnummern ist ebenso unbrauchbar wie ein aktueller Plan in einem verschlüsselten Laufwerk. Sensible Informationen in Offline-Kopien brauchen wiederum Zugangsschutz und einen geregelten Austausch bei Änderungen.
Die Kommunikation ist ein eigener Prozess. Mitarbeiter benötigen klare Arbeitsanweisungen, Kunden möglicherweise eine Aussage zu Ausfällen, Behörden unter Umständen formelle Meldungen. Bereiten Sie dafür Verantwortlichkeiten und erreichbare Kanäle vor, aber formulieren Sie keine starre Meldung für jeden Vorfall. Bei einer Störung ohne personenbezogene Daten gelten andere Anforderungen als bei einer Datenschutzverletzung. Das Verfahren für eine DSGVO-Datenpanne sollte deshalb mit dem BCMS verknüpft, aber gesondert geprüft werden.
Geschäftsfortführung und Wiederanlauf getrennt planen
Geschäftsfortführung bedeutet, eine Mindestleistung während des Ausfalls zu erbringen. Wiederanlauf beschreibt die Rückkehr zum Regelbetrieb. Für einen Händler könnte der Notbetrieb telefonisch erfasste Aufträge und begrenzte Lagerausgabe erlauben; der Wiederanlauf umfasst Datenabgleich, erneute Zahlungsfreigabe und die Rückkehr in den Webshop. Schreiben Sie pro kritischem Prozess die auslösenden Bedingungen, Aufgaben, Reihenfolge, benötigten Ressourcen, Verantwortlichen und Abbruchkriterien auf. Geben Sie auch an, welche Daten beim Wechsel zwischen Ersatz- und Primärverfahren verloren gehen oder doppelt entstehen können.
Vermeiden Sie Pläne, die nur einen Idealzustand voraussetzen. Was geschieht, wenn der erste Stellvertreter fehlt oder der Cloud-Dienstleister selbst betroffen ist? Welche Entscheidung ist möglich, bevor die Ursache des Ausfalls bekannt ist? Ein kurzer, geübter Plan mit überprüften Kontakten ist im Ernstfall wertvoller als ein umfangreiches Handbuch voller ungetesteter Annahmen. Gleichzeitig muss die Dokumentation ausreichend präzise sein, damit ein anderes Team die Maßnahme ausführen kann. Diese Balance zeigt sich erst im Test.
Übungen: aus Befunden Maßnahmen machen
BSI 200-4 verlangt eine geplante Überprüfung und Verbesserung des BCMS; ein pauschaler gesetzlicher Jahresturnus für jede Organisation und jede Übungsform folgt daraus nicht. Planen Sie Häufigkeit und Tiefe nach Kritikalität, Veränderungen und Vorgaben, denen Ihre Organisation tatsächlich unterliegt. Ein Tabletop kann Zuständigkeiten und Entscheidungen prüfen. Ein technischer Restore zeigt, ob Sicherungen funktionieren. Eine funktionale Übung verknüpft Teams und Ersatzprozesse. Eine Vollübung stellt größere Teile einer realen Unterbrechung nach und benötigt entsprechend mehr Vorbereitung.
Vor jeder Übung stehen Ziel, Umfang, Sicherheitsgrenzen und Beobachtungskriterien fest. Bei einem Restore kann das Ziel sein, einen definierten Datenstand innerhalb einer bestimmten Frist nutzbar bereitzustellen. Halten Sie Start- und Endzeit, fehlende Berechtigungen, Datenabweichungen und Abhängigkeiten fest. Werten Sie nicht nur aus, ob die Technik gestartet ist, sondern ob der Fachprozess wieder arbeiten konnte. Beschließen Sie für jeden Befund einen Verantwortlichen und Termin; prüfen Sie die Umsetzung in der nächsten Übung. Das ältere BSI-Schulungsmaterial zu Tests und Übungen erläutert diese Auswertung anschaulich, stammt aber aus der 100-4-Methodik.
Schnittstelle zu DSGVO und NIS2
Artikel 32 DSGVO verlangt unter anderem, Verfügbarkeit personenbezogener Daten und Zugang nach einem physischen oder technischen Zwischenfall rasch wiederherstellen zu können sowie Maßnahmen regelmäßig zu überprüfen. BSI 200-4 kann die organisatorische und technische Vorbereitung dafür strukturieren. Ob die Maßnahmen angemessen sind, hängt jedoch vom konkreten Risiko für betroffene Personen, Stand der Technik, Kosten und Art der Verarbeitung ab. Ein BCMS-Plan allein belegt weder die Angemessenheit sämtlicher Sicherheitsmaßnahmen noch die Einhaltung aller DSGVO-Pflichten.
Bei einem Sicherheitsvorfall müssen Kontinuität und Meldungen parallel laufen. Ein unterbrochener Dienst ist nicht automatisch eine meldepflichtige Datenschutzverletzung. Wenn personenbezogene Daten betroffen sind, ist das Risiko für natürliche Personen nach den Artikeln 33 und 34 DSGVO gesondert zu beurteilen. Notieren Sie deshalb im Krisenprotokoll, wann das Team welche Tatsachen kannte und wer die Datenschutzbewertung übernommen hat. Das erleichtert eine fristgerechte Entscheidung, ohne die Wiederherstellung zu verzögern.
NIS2 und die deutsche Umsetzung verlangen für betroffene Einrichtungen unter anderem Maßnahmen zur Aufrechterhaltung des Betriebs, Backup-Management und Krisenmanagement. Der Leitfaden zur NIS2-Umsetzung in Deutschland erläutert den Anwendungsbereich; die NIS2-Meldepflichten gehören in eine eigene Vorfallroutine. BSI 200-4 ist dafür eine nützliche Methode, aber keine automatische Erfüllung der gesetzlichen Anforderungen. Prüfen Sie insbesondere sektorale Vorgaben und die tatsächlich zuständige Aufsicht.
Ein tragfähiger Start in acht Wochen
Eine kleine Organisation kann mit einer begrenzten, überprüfbaren Leistungskette beginnen. In der ersten Phase benennt sie Eigentümer, Geltungsbereich und Ausfallkriterien. Danach führt sie mit den Fachbereichen eine BIA durch und gleicht RTO und Mindestbetrieb mit den vorhandenen IT- und Personalressourcen ab. Anschließend wählt sie für zwei oder drei kritische Szenarien Strategien, schreibt Alarmierungs- und Fortführungsanweisungen und testet mindestens eine zentrale Annahme. Die acht Wochen sind ein Arbeitsbeispiel, keine vom BSI oder Gesetz vorgeschriebene Frist.
Der erste Test sollte eine konkrete Frage beantworten: Kann der Betrieb den priorisierten Prozess mit den verfügbaren Personen und Daten wirklich fortführen? Falls nein, ist das ein nützlicher Befund. Ändern Sie dann Strategie, Ressourcen oder Zielwerte und lassen Sie die Geschäftsleitung das verbleibende Risiko entscheiden. Wiederholen Sie den Zyklus bei neuen Dienstleistungen, größeren IT-Änderungen oder wichtigen Erkenntnissen aus Vorfällen. So wächst das BCMS mit der Organisation, statt als unveränderte Mappe im Schrank zu liegen.
Für die spätere Pflege sollten die Beteiligten Änderungen in den regulären Betriebsprozessen melden können. Eine neue Zahlungsplattform, der Wechsel des Hosting-Anbieters oder eine umgestellte Schichtplanung können einen bis dahin brauchbaren Fortführungsplan entwerten. Verknüpfen Sie daher Freigaben für solche Änderungen mit einer kurzen Frage nach Auswirkungen auf BIA, Kontakten, Ersatzverfahren und Wiederanlaufreihenfolge. Nicht jede Änderung erfordert eine vollständige Neubewertung; sie braucht aber einen nachvollziehbaren Entscheid. Bei einem tatsächlichen Notfall dokumentieren Sie Abweichungen vom Plan und übertragen die Erkenntnisse nach der Stabilisierung in die nächste Version. So bleiben Dokumentation und gelebter Betrieb beieinander.
Häufige Fragen
Ist BSI 200-4 gesetzlich verpflichtend?
Der Standard selbst ist nicht pauschal für alle Unternehmen vorgeschrieben. Konkrete Gesetze, Aufsichtsanforderungen oder Verträge können wirksames Kontinuitätsmanagement verlangen; BSI 200-4 ist dann ein möglicher methodischer Weg. Prüfen Sie die Pflichten für Ihre Einrichtung und Branche gesondert.
Muss jede Organisation alle drei Stufen durchlaufen?
Nein. Wählen Sie eine Zielstufe, die zu Folgen eines Ausfalls und Ihren Verpflichtungen passt. Ein Reaktiv-BCMS kann Einstieg sein; wer ein ausgereiftes Managementsystem benötigt, kann unmittelbar auf ein Standard-BCMS hinarbeiten. Halten Sie Übergangslücken und nächste Ausbauschritte fest.
Sind RTO und maximale tolerierbare Ausfallzeit dasselbe?
Nein. Die maximal tolerierbare Ausfallzeit beschreibt eine fachliche Grenze, während das RTO ein geplantes Wiederanlaufziel ist. Das Ziel muss genügend Abstand zu der Grenze lassen, um Ungewissheit und Folgearbeiten aufzufangen. Beide Werte müssen zu Ressourcen und realen Tests passen.
Reicht ein erfolgreicher Backup-Test?
Ein Backup-Test prüft einen wichtigen technischen Teil. Ein BCMS muss darüber hinaus Menschen, Lieferanten, Kommunikation, Mindestbetrieb und Rückkehr zum Regelbetrieb berücksichtigen. Erst ein Test der ganzen Leistungskette zeigt, ob die Wiederherstellung für Kunden oder Nutzer rechtzeitig wirksam wird.