Press Release
Last Updated on January 14, 2024
Recovery Time Objectives (RTOs) are the essential starting point for determining your disaster recovery strategy. Why? Because you need to know which functions are most critical and how long others can be deferred, so you can make the most time- and cost-effective use of your recovery budget.
What is an RTO?
A Recovery Time Objective is the duration of time within which a business process must be restored after an information security disaster/disruption in order to avoid unacceptable results of a break in business continuity. This should be identified in your business impact analysis.
Your business impact analysis (BIA) report is your recovery requirements document. This is how you determine what functions are performed, identify the Recovery Time Objective for each one, and from there prioritize their recovery.
If you don’t do a BIA, you won’t know what you need or when you need it. As a result, recovery of critical functions may be delayed because you’re spending your time recovering a function you don’t actually need right now.
Why You Need an RTO and BIA Best Practices
Given unlimited time and resources, anybody can recover from anything. The trick is to do it efficiently and effectively and minimize the impact of the disruption by recovering your most critical functions first. How do you know what’s most critical? You perform a BIA.
Still not convinced that you need a BIA and concrete RTOs? Consider this: any recovery strategy you implement comes with a price tag. Strategies that enable the fastest recovery are the most expensive.
As an example, backup tapes can be a cheap and effective strategy for data recovery. But think about what you need to have up-and-running to recover that system using tape backups—the server, the tape device, the application, the database…
Tape may be cheap, but it’s not fast. To back up a function that you need to recover quickly, you need to plan on investing in pricier media, redundant systems, etc. To make that possible given that price tag, you may need to minimize the cost associated with recovering lower-priority functions.
Say you have ten functions, but only one of them needs to be recovered within eight hours. By limiting the implementation of a rapid recovery strategy to just that one function and using less expensive strategies for the others—in alignment with their RTOs—you may be able to buy more recovery capability for the one function rather than needlessly throwing your whole budget at a high-end strategy that will recover various functions faster than business needs dictate.
How can you be sure you’re spending your limited recovery budget in the most judicious manner? Perform a BIA, identify RTOs and prioritize on that basis. Otherwise, you’re shooting from the hip.
It can be easy to think that you have the “common sense” answers you need to implement a recovery strategy without doing a BIA and computing Recovery Time Objectives. But it’s axiomatic that “we don’t know what we don’t know.”
If you haven’t done a BIA, there is probably a lot you don’t know. You don’t want to find that out the hard way during a disaster.
You also don’t want to be the person answering this question from senior management: “Why did it take us four weeks and $3 million to recover, when we could have done it in 10 days for $250,000?”
To get expert advice on initiating and implementing a recovery strategy, contact Pivot Point Security.
