When it comes to their application in the business world, the terms “business continuity” and “disaster recovery” seem self-explanatory. So why is there so much confusion between the two?
Business continuity (BC) is, simply put, enabling a business to continue operations. Disaster recovery (DR) is just that: recovering from a disaster. It’s easy to see why many people use these terms interchangeably. Both are about not letting an event disrupt business operations for any longer than necessary. But it’s important to understand that BC and DR, while similar, are really two different things. Both are vital to businesses of all sizes.
BC Keeps Business Going
One of the key differentiators between BC and DR is that BC is business-centric. DR is data-centric.
BC entails a comprehensive strategy that will allow your business to function during and after a disruptive occurs. Note the word “during,” because ideally, you want – and need – your business to continue operating normally at all times. It’s important to keep in mind that a disruptive event doesn’t necessarily have to be a natural disaster like an earthquake or flood. It could be an employee strike or flu outbreak that keeps half your staff at home. It could be an electrical outage or a cyber-attack.
That means that a BC plan has to take into account any number of scenarios and include strategies for keeping operations going. This might entail moving operations to a temporary location — with all the logistics of doing so spelled out in the plan. It might require key employees to work from home — in which case the plan should specify the resources needed to make that happen, which employees will be involved and how communications and workflows will occur.
Most businesses rely heavily on data for their day-to-day operations, so a BC plan will typically require that data be accessible with little or no downtime when a failure or disaster happens. Ensuring that is the case usually involves a combination of hardware and software technologies that keep data in two different places at the same time. For example, if a power outage takes out your on-site production servers, your data and application “fail over” to another system located elsewhere. If all goes as planned, end users won’t even know a disruptive event occurred.
However, BC goes far beyond the recovery of data. It also focuses on what data and applications are most important for keeping your business running. Sure, all data and applications are important but with BC, your most essential data and applications get first priority. That’s where factors such as recovery time come into play. Among the questions that need to be addressed:
- What needs to be recovered first in order to continue your operations?
- What do your customers need to be satisfied and confident of in your stability?
- What do your business partners require to continue order fulfillment, delivery or other tasks?
- What do your vendors need so they can continue to work with you?
Determining the most important criteria for keeping your business operating – and putting plans in place to make sure it does – it’s the crux of BC.
DR: Get Your Data Back
DR is a subset of BC. In terms of IT, it is focused on getting essential data and systems back up and running after a disruptive event. Note that the emphasis here is on “after” the event. The basic idea is to save your data somewhere so that you can recover it after a disaster.
DR can be as simple as ensuring your data is backed up remotely even if you can’t access or utilize it right away. As with BC, a DR plan may note that some data is deemed more important than other data. That data gets recovered first. The speed at which it is recovered also gets noted in a DR plan. Some data may need to be immediately recovered; other data can wait days or even weeks. Recovery time needs will influence the tactics used for data recovery —and there are many recovery tactics, each with its own advantages and disadvantages. Many companies are finding that disaster recovery as a service (DRaaS) solutions that utilize cloud resources serve their DR needs well.
Just because you have a plan for recovering data after a disruptive event doesn’t mean your work is done. You have to test your DR plan — again and again. You can’t really recover data if your DR plan doesn’t work….and you won’t know if it works until you test it. The time to test it, obviously, is not when a disaster hits. You not only could fail at disaster recovery and possibly business continuity. You could likely be out of a job.
Are You Ready?
Regardless of their definitions, BC and DR are both essential to all organizations if they expect to stay viable. Knowing the differences between the two is important, but creating and implementing them is what really counts. It’s also important to keep in mind that for BC and DR to be effective, they need to be ingrained in the culture of your organization. Companies put a great deal of time into training, migration, and rollout when a new application is brought on, but it’s early on – at the design phase – when BC/DR needs to be considered. Retrofitting a BC/DR plan after the fact is inviting risk.