Does Your IT Department Have a Disaster Recovery Plan? Four Reasons that Could be a Big Problem

During challenging times, we hope we have the right tools in place to see us through. A key piece for any business is having the right plans in place in case of a disaster. Unfortunately, many businesses find themselves at risk because:

• • The company does not have a disaster recovery plan;

  • A disaster plan was created but not kept up to date; or

  • The disaster plan exists but does not get tested regularly

However, there is another scenario that is at least as common as these which is putting companies at risk all over the globe. The problem is that only the IT Department has a Disaster Recovery Plan.

If you are an IT professional in a mature and healthy IT department, then you know the routine. A Disaster Recovery Plan (DRP) was created, which involved establishing off-campus hot sites, remote storage and recovery of data and systems, established or reserved communications channels to bypass network disruptions and more. Your department is regularly maintaining lists of systems and building them into your recovery plans. You are, at least once a year, running a drill of that plan to validate your ability to standup at your remote site and recover back. Your developers are building resiliency into their applications by avoiding unnecessary hardcoded information. IT folks know the routine. But…

         If Disaster Recovery is happening exclusively within the IT department, your business is fundamentally at risk.

A disaster situation is an existential risk to the business, not just the IT department. A disaster recovery plan is about maintaining function for the business, not the IT department. So how can it be that such a plan is developed and executed by the IT department alone and not the business? And yet, that is what so many of us do.

Many DRP’s ultimately fail for reasons that are solved by having the business closely involved in the plan’s development. Think of some of the common failures in disaster scenarios where the DRP execution goes exactly as planned:

• • Enterprise applications are stood up but essential data outside of those systems, sometimes on workstations, is unavailable.
  • Everything in the DRP is stood up effectively, but IT is unaware of newer, critical systems.
  • Access to cloud-based systems not normally directly affected by the disaster is unavailable.
  • IT takes too long standing up systems because the priorities were not structured to meet the needs of the business.
  • IT is unable to respond to changing needs during the process because communication with the business was not built into the DRP.

If you are in the situation where you have created a DRP exclusively within IT, or if you are working on creating or improving your DRP, stop now and address this most fundamental risk. First, make sure that business stakeholders are included in all discussions. In a disaster scenario, choices will be made, and some things will be prioritized over others. IT is not equipped to make those decisions. Or worse, IT is simply trying to restore everything, and priority data and systems are delayed. So, make sure that critical stakeholders are informing, in advance as part of the DRP, what those priorities are, as well as who should be part of the decision making when decisions arise during a disaster situation.

This leads to the second point: business leaders are the ones who should be making the central decisions around disaster recovery, starting with when to invoke the DRP in the first place. Those leaders cannot make those decisions if they were not a part of designing the plan and establishing the criteria for when the plan should be invoked. Once involved in those decisions and deliberations, those key business leaders will see the need to be involved in the ongoing decisions of the plan itself.

Let’s also not forget that in a disaster state, the business may make different decisions than during regular operations. Quite possibly, users and departments may determine that there are functions and activities that they do not need or for which there are alternatives during a disaster and do not need to be replicated at the DR site. IT can overspend in both resources and efforts if the rest of the business is not advising on what is needed to be available in a disaster situation.

Finally, having the IT department walk through the plan is not enough. In a disaster scenario, users are likely to be disrupted in their business operations as well. Are they prepared for accessing systems differently? Are they prepared to respond when some systems are available but not others? Imagine that IT has restored systems flawlessly according to plans, but if end users are not prepared to operate under the conditions of the plan, business functions may grind to a halt anyway.

Why would a security company be telling you all this? Because security is fundamentally about risk. Anyone can sell you a firewall, but as an independent reseller not associated with any one product, we understand that the decisions you make around your security products are at least as important as the products themselves. Having the right DRP is essential to having the right security solutions in place. A good security partner wants to make sure that all of your risk is effectively addressed. Any risks that can be avoided completely are not only cheaper for you, but they also make the necessary precautions on your network even stronger.

There is no question that IT will be doing a ton of work to have an effective DRP and that IT staff are critical to making that plan viable and if needed executing the plan. However, in the end, your business should have a disaster plan, not your IT department.