RTO vs RPO Explained

What is recovery time objective (RTO)?

NIST defines the recovery time objective as the overall length of time an information system’s components can be in the recovery phase before negatively impacting the organisation’s mission or business processes. In business continuity practice the same idea is applied more broadly than IT: the RTO is the target elapsed time between a disruption starting and a prioritised activity being resumed at an agreed minimum level.

Practical points that matter when you set one:

• The clock runs forward from the moment of disruption, and it includes detection, decision making, invocation and the actual restoration work, not just the technical restore.
• The RTO must be shorter than the maximum tolerable period of disruption for that activity. The gap between the two is your safety margin.
• RTO is set per activity or per system, not once for the whole organisation. A payments platform and an internal reporting tool do not need the same target.
• It is a business decision informed by impact over time, then costed by IT and operations. It is not a number the infrastructure team invents.
• The RTO drives architecture: warm and hot standby, clustering, automated failover, cross site capacity and standby staffing all exist to shorten it.

An RTO that has never been tested is an assumption. Exercising and testing recovery, and recording the actual achieved recovery time, is what turns the target into evidence.

What is recovery point objective (RPO)?

NIST defines the recovery point objective as the point in time to which data must be recovered after an outage. Put another way, it is the maximum amount of data loss the organisation is prepared to accept, expressed as a period of time. An RPO of four hours means that after recovery you may have lost up to four hours of transactions and you must be able to operate on that basis.

Practical points that matter when you set one:

• The clock runs backward from the moment of disruption to the last usable recovery point, so RPO is governed by how often data is copied, not by how fast you restore.
• The RPO sets the backup or replication frequency. A near zero RPO means synchronous replication. A twenty four hour RPO means a nightly backup can be enough.
• It is constrained by what the business can reconstruct. If orders can be re keyed from email, a longer RPO is tolerable. If they cannot, it is not.
• Backup success reports do not prove the RPO. Only a tested restore, checked against the data actually recovered, proves it.
• Immutable or offline copies matter here. A ransomware event that encrypts the replica destroys the recovery point even when replication was working perfectly.

RTO vs RPO: side by side

Which one do you need?

You need both. They are not alternatives, and setting one without the other leaves a real gap. A four hour RTO with a twenty four hour RPO means you are back online quickly, working on yesterday’s data. A fifteen minute RPO with an eight hour RTO means the data is current but nobody can reach it for most of a working day.

A workable sequence looks like this:

1. Run a business impact analysis to identify prioritised activities and how impact grows over time.
2. Set the maximum tolerable period of disruption for each activity from that impact curve.
3. Set the RTO inside that limit, and set the RPO from how much data loss the activity can absorb.
4. Cost the technical options that would meet those targets and take the gap back to the business owners.
5. Agree final targets, document them, then exercise and measure the achieved values.
6. Review the targets when the activity, the volumes or the dependencies change.

If you are implementing ISO 22301, both figures become audit evidence. An auditor will look for the link from the business impact analysis to the agreed targets, and from the targets to the continuity solutions and the exercise records that show they hold.

Frequently asked questions

Is RTO or RPO a standard you can be certified against?

No. Neither is a standard. Both are recovery targets that an organisation sets for itself. Certification applies to the management system around them, most commonly ISO 22301:2019, the business continuity management system standard, which requires you to determine recovery time objectives and recovery point objectives during the business impact analysis.

Which should be shorter, RTO or RPO?

There is no rule that one must be shorter than the other. They measure different things. What matters is that each is justified by the impact on the activity and that the technical solution actually delivers both. It is common for a transactional system to have a very short RPO and a longer RTO, and for a reporting system to have the reverse.

How does RTO relate to maximum tolerable period of disruption?

The maximum tolerable period of disruption is the point at which the impact of an outage becomes unacceptable to the organisation. The recovery time objective is the target you plan to, and it is set inside that limit so that there is margin for a recovery that runs late.

Does a shorter RPO always cost more?

Generally yes, because reducing the RPO means copying data more often or continuously. Moving from a nightly backup to asynchronous replication adds bandwidth and storage. Moving to synchronous replication adds latency constraints and usually a second site. The right question is what the business loses per hour of lost data, and whether that exceeds the cost of closing the gap.

How often should RTO and RPO be reviewed?

Review them whenever the underlying activity, transaction volume, dependency map or regulatory position changes, and at minimum as part of the periodic business impact analysis refresh. Under ISO 22301 the review is also picked up through management review and internal audit.

Do RTO and RPO apply to cloud and SaaS services?

Yes, and they need to be checked against what the provider actually commits to in the contract. Cloud service level agreements usually cover availability, which is not the same as a recovery time or recovery point commitment after data loss. Where the provider does not commit to your targets, the gap has to be closed by your own backup arrangements or accepted formally.

Univate Solutions runs business impact analysis workshops and business continuity management system implementation, including ISO 22301 certification readiness. Book a consultation to set recovery objectives you can actually evidence.

Univate Global delivers ISO certifications, data privacy compliance, and cybersecurity frameworks across 9 markets.