Business Continuity stellt sicher, dass die kritischen Aktivitäten des Unternehmens auch bei Störungen weiterlaufen. Disaster Recovery stellt die für diese Aktivitäten notwendige Technologie wieder her. Es handelt sich dabei nicht um konkurrierende Ansätze und auch nicht um dasselbe Dokument. Business Continuity ist eine betriebswirtschaftliche Disziplin, die festlegt, was wie weitergeführt werden muss. Recovery ist eine technische Disziplin, die Systeme in einer definierten Reihenfolge wiederherstellt, um die vom Unternehmen festgelegten Ziele zu erreichen.
- Unterschiedliche Verantwortlichkeiten: Kontinuität liegt üblicherweise beim Betrieb oder Risikomanagement, Wiederherstellung bei der IT.
- Unterschiedliche Auslöser: Kontinuität wird bei Geschäftsauswirkungen aktiviert, Wiederherstellung bei technischem Ausfall.
- Unterschiedliche Definitionen von Erfolg: Fortsetzung der Arbeit versus Wiederherstellung der Systeme.
- Ein gemeinsamer Datensatz, beide stammen aus derselben Geschäftsauswirkungsanalyse.
- Die Fehler treten an der Nahtstelle zwischen den beiden Komponenten auf, nicht innerhalb einer der beiden.
Worin unterscheiden sich Geschäftskontinuität und Notfallwiederherstellung tatsächlich?
Fragt man die meisten Leute nach dem Unterschied zwischen Geschäftskontinuität und Notfallwiederherstellung, lautet die Antwort meist: Geschäftskontinuität ist umfassend, Wiederherstellung technisch. Das stimmt zwar, ist aber wenig hilfreich, wenn es darum geht, wer welche Dokumentation erstellt. Sinnvoller ist die Unterscheidung anhand der jeweiligen Verantwortlichkeiten und der Quellen der Anweisungen.
Ein Notfallplan geht von den laufenden Aktivitäten aus. Er fragt, welche Tätigkeiten der Organisation unabdingbar sind, wie lange diese jeweils unterbrochen werden können, bevor der Schaden kritisch wird, und welche alternative Arbeitsweise in der Zwischenzeit möglich ist. Das Ergebnis ist eine Reihe von Entscheidungen über Prioritäten und Ausweichmöglichkeiten.
Ein Wiederherstellungsplan beginnt bei den Systemen. Er fragt, was in welcher Reihenfolge wiederhergestellt werden muss, um die zugesicherten Zeiträume für die Geschäftskontinuität einzuhalten. Das Ergebnis ist ein Handlungshandbuch. Der umfassendere Zusammenhang zwischen beiden und einer einzigen Fähigkeit wird unter Geschäftskontinuität dargestellt.
| Geschäftskontinuität | Katastrophale Erholung | |
|---|---|---|
| Wem gehört es? | Operations, Risikomanagement oder ein dedizierter Kontinuitätsbeauftragter mit Unterstützung der Geschäftsleitung. | IT oder Infrastruktur, oft dasselbe Team, das die Plattform tagtäglich betreibt. |
| Was löst es aus? | Wenn die Auswirkungen auf das Geschäft einen Schwellenwert erreichen, unabhängig von der Ursache, auch bei Ursachen ohne technische Komponente. | Ein technischer Ausfall oder Verlust eines Systems, einer Website oder eines Datensatzes. |
| Was bedeutet „wiederhergestellt“? | Kritische Dienstleistungen werden den Kunden wieder auf jedem akzeptablen Weg zugestellt. | Die genannten Systeme sind betriebsbereit, erreichbar und wurden hinsichtlich ihrer Datenintegrität verifiziert. |
| Woher die Ziele kommen | Die Geschäftsauswirkungsanalyse, die von den für die jeweilige Aktivität Verantwortlichen unterzeichnet wurde. | Aus der Kontinuitätsstruktur übernommen. Die Wiederherstellung setzt sich keine eigenen Ziele. |
| Was Wirtschaftsprüfer fragen | Nachweise über Übungen, die das Unternehmen einbeziehen, und dass die Prioritäten den aktuellen Geschäftsbetrieb widerspiegeln. | Nachweise über Wiederherstellungstests mit Ergebnissen und dass die Backups tatsächlich wiederherstellbar sind. |
| Was es kostet, falsch zu liegen | Die Arbeiten wurden unterbrochen, obwohl die Systeme in Ordnung waren, weil niemand der manuellen Vorgehensweise zugestimmt hatte. | Die Systeme kehren in einer Reihenfolge zurück, in der die kritische Aktivität am längsten warten muss. |
Wem gehört welcher Tarif, und warum verursacht das Probleme?
Aufteilung der Zuständigkeiten ist sinnvoll. Diejenigen, die wissen, welche Kundenverpflichtungen wichtig sind, kennen nicht unbedingt die Wiederherstellungssequenz für einen Datenbankcluster. Das Problem ist nicht die Aufteilung an sich, sondern dass beide Seiten oft isoliert voneinander arbeiten und die Diskrepanz erst im Falle eines Vorfalls entdecken.
Drei Muster treten immer wieder auf. Erstens ein Wiederherstellungsplan mit Zielen, denen niemand im Unternehmen zugestimmt hat. Diese Ziele orientieren sich meist an den Möglichkeiten der Infrastruktur, anstatt an den tatsächlichen Anforderungen der Geschäftstätigkeit. Zweitens ein Kontinuitätsplan, der von einer manuellen Notlösung ausgeht und stillschweigend auf demselben System basiert, das ausgefallen ist. Das dritte und häufigste Muster: Beide Pläne existieren, beide sind technisch einwandfrei, und keiner legt fest, wer einen Vorfall meldet oder wer entscheidet, dass der Normalbetrieb wieder aufgenommen wurde.
Die Lösung ist keine Fusion. Es handelt sich um eine definierte Schnittstelle: gemeinsame Ziele, die aus der Geschäftsauswirkungsanalyse abgeleitet werden , eine zentrale Instanz zum Eingreifen und Aufheben der Maßnahmen sowie eine gemeinsame Übung mindestens einmal jährlich, an der beide Seiten teilnehmen.
Dahinter steckt ein größeres Bild.
Diese Seite behandelt einen Aspekt der Unternehmensresilienz. Echte Resilienz – das Rahmenwerk von IO zur Verknüpfung von Sicherheit, Datenschutz und KI-Governance – liefert das Gesamtbild.
Wo erfolgt die Übergabe von einem zum anderen?
Die meisten nachträglichen Analysen von Vorfällen, die einen Plan verantwortlich machen, beschreiben in Wirklichkeit eine Übergabe, die nie definiert wurde. Kontinuität und Wiederherstellung laufen parallel, nicht nacheinander, und berühren sich an vier Punkten: der Entscheidung zur Aktivierung des Notfallplans, der Wahl der Geschäftsaktivitäten während des Systemausfalls, dem Zeitpunkt, an dem die Technologie wieder einsatzbereit ist, und der Bestätigung, dass der Geschäftsbetrieb tatsächlich wiederhergestellt und nicht nur verbunden ist.
Beachten Sie den Startpunkt der Sequenz. Die Erkennung erfolgt fast immer auf technischer Ebene, weshalb viele Unternehmen das gesamte Ereignis als IT-Angelegenheit behandeln und die Fachabteilungen zu spät einbeziehen. Bis die Entscheidung über die Aufrechterhaltung des Geschäftsbetriebs getroffen werden muss, ist das Zeitfenster für eine saubere Umgehungslösung oft bereits geschlossen.
Was geschieht in den ersten 24 Stunden?
Beide Pläne sind gleichzeitig aktiv und erfüllen unterschiedliche Aufgaben. Diese explizite Darstellung ist die mit Abstand wichtigste Seite in beiden Dokumenten, denn sie beseitigt die Wartezeit, in der alle abwarten, wer den ersten Schritt macht.
| Praktikum | Kontinuität bedeutet, etwas zu tun. | Die Erholung findet statt |
|---|---|---|
| Erste Stunde | Feststellung, welche Aktivitäten betroffen sind, und Bestätigung, wer die Befugnis hat, diese Maßnahmen einzuleiten. | Umfang der Diagnose ermitteln, Fehler eingrenzen und überprüfen, ob die Backups intakt sind. |
| Stunden zwei bis vier | Die alternative Arbeitsweise aufzeigen und Mitarbeiter und Kunden darüber informieren. | Entscheidung, ob eine Reparatur vor Ort durchgeführt oder ein Failover durchgeführt werden soll, und Start des Wiederherstellungsprozesses. |
| Stunden vier bis zwölf | Die Ausweichlösung muss den zuständigen Personen zur Verfügung gestellt werden, und es muss nachverfolgt werden, was sich ansammelt und nicht erledigt wird. | Wiederherstellung in Abhängigkeitsreihenfolge und Überprüfung der Daten, sobald jede Ebene wiederhergestellt ist. |
| Stunde zwölf bis vierundzwanzig | Die Bewältigung von Erschöpfung, Übergaben und dem wachsenden Rückstand, den die Notlösung nicht auffangen kann. | Die verbleibenden Anwendungen werden wiederhergestellt und anhand realer Transaktionen getestet. |
| Mehr als vierundzwanzig Stunden | Entscheiden, wann man die Arbeit beendet, und dann den Rückstand in der Reihenfolge der Priorität abarbeiten. | Bestätigung des vollständigen Betriebs, Abgleich der während der Umgehungslösung erstellten Daten. |
Die letzte Zeile markiert den Punkt, an dem die meisten Planungen enden, die meisten realen Vorfälle jedoch nicht. Manuell durchgeführte Arbeiten müssen nachträglich in die Systeme eingepflegt werden, und ein in der falschen Reihenfolge abgearbeiteter Rückstand kann selbst zu einer erneuten Störung führen.
Benötigen Sie beide Dokumente, oder reicht ein Dokument aus?
Kleine Organisationen verwenden oft nur ein einziges Dokument, und für einen wirklich kleinen Betrieb kann das funktionieren. Entscheidend ist nicht die Größe, sondern ob beide Zielgruppen unter Zeitdruck die benötigten Informationen finden können. Ein Techniker, der um drei Uhr morgens eine Datenbank wiederherstellt, sollte nicht die Kundenkommunikation lesen müssen, und ein Betriebsleiter, der einen manuellen Prozess einrichtet, sollte nicht die Failover-Befehle durchblättern müssen. Was das Kontinuitätsdokument selbst enthalten sollte und woher die Inhalte der einzelnen Abschnitte stammen, ist im Abschnitt „ Geschäftskontinuitätsplan“ beschrieben.
Halten Sie die Dokumente getrennt, sobald eine der Zielgruppen mehr als ein oder zwei Seiten benötigt, und stellen Sie Querverweise sicher. Zahlenangaben dürfen niemals doppelt vorkommen. Wenn der Wiederherstellungszeitraum in beiden Dokumenten aufgeführt ist und sich die Angaben unterscheiden, widersprechen sich die Pläne genau dann, wenn es am wichtigsten ist. Legen Sie die Ziele einmalig in der Folgenabschätzung fest und beziehen Sie sich in allen anderen Dokumenten darauf. Die technischen Details des Dokuments werden im Notfallwiederherstellungsplan behandelt , die Szenarioebene darunter in Ihren Notfallplänen.
Welche Normen decken die einzelnen Bereiche ab?
Die Aufteilung zeigt sich bereits in den Normen selbst, was eine sinnvolle Überprüfung des Geltungsbereichs ermöglicht. ISO 22301 spezifiziert ein Managementsystem für Geschäftskontinuität: Es ist zertifizierbar und befasst sich mit der organisatorischen Fähigkeit. ISO/IEC 27031 deckt die Bereitschaft der Informations- und Kommunikationstechnologie (IKT) für Geschäftskontinuität ab und bildet somit die Wiederherstellungsebene. ISO 27001 verbindet diese beiden Normen über Anhang A, in dem Kontrollpunkt 5.29 die Informationssicherheit während Störungen und Kontrollpunkt 5.30 die IKT-Bereitschaft behandelt.
Die Einhaltung dieser Standards führt nicht zur Verschmelzung der beiden Disziplinen, sondern erzwingt lediglich die Existenz einer Schnittstelle. Ein Managementsystem muss nachweisen, dass die technische Bereitschaft den Geschäftsprioritäten dient – genau hier liegt das Problem, wenn niemand dazu aufgefordert wird, dies zu demonstrieren.
ISO 27001 leicht gemacht
Ein Vorsprung von 81 % vom ersten Tag an
Wir haben die harte Arbeit für Sie erledigt und Ihnen vom Moment Ihrer Anmeldung an einen Vorsprung von 81 % verschafft. Sie müssen nur noch die Lücken ausfüllen.
Welche Rolle spielt das Duo im Hinblick auf die Resilienz von Unternehmen?
Kontinuität und Wiederherstellung beantworten dieselbe Frage: Was passiert, wenn etwas ausfällt? Resilienz beantwortet eine umfassendere Frage. Sie ist die Fähigkeit, Veränderungen jeglicher Art aufzufangen, einschließlich unvorhergesehener Störungen und Verpflichtungen, die zum Zeitpunkt ihrer Erstellung noch nicht bestanden. Beide Planungsformen sind Bestandteile der Resilienz, nicht deren Ersatz.
Der Resilience Loop integriert Informationssicherheit gemäß ISO 27001 , Datenschutz gemäß ISO 27701 und KI-Governance gemäß ISO 42001 in ein zusammenhängendes System. Kontinuität und Wiederherstellung nutzen dieselben Kontrollmechanismen als zusätzliche Perspektive. Dies ist entscheidend: Zugriffsmanagement, Datensicherung und Lieferantenkontrollen, auf denen ein Wiederherstellungshandbuch basiert, sind dieselben, die auch für die Kontinuitätsmaßnahmen erforderlich sind. Ihre einmalige Pflege kommt daher beiden zugute. Wie das gesamte System zusammenwirkt, wird im Business Resilience Framework beschrieben.
Dies erklärt auch, warum ein Systemausfall innerhalb weniger Stunden zu einem Datenschutzproblem werden kann. Die Wiederherstellung eines Systems aus einem älteren Backup kann Daten wiederherstellen, deren Löschung zuvor angeordnet wurde. Zudem schafft eine Notlösung, bei der Kundendatensätze in eine Tabellenkalkulation verschoben werden, einen Verarbeitungsweg, den niemand geprüft hat. Werden die Wiederherstellungsmaßnahmen rein technisch betrachtet, bleiben diese Konsequenzen oft unbemerkt.
Wie beweist man, dass beides funktioniert?
Niemand prüft, ob Ihnen zwei Dokumente gehören. Kunden, Wirtschaftsprüfer und regulierte Mandanten stellen eine schwierigere Frage: Zeigen Sie mir, dass beide funktionieren, dass sie übereinstimmen und dass sie Ihre aktuelle Arbeitsweise widerspiegeln.
Das bedeutet: die aktuellen Ziele mit Nachweis der Genehmiger, ein Wiederherstellungstest mit Ergebnissen statt eines festgelegten Termins, eine Übung mit benannten Teilnehmern, die Ergebnisse beider Übungen sowie die abgeschlossenen Korrekturmaßnahmen. Die gemeinsame Übung fehlt am häufigsten und ist der einzige Nachweis für die Übergabe. Die Vorgehensweise ist im Abschnitt „ Nachweis von Resilienz“ beschrieben , und der Resilienz-Score dient als Ausgangspunkt.
Warum sollten Sie sich für ISMS.online im Bereich Kontinuität und Wiederherstellung entscheiden?
Die Schnittstelle zwischen diesen beiden Plänen ist sowohl ein Problem der Datenverwaltung als auch der Planung. ISMS.online sorgt dafür, dass beide Seiten mit derselben Datenquelle arbeiten.
- Eine Reihe von ZielenDie Wiederherstellungszeiträume sind an einem Ort gespeichert und fließen in beide Pläne ein, sodass sie sich nicht auseinanderentwickeln können.
- Pläne, die mit den Kontrollmechanismen verknüpft sind, auf die sie sich stützenDie Backup-, Zugriffs- und Lieferantenkontrollen hinter jedem Plan sind sichtbar, sodass eine Lücke in dem einen Plan auch im anderen sichtbar wird.
- integrierte Trainingsaufzeichnungen: Technische Wiederherstellungstests und Geschäftsübungen gemeinsam planen, Ergebnisse erfassen und Maßnahmen im selben System verfolgen.
- Ein Steuerungssatz, jedes Framework: Einmal abbilden und für ISO 22301, ISO 27001, ISO 27701 und ISO 42001 wiederverwenden, anstatt parallele Datensätze zu pflegen.
- Nachweis auf AnfrageZeigen Sie einen aktuellen Plan mit Testhistorie, nicht nur ein Dokument und eine Zusicherung.
- Eigentumsrechte: Benannte Eigentümer, Stellvertreter und Überprüfungstermine auf beiden Seiten der Übergabe.
- Entwickelt für den britischen Markt und regulierte Märkte: Konzipiert für Organisationen, die ihre Widerstandsfähigkeit unter Beweis stellen müssen, um Aufträge zu gewinnen und zu behalten.
Sehen Sie, wie es auf der Business-Resilienz-Plattform zusammenpasst , oder buchen Sie eine Demo.
Häufig gestellte Fragen
Ist die Notfallwiederherstellung Teil der Geschäftskontinuität?
Ja, insofern die Wiederherstellung den Zielen der Geschäftskontinuität dient. Geschäftskontinuität ist der umfassendere Bereich, der alle kritischen Aktivitäten und jede Störungsursache abdeckt, auch solche ohne technische Komponente. Die Notfallwiederherstellung ist die technologische Komponente innerhalb dieses Bereichs. Die Wiederherstellung übernimmt ihre Ziele von der Geschäftskontinuität, anstatt eigene festzulegen. Daher schützt ein Wiederherstellungsplan, der ohne Geschäftsauswirkungsanalyse erstellt wurde, tendenziell zuerst die falschen Systeme.
Kann es einen Notfallwiederherstellungsplan ohne einen Geschäftskontinuitätsplan geben?
Das ist möglich, und viele Organisationen tun es auch, aber dann tappen Sie im Dunkeln, was Ihre Prioritäten angeht. Ohne eine gemeinsame Auffassung darüber, welche Aktivitäten wichtig sind und wie lange jede einzelne unterbrochen werden darf, wird die Reihenfolge der Wiederherstellung nach technischen Gesichtspunkten festgelegt. Zudem bleibt eine Lösung für nicht-technische Störungen wie den Ausfall eines Standorts, eines wichtigen Lieferanten oder des Personals, das einen kritischen Prozess leitet, unbeantwortet.
Wem sollte welcher Plan gehören?
Die Kontinuitätsplanung ist Aufgabe des Unternehmens, in der Regel des Betriebs- oder Risikomanagements, mit einem verantwortlichen Manager, der Prioritäten festlegen kann. Die Wiederherstellung hingegen ist Aufgabe der IT oder der Infrastruktur. Entscheidend ist nicht die Berichtslinie, sondern die Schnittstelle: eine benannte Instanz, die die Maßnahmen einleiten und beenden kann, ein gemeinsames Set an Wiederherstellungszielen und eine gemeinsame Übung, an der beide Seiten beteiligt sind.
Nutzen die beiden Tarife die gleiche RTO?
Sie sollten dieselben Zahlen aus einer einzigen Quelle verwenden. Das Wiederherstellungszeitziel (Recovery Time Objective, RTO) für eine Aktivität wird in der Geschäftsauswirkungsanalyse festgelegt, und der technische Plan ist darauf ausgelegt, dieses Ziel zu erreichen. Dabei wird berücksichtigt, dass die Wiederherstellung eines Systems nicht gleichbedeutend mit der vollständigen Erledigung der Aktivität ist. Wenn die beiden Dokumente jeweils unterschiedliche Zahlenwerte enthalten, werden sie sich zwangsläufig widersprechen, und diese Diskrepanz wird im Falle eines Vorfalls zutage treten.
Wie oft sollten wir sie gemeinsam trainieren?
Mindestens jährlich und nach jeder Änderung, die die Übergabe beeinflusst: ein neues kritisches System, eine andere Hosting-Vereinbarung, eine Umstrukturierung mit Eigentümerwechsel oder ein tatsächlicher Vorfall. Separate technische Wiederherstellungstests können und sollten häufiger durchgeführt werden. Die gemeinsame Übung testet die Schnittstelle; ein Programm mit häufigen technischen Tests ohne gemeinsame Übung lässt daher die wahrscheinlichste Fehlerquelle unerforscht.
