Die Recovery Point Objective, kurz RPO, beziffert den Datenverlust, den eine Organisation im Störungsfall hinnehmen kann. Sie wird als Zeitspanne angegeben und bezieht sich auf den Zeitraum vor dem Ereignis: Bei einer RPO von vier Stunden dürfen die Arbeitsergebnisse der letzten vier Stunden verloren gehen. Wie die Recovery Time Objective stammt sie aus der Business Impact Analyse und wird vom Fachbereich vorgegeben, nicht von der IT.
Vorgabe und Umsetzung nicht verwechseln
Die RPO ist eine Anforderung. Das Sicherungsintervall ist die technische Antwort darauf. Zwischen beiden besteht eine feste Beziehung: Der Abstand zwischen zwei Sicherungen begrenzt den maximal möglichen Verlust, also muss er höchstens so groß sein wie die RPO.
In der Praxis stehen diese beiden Werte oft unabgeglichen nebeneinander. Im Notfallkonzept steht eine RPO von einer Stunde, im Betriebshandbuch eine nächtliche Sicherung. Beide Dokumente sind für sich schlüssig, zusammen ergeben sie einen möglichen Verlust eines vollen Arbeitstages. Der Abgleich dieser beiden Angaben ist eine der schnellsten und ergiebigsten Prüfungen im internen Audit.
Der Wiederherstellungspunkt ist nicht die letzte Sicherung
Maßgeblich ist der letzte Stand, der sich tatsächlich verwenden lässt. Drei Fälle verschieben diesen Punkt nach hinten:
Die Sicherung ist unbrauchbar. Ohne regelmäßige Rückspielprobe ist unbekannt, ob sich der Bestand wiederherstellen lässt. Der reale Wiederherstellungspunkt liegt dann beim letzten geprüften Stand.
Die Sicherung ist inkonsistent. Wenn Datenbank und Dateiablage zu unterschiedlichen Zeitpunkten gesichert werden, ist der gemeinsam nutzbare Punkt der ältere von beiden.
Der Fehler ist mitgesichert worden. Bei Verschlüsselung durch Schadsoftware oder einer fehlerhaften Massenänderung liegt der brauchbare Punkt vor dem Beginn des Vorfalls. Wenn der Vorfall Tage unbemerkt lief, wird die Aufbewahrungstiefe zur eigentlichen Begrenzung. Eine Replikation hilft hier nicht, sie überträgt den Schaden. Diese Lücke gehört als Restrisiko benannt und nicht stillschweigend übergangen.
Was außerhalb der Systeme liegt
Zwischen der Entstehung einer Information und ihrer Erfassung vergeht Zeit. Der Wareneingangsschein auf der Rampe, das Prüfprotokoll auf dem Klemmbrett, die telefonische Bestellung im Notizblock — dieser Bestand ist durch keine Sicherung gedeckt. Wer eine niedrige RPO zusagt, sollte prüfen, wie lange Informationen typischerweise unerfasst bleiben. Häufig ist diese Spanne größer als das Sicherungsintervall.
Die Vorgabe gehört an den Prozess, nicht an das System
Zwei Prozesse können dieselbe Datenbank nutzen und sehr unterschiedliche Verluste vertragen. Die Vorgabe wird deshalb an der Aktivität festgelegt und erst danach auf die Systeme abgebildet, die sie tragen. Trifft eine Datenbank auf mehrere Aktivitäten mit unterschiedlichen Vorgaben, gilt die strengste — dieselbe Logik wie beim Maximumprinzip der Schutzbedarfsfeststellung.
Umgekehrt lohnt die Prüfung, ob sich eine besonders strenge Anforderung isolieren lässt. Eine einzelne Tabelle mit kurzer Vorgabe getrennt zu sichern ist meist günstiger, als das Sicherungsintervall des gesamten Bestands zu verkürzen.
Woran es scheitert
Eine RPO für alle Systeme. Buchhaltung, Konstruktionsdaten und Fertigungsaufträge vertragen sehr unterschiedliche Verluste. Eine gemeinsame Vorgabe ist entweder zu teuer oder zu riskant.
Keine Rückspielprobe. Eine ungeprüfte Sicherung ist eine Annahme. Ein dokumentierter Test mit Datum und gemessener Dauer beantwortet im Überwachungsaudit zwei Fragen auf einmal.