Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the two numbers that define what “recovered” means. Getting them agreed — and funded — is where many DR plans stall.
Definitions
- RTO: how long a service can be down before the impact is unacceptable.
- RPO: how much data, measured in time, you can afford to lose.
Why they are often wrong
Targets are frequently set by IT alone, copied from a template or never tested. In a cyber event, recovery also includes investigation and validation time, so cyber RTOs are usually longer than DR RTOs.
A practical approach
- List critical business services, not just servers.
- Ask owners what an hour, a day and a week of downtime would cost.
- Tier services by impact and assign RTO/RPO per tier.
- Check what your current architecture can actually deliver — and close the gap or adjust the target.
Why it matters: realistic, signed-off targets drive the right investment — and give you a defensible answer when auditors ask.
Example tiers
| Tier | Typical services | Example RTO | Example RPO |
|---|---|---|---|
| Tier 1 | Customer-facing transactions, identity, payments | Hours | Minutes |
| Tier 2 | Internal business applications, reporting | 1–2 days | Hours |
| Tier 3 | Archives, development, non-critical tools | Days to weeks | 24 hours |
The numbers will differ for every organization. What matters is that each tier is agreed with business owners, mapped to the protection technology that can deliver it and tested at least once a year.
Key takeaways
- Set targets per business service, with the business.
- Cyber recovery adds validation time to RTO.
- Test against the targets and report the gap.
Need defensible RTO/RPO targets?
Our DR Planning & Design service helps you agree targets and design an architecture that meets them.
