RTO und RPO je Geschäftsprozess festlegen: Wiederherstellungsziele am tatsächlichen Ausmaß der Auswirkungen ausrichten

Wird ein digitaler Dienst unterbrochen, hat das nicht für alle Prozesse die gleichen Folgen. Auch können nicht alle gleich lange auf ihre Wiederherstellung warten. Ebenso macht es einen Unterschied, ob wenige Minuten oder ein ganzer Tag an Informationen verloren gehen. Wiederherstellungsziele sollten deshalb die geschäftlichen Anforderungen mit den technischen Möglichkeiten verbinden, statt allen Anwendungen pauschal dieselben Werte zuzuweisen.

Zwei Kennzahlen helfen dabei, diese Anforderungen auszudrücken: Der RTO legt fest, wie lange ein Prozess unterbrochen sein darf, bevor die Auswirkungen nicht mehr akzeptabel sind. Der RPO beschreibt, wie viel Datenverlust, ausgedrückt als Zeitraum, toleriert werden kann. Beides sind vereinbarte Ziele, keine automatischen Garantien. Damit sie hilfreich sind, müssen sie verständlich, realistisch und überprüfbar sein.

RTO und RPO beantworten unterschiedliche Fragen

Der RTO, das Wiederherstellungszeitziel, beantwortet die Frage: Wie lange können wir auf diesen Prozess verzichten? Gemessen wird die Zeit von der Unterbrechung bis zu dem Zeitpunkt, an dem der Prozess wieder den vereinbarten Betriebszustand erreicht. Es reicht nicht, wenn ein Server startet: Der Dienst muss die Funktionen erfüllen können, die seine Wiederherstellung erforderlich machen.

Der RPO, das Wiederherstellungspunktziel, beantwortet die Frage: Bis zu welchem Zeitpunkt müssen die wiederhergestellten Daten verfügbar sein? Beträgt der vereinbarte RPO eine Stunde, akzeptiert das Unternehmen höchstens, Daten wiederherzustellen, deren Stand eine Stunde vor dem Vorfall liegt. Der RPO gibt nicht an, wie lange die Wiederherstellung dauert; dafür ist der RTO maßgeblich.

Beide Kennzahlen ergänzen einander, lassen sich aber nicht gegeneinander austauschen. Ein System kann eine Sicherung schnell wiederherstellen, die veraltete Daten enthält. Umgekehrt können aktuelle Daten erhalten bleiben, während die Wiederaufnahme des Betriebs zu lange dauert. Die Entscheidung muss beide Szenarien berücksichtigen und genau festlegen, was „wiederhergestellt“ bedeutet: Welche Nutzer, Transaktionen oder Funktionen müssen verfügbar sein?

Ziele je Prozess statt je Anwendung festlegen

Eine Anwendung kann mehrere Prozesse unterstützen, deren Auswirkungen unterschiedlich sind. Umgekehrt ist ein Prozess oft von mehreren Anwendungen, Datenbeständen, Anbietern und betrieblichen Aufgaben abhängig. Wer mit einer Systemliste beginnt und technische Prioritäten vergibt, übersieht daher möglicherweise, was das Unternehmen tatsächlich schützen muss.

Sinnvoll ist es, zunächst konkrete Prozesse zu bestimmen, etwa Bestellungen anzunehmen, Zahlungen zu erfassen oder Anfragen zu bearbeiten. Für jeden Prozess sollte die fachlich verantwortliche Person die Folgen einer Unterbrechung und eines Datenverlusts beschreiben. Anschließend kann die IT die dafür erforderlichen Anwendungen und Abhängigkeiten erfassen. Unterstützt dieselbe Plattform Prozesse mit unterschiedlichen Zielen, muss geprüft werden, ob sie getrennt wiederhergestellt werden können oder ob eine gemeinsame Einschränkung ausdrücklich berücksichtigt werden muss.

Diese Sichtweise hilft auch, übersehene Abhängigkeiten zu erkennen: Identitäts- und Zugriffsverwaltung, Kommunikation, Schnittstellen, Datenbanken, Konfigurationsdaten, spezialisiertes Fachpersonal und externe Anbieter. Die Wiederherstellung der Hauptanwendung setzt den Prozess nicht wieder in Gang, solange eine kritische Abhängigkeit ausgefallen ist.

Auswirkungen im Zeitverlauf einschätzen

