Business Continuity Plan: BSI 200-4 und DSGVO Art. 32

In einem Satz. Ein Business Continuity Plan (BCP) nach BSI-Standard 200-4 kann die risikobasierte Wiederherstellung nach DSGVO Artikel 32 Absatz 1 Buchstabe c konkretisieren: die “Fähigkeit, die Verfügbarkeit der personenbezogenen Daten und den Zugang zu ihnen bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen” — RTO (Recovery Time Objective) und RPO (Recovery Point Objective) sind dabei Planungsgrößen, keine gesetzlichen Einheitswerte.

BSI-Standard 200-4 (Version 1.0, Juni 2023) hat den älteren BSI-Standard 100-4 abgelöst und definiert ein dreistufiges Reifegradmodell: Reaktiv-BCMS, Aufbau-BCMS und Standard-BCMS. Der Standard zeigt Schnittstellen zum IT-Grundschutz und zum Risikomanagement; ob weitere gesetzliche Pflichten gelten, ist je nach Einrichtung und Sektor gesondert zu prüfen.

Für den Sicherheitsrahmen siehe DSGVO Artikel 32 Sicherheit. Für die NIS2-Pflichten NIS2 Umsetzung Deutschland. Der vollständige Standard steht beim BSI zum BCM-Standard 200-4 bereit; die zugrundeliegende Verfügbarkeitspflicht ergibt sich aus Art. 32 DSGVO.

Wichtige Punkte

• BSI-Standard 200-4 löst 100-4 ab und bietet drei Reifegrade (Reaktiv, Aufbau, Standard).
• DSGVO Artikel 32 Absatz 1 Buchstabe c fordert “rasche Wiederherstellung” — BCP liefert RTO/RPO als Beweis.
• Business Impact Analyse (BIA) ist der Kern: jede Geschäftsprozess wird nach MTPD (Maximum Tolerable Period of Disruption) klassifiziert.
• Verfügbarkeit ist risikobasiert zu sichern; nicht jeder Ausfall führt zu einer Meldepflicht oder Sanktion.
• Übungen und Wiederherstellungstests müssen zur Kritikalität der Prozesse und zu den gewählten Wiederanlaufzielen passen.

1. Rechtliche Grundlage — Artikel 32 trifft BSI 200-4

DSGVO Artikel 32 nennt vier Schutzziele: Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit. BSI 200-4 operationalisiert die letzten beiden durch BCM (Business Continuity Management).

2. Die drei Reifegrade nach BSI 200-4

Reaktiv-BCMS (Stufe 1) — ein pragmatischer Einstieg mit Alarmierung, Rollen und ersten Notfallverfahren; das passende Schutzniveau hängt vom Risiko des Unternehmens ab.

Aufbau-BCMS (Stufe 2) — BIA, priorisierte Prozesse und Wiederanlaufziele werden systematischer entwickelt; auch dies ist keine automatische DSGVO-Konformitätsbescheinigung.

Standard-BCMS (Stufe 3) — ein umfassenderes Managementsystem, das an ISO 22301 anschlussfähig ist; zusätzliche sektorale Pflichten und Prüfintervalle sind gesondert zu bestimmen.

3. Business Impact Analyse (BIA)

Die BIA ist der diagnostische Kern des BCP. Jeder Geschäftsprozess wird bewertet nach:

• MTPD (Maximum Tolerable Period of Disruption) — maximale Ausfallzeit ohne existenzielle Folgen
• RTO (Recovery Time Objective) — Ziel-Wiederanlaufzeit
• RPO (Recovery Point Objective) — maximaler tolerabler Datenverlust
• MBCO (Minimum Business Continuity Objective) — Mindestbetriebsniveau

Rein illustrative Beispiel-Klassifikation, deren Werte in einer echten BIA erst begründet werden müssen:

• Lohnbuchhaltung: MTPD 5 Tage, RTO 48h, RPO 24h
• E-Commerce-Plattform: MTPD 4 Stunden, RTO 1h, RPO 15min
• HR-Aktenarchiv: MTPD 30 Tage, RTO 7 Tage, RPO 24h

4. IT-Notfallplan vs. BCP — die Abgrenzung

Artikel 32 verlangt ein dem Risiko angemessenes Schutzniveau und die Fähigkeit zur raschen Wiederherstellung. Ob ein formales BCMS erforderlich ist, hängt vom Kontext ab; ein dokumentierter Wiederanlaufprozess macht die Wirksamkeit überprüfbar.

