Many organizations have fallen into the habit of letting the IT department have veto power over the recovery time objectives proposed by the business units. This is a bad idea for any company that wants their business continuity program to actually protect the business.
Related: Bridging the Gap: Aligning RTOs Between IT and the Business Units
Summary
There are two kinds of organizations when it comes to business continuity programs.
Some have a BC program because they have to or think they ought to. But they make it obvious from things they say and do that they place little value on continuity planning.
Others invest in BC because they are realistic about the possibility of disruptions and want to ensure that, if they experience one, they will be able to recover quickly, with minimal impact to their operations, reputation, and bottom line.
A good way of telling how a given company feels about BC is to look at who in the organization has the greatest influence on its recovery time objectives (RTOs).
RTOs, of course, are the windows of time after a disruption within which critical business processes, systems, and applications must be recovered to prevent an unacceptable level of damage. Sound BC methodology calls for RTOs to be established through discussions among the BC office, the business units, IT, in the case of technical resources, and management.
If a company lets BC and the business units be the main driver in the RTO discussion, that’s a pretty good sign that they are serious about protecting the organization and its stakeholders from disasters.
If it defers to IT, it is a strong indication that their approach to contingency planning comes down, essentially, to crossing their fingers.
For any BC person, whether in-house practitioner or external consultant, working with organizations that lack a serious commitment to continuity can be frustrating.
Few aspects of working for a company like this are more frustrating than the discussions that take place around RTOs.
Here’s an experience I’ve had many times in doing engagements with companies whose interest in BC planning was less than whole-hearted:
We get management to weight and set the impact categories and indicate their risk tolerance. Then we go through a rigorous BIA, talking with key people at the critical business departments to learn the relative criticality of their processes, systems, and dependencies.
Based on the information obtained, we come up with appropriate RTOs for the key processes, systems, and apps. In this blog, we are only concerned with critical processes that involve information technology. Many do not, of course.
So far, so good.
Then we go to management and IT and tell them our findings regarding what the RTOs should be for different technology resources.
Their reaction, in many cases, is to look at you like you’re an alien with a third eye. They frequently look shocked and horrified and make it obvious they regard your findings as one step shy of ridiculous.
It’s common for IT departments, and the executives are often in lockstep with them, even though the findings are based on information that management helped us obtain.
It’s not unusual for IT to regard the proposing of new, shorter RTOs as a personal attack.
The issue is that the careful application of BC methodology as described above commonly results in RTOs that IT knows it cannot meet. And which management knows could only be met if significant resources were invested in beefing up IT’s capabilities.
So IT is inclined to scoff at the proposed new RTOs, and management has a tendency to agree with them.
Why is this a problem?
Because it shuts out the people who have the most intimate knowledge of the damage that would be caused by prolonged disruption of the various processes: the key people in the business departments.
IT shouldn’t get to define the business’s tolerance for disruption simply by pointing to its current technical capabilities.
When IT tells the business people what the RTOs are going to be, rather than the other way around, the cart has officially been placed in front of the horse.
In these cases, management is a little like someone who strolls into a Porsche dealership and says he wants a 911 with all the trimmings then freaks out when he learns the price.
The bottom line is, the business departments, with BC acting as their wingman, should drive the RTO discussion.
This is not to say that the business departments should dictate the RTOs. Nobody in this discussion should be dictating anything.
Here’s how the process should go:
This doesn’t mean management has to drop everything and spend whatever it takes to close the gaps.
It just means being realistic and working together as a team to address the gaps over time.
For example, IT might tell a particular department: “You say you need this in 24 hours, but right now the best we can do is 48. We’ll try to get the funding that will enable us to shorten it, but are there any mitigations you can set up in the meantime?”
One thing the approach I’m recommending definitely does not entail is IT and management simply dismissing the proposed RTOs out of hand as a collective delusion of the business units and BC office.
In our work with organizations, we’ve found that a few practical approaches can make conversations about RTOs with management and IT considerably more productive. In-house BC practitioners might also find them helpful.
One reason people can react badly to RTOs is that they have no frame of reference for what reasonable recovery targets look like. If you tell an IT department that a critical application has an RTO of 24 hours and they know they currently need 48, they may immediately conclude that the RTO is unrealistic. If, on the other hand, they understand that 24 hours is a common target for critical applications in their industry, they might find your number easier to digest. Providing such context can be difficult for an in-house practitioner who has worked with only one or a small number of organizations. A consultant with experience across many organizations and industries can be particularly useful here.
Don’t simply present management and IT with a list of numbers. Take them through the process that produced the results: which processes were assessed, what impacts were identified, how those impacts were weighted, what risk tolerance management established, and how those factors led to the resulting recovery objectives. Make it clear that nobody pulled the RTOs out of a hat. They are the product of a business-driven process that involved the organization’s own people.
An RTO tells the organization what recovery capability it believes it needs. It does not necessarily describe what the organization can accomplish today. That distinction gives IT an opportunity to say, in effect, “We understand that the business needs this capability. We can’t deliver it today, but here’s what it would take to get there.” Perhaps the current capability is 48 hours while the business needs 24. Now the organization has a gap to address.
Nobody should expect an organization to transform its recovery capabilities overnight. Some improvements may be relatively easy; others may require new technology, additional staff, changes to processes, or significant investment. The important thing is to acknowledge the gap, understand its implications, and work together on how to address it.
That, ultimately, is what a mature RTO discussion looks like: not the business dictating impossible demands to IT, and not IT dictating the organization’s risk tolerance to the business, but the two sides working together to understand what the business needs, what the organization can currently deliver, and what it will take to close the gap.
RTOs should reflect the amount of downtime the business can tolerate, not simply the recovery capabilities IT happens to have today. A well-conducted BIA gives the organization a business-driven target and exposes the gaps between that target and current capabilities.
The answer to those gaps is not for IT and the leadership to dismiss the RTOs. It is for all the parties to understand the gap, assess the risk, and work together over time to build the recovery capabilities the business actually needs.
MHA Consulting helps organizations conduct BIAs, establish business-driven RTOs, and develop practical strategies for closing recovery gaps. Contact MHA to learn how we can help your organization align its recovery capabilities with its business needs.
Recovery time objectives (RTOs) define how quickly critical business processes, systems, and applications need to be recovered after a disruption to prevent unacceptable damage. They should be established through a business-driven process involving the BC office, business units, IT, and management, not simply dictated by IT’s current capabilities.
A well-conducted BIA can produce RTOs that IT knows it cannot currently meet, which can lead IT and management to dismiss the results as unrealistic. This can turn RTOs into a source of conflict and allow technical constraints to override the business’s assessment of how much disruption it can tolerate.
The organization should accept the RTOs as legitimate business objectives and then work collaboratively to address the resulting gaps. That may involve additional investment, improved technology or processes, or interim mitigations while longer-term improvements are made.
Four approaches can help: provide industry context so people have a frame of reference for the targets; explain how the RTOs were derived from the BIA; emphasize that RTOs are objectives rather than commandments; and give the organization time to build the capabilities needed to meet them.
RTOs should reflect how much downtime the business can actually tolerate, rather than simply reflecting what IT can recover today. The purpose is not to demand instant transformation, but to identify the gap between business needs and current capabilities and work together to close it over time.