RTO und RPO festlegen: So wird es belastbar

Ein ERP-System fällt um 10:15 Uhr aus. Die IT kann eine Wiederherstellung innerhalb von vier Stunden zusagen. Für den Vertrieb wäre das verkraftbar, für die laufende Fertigungsplanung jedoch nicht. Wer RTO und RPO festlegen will, muss deshalb mehr beantworten als die technische Frage nach Backup, Failover oder Wiederanlauf. Es geht um die geschäftliche Wirkung eines Ausfalls und um die Frage, welche Unterbrechung ein Unternehmen tatsächlich tragen kann.

Recovery Time Objective (RTO) und Recovery Point Objective (RPO) gehören zu den zentralen Zielgrößen im Business Continuity Management (BCM) und im IT Service Continuity Management (ITSCM). Richtig abgeleitet schaffen sie eine nachvollziehbare Verbindung zwischen kritischen Geschäftsprozessen, IT-Services, Schutzmaßnahmen und Investitionsentscheidungen. Zu ambitioniert formuliert, erzeugen sie hohe Kosten und Erwartungen, die im Ernstfall nicht eingelöst werden. Zu großzügig gewählt, gefährden sie operative Leistungsfähigkeit, Compliance und Vertrauen.

Was RTO und RPO im Ernstfall steuern

Das RTO beschreibt die Wiederanlaufzeit, bis ein Prozess, ein IT-Service oder eine Anwendung nach einer Störung wieder in einem definierten Mindestumfang verfügbar sein muss. Es ist kein Wunschwert für die IT, sondern eine geschäftlich begründete Zeitvorgabe. Ein RTO von acht Stunden kann etwa bedeuten, dass ein Service spätestens innerhalb eines Arbeitstags wieder nutzbar sein muss - gegebenenfalls zunächst mit reduzierter Funktionalität.

Das RPO beschreibt dagegen den Zeitpunkt der letzten Datensicherung. Liegt das RPO bei einer Stunde, dürfen bei einer Wiederherstellung höchstens Daten der letzten 60 Minuten verloren gehen. Daraus ergeben sich Anforderungen an Sicherungsintervalle, Replikation, Protokollierung und Wiederanlaufverfahren.

Beide Werte sind eng verbunden, aber nicht austauschbar. Eine Anwendung kann sehr schnell wieder verfügbar sein und dennoch mit einem Datenstand von gestern starten. Umgekehrt kann ein nahezu aktueller Datenbestand gesichert sein, obwohl die Wiederherstellung der Anwendung viele Stunden dauert. Für einen Zahlungsverkehrsprozess wäre möglicherweise beides nicht akzeptabel. Für ein Archivsystem kann hingegen ein längeres RTO bei geringem RPO sinnvoll sein.

RTO und RPO festlegen beginnt im Geschäftsprozess

Die häufigste Fehlannahme lautet: Die IT bestimmt die Zielwerte allein. Technische Teams können beurteilen, welche Wiederanlaufzeiten und Datenstände mit einer Architektur realistisch erreichbar sind. Ob diese Ziele angemessen sind, entscheidet aber der betroffene Geschäftsbereich auf Basis der geschäftlichen Auswirkungen.

Der Ausgangspunkt ist daher eine Business Impact Analyse. Sie ermittelt, welche Folgen eine Unterbrechung für Umsatz, Lieferfähigkeit, gesetzliche Pflichten, Sicherheit, Vertragsbeziehungen und Reputation hat. Entscheidend ist der zeitliche Verlauf: Nicht jeder Ausfall wird sofort kritisch. Manche Prozesse lassen sich zwei Stunden manuell überbrücken, nach einem Tag entstehen jedoch Vertragsverletzungen oder Produktionsstillstände. Andere Services müssen praktisch ohne Unterbrechung funktionieren, weil sie Personen schützen oder gesetzlich vorgeschriebene Meldungen ermöglichen.

