Difference between DR and BCP and other stories
Others
Business Continuity Planning (BCP) and Disaster Recovery (DR) are used together so often that people often begin to forget that there is a difference between the two. The idea of this post is to try to define these terms from a practical point of view. As I like to mention in all my posts, this blog is about practical information security...
In day to day lingo, BCP refers to plans about how a business should plan for continuing in case of a disaster. DR refers to how the IT (information technology) should recover in case of a disaster. It may sound a bit weird, but after the first 500 times, you sort of start getting used to it and start preaching it as well. I think these definitions must have started off as a practical joke played by mischievous IT staff on their organization, or maybe it was some consultant trying to wiggle out of a situation where he forgot to make a BCP for IT.
“Oh, I have given you a BCP. For IT, what you really need is a DR. Should I send you a bill for that as well?”
The definitions are so ingrained in daily (consultant) life that we now refer to DR as IT-DR. You will hear wise sounding words like, “We have a DR in place, but not a BCP” If you want to stick to pop culture, you can stop reading now. You know all that you need to know about the difference between DR and BCP. If you are interested in analyzing the words further, read on.
If you think practically, a BCP is a plan that allows a business to plan in advance what it needs to do to ensure that its key products and services continue to be delivered (technicality: at a predefined level) in case of a disaster, while a DR allows a business to plan what needs to be done immediately after a disaster to recover from the event. So, a BCP tells your business the steps to be taken to continue its key product and services, while a DR tells your business the steps to be taken to recover post an incident.
Your impact analysis, your business continuity strategy and business continuity plans are a part of BCP. Your incident response, emergency response, damage assessment, evacuation plans, etc. are all a part of DR. It makes sense to divide your planning into two parts
- Planning to continue your business operations and
- Planning to recover from disaster situations
If you use these definitions of BCP and DR, you would probably end up having a practical and effective BCMS for your organisation.
As usual, the story is never simple.
Let us assume a practical scenario in an organization, where the IT team is the one that is really worried about data backup and recovery. No one else gives two hoots. Roughly translated, it means the others will run to IT in case of disaster and say: “What do you mean you cannot recover it. I assumed it was being backed up.”
So, the IT team takes it upon itself to build a business continuity plan. The problem, however, is that they will receive no data from business about esoteric terms like ‘criticality of activities supporting key products and services’. They have to do the next best thing. Ask the business “What will happen if this application crashes and is not recoverable?” This becomes the applications RTO. They ask “What will happen if we lose data for 1 min, 1 hour, 1 day, 1 week, 1 year, etc. progressively (until they see the business users pupils dilate). This becomes their RPO. Armed with this data they create a plan to recover these key applications and services (provided and supported by IT) within the RTO and RPO. Calling this a business continuity plan is not the right thing to do, hence the IT calls it a DR plan. It is then free to make statements like “We have a DR, but not a BCP” to the half-read consultant and get away by showing this document as a BCP to the untrained auditor (believe me there are plenty of those around). The auditor sees some calculation of RTO and RPO and accepts the plan as a BCP, thus obfuscating the definitions further.
Practical advice: Plan in two parts as above. A plan to continue business processes (Including support processes like IT) and a plan to respond to and recover from incidents (Emergency Management) and you should be good. If you are in IT and the business is not responding for a BCMS, use the tactic shown above to have a minimalist practical plan.
