Defining RPO and RTO Correctly: How to Find the Right Values

TL;DR

RPO (Recovery Point Objective) defines the maximum data loss in time units. An RPO of 4 hours means: you accept the loss of up to 4 hours of data.
RTO (Recovery Time Objective) defines the maximum downtime. An RTO of 8 hours means: the system must be available again within 8 hours of the outage.
RPO and RTO are not determined by IT alone but jointly with the business departments based on a Business Impact Analysis.
Shorter RPO and RTO values cost exponentially more. An RTO of 1 hour requires a fundamentally different infrastructure than an RTO of 24 hours.
The defined values must be regularly verified through restore tests. An RTO on paper that is unachievable in practice only creates a false sense of security.

Two metrics that determine everything

When you deal with backup, disaster recovery, or business continuity, you encounter two abbreviations over and over: RPO and RTO. These two metrics are the foundation of your entire data backup and recovery strategy. They determine how often you must back up, which backup method you need, and how much money you should invest in your DR infrastructure.

The problem: in many organizations, RPO and RTO are either not defined at all, applied uniformly to all systems ("everything is critical, everything immediately"), or determined by the IT department alone without involving the business units. All three approaches lead to a backup strategy that either provides too little protection or is needlessly expensive.

RPO: how much data loss can you tolerate?

RPO stands for Recovery Point Objective and answers the question: how many minutes, hours, or days of data may be lost at most when a system fails?

The RPO is measured backward from the point of failure. If your ERP system fails at 2:00 PM and the RPO is 4 hours, the last usable backup must be from no earlier than 10:00 AM. All data entered between 10:00 AM and 2:00 PM may be lost.

RPO determines your backup interval

The RPO has direct implications for your backup interval. If the RPO is 24 hours, a daily backup suffices. If the RPO is 4 hours, you need a backup at least every 4 hours or a continuous replication mechanism. If the RPO is 15 minutes, you need transaction log backups, continuous data replication, or snapshots at minute-level intervals. And if the RPO is zero (no data loss tolerable), you need synchronous replication to a second system, which brings considerable cost and complexity.

RPO does not equal backup interval

A common misconception: "We back up every 4 hours, so our RPO is 4 hours." This is only true if the backup is actually consistent and restorable. If your 4-hour backup is corrupted and you must fall back to the previous one (8 hours old), your actual RPO is 8 hours, not 4.

That is why RPO always includes the question: how many backup generations do I retain, and how do I ensure that at least one of them works? Regular restore tests are the answer.

Different RPOs for different data

Not all data in a system has the same value. The transaction data in your ERP system (orders, invoices, postings) changes constantly and has high value. The master data (item data, customer records) changes less frequently. The system configuration changes almost never.

In practice, RPO is still defined per system rather than per data type, because selective backup/restore at the data level is impractical in most systems. But it helps with estimation: if transaction data changes every few minutes but master data only weekly, an RPO of 4 hours is an acceptable compromise.

RTO: how long may the system be down?

RTO stands for Recovery Time Objective and answers the question: how much time may pass between the failure of a system and its full restoration?

The RTO is measured forward from the point of failure. If the ERP system fails at 2:00 PM and the RTO is 8 hours, it must be fully operational again by 10:00 PM at the latest.

What is included in the RTO calculation?

The RTO encompasses not just the raw restore time but the entire recovery process. This includes detecting the outage (how long until someone notices the system is down?), diagnosis (what is the cause, and which recovery strategy is appropriate?), provisioning the infrastructure (if hardware is damaged: procuring and setting up replacement hardware), the actual restore (recovering data from backup), verification (does the system work correctly after the restore?), and user release (system is released to users, VPN tunnels may need reconfiguration, DNS records adjusted).

Many organizations define their RTO based only on the raw restore time and forget the other phases. In practice, detection, diagnosis, and verification often take longer than the actual restore.

RTO determines your DR strategy

The RTO has direct implications for the architecture of your recovery solution.

RTO over 24 hours: Standard backup restore is sufficient. No special DR infrastructure needed. Cost: low.

RTO 4 to 24 hours: Fast restore capability required. Local backups (not just cloud), possibly pre-provisioned replacement VMs. Cost: moderate.

