---
title: "Defining RTO and RPO Correctly: A Practical Guide"
date: 2026-06-01T14:50:00+02:00
author: FAST LTA
canonical_url: "https://www.fast-lta.de//en/blog/rto-und-rpo-richtig-definieren-praxisanleitung"
section: "Entries: Articles"
---
### Definitions [\#](#definitions "Definitions")

#### Recovery Time Objective (RTO) [\#](#recovery-time-objective-rto "Recovery Time Objective (RTO)")

RTO is the **maximum acceptable downtime** for a system or process.

Examples:

- “Our ERP has an RTO of 4 hours” = if the ERP goes down, we must bring it back within 4 hours.
- “Our file servers have an RTO of 8 hours” = after 8 hours, the business impact is too large; they must be online.
- “Our CRM has an RTO of 2 hours” = the sales team can work without CRM for at most 2 hours.

RTO is a **business decision**, not a technical one.

#### Recovery Point Objective (RPO) [\#](#recovery-point-objective-rpo "Recovery Point Objective (RPO)")

RPO is the **maximum acceptable data loss** for a system, expressed as time.

Examples:

- “Our ERP has an RPO of 1 hour” = we can lose up to 1 hour of transactions.
- “Our database has an RPO of 15 minutes” = backup or replication intervals must guarantee that no more than 15 minutes of data can be lost.
- “Our email has an RPO of 24 hours” = up to 24 hours of email loss is acceptable (not ideal, but tolerable for the business).

RPO is also a **business decision**: how much data loss can you economically tolerate?

### Relationship to Other Terms [\#](#relationship-to-other-terms "Relationship to Other Terms")

Two other terms are often confused with RTO and RPO:

**Mean Time To Recover (MTTR):** The average time it actually takes to recover a system, as measured in practice or in tests.

The difference between RTO and MTTR is your buffer. If RTO = 4 hours and MTTR = 3 hours (measured from tests), you have 1 hour of buffer. That is tight.

**Maximum Tolerable Downtime (MTD):** The longest outage the organization can survive before the damage becomes unacceptable. The RTO is set below the MTD to leave a safety margin.

### BIA Workshop Methodology: How to Derive RTO/RPO [\#](#bia-workshop-methodology-how-to-derive-rto-rpo "BIA Workshop Methodology: How to Derive RTO/RPO")

The correct sequence:

#### Step 1: Identify critical processes [\#](#step-1-identify-critical-processes "Step 1: Identify critical processes")

Invite: CFO, COO, department heads, IT lead.

Walk through each business department:

- Sales: ​“Without CRM, how long can we operate?”
- Operations: ​“Without production control, how long can we operate?”
- Finance: ​“Without the accounting system, how long can we operate?”

#### Step 2: Qualify the impact [\#](#step-2-qualify-the-impact "Step 2: Qualify the impact")

For each process: ​“What happens if this process is down for X hours?”

**Sales example:**

- 1 hour down: ​“Little impact; offline sales can be logged in CRM later.”
- 4 hours down: ​“Meaningful impact; we lose several important deals.”
- 8 hours down: ​“Critical impact; customers contact competitors.”

**Production example:**

- 30 minutes down: ​“No problem; the production buffer absorbs it.”
- 2 hours down: ​“We fall behind on individual orders.”
- 4 hours down: ​“Delivery delays, unhappy customers, penalty costs.”

#### Step 3: Set the RTO threshold [\#](#step-3-set-the-rto-threshold "Step 3: Set the RTO threshold")

The RTO threshold is **the point at which business impact becomes too large**.

Example:

- Sales CRM: ​“After 4 hours we lose significant deals. Therefore RTO = 4 hours.”
- Production: ​“After 2 hours we face delivery difficulties. Therefore RTO = 2 hours.”

This is not theoretical. It is a business fact.

#### Step 4: Set the RPO threshold [\#](#step-4-set-the-rpo-threshold "Step 4: Set the RPO threshold")

For each process: ​“How current does the data need to be?”

**Sales CRM example:** ​“Salespeople close new deals every day. Data loss of more than one hour is problematic. Therefore RPO = 1 hour.”

**Production database example:** ​“We capture production lots in real time. Data loss of more than 15 minutes means we do not know what was just produced. Therefore RPO = 15 minutes.”

**Email example:** ​“Email is important but not critical. Data loss of up to 24 hours is economically tolerable. Therefore RPO = 24 hours.”

#### Step 5: Document dependencies [\#](#step-5-document-dependencies "Step 5: Document dependencies")

