Disaster RecoveryBusiness ContinuityPlanning
RTO and RPO: How to Set Recovery Objectives That Hold Up
Recovery time and recovery point objectives turn 'we need it back fast' into numbers you can plan, buy and test against. Here's how to set them per workload.
- Published
- Reading time
- 3 min read
- Author
- KELYN Technologies

Ask anyone how quickly a critical system needs to come back after an outage and the answer is usually "immediately." That isn't a plan. Two numbers turn it into one.
Two definitions
Recovery time objective (RTO) is how long a workload can be down before the outage does unacceptable harm: the target time to have it running again.
Recovery point objective (RPO) is how much data, measured in time, a workload can afford to lose. An RPO of 15 minutes means backups must run at least every 15 minutes, because anything written since the last one is gone.
RTO drives how you recover. RPO drives how often you back up.
Set them per workload, not per company
A single company-wide RTO is either too expensive for most systems or too slow for the important ones. Instead, list the systems the business can't run without, then work outward. For each workload, write down:
- The owner, by name and role, who decides what "acceptable" means.
- The RTO, from what an hour of downtime actually costs. The downtime cost calculator helps put a figure on it.
- The RPO, from how much re-entered or lost work the business can absorb.
- Backup frequency and retention that actually meet that RPO, and any records or regulatory requirements.
A student information system, for example, might carry a 4-hour RTO and a 15-minute RPO, backed up every 15 minutes and kept for seven years.
Check the order, not just the numbers
Objectives only hold if the systems they depend on come back first. The backup platform itself has to recover before anything else can be restored. Identity usually comes next: until Active Directory and Entra ID are trustworthy, nobody can sign in to the applications you just restored.
Write the recovery order down, with what each system depends on and who restores it.
Prove them
An RTO you have never measured is a hope. Restore tests show how long recovery really takes, and whether your RPO survives contact with real backup jobs. Test on a schedule, record the result, and adjust either the objectives or the infrastructure when they don't match.
A template to start from
Our free disaster recovery plan template has tables for recovery objectives, copies and locations, recovery order, testing and contacts. It's a two-page PDF to print and fill in with your team.
KELYN also plans, tests and keeps disaster recovery plans current as a managed service, with a biannual KELYN Score review.