Business Continuity Planning (BCP): Was es ist, warum es wichtig ist und wie man einen BCP erstellt

Business Continuity Planning stellt sicher, dass kritische Geschäftsfunktionen während einer Störung fortgeführt werden können und sich schnell davon erholen. Ob die Störung ein Cyberangriff, Systemausfall, Naturkatastrophe oder Lieferkettenausfall ist — ein gut konzipierter BCP minimiert Ausfallzeiten, schützt Daten und erhält das Kundenvertrauen.

Für B2B-Unternehmen ist BCP eine Compliance-Anforderung unter ISO 27001, NIS2 und DORA. Enterprise-Käufer erwarten, dass Anbieter operationelle Resilienz durch dokumentierte und getestete Kontinuitätspläne nachweisen. Ein starker BCP ist sowohl eine Risikomanagement-Disziplin als auch ein Wettbewerbsvorteil.

Dieser Leitfaden behandelt, was BCP ist, seine Kernkomponenten, wie er auf Compliance-Frameworks abbildet und wie man einen effektiven Business-Continuity-Plan erstellt und testet.

BCP vs Disaster Recovery

Verständnis des Umfangs

Aspekt	Business Continuity Planning	Disaster Recovery
Umfang	Gesamte Organisation — Menschen, Prozesse, Technologie, Einrichtungen	IT-Systeme, Anwendungen und Daten
Fokus	Aufrechterhaltung des Geschäftsbetriebs während Störungen	Wiederherstellung von Technologie nach Störungen
Abdeckung	Krisenkommunikation, alternative Arbeitsplätze, manuelle Verfahren, Lieferkette	Backups, Failover, Datenreplikation, Systemwiederherstellung
Zeitrahmen	Vor, während und nach einer Störung	Hauptsächlich nach einer Störung
Verantwortlich	Geschäftsleitung / Business Leadership	IT / Infrastruktur-Team
Standard	ISO 22301 (Business Continuity Management)	Teil der ISO 27001, DORA, NIS2-Anforderungen

Disaster Recovery ist eine kritische Komponente von BCP, aber BCP umfasst weit mehr als nur technische Wiederherstellung.

Kernkomponenten des BCP

1. Business Impact Analysis (BIA)

Die BIA ist das Fundament jedes BCP. Sie identifiziert:

Kritische Geschäftsfunktionen — Welche Prozesse für den Betrieb essentiell sind
Auswirkungsbewertung — Finanzielle, betriebliche, reputationsbezogene und regulatorische Folgen einer Störung
Abhängigkeiten — Systeme, Daten, Menschen, Lieferanten und Einrichtungen, die jede Funktion benötigt
Wiederherstellungsprioritäten — Welche Funktionen zuerst wiederhergestellt werden müssen

Wiederherstellungskennzahlen

Kennzahl	Definition	Beispiel
RTO (Recovery Time Objective)	Maximal akzeptable Ausfallzeit	4 Stunden für kundenorientierte Services
RPO (Recovery Point Objective)	Maximal akzeptabler Datenverlust	1 Stunde (Backups alle 60 Minuten)
MTD (Maximum Tolerable Downtime)	Längste Zeit, die das Unternehmen ohne die Funktion überleben kann	24 Stunden für Abrechnungssysteme
MBCO (Minimum Business Continuity Objective)	Minimales Service-Level während einer Störung	50% der normalen Transaktionskapazität

2. Wiederherstellungsstrategien

Strategie	Anwendungsfall	RTO
Hot Standby	Kritische Systeme mit nahezu Null-Ausfallzeit	Minuten
Warm Standby	Wichtige Systeme mit moderater RTO-Toleranz	Stunden
Cold Standby	Nicht-kritische Systeme mit höherer RTO-Toleranz	Tage
Cloud-basierte Wiederherstellung	Nutzung von Cloud-Infrastruktur für schnelles Failover	Minuten bis Stunden
Manuelle Überbrückung	Geschäftsprozesse, die vorübergehend ohne IT betrieben werden können	Sofort (reduzierte Kapazität)

3. Krisenmanagement