5. Verzahnung mit IT-Grundschutz (BSI 200-2/200-3)

BSI 200-4 baut auf der IT-Grundschutz-Methodik auf. Der Bezug:

• 200-2 Methodik — Strukturanalyse, Schutzbedarfsfeststellung
• 200-3 Risikoanalyse — Bedrohungsmodellierung
• 200-4 BCMS — Geschäftsfortführung trotz Eintritt

Die Standards können sich ergänzen. Eine ISO-27001-Zertifizierung und eine rechtliche Pflicht zum BCMS sind davon getrennt zu beurteilen.

6. Wiederanlaufpläne (WAP) — die operative Ebene

Jeder kritische Prozess benötigt einen WAP mit:

• Auslöser (welches Ereignis aktiviert den Plan)
• Verantwortliche (Rollen, nicht Personen)
• Schritte (zeitlich geordnet, mit Zwischenzielen)
• Ressourcen (Personal, Hardware, externe Dienstleister)
• Eskalationsweg

Der Plan sollte so kurz wie möglich und so vollständig wie nötig sein; die Benutzbarkeit ist in einer Übung mit Personen zu prüfen, die ihn nicht verfasst haben.

Wenn der Wiederanlauf von Routern oder Switches abhängt, prüft ein Protokoll zur Konfigurationswiederherstellung Version, Zugriff auf die Kopie und Netzfunktionen nach dem Import.

7. Testierung und Übungen

BSI 200-4 unterscheidet:

• Schreibtischübungen prüfen Rollen und Entscheidungen.
• Funktionsübungen prüfen einzelne technische oder organisatorische Wiederanlaufschritte.
• Umfassende Übungen prüfen mehrere Abhängigkeiten und die Koordination zwischen Teams.

Jede Übung mündet in einen Lessons-Learned-Bericht. Bewahren Sie die Übungsergebnisse und offenen Maßnahmen so auf, dass Leitung, Audit und gegebenenfalls Aufsicht die Entwicklung nachvollziehen können.

Der praktische Wert der Übungen liegt weniger im “Bestehen” als im Aufdecken stiller Annahmen. Typische Erkenntnisse aus Funktionsübungen: Backups lassen sich zwar erstellen, aber die Wiederherstellung dauert dreimal länger als der definierte RTO; die Notrufkette enthält Handynummern ehemaliger Mitarbeiter; oder der Wiederanlaufplan setzt ein Netzwerk voraus, das bei einem Ransomware-Befall gerade isoliert wurde. Diese Lücken werden nur in der Übung sichtbar, nie im Dokument. Deshalb gilt: Ein einmal geschriebener, nie getesteter BCP ist im Ernstfall wertlos und aus Sicht der Aufsicht kaum besser als kein Plan.

8. Dokumentation für DSGVO-Nachweis

Artikel 5 Absatz 2 (Rechenschaftspflicht) verlangt Nachweis. Für BCP/BCM:

• BIA-Dokument mit RTO/RPO pro Prozess
• BCP/IT-Notfallhandbuch (aktueller Stand)
• Übungsberichte aus dem intern festgelegten Aufbewahrungszeitraum
• Lessons-Learned-Protokolle
• Schulungsnachweise für Krisenstab

Entscheidend ist die Aktualität: Ein altes BIA-Dokument kann durch veränderte Prozesse, Systeme und Abhängigkeiten unbrauchbar werden; prüfen Sie Werte deshalb regelmäßig und nach wesentlichen Änderungen. Verankern Sie deshalb einen festen Review-Zyklus — mindestens jährlich sowie anlassbezogen nach jeder wesentlichen Änderung der IT-Landschaft (Cloud-Migration, neue Kernsysteme, Fusion). Verknüpfen Sie den BCP zudem mit Ihrem Verzeichnis von Verarbeitungstätigkeiten: Nur so ist nachvollziehbar, welche personenbezogenen Verarbeitungen an welchen kritischen Prozessen hängen und deshalb bevorzugt wiederangelaufen werden müssen.

9. Werkzeuge

Eine geeignete Dokumentation verknüpft Prozesse, Wiederanlaufziele, Übungen und betroffene Verarbeitungen. Vor einer Softwareentscheidung sollten diese Datenbeziehungen und Alarmierungsanforderungen als prüfbare Kriterien beschrieben werden.

Verwandte Leitfäden: DSGVO Artikel 32 Sicherheit, NIS2 Umsetzung Deutschland, Datenpanne melden.

