RTO und RPO sind die zwei fun­da­men­ta­len Kenn­zah­len jeder Busi­ness-Con­ti­nui­ty- und Disaster-Recovery-Planung.

Das Reco­very Time Objec­ti­ve (RTO) gibt an, wie lan­ge ein Sys­tem oder ein Geschäfts­pro­zess nach einem Aus­fall maxi­mal nicht ver­füg­bar sein darf, bevor es zu exis­tenz­be­dro­hen­den Schä­den kommt. Ein RTO von 4 Stun­den für das ERP-Sys­tem bedeu­tet: Der Wie­der­her­stel­lungs­pro­zess muss in weni­ger als 4 Stun­den abge­schlos­sen sein.

Das Reco­very Point Objec­ti­ve (RPO) gibt an, wie viel Daten­ver­lust maxi­mal akzep­ta­bel ist — aus­ge­drückt als Zeit­raum. Ein RPO von 1 Stun­de für Trans­ak­ti­ons­da­ten bedeu­tet: Back­ups müs­sen min­des­tens stünd­lich erstellt wer­den, damit im Ernst­fall maxi­mal 1 Stun­de an Trans­ak­ti­ons­da­ten ver­lo­ren geht.

Der häu­figs­te Feh­ler: RTO und RPO wer­den defi­niert, aber nie gegen die tat­säch­li­che Back­up-Archi­tek­tur getes­tet. Ein RTO von 4 Stun­den ist wert­los, wenn der tat­säch­li­che Res­to­re 48 Stun­den dau­ert. (Art. 11) und NIS2 (§30 NIS2UmsuCG) ver­lan­gen aus­drück­lich, dass RTOs und RPOs nicht nur defi­niert, son­dern durch doku­men­tier­te Tests belegt sind. Typi­sche RTOs nach Back­up-Archi­tek­tur: Fest­plat­ten­ba­sier­ter (Silent Brick) 4 – 8 Stun­den; Tape-basier­tes 24 – 96 Stun­den; Cloud-Back­up 12 – 72 Stun­den (WAN-abhän­gig, aber im Ran­som­wa­re-Fall oft kompromittiert).

Fragen und Antworten

Ausgangspunkt ist eine Business Impact Analysis (BIA): Welcher finanzielle, operative und reputative Schaden entsteht pro Stunde Ausfall je kritischem System? Daraus ergibt sich die Maximum Tolerable Downtime (MTD), aus der sich das RTO ableitet. Das RPO folgt aus der Backup-Frequenz und dem Wert der im letzten Backup-Intervall erzeugten Daten. RTO und RPO müssen von der Geschäftsführung genehmigt und in der Backup-Architektur technisch umgesetzt werden.
Nach NIS2 (§38 NIS2UmsuCG) und DORA muss die Geschäftsführung die Backup-Strategie genehmigen — das schließt RTO und RPO ein. IT-Leiter und CISOs tragen die operative Verantwortung für die Umsetzung. Die Dokumentation von Recovery-Tests schützt alle Beteiligten: Sie belegt, dass RTO-Ziele bekannt waren und die Architektur entsprechend ausgelegt wurde.