Im letzten Abschnitt der Domain geht es um die Planung und Methoden, wie der Geschäftsbetrieb während und unmittelbar nach einem Störfall aufrechterhalten oder schnellstmöglich wiederhergestellt werden kann.
Business Continuity und Disaster Recovery
Diese beiden Begriffe werden oft gemeinsam als BC/DR geschrieben. Sie sind eng miteinander verbunden, stellen aber getrennte Phasen im Umgang mit Katastrophen dar.
Business Continuity (BC)
Der Business Continuity Plan (BCP) verfolgt ein kurzfristiges Ziel: die wesentlichen Geschäftsprozesse während und unmittelbar nach einem Störfall am Laufen zu halten. Dabei fokussiert sich BC ausschließlich auf die kritischen Kernfunktionen des Unternehmens, nicht auf die vollständige Wiederherstellung. Dies erfolgt nach einem vorher definierten Plan, der u. a. die Priorisierung von Ressourcen (materiell und personell), die Vorbereitung von Ersatzlösungen sowie Remote-Arbeitsfähigkeit umfasst.
Disaster Recovery (DR)
Der Disaster Recovery Plan (DRP) verfolgt gewissermaßen mittelfristige bis langfristige Ziele – die vollständige Wiederherstellung aller Dienste und Systeme auf ihren Normalzustand.
DR beginnt erst, wenn der unmittelbare Notfallbetrieb der BC abgeschlossen ist. Typische Maßnahmen in dieser Phase sind die Wiederherstellung von Daten aus Backups, bei Bedarf der Neuaufbau von IT-Systemen sowie die anschließende Validierung der durchgeführten Maßnahmen.
BC/DR Herausforderungen
Idealerweise decken BC/DR-Pläne verschiedene Bedrohungsszenarien ab, tdie sowohl technischer als auch organisatorischer Natur sein können. Was uns drohen kann, haben wir alle während der Coronapandemie hautnah erlebt.
Mögliche Bedrohungsszenarien sind:
Naturkatastrophen – eher selten, lassen sich aber durch geografisch verteilte Cloud-Regionen abmildern.
Cyberangriffe (z. B. Ransomware) – im Fall der Verschlüsselung oder des Verlusts kritischer Daten sind die Mitigationsmaßnahmen komplex. Immutable Cloud-Backups und Zero-Trust-Architektur können hier sinnvoll sein.
Pandemien – Remote-Work über Cloud-basierte Plattformen hat sich bewährt.
Versorgungsunterbrechungen – bei Netzwerkausfällen können redundante Leitungen helfen. Bei Stromausfällen hängen die Maßnahmen vom Ausmaß ab.
Cloud-Integration in BC/DR
In allen genannten Szenarien kann die Cloud aufgrund ihrer globalen Verfügbarkeit, schnellen Skalierbarkeit und Kosteneffizienz (Pay-as-you-go) eine effiziente Lösung sein.
Geschäftsanforderungen
Hier geht es weiter um das Thema BC/DR, wobei der Fokus auf drei zentralen Kennzahlen in diesem Kontext liegt.
Recovery Time Objective (RTO)
Das RTO beschreibt die maximal tolerierbare Ausfallzeit, bevor dieser zu einem geschäftskritischen Verlust führt. Ein Onlineshop kann z. B. nur einen 15-minütigen Ausfall des Zahlungsdienstes verkraften, bevor ernsthafte Folgen entstehen – in diesem Fall beträgt das RTO 15 Minuten.
Das RTO ist nicht die Zeit, die die IT tatsächlich für die Wiederherstellung benötigt, sondern die Zeit, die das Geschäft tolerieren kann. Deshalb wird das RTO nicht von der IT, sondern auf Geschäftsebene festgelegt. Und je kürzer das RTO, desto teurer sind Hochverfügbarkeitslösungen und desto komplexer die Recovery-Strategie.
Recovery Point Objective (RPO)
Das RPO definiert die maximal akzeptable Datenverlustmenge in einem bestimmten Zeitabschnitt und beantwortet die Frage: Wie alt dürfen die Daten maximal sein, die im Katastrophenfall wiederhergestellt werden? Ebenso wie das RTO wird das RPO auf Geschäftsebene festgelegt.
Beispiel: Beträgt das RPO 8 Stunden, dürfen höchstens 8 Stunden an Daten verloren gehen – was bedeutet, dass Backups mindestens alle acht Stunden durchgeführt werden müssen. Je kürzer das RPO, desto häufiger sind Sicherungen erforderlich – und desto teurer wird es. Deshalb ist eine wirtschaftliche Bewertung notwendig, um den richtigen Kompromiss zwischen dem Wert der Daten und den Investitionen in die Backup-Infrastruktur zu finden.
Recovery Service Level (RSL)
Das Recovery Service Level (RSL) legt die Mindestanzahl an laufenden Infrastrukturkomponenten fest, die während eines Ausfalls (Katastrophe) aufrechterhalten werden müssen, um kritische Geschäftsprozesse am Laufen zu halten. Die Festlegung erfolgt während der Erstellung des Business-Continuity-Plans (BCP) gemeinsam auf Geschäfts- und IT-Ebene.
BC/DR-Planung – Erstellung, Umsetzung und Prüfung
Der letzte Abschnitt ist eine direkte Fortsetzung des Themas BC/DR und behandelt die konkreten Schritte zur Analyse, Erstellung, Umsetzung und Überprüfung eines Business Continuity Plans (BCP) und Disaster Recovery Plans (DRP).
Business Impact Analysis (BIA)
Die BIA ist die Grundlage jeder BC/DR-Strategie. Sie hilft zu verstehen, welche Ressourcen für den Geschäftsbetrieb kritisch sind und welche Auswirkungen deren Ausfall hätte. Die BIA wird in vier Schritte unterteilt:
Identifikation – alle physischen und logischen Assets (Systeme, Daten, Personal, Standorte) werden erfasst, ebenso organisatorische Aspekte.
Bewertung der Auswirkungen – es wird analysiert, welche Folgen ein Ausfall hätte: Umsatzverlust, Vertragsverletzung, Imageschaden usw.
Priorisierung – Assets werden in kritische, wichtige und unkritische Kategorien eingeteilt.
Planung – Strategien und Wiederherstellungsmaßnahmen (z. B. Backup-Intervalle, Redundanz) werden definiert.
Implementierung
Dieser Punkt beschreibt, wie die theoretischen Schritte der BIA in die Praxis überführt werden. Ohne strukturierte Implementierung bleibt der BCP ein Papierdokument. Zentrale Elemente dabei sind:
Klare Rollenverteilung – Verantwortlichkeiten und Eskalationspfade müssen für den Krisenfall klar definiert sein.
Executive Sponsorship – die Unterstützung der Unternehmensführung ist entscheidend für die Bereitstellung von Ressourcen sowie für Akzeptanz und Durchsetzung.
Kommunikationsplan – es muss klar geregelt sein, wer im Krisenfall wen informiert, intern wie extern.
Ressourcenbereitstellung – Budget, Tools und Infrastruktur müssen vorab gesichert sein, damit im Ernstfall keine Zeit mit Beschaffung verloren geht.
Dokumentation – alle Pläne müssen schriftlich fixiert, versioniert und für alle relevanten Personen jederzeit zugänglich sein.
Prüfung der BC/DR-Pläne
Um sicherzustellen, dass BCP und DRP realistisch, lückenlos und für alle Beteiligten verständlich sind, müssen sie regelmäßig getestet werden. Ein BC/DR-Plan ist kein statisches Dokument – er ist ein lebendiger Prozess, der kontinuierlich überprüft und angepasst werden muss.
Es gibt fünf Testarten, wobei die Reihenfolge auch den Realismus und das Risiko abbildet: Tabletop > Walkthrough > Simulation > Parallel > Full Cutover
Tabletop – theoretische Besprechung eines fiktiven Katastrophenszenarios mit Schlüsselpersonen (IT, Management, Sicherheit), um Planlücken zu identifizieren.
Walkthrough – ähnelt dem Tabletop, beinhaltet aber einen physischen Durchlauf durch die Standorte. Die Beteiligten prüfen vor Ort, ob erforderliche Ressourcen und Verfahren vorhanden sind.
Simulationstest – eine Katastrophe wird simuliert, die Produktivsysteme bleiben aktiv, aber die Abläufe werden wie im Ernstfall durchgespielt. Hilft, Prozesse und Reaktionszeiten ohne echte Ausfälle zu validieren.
Paralleltest – die DR-Systeme werden unter Echtbedingungen aktiviert, während die Primärsysteme weiterlaufen. Hoher Aufwand, aber geringes Risiko.
Full Cutover – die Primärsysteme werden vollständig abgeschaltet, der Betrieb läuft ausschließlich über Backup-/DR-Systeme. Erbringt den Beweis der Funktionsfähigkeit, ist aber mit dem höchsten Aufwand und einem realen Betriebsrisiko verbunden.
Weitere Informationsquellen
Dieser Abschnitt liefert nur einen Überblick über BC/DR und BIA. Für eine vertiefte Auseinandersetzung empfehlen sich folgende Standards:
NIST SP 800-34 – der US-amerikanische Leitfaden für Notfallplanung in Informationssystemen, der die BIA als ersten und zentralen Schritt detailliert beschreibt.
ISO 22301 – der internationale Standard für Business Continuity Management, in dem die BIA als unverzichtbares Kernelement verankert ist.
ISO 27031 – speziell auf IT-bezogene Business Continuity ausgerichtet und damit besonders relevant für Cloud- und Rechenzentrumsumgebungen.
BCI Good Practice Guidelines – vom Business Continuity Institute herausgegeben und in der Praxis als de-facto-Standard für die BIA-Methodik anerkannt.