RTO und RPO: So legst du Wiederherstellungsziele im Finanzsektor fest
Systemausfälle und Datenverluste gehören zu den größten operativen Risiken von Banken und Wertpapierinstituten. Zwei Kennzahlen steuern die Notfallplanung im Business Continuity Management: das Recovery Time Objective (RTO) und das Recovery Point Objective (RPO).
Kurz gesagt: Das RTO legt fest, wie schnell eine Funktion nach einem Ausfall wieder laufen muss. Das RPO legt fest, wie viele Daten maximal verloren gehen dürfen. Beide Werte werden je Funktion aus einer Business-Impact-Analyse abgeleitet, nicht pauschal von der IT gesetzt.
Management Summary
Vier Punkte, die du zu RTO und RPO wissen solltest.
Zeit bis zum Wiederanlauf
Das RTO ist die Zielzeit bis zur Wiederaufnahme einer Funktion im vereinbarten Mindestumfang. Es wird kürzer als die maximal tolerierbare Ausfallzeit (MTPD) angesetzt.
Tolerierbarer Datenverlust
Das RPO gibt in Zeit an, welcher Datenverlust hinnehmbar ist. Es bestimmt wesentlich Sicherungsintervall und Replikationsverfahren, setzt aber wiederherstellbare Sicherungen voraus.
Pflicht je Funktion
DORA verlangt RTO und RPO je Funktion, abhängig von Kritikalität und Auswirkung auf die Markteffizienz. Die Ziele müssen auch in extremen Szenarien tragen (Art. 12 Abs. 6 DORA).
Festlegen, absichern, testen
Ausgangspunkt ist die BIA. Danach folgen Technik, Dienstleistersteuerung und mindestens jährliche Tests der Pläne.
RTO und RPO im Überblick
| Begriff | Bedeutung | Beispiel aus der Finanzbranche |
|---|---|---|
| RTO (Recovery Time Objective) | Zielzeit, innerhalb der eine Funktion nach einem Ausfall im vereinbarten Mindestumfang wieder bereitstehen muss | Die Handelsplattform ist spätestens nach 2 Stunden wieder verfügbar |
| RPO (Recovery Point Objective) | Maximal tolerierbarer Datenverlust, gemessen in Zeit | Transaktionsdaten werden mindestens alle 20 Minuten gesichert |
| MTPD (maximal tolerierbare Ausfallzeit) | Grenze, ab der ein Ausfall nicht mehr tragbar ist; das RTO wird kürzer als die MTPD angesetzt, damit ein Puffer bleibt | MTPD 8 Stunden, RTO 4 Stunden |
| Grundlage | Business-Impact-Analyse (BIA) je Prozess bzw. Funktion | Zahlungsverkehr erhält ein kürzeres RTO als die interne Berichterstellung |
| Umsetzung | Backup-, Redundanz- und Wiederherstellungsverfahren, die RTO und RPO technisch tragen | Gespiegelte Systeme, getestete Restore-Verfahren |
Was ist das RTO (Recovery Time Objective)?
Das RTO ist die Zeitspanne, innerhalb der eine Funktion, ein System oder ein Geschäftsprozess nach einem Ausfall wieder im vereinbarten Mindestumfang laufen muss. Gemeint ist nicht zwingend der Vollbetrieb, sondern das zuvor festgelegte Leistungsniveau. Ein RTO von vier Stunden bedeutet: Spätestens vier Stunden nach Eintritt der Störung ist die Funktion in diesem Umfang wieder verfügbar.
Das RTO wird kürzer als die maximal tolerierbare Ausfallzeit (MTPD) angesetzt, damit ein Puffer bleibt. Die MTPD ist ein Begriff aus dem BCM (etwa ISO 22301), kein DORA-Begriff. Die Geschäftsleitung entscheidet, wie lange das Unternehmen ohne eine Funktion auskommt, bevor der finanzielle, rechtliche oder reputative Schaden nicht mehr tragbar ist.
Was ist das RPO (Recovery Point Objective)?
Das RPO legt fest, wie viel Datenverlust, gemessen in Zeit, tolerierbar ist. Es bestimmt, auf welchen Zeitpunkt vor dem Ausfall die Daten mindestens wiederherstellbar sein müssen. Ein RPO von 20 Minuten setzt voraus, dass Daten mindestens alle 20 Minuten gesichert oder repliziert werden. Das Intervall allein garantiert das Ziel aber nicht: Die Sicherungen müssen erfolgreich durchlaufen, in sich konsistent und im Ernstfall tatsächlich wiederherstellbar sein. Das zeigen nur regelmäßige Wiederherstellungstests.
Für Systeme mit Transaktionsdaten, etwa im Zahlungsverkehr oder Wertpapierhandel, wird das RPO häufig sehr niedrig angesetzt, teils im Sekundenbereich oder nahe null. Welches Verfahren dafür geeignet ist, hängt vom Ausfallszenario ab: Synchrone Replikation schützt vor dem Ausfall von Hardware oder Standort, überträgt aber logische Fehler, Fehlbedienung oder Schadsoftware mit. Dagegen helfen je nach Ziel Transaktionsprotokolle mit Wiederherstellung auf einen bestimmten Zeitpunkt oder unveränderliche Sicherungen. Für Archiv- und Auswertungsdaten sind längere Zeiträume üblich.
Rechtsgrundlage: So verankert die Regulierung RTO und RPO
Die Festlegung von RTO und RPO ist keine freiwillige Best Practice. Welche Vorgabe gilt, hängt von der Art des Instituts ab.
| Norm | Regelung | Bedeutung für die Praxis |
|---|---|---|
| Art. 12 DORA | Sicherungs- und Wiederherstellungsverfahren; RTO und RPO je Funktion unter Berücksichtigung von Kritikalität und Auswirkung auf die Markteffizienz. Die Zielzeiten müssen auch in extremen Szenarien die vereinbarten Servicelevel sicherstellen (Abs. 6) | RTO und RPO je Funktion festlegen, begründen und auch für extreme Szenarien auf Tragfähigkeit prüfen |
| Art. 11 Abs. 6 DORA | Mindestens jährliche Tests der IKT-Geschäftsfortführungs- und Wiederherstellungspläne | Testplan, Testergebnisse und Abweichungen dokumentieren |
| Art. 19 DORA | Meldung schwerwiegender IKT-bezogener Vorfälle an die Aufsicht | Keine laufenden RTO-Reports, aber Meldepflicht im Vorfall |
| VO (EU) 2024/1774 | Delegierte Verordnung zum IKT-Risikomanagementrahmen (RTS) | Konkretisiert die Anforderungen an Fortführungs- und Wiederherstellungspläne |
| § 25a Abs. 1 Satz 3 Nr. 5 KWG | Angemessene Notfallkonzepte, insbesondere für IT-Systeme | Gilt für Kreditinstitute |
| MaRisk AT 7.3 | Notfallkonzept mit Wiederanlaufplänen für zeitkritische Aktivitäten und Prozesse | Gilt für Kreditinstitute, nicht unmittelbar für Wertpapierinstitute |
Was die Aufsicht in der Praxis erwartet
- Dokumentation: RTO und RPO sind je Funktion festgelegt und aus der BIA begründet.
- Erreichbarkeit: Die Werte sind technisch und organisatorisch tragfähig, auch bei ausgelagerten Diensten.
- Tests: Die Pläne werden regelmäßig getestet, und Abweichungen führen zu Maßnahmen.
- Verantwortung: Die Geschäftsleitung genehmigt die Zielwerte und nimmt die Ergebnisse zur Kenntnis.
RTO und RPO in fünf Schritten festlegen
Die Festlegung ist keine reine IT-Aufgabe, sondern eine Entscheidung der Geschäftsleitung auf Basis der Fachbereiche.
- Business-Impact-Analyse durchführen: Identifiziere die kritischen und wichtigen Funktionen, etwa Zahlungsverkehr oder Wertpapierhandel, und bewerte die Folgen eines Ausfalls über die Zeit.
- MTPD und RTO definieren: Lege je Funktion fest, wann der Ausfall nicht mehr tragbar ist, und leite daraus das RTO ab. Kritische Funktionen erhalten kurze RTOs, weniger kritische längere.
- RPO festlegen: Bestimme je Funktion und Datenart, wie viel Datenverlust tolerierbar ist. Berücksichtige dabei auch gesetzliche Aufbewahrungs- und Nachweispflichten.
- Strategie und Technik ableiten: Gestalte Backup, Redundanz und Wiederherstellungsverfahren so, dass die Ziele erreichbar sind. Prüfe auch Abhängigkeiten von IKT-Drittdienstleistern und deren vertragliche Zusagen.
- Testen und nachsteuern: Prüfe in regelmäßigen Notfalltests, ob RTO und RPO tatsächlich eingehalten werden. Dokumentiere Abweichungen und passe Ziele oder Maßnahmen an.
Fristen und Zeitpunkte rund um RTO und RPO
Die folgenden Zeitpunkte sind für die Umsetzung relevant.
| Zeitpunkt | Was gilt | Grundlage |
|---|---|---|
| seit 17.01.2025 | DORA ist anzuwenden, einschließlich der Vorgaben zu Wiederherstellungszielen | VO (EU) 2022/2554 |
| mindestens jährlich | Test der IKT-Geschäftsfortführungs- und Wiederherstellungspläne | Art. 11 Abs. 6 DORA |
| im Vorfall | Meldung schwerwiegender IKT-bezogener Vorfälle an die Aufsicht | Art. 19 DORA |
FAQ zu RTO und RPO im Business Continuity Management
RTO und RPO sind keine reinen IT-Kennzahlen. Beide Werte müssen aus der Kritikalität der Geschäftsprozesse, den regulatorischen Anforderungen und der tatsächlichen technischen Wiederherstellbarkeit abgeleitet werden.
Was ist der Unterschied zwischen RTO und RPO?
Das RTO beschreibt, wie schnell eine Funktion nach einem Ausfall wieder verfügbar sein muss. Das RPO beschreibt, wie viel Datenverlust, gemessen in Zeit, tolerierbar ist. Das RTO steuert also die Wiederanlaufzeit, das RPO den Datenstand, auf den zurückgekehrt werden muss.
Warum sind RTO und RPO für Banken und Finanzdienstleister besonders wichtig?
Finanzunternehmen sind von IT-Systemen und Daten in Echtzeit abhängig, und Ausfälle wirken schnell auf Kunden, Märkte und Gegenparteien. Zudem verlangt DORA die Festlegung von Wiederherstellungszielen je Funktion (Art. 12 Abs. 6 DORA), und Kreditinstitute müssen ein Notfallkonzept nach § 25a Abs. 1 Satz 3 Nr. 5 KWG vorhalten.
Wie wird ein angemessenes RTO festgelegt?
Ausgangspunkt ist die BIA: Sie zeigt, ab wann ein Ausfall nicht mehr tragbar ist (MTPD). Das RTO wird kürzer als die MTPD angesetzt und muss zugleich technisch und organisatorisch erreichbar sein, einschließlich der Zeit für Entscheidung, Alarmierung und Wiederanlauf.
Wie wird ein realistisches RPO bestimmt?
Entscheidend ist, wie viele Daten du je Prozess maximal neu erfassen oder rekonstruieren kannst, ohne Kunden, Compliance oder Bilanzierung zu gefährden. Das RPO bestimmt wesentlich Sicherungsintervall und Replikationsverfahren, ersetzt aber nicht den Nachweis, dass sich die Daten tatsächlich wiederherstellen lassen.
Welche Rolle spielt die Business-Impact-Analyse bei RTO und RPO?
Die BIA ist die Grundlage: Sie identifiziert kritische Funktionen, bewertet die Auswirkungen eines Ausfalls über die Zeit und liefert damit die Begründung für jedes RTO und RPO. Ohne BIA sind die Werte weder steuerbar noch gegenüber Prüfern belegbar.
Müssen RTO und RPO für alle Systeme gleich festgelegt werden?
Nein. Sie werden je Funktion bzw. Prozess nach Kritikalität differenziert (Art. 12 Abs. 6 DORA). Ein einheitlicher Wert für alle Systeme ist entweder zu teuer oder für kritische Funktionen zu lang.
Welche technischen Maßnahmen unterstützen die Einhaltung von RTO und RPO?
Dazu zählen Datensicherungen in passender Frequenz, Replikation, unveränderliche Sicherungen, redundante Systeme und Rechenzentren, automatisierte Failover-Verfahren sowie dokumentierte Wiederherstellungsverfahren. Die Auswahl richtet sich nach dem konkreten Ziel und dem Ausfallszenario, das abgedeckt werden soll. Bei ausgelagerten Diensten müssen die Zusagen der Dienstleister die Ziele ebenfalls tragen.
Warum sollten RTO und RPO regelmäßig getestet werden?
Nur Tests zeigen, ob die Werte in der Praxis erreichbar sind. DORA verlangt mindestens jährliche Tests der IKT-Geschäftsfortführungs- und Wiederherstellungspläne (Art. 11 Abs. 6 DORA). Ergebnisse und Abweichungen sind zu dokumentieren.
Welche typischen Fehler machen Unternehmen bei der Definition von RTO und RPO?
Häufig werden die Werte ohne BIA aus der IT heraus gesetzt, für alle Systeme einheitlich vergeben oder nie getestet. Weitere typische Fehler sind Zielwerte, die die Technik nicht erreicht, übersehene Abhängigkeiten von Dienstleistern und fehlende Dokumentation der Begründung.
Kompetenz aufbauen: Seminare für BCM und Resilienz
S+P Seminare bietet Weiterbildungen, mit denen du RTO und RPO in deinem Unternehmen fachlich fundiert festlegst und umsetzt:
Lehrgang Resilience Officer: RTO und RPO in ein ganzheitliches, DORA-konformes Resilienzkonzept einbetten.
Seminar Notfallbeauftragter: Business-Impact-Analysen, Risk-Impact-Analysen und Notfallpläne aufbauen, mit Tools und Guideline für die Umsetzung im eigenen Haus.
Information Security Officer: BCM mit Informationssicherheit und Cyber-Resilienz verknüpfen.
- Verordnung (EU) 2022/2554 (DORA), insbesondere Art. 11, 12 und 19: eur-lex.europa.eu
- Delegierte Verordnung (EU) 2024/1774 (RTS zum IKT-Risikomanagementrahmen): eur-lex.europa.eu
- § 25a KWG (Besondere organisatorische Pflichten von Instituten): gesetze-im-internet.de
- Wertpapierinstitutsgesetz (WpIG): gesetze-im-internet.de
Verwandte Leistungen und Programme
Die Festlegung von RTO und RPO greift in bestehende Prozesse ein. Diese Bausteine schließen an.
1st Line Services
Operative Bearbeitung datenintensiver und fristgebundener Fachprozesse nach den Vorgaben deines Instituts, auch für die laufende Pflege von Notfall- und Wiederanlaufdokumentation.
1st Line Services ansehenCompliance Technology Services
Anbieterneutrale Unterstützung bei Datenhaushalt, Schnittstellen und Auswertbarkeit der Systemlandschaft, ohne Bindung an ein Produkt. Relevant, wenn RTO und RPO an der tatsächlichen IT-Landschaft gemessen werden.
Compliance Technology Services ansehenThree-Lines-Modell
Abgrenzung der Verantwortlichkeiten zwischen operativer Steuerung, etwa dem IKT-Betrieb, den Kontrollfunktionen und der Revision.
Three-Lines-Modell ansehenS+P Compliance Cockpit
Governance-, Maßnahmen- und Evidenzregister an einem Ort, in deiner bestehenden Microsoft- oder SharePoint-Umgebung, geeignet als Ablage für BIA-Ergebnisse, RTO- und RPO-Festlegungen und Testnachweise.
Compliance Cockpit ansehenAuslagerung Interne Revision
Auslagerung der Revisionsfunktion mit dokumentiertem Mandat und geregelter Berichtslinie, einschließlich der Prüfung von Notfallkonzept und Testverfahren.
Auslagerung ansehenWeitere Perspektiven auf das Thema
S+P Governance
Wie Geschäftsleitung und Aufsichtsorgan RTO und RPO genehmigen und die Ergebnisse der Notfalltests bewerten. Relevant, weil die Zielwerte in der Leitungsebene des Instituts entschieden werden.
S+P Governance ansehenS+P Seminare
Wie dein Team zu Business-Impact-Analyse, Notfallkonzept und Resilienz qualifiziert wird. Relevant, weil die Qualität der Umsetzung von der Kompetenz der Beteiligten abhängt.
S+P Seminare ansehen