Ein BCP beginnt beim Geschäftsprozess, nicht beim Backup

Ein Backup beantwortet die Frage, ob ein Datenstand wiederhergestellt werden kann. Ein Business-Continuity-Plan beantwortet, wie die Leistung während der Unterbrechung aufrechterhalten oder geordnet wieder aufgenommen wird. Für eine Lohnabrechnung bedeutet das beispielsweise nicht nur das Zurückspielen der Datenbank. Es braucht rechtzeitigen Zugang zu freigegebenen Zahlungsläufen, eine Ersatzperson für die Freigabe und einen sicheren Kanal zum Zahlungsdienstleister. Ein Plan, der ausschließlich „IT stellt Server wieder her“ sagt, übersieht diese Abhängigkeiten. Der BSI-Standard 200-4 führt deshalb von der Geschäftsauswirkungsanalyse über Strategien zu konkreten Wiederanlaufplänen und Übungen.

In der BIA erfassen Prozesseigner zunächst die Leistung, Kunden und Rechtsfristen. Dann beschreiben sie, welche Folgen ein Ausfall nach zwei, acht, vierundzwanzig und achtundvierzig Stunden hat. Erst daraus folgen MTPD, angestrebter Wiederanlauf und minimale Betriebsleistung. RTO und RPO müssen mit der realen Architektur zusammenpassen: Eine Anwendung mit einem RTO von einer Stunde benötigt getestete Ersatzkapazität und einen Eskalationsweg; eine nächtliche Sicherung mit einem RPO von fünfzehn Minuten ist widersprüchlich. Die Werte sind Planungsentscheidungen, keine allgemeine gesetzliche Liste. Ein Verantwortlicher nach DSGVO muss die Angemessenheit seiner Wahl am Risiko für die Rechte betroffener Personen messen.

Personenbezogene Daten im Notbetrieb

Der Ersatzprozess darf Datenschutz nicht „für später“ verschieben. Wenn ein Service-Team bei Ausfall des CRM auf eine Tabellenkalkulation ausweicht, muss feststehen, wer Zugriff hat, wo die Datei gespeichert wird, wann sie in das reguläre System zurückgeführt und gelöscht wird und wie Änderungen nachvollzogen werden. Papierformulare brauchen dieselbe Betrachtung: verschlossene Aufbewahrung, begrenzte Kopien und sichere Vernichtung. Ein Notbetrieb kann Verfügbarkeit herstellen und zugleich neue Risiken für Vertraulichkeit und Integrität schaffen. Die technischen und organisatorischen Maßnahmen nach Art. 32 umfassen daher auch die Alternative zum Normalbetrieb.

Ein Ausfall ist nicht automatisch eine meldepflichtige Datenschutzverletzung. Ein Verlust der Verfügbarkeit personenbezogener Daten kann jedoch eine Verletzung des Schutzes personenbezogener Daten sein. Das Krisenteam prüft deshalb getrennt, ob Daten exfiltriert, verändert oder zeitweise unzugänglich wurden, welche Personen betroffen sind und welches Risiko daraus folgt. Art. 33 DSGVO verlangt bei meldepflichtigem Risiko eine Meldung grundsätzlich binnen 72 Stunden nach Bekanntwerden; die interne BCP-Aktivierung ist kein Ersatz für diese Prüfung. Ein Vorfallslog mit Zeitpunkten, Entscheidungen und Begründungen verbindet die beiden Workflows.

Wiederanlaufplan als ausführbares Dokument

Ein guter Plan nennt Auslöser, Entscheidungsträger, Ansprechpartner, alternative Arbeitsorte, benötigte Zugänge, Reihenfolge der Systeme, Datenabgleich und die Bedingungen für die Rückkehr zum Normalbetrieb. Beginnen Sie mit einer einzigen kritischen Leistung und lassen Sie eine andere Schicht den Plan lesen. Kann diese Schicht ohne den Autor entscheiden, wen sie nachts erreicht und welches System zuerst startet? Falls nicht, fehlt operative Information. Kontaktlisten müssen auch offline verfügbar sein, und Zugangsdaten dürfen nicht im Klartext im Plan liegen. Ein Ersatzkommunikationskanal braucht vorab freigegebene Empfänger und eine Regel für vertrauliche Informationen.

