Business Continuity and Disaster Recovery known as BCDR is a defined process of executable procedures and policies to remain operational in the event of technical disruption.  Disruptions could be physical (power, internet or infrastructure loss), geopolitical changes or even in recent months a global pandemic.  Inside of core set of best practices of a BCDR resides the strategy for changes to the plan to keep an organization operational, customers supported, and employees empowered to continued supporting the business.


Planning for these unforeseen changes to the business is not a new concept however as more applications and workflow leaves the corporate WAN for cloud native environments, C-level executives must keep the business continuity plan updated regularly.  If you imagine the amount of SaaS tools added into an organization both from a standard best practice (i.e. IT approves of the license) to unregulated shadow IT deployments which seem inconsequential but are solving business process that does go unaccounted for, it could be disaster


Most organizations dislike or downright loath the thought of regularly keeping their BCDR plan updated and possibly tested on a regular basis.  Dev wants to build, not think about the possible future outage which may never happen due to the redundance already in place.  Conversely, the Finance organization who might have minimal “tech” knowledge to start with, now unsure how to perform their regular tasks and how to achieve it from a “remote” location or tools not sued in a decade?


Organizations must look at their culture to build a true and functional plan for a disaster.  Often, we are asked what the difference between a Disaster Recovery Plan and BCDR?


Advantages of a BCDR

A BCDR plan helps to alleviate disruption in a time of need shielding an organization from the event, minimize financial loss and keep orderly workstreams operational.  What should be included in a business continuity and disaster recovery plan?

  1. Jumpstart operations quickly with everyone involved understanding their role.
  2. Reduce customer and financial loss as much as possible.
  3. Maintain compliance depending on the industry an organization must follow, HIPAA, SOX, etc.


A BCDR Plan involves the following:

  1. BCDR Team:Identifying key roles and members of the entire organization who have a role in the event of an impact to business.  Don’t forget about the physical areas outside of your cloud applications such as physical office, hardware, etc.
  2. Business Impact Analysis (BIA) – A deep analysis of potential threats and how they could impact the business — usually described in terms of cost to the business. The BIA identifies the most critical business functions that you need to protect and restore quickly.  There
  3. Infrastructure & Resource Preparedness – Outline key network/WAN services which should include connecting Cloud and Unified Communications.  How will these services alternatively operate, who will support them and how?
  4. Testing:  The best plans sometimes fail if they never have a chance for a trial run to prepare real-world scenarios.  Even working on small things such as employee productivity with remote tools is paramount to assemble teams together quickly.

Conversly, planning for disaster recovery is slightly different as the KPIs look more to RTO and RPO.


Cloud BCDR Planning


Looking at a Cloud example, organizations should leverage what the Gartner leaders in IaaS have built, advised and launched for thousands of customers already in a BCDR process.  Let’s take Microsoft Azure as an example.  If your IT team is sitting in a conference room or collaboration environment meeting to discuss how to build a BCDR plan for Azure and you do not have Microsoft riding shotgun with you, the battle is already lost.  Sure, most organizations will understand the need to rely on their Azure Solutions Architect to help mitigate an Azure environment loss.


However, it should go deeper than that so you can teach everyone within the team and org even at a macro level what this means for the business.  If your IT team conveys to Product how your BCDR is built who passes it to the Sales Teams (maybe slightly watered down less technically, no offense Sales!) that is a great way to communicate with current and future customers.  Your clients equally want to know if they put the trust in your application, you know what to do in the event of a disruption.  Sounds trivial, however 20% of all organizations do not articulate their BCDR plan to their client base well.  This does not mean you offer the security codes to the castle, but you can ease concerns about your ability to weather a storm because your competitors will as well!



BCDR for Azure Cloud:

When cloud teams look to fulfill their business continuity with public cloud such as Azure, it’s more than just having another region or option to route requests to.  Outside of your internal RTO/RPO process and the makeup of human capital of dev, SecOps


One of the benefits in your continuity planning with Azure is regional pairs.  Regional Azure pairs which is a set of colocation facilities withing a low-latency network to keep absolute peak uptime.  This setup has at least one Azure regional pair within the same geography which helps for maintenance and software updates affording the topology to only have one facility impacted at a time due to the pair.

Advantages of Azure Paired Regions

Separation – Microsoft suggests at a minimum 300 miles of distance between datacenters with respect to a regional pair.  However, there are issues in some regions of achieving this minimum distance as the earth was not designed for cloud!  If you look back to the original business continuity planning with N+1 redundancy, colocation instances were often a 1000+ miles away.  It wasn’t uncommon for US based organizations to select the east and west coast for Datacenter redundancy or the UK and APAC from an international scale.  Generally, IT teams were planning their BCDR around power and internet outages primarily and physical or geopolitical issues secondary.

Regional order to recover:  If a large wide-scale outage occurs with Azure, the return of a region is prioritized out of every pair.  The advantage is that organizations who have deployed within regions are guaranteed to have one of the regions recovered with high order of MTTR.  So, if your environment deployed across regions which are not paired, you could have a hot potato recovery without a true schema based on your initial deployment.  Said another way, you could have gambled incorrectly, and the last regions chosen are delaying your recovery.

Sequential updates – Planned maintenance windows for Azure affords updates to be administered to paired regions reducing downtime.  If an issue occurs, it does not hit the pair together.

Data residency – A region resides within the same geography as its pair (with the exception of Brazil South) to meet data residency requirements for tax and law enforcement jurisdiction purposes.

(some example, not all, Azure Regional Pairs Globally)


In the event of a disruption, businesses must be able to quickly recover mission-critical data, restore IT systems and smoothly resume operations. A robust business continuity and disaster recovery (BCDR) plan is the key to having confidence in your ability to recover quickly with minimal disruption to the business.

The next time you find yourself dusting off the BCDR plan, don’t forget the last piece in all of this….Security.  Don’t let your preparedness forget about the ability to prevent & mitigate threats to the organization.