Designing and/or updating business continuity and disaster recovery (BCDR) plans and processes is not necessarily anyone’s favorite task. It’s complex, cumbersome, somewhat nebulous, and requires a lot of different parties to be involved.
If you want to know where to get started, check out our disaster recovery series, which walks you through the steps and important considerations (including some more advice on how to talk to management about your plan).
Each organization’s commitment to a BCDR plan varies. The more you could stand to lose in the face of an outage or disaster, the more involved your BCDR plan should be. However, this isn’t always the case and we’ve seen lots of organizations brought to their knees by a disastrous event before any plan was ever created and approved.
If you are writing or retooling your BCDR plan, you know that defining the tolerable length of time it takes to get back up and running – known as recovery time objective (RTO) – and how far back in time in terms of your data you can feasibly go back – known as recovery point objective (RPO) — is usually one of the first steps. Unfortunately, these aren’t just numbers you can pull out of thin air; they require a bit of business intelligence and strategy.
BCDR Is a Business Decision, Not an IT Decision
In other words, in order to lay out what your organization can conceivably tolerate in terms of downtime and data loss, you’ll need to collaborate with the muckety mucks upstairs. Some may even term this a Business Impact Analysis, which aims to predict the consequences of disruption, like financial or reputation loss, while identifying the most critical business functions. For example, if you are an ecommerce company, how much in sales revenue might you be out for each minute your web server is down? Or, even more seriously, if you’re a healthcare organization, will people’s lives be at stake if you’re down?
As the IT expert, you know technically what’s required, and that there are certain contingencies. And typically, the lower your recovery time objective and/or your recovery point objective, the more costly and involved your BCDR solution is going to be. This is where you will have to work with leadership to balance the expense and the level of risk they’re willing to accept.
It is in your best interest, IT department, to get leadership’s written approval of your BCDR plan ahead of time.
Communication is Key
Recovering from a disaster on its own is stressful — add on top of that a bunch of fuming C-levels with the absolute power to fire you in one fell swoop breathing down your neck and you’ve got an extremely difficult situation to manage. Having planned and communicated the terms of your BCDR plan to them ahead of time may prevent some of this.
So how do you present this in a productive way to your organization’s leadership? When doing your Business Impact Analysis, break down your business functions in terms of the systems and applications and walk through them (bearing in mind that their time and attention is limited, so be prepared and organized). Remind them what systems rely on each other, like if your mail server is critical, so should your Active Directory be. Bring testimonies from the stakeholders for each system or application, like what accountants may say about their bookkeeping software or payroll software being down. Is it tolerable to pay your employees late?
How to Get the Word Out
You will also want to lay out a communication plan, both for internal purposes and externally, especially if loss of reputation is defined as a risk. When it comes to communicating with the corner offices about the progress being made on restoring after a disaster, lay out those communication channels in your BCDR plan. Having to update the CEO every 15 minutes can really cut into the progress you can be making on the actual work. Assign a liaison to communicate up the chain and make it clear who everyone’s internal point of contact is.
You may find a need to communicate with the public or law enforcement or governmental agencies regarding the disaster. Designate one spokesperson, and come up with a plan for crafting that message. For example, if you’re a small town bank and you tell your customers your systems are down and won’t be back up for a few days, they may not trust you with their money anymore. If your reputation is key to your organization’s success, your leadership team must consider how to address the public in the face of a disaster or disruption.
Stay on Top of It
Lots of pieces and parts make up your BCDR plan, and it won’t be stagnant either. These things can change, and it should all be reviewed and tested periodically. How often may depend on what level of priority your BCDR is to your organization. New risks and threats can crop up, like a new type of malware, or your environment’s composition may change – hello, Cloud – and your processes will need to be rewritten accordingly.
This is all to say that your BCDR plan cannot be created by IT alone. Get support and buy-in from upstairs management, whether it be to approve additional expenditures on the technology you need to make it happen or as a CYA for if it all hits the fan.