---
title: "RTO und RPO richtig definieren: Praxisanleitung"
date: 2026-06-01T14:50:00+02:00
author: FAST LTA
canonical_url: "https://www.fast-lta.de//de/blog/rto-und-rpo-richtig-definieren-praxisanleitung"
section: "Entries: Articles"
---
### Die Defi­ni­tio­nen [\#](#die-definitionen "Die Definitionen")

#### Reco­very Time Objec­ti­ve (RTO) [\#](#recovery-time-objective-rto "Recovery Time Objective (RTO)")

RTO ist der **maxi­ma­le akzep­ta­ble Aus­fall­zeit­raum** eines Systems/​Prozesses.

Bei­spie­le:

- “Unser ERP hat RTO 4 Stun­den” = Wenn das ERP down geht, müs­sen wir es in maxi­mal 4 Stun­den wie­der hochfahren.
- “Unse­re File­ser­ver haben RTO 8 Stun­den” = Nach 8 Stun­den sind die Aus­wir­kun­gen zu groß; wir müs­sen sie online haben.
- “Unser CRM hat RTO 2 Stun­den” = Sales-Team kann maxi­mal 2 Stun­den ohne CRM arbeiten.

RTO ist eine **geschäft­li­che Ent­schei­dung**, nicht technisch.

#### Reco­very Point Objec­ti­ve (RPO) [\#](#recovery-point-objective-rpo "Recovery Point Objective (RPO)")

RPO ist der **maxi­mal akzep­ta­ble Daten­ver­lust** eines Systems.

Bei­spie­le:

- “Unser ERP hat RPO 1 Stun­de” = Wir kön­nen bis zu 1 Stun­de an Trans­ak­tio­nen verlieren.
- “Unse­re Daten­bank hat RPO 15 Minu­ten” = Wir tes­ten stünd­li­che Back­ups, akzep­tie­ren bis zu 15 Minu­ten Datenverlust.
- “Unse­re E‑Mail hat RPO 24 Stun­den” = E‑Mail-Ver­lust von bis zu 24 Stun­den ist akzep­ta­bel (nicht ide­al, aber geschäftsverträglich).

RPO ist auch eine **geschäft­li­che Ent­schei­dung** — wie­viel Daten­ver­lust kön­nen Sie wirt­schaft­lich tolerieren?

### Bezie­hung zu ande­ren Begrif­fen [\#](#beziehung-zu-anderen-begriffen "Beziehung zu anderen Begriffen")

Es gibt zwei wei­te­re Begrif­fe, die oft ver­wech­selt werden:

**Mean Time To Reco­ver (MTTR):** Die durch­schnitt­li­che Zeit, die es tat­säch­lich dau­ert, ein Sys­tem zu recovered.

**Reco­very Time Objec­ti­ve (RTO):** Die maxi­ma­le Zeit, die wir uns leis­ten können.

Die Dif­fe­renz ist der Puf­fer. Wenn RTO = 4 Stun­den und MTTR = 3 Stun­den (aus Tests), haben Sie 1 Stun­de Puf­fer. Das ist knapp.

**Maxi­mum Tole­ra­ble Down­ti­me (MTD):** Der größ­ten Scha­den, den das Unter­neh­men tole­rie­ren kann (in Geldwert).

RTO ist die Zeit-Dimen­si­on von MTD.

### BIA-Work­shop Metho­dik: Wie man RTO/RPO ablei­tet [\#](#bia-workshop-methodik-wie-man-rto-rpo-ableitet "BIA-Workshop Methodik: Wie man RTO/RPO ableitet")

Das ist die rich­ti­ge Reihenfolge:

#### Schritt 1: Kri­ti­sche Pro­zes­se iden­ti­fi­zie­ren [\#](#schritt-1-kritische-prozesse-identifizieren "Schritt 1: Kritische Prozesse identifizieren")

Laden Sie ein: CFO, COO, Abtei­lungs­lei­ter, IT-Leiter.

Gehen Sie durch jede Geschäftsabteilung:

- Sales: ​“Ohne CRM kön­nen wir wie lan­ge arbeiten?”
- Ope­ra­ti­ons: ​“Ohne Pro­duk­ti­ons-Steue­rung kön­nen wir wie lan­ge arbeiten?”
- Finan­ce: ​“Ohne Buch­hal­tungs-Sys­tem kön­nen wir wie lan­ge arbeiten?”

#### Schritt 2: Impact qua­li­fi­zie­ren [\#](#schritt-2-impact-qualifizieren "Schritt 2: Impact qualifizieren")