Die Wiederanlaufreihenfolge sollte Abhängigkeiten sichtbar machen. Der Webshop kann erst wieder Bestellungen annehmen, wenn Identitätsdienst, Produktbestand, Zahlungsanbindung und Kundensupport verfügbar sind. Ein technisches „Server grün“ beweist keinen wiederhergestellten Geschäftsprozess. Planen Sie für jede Stufe eine fachliche Abnahme: Beispielsweise führt die Fachabteilung eine Testbestellung durch, prüft Bestandsbuchung und kontrolliert, ob die Transaktion im Verzeichnis der Verarbeitungstätigkeiten und in Aufbewahrungsregeln unverändert abgebildet ist. Wo Dienstleister beteiligt sind, gehören ihre zugesagten Wiederherstellungsleistungen und Eskalationskontakte in den Plan; eine allgemeine SLA-Klausel genügt nicht.

Übungen, die eine Entscheidung verbessern

Drei unterschiedliche Übungen prüfen drei unterschiedliche Schwächen. Ein Tabletop mit Fachseite, IT, Datenschutz und Kommunikation testet Entscheidungen und Reihenfolge. Ein technischer Restore aus einer unveränderbaren Sicherung testet Integrität, Zeit und Abhängigkeiten. Ein begrenzter Umschaltversuch testet, ob Menschen mit dem Ersatzprozess tatsächlich arbeiten können. Die Häufigkeit folgt Risiko, Änderungstempo und regulatorischem Kontext; weder BSI 200-4 noch Art. 32 macht aus jedem Unternehmen automatisch eine einheitliche halbjährliche Testpflicht. Halten Sie Szenario, Startzeit, Sollwert, Istwert, Abweichung, Verantwortlichen und Termin für die Korrektur fest. Wenn eine Übung alle Ziele „grün“ meldet, aber niemand den Datenabgleich nach Rückkehr getestet hat, ist das Ergebnis unvollständig.

Nach jedem größeren Systemwechsel wird der Plan erneut geprüft. Neue Cloud-Regionen, ein anderer Zahlungsdienstleister, ein Outsourcing-Vertrag oder geänderte Berechtigungen können die alte BIA entwerten. Der BCP hat deshalb einen Besitzer im Betrieb, einen jährlichen Review-Termin als interne Praxis und ereignisbezogene Reviews nach Änderungen. Die Backup-Wiederherstellung und die NIS-2-Risikomanagementmaßnahmen liefern ergänzende Prüfpfade, dürfen aber nicht als pauschaler Nachweis für den ganzen Plan ausgegeben werden.

Nachweise für Leitung und Aufsicht

Die Geschäftsleitung sollte nicht bloß eine Freigabe auf dem Deckblatt unterschreiben. Ein brauchbares Berichtspaket enthält die priorisierten Prozesse, nicht erfüllte RTO/RPO-Ziele, offene Dienstleisterabhängigkeiten, letzte Übung, kritische Abweichungen und Maßnahmen mit Budgetentscheidung. Datenschutzverantwortliche ergänzen die Folgen für Betroffene und die mit Notverfahren eingeführten Sicherheitsmaßnahmen. Diese wenigen Artefakte zeigen, ob der Plan betrieben wird. Ein Zertifikat nach ISO 22301 oder ein BSI-konformes Dokument kann hilfreich sein; die tatsächliche Wiederherstellungsfähigkeit ergibt sich erst aus Architektur, Menschen und überprüften Übungen.

Abstimmung mit Risikoanalyse und Incident Response

Die BIA bewertet Folgen eines Ausfalls für einen Geschäftsprozess; die technische Risikoanalyse nach BSI 200-3 kann ergänzend die Bedrohungen der unterstützenden Systeme vertiefen. Beide Ergebnisse sollten sich nicht widersprechen: Wenn ein Prozess nur zwei Stunden stillstehen darf, darf ein zentraler Identitätsdienst ohne Wiederanlaufplan nicht als unkritisch geführt werden. Ähnlich braucht die Vorfallmeldung nach DORA, NIS 2 und DSGVO eine gemeinsame Zeitleiste mit dem Krisenstab, aber getrennte Meldeentscheidungen. Ein BCP, der diese Übergaben benennt, spart im Ernstfall die Suche nach Zuständigkeiten.

Quellen und Prüfschritte

Als Primärquellen dienen BSI-Standard 200-4 und Art. 32 sowie Art. 33 DSGVO. Prüfen Sie bei jedem genannten Fallbeispiel, ob die Primärquelle tatsächlich eine Sanktion wegen fehlender Verfügbarkeitssicherung belegt; ein bekanntes Ransomware-Ereignis ist nicht automatisch ein DSGVO-Präzedenzfall. Prüfen Sie gesetzliche Sektorpflichten zusätzlich am eigenen Anwendungsbereich, bevor ein internes Testintervall als allgemein verbindlich ausgegeben wird.

