Recovery Time Objective Vs. Recovery Point Objective

What a difference a word makes.

Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are close enough in phrasing that the two concepts are often confused. But it’s safe to say that you can’t develop a realistic business recovery strategy without using them both, so it’s worth taking a minute to get it right.

Recovery Time Objective Vs. Recovery Point Objective

Recovery Time Objective

Recovery time objective is the time in which a business process and its associated applications must be functional again after an outage event.

In other words, RTO refers to the time it takes for functional restoration of a business process, close to where it was before the disruption. If the finance department’s accounts payable process needs to be operational again four hours after a disruption occurs, that means it has an RTO of four hours or less to return to its pre-event state of functionality. RTO is used to develop recovery strategies and implement technologies to allow that to happen in the necessary time frame.

The RTO for a business process also applies to the applications associated with that process. For example, the computer systems utilized by customer service are under the same RTO umbrella as the customer service processes themselves and must be recovered in the same amount of time. This is especially useful considering the fact that many applications are shared across departments and processes; so if one department needs the application to be recovered in 12 hours and the other in four hours, its recovery must be planned to meet the four-hour RTO. This allows both processes to return to normal operations in the necessary time frame.

The best way to determine RTO is through a Business Impact Analysis (BIA). Estimating the dollar and non-dollar impacts of a disruption helps you arrive at a realistic and objective RTO. But even without a complete BIA, you can still determine RTO through a less formal process. To do so, you’ll want to talk through the various aspects of the unit, including a discussion of processes and dependencies. Keep in mind, though, that the BIA is valuable in part because of its objectivity. Without it, managers may under-report their needs and staff members tend to over-report. A BIA is designed to overcome preconceived notions with objective questions and criteria.

Performing a Business Impact Analysis doesn’t have to be difficult. Try our BIA On-Demand self-assessment tool to see for yourself.

Recovery Point Objective

Recovery point objective defines the maximum acceptable data loss that a business process can stand to lose within individual applications before it is critically impacted. In other words, it’s a data-loss metric expressed in time (e.g., minutes, hours, or days) directly related to applications. RPO is used to determine the point in time to which data needs to be recovered after a disruption, which usually comes down to minutes or hours.

RPO is used to define the type of data recovery strategy you’ll leverage on your applications,  allowing your technical team to make appropriate technology and cost choices. As we become more reliant on technology, RPOs are becoming shorter and shorter—so to use them effectively you must understand the need behind a recovery time. For example, for a business unit that uses multiple applications, first try to understand what each application is used for and how it might be worked around should it fail. You might discover it’s more cost-effective to focus recovery efforts on a single application that can support a unit’s processes sufficiently, and is also less expensive to protect when it comes to data loss.

The Interrelatedness Of Recovery Time Objective & Recovery Point Objective

While RTO and RPO are related, in many cases they aren’t the same.

Here’s an example of a high RTO and low RPO:

The accounts payable process typically has a long recovery time, because in a disruption, paying out isn’t considered a highly critical business activity. So, accounts payable might have an RTO of five days. That means your recovery strategy will aim to have the accounts payable process and all of its required applications up and running in five days. However, the computer system itself has valuable data on it—and any loss of that data will result in the team no longer having a way to tell what checks have previously been cut, what invoices have been submitted recently, etc. In this situation, there’s little to no room for data loss, so the RPO is near zero.

An example of low RTO and high RPO:

For many businesses, maintaining a web presence is critical to operations. In the event of disruption, restoring the company website is a high priority—so the RTO is almost immediate. But the data on the site probably doesn’t change very often (maybe once weekly), so it’s less critical to guard against data loss, resulting in a higher RPO.

An example of similar RTO and RPO:

Consider a massive online retailer like Amazon, whose website must always be operational (near zero RTO) and whose data loss must be almost nonexistent (near zero RPO). Without a quick recovery of the website and all its associated data, the impact of a disruption would be catastrophic.

Moving In The Right Direction

The key to understanding both of these concepts is the “O”—objective. Both RTO and RPO describe a desired requirement or position. Sometimes it’s simply not possible to achieve the objective, but you should be continually moving toward it. You might be tempted to change the RTO to a more achievable time frame, but resist the temptation. The number is based on business needs, not capability.

If you can’t meet either the RTO or the RPO, start with what you can do and try to improve incrementally. It’s too expensive to jump from 24 hours to zero, but if you strive to reach 12 hours, you’re still making a significant improvement (but at less cost).

Need help?

For help setting these critical benchmarks, try our BCMMetrics™ BIA On-Demand (BIA^OD) tool. Using the latest industry standards, it provides you with you all the right questions to ask so you can set realistic RTOs and RPOs. You can also generate a wide range of easy-to-read charts to share your results with management. There’s no software to install; the tool is cloud-based and secure, so you can get started right away.

Schedule a demo to see BIA^OD in action, or contact us if you have any questions.