Für jeden Pro­zess: ​“Was pas­siert, wenn die­ser Pro­zess für X Stun­den down ist?”

**Sales-Bei­spiel:**

- 1 Stun­de down: ​“Wenig Aus­wir­kung; Off­line-Ver­kauf im CRM nachholen.”
- 4 Stun­den down: ​“Bedeut­sa­mer Ein­fluss; wir ver­lie­ren meh­re­re wich­ti­ge Deals.”
- 8 Stun­den down: ​“Kri­ti­scher Impact; Kun­den kon­tak­tie­ren Konkurrenz.”

**Pro­duk­ti­on-Bei­spiel:**

- 30 Minu­ten down: ​“Kein Pro­blem; Fer­ti­gungs-Puf­fer absorbiert.”
- 2 Stun­den down: ​“Wir gera­ten in Ver­zug bei ein­zel­nen Aufträgen.”
- 4 Stun­den down: ​“Lie­fer­ver­zö­ge­run­gen, Kun­den unzu­frie­den, Strafkosten.”

#### Schritt 3: RTO-Schwell­wert fest­le­gen [\#](#schritt-3-rto-schwellwert-festlegen "Schritt 3: RTO-Schwellwert festlegen")

Die RPT-Schwel­le ist **der Punkt, nach dem Geschäftsim­pakt zu groß wird**.

Bei­spiel:

- Sales CRM: ​“Nach 4 Stun­den ver­lie­ren wir signi­fi­kan­te Deals. Des­halb RTO = 4 Stunden.”
- Pro­duk­ti­on: ​“Nach 2 Stun­den gera­ten wir in Lie­fer-Schwie­rig­kei­ten. Des­halb RTO = 2 Stunden.”

Das ist nicht theo­re­tisch — das ist Geschäfts-Tatsache.

#### Schritt 4: RPO-Thres­hold fest­le­gen [\#](#schritt-4-rpo-threshold-festlegen "Schritt 4: RPO-Threshold festlegen")

Für jeden Pro­zess: ​“Wie aktu­ell müs­sen die Daten sein?”

**Sales CRM-Bei­spiel:**

- “Sale­s­peo­p­le machen täg­lich neue Deals. Daten­ver­lust von mehr als einer Stun­de ist pro­ble­ma­tisch. Des­halb RPO = 1 Stunde.”

**Pro­duk­ti­ons-Daten­bank-Bei­spiel:**

- “Wir erfas­sen Pro­duk­ti­ons­lo­se real-time. Daten­ver­lust von mehr als 15 Minu­ten bedeu­tet, dass wir nicht wis­sen, was gera­de pro­du­ziert wur­de. Des­halb RPO = 15 Minuten.”

**E‑Mail-Bei­spiel:**

- “E‑Mail ist wich­tig, aber nicht kri­tisch. Daten­ver­lust von bis zu 24 Stun­den ist wirt­schaft­lich tole­rier­bar. Des­halb RPO = 24 Stunden.”

#### Schritt 5: Abhän­gig­kei­ten doku­men­tie­ren [\#](#schritt-5-abh%C3%A4ngigkeiten-dokumentieren "Schritt 5: Abhängigkeiten dokumentieren")

Wel­che ande­ren Sys­te­me braucht die­ses Sys­tem um zu funktionieren?

“ERP braucht Acti­ve Direc­to­ry.” ​“File­ser­ver braucht Netz­werk-Zugang.” ​“Data­ba­se braucht Backup-Storage.”

Das bestimmt die Reco­very-Rei­hen­fol­ge: AD muss vor ERP wie­der­her­ge­stellt werden.

### Typi­sche RTO/RPO Wer­te nach Sys­tem­ka­te­go­rie [\#](#typische-rto-rpo-werte-nach-systemkategorie "Typische RTO/RPO Werte nach Systemkategorie")

Dies sind Richt­li­ni­en, nicht Regel:

Sys­temKate­go­rieTypi­scher RTOTypi­sches RPO\*\*Acti­ve Directory\*\*kri­tisch1 – 2 Std15 Min\*\*ERP\*\*kri­tisch4 Std1 Std\*\*E‑Commerce Web­site\*\*kri­tisch1 Std15 Min\*\*E‑Mail\*\*wich­tig8 – 24 Std1 – 24 Std\*\*CRM\*\*wich­tig4 Std1 Std\*\*File­ser­ver\*\*wich­tig8 Std1 Std\*\*Data­ba­se\*\*kri­tisch2 – 4 Std15 Min — 1 Std\*\*Deve­lo­p­ment-Tools\*\*nied­rig48 Std1 TagDie Begrün­dung: Kri­ti­sche Sys­te­me, auf die Kun­den oder Pro­duk­ti­on abhän­gig sind, haben aggres­si­ve RTO/RPO. Inter­ne oder non-Cus­to­mer-facing Sys­te­me kön­nen ent­spann­ter sein.