RTO 1 to 4 hours: Standby systems or cloud DR (Azure Site Recovery, Zerto) required. Automated failover or at least orchestrated restore. Cost: significant.

RTO under 1 hour: Active-active setup with automatic failover or high-availability cluster. Cost: high to very high.

RTO near zero: Full redundancy with synchronous replication. Typical only for business-critical systems in large enterprises or regulated industries. Cost: very high.

Costs increase not linearly but exponentially as the RTO gets shorter. The jump from 24 hours to 4 hours is typically achievable with moderate investment. The jump from 4 hours to 1 hour typically doubles or triples the cost.

How to determine RPO and RTO correctly

RPO and RTO are not defined by the IT department behind closed doors. They result from a Business Impact Analysis and the requirements of business processes -- and the business units know those better than IT.

Step 1: Identify business processes

List the most important business processes of your organization. For a manufacturing company, these might be: order intake and processing, production and manufacturing control, procurement and inventory management, accounting and controlling, human resources and time tracking, customer service and support.

Step 2: Map IT systems

For each business process, identify the IT systems that support it. Order processing depends on the ERP system and the email system. Production depends on the ERP and possibly an MES (Manufacturing Execution System). Accounting depends on the ERP and the DATEV system.

Step 3: Assess outage impact

For each business process, assess the impact of an outage over time. What happens if order processing is down for 1 hour? 4 hours? 1 day? 3 days? 1 week?

The impacts can be financial (revenue loss, contractual penalties, overtime costs), operational (production standstill, delivery delays), regulatory (violations of reporting obligations, GDPR issues), or reputational (customer loss, trust damage).

The business departments are the right contacts for this assessment. The sales director knows how many orders come in per hour and what a day of downtime means for the customer relationship. The production manager knows which production lines stop during an IT outage and what costs that incurs. The finance department knows which payment deadlines and regulatory dates are affected.

Step 4: Determine tolerance thresholds

From the impacts, you derive the tolerance thresholds. The point at which impacts become unacceptable defines your RTO. The data loss that is just barely tolerable defines your RPO.

Example: the sales director says that a failure of order processing is tolerable for up to 4 hours because customers can be put off by phone. After 4 hours, customers begin migrating to competitors. The RTO for the ERP system (insofar as it concerns order processing) is therefore 4 hours.

The sales director further states that losing more than 2 hours of order data is problematic because manual re-entry is error-prone and time-consuming. The RPO for the ERP system is therefore 2 hours.

Step 5: Reality check with IT

The values desired by the business departments must be reconciled with technical reality and the budget. IT checks whether the desired values are achievable with the existing or realistically procurable infrastructure.

If the business unit wants an RTO of 2 hours but experience shows the ERP system restore takes 6 hours, there are three options: invest in faster recovery technology (e.g., hot standby), adjust the RTO to a realistic value (and inform executive management about the residual risk), or adapt the business process to better bridge a longer IT outage (manual fallback processes).

Step 6: Documentation and approval

The final RPO and RTO values are documented and approved by executive management. This is not bureaucratic formality but necessary because management must consciously accept the residual risk. An RPO of 4 hours means: we consciously accept that up to 4 hours of data may be lost. Executive management must endorse this decision.

Typical RPO and RTO values for SMEs

To give you some orientation, here are typical values for various system categories in mid-market companies. These are reference values, not prescriptions. Your actual values depend on your specific business model.

Business-critical systems (ERP, database, Active Directory)

Typical RTO: 2 to 8 hours. Typical RPO: 1 to 4 hours. Backup strategy: local backups every 2 to 4 hours, possibly transaction log backups every 15 minutes for databases. Standby system or cloud DR for RTOs under 4 hours.

Important systems (file server, email, CRM)

Typical RTO: 8 to 24 hours. Typical RPO: 4 to 12 hours. Backup strategy: daily backups with local and cloud copy. Restore from local backup possible.

Standard systems (intranet, time tracking, print server)

Typical RTO: 24 to 72 hours. Typical RPO: 24 hours. Backup strategy: daily backup, restore as needed. No special DR infrastructure.

Non-critical systems (test environments, archive)

Typical RTO: 72 hours to 1 week. Typical RPO: 24 hours to 1 week. Backup strategy: weekly backup or reinstallation as needed.

RPO/RTO in practice: two examples

Example 1: Retail company with an online shop

