RTO (Recovery Time Objective) measures how quickly you need to recover after an outage. RPO (Recovery Point Objective) measures how much data you can afford to lose. Every disaster recovery strategy needs both.

This article explains how RTO and RPO differ, how ransomware changes the picture, and how to set targets your business can actually meet.

Who sets RTO and RPO?

The business sets RTO and RPO, and IT delivers them. Each part of the organisation has a role:

    • Finance decides how much downtime and data loss the business can afford

    • Operations decides how much disruption customers and staff can tolerate

    • IT designs the recovery architecture to meet those targets

    • Managed services keep that architecture monitored, tested, and achievable over time

Technology should support the recovery objectives your business needs, not dictate them. The Missing Link’s Assess → Improve → Manage approach works this way, from SmartPROTECT backup and Disaster Recovery as a Service to Managed IT Services.

What is RTO (Recovery Time Objective)?

RTO is the target time to restore a system after an outage. If your finance platform has an RTO of four hours, it must be running again within four hours of going down. Anything longer starts to cause unacceptable financial, operational, or reputational damage.

There’s no universal “good” RTO. The right target depends on what the system does and what downtime costs you. An online retailer may need its checkout restored in under an hour, because every minute offline is lost revenue. A professional services firm might tolerate a day without its document archive, because staff can keep working around it.

The shorter the RTO, the more investment it needs. Near-instant recovery requires replicated infrastructure that’s ready to take over. A 24-hour RTO might only need reliable backups and a tested restore process. To weigh those trade-offs, start by understanding what IT downtime actually costs your business.

What is RPO (Recovery Point Objective)?

RPO is the maximum age of the data you can recover to, which tells you how much recent data you can afford to lose. If a system has an RPO of 15 minutes, you need a copy of its data no more than 15 minutes old at any point. When disaster strikes, anything created after that copy is gone.

RPO sets how often you back up or replicate. A one-hour RPO means protecting data at least hourly. A near-zero RPO means continuous replication.

To set it, ask: if this system failed right now, how much work could your team realistically re-enter or recreate? For a transaction system, the answer may be almost none. For a shared drive of reference material, it may be a full day.

RTO vs RPO: What’s the difference?

RTO looks forward from the moment of failure: how long until you’re back up. RPO looks back: how much data from before the failure you lose. A third measure, maximum tolerable downtime (MTD), is the longest a business process can be down before the damage becomes serious. Both RTO and RPO need to fit within it. 

 

RTO

RPO

MTD

Measures Downtime Data loss Total outage the business can survive
Direction Forward from the failure Back from the failure Forward from the failure
Answers How fast must we recover? How much data can we lose? When does the outage become critical?
Drives Recovery infrastructure and failover design Backup and replication frequency The ceiling for RTO and the business continuity plan
Example Restore ERP within 2 hours Lose no more than 15 minutes of transactions ERP outage beyond 8 hours stops fulfilment

Your RTO should be well below your MTD, because recovery doesn’t end when systems come back online. Teams still need to validate data, re-enter lost work, and resume normal operations. 

The period between the last clean backup and the failure is data you may lose. The period after the failure is downtime you need to recover from.

How does ransomware affect RPO?

Ransomware makes RPO harder to meet. If attackers have reached your backups, you can only recover to your most recent clean backup.

Attackers often sit inside a network for days or weeks before they encrypt anything. In that time, they may corrupt, encrypt, or delete backups, or plant malware that ends up inside them. A business with hourly backups and a one-hour RPO can still lose weeks of data if every recent copy is compromised.

To protect your recovery point against ransomware:

    • Use immutable backups that can’t be changed or deleted during their retention period, even by an admin account

    • Keep at least one copy isolated from your production network and credentials

    • Retain enough history to reach back past a long dwell time

    • Scan and validate restores so you don’t reintroduce the threat

    • Rehearse a ransomware recovery as well as a hardware failure

Recovering cleanly from ransomware depends on three things: secure backups, rapid threat detection and response, and a rehearsed recovery process.

How do you set RTO and RPO for each workload?