### RTO-Mes­sung: Geschätzt vs. Getes­tet [\#](#rto-messung-gesch%C3%A4tzt-vs-getestet "RTO-Messung: Geschätzt vs. Getestet")

Ein häu­fi­ger Feh­ler: ​“Unser RTO ist 4 Stun­den” — aber das ist eine Schät­zung, nie getestet.

**Geschätz­te RTO:** ​“Unser Back­up-Sys­tem kann 2 Stun­den Res­to­re-Zeit pro 100GB. Unser ERP ist 500GB. Also RTO ≈ 10 Stunden.”

**Getes­te­te RTO:** ​“Wir haben einen ech­ten Reco­very-Test durch­ge­führt. Back­up wur­de in 2 Stun­den wie­der­her­ge­stellt. Das ist unse­re **tat­säch­li­che** RTO.”

Die Dif­fe­renz kann enorm sein. Back­ups, die nicht getes­tet wur­den, sind oft nicht wie­der­her­stell­bar. RPT von 4 Stun­den ist nur vali­de, wenn sie getes­tet wurden.

### Häu­fi­ge Feh­ler [\#](#h%C3%A4ufige-fehler "Häufige Fehler")

**Feh­ler 1: Unrea­lis­ti­sche RTO** ​“Unser ERP-RTO ist 30 Minu­ten” — aber ihr Reco­very-Pro­zess dau­ert 2 Stun­den. Das ist kein RTO, das ist Traum.

Die Lösung: RTO muss mit tat­säch­li­chen Reco­very-Zei­ten ali­gned sein, oder Sie müs­sen mehr in Infra­struk­tur inves­tie­ren (bes­se­re Back­ups, Fail­over, etc.).

**Feh­ler 2: Abhän­gig­kei­ten vergessen** ​“Unser ERP-RTO ist 4 Stun­den — aber wir haben nicht geprägt, dass AD auch reco­ver­ed wer­den muss, was wei­te­re 2 Stun­den dauert.”

Reco­very-Rei­hen­fol­ge ist wichtig.

**Feh­ler 3: RPO grö­ßer als RTO** ​“RTO 4 Stun­den, RPO 1 Woche” — das ergibt kei­nen Sinn. Wenn Sie den Ser­ver nach 4 Stun­den wie­der­her­stel­len, aber nur Wochen­al­ter Daten haben, haben Sie zu viel Datenverlust.

Typi­scher­wei­se: RPO ≤ RTO.

### Doku­men­ta­ti­on [\#](#dokumentation "Dokumentation")

RTO/RPO soll­te doku­men­tiert und geneh­migt sein:

```
System: ERP (SAP)
RTO: 4 Stunden
RPO: 1 Stunde
Begründung: Produktion und Sales hängen davon ab. Nach 4 Stunden Ausfall entstehen Lieferverzögerungen. Nach 1 Stunde Datenverlust ist Tagesabschluss beeinträchtigt.
Getestet: Ja (Letzter Test: 15.02.2026 — tatsächliche Recovery-Zeit: 2.5 Stunden)
Approver: CIO, CFO
Gültig bis: 15.02.2027 (Jährliche Überprüfung)

```

Die­ses Doku­ment ist dein Beweis gegen­über Audi­to­ren, dass du RTO/RPO ratio­nal defi­niert hast.

### Häu­fi­ge Fra­gen [\#](#h%C3%A4ufige-fragen "Häufige Fragen")

**Wer bestimmt RTO/RPO?** Die Geschäfts­sei­te (CFO, Abtei­lungs­lei­ter) bestimmt, was sie brau­chen. IT sagt, ob das tech­nisch mach­bar ist und zu wel­chem Kosten.

**Kön­nen RTO/RPO sich ändern?** Ja. Jähr­lich soll­ten sie review­ed wer­den. Nach signi­fi­kan­ten Geschäfts­ver­än­de­run­gen sofort.

**Was ist, wenn RTO tech­nisch nicht mach­bar ist?** Dann müs­sen Sie inves­tie­ren (bes­se­re Infra­struk­tur) oder Sie müs­sen den RTO-Erwar­tung reduzieren.

---