When disaster strikes - a ransomware attack, a server failure, a fire, a flood - two numbers determine whether your business gets back on its feet quickly or spends days in chaos. Those numbers are your RTO and your RPO. Most businesses have heard the terms. Far fewer have actually set them with any rigour.
This guide explains what RTO and RPO really mean, why the difference matters, how to set targets that reflect your actual business needs, and what your disaster recovery infrastructure needs to look like to meet them.
In short: RTO (Recovery Time Objective) defines how quickly you need to be back online after an incident. RPO (Recovery Point Objective) defines how much data you can afford to lose. Together, they are the foundation of any credible disaster recovery plan and getting them right is what separates businesses that recover quickly from those that don't.
What is RTO?
RTO stands for Recovery Time Objective. It is the maximum amount of time your business can tolerate being without a particular system or service before the impact becomes unacceptable.
Think of it as a deadline for recovery. If your RTO for your core business systems is four hours, that means your disaster recovery plan must be capable of restoring those systems within four hours of an incident every time, reliably.
RTO is expressed in time: minutes, hours, or days. The shorter the RTO, the more investment is typically required in your recovery infrastructure, because faster recovery demands more sophisticated tooling, pre-staged environments, and tested processes.
Different systems within the same organisation will have different RTOs. Your customer-facing e-commerce platform may have an RTO of 30 minutes. Your internal HR system might tolerate 48 hours. Defining RTO at the system level - not just as a blanket business target is where disaster recovery planning becomes more nuanced.
What is RPO?
RPO stands for Recovery Point Objective. It defines the maximum amount of data your business can afford to lose, measured in time.
If your RPO is one hour, your backup or replication strategy must ensure that no more than one hour of data is ever at risk. In practice, this means backups need to run at least every hour - because if a failure occurs just before the next backup, you'll lose everything since the last one.
RPO drives your backup frequency and your data replication strategy. A tight RPO - say, 15 minutes or less typically requires continuous data replication rather than scheduled backups. A more relaxed RPO of 24 hours can be met with daily backups, as long as the business can genuinely absorb that data loss.
Like RTO, RPO should be set at the system level. Data from a live transaction processing system has very different loss tolerance than data from an internal file share.
RTO vs RPO - what's the difference?
The simplest way to remember the distinction:
- RTO is about time: How long can you be down?
- RPO is about data: How much can you afford to lose?
They address different aspects of a disaster recovery scenario - and they drive different decisions.
- RTO informs your recovery infrastructure: do you need physical kit on standby, a warm virtual environment, or cloud-based failover?
- RPO informs your data protection strategy: how frequently do you back up, whether you replicate continuously, and where that data lives.
The two interact, but they are not the same thing. A business could have a tight RTO (systems back online in one hour) but a relatively relaxed RPO (willing to lose up to 24 hours of data), or vice versa.
Understanding both and setting them independently for each critical system - gives you a much clearer picture of what your disaster recovery solution needs to deliver.
How to set your RTO and RPO targets
The starting point is a business impact analysis (BIA). This is the formal process of identifying your critical systems and services, and quantifying the impact of losing each one over time.
For each system, ask:
- What does one hour of downtime cost us in lost revenue, staff productivity, customer impact, or regulatory exposure?
- At what point does downtime become genuinely critical - a reputational risk, contractual breach, or regulatory issue?
- How much data could we recreate manually, and at what cost?
- Are there contractual or compliance obligations that define a minimum recovery standard?
The answers give you the business case for your recovery targets and help you prioritise investment where it matters most.
A common mistake is setting RTO and RPO based on what sounds reasonable rather than what the business actually needs - or what the recovery infrastructure can realistically deliver. Both errors are expensive. Targets that are too tight cost more than necessary. Targets that are too relaxed leave you exposed.
Why backups alone aren't enough and what cyber incident recovery involves
A backup strategy will help you meet your RPO. It will not, on its own, help you meet your RTO and in the era of ransomware, it may not fully protect your data.
Modern ransomware is sophisticated. Attackers often infiltrate systems and remain dormant for weeks or months, embedding themselves deeply before triggering encryption. By the time the attack becomes visible, recent backups may already be compromised. Restoring from them risks reintroducing the threat.
This is where cyber incident recovery becomes essential. Our approach combines isolated recovery environments (IREs) with forensic analysis to ensure recovery is safe, not just fast.
Key questions that must be answered before recovery:
- How did the attackers get in?
- How long were they present before triggering the attack?
- What systems and data were accessed?
- Has anything been exfiltrated?
- Are they likely to return?
- Do vulnerabilities need fixing before recovery begins?
- Can we reconstruct a cleaner restore point from multiple snapshots?
In many ransomware scenarios, careful forensic work allows organisations to reconstruct a cleaner recovery state and reduce effective data loss beyond what standard backups would allow.
A real-world illustration: a large UK retailer affected by ransomware in 2025 achieved rapid containment, but full recovery took months. The challenge was not restoring systems, but validating which data could be trusted. Systems were ready long before the data was safe to reconnect.
Introducing MTCR: Mean Time to Clean Recovery
Traditional disaster recovery focuses on speed. But in cyber incidents, speed without confidence is risky.
MTCR shifts the focus from “how fast can we restore?” to “how confidently can we recover?”
It is built on four foundations:
- Clean data verification: Data is scanned and validated before use
- Isolated recovery environments: Recovery happens in secure, air-gapped environments
- Validation pipelines: Systems are tested before being reconnected
- Operational discipline: Teams follow rehearsed processes under pressure
MTCR reflects the full recovery journey - not just the technical restore time.
What is your Minimum Viable Company?
Your Minimum Viable Company (MVC) is the minimum set of systems required to keep the business operating during recovery.
Most organisations already have a version of this in their plans but have not clearly defined it. During a cyber incident, you are unlikely to recover everything at once.
Knowing what needs to come back first, in what order, and to what minimum standard allows you to maintain operations while full recovery continues.
The one thing most businesses forget: testing
Defining RTO, RPO, and MTCR targets is only half the job. The other half is proving your recovery strategy can actually meet them.
An untested recovery plan is an unreliable one.
Regular rehearsals:
- Validate that targets are achievable
- Identify gaps and dependencies
- Ensure teams can execute under pressure
Automated testing takes this further by allowing organisations to simulate full recovery scenarios regularly. This builds confidence, improves processes over time, and creates genuine operational readiness.
We offer automated testing across both disaster recovery and cyber incident recovery scenarios, enabling organisations to exercise their full recovery chain as often as needed.
What recovery options does your RTO actually require?
Once RTOs are defined, the next step is designing infrastructure that can meet them.
We offer a range of disaster recovery options:
Virtual recovery
Recovery into cloud or virtual environments, enabling fast and flexible restoration.
Ship-to-site (kit to site)
Pre-configured physical infrastructure delivered when required.
Mobile recovery
40ft mobile data centre units with power, storage, and compute, deployed directly to site.
A hybrid approach is often the most effective, combining different recovery methods for different system tiers.
Key takeaways
- RTO defines acceptable downtime
- RPO defines acceptable data loss
- Both should be set at the system level
- Backups alone are not enough for cyber recovery
- MTCR reflects real recovery readiness
- MVC defines operational continuity during recovery
- Testing is essential to validate your strategy
.png?width=440&height=295&name=Blog%20image%20(2).png)
