A lot of people use the terms disaster recovery (DR) and
business continuity (BC) plans interchangeably, but technically there is a
difference. A disaster recovery plan is more reactive while a business
continuity plan is more proactive.
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.
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.
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.
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.
The Bottom Line
Business Continuity is the first defense against a disaster
threatening the proper function of business. However, Disaster Recovery is a
must for any organization who cannot function without its vital business data.
Although Disaster Recovery is just a smaller part of the larger Business
Continuity umbrella, enterprise organizations would be wise to employ both
strategies for full protection. Disaster Recovery techniques are more
preventative in nature than continuity tools, which are typically used to
maintain smooth business operations.
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."
