Sometimes problems result when the IT department does its own recovery planning then BC 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.
Related on BCMMETRICS: How to Build a Good Relationship Between the BCM Program and the IT Department
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. 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.
In creating their recovery plans, the IT department typically establishes Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for each system or application.
RTOs, as you’ll recall, 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 a measure of time (such as 8 hours or 24 hours) expressing how long a period of transactions the organization is willing to accept the loss of in the event of an outage.
Typically, when the IT staff sets the RTOs and RPOs for various applications, they do so essentially randomly. 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 just a hunch regarding what is most sensitive and important.
The gap between the recovery strategy of the IT department and the BC 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 consulting stakeholders (including IT) and identifying and weighting impact categories that will be used to measure the impact of a disruption. Through analysis and collaboration, the BC 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 the BC team 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.
The disaster recovery strategy gap is what happens when there’s a difference between the RTOs and RPOs estimated by the IT team and those arrived at through careful analysis by the BC team.
Usually (but not always), the BC team’s objectives are more stringent.
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 decide that they share IT’s skepticism of the BIA results.
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.
I talked previously about RTOs and RPOs. 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.
The IT department typically has this information, but they might 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.
It’s better for the company that the actual recovery capabilities be openly known. If the gaps between your goals and the reality of what you can do are known, you can work to correct them or make plans to allow for them.
To me as a BC professional, it is obvious that the BC team and the BC 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.
The IT department, in contrast, does not always have this perspective or information. They tend to be much too be absorbed at the granular level in their servers and other equipment to have a firm grasp on the bigger picture.
The best way for a BC professional to deal with any recovery strategy gap that is uncovered between the recovery planning of the IT department and that of the BC team is to become a diplomat and teacher.
The BC 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 your IT department as an ally. You will be able to accomplish much more by combining your efforts to secure the support and resources you need.
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. I think the best approach is to be patient and persistent and take things one step at a time.
Here are three things that you as a BC professional can do to help bring the recovery planning of your organization’s IT’s department in line with that of the BC program: