„Vier Stunden RTO.“
Stand auf jeder Folie. Stand in jedem Vertrag. Stand in jeder Management-Präsentation. Im Workshop wurde dann klar: Diese vier Stunden waren weder technisch noch betriebswirtschaftlich realistisch.
Nicht, weil die IT schlecht gearbeitet hatte. Nicht, weil niemand Business Continuity ernst nahm. Sondern weil die Zahl irgendwann gesetzt wurde — und danach niemand mehr gefragt hatte, ob sie noch stimmt.
Genau das sehe ich immer wieder. RTO und RPO werden in vielen Organisationen behandelt wie technische Parameter. Dabei sind sie in Wahrheit Managemententscheidungen. Sie bestimmen, wie viel Ausfall ein Unternehmen akzeptiert, wie viel Datenverlust tolerierbar ist und wie viel Geld in Resilienz investiert werden muss.
Das NIST Cybersecurity Framework 2.0 ordnet Wiederherstellung und Kontinuitätsplanung ausdrücklich als Teil eines strukturierten Cybersecurity- und Resilienzansatzes ein und arbeitet mit den Funktionen Govern, Identify, Protect, Detect, Respond und Recover. Wiederanlauf ist nicht nur ein IT-Thema, sondern Teil von Governance und Risikosteuerung.
Was RTO und RPO wirklich bedeuten
Bevor man über Ziele spricht, müssen die Begriffe sauber sein.
„Wie lange darf etwas ausfallen?“
Die Zielzeit, innerhalb der ein Prozess, Service oder System nach einer Störung wieder verfügbar sein soll. Misst Ausfallzeit.
„Wie viele Daten dürfen wir verlieren?“
Der maximal tolerierbare Datenverlust, gemessen als Zeitraum zwischen letztem nutzbaren Backup und Vorfall. Misst Datenverlust.
Beispiel: Ein Unternehmen hat für sein ERP-System ein RTO von 8 Stunden und ein RPO von 30 Minuten. Das heißt: Das ERP soll spätestens nach 8 Stunden wieder nutzbar sein. Und im schlimmsten Fall dürfen maximal 30 Minuten Daten verloren gehen.
Klingt einfach. Ist es aber nicht. Denn die eigentliche Frage lautet nicht „Was wünschen wir uns?“, sondern: Was können wir technisch, organisatorisch und wirtschaftlich belastbar zusagen?
Der BSI-Standard 200-4 stellt Business Continuity Management als systematischen Ansatz dar, um den Geschäftsbetrieb bei Ausfällen und Notfällen aufrechtzuerhalten oder wiederherzustellen. Dazu gehören eben nicht nur technische Wiederherstellungsmaßnahmen, sondern auch Rollen, Prozesse, Notbetrieb, Wiederanlauf und Managemententscheidungen.
Der häufigste Fehler: RTO wird pro System definiert
In vielen Workshops sehe ich Tabellen wie diese:
⚠ Typische, aber falsche Sicht: Systembezogen
Das sieht sauber aus. Ist aber oft die falsche Perspektive. Denn Geschäftsleitungen führen keine Systeme. Sie führen Leistungen. Deshalb muss die bessere Tabelle so aussehen:
✓ Bessere Sicht: Leistungsbezogen
RTO am System ist IT-Logik. RTO an der kritischen Leistung ist Geschäftslogik. Das ist der entscheidende Perspektivwechsel.
NIST SP 800-34 beschreibt Contingency Planning genau in dieser Logik: Organisationen sollen Systeme und Betriebsabläufe bewerten, um Anforderungen und Prioritäten für die Notfallplanung abzuleiten. Es geht nicht darum, isolierte Systeme schön zu dokumentieren, sondern darum, Wiederanlauf an geschäftlichen Prioritäten auszurichten.
Warum vier Stunden oft nicht vier Stunden sind
Ein RTO von vier Stunden klingt gut. Aber was heißt das konkret? Viele verstehen darunter: „Die IT stellt das System innerhalb von vier Stunden wieder her.“ Das ist zu kurz gedacht. Ein belastbares RTO umfasst die gesamte Kette bis zur nutzbaren Geschäftsleistung:
Vorfall erkennen — Detection, Alarmierung, Lagebild.
Lage bewerten und Krisenmodus aktivieren — Eskalation, Krisenstab, Entscheidungsstrukturen.
Ursache eingrenzen, Wiederherstellungsweg entscheiden — bei Cyberangriffen oft der zeitkritischste Block.
Systeme aus sauberen Quellen wiederherstellen — Restore, nicht infizierte Backups, Reihenfolge nach Abhängigkeiten.
Datenintegrität prüfen, Schnittstellen testen — technischer Online-Status reicht nicht.
Fachbereich nimmt Prozess wieder auf — erst hier endet das echte RTO.
Wenn die Uhr beim ersten Business Impact startet, dann zählt nicht nur die reine Restore-Zeit. Dann zählt die gesamte Kette bis zur nutzbaren Leistung. Gerade bei Cybervorfällen wird das oft unterschätzt. Bei Ransomware reicht es nicht, Daten zurückzuspielen. Man muss auch sicherstellen, dass die Umgebung sauber ist, dass Angreifer keinen Zugriff mehr haben, dass Identitäten wieder vertrauenswürdig sind. CISA empfiehlt deshalb, kritische Backups offline und verschlüsselt vorzuhalten und ihre Verfügbarkeit und Integrität regelmäßig in Disaster-Recovery-Szenarien zu testen.
Drei Beispiele aus der Praxis
Produktion mit „4 Stunden RTO"
Ein Produktionsunternehmen hatte für die zentrale Produktionssteuerung ein RTO von vier Stunden festgelegt. Auf dem Papier sah das gut aus. Im Workshop stellten wir drei Fragen: Wie lange dauert der technische Restore? Wie lange die Datenkonsistenzprüfung zwischen ERP, MES und Lager? Wie lange, bis die Produktion mit belastbaren Auftragsdaten arbeitet?
Technischer Restore: ca. 3–5 Stunden
Datenprüfung: 2–4 Stunden
Abstimmung mit Produktion und Logistik: +2 Stunden
Realistischer Wiederanlauf: eher 8–12 Stunden
Das eigentliche RTO war also nicht 4 Stunden, sondern mindestens 8. Das Problem war nicht die IT — das Problem war eine Managementannahme, die nie getestet wurde.
Best Practice: Für jede kritische Leistung sollte zwischen technischem Restore-Zeitpunkt, fachlicher Nutzbarkeit, stabiler Prozessfähigkeit und vollständigem Normalbetrieb unterschieden werden. Ein System, das technisch wieder online ist, ist noch kein wiederhergestellter Geschäftsprozess.
Online-Shop mit kurzem RTO, aber langem RPO
Ein E-Commerce-Unternehmen wollte für den Shop ein RTO von einer Stunde — nachvollziehbar, jede Stunde Ausfall kostete Umsatz. Aber das RPO war unklar. Der Shop sollte schnell wieder online gehen, aber Bestellungen, Warenkörbe, Zahlungen und Lagerbestände durften keinesfalls inkonsistent sein.
Die eigentliche Frage lautete nicht nur „Wie schnell ist der Shop wieder da?“, sondern: Mit welchem Datenstand darf er wieder online gehen? Ein RTO von einer Stunde mit einem RPO von 24 Stunden hätte bedeutet: schnell wieder sichtbar — aber operative Daten massiv veraltet. Für Kunden, Logistik und Buchhaltung kaum akzeptabel.
Best Practice: RTO und RPO müssen immer zusammen entschieden werden. Ein kurzes RTO mit langem RPO kann gefährlich sein. Ein kurzes RPO mit langem RTO kann ebenfalls geschäftlich unbrauchbar sein. Die Frage lautet immer: Welche Kombination aus Ausfalldauer und Datenverlust ist für diese Leistung tragbar?
Banking-Prozess mit regulatorischem Druck
Bei Finanzdienstleistern ist die Diskussion noch sensibler. Ein Zahlungsprozess kann nicht einfach „irgendwann“ wiederkommen. Gleichzeitig reicht es nicht, dass ein System technisch startet. Die Organisation muss sicherstellen, dass Transaktionen korrekt, nachvollziehbar und kontrolliert verarbeitet werden.
Hier können RTO und RPO nicht isoliert aus der IT heraus definiert werden. Es braucht mindestens: Fachbereich, IT, Informationssicherheit, Risikomanagement, Compliance, Datenschutz, Outsourcing-Management und die Geschäftsleitung — mit einem formalen Beschluss zu Kritikalität, tolerierbarem Ausfall, regulatorischen Anforderungen und akzeptiertem Restrisiko.
Warum RTO-Verkürzung nicht linear kostet
Einer meiner wichtigsten Sätze in RTO-Diskussionen lautet: RTO-Verkürzung skaliert nicht linear mit Kosten. Die ersten Stunden sind günstig zu gewinnen — die letzten kosten überproportional.
Kosten/Aufwand pro RTO-Stufe
Schematische Darstellung — reale Kurven hängen stark von Architektur, Cloud-Strategie und Ausgangslage ab.
Kurze RTOs bedeuten in der Realität: redundante Architektur, hochverfügbare Plattformen, automatisierte Wiederherstellung, aktuelle Replikation, klar definierte Failover-Verfahren, 24/7-Bereitschaft, regelmäßig getestete Runbooks, geringere manuelle Abhängigkeiten, höhere Lizenz- und Infrastrukturkosten und stärkere Provider-Abhängigkeiten.
Das ist keine reine IT-Budgetfrage. Das ist eine Geschäftsentscheidung. Eine Geschäftsleitung muss entscheiden, ob die Reduktion von 24 auf 4 Stunden den Preis wert ist. Manchmal ist sie es. Manchmal nicht. Aber die Entscheidung darf nicht zufällig entstehen.
Die gefährlichste RTO-Zahl: die ungeprüfte Vertragszusage
Besonders kritisch wird es, wenn RTOs in Verträgen, Kundenvereinbarungen oder internen Service-Level-Zusagen stehen. Dann ist eine unrealistische RTO nicht nur ein technisches Problem — sie wird ein rechtliches, finanzielles und reputatives Problem. Typische Formulierungen:
„Wiederherstellung innerhalb von 4 Stunden“
„99,9 % Verfügbarkeit“
„kritische Services werden am selben Geschäftstag wiederhergestellt“
„vollständige Datenwiederherstellung gewährleistet“
„Business Continuity Plan vorhanden“
Solche Aussagen klingen harmlos, bis ein Vorfall passiert. Dann fragt jemand: Können wir das wirklich nachweisen? Wenn nicht, wird aus Resilienzsprache schnell Haftungs- und Vertrauensrisiko.
Best Practice. Alle vertraglich zugesagten RTO-/RPO-Werte sollten mindestens jährlich gegen drei Dinge geprüft werden: technische Realität, getestete Wiederherstellungsfähigkeit und Business-Impact-Anforderung. Eine Zusage, die nie getestet wurde, ist keine Resilienzzusage. Sie ist eine Hoffnung.
Wie man RTO und RPO sauber festlegt
Ich nutze dafür gerne einen einfachen Ablauf in sechs Schritten.
Kritische Leistungen identifizieren. Nicht mit Systemen starten, sondern mit Leistungen: Kundenaufträge annehmen, Produktion steuern, Zahlungen verarbeiten, Patienten versorgen, Lieferungen disponieren, Notfallkommunikation sicherstellen.
Business Impact bestimmen. Umsatzverlust pro Stunde, Vertragsstrafen, regulatorische Folgen, Reputationsschaden, operative Ketteneffekte. Es geht nicht um Scheingenauigkeit, sondern um Entscheidungsfähigkeit.
MTPD, RTO und RPO unterscheiden. MTPD ist die maximal tolerierbare Ausfalldauer, RTO die Zielzeit für den Wiederanlauf (muss vor MTPD liegen), RPO der maximal tolerierbare Datenverlust.
Technische Machbarkeit prüfen. Welche Systeme, Datenbanken, Identitäten, Cloud-Dienste, Dienstleister und Abhängigkeiten? Hier zeigt sich oft: Ein Prozess hat ein RTO von 4 Stunden — aber hängt an einem Identity Provider mit 24 Stunden Wiederherstellungszeit.
Kosten und Zielbild gegenüberstellen. Status quo, verbesserter Restore, Hochverfügbarkeit, aktive Redundanz — mit Investitionsbedarf und Restrisiko.
Entscheidung dokumentieren. Beschlossenes Ziel, Geltungsbereich, Annahmen, Abhängigkeiten, Kostenrahmen, Restrisiko, Testfrequenz, Verantwortliche, nächste Überprüfung — nicht als technische Annahme, sondern als Managemententscheidung.
MTPD vs. RTO vs. RPO — Beispielwerte
„Wer RTO nicht entschieden hat, hat die längste Zeit faktisch akzeptiert — nur ohne es zu wissen.“
RTO ohne Test ist nur eine Behauptung
Ein RTO ist erst dann belastbar, wenn es getestet wurde — und zwar nicht nur technisch. Ein guter Test prüft Alarmierung, Krisenstabsaktivierung, Entscheidungswege, technischen Restore, Datenintegrität, Fachbereichsabnahme, Notbetrieb, Kommunikation, Dokumentation und Lessons Learned.
Viele Unternehmen testen nur den Restore eines Systems. Das ist wichtig, aber zu wenig. Die entscheidende Frage lautet: Konnte die kritische Leistung innerhalb des RTO wieder erbracht werden? Der BSI-Standard 200-4 betont die praktische Umsetzung und Steuerung eines BCM-Systems — dazu gehören nicht nur Konzepte, sondern auch Verfahren, Hilfsmittel und die Verankerung in der Organisation.
Fünf typische Fehlannahmen
1. „Wir haben Backups, also schaffen wir das RTO." Backups beantworten nur einen Teil der Frage. Nicht jedes Backup ist schnell wiederherstellbar, sauber, vollständig oder unter Krisenbedingungen getestet. Backups sind keine Resilienz — sie sind ein Baustein davon.
2. „Cloud macht unser RTO automatisch kurz." Cloud kann helfen, aber auch neue Abhängigkeiten schaffen. Wenn Identität, Netzwerk, Schlüsselmanagement oder Provider-Zugriffe betroffen sind, kann Wiederherstellung komplex werden.
3. „Die IT legt das RTO fest." Die IT kann sagen, was technisch möglich ist. Der Fachbereich, was geschäftlich nötig ist. Finance, was es kostet. Risk, welches Restrisiko bleibt. Entscheiden muss die Geschäftsleitung.
4. „Ein RTO gilt für alle Vorfälle." Ein Hardware-Ausfall ist etwas anderes als Ransomware. Bei Cybervorfällen sind Forensik, Eindämmung, Bereinigung, Credential-Rotation, Integritätsprüfung und sichere Wiederinbetriebnahme zusätzlich nötig.
5. „Wenn es im Vertrag steht, wird es schon stimmen." Verträge übernehmen oft alte Annahmen, Wunschwerte oder Zahlen aus Ausschreibungen. Ein vertragliches RTO ist nur dann belastbar, wenn Betrieb, Architektur, Personal, Dienstleister und Tests dazu passen.
Best-Practice-Modell: Die RTO-Entscheidungsmatrix
Diese Matrix zwingt die Diskussion auf die richtige Ebene. Nicht: „Kann IT das irgendwie schaffen?“ Sondern: Welche Resilienz kaufen wir — und welches Risiko akzeptieren wir bewusst?
Wie oft sollten RTO und RPO überprüft werden?
Mindestens jährlich — und zusätzlich immer bei relevanten Veränderungen: neue kritische Anwendungen, Cloud-Migration, neue Produktionsstandorte, M&A, neue regulatorische Anforderungen (etwa ENISA-Vorgaben, NIS2 oder DORA), neue Outsourcing-Partner, größere Architekturänderungen, relevante Incidents oder neue Kundenverträge mit SLA-Anforderungen.
Ein RTO von 2022 kann 2026 völlig falsch sein. Nicht weil jemand schlecht gearbeitet hat, sondern weil sich Geschäftsmodell, Abhängigkeiten und Technologie verändert haben.
Was Vorstände und Geschäftsführungen konkret verlangen sollten
RTO/RPO pro kritischer Leistung, nicht nur pro System.
Nachweis, wann das RTO zuletzt getestet wurde.
Transparenz über die Lücke zwischen Anspruch und Realität.
Kostenoptionen für kürzere Wiederanlaufzeiten.
Dokumentierte Entscheidung über akzeptiertes Restrisiko.
Damit wird BCM vom Dokumentationsprogramm zur Führungsdisziplin.
Fazit: RTO ist keine Zahl. RTO ist ein Versprechen.
„Vier Stunden RTO“ klingt gut. Aber die Zahl ist wertlos, wenn niemand weiß, was sie kostet, worauf sie sich bezieht und ob sie getestet wurde. Die zentrale Erkenntnis aus vielen Workshops ist für mich: RTO und RPO sind keine IT-Abkürzungen. Sie sind Managemententscheidungen.
Wer kurze Wiederanlaufzeiten will, muss sie bezahlen, bauen, betreiben und üben. Wer sie nicht bezahlen will, darf das entscheiden — aber dann muss auch das Restrisiko bewusst akzeptiert werden.
Das Problem sind nicht lange RTOs. Das Problem sind unbewusste RTOs.
Quellen & weiterführende Lektüre
- NIST — Cybersecurity Framework (CSF) 2.0: nist.gov/cyberframework
- NIST — SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems: csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
- BSI — BSI-Standard 200-4: Business Continuity Management: bsi.bund.de
- CISA — StopRansomware Guide: cisa.gov/stopransomware
- ENISA — Threat Landscape: enisa.europa.eu