Muster einer BIA-Entscheidung für einen personenbezogenen Prozess

Ein mittelständischer Gesundheitsdienst nutzt Terminplanung, Patientenkommunikation und Abrechnung. Ein Ausfall der Terminplanung führt bereits nach wenigen Stunden zu verpassten Behandlungen; die Abrechnung kann länger manuell überbrückt werden. Die BIA hält für jede Leistung Nutzer, Ausfallfolgen, alternative Arbeitsweise und Abhängigkeiten fest. Bei der Terminplanung können eine offline bereitgestellte Tagesliste und ein Rückrufprozess den Betrieb begrenzt erhalten. Dafür muss die Liste verschlüsselt, zeitnah erstellt, nur für Berechtigte zugänglich und nach dem Ausfall sauber abgeglichen werden. Die Leitung dokumentiert, wie lange dieser Ersatzbetrieb tragbar ist. Erst danach setzt das IT-Team RTO und RPO. Ein schneller Datenbank-Restore, der die Telefonanlage oder die Authentisierung nicht berücksichtigt, würde das fachliche Ziel verfehlen.

Der Plan enthält auch einen Stopppunkt. Wenn die Tagesliste veraltet ist, Einwilligungen oder Warnhinweise fehlen oder Identitäten nicht sicher geprüft werden können, darf die Ersatzlösung nicht unbegrenzt weiterlaufen. Eine benannte fachliche Person entscheidet, welche Leistungen ausgesetzt oder umgeleitet werden. Diese Entscheidung schützt Betroffene besser als die Kennzahl „System innerhalb einer Stunde hoch“. Nach Wiederherstellung werden manuelle Änderungen nachvollziehbar übernommen und doppelte oder widersprüchliche Einträge geprüft.

Testprotokoll und Nacharbeit

Ein schlankes Testprotokoll kann auf einer Seite festhalten: Szenario, getesteter Prozess, beteiligte Rollen, geplante und tatsächliche Zeiten, verwendeter Datenstand, fachliche Abnahme und drei wichtigste Abweichungen. Für jede Abweichung gibt es eine zuständige Person, Termin und einen erneuten Prüfschritt. Wird der Wiederanlauf wegen einer fehlenden DNS-Abhängigkeit verzögert, reicht „Dokumentation ergänzen“ nicht; der Betreiber sollte die Abhängigkeit in Architektur und Plan sichtbar machen und den nächsten Restore unter denselben Bedingungen wiederholen. Ein solcher Nachweis zeigt mehr als eine ungetestete Behauptung über Verfügbarkeit.

Die Übung prüft auch Kommunikation. Wer informiert betroffene Beschäftigte oder Kunden, wenn der Ersatzbetrieb Leistungen einschränkt? Welche Informationen dürfen über private Mobiltelefone nicht geteilt werden? Wer hält die Datenschutzprüfung nach Art. 33 DSGVO aktuell, wenn die Ursache noch unklar ist? Die Antworten gehören in den Krisenablauf, nicht in einen isolierten Anhang. Der BCP ist damit ein lebender Entscheidungsweg, dessen Qualität an konkreten Ausfällen, Tests und Korrekturen sichtbar wird.

Fazit

BCP ist nicht “IT-Backup mit Begleitdokument” — es ist die Übersetzung von Geschäftsprioritäten in Wiederanlaufmechaniken. BSI 200-4 gibt einen pragmatischen, mehrstufigen Rahmen. Die DSGVO-Verzahnung läuft über Artikel 32 Absatz 1 Buchstabe c und die Rechenschaftspflicht aus Artikel 5 Absatz 2.

Für viele mittelständische Verantwortliche kann ein Aufbau-BCMS ein sinnvoller Einstieg sein: eine belastbare Business Impact Analyse, definierte RTO/RPO-Werte für die wenigen wirklich kritischen Prozesse und mindestens eine getestete Wiederanlaufprozedur. Alles Weitere lässt sich iterativ ergänzen. Entscheidend ist, überhaupt anzufangen und die Ergebnisse jährlich zu prüfen — ein gelebtes, unvollständiges BCMS schützt im Ernstfall besser als ein perfektes Konzept, das nie über den Entwurf hinauskam.