Krisenteam — Definierte Rollen und Verantwortlichkeiten mit klaren Eskalationspfaden
Kommunikationsplan — Interne Kommunikation, Kundenbenachrichtigung, behördliche Meldung, Medienhandhabung
Entscheidungsbefugnis — Wer kann eine Krise erklären, den BCP auslösen und Ausgaben genehmigen
Lagebeurteilung — Verfahren zur Bewertung des Umfangs und der Schwere einer Störung

4. Backup und Datenschutz

Anforderung	Best Practice
Backup-Häufigkeit	Am RPO ausgerichtet — kritische Daten stündlich oder in Echtzeit gesichert
Backup-Tests	Regelmäßige Wiederherstellungstests zur Überprüfung der Backup-Integrität
Geografische Trennung	Backups an einem separaten Standort oder in einer separaten Region gespeichert
Verschlüsselung	Backups im Ruhezustand und bei der Übertragung verschlüsselt
Aufbewahrung	Aufbewahrungsrichtlinien im Einklang mit regulatorischen Anforderungen
Unveränderlichkeit	Unveränderliche Backups zum Schutz vor Ransomware

5. Tests und Übungen

Testtyp	Beschreibung	Häufigkeit
Tabletop-Übung	Diskussionsbasierter Durchlauf von Szenarien und Reaktionen	Vierteljährlich
Funktionstest	Test spezifischer Wiederherstellungsverfahren (z.B. Failover zum Backup-Standort)	Halbjährlich
Vollübung	Simulation einer tatsächlichen Störung mit allen Teams	Jährlich
DR-Failover-Test	Überprüfung, ob Disaster-Recovery-Systeme wie erwartet funktionieren	Jährlich
Kommunikationstest	Test der Krisenkommunikationskanäle und Kontaktlisten	Vierteljährlich

BCP und Compliance-Frameworks

Regulatorisches Mapping

Anforderung	Framework	BCP-Zuordnung
Business-Continuity-Planung	NIS2 Art. 21(2)(c), DORA Art. 11	Kern-BCP-Entwicklung und -Pflege
Backup-Management	NIS2 Art. 21(2)(c), ISO 27001 A.8.13	Backup-Richtlinien am RPO ausgerichtet
Disaster Recovery	NIS2 Art. 21(2)(c), DORA Art. 12-14	DR-Pläne mit definierten RTO/RPO
Krisenmanagement	NIS2 Art. 21(2)(c), DORA Art. 11	Krisenkommunikation und Entscheidungsverfahren
IKT-Bereitschaft	ISO 27001 A.5.30	IKT-Kontinuitätsplanung und -tests
Kontinuitätstests	DORA Art. 15, ISO 27001 A.5.30	Regelmäßige Tests von Plänen und Verfahren
Vorfallmeldung	NIS2 Art. 23, DORA Art. 19	Meldung von Störungen an Behörden
Managementaufsicht	NIS2 Art. 20, DORA Art. 5	Genehmigung und Überwachung auf Vorstandsebene

DORA-spezifische Anforderungen

DORA stellt detaillierte Anforderungen an die operationelle Resilienz von Finanzunternehmen:

DORA-Artikel	Anforderung
Artikel 11	IKT-Business-Continuity-Richtlinie für alle Funktionen, Assets und Drittparteien-Abhängigkeiten
Artikel 12	IKT-Response- und Recovery-Pläne mit Szenarien, Aktivierungsbedingungen und Ressourcenallokation
Artikel 13	Backup-Richtlinien mit Umfang, Häufigkeit, Wiederherstellungs- und Abgleichverfahren
Artikel 14	Wiederherstellungs- und Recovery-Verfahren zur Einhaltung von RPO/RTO-Zusagen
Artikel 15	Tests der IKT-Business-Continuity-Pläne einschließlich szenariobasierter und Vollübungen

BCP erstellen: Schritt für Schritt

Schritt 1: Umfang und Governance

BCP-Umfang definieren — welche Geschäftsfunktionen, Standorte und Dienste abgedeckt werden
Governance etablieren — BCP-Verantwortlichen benennen, Rollen und Verantwortlichkeiten definieren
Management-Commitment sichern — Genehmigung und Ressourcenzuweisung auf Vorstandsebene
Compliance-Ausrichtung — BCP-Anforderungen auf anwendbare Frameworks abbilden (ISO 27001, NIS2, DORA)