Which other systems does this system need to function?

“ERP requires Active Directory.” ​“File server requires network access.” ​“Database requires backup storage.”

This determines the recovery sequence: AD must be restored before ERP.

### Typical RTO/RPO Values by System Category [\#](#typical-rto-rpo-values-by-system-category "Typical RTO/RPO Values by System Category")

These are guidelines, not rules:

- **Active Directory (critical):** RTO 1 to 2 hours, RPO 15 minutes
- **ERP (critical):** RTO 4 hours, RPO 1 hour
- **E‑commerce website (critical):** RTO 1 hour, RPO 15 minutes
- **Email (important):** RTO 8 to 24 hours, RPO 1 to 24 hours
- **CRM (important):** RTO 4 hours, RPO 1 hour
- **File server (important):** RTO 8 hours, RPO 1 hour
- **Database (critical):** RTO 2 to 4 hours, RPO 15 minutes to 1 hour
- **Development tools (low):** RTO 48 hours, RPO 1 day

The rationale: critical systems that production or customers depend on get aggressive RTO/RPO. Internal or non-customer-facing systems can be more relaxed.

### RTO Measurement: Estimated vs. Tested [\#](#rto-measurement-estimated-vs-tested "RTO Measurement: Estimated vs. Tested")

A common mistake: ​“Our RTO is 4 hours,” but this is an estimate, never tested.

**Estimated RTO:** ​“Our backup system can restore 100 GB in 2 hours. Our ERP is 500 GB. Therefore RTO is about 10 hours.”

**Tested RTO:** ​“We conducted a real recovery test. The backup was restored and validated in 2 hours. This is our actual recovery time.”

The difference can be enormous. Backups that have not been tested are often not recoverable, and in a ransomware incident the attacker has usually gone after the backup repositories first. An RTO of 4 hours is only valid if it has been tested from an isolated, intact backup copy. This is also the regulatory direction: DORA (Regulation (EU) 2022⁄2554) requires financial entities to test recovery, and GDPR Art. 32 demands the ability to restore data availability in a timely manner.

### Common Mistakes [\#](#common-mistakes "Common Mistakes")

**Mistake 1: Unrealistic RTO.** ​“Our ERP RTO is 30 minutes,” but the recovery process takes 2 hours. That is not an RTO; it is wishful thinking. The solution: align the RTO with actual recovery times, or invest in better infrastructure (faster secondary storage, failover).

**Mistake 2: Forgetting dependencies.** ​“Our ERP RTO is 4 hours,” but you did not account for the fact that AD must be recovered first, which takes an additional 2 hours. Recovery sequence matters.

**Mistake 3: RPO larger than makes sense relative to RTO.** ​“RTO 4 hours, RPO 1 week” rarely makes sense. If you restore the server after 4 hours but only have week-old data, the fast restore is worth little. Typically: RPO is less than or equal to RTO.

### Documentation [\#](#documentation "Documentation")

RTO/RPO should be documented and approved. A practical record per system contains:

- System: ERP (SAP)
- RTO: 4 hours
- RPO: 1 hour
- Rationale: Production and sales depend on it. After 4 hours of downtime, delivery delays occur. After 1 hour of data loss, the daily close is affected.
- Tested: yes (last test: 15 Feb 2026, actual recovery time: 2.5 hours)
- Approver: CIO, CFO
- Valid until: 15 Feb 2027 (annual review)

This document is your proof to auditors, and under NIS2 to the supervisory authority, that RTO/RPO were defined rationally and verified.

### Frequently Asked Questions [\#](#frequently-asked-questions "Frequently Asked Questions")

**Who defines RTO/RPO?** The business side (CFO, department heads) defines what they need. IT states whether that is technically feasible and at what cost.

**Can RTO/RPO change?** Yes. They should be reviewed annually. After significant business changes, immediately.

**What if the RTO is not technically achievable?** Then you need to invest (better infrastructure, typically faster disk-based secondary storage and an isolated backup tier) or adjust the RTO expectation.

---

### Further Resources [\#](#further-resources "Further Resources")

→ IT Resilience Guide (/en/blog/it-resilienz-leitfaden/) → Business Continuity Plan (/en/blog/business-continuity-plan-leitfaden/) → Disaster Recovery Test (/en/blog/disaster-recovery-test/)

### GDPR

The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing).

[Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr)

### DORA

DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting.

[Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora)

### Disaster Recovery

Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage.

[Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery)