Most organisations either over-invest in disaster recovery or assume their backups will be enough. Neither works. Here's how to set RTO and RPO targets that are actually aligned to what your business needs.
Ask a room full of business leaders what their disaster recovery targets are, and you'll often get one of three answers:
"We should be back up within a few hours, I think."
"Our backups run every night, so we're probably fine."
"Whatever our IT provider recommends."
None of those answers are unreasonable. They're also the reason many organisations either spend far more than they need to — or far less than they should.
Recovery Time Objective (RTO) and Recovery Point Objective (RPO) sound like technical terms. In practice, they're business decisions.
Why RTO and RPO are so often misunderstood
At a basic level: RTO is how quickly you need a system back after an outage. RPO is how much data you can afford to lose.
Simple enough.
The problem is that these numbers are often set without context. They're guessed, inherited, or copied from another organisation's template. They're driven by what the technology supports rather than what the business actually needs.
And because disaster recovery is something we hope we never need, it rarely gets revisited once it's written down.
The two common failure modes
Most organisations fall into one of two traps.
Trap one: "Protect everything like it's mission-critical"
In this scenario, leaders assume the safest option is to recover everything immediately, with near-zero data loss.
Every system is treated as critical. Every workload gets the same aggressive RTO and RPO targets. The resulting solution is expensive, complex, and difficult to test meaningfully.
It looks impressive on paper — but the cost often crowds out other priorities, and the recovery environment itself becomes hard to manage.
Ironically, this level of protection is rarely used across the whole environment. Much of it exists "just in case".
Trap two: "We'll figure it out if it happens"
At the other end of the spectrum, some organisations assume their backups will be enough.
They know data is being copied somewhere. They trust that recovery will work. They've never had a serious outage — so it's hard to justify spending more.
The problem is that backups alone don't equal recovery.
In real incidents, organisations often discover that restores take far longer than expected, dependencies between systems weren't understood, data loss is greater than assumed, and the order of recovery wasn't clear.
By the time those gaps surface, the business impact is already real.
Why "one size fits all" never works
The core issue in both cases is the same: not everything is equally important.
Some systems are genuinely business-critical. Others are important but tolerable for a short period. Some are inconvenient to lose but not damaging.
Without distinguishing between them, RTO and RPO targets become blunt instruments.
Setting realistic recovery objectives requires understanding what actually matters to the business, not just what exists in the technology environment.
What usually gets missed in RTO/RPO conversations
When organisations struggle with recovery planning, it's rarely because they lack technology.
What's missing is business context.
For example: which systems directly affect customers or revenue? Which ones support internal efficiency but have workarounds? What happens if a system is unavailable at month-end versus mid-week? How much manual effort is acceptable during an outage — and for how long?
These questions don't have technical answers. They require cross-functional input and a structured way to weigh impact against cost.
Making RTO/RPO a business conversation again
The most effective disaster recovery strategies start by reframing the discussion.
Instead of asking "What can our technology do?", the better question is: "What does the business actually need to survive — and for how long?"
In practice, this means mapping systems to business functions and impact scenarios.
A practical example might look like this: email needs to be restored quickly, but a small delay is manageable. Finance systems may tolerate limited downtime, but data loss is not acceptable. A legacy reporting system might be unavailable for days with minimal impact. Customer-facing platforms may require rapid recovery during business hours, but less so overnight.
Once these distinctions are made, RTO and RPO targets stop being abstract numbers. They become risk-aligned decisions.
Why cost and confidence improve at the same time
This is the part that often surprises people.
When recovery objectives are properly aligned to business impact, organisations usually find they can reduce complexity and cost in some areas — while genuinely improving protection where it matters most.
By focusing investment where it genuinely matters, they avoid over-engineering low-impact systems while strengthening protections around the ones that could cause real damage.
The recovery environment becomes simpler. Testing becomes more realistic. Confidence improves — not because everything is covered equally, but because the right things are covered well.
The role of Disaster Recovery Strategy & ICT Risk Assessment
This is where a structured Disaster Recovery Strategy & ICT Risk Assessment makes a meaningful difference.
Rather than starting with solutions, it starts with understanding: the current recovery capability, system dependencies and failure points, business impact of downtime and data loss, and gaps between assumptions and reality.
From there, recovery objectives are set deliberately — and defensibly.
The outcome isn't a generic DR plan. It's a prioritised, practical recovery approach that aligns technology effort with business risk. Importantly, it also creates a shared understanding between technical teams and leadership. Everyone knows why certain systems are prioritised, what the targets mean, and what investment is justified.
Testing assumptions before they're tested for you
Another quiet benefit of doing this work properly is that it makes testing meaningful.
When RTO and RPO targets are realistic, recovery testing becomes less about ticking a box and more about validating what the business actually expects.
Instead of asking "Did it restore?", the question becomes "Did it restore in the way the business expects?"
That shift alone can prevent painful surprises.
Disaster recovery isn't about perfection
It's about preparedness.
No organisation can eliminate all risk. But organisations that understand their recovery requirements — and have aligned their technology accordingly — are far better positioned to respond when something goes wrong.
Setting realistic RTO and RPO targets isn't about being pessimistic. It's about being intentional.
And when that clarity exists, disaster recovery stops being an uncomfortable topic — and becomes part of confident, disciplined technology governance.