One recovery target for the whole business is a common mistake. It either overspends on systems that can wait or underprotects the ones that can’t. Set objectives per workload instead.

    • Map your critical business processes. Start with what the business does, such as taking orders, paying staff, or serving patients, rather than with servers.

    • Identify the systems and dependencies behind each process. An ERP may depend on identity services, a database, network links, and a third-party integration. Its RTO is only as good as the slowest of those.

    • Estimate the cost of downtime and data loss over time. Look at lost revenue, idle staff, contractual penalties, regulatory exposure and reputational damage.

    • Group workloads into tiers and assign targets to each tier.

    • Match the recovery approach to the tier. Then test it to confirm the targets hold.

The tiers below are examples only. Your own targets should come from your business impact analysis.

Tier Example workloads Illustrative RTO Illustrative RPO
Tier 1: Mission critical ERP, customer-facing platforms, payment systems Under 1 hour Minutes
Tier 2: Business critical Email and Microsoft 365, CRM, finance systems 4–8 hours 1–4 hours
Tier 3: Important File shares, intranet, internal reporting 24 hours 24 hours
Tier 4: Deferrable Archives, test and development environments Several days Several days

Working out which tier a system belongs in usually reveals dependencies nobody had documented. That makes an infrastructure and recovery assessment the best place to start.

Is backup the same as disaster recovery?

No. Backup protects your data, but it doesn’t give you anywhere to run your systems. It’s one of the most common assumptions we hear: “we’re covered, we have backups.” If your servers, storage, or data centre are unavailable, a perfect backup can still leave you offline for days while you source hardware, rebuild environments, and restore terabytes of data.

  • Backup mainly serves your RPO. It makes sure a recent copy of your data exists.
  • Disaster recovery serves your RTO. It replicates your whole environment, including servers, applications, configuration, and data, so it can be brought online somewhere else quickly.

Most organisations need both, tuned to each workload tier.

That’s why we built SmartPROTECT, our ISO 27001-certified Backup-as-a-Service platform. We own and operate it, and it runs on enterprise-grade data protection software and flash storage for fast restores. It includes:

    • Local, offsite, and immutable copies: all managed by The Missing Link, so a ransomware attack can’t wipe out your recovery point

    • Hybrid cloud coverage: protects data across on-premises and cloud environments

    • Long-term retention: older backups can be moved to low-cost cloud storage for compliance and archiving

    • Restore and failover testing: so you know your recovery process works before you need it

    • Managed or self-managed: choose the level of service that suits your team

For workloads that need rapid failover, our Disaster Recovery as a Service replicates your physical servers and virtual machines to Microsoft Azure. If your primary environment goes down, those systems can be started in Azure instead of rebuilt from scratch. The service includes annual failover testing with reporting, plus regular health monitoring.

Why do businesses miss their RTO?

When a business misses its RTO, the cause usually started months before the incident. The most common causes are operational:

    • Backups fail silently. A job stops running or a storage target fills up, and nobody notices until a restore is needed.

    • Systems go unpatched. Known vulnerabilities give attackers an easy way in. The longer they go undetected, the further back your last clean recovery point sits.

    • The environment changes, but the plan doesn’t. New applications, cloud migrations, and integrations get added, and the recovery plan still describes the old setup.

    • Failover is never tested. Untested plans often fail during a real incident because of missing credentials, out-of-date runbooks, or a restore order nobody worked out.

    • Nobody owns the incident. When something breaks at 2 am, it’s unclear who declares a disaster, who starts the recovery, and who talks to the business.

Managed IT Services address each of these before a disaster happens. We monitor backup health, patch and maintain critical infrastructure, update recovery plans as your environment changes, test failover, and run the response when something goes wrong.

Case study: DGT Costs Lawyers. DGT came to us with outdated infrastructure and a critical server close to failure. Left as it was, that server could have caused an unplanned outage. Through managed end-user and infrastructure support, we modernised their environment and introduced regular patching and security awareness training aligned to the ASD Essential Eight. Read the DGT Costs Lawyers case study.

“Their innovative solutions, from Microsoft Intune deployment to SharePoint Online migration, have not only modernised our infrastructure but significantly enhanced our security and operational efficiency.”
Tristan Kontonis, Office Manager, DGT Costs Lawyers

Managed IT doesn’t have to mean outsourcing everything. Many organisations keep their internal IT team for day-to-day work and bring in a partner for monitoring, after-hours cover and recovery. If you’re weighing up that model, see our guide to outsourced vs co-managed IT support.

Do Australian regulations require RTO and RPO?