Schritt 2: Business Impact Analysis durchführen

Alle kritischen Geschäftsfunktionen und -prozesse identifizieren
Auswirkungen einer Störung bewerten (finanziell, betrieblich, reputationsbezogen, regulatorisch)
RTO, RPO und MTD für jede Funktion bestimmen
Abhängigkeiten von Systemen, Daten, Menschen, Einrichtungen und Lieferanten abbilden
Wiederherstellung nach Auswirkung und Dringlichkeit priorisieren

Schritt 3: Wiederherstellungsstrategien entwickeln

Wiederherstellungsstrategien für jede kritische Funktion basierend auf RTO/RPO entwerfen
Geeignete technische Lösungen wählen (Hot/Warm/Cold Standby, Cloud-basierte Wiederherstellung)
Manuelle Überbrückungsverfahren für den Betrieb während der Wiederherstellung definieren
Alternative Arbeitsorte planen, falls Einrichtungen betroffen sind
Lieferkettenkontinuität für kritische Drittparteien-Abhängigkeiten adressieren

Schritt 4: Den Plan dokumentieren

Business-Continuity-Plan mit klaren Verfahren für jedes Szenario verfassen
Kontaktlisten, Eskalationsverfahren und Entscheidungsbefugnisse aufnehmen
Krisenkommunikationsvorlagen für interne und externe Stakeholder dokumentieren
Kurzreferenzen für Krisenteam-Mitglieder erstellen
Den Plan an mehreren zugänglichen Orten speichern (nicht nur auf Systemen, die betroffen sein könnten)

Schritt 5: Testen und verbessern

Tabletop-Übungen durchführen, um die Logik und Vollständigkeit des Plans zu validieren
Funktionstests für spezifische Wiederherstellungsverfahren durchführen
Jährliche Vollübungen mit realistischen Störungsszenarien durchführen
Erkenntnisse dokumentieren und den Plan entsprechend aktualisieren
Nach jeder wesentlichen Änderung überprüfen und aktualisieren (Infrastruktur, Organisation, Bedrohungslandschaft)

Häufige BCP-Fehler

Fehler	Konsequenz
Keine BIA	Wiederherstellungsprioritäten sind Schätzungen, Ressourcen werden falsch zugewiesen
Ungetestete Pläne	Pläne versagen im Ernstfall — Verfahren sind veraltet oder unvollständig
Nur IT-Fokus	Geschäftsprozesse, Menschen und Kommunikation werden vernachlässigt
Single Point of Failure	Kritische Abhängigkeiten werden nicht identifiziert oder adressiert
Fehlende Drittparteien-Abdeckung	Lieferkettenstörungen werden nicht eingeplant
Kein Management-Buy-in	Pläne sind unterfinanziert und werden nicht ernst genommen
Statische Dokumentation	Pläne werden veraltet, wenn sich das Unternehmen verändert

Wie Orbiq Business Continuity unterstützt

Trust Center: Veröffentlichen Sie Ihre BCP-Lage — Kontinuitätspläne, RTO/RPO-Zusagen und Testnachweise für Käufer-Self-Service
Kontinuierliches Monitoring: Verfolgen Sie die Business-Continuity-Compliance über ISO 27001, NIS2 und DORA-Anforderungen hinweg
Evidenz-Management: Zentralisieren Sie BCP-Dokumentation, Testergebnisse und Wiederherstellungsnachweise für Auditoren
KI-gestützte Fragebögen: Automatische Beantwortung von Business-Continuity-Fragen von Enterprise-Käufern anhand Ihrer dokumentierten Kontrollen

Weiterführende Informationen

Risikomanagement-Frameworks — Integration von BCP in das unternehmensweite Risikomanagement
Incident Response — Koordination der Incident Response mit Business Continuity
NIS2 Compliance — Erfüllung der NIS2-Business-Continuity-Anforderungen
DORA Compliance — DORA-Pflichten zur operationellen Resilienz
ISO 27001 Zertifizierung — ISO 27001-Business-Continuity-Kontrollen

Dieser Leitfaden wird vom Orbiq-Team gepflegt. Letzte Aktualisierung: März 2026.