Die Auswirkungen treten nicht immer sofort vollständig ein. Eine kurze Unterbrechung kann noch verkraftbar sein. Wird jedoch ein bestimmter Schwellenwert überschritten, können sich unerledigte Aufgaben anhäufen, Zusagen nicht eingehalten werden oder betriebliche Möglichkeiten wegfallen. Die Analyse sollte beschreiben, wie sich der Schaden mit der Zeit verändert, statt ein System lediglich als „kritisch“ einzustufen.

Für eine praktische Einschätzung kann das Team folgende Fragen stellen:

• Was kommt zum Stillstand: Welche Abläufe, Kanäle oder Entscheidungen hängen vom Prozess ab?
• Wer ist betroffen: Kunden, Beschäftigte, Partner oder andere Teams?
• Was häuft sich an: ausstehende Bestellungen, unbearbeitete Fälle oder Informationen, die nicht mehr erfasst werden?
• Ab wann ist die Situation nicht mehr tragbar: Wann überschreiten die Auswirkungen die vom Unternehmen akzeptierte Grenze?
• Welche Daten könnten verloren gehen: Wie wichtig sind sie, wie oft werden sie aktualisiert und lassen sie sich rekonstruieren?

Die Einschätzungen sollten relevante Bedingungen wie Zeiten hoher Auslastung oder betriebliche Abschlussphasen berücksichtigen. Fehlen ausreichende Daten, sollte die Unsicherheit dokumentiert und eine überprüfbare Annahme vereinbart werden. Das ist besser, als eine scheinbar exakte, aber unbegründete Zahl anzugeben.

Umsetzbare Ziele vereinbaren

Die fachlich verantwortliche Person schlägt vor, welcher Datenverlust und welche Verzögerung tragbar sind. Die IT prüft, welche Mittel und Verfahren nötig wären, um diese Grenzen einzuhalten. Der Betrieb erläutert, wie ein Vorfall erkannt wird, wer über die Aktivierung der Wiederherstellung entscheidet und welche Aufgaben auszuführen sind. Die endgültige Entscheidung erfordert den Austausch zwischen diesen Funktionen: Ein ehrgeiziger RTO senkt das Risiko nicht, wenn die nötigen Ressourcen fehlen oder die Fähigkeit zur Einhaltung nicht nachgewiesen ist.

Eine hilfreiche Vereinbarung benennt mindestens den Prozess, RTO und RPO, den Umfang der Wiederherstellung, Abhängigkeiten, Verantwortliche und die Nachweise, mit denen die Einhaltung belegt werden soll. Sie hält auch Annahmen fest, etwa welche Funktionen zuerst wiederhergestellt werden oder welche manuellen Verfahren den Betrieb vorübergehend aufrechterhalten können. Eine manuelle Alternative kann die Auswirkungen mindern, braucht aber klare Verantwortliche, Anweisungen und Grenzen. Ihre Verfügbarkeit darf nicht einfach vorausgesetzt werden.

Beim Vergleich der Anforderungen mit den vorhandenen Möglichkeiten können Lücken sichtbar werden. Die Lösung muss nicht immer in der Anschaffung neuer Technologie liegen. Denkbar sind auch vereinfachte Abhängigkeiten, bessere Verfahren, eine zuverlässigere Datenerfassung, die Priorisierung einer wesentlichen Funktion oder die formelle Akzeptanz eines anderen Risikoniveaus. Welche Maßnahme passt, hängt von den Auswirkungen und den tatsächlich verfügbaren betrieblichen Optionen ab.

Abhängigkeiten, Architektur und Betrieb überprüfen

Das vereinbarte Ziel muss mit dem gesamten Wiederherstellungsablauf abgeglichen werden. Für den RTO zählen die Erkennung des Vorfalls, die Entscheidungsfindung, der Zugriff auf Personen und Systeme, die Wiederherstellung, die Überprüfung und die Wiederaufnahme des Prozesses. Fehlt eine dieser Phasen im Plan, kann die vorgesehene Dauer unrealistisch sein.

Für den RPO sollte geprüft werden, wie wiederherstellbare Daten erzeugt und aufbewahrt werden, wie häufig sie aktualisiert werden und welche Informationen von diesem Verfahren nicht erfasst werden. Eine Sicherung ist ein Baustein der Strategie, aber kein Nachweis dafür, dass die Wiederherstellung innerhalb der Ziele möglich ist. Es muss geprüft werden, ob die Daten verwendbar sind und ob das Verfahren auf ungeprüften Annahmen beruht.

Wichtig ist außerdem, gemeinsam genutzte Abhängigkeiten zu identifizieren. Benötigen mehrere Prozesse dieselbe Identitätsverwaltung, dasselbe Netzwerk oder denselben Anbieter, können sie bei einer parallelen Wiederherstellung um Ressourcen konkurrieren oder eine bestimmte Reihenfolge erfordern. Wenn diese Beziehungen dokumentiert sind, lassen sich Wiederherstellungsprioritäten festlegen und erreichbare Ziele unter verschiedenen Bedingungen besser einschätzen.

Ziele testen, überprüfen und anpassen

Tests machen aus den Zielen überprüfbare Nachweise. Eine Übung kann den Ablauf von Anfang bis Ende durchspielen, die Zeit bis zur Wiederherstellung der vereinbarten Funktionen messen und den Zustand der wiederhergestellten Daten prüfen. Es reicht nicht, festzustellen, dass eine Sicherung vorhanden ist oder eine Instanz startet: Die für den Prozess verantwortliche Person muss bestätigen, dass sich mit dem Ergebnis tatsächlich arbeiten lässt.

Je nach Risiko und Leistungsfähigkeit des Teams können Übungen mit einer Überprüfung der Verfahren beginnen und schrittweise umfassendere technische Szenarien einbeziehen. Bei jedem Test sollten folgende Angaben festgehalten werden:

• Welcher Prozess, welches Szenario und welche Abhängigkeiten getestet wurden.
• Wann die Unterbrechung begann und wann die vereinbarten Funktionen wieder verfügbar waren.
• Auf welchen Datenstand zurückgegriffen wurde und welcher Verlust festgestellt wurde.
• Welche Schritte scheiterten, welche Annahmen nicht zutrafen und wer die jeweilige Lücke behebt.

Wird der RTO oder RPO im Test überschritten, muss entschieden werden, ob die Wiederherstellungsfähigkeit verbessert, der Prozess geändert oder das Ziel gemeinsam mit dem Fachbereich angepasst wird. Einen Test zu wiederholen, ohne die festgestellten Probleme zu beheben, schafft kein Vertrauen. Auch bei Änderungen am Prozess, an der Architektur, am Aktivitätsvolumen oder an den Abhängigkeiten sollten die Ziele überprüft werden.

Häufige Fehler und Entscheidungsvorlage

Zu den häufigsten Fehlern zählen, für den gesamten Systembestand dieselben Ziele festzulegen, RTO und RPO zu verwechseln, eine Sicherung mit einer erfolgreichen Wiederherstellung gleichzusetzen und Ziele ohne Beteiligung des Fachbereichs zu definieren. Riskant ist es auch, nur die technische Verfügbarkeit zu messen, Koordinationsaufgaben zu übersehen oder einen Test als erfolgreich zu bewerten, ohne Daten und Prozessfunktionen zu prüfen.

Ein einfaches Formular hilft, Entscheidungen nachvollziehbar zu dokumentieren. Es kann folgende Felder enthalten:

• Prozess und fachlich verantwortliche Person: Welche Aktivität wird geschützt und wer akzeptiert die Auswirkungen?
• Auswirkungen nach Dauer und Datenverlust: Welche Folgen entstehen und welche Grenzen sind tragbar?
• Vereinbarter RTO und RPO: Welche Ziele und welcher Umfang der Wiederherstellung gelten?
• Anwendungen und Abhängigkeiten: Welche Komponenten, Teams und Anbieter werden benötigt?
• Verfahren und manuelle Alternative: Welche Schritte, Prioritäten, Verantwortlichen und Grenzen gelten?
• Letzter Test und Nachweise: Welches Ergebnis wurde beobachtet, welche Lücken bestehen und welche Maßnahmen sind offen?

RTO und RPO je Prozess festzulegen bedeutet nicht, ideale Zahlen auszuwählen. Entscheidend ist, Grenzen zu vereinbaren, die den Auswirkungen entsprechen, die Fähigkeit zu ihrer Einhaltung zu prüfen und Lücken zu beheben. Regelmäßige Überprüfungen halten die Ziele am tatsächlichen Dienst ausgerichtet und verhindern, dass eine dokumentierte Erwartung mit einer nachgewiesenen Fähigkeit verwechselt wird.