Developing your business continuity plan

This article provides guidance on developing a business continuity plan that takes Microsoft 365 dependencies into account. Here, we recommend methods for analyzing your business functions and identifying the ones that depend on Microsoft 365 services. You perform this analysis with the anticipation that there might be service failures and that you need to prepare for those possibilities.

Broadly speaking, business continuity planning involves four aspects: assessment, planning, capability validation, and communication and coordination.

Assessment

First, identify the business functions in your organization and the services and processes that support them. This step includes completing a business impact analysis, where you rank each business function according to how critical it is and identify the processes and services that each one depends on. Here's a sample table you can refer to help you get started with your own assessment.

Sample Business Impact Assessment (BIA)

This is a BIA document for name of the service, system, process, or function

Planning

Next, look across business processes to see where any cascading dependency relationships exist. Based on the outcome, prioritize and form resiliency strategies, and standard operating procedures supporting your strategies.

You can use Microsoft Service Map to help you with this mapping. Microsoft Service Map automatically discovers application components on Windows and Linux systems and maps all TCP dependencies, identifies connections, and remote third-party systems that the app depends on. It also maps dependencies to areas of your network that are traditionally dark, such as Active Directory.

Here's a sample Dependency Analysis (DA) you can start from. In your DA, identify and examine the process dependencies. Make sure you include people, suppliers, customers, partnerships, and facilities. Use the data from this analysis to identify gaps between the recovery requirements of a process and the recovery capabilities of supporting dependencies.

Capability validation

Once you have inventoried your business processes and mapped out relationships to other processes and technologies, build validation scenarios for all the processes. Figure out how you're going to validate your business process continuity plans. You might find that some processes are more important than others. Prioritize those processes. Don't forget that regularly training employees on incident response and continuity measures is important once the plan is established. Use post-incident reviews to enhance your resiliency strategies by incorporating learnings from each validation or test.

Incident coordination and communication

During a service incident, normal communications channels might be impacted or degraded. Prearrange alternatives to help your organization stay connected during an incident. It's critical that you establish communication channels, vet them for security and compliance, and train users on their use before a disruption. Failing from a known state to another known state is far preferable to users coming up with ad-hoc, unknown solutions in the middle of a crisis.

At Microsoft, each service team establishes internal alternative communication channels to help coordinate when normal communications channels aren't available. These alternatives include backup telephony and audio-conferencing solutions, Viva Engage groups, Teams groups, internal Service Health Dashboards, and internal Incident Management software.

During your BIA and DA, map critical processes and the technologies or services they depend on. Pay special attention to communication during this phase of planning and think of alternatives. Here are some examples.

• If email is your primary method of keeping your users and stakeholders informed, and your email service is degraded or unavailable, use another service such as Microsoft Teams, Viva Engage, or another third-party service as a backup. The key is to establish these alternatives beforehand and train your users on where to go. A Viva Engage thread isn't useful if no one knows it exists or if no one has it bookmarked.
• If your internal Incident Management processes rely on voice communications to coordinate your responses, establish an alternative telephony solution for use during a crisis. This solution doesn't need to have full parity with your primary service but should provide the minimum level of collaboration to coordinate your Business Continuity and Incident Management teams. Additionally, asking users to publish their mobile phone numbers in your Global Address List can provide an extra layer of backup communication in extreme cases.
• You might want to create a custom service health dashboard, or other such site, which can provide status updates during an incident. Training users where to go for information beforehand helps reduce unnecessary calls to help desk and instills confidence in your user base that the situation is being handled quickly and efficiently. Use the O365 Service Communications API to tie this information into Microsoft 365 for an even greater level of visibility.
• It's critical that the location of your Business Continuity Plans and Standard Operating Procedures is well known. Maintain online and offline copies of critical documentation, such as with SharePoint or OneDrive configured for automatic sync to local devices. For Service/Network Operations Centers and other similar teams that are critical for recovery, you might also want to keep hard copies available to be used in case event of an emergency.

Know your external points of integration

Regardless of business model, every company has points of integration with their customers, partners, and vendors. The business value supply chain is built on integration with external entities. Improving business continuity for service disruptions requires consideration and protection of each point of integration.
As you analyze your supply chain, consider external communications in the same way you analyze internal communications. Do your customers rely on your Exchange Online servers as the only method of contacting you? Have you established and made your suppliers aware of alternative communication methods, in the event uptime is impacted? Here's a sample table that suggests how to organize your thinking.