RTO
RTO (Recovery Time Objective) is the maximum acceptable time for restoring a system after a disruption, measured from incident onset to full service availability. Key parameter of Business Continuity Planning and Disaster Recovery.
What is RTO?
RTO (Recovery Time Objective) is the maximum acceptable time for restoring a system or business process after a disruption. Measured from incident onset to full service availability — it is one of two key Business Continuity Planning parameters (alongside RPO).
RTO in 30 seconds
- What it measures: time from failure to working service
- How it’s expressed: hours or minutes (e.g., RTO = 4h)
- Who sets it: BIA + business decision + cost tradeoff
- Why it matters: drives DR architecture and acceptable loss ceiling
RTO vs RPO vs MTTR — distinction
| Parameter | What it measures | Example |
|---|---|---|
| RTO | Max downtime (recovery time) | System online max 4h after failure |
| RPO | Max data loss | Max 15min of transactions lost |
| MTTR | Mean time to repair (historical) | Average repair takes 2.5h |
| MTTF | Mean time to failure | System runs 10k hours failure-free |
| MTTD | Mean time to detect | Attack detected in 15min |
RTO ≠ MTTR: RTO is a target (business promise), MTTR is historical measurement. Organizations should drive MTTR < RTO.
How to set RTO — Business Impact Analysis
Step 1: Business process inventory and supporting systems Step 2: Hourly downtime loss estimate (revenue lost, SLA penalties, reputation) Step 3: Criticality tiering (Tier 0 = core, Tier 1 = important, Tier 2 = supporting) Step 4: Propose per-tier RTO (e.g., Tier 0 = 1h, Tier 1 = 4h, Tier 2 = 24h) Step 5: Cost analysis (active-active, warm standby, cold backup) Step 6: Business negotiation + document in BCP/DRP
Typical RTO by industry
| Industry / system | Typical RTO |
|---|---|
| Fintech transaction systems | 15-30 min |
| Card payment systems | <30 min |
| Core ERP (manufacturing) | 2-4h |
| CRM / sales | 4-8h |
| HR/payroll systems | 24h |
| Archival / reporting | 72h+ |
RTO and regulatory requirements
- NIS2 (Art. 21): proportionate continuity measures — RTO 4-24h for essential and important entities
- DORA (financial, Art. 11): documented and tested RTO/RPO for critical functions
- ISO 22301 (BCM): formal BIA-based RTO determination methodology
- PCI DSS (payments): continuity plan with RTO/RPO for cardholder data systems
DR architecture vs RTO — cost tradeoff
- Cold standby (tape/S3 backup) → RTO 24-72h, cost <10% of production
- Warm standby (DR site, replicated data, stand-by apps) → RTO 2-8h, cost 30-50%
- Hot standby (active-passive, continuous replication, manual failover) → RTO 30min-2h, cost 60-80%
- Active-active (multi-site, automatic failover, load balanced) → RTO <15min, cost 100-150%
Explore our services
Frequently asked questions
+ What is RTO?
RTO (Recovery Time Objective) is the maximum acceptable time for restoring a system or business process after an incident — from occurrence to full availability. If RTO = 4h and outage lasts 6h, the organization incurs losses beyond acceptable. RTO is a key parameter of Business Continuity Planning.
+ How does RTO differ from RPO?
RTO (Recovery Time Objective) defines the TIME to restore — how long downtime may last. RPO (Recovery Point Objective) defines the AMOUNT OF DATA that can be lost — how many hours/minutes of pre-incident data must be recoverable. Example: RTO = 4h, RPO = 15min means systems restored in 4h with max 15 minutes of transaction loss. RPO drives backup frequency, RTO drives DR architecture.
+ How to determine RTO for a system?
RTO is set through Business Impact Analysis (BIA): (1) identify critical processes, (2) estimate hourly downtime costs, (3) analyze recovery architecture costs (HA, active-active, warm/cold standby), (4) negotiate cost-vs-loss tradeoff with business owners. Typical RTO: critical systems 15min-1h, important 4-8h, others 24h+.
+ What RTO does NIS2 and DORA require?
NIS2 does not define hard RTO thresholds but Art. 21 requires proportionate business continuity measures — in practice EU Commission recommends 4h RTO for core systems. DORA (financial) is stricter: Art. 11 requires documented recovery policy with RTO/RPO for every critical function, tested annually. Core banking systems typically 2-4h RTO, card payments <30min.
+ How much does achieving low RTO cost?
Cost grows geometrically as RTO decreases. RTO 24h = standard backup + secondary infrastructure = 10-30% of production cost. RTO 4h = warm standby + DR site = 30-60%. RTO <1h = active-active multi-site replication = 80-150% of production cost. Decision should follow BIA — if hourly downtime costs €100k, 4h RTO saves €400k per incident and justifies investment.