RPO is the most data you can afford to lose, measured in time. RTO is the longest you can be down. Set them per system, from the cost of an outage, then price what it takes to hit them and test the result. A target nobody has restored against is only a wish.
Two numbers, two different jobs
Recovery point objective (RPO) is about the past. If your RPO is one hour, you must be able to restore to a state no more than one hour old. Backup frequency sets the limit: the AWS reliability guidance says how often you back up determines the recovery point you can achieve, and that it should line up with your RPO.
Recovery time objective (RTO) is about the future. It is the clock from "we are down" to "users are served again." It includes finding the problem, deciding to recover, restoring data, redeploying code and checking the result. Teams often count only the restore step and are surprised.
Set them per system, not per company
One company-wide number is almost always wrong. Your billing database and your marketing site do not deserve the same budget.
Sort systems into three or four tiers. For each, ask the product owner two plain questions. What happens to revenue and customers if this is down for an hour, a day, a week? What happens if the last day of its data is gone? Write the answers down. The tiers fall out of them.
A typical result looks like this:
- Tier 1, customer-facing and transactional: minutes to an hour for both numbers.
- Tier 2, internal systems that block work: a few hours.
- Tier 3, everything else: a day or more, restored from nightly backups.
Your numbers will differ. The point is that they are chosen on purpose.
Price the target before you commit to it
Tighter targets cost more. The AWS guidance describes a ladder: backup and restore is the cheapest and slowest, then pilot light, warm standby and active/active, each faster and more complex than the last. It also notes that even the best setups have a recovery time and point greater than zero.
So turn each target into a design and a bill. An RPO of near zero needs continuous replication plus point-in-time backups. An RTO of minutes needs a standby environment and scripted failover. If the business will not pay for that, the honest answer is to loosen the target, not to write a number you cannot meet.
Measure what you can actually do today
Run a restore and time it. Record the age of the data you got back and the wall-clock time from start to a working service. Those two measurements are your real RPO and RTO.
Compare them to the targets. The gap is your work list. For a repeatable method, see our small team restore test guide.
Keep the numbers alive
Targets drift. A database grows tenfold and its restore time grows with it. Put the targets next to each system in your service catalogue, and re-run the restore test whenever the data volume or architecture changes meaningfully.
Safeguard's compliance and evidence automation can hold the dated restore-test results that auditors tend to ask for, so the proof sits beside the target. You can also run a free dependency scan at gold.safeguard.sh/scan to see what your recovery plan would need to redeploy.
Quick check
Can RTO be shorter than RPO?
Yes. They measure different things. You can restore in ten minutes (short RTO) from a backup that is a day old (long RPO).
Who should set these numbers?
The business owner of each system, with engineering supplying cost and feasibility. Engineering alone will pick what is easy to build.
Sources
Last reviewed: 19 October 2026.