A retail company with 80 employees operates an online shop that generates 60% of revenue. The shop runs on an e-commerce platform with an integrated warehouse management system.

The online shop has an RPO of 15 minutes (transaction log backup of the database every 15 minutes, because every lost order means revenue loss and customer frustration) and an RTO of 2 hours (an outage of more than 2 hours during business hours costs thousands of euros and harms Google ranking).

The warehouse management system has an RPO of 1 hour and an RTO of 4 hours (orders can be manually buffered in the interim).

The DR strategy for the shop looks like this: the database is synchronously replicated to a standby system. On failure of the primary system, automatic failover occurs. Transaction log backups every 15 minutes provide additional safety. This is more expensive than a simple daily backup, but executive management decided that the cost of a shop outage far exceeds the DR costs.

Example 2: Engineering firm

An engineering firm with 25 employees works primarily with CAD software and a project management tool. CAD files are large (several GB per project) but only change during active editing phases.

The CAD data on the file server has an RPO of 4 hours (a lost workday would be annoying, but 4 hours of work can be redone) and an RTO of 24 hours (engineers can bridge one day with planning activities, client meetings, or documentation in an emergency).

The project management tool has an RPO of 24 hours and an RTO of 48 hours (data changes infrequently, and employees can briefly work without it).

The DR strategy: daily backup of the file server to a local NAS and to the cloud. Weekly full backup, daily incremental backup. No standby system needed. The cost of this strategy is a few hundred euros per month.

The cost trap: overly ambitious values

The most common mistake in RPO/RTO definition is the desire to set the shortest possible values for everything. "Better safe than sorry" sounds reasonable but leads to a massively over-dimensioned and expensive infrastructure.

A concrete calculation example: a company with 15 virtual machines wants an RTO of 2 hours and an RPO of 30 minutes for all systems. This requires a standby system or cloud DR replication for every system, transaction log backups or snapshots every 30 minutes for all databases, orchestration software for automated failover, and substantial storage for the frequent backups.

The estimated cost is 3,000 to 5,000 euros per month, plus one-time setup costs.

If the company realistically assesses which systems actually need a 2-hour RTO (probably 2 to 3) and accepts 24 hours for the rest, costs drop to 800 to 1,500 euros per month. The savings are substantial, and the actual risk barely increases because the non-critical systems only affect a few users anyway.

Reviewing and adjusting RPO/RTO

RPO and RTO are not static values. They must be regularly reviewed and adjusted as needed -- specifically when the IT landscape changes (new ERP system, cloud migration, new business applications), when the business model changes (new online shop, new production line, expansion), after restore tests (if actual recovery time exceeds the RTO), after real incidents (if the RPO turns out to have been too generous or too tight), when regulatory requirements change (new NIS2 implementing regulation, new industry standards), and at least annually as part of the management review.

Measurement and evidence

For audits and certifications, it is not enough to define RPO and RTO on paper. You must demonstrate that you can actually meet the values. Evidence comes from regular restore tests in which you measure the actual recovery time (RTA, Recovery Time Actual) and determine the actual data loss (RPA, Recovery Point Actual).

If the defined RTO is 4 hours and your last restore test yielded an RTA of 5.5 hours, you have a problem that needs to be solved. Either you improve the recovery process (faster hardware, optimized runbooks, parallel restores) or you adjust the RTO and communicate the residual risk to executive management.

Document every restore test with date, tested system, planned RTO/RPO, measured RTA/RPA, and deviations with root cause analysis. This documentation is your strongest argument in an audit.

RPO and RTO in ISMS documentation

RPO and RTO are part of several ISMS documents. In the Business Impact Analysis (BIA), the values are initially determined and justified. In the Disaster Recovery Plan, they serve as target values for recovery strategies. In the backup policy, backup intervals are derived from the RPOs. In the restore test reports, the actually achieved values are documented. In the management review, deviations between targets and actuals are reported and corrective actions decided.

When you define, document, and regularly verify RPO and RTO properly, you not only have a functioning backup and DR strategy but also have covered a substantial part of your NIS2 and ISO 27001 requirements. In ISMS Lite, RPO and RTO values can be documented per system, linked to backup strategies, and evidenced through test results.

RPO RTO Backup Disaster Recovery BCM Business Impact Analyse ISMS