The Problem

These definitions are generally accepted by the disaster recovery and business continuity community. Yet, despite this acceptance, we see many problems with the use of these terms.

The first problem is that most people talk about their RTOs as if they can achieve them, and that they’re all the same. Ask anyone, for example at the next Continuity Insights conference: “What are your RTOs?” Often you’ll get the following answer: “We have 24-hour RTOs.” However, it is highly unlikely that everyone’s the RTOs are exactly the same.

In a typical BIA, there are at least three different tiers of RTOs; let’s say 12 hours or less, 12 to 48 hours, and greater than 48 hours. It is more likely, there are about six tiers. But the real problem is not whether there are three or six tiers, but rather that people talk about them as if they are attainable.

The Solution

That’s where the concept of RTAs or Recovery Time Achievable can help by enabling business units and IT to communicate more accurately and realistically. Some organizations are using all three terms: RTOs, RPOs, and RTAs. Here’s why:

Assume that your RTO for a critical process is 12 hours but the best that you can achieve is 48 hours. Then the RTO is still 12 hours and the RTA is 48. That’s a 36 hour gap. Together the business units can work with IT on improving the RTAs through technology solutions such as mirroring or through work-arounds. Too often we hear IT professionals say that business unit RTOs are too short. What IT is really saying is that the RTOs are too expensive to achieve.

This is almost always the case in health care. Nurses say they need patient care recovered in minutes. Patients would agree. But IT says that’s unrealistic. What they really mean is that a not-for-profit hospital is not about to spend the money to do mirroring.

The Technology

Notice that the DRII definition of RTO says nothing about technology. The DRII definition says “lack of business function.” That’s why the Joint Commission requires hospitals to have “down time procedures,” so that the patient care process can be restored before the technology is. This can work in every industry and for every business function — granted some better than others.

This whole scenario of IT saying that the RTOs are too short, illustrates another reason why BIAs should be executed by business units, not IT. You can identidy, during BIA workshops, the possibility of “work arounds” to address the expected gap between RTOs and affordable RTAs. In other cases, where the RTOs already have been defined, you can conduct workshops to get the business units to identify solutions that will improving RTAs. It’s not just IT’s responsibility.

Another interesting phenomenon is how often the RTOs are defined by the solution. For example, your hot site contract may guarantee access within 24 hours; therefore, the RTO is 24 hours. Talk about the tail wagging the dog.

The Conclusion

In conclusion, I humbly suggest that the DRII add RTA to its lexicon. Recovery Time Achievable (RTA) “is comprised of two components: the time before a disaster is declared, and the time to perform tasks (documented in the disaster recovery plan) to the point of business resumption.”

Edward (Ted) B. Brown III, CBCP CBCV is President and CEO of KETCHConsulting. He has 40 years experience in IT and 20 years experience in DR and BCP. He can be reached at (570) 563-0868.