For some organisations, yes. Australian regulators increasingly expect recovery objectives to be defined, documented and tested, and three frameworks address them directly:

  • APRA CPS 230 Operational Risk Management: In force since 1 July 2025 for APRA-regulated entities, with smaller, less complex entities given an extra 12 months for some requirements. For each critical operation, entities must set tolerance levels for the maximum period of disruption, the maximum extent of data loss, and minimum service levels during a disruption. The first two work like RTO and RPO. Business continuity plans must be tested against these levels, including an annual business continuity exercise.

  •  ASD Essential Eight: Regular backups are one of the eight mitigation strategies. Every maturity level requires disaster recovery exercises that test restoring data, applications, and settings, and stop unprivileged accounts from modifying or deleting backups. Higher maturity levels extend that protection to privileged and backup administrator accounts. ASD has proposed evolving the Essential Eight into a broader Essentials series over the next two years, but the current framework remains in force. 

  • SOCI Act: Responsible entities for certain critical infrastructure assets must adopt, maintain, and comply with a written risk management program that addresses hazards to the availability of their assets. Recovery capability is part of meeting that obligation.

Even if none of these apply to you directly, your customers, insurers, and board may expect similar evidence. Documented, tested recovery objectives are increasingly part of cyber insurance questionnaires and supplier due diligence.

How does The Missing Link help businesses meet their RTO and RPO?

We start by understanding what your business can and can’t afford to lose before recommending any technology. Then we design a recovery setup to meet those objectives and test that it does. Our approach has three stages:

1. Assess. We work with your stakeholders to identify critical processes and their dependencies. Then we compare your current recovery capability with the RTO and RPO each workload needs, and identify the gaps.

2. Improve. Our architects design and implement the right mix of backup, replication, and failover for each tier. That may include SmartPROTECT, DRaaS, or improvements to the underlying infrastructure.

3. Manage. We run your recovery environment as part of our Managed IT Services, with regular reporting and service reviews that show whether your recovery readiness is holding up.

Our team of 200+ specialists holds 1,400+ certifications across 80+ vendors. We’re ISO 27001:2022 certified, and our customers rate us at 98%+ CSAT, against an industry average of 85–90%. As part of Infosys, we combine an onshore team with global scale.

FAQs

Which is more important, RTO or RPO?

They’re equally important because they cover different risks. A payments platform might need a near-zero RPO because lost transactions are unacceptable, while its RTO could be an hour or two. A booking website might be the reverse. Set both for each workload.

What’s the difference between disaster recovery and business continuity?

Business continuity is the broader plan to keep the organisation operating during a disruption, including people, premises, suppliers, and communications. Disaster recovery is the IT part of that plan: restoring systems and data within your RTO and RPO. You need both, and they should use the same recovery targets.

Is my Microsoft 365 data backed up by Microsoft?

Not fully. Under Microsoft’s shared responsibility model, customers always remain responsible for their data and accounts, including in SaaS services like Microsoft 365. Protecting email, SharePoint, OneDrive, and Teams data against deletion, corruption, or ransomware is largely your job. Microsoft 365 should be in your backup scope with its own RPO. Our Modern Workplace team can help you set it up.

How often should disaster recovery be tested?

At least once a year with a full failover test, more often for critical systems, and after any significant change to your environment. Regular checks of backup health and test restores should happen in between.

What should a managed services agreement say about disaster recovery?

At a minimum: which systems are covered, the agreed RTO and RPO for each, who can declare a disaster, escalation paths and response times, how often failover is tested, and how results are reported. Without this in writing, it’s hard to hold anyone accountable during an incident.

 

Find out if your recovery targets will hold

Most businesses have recovery targets on paper. Fewer know whether those targets would hold during a real outage or ransomware attack.

Book a backup and disaster recovery assessment. We’ll review your current setup against your recovery objectives and show you where the gaps are. If you’d rather have a partner own resilience day-to-day, explore our Managed IT Services.

 

Author

Louise Wallace

As a Content Marketing Specialist at The Missing Link, I turn technical insights into engaging stories that help businesses navigate the world of IT, cybersecurity, and automation. With a strong background in content strategy and digital marketing, I specialise in making complex topics accessible, relevant, and valuable to our audience. My passion for storytelling is driven by a belief that great content connects, educates, and inspires. When I’m not crafting compelling narratives, I’m exploring new cultures, diving into literature, or seeking out the next great culinary experience.