RTO and RPO: A crash course in determining recovery requirements

Clock 1Planning for recovery is an essential part of BC/DR. (Recover is the “R,” after all.)

But what does recovery actually mean? When it comes to your performing your business impact assessment, you’ll generally be interested in two measures: RTO and RPO.

RTO: recovery time objective

When thinking about your recovery time objective for any particular process, consider the length of time you can go without it before your business starts to suffer irreparable damage. For critical IT systems, this could be a matter of hours. Some facilities issues might have a much longer RTO. For most processes, however, the more time you spend without them, the greater the impact to the organization.

To determine your RTO, look at each process you rely on and ask “What’s an acceptable time window? Can we live without a process for days? Only hours? Minutes?”

RTOs differ from company to company—and even from department to department—but here are some common ones:

  • One hour
  • Close of business
  • Current business day
  • Tomorrow
  • Three days
  • Within a week
  • Beyond a week

They may also vary from season to season. If your business goes through peak periods and lulls, for example, recovering a particular process before another may become less important, or unnecessary altogether.

It’s important to figure it all out, though. By quantifying and ranking the RTOs for each critical process, you’ll be able to prioritize resources to restore the ones with lower RTOs before the rest of them.

Tip: partial recovery may be enough

You may wish to think about partial recovery for your processes. If fully recovering a particular process isn’t necessary to keep your organization running in the short term, consider stopping when it’s recovered “enough,” and moving on to others.

Tip: your RTO may not start when you think it does

Remember to calculate your RTO from the time a disruption is discovered and declared, as opposed to when the disruption actually happened.

Why? For all intents and purposes, until a disruption is discovered, you can’t do anything about it.

RPO: recovery point objective

Don’t confuse RTO with RPO, as the latter applies only to processes that involve data.

For any data-bound process, your recovery point objective is the measure of how current your data needs to be once it’s restored. In other words, it’s the maximum time period in which data might be lost.

A financial institution might need data that is current within the past hour. A manufacturer or retailer, on the other hand, might be able to survive by restoring a back-up from the night before, so a typical RPO might be eight hours.

Tip: Understand how RTO and RPO work together

RTO and RPO are different measures; it might help to think of RPO as what you need and RTO as the time you need to get it in.

It’s quite conceivable, for example, to have an RPO of one hour but an RTO of four hours. This scenario would see your IT recovery specialists having a four-hour window to restore data that’s no more than an hour old—meaning you’d need to plan for mirrored data that could be pressed into service at a moment’s notice.

Using RTO and RPO to assess your resources

By determining your RTOs (and RPOs, if necessary) you’ll be able to identify the resources you’ll need in place before disaster threatens.

Which, of course, is a good thing—knowing in advance what technology, supplies, people and vendors need to be in place to restore your processes will only help during the heat of a crisis.

Learn more about BC management with The Definitive Guide to Business Continuity Planning. Learn more about emergency notification with 10 Tips to Improve Notification Response Rates.