¶ RPO und RTO verständlich erklärt
Kurz gesagt: Das RPO beantwortet die Frage „Wie viele Daten dürfen im schlimmsten Fall fehlen?“. Das RTO beantwortet die Frage „Wie lange darf der Service höchstens ausfallen?“. Beide Zielwerte werden aus den geschäftlichen Auswirkungen einer Unterbrechung abgeleitet – nicht allein aus den Möglichkeiten der IT.
Musterstatus: Diese Seite ist eine Wissens- und Entscheidungshilfe. Die genannten Zeitwerte sind Beispiele und keine Empfehlung für ein bestimmtes Unternehmen. Verbindliche RPO- und RTO-Werte müssen durch Business-Impact-Analyse, Risikobewertung, technische Prüfung und Freigabe festgelegt werden.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-WIS-05-01 |
| Dokumentenart | Wissens- und Entscheidungshilfe |
| Wiki.js-Pfad | /ISMS/05-Vorfaelle-und-Notfallmanagement/RPO-und-RTO-verstaendlich-erklaert |
| Verantwortlich | BCM-/ITSCM-Verantwortliche/r und ISMS-Beauftragte/r |
| Fachlich geprüft durch | Prozessverantwortliche, IT, Informationssicherheit, Datenschutz und Lieferantenmanagement |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – organisationsbezogene Zielwerte und Nachweise nicht bestätigt |
| Version | 1.0 |
| Stand | 09.08.2026 |
| Nächste Prüfung | Mindestens jährlich sowie nach BIA, Tests, Vorfällen oder wesentlichen Änderungen |
| Schutzklasse | Intern |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.29, 5.30, 8.13 und 8.14 |
| Ergänzende Orientierung | ISO 22301, ISO/IEC 27031 und BSI-Standard 200-4 |
RPO blickt vom Ausfall zum letzten nutzbaren Datenstand zurück; RTO misst vom definierten Ausfallbeginn bis zum wieder nutzbaren und freigegebenen Service. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Warum beide Werte benötigt werden
Ein System kann schnell wieder starten und trotzdem ungeeignete oder zu alte Daten enthalten. Umgekehrt kann ein vollständiger Datenbestand verfügbar sein, während Anwendung, Schnittstellen oder Benutzerzugänge noch stundenlang nicht funktionieren. Deshalb betrachten RPO und RTO zwei unterschiedliche Folgen desselben Ausfalls:
- RPO – Recovery Point Objective: zulässiger Datenverlust beziehungsweise zulässiger Abstand zwischen Störungszeitpunkt und dem letzten akzeptablen Wiederherstellungspunkt.
- RTO – Recovery Time Objective: angestrebte maximale Zeit vom festgelegten Beginn der Unterbrechung bis zur nutzbaren Wiederherstellung der Leistung.
RPO und RTO sind Zielwerte. Erst ein Test oder ein tatsächlicher Wiederanlauf liefert Ist-Werte. Ein eingetragener Zielwert ist daher noch kein Wirksamkeitsnachweis.
¶ 2. Der Zeitstrahl in einem Beispiel
Eine Auftragsanwendung fällt um 10:00 Uhr aus. Nach der Wiederherstellung stehen freigegebene Geschäftsdaten mit Stand 09:45 Uhr zur Verfügung. Der Service ist um 11:20 Uhr technisch stabil, sicherheitsgeprüft und fachlich freigegeben.
| Messgröße | Rechnung | Ergebnis | vereinbartes Ziel | Bewertung |
|---|---|---|---|---|
| tatsächliche Datenlücke | 10:00 − 09:45 | 15 Minuten | RPO 30 Minuten | Ziel erreicht |
| tatsächliche Wiederanlaufzeit | 11:20 − 10:00 | 1 Stunde 20 Minuten | RTO 2 Stunden | Ziel erreicht |
Wäre lediglich der Server um 10:50 Uhr gestartet, die Anwendung aber erst um 11:20 Uhr fachlich nutzbar gewesen, wäre 11:20 Uhr der relevante Endpunkt. Der reine Start eines Servers erfüllt das Geschäftsbedürfnis nicht.
¶ Messregeln
Ist-RTO = Zeitpunkt der nutzbaren und freigegebenen Leistung
minus definierter Beginn der Unterbrechung
Ist-Datenlücke = Bezugszeitpunkt der Unterbrechung
minus Zeitstempel des letzten akzeptablen Datenstands
Der Bezugszeitpunkt muss im Plan eindeutig festgelegt sein. Je nach Szenario kann dies der tatsächliche Ausfall, die Erkennung oder die formale Notfallerklärung sein. Ohne diese Festlegung sind Messergebnisse nicht vergleichbar.
¶ 3. RPO und RTO im direkten Vergleich
| Frage | RPO | RTO |
|---|---|---|
| Was wird begrenzt? | Datenverlust | Ausfallzeit der Leistung |
| Blickrichtung | rückwärts zum letzten akzeptablen Datenstand | vorwärts bis zur nutzbaren Wiederherstellung |
| Typische Einheit | Sekunden, Minuten oder Stunden Datenlücke | Minuten, Stunden oder Tage Ausfallzeit |
| Fachliche Grundlage | Wert und Wiederbeschaffbarkeit der Daten, Transaktionsvolumen, rechtliche und vertragliche Folgen | Auswirkung einer Nichtverfügbarkeit auf Betrieb, Kunden, Sicherheit, Recht und Reputation |
| Technische Einflussgrößen | Sicherungsintervall, Replikation, Transaktionsprotokolle, Konsistenz und Integrität | Architektur, Ersatzsysteme, Personal, Abhängigkeiten, Wiederaufbau, Restore, Tests und Freigabe |
| Typischer Nachweis | wiederhergestellter Datenstand mit Zeitstempel und Vollständigkeitsprüfung | Zeitlinie vom Startpunkt bis zur technischen und fachlichen Freigabe |
| Häufiger Irrtum | „Tägliches Backup bedeutet automatisch RPO 24 Stunden.“ | „Der Server läuft wieder, also ist das RTO erfüllt.“ |
¶ 4. Wie Zielwerte festgelegt werden
Die Zielwerte beginnen beim Geschäftsprozess. In der Notfallvorsorge und im BCM werden die Auswirkungen einer Unterbrechung über die Zeit untersucht. Daraus entstehen unter anderem maximal tolerierbare Ausfallzeiten, Mindestbetriebsniveaus und Wiederanlaufprioritäten. Anschließend wird geprüft, welche Anwendungen, Daten, Personen, Standorte und Dienstleister benötigt werden.
Ein belastbarer Ablauf umfasst:
- relevanten Prozess und Service eindeutig abgrenzen,
- Folgen von Datenverlust und Nichtverfügbarkeit zeitabhängig bewerten,
- maximal tolerierbare Ausfallzeit – häufig MTPD oder MTPDO genannt – festlegen,
- fachliches RPO und RTO innerhalb dieser Grenze bestimmen,
- abhängige Services mit eigenen, gegebenenfalls kürzeren Zielwerten versehen,
- technische und organisatorische Lösungsoptionen bewerten,
- Kosten, Risiken, Verträge und Stand der Technik gegeneinander abwägen,
- Zielwerte durch Prozess- und Serviceverantwortliche bestätigen lassen,
- Wiederanlaufverfahren erstellen und testen,
- Soll-/Ist-Abweichungen als Risiko oder Maßnahme behandeln.
Das RTO muss vor dem Zeitpunkt liegen, ab dem der Schaden für die Organisation nicht mehr tragbar ist. Zusätzlich wird Zeit für Lageerkennung, Entscheidungen, abhängige Services, Notbetrieb und Rückkehr zum Normalbetrieb benötigt. Deshalb darf die Summe aller Teilzeiten nicht unbemerkt größer als die tolerierbare Gesamtdauer werden.
¶ 5. Praxisbeispiele
¶ 5.1 Produktionssteuerung
Ein Produktionsprozess benötigt ein RPO von 5 Minuten und ein RTO von 30 Minuten. Eine nächtliche Sicherung kann dieses RPO nicht erfüllen, weil bis zu 24 Stunden Daten fehlen könnten. Mögliche Lösungsbausteine sind engmaschige Transaktionssicherung, geeignete Replikation, eine vorbereitete Ersatzumgebung, qualifiziertes Personal und getestete Umschaltverfahren. Ob diese Maßnahmen genügen, zeigt erst ein Ende-zu-Ende-Test einschließlich Maschinen-, Schnittstellen- und Fachfreigabe.
¶ 5.2 Allgemeine Dateiablage
Für eine weniger zeitkritische Ablage werden beispielhaft RPO 24 Stunden und RTO 8 Stunden festgelegt. Eine täglich erfolgreich erzeugte Sicherung könnte das RPO unterstützen. Sie genügt aber nur, wenn der Sicherungszeitpunkt, die vollständige Abdeckung, die Integrität und die tatsächliche Rücksicherung geprüft sind. Für das RTO müssen außerdem Bereitstellung von Infrastruktur, Restore, Berechtigungen, Virenprüfung und Benutzerfreigabe in acht Stunden möglich sein.
¶ 5.3 Cloud- und SaaS-Dienst
Der Fachbereich benötigt den Service nach spätestens zwei Stunden. Der Vertrag des Anbieters nennt aber ein Wiederherstellungsziel von vier Stunden und macht keine ausreichend genaue Zusage zum Datenstand. Damit besteht eine dokumentationspflichtige Lücke. Optionen sind ein höheres Serviceniveau, ein Ersatzverfahren, ein zusätzlicher Datenexport, ein anderer Anbieter oder eine formale Risikoakzeptanz. Ein Marketingversprechen zur Verfügbarkeit ersetzt keine überprüfbare RTO-/RPO-Zusage.
¶ 5.4 Ransomware
Die neuesten Sicherungen können Schadsoftware, verschlüsselte Daten oder manipulierte Konten enthalten. Dann muss auf einen älteren, vertrauenswürdigen Stand zurückgegriffen werden. Obwohl Backups vorhanden sind, kann das RPO überschritten werden. Gleichzeitig verlängern forensische Prüfung, Bereinigung, Neuaufbau und Credential-Rotation das RTO. Das Beispiel zeigt, warum unveränderbare Sicherungen, getrennte Administrationswege, saubere Wiederherstellungsumgebungen und Cyber-Recovery-Tests wichtig sind.
¶ 6. Beispielhafte Kritikalitätsklassen
Achtung: Die folgende Tabelle ist nur eine Diskussionshilfe. Sie ersetzt keine BIA und keine organisationsbezogene Entscheidung.
| Beispielklasse | denkbares RTO | denkbares RPO | typische technische Konsequenz |
|---|---|---|---|
| K1 – existenziell | 30 Minuten | 5 Minuten | hohe Automatisierung, redundante Komponenten, kurze Umschaltung, intensive Tests |
| K2 – sehr hoch | 2 Stunden | 30 Minuten | vorbereitete Ersatzkapazität, häufige Sicherung oder Replikation, klare Bereitschaft |
| K3 – mittel | 8 Stunden | 4 Stunden | planbarer Restore mit verfügbaren Fachrollen und dokumentierten Abhängigkeiten |
| K4 – niedrig | 48 Stunden | 24 Stunden | klassische Sicherung und geplanter Wiederaufbau können ausreichend sein |
Ein kürzerer Zielwert ist nicht automatisch besser. Er erhöht regelmäßig Kosten und Komplexität. Entscheidend ist ein begründetes Verhältnis zwischen Schadenspotenzial, rechtlichen und vertraglichen Anforderungen, technischer Machbarkeit und Ressourceneinsatz.
¶ 7. Technische Lösung ist nicht gleich Geschäftsziel
Ein Sicherungsintervall von 15 Minuten kann ein RPO von 15 Minuten unterstützen, aber nicht allein beweisen. Fehlgeschlagene Jobs, unvollständige Datenbanken, asynchrone Schnittstellen, Zeitabweichungen oder beschädigte Sicherungen können die tatsächliche Datenlücke vergrößern.
Auch das technische Restore-Zeitfenster ist nur ein Teil des RTO. Zur Ende-zu-Ende-Dauer gehören je nach Service:
- Erkennung, Bewertung und Aktivierung des Verfahrens,
- Verfügbarkeit von Entscheidern und Spezialisten,
- Bereitstellung oder Bereinigung der Zielumgebung,
- Wiederherstellung von Netz, Identitäten, Schlüsseln und Basisdiensten,
- Restore oder Wiederaufbau von Anwendung und Daten,
- Integritäts-, Sicherheits- und Schadsoftwareprüfung,
- Synchronisierung von Schnittstellen und Nachverarbeitung,
- technischer Funktionstest,
- fachliche Abnahme und dokumentierte Produktivfreigabe.
Die Wiederanlaufplanung ordnet diese Schritte und ihre Abhängigkeiten. Die Datensicherung und Wiederherstellung behandelt Sicherungsumfang, Schutz und Restore.
¶ 8. Typische Fehler und bessere Prüfungsfragen
| Fehler | bessere Prüfungsfrage |
|---|---|
| IT legt Zielwerte ohne Fachbereich fest | Welche geschäftliche Auswirkung begründet genau diesen Wert? |
| Backup-Intervall wird mit RPO gleichgesetzt | Welcher konsistente Datenstand wurde tatsächlich wiederhergestellt und geprüft? |
| Serverstart gilt als RTO-Ende | Ab wann konnten berechtigte Nutzer den fachlichen Prozess sicher ausführen? |
| alle Services erhalten dieselben Werte | Welche Abhängigkeit muss früher bereitstehen als der Geschäftsservice? |
| Providerangaben werden ungeprüft übernommen | Sind die Zusagen vertraglich, messbar und mit dem eigenen Bedarf vereinbar? |
| Normalstörung ist das einzige Testszenario | Was geschieht bei Ransomware, Standortausfall oder fehlendem Personal? |
| Test stoppt nach dem Restore | Wurden Schnittstellen, Berechtigungen, Datenkonsistenz und Fachfunktion abgenommen? |
| überschrittene Ziele bleiben folgenlos | Wurde eine Maßnahme, Neubewertung oder befristete Risikoakzeptanz dokumentiert? |
¶ 9. Nachweise und Wirksamkeitsprüfung
Für jeden kritischen Service sollten mindestens folgende Angaben nachvollziehbar sein:
| Nachweisfeld | Erwarteter Inhalt |
|---|---|
| Service und Owner | eindeutige Bezeichnung, verantwortliche Fach- und IT-Rolle |
| Prozessbezug | BIA, Kritikalität, Mindestbetriebsniveau und tolerierbare Gesamtdauer |
| Sollwerte | bestätigtes RTO und RPO mit Begründung und Freigabe |
| Messbeginn und Messende | eindeutig definierte Zeitpunkte und Zeitquelle |
| Wiederherstellungspunkt | gewählter Datenstand, Zeitstempel und Auswahlbegründung |
| Test-/Vorfallzeitlinie | Alarmierung, Entscheidungen, technische Schritte und Freigaben |
| Istwerte | gemessene Wiederanlaufzeit und tatsächliche Datenlücke |
| Prüfergebnis | technische, sicherheitsbezogene und fachliche Abnahme |
| Abweichung | Soll-/Ist-Vergleich, Ursache, Risiko und Auswirkung |
| Folgemaßnahme | Owner, Termin, Priorität, Retest und Abschlussnachweis |
Restore- und Wiederanlauftests werden unter Backup-, Restore- und Wiederanlauftests dokumentiert. Zielüberschreitungen oder ungeklärte technische Grenzen gehören in das Risikoregister und gegebenenfalls in den Risikobehandlungsplan.
¶ 10. Kompakte Prüfliste
- Prozess, Service, Datenbestand und Abhängigkeiten sind eindeutig abgegrenzt.
- RPO und RTO wurden aus der BIA abgeleitet und fachlich bestätigt.
- Zielwerte liegen innerhalb der maximal tolerierbaren Gesamtausfallzeit.
- Provider- und Lieferantenzusagen passen zu den eigenen Zielwerten.
- Sicherungs-, Replikations- und Wiederanlaufverfahren sind technisch geeignet.
- Messbeginn, Wiederherstellungspunkt und Freigabekriterium sind definiert.
- Tests umfassen Technik, Sicherheit, Schnittstellen und Fachfunktion.
- Ist-RTO und tatsächliche Datenlücke werden getrennt gemessen.
- Abweichungen führen zu Maßnahmen, Risikobewertung oder genehmigter Akzeptanz.
- Zielwerte und Verfahren werden nach Änderungen, Tests und Vorfällen aktualisiert.
¶ 11. Weiterführende Seiten
- Notfallvorsorge und BCM
- Wiederanlaufplanung
- Datensicherung und Wiederherstellung
- Backup-, Restore- und Wiederanlauftests
- Prozesslandkarte
- Risikoregister
¶ 12. Externe Orientierung
- NIST SP 800-34 Rev. 1 – Contingency Planning Guide for Federal Information Systems
- NIST – Contingency Planning
- BSI – Ressourcen und Wiederanlauf-Parameter bestimmen
Die externen Quellen dienen der fachlichen Orientierung. Maßgeblich sind die für die Organisation geltenden gesetzlichen, vertraglichen und freigegebenen internen Anforderungen.
¶ 13. Änderungsverlauf
| Version | Datum | Änderung | Status |
|---|---|---|---|
| 1.0 | 09.08.2026 | Erstfassung mit Zeitstrahl, Berechnungen, Praxisbeispielen, Zielwertableitung, Fehlerbildern und Nachweisfeldern | Entwurf |