Defining RTO and RPO Correctly: A Practical Guide

Definitions #

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) #

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 #

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 #

The correct sequence:

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 #

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 #

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 #

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 #

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 #

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 #

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) ²⁰²²⁄₂₅₅₄) requires financial entities to test recovery, and GDPR Art. 32 demands the ability to restore data availability in a timely manner.

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 #

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 #

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 #

→ 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/)