Eine belastbare Analyse betrachtet auch Abhängigkeiten. Der Prozess „Auftrag ausliefern“ hängt möglicherweise von Auftragsmanagement, Lagerverwaltung, Schnittstellen zu Logistikpartnern, Identitätsdiensten, Netzwerken und qualifiziertem Personal ab. Ein ambitioniertes RTO für die Lageranwendung hilft nicht, wenn die notwendige Schnittstelle zum Transportdienstleister erst am Folgetag wiederhergestellt wird. RTOs müssen deshalb entlang einer vollständigen Leistungskette abgestimmt werden.

Von der maximal tolerierbaren Ausfallzeit zum Zielwert

In der Business Impact Analyse wird oft zunächst die maximal tolerierbare Ausfallzeit bestimmt. Sie markiert die Grenze, ab der die Folgen für das Unternehmen nicht mehr akzeptabel sind. Das RTO muss vor dieser Grenze liegen. Es benötigt zudem einen realistischen Puffer für Lagebewertung, Aktivierung der Notfallorganisation, technische Maßnahmen, fachliche Prüfungen und die Stabilisierung des Betriebs.

Ein Beispiel: Ein kritischer Prozess erreicht nach zwölf Stunden eine nicht mehr tolerierbare Schadensschwelle. Ein RTO von zwölf Stunden wäre dennoch riskant, weil es keinerlei Reserve für Komplikationen gibt. Je nach Szenario, Abhängigkeiten und Wiederanlaufreife kann ein Ziel von sechs oder acht Stunden angemessener sein. Es bleibt eine Managemententscheidung, die dokumentiert, freigegeben und regelmäßig überprüft werden muss.

Beim RPO gilt dieselbe Logik. Nicht die technische Taktung der Datensicherung definiert den Wert, sondern die Frage: Welche Transaktionen, Änderungen oder Nachweise können nachträglich rekonstruiert werden? Wenn Aufträge bei einem Datenverlust von vier Stunden aus Papierbelegen, Schnittstellenprotokollen und Kundenbestätigungen zuverlässig nacherfasst werden können, ist ein RPO von vier Stunden unter Umständen vertretbar. Sind Transaktionen dagegen rechtlich relevant, hochvolumig oder nur mit hohem Aufwand nachvollziehbar, kann ein deutlich kürzeres RPO erforderlich sein.

Die Zielwerte müssen technisch und organisatorisch erfüllbar sein

Nach der geschäftlichen Ableitung folgt der Realitätscheck. Ein RTO von 15 Minuten bedeutet nicht automatisch, dass eine tägliche Datensicherung ausreicht. Je nach Service können hochverfügbare Komponenten, geografisch getrennte Replikation, automatisierte Wiederanlaufabläufe, vorbereitete Ersatzarbeitsplätze und klar geregelte Entscheidungswege notwendig sein. Diese Maßnahmen verursachen Aufwand, Kosten und zusätzliche Komplexität.

Besonders kritisch ist die Verwechslung von Backup und Wiederanlauffähigkeit. Ein Backup bestätigt zunächst nur, dass Daten gesichert wurden. Ob die Daten vollständig, konsistent und innerhalb des geforderten RTO wiederherstellbar sind, zeigt erst ein dokumentierter und getesteter Restore-Prozess. Bei komplexen Anwendungen müssen Datenbanken, Konfigurationen, Schnittstellen, Berechtigungen und Reihenfolgen berücksichtigt werden.

Auch die Notfallorganisation beeinflusst die tatsächlich erreichbare Wiederanlaufzeit. Wer entscheidet über die Aktivierung? Wer erreicht Dienstleister außerhalb der Geschäftszeiten? Sind Zugänge, Kontakte, Ersatzhardware und Freigaben verfügbar? Ein technisch mögliches RTO kann operativ verfehlt werden, wenn diese Fragen ungeklärt bleiben. ITSCM verbindet deshalb technische Vorsorge mit Rollen, Notfallhandbüchern, Alarmierung und Übungen.

Für die Plausibilisierung helfen vier Fragen:

• Welcher Geschäftsprozess verliert ab welchem Zeitpunkt seine Funktionsfähigkeit?
• Welche Anwendungen, Daten, Infrastrukturen und externen Leistungen werden dafür zwingend benötigt?
• Welche Wiederanlaufstrategie erreicht RTO und RPO auch bei einem realistischen Schadensszenario?
• Wann wurde die Fähigkeit zuletzt unter praxisnahen Bedingungen nachgewiesen?

Unterschiedliche Klassen statt pauschaler Zielwerte

Nicht jede Anwendung benötigt identische Schutzniveaus. Einheitliche Vorgaben wie „alle Systeme innerhalb von vier Stunden“ wirken auf den ersten Blick klar, führen aber oft zu unnötigen Kosten oder gefährlichen Lücken. Sinnvoller ist eine Klassifizierung, die kritische Services, unterstützende Services und weniger zeitkritische Systeme unterscheidet.

Dabei darf eine niedrige fachliche Sichtbarkeit nicht über die Bedeutung eines Dienstes hinwegtäuschen. Identitäts- und Berechtigungsdienste, DNS, Netzwerkkomponenten, Zeitdienste oder zentrale Integrationsplattformen sind selten direkt einem Geschäftsprozess zugeordnet. Fällt einer dieser Basisdienste aus, kann er jedoch zahlreiche Anwendungen gleichzeitig blockieren. Ihre RTO- und RPO-Vorgaben müssen sich an ihrer Rolle als technische Abhängigkeit orientieren.

Auch regulatorische und vertragliche Anforderungen sind einzubeziehen. NIS-2, DORA, KRITIS-orientierte Vorgaben sowie Anforderungen aus BSI-Standards verlangen kein universelles RTO oder RPO. Sie erhöhen jedoch die Erwartung, dass kritische Funktionen identifiziert, Risiken bewertet, angemessene Maßnahmen umgesetzt und deren Wirksamkeit nachgewiesen werden. Vertraglich zugesicherte Service Levels oder Meldepflichten können Zielwerte zusätzlich beeinflussen.

Nachweis schlägt Annahme: testen, messen, nachsteuern

RTO und RPO sind nur dann belastbar, wenn sie überprüft werden. Ein erfolgreicher Test muss nicht immer die gesamte Produktionsumgebung umfassen. Je nach Kritikalität reichen gestufte Verfahren: Review von Wiederanlaufdokumenten, technische Restore-Tests, Tests einzelner Abhängigkeiten, simulierte Ausfälle oder vollständige Notfallübungen. Wichtig ist, dass das jeweilige Testszenario zum nachzuweisenden Ziel passt.

Gemessen wird nicht allein die Dauer, bis ein Server startet. Für das RTO zählt die Wiederherstellung des vereinbarten Serviceumfangs. Dazu gehören fachliche Funktionsprüfung, Datenkonsistenz, Schnittstellen und die Übergabe an den Betrieb. Beim RPO muss nachvollziehbar sein, welcher Datenstand tatsächlich wiederhergestellt wurde und ob erforderliche Nacharbeiten beherrscht werden.

Abweichungen sind wertvolle Erkenntnisse, kein Anlass, Ergebnisse zu beschönigen. Wenn ein Service sein RTO verfehlt, braucht es eine klare Entscheidung: Wiederanlaufverfahren verbessern, Architektur anpassen, Abhängigkeiten reduzieren oder den Zielwert nach erneuter fachlicher Bewertung verändern. Die gewählte Maßnahme muss zur Risikotoleranz des Unternehmens passen.

Mit einer zentralen Dokumentation lassen sich Zielwerte, Abhängigkeiten, Maßnahmen, Testnachweise und Verantwortlichkeiten dauerhaft konsolidieren. Softwaregestützte Prozesse, etwa mit [alive-IT], erleichtern es, Änderungen an Anwendungen oder Geschäftsprozessen in die Notfallvorsorge zu überführen und den Pflegeaufwand transparent zu steuern.

RTO und RPO sind keine einmalige Übung für ein Audit. Sie sind ein verbindliches Leistungsversprechen der Organisation an ihre kritischen Prozesse. Wer sie aus der Geschäftsrealität ableitet, technisch absichert und regelmäßig trainiert, schafft im Störungsfall nicht nur schnellere Wiederanläufe, sondern vor allem verlässliche Handlungsfähigkeit.