Getting in Sync: Eliminating Recovery Strategy Gaps between BC and IT

Sometimes problems result when the IT department does its own recovery planning then the business continuity  (BC) team comes along and conducts an analysis that shows IT’s plans to be inadequate. 

In today’s post, we’ll look at why this gap in recovery strategies is dangerous and what you as a business continuity professional can do to narrow it.

Why IT Can’t Do Recovery Strategies in a Silo

The lack of alignment on key recovery objectives between IT and the business continuity team can lead to catastrophic impacts to customer service, operations, shareholder value, and other areas in the event of a critical disruption.

However, this is an area where the IT department deserves a good amount of sympathy and understanding from the BC team.

The problem starts when the IT team sets about working on its own to develop recovery plans for the organization’s systems and applications independently from the business continuity team. Often they are told to do this by management, and they typically do the work in a silo, with minimal cooperation from other departments.

In devising their recovery plans, the IT department is usually flying blind because they have a limited view of the larger needs of the organization.  

How IT Sets RTOs and RPOs

In creating their disaster recovery plans, the IT department typically establishes Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for each system or application.

RTOs are expressed as the amount of time (such as 8 hours or 24 hours) within which the process must be restored after a disruption to avoid significant impact to the organization.

RPOs are applied to systems where data transactions take place and where failures can lead to the loss of unbacked-up data. The RPO is also a measure of time (such as 8 hours or 24 hours) expressing how long a period of transactions the organization can lose in the event of an outage.

Related to those are the metrics of the Recovery Time Actual (RTA) and the Recovery Point Actual (RPA). These are the levels at which a process can actually be recovered at the organization. If RTOs and RPOs are the dream, RTAs and RPAs are the reality.

Typically, when the IT staff sets the RTOs and RPOs for various applications, they do so at random. They guesstimate what they think the RTOs and RPOs should be, based on their experience with the business units on a day-to-day basis. Or sometimes they’re based on a hunch regarding what is most sensitive and important.

The Difference a BIA Makes 

The gap between the recovery strategy of the IT department and the business continuity team emerges when management decides it is time to conduct a Business Impact Analysis (BIA).

At that time, the BC team goes to work systematically doing BIA interviews with stakeholders (including IT), identifying and weighting impact categories that will be used to measure the impact of a disruption.
Through analysis and collaboration, the business continuity management department arrives at an objective understanding of how the different processes rank in terms of how much damage would be caused to the vital interests of the company if the process was interrupted, as measured over different periods of time.

This analysis enables you to establish RTOs and RPOs for each critical process that have a demonstrable, rational connection to the well-being of the company, rather than just being guesswork. While doing the BIA, you should request the RTA from the IT department. They may not be that eager to share it with you. Sometimes if the figures are bad they are embarrassed by it, or they may fear repercussions for the less than perfect results they’ve managed to achieve with inadequate resources.

However, try to reassure them that it’s better for the company that the actual recovery capabilities be openly known. If the gaps between the goals in your business continuity plan and the reality of what you can do are known, you can work to correct them or make plans to allow for them.

The Issues That a BIA Can Cause 

The formal BIA is a sensitive subject with many IT departments. Often the IT department dislikes the BIA because it contradicts their findings and calls their judgment into question.

The formal BIA might also result in the IT department being asked to meet stringent new requirements in terms of RTOs and RPOs. This can lead to challenging new obligations and responsibilities, a responsibility that doesn’t always come with additional funding.

Sometimes the IT department will reject the results of the BIA out of hand.
If management does not come down firmly on the side of implementing the BIA-derived results, the matter can be allowed to slide, with potentially damaging results to the company. Even worse, in spite of the BC team’s best efforts to secure appropriate support ahead of time, sometimes management decides that they share IT’s skepticism of the BIA results.

As a business continuity professional, it’s clear to me that the BC team and the BCM process need to be the driver on the issue of setting recovery objectives.

The BC team has a high-altitude, company-wide view of the enterprise’s mission, priorities, and vulnerabilities. They are also the hub of a network of their colleagues across the company and in management.

That said, I’ve also known many companies where the IT department is happy to work with BC. And sometimes I have seen it happen that the plans devised by IT are more stringent than what is called for in the BIA.

It’s also important to remember that bringing the recovery objectives of the IT team in line with the BIA-derived objectives of the BC team is not something that happens overnight. It’s a process.
It’s not unusual for it to take a year, and the alignment might never be perfect. In my experience, the best approach is to be patient and persistent and take things one step at a time.

Fixing the Recovery Strategy Gaps With IT 

The best way for a BC professional to deal with any recovery strategy gap between IT and  BC team is to become a diplomat and teacher.

The business continuity team cannot make IT do anything it doesn’t want to. If management backs you up, then great. But it often happens that you have to persuade IT and management of the legitimacy of your analysis and conclusions and of its importance to the company.

I think it’s important to be considerate, respectful, and nonconfrontational. It helps to focus on persuasion and education. This is a lot easier to do if your work is rigorous and you know your stuff.

In addition to being a diplomat and teacher, it helps to become something of a lawyer. If you can make a tight, sound case explaining why your work and conclusions are well-founded and are important for protecting the company, backing it up with evidence, you’re more likely to get people to move in your direction.

Finally, never underestimate the value of having a strong relationship with your IT department t. If you can work together, you will be able to accomplish much more by combining your efforts to secure the support and resources you need.

Three Tips to Sync With IT 

Here are three things that you can do to help bring the recovery planning of your organization’s IT’s department in line with that of the business continuity management program and reduce the recovery strategy gaps.

1. Emphasize the need to have one set of ground rules (namely those derived through the logical analysis contained in the BIAs rather than through guesswork).
2. Hold nonconfrontational meetings with IT to discuss their current capabilities and what the BIAs call for and why.
3. Learn to build an objective business case that demonstrates the validity and importance of your conclusions regarding the RTOs and RPOs that are in the best interests of the company.

Unified Recovery Strategy Plans Using Software

Working with IT to have clear RTOs and RPOs, and ensuring that your company’s recovery strategies don’t have any gaps can be a long process. It’s also one that requires you to have a strong relationship with the IT team.

To help you organize your findings, share, and collaborate on them, you can use BCMMetrics. Our business continuity software was built by BC experts at MHA Consulting, and it helps you to do BIAs, ensure compliance, and build and share your plans, and much more!

Take a virtual tour of BCMMetrics to see how it works and how it can support you.