What’s the difference between an RPO and an RTO?

The recovery point objective (RPO) and the recovery time objective (RTO) are two of the most vital elements of any disaster recovery (DR) program. But they also sound – and appear – strikingly similar. So, it wouldn’t be surprising if you mixed them up, or worse yet, didn’t know what they were all together.

If your organization doesn’t have or know them, your chance of successfully recovering after a disaster is slim. We’re here to make sure that doesn’t happen.

Let’s discuss the main differences between RPO and RTO, why each is important to a successful recovery, how to calculate them and real-world examples of each in practice.

What is RPO?

RPO is the amount of data your business can afford to lose, measured in terms of time. It refers to the period before the incident – specifically that last clean data point you’re going to recover from - and determines how often you need to back up your data.

For example, an organization with infrequent changes to data might have an RPO of 12 hours, while one with constant transactions might have an RPO of five minutes, or even zero if no data loss is acceptable.

RPO is driven by your organization’s investment in the technology solution it’s using, the number of product changes being sent into the DR site and how much bandwidth you have to process those changes. It’s also heavily dependent on the nature of your business and its work. For instance, a financial institution or hospital can’t really afford any data loss, while a local bookstore probably can get away with losing more.

How to calculate RPO

Calculating RPO is about finding the right balance between the cost of recovering all data and the risk of losing any data, based on your organization’s business needs and risk tolerance. Different applications can have different RPOs.

Ask yourself: What are your most critical applications, and how would your business be impacted if they went down and began losing data?

A bank might not be able to afford losing any transaction data but might be OK with losing the last day’s worth of HR data, which is more easily replicated. With this information, tier your applications based on their level of importance.

Tier 1 for mission-critical applications, Tier 2 for business-critical applications and Tier 3 for important applications that don’t really affect your revenue. 

By categorizing your applications based on the impact they have on your business, it’ll be easier to decide how frequently you need to backup your data, as well as the order in which applications should be recovered. 

What is RTO?

RTO refers to how quickly your organization needs to be back up and running after a disaster. The RTO is the time between the incident and when your systems are back online. The clock starts when the incident occurs, not when IT reacts to the incident. 

For example, let’s say your RTO is 24 hours. If it takes your organization three hours to invoke its DR plan and your IT team three hours to respond, you’ve already used six hours, leaving you with 18 hours left. 

Despite this lost time, some organizations believe they’re still within the 24-hour recovery period. This misinterpretation can lead businesses to fall outside their desired RTO and miss their recovery requirements. If you’re not up and running in the designated time frame, you could face repercussions such as lost revenue and reputational damage.

Therefore, RTO must be driven by more than just the time it takes the IT team to perform the actual recovery work. 

How to calculate RTO 

Since RTO has to do with the time it takes your business to recover, you need to weigh all aspects of the recovery. 

How long it takes to assemble a crisis management team and assess the incident. How long before you invoke your DR plan and your IT team responds to the incident. How long the actual recovery work itself will take. 

These are all factors that you must consider when determining your RTO. Additionally, just like RPOs, RTOs can vary based on the types of businesses and applications you’re dealing with. Banks and hospitals would likely need shorter RTOs, while a marketing firm might not need to be up and running almost immediately. Applications that directly relate to revenue are more important than HR data, so their RTOs should be shorter as well. 

How often should you review RPO and RTO?

Organizations should review their RPOs and RTOs at least once a year. But that’s assuming their business priorities and IT environment haven’t changed all year, which is rarely the case.

Businesses undergo technology transformations all the time. Their needs and, subsequently, what’s most important to them, constantly change as well. 

We worked with a manufacturer that strictly distributed its products to retailers for resale. After a few years, the manufacturer altered its business model and began selling its products online directly to consumers. As a result, a system that was once of little importance to the company became its most important system, and its direct sales customer database, which once held very little value, became its number one application. The RPOs and RTOs had to be reevaluated to reflect these changes.

Perform regular assessments as your business and technology needs change to determine the impact of an outage. With this, you can identify the correct timeframe for recovery and the data point you need to keep, ensuring that your RPOs and RTOs reflect the changes of the business.

How cyber attacks affect RPO and RTO

Everything we’ve covered so far relates to traditional recovery like a system outage. RPO and RTO become more complicated when you start talking about data recovery.

DR and data recovery are two completely unique recovery cases that need different approaches. 

With a system outage, you recover using the latest data. However, with a cyber event, you’re looking for the cleanest data. That means the recovery is going to take longer, and you shouldn’t expect to meet your initial RTOs.

As it pertains to cyber, RPO is about business survival, not business disruption. RTO is about making sure your systems are clean and functional, not just up and running quickly. Only through forensic analysis will you be able to ensure you’re using the most recent clean data. 

If you want to reduce the risk of a failed cyber recovery effort, these best practices – which we’ve integrated into our compromised data risk management (CDRM) framework – can help.

Do you know your RPOs and RTOs?

According to a recent Gallup survey, one in three Americans were impacted by an extreme weather event in the past two years. Cyberattacks remain a growing threat. It’s clear that businesses must be even more on their toes and ready to recover from disruptions.

The acronyms may look the same, but each represents an important element of your recovery strategy. Be sure they reflect changes to your business needs and the technologies you rely on the most, so you can more quickly and successfully recover after a disaster.