Business Continuity Planning: What are RPO and RTO?

RPO and RTO are two of the most common terms in business continuity and disaster recovery planning. They’re also two of the most consequential. Between them, they define how much data an organisation is prepared to lose in an incident, and how much downtime it's prepared to have. Every other recovery decision, including architecture, replication, standby models, and budget, flows from these two numbers.

Recovery Point Objective (RPO) is defined as the maximum amount of data loss your organisation can tolerate, expressed as a point in time. An RPO of 15 minutes means your recovery architecture must ensure no more than 15 minutes of data can be lost.

Recovery Time Objective (RTO) is defined as the maximum acceptable period of downtime for a system or service. An RTO of 4 hours means recovery processes must restore that service within 4 hours of an incident being declared.

To put it simply, RPO looks backwards from the incident (how much recent data is gone?), while RTO looks forward (how long until we’re running again?). They’re related but independent - a system can have an aggressive RPO and a relaxed RTO, or the reverse.

Why do they matter so much? RPO and RTO read as technical metrics, and technology does set the bounds of what is possible, but the numbers are set by the business and define how much revenue, productivity, and customer trust the organisation is willing to put at risk. They determine what your disaster recovery services need to deliver and what they’ll cost.

Common RPO and RTO pitfalls

On paper, recovery objectives look simple as two numbers, agreed and documented. Yet, they're one of the most common points of failure in disaster recovery planning - not because the numbers are wrong, but because of how they're set, interpreted, and communicated across the business.

Each one of these pitfalls tends to stay invisible until an incident exposes it, and includes:

Unclear targets create false confidence 
If RPO and RTO have never been formally defined, everyone assumes a number, and these assumptions can differ. The differences in assumed expectations will often surface during an incident - which is exactly the wrong moment.

Executive teams misunderstand the targets 
“RTO of 4 hours” is often heard as “we’ll be fully back to normal in 4 hours” rather than “the defined service is restored within 4 hours of declaration.” Recovery objectives need to be communicated in business language, with their limits made explicit.

“Minimal downtime” is not a recovery objective 
Targets must be specific and measurable. “As fast as possible” can’t be architected for, tested against, or contractually committed to.

How to define RPO and RTO: a four-step approach

In our experience, setting targets that hold up under pressure comes down to four key decisions.

Step 1: Identify critical services

RPO and RTO are generally set per service, not per organisation. A blanket target across your whole estate either over-protects low-value systems or under-protects the ones that are essential.  

We recommend you start by identifying which services are genuinely critical to operations and mapping the dependencies underneath them. Our guide to creating an IT disaster recovery strategy covers this dependency mapping in detail. 

Step 2: Quantify downtime impact

• Revenue per hour: Includes directly lost sales or billable work while the service is down. 
• Regulatory exposure: reporting obligations, audit findings, or enforcement risk triggered by downtime. 

• SLA (Service Level Agreement) penalties: contractual commitments to your own customers that depend on the service.
• Operational disruption: staff who can’t work, processes that stall and the backlog that builds while systems are down.
• The output of this step is your RTO evidence base and the downtime tolerance of your organisation.

Step 3: Define acceptable data loss

Data loss tolerance varies enormously by system type, which is why RPO must be set individually. It’s important to consider:

• Transaction-based systems: lost transactions may be unrecoverable and carry direct financial consequences. These justify the tightest RPOs, often minutes or less.
• Financial systems: reconciliation and compliance requirements typically demand very low data loss, even where some downtime is tolerable. 
• SaaS (Software as a Service) platforms: data in platforms such as Microsoft 365 sits under a shared responsibility model the provider runs the platform, but achieving a customer-defined RPO for your data typically remains your responsibility. However, some providers will take responsibility for customer data, so you will need to understand and be comfortable with the RPO offered.  
• User-generated data: documents and files can sometimes be recreated from memory or other sources. A few hours of loss may be tolerable, but a few hours of transactions would not be. 

Step 4: Align to budget and architecture

This is where the decision becomes economic, as faster recovery typically costs more. Aggressive RTOs require standby infrastructure that’s always ready, and near-zero RPOs require continuous replication.

The right targets are the ones where the cost of achieving them is justified by the impact they avoid, which is why steps 2 and 3 come first. The organisation can set the targets from business impact, then choose the architecture that delivers them, not the other way round. 

RPO and RTO in cloud environments 

Cloud infrastructure has also changed how recovery objectives are achieved and introduced some new considerations. 

• Replication type drives RPO: synchronous replication can deliver near-zero data loss but requires low-latency connectivity. Asynchronous replication is more flexible but introduces a small loss window. 

• Region failover affects RTO: in traditional recovery, replacing damaged hardware means sourcing, shipping, and setup. Recovering to the cloud removes hardware procurement delays, but failover time still depends on how much is pre-provisioned, and a cold environment in the cloud is still a cold environment. Our Disaster Recovery guide also explores the different types of disaster recovery environments and how they can impact your strategy. 

• SaaS platforms may not guarantee your RPO: platform providers commit to availability, not to your point-in-time recovery targets. Native retention features are not designed around a customer-defined RPO. 

• The shared responsibility model: under the shared responsibility model, the provider is responsible for the platform; your data, workloads, and recovery capability remain your responsibility. Assuming otherwise is one of the most common gaps we encounter.

The cost curve of recovery objectives

Recovery objectives typically sit on a cost curve, and the following is often seen:

• An aggressive RTO (minutes) typically requires a hot standby or active-active architecture, with infrastructure consistently running in parallel. 
• A near-zero RPO requires synchronous or near-synchronous replication, with the connectivity and infrastructure to support it.
• Each step down in tolerated downtime or data loss increases infrastructure overhead - the difference between a 4-hour RTO and a 15-minute RTO is usually an architectural change, not a tuning exercise. 

This is why the commercial trade-off belongs to the business, not to IT alone. The question is never “what’s the fastest recovery available?” but “what level of protection does the impact justify?” For most organisations, the answer is a tiered model, which means aggressive targets for the systems that genuinely need them, proportionate targets everywhere else. 

Real-world examples of RPO and RTO

As mentioned above, if planned and designed correctly, the same organisation will hold very different RPO and RTO targets for different systems within the organisation. Here are some real-world examples to help you place your organisational priorities. 

Treating these three systems identically would either waste budget on the HR system or dangerously under-protect the e-commerce platform. Tiered targets keep protection proportionate to impact.

Setting targets you can meet

A defined RPO and RTO is a starting point; a validated one is a capability. Targets should be tested against reality through structured recovery testing and revisited as your environment changes. Our guide to how often you should test your disaster recovery strategy covers how to keep validation aligned to risk.

At DCS, defining RPO and RTO per workload is core to our disaster recovery engagements. As a UK-based, engineer-led cloud and cyber resilience provider, we help organisations quantify downtime impact, set proportionate recovery targets, and design and test the architecture against them.

For a recommendation on RPO and RTO for your business, call +44 3453 888 327 or email enquiries@virtualdcs.co.uk,.