RPO and RTO are the two recovery targets set for a system. RPO (recovery point objective) is the most data, measured in time, that you accept losing in an incident, and RTO (recovery time objective) is the longest a system can stay unavailable before the impact becomes unacceptable. Together they decide how often you must copy data and how quickly you must be able to bring a service back.
RPO and RTO definitions side by side
| Aspect | RPO | RTO |
|---|---|---|
| Question it answers | How much recent data can we afford to lose? | How long can this system be down? |
| Measured as | Time between the last recoverable copy and the failure. | Time from the failure until the system works again. |
| NIST SP 800-34 describes it as | The point in time to which data can be recovered, given the most recent backup copy. | The maximum time a system resource can be unavailable before the impact becomes unacceptable. |
| What it mainly drives | How often data is backed up or replicated. | How recovery is done and how much standby capacity is kept ready. |
| Common mistake | Assuming a nightly backup gives a small RPO. It can mean losing most of a day. | Quoting a target that has never been timed in a restore test. |
The definitions come from NIST SP 800-34 Rev. 1, the US contingency planning guide for information systems (May 2010, updated 11 November 2010), where they sit in the business impact analysis. The Google Cloud disaster recovery guide defines them almost identically for applications. NIST treats RPO and RTO as targets set per system resource and business process, not once for the whole organisation.
How do RTO, RPO and maximum tolerable downtime relate?
RTO must normally be shorter than the maximum tolerable downtime (MTD), and RPO is a separate measure. NIST defines MTD as the total outage the system owner is willing to accept for a business process, counting every impact. RTO has to be shorter because work remains after the system is back, such as checking data, replaying transactions and clearing the backlog. RPO concerns data loss, not time down, so it does not feed into the MTD calculation.
The business owner of the process accepts the MTD and the data loss. IT’s job is to say which recovery times and data-loss windows each design can actually deliver, and what each one involves. A complete RPO RTO definition in the plan therefore carries the owner’s name and the date it was agreed.
A worked example of RPO and RTO for an order system
This is a hypothetical case. The figures are invented for illustration and are not benchmarks or recommendations. A distributor takes customer orders in one application and promises next-day delivery. The steps below set RPO and RTO for that application.
- Find the MTD. Operations managers say that after 8 hours without order entry, next-day delivery promises start to fail. MTD is 8 hours.
- Set the RTO. After a recovery, staff need about 3 hours to re-key orders from the call-centre log and check stock. That leaves 5 hours, and the team sets the RTO at 4 hours to keep a margin.
- Set the RPO. Phone orders are logged separately, so the last 30 minutes of orders can be re-entered. Anything older cannot be rebuilt reliably. The RPO is 30 minutes.
- Compare with what exists today. A single backup at 01:00 each night means an outage at 00:59 loses almost 24 hours of orders. The last restore test took 9 hours. Both results miss the targets.
- Close the gap. Meeting a 30-minute RPO needs copies of the data, such as transaction log shipping or replication, at intervals of no more than 30 minutes. Meeting a 4-hour RTO probably needs a standby environment prepared in advance rather than a rebuild from backup. Ask for options priced against each target, because each tightening adds cost and effort.
- Test and record. Run a recovery, time it against the RTO, check how much data came back against the RPO, and repeat after any change.
Which recovery approach fits which RPO and RTO targets?
Backup and restore suits the longest RPO and RTO tolerances, and pilot light, warm standby and multi-site active/active suit progressively shorter ones. Shorter targets need more standby capacity and more frequent copies, and the cost rises with them. The table follows the four strategies in the AWS disaster recovery whitepaper. NIST describes a comparable range of alternate sites, from cold to mirrored. Cost is shown only as a relative ranking, because real figures depend on data volume, design, licences and provider.
| Objectives | Approach category | What is kept ready | Relative cost and effort |
|---|---|---|---|
| Longest downtime and most data loss tolerated | Backup and restore | Backup copies held separately. Systems are rebuilt and data restored after an incident. | Lowest cost and complexity. |
| Shorter recovery, little data loss | Pilot light | Data replicated continuously and core infrastructure running. Application servers are switched off until needed. | Higher than backup and restore. |
| Short recovery | Warm standby | A scaled-down but working copy of the workload running at all times, scaled up on failover. | Higher again. |
| Near-zero recovery time and data loss | Multi-site active/active | The workload runs in more than one location at the same time. | Highest cost and complexity. |
NIST’s own mapping is similar. Its Table 3-2 pairs lower-impact systems with tape backup and cold sites, and high-impact systems with mirrored systems and hot sites. Replication copies deletions and corruption as faithfully as good data, so many designs keep point-in-time backups alongside it.
Where do recovery plans usually go wrong?
- IT sets the numbers alone. The business owner has to accept the downtime and data loss, so the targets need their sign-off.
- One target for everything. A payroll database and an intranet do not need the same RTO. Tier systems by impact so the expensive approaches go only where the impact justifies them.
- RPO and RTO are never tested. The real recovery time is unknown until someone measures it. AWS, Google Cloud and NIST all call for regular testing of recovery plans.
- Dependencies are missed. A recovered application that cannot reach its identity service, DNS or network has not recovered.
Do Saudi rules set RPO or RTO values?
Not in the NCA controls we reviewed. ECC-2:2024 control 3-1-3 requires entities in scope to include developing disaster recovery plans in their business continuity cybersecurity requirements, but the controls in that sub-domain do not prescribe numeric values for RPO and RTO. The targets are yours to set and defend. The ECC applies to government agencies and their affiliates and to owners, operators and hosts of critical national infrastructure, and the NCA encourages other entities to use it. Sector regulators may add requirements of their own, so check yours.
Where the recovery copy sits is a separate question. It holds the same data as production, so the location rules covered in data residency in Saudi Arabia apply to it too. If you run business continuity under ISO 22301:2019, the international standard for business continuity management systems, treat RPO and RTO as inputs to that wider system rather than as a technical setting.
WASNA Digital Solutions covers disaster recovery planning, including RPO and RTO definition and recovery testing, as part of its virtualisation, edge computing and disaster recovery work.
Check your recovery targets against what your backups can actually do
Send us your main systems, how they are backed up today and the last time anyone timed a restore. A WASNA Digital Solutions consultant will come back with the questions that shape the targets and the options.
Sources
- Contingency Planning Guide for Federal Information Systems, NIST SP 800-34 Rev. 1 (May 2010, updated 11 November 2010). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final; full text https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf. Accessed 2 October 2026.
- Disaster recovery planning guide (last reviewed 5 July 2024). Google Cloud documentation. https://docs.cloud.google.com/architecture/dr-scenarios-planning-guide. Accessed 2 October 2026.
- Disaster Recovery of Workloads on AWS: Disaster recovery options in the cloud. Amazon Web Services documentation. https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html. Accessed 2 October 2026.
- Essential Cybersecurity Controls (ECC-2:2024). National Cybersecurity Authority (NCA). https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654_ECC–2024-EN.pdf. Accessed 2 October 2026.
- ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements. International Organization for Standardization. https://www.iso.org/standard/75106.html. Accessed 2 October 2026.
