├── CODE_OF_CONDUCT.md ├── LICENSE ├── README.md ├── SECURITY.md ├── SUPPORT.md ├── getting-started.md └── media ├── Business_Continuity-Minimum_Business_Continuity_Objective.png ├── Implement-Impact_Scope.png ├── Prepare-Criticality_Definitions.png ├── RACI-legend.png ├── application-requirements.png ├── architecture-continuity-design.png ├── autosave.png ├── business-commitment-model-availability-requirements.png ├── business-commitment-model-collapsed.png ├── business-commitment-model-deployment-requirements.png ├── business-commitment-model-general-requirements.png ├── business-commitment-model-monitoring-requirements.png ├── business-commitment-model-recoverability-requirements.png ├── business-commitment-model-security-requirements.png ├── business-commitment-model-testing-requirements.png ├── business-commitment-requirements.png ├── business-risk-calculation.png ├── category-filter-off.png ├── category-filter-on.png ├── collapse-button.png ├── expand-button.png ├── glossary-button.png ├── home-button.png ├── navigation-buttons.png ├── personas-button.png ├── references-button.png └── reliability-trade-offs-footnote.png /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Microsoft Open Source Code of Conduct 2 | 3 | This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). 4 | 5 | Resources: 6 | 7 | - [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/) 8 | - [Microsoft Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) 9 | - Contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with questions or concerns 10 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) Microsoft Corporation. 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Introducing the Azure Business Continuity Guide 2 | 3 | > [!IMPORTANT] 4 | > It is recommended to open the ABC Guide Excel Workbook in Desktop View for the best experience! 5 | 6 | **Download Latest Release:** [Azure Business Continuity Guide v0.55](https://github.com/Azure/BusinessContinuityGuide/releases/download/v0.55/ABCG.v0.55.xlsx) 7 | 8 | 📢 *For a brief overview of how the ABC Guide is structured and how to navigate the content, please see the **[Getting Started](getting-started.md)** page.* 9 | 10 | ## What is the Azure Business Continuity Guide (ABC Guide)? 11 | 12 | The Azure Business Continuity Guide provides a comprehensive set of recommendations to help customers define what BCDR looks like for their applications. Often a customer will ask us for help with their business continuity and disaster recovery plans. Sometimes, the customer simply needs a structured approach to protect one application in Microsoft Azure. In other cases, they have a portfolio of many applications in a hybrid environment that might never have had a good solution to protect everything with a single BCDR framework. In addition, Microsoft Azure offers a variety of services and features to help customers achieve high availability, disaster recovery, and backup for their applications and data. However, planning and implementing a solid strategy can be challenging, especially for complex environments. 13 | 14 | That's why we created the Azure Business Continuity Guide. This guide available to all customers who are adopting BCDR solutions at any point in their journey. Let's take a tour! 15 | 16 | ## What's included in the Azure Business Continuity Guide? 17 | 18 | The ABC Guide is a comprehensive and practical resource that helps you design and execute a BCDR plan for your Azure resources. The ABC Guide is published as an [Excel workbook](https://github.com/Azure/BusinessContinuityGuide/releases/download/v0.55/ABCG.v0.55.xlsx), which you can download and customize for your own needs. The ABC Guide contains a few different elements: 19 | 20 | - Select documentation covering the important concepts of BCDR on Microsoft Azure 21 | - Recommended templates to help define your BCDR requirements in a consistent way 22 | - Example assessments, plans and checklists for customers to consider in their own BCDR implementation 23 | 24 | The workbook is divided into 3 distinct phases across the BCDR journey, from readiness to application continuity all the way through business continuity. 25 | 26 | ## Phase 1: Prepare 27 | 28 | In this phase we review fundamental concepts to answer the question, "What is the Microsoft Azure BCDR Solution?" This includes documentation on platform features, the shared responsibility model, design patterns and reliability trade-offs (ex. cost) just to name a few of the concepts. We also provide a set of templates that compose a structured methodology for assessing the business continuity of existing applications and facilitating the design of new ones. This approach can improve the overall adoption of BCDR and lead to more consistent planning. 29 | 30 | ![Phase 1 - Criticality Definitions](media/Prepare-Criticality_Definitions.png) 31 | 32 | *For more information on this phase, head over to [Getting Started - Phase 1: Prepare](getting-started.md#phase-1-prepare)* 33 | 34 | ## Phase 2: Application Continuity 35 | 36 | From this point we have an iterative set of activities that should be followed for each independent application that needs a continuity plan. 37 | 38 | ### Assess 39 | 40 | Starting with an assessment of the application to determine the requirements and architectural decisions. This should be guided by the business case for each application, which includes data from business impact assessments, service mapping and fault tree analysis among other included examples. Once you have validated your requirements in this way, any gaps in the implementation or design can be addressed during the implement activity. 41 | 42 | ### Implement 43 | 44 | In this activity we develop our response plan for the application that describes the types of events, their scope of impact and the appropriate response (and preparation) that should take place. For example, if a disaster impacts a single Availability Zone within a region we define the automated and/or manual failover activities that need to occur to recover. 45 | 46 | ![Phase 2 - Impact Scope](media/Implement-Impact_Scope.png) 47 | 48 | Next, we recommend documenting the architectural considerations for each service or component that affects the application's resiliency. This can be defined as a list of requirements with details on how the components meet requirements (i.e. use of availability zones or paired regions). The result is a robust document describing how the application should be implemented to meet the resiliency requirements. Any gaps or unmet requirements should be included so that your contingency planning can account for these items as needed. 49 | 50 | Before moving to the next activity, we recommend customers assign roles and responsibilities to the recovery team that will be involved in the BCDR testing. A RACI template is included to help you consistently plan your teams across all applications. 51 | 52 | ### Test 53 | 54 | Without regular testing, even the most robust plan can fail when it's needed most. Testing activities should include a failover plan, recovery plan, acceptance testing, outage communications and a regular review (and update) of all documents that support your application continuity plan. A test summary example is included in the ABC Guide to help track testing activities and results over time. Don't forget to include appropriate communication plans during tests as well. As you review your testing outcomes, look for ways to improve your plans to reduce costs, recovery times and efficiency. 55 | 56 | *For more information on this phase, head over to [Getting Started - Phase 2: Application Continuity](getting-started.md#phase-2-application-continuity)* 57 | 58 | ## Phase 3: Business Continuity 59 | 60 | For the final phase of the ABC Guide, we focus on minimum business continuity objective (MBCO) planning and ongoing management. This involves combining and coordinating the individual application continuity plans for all critical applications. Your organization should define the risks that are most likely to impact the business (i.e. natural disasters, cyberattacks, power outages, etc). We provide an example list of considerations to include from people and processes to validation and testing. The details from your risk assessment (and the outcomes of all the other activities up to this point) should help define the recovery order of your application portfolio. You should also identify any business critical events for your organization to ensure that BCDR testing does not cause disruption during these times. 61 | 62 | ![Phase 3 - Application Recovery Order](media/Business_Continuity-Minimum_Business_Continuity_Objective.png) 63 | 64 | *For more information on this phase, head over to [Getting Started - Phase 3: Business Continuity](getting-started.md#phase-3-business-continuity)* 65 | 66 | ## Get Started with the ABC Guide 67 | 68 | If you are ready to start, **[download the latest release](https://github.com/Azure/BusinessContinuityGuide/releases)** and then head over to the **[Getting Started](getting-started.md)** page to learn more about how to navigate the contents. 69 | 70 | 71 | ## Feedback 72 | The Azure Business Continuity Guide is a living document which we think our customers will value. Over time we plan to improve upon it based on your feedback. Please download a copy of the ABC Guide and let us know what you find useful, and what might make it even better for others! 73 | 74 | ## Contributing 75 | 76 | This project welcomes contributions and suggestions. Most contributions require you to agree to a 77 | Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us 78 | the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com. 79 | 80 | When you submit a pull request, a CLA bot will automatically determine whether you need to provide 81 | a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions 82 | provided by the bot. You will only need to do this once across all repos using our CLA. 83 | 84 | This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). 85 | For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or 86 | contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments. 87 | 88 | ## Trademarks 89 | 90 | This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft 91 | trademarks or logos is subject to and must follow 92 | [Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general). 93 | Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. 94 | Any use of third-party trademarks or logos are subject to those third-party's policies. 95 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## Security 4 | 5 | Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet), [Xamarin](https://github.com/xamarin), and [our GitHub organizations](https://opensource.microsoft.com/). 6 | 7 | If you believe you have found a security vulnerability in any Microsoft-owned repository that meets [Microsoft's definition of a security vulnerability](https://aka.ms/opensource/security/definition), please report it to us as described below. 8 | 9 | ## Reporting Security Issues 10 | 11 | **Please do not report security vulnerabilities through public GitHub issues.** 12 | 13 | Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://aka.ms/opensource/security/create-report). 14 | 15 | If you prefer to submit without logging in, send email to [secure@microsoft.com](mailto:secure@microsoft.com). If possible, encrypt your message with our PGP key; please download it from the [Microsoft Security Response Center PGP Key page](https://aka.ms/opensource/security/pgpkey). 16 | 17 | You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://aka.ms/opensource/security/msrc). 18 | 19 | Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue: 20 | 21 | * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.) 22 | * Full paths of source file(s) related to the manifestation of the issue 23 | * The location of the affected source code (tag/branch/commit or direct URL) 24 | * Any special configuration required to reproduce the issue 25 | * Step-by-step instructions to reproduce the issue 26 | * Proof-of-concept or exploit code (if possible) 27 | * Impact of the issue, including how an attacker might exploit the issue 28 | 29 | This information will help us triage your report more quickly. 30 | 31 | If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://aka.ms/opensource/security/bounty) page for more details about our active programs. 32 | 33 | ## Preferred Languages 34 | 35 | We prefer all communications to be in English. 36 | 37 | ## Policy 38 | 39 | Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://aka.ms/opensource/security/cvd). 40 | 41 | 42 | -------------------------------------------------------------------------------- /SUPPORT.md: -------------------------------------------------------------------------------- 1 | # TODO: The maintainer of this repo has not yet edited this file 2 | 3 | **REPO OWNER**: Do you want Customer Service & Support (CSS) support for this product/project? 4 | 5 | - **No CSS support:** Fill out this template with information about how to file issues and get help. 6 | - **Yes CSS support:** Fill out an intake form at [aka.ms/onboardsupport](https://aka.ms/onboardsupport). CSS will work with/help you to determine next steps. 7 | - **Not sure?** Fill out an intake as though the answer were "Yes". CSS will help you decide. 8 | 9 | *Then remove this first heading from this SUPPORT.MD file before publishing your repo.* 10 | 11 | # Support 12 | 13 | ## How to file issues and get help 14 | 15 | This project uses GitHub Issues to track bugs and feature requests. Please search the existing 16 | issues before filing new issues to avoid duplicates. For new issues, file your bug or 17 | feature request as a new Issue. 18 | 19 | For help and questions about using this project, please **REPO MAINTAINER: INSERT INSTRUCTIONS HERE 20 | FOR HOW TO ENGAGE REPO OWNERS OR COMMUNITY FOR HELP. COULD BE A STACK OVERFLOW TAG OR OTHER 21 | CHANNEL. WHERE WILL YOU HELP PEOPLE?**. 22 | 23 | ## Microsoft Support Policy 24 | 25 | Support for this **PROJECT or PRODUCT** is limited to the resources listed above. 26 | -------------------------------------------------------------------------------- /getting-started.md: -------------------------------------------------------------------------------- 1 | # How to use the ABC Guide 2 | 3 | ## General Guidance 4 | 5 | **It is recommended to open the guide using the desktop version of Excel.** If the file is slow to open or navigate consider saving the guide to a location outside of OneDrive (or turn off AutoSave) since this will cause Excel to pause frequently when writing the file. 6 | 7 | ![Turn off AutoSave](media/autosave.png) 8 | 9 | ### Navigation 10 | 11 | Navigation Buttons 12 | 13 | In each page of the guide, you will find quick access navigation buttons at the top left. These buttons will take you to the main sections of the guide. 14 | 15 | Home ButtonNavigate to Business Continuity and Disaster Recovery Framework (Home) 16 | 17 | Personas ButtonNavigate to Personas: Business Continuity and Disaster Recovery by Role and Task 18 | 19 | Glossary ButtonNavigate to Glossary 20 | 21 | References ButtonNavigate to References 22 | 23 | ### Collapsible Sections 24 | 25 | Many of the pages include vertical sections (rows) or horizontal sections (columns) that have been collapsed or expanded by default. Look for the **[+]** and **[-]** buttons to expand or collapse sections. 26 | 27 | ![Collapse Button](media/collapse-button.png)Collapse this section 28 | 29 | ![Expand Button](media/expand-button.png)Expand this section 30 | 31 | ### Filters 32 | 33 | Some of the pages in the guide have built-in filters you can leverage by simply clicking on the desired button 34 | 35 | ![Category Filter On](media/category-filter-on.png)
36 | (Show items in the Availability, Deployment and General categories) 37 | 38 | ![Category Filter Off](media/category-filter-off.png)
39 | (Show only items in the General category) 40 | 41 | ### Footnotes 42 | 43 | Many of the templates and examples will include a list of footnotes at the bottom of the worksheets. When first viewing the guide it is a good idea to check the footnotes and become familiar with the details. It will help you understand the templates better. 44 | 45 | ### Other tips 46 | 47 | - Familiarize yourself with the sections of the guide and ensure you are using the latest version. For a high-level introduction you can refer back to the [read me](README.md) in this repo, which gives an overview of each phase of the planning process. 48 | - Be sure to review the Personas view to see how each role is involved (Application Owner, Architects, etc) and the steps in sequence they are responsible for in completing templates in the guide. 49 | 50 | --- 51 | 52 | ## Phase 1: Prepare 53 | 54 | ### Concepts 55 | 56 | Building a Business Continuity and Disaster Recovery (BCDR) strategy is crucial for ensuring the resilience of a business in the face of unforeseen disruptions or disasters. This section is composed of important documentation that we recommend reading as you prepare and look back to for reference in later phases. In order to be ready for BCDR strategy discussions, it is strongly suggested to be aware of the concepts in this section. 57 | 58 | The Prepare phase of the guide, as well as the other phases, includes numerous footnotes at the bottom of the "home" page. Be sure to look for the superscript numbers and review the footnotes to understand the details of the templates and examples. In some cases the footnotes will include a list of links that apply to a particular concept. For example, you will find 3 links related to Reliability Trade-Offs8: 59 | 60 | ![Reliability Trade-Offs Footnote](media/reliability-trade-offs-footnote.png) 61 | 62 | ### Supporting Artifacts 63 | 64 | In this section you will find the main templates to be used during the BCDR strategy discussion. These templates are meant to be used as a starting point and can be modified to fit your organization's needs. The templates included are as follows: 65 | 66 | #### Criticality Model (example) 67 | 68 | Enterprise organizations typically have a large application portfolio, but not all applications are of equal importance. Applications should be classified based on a [criticality scale](https://learn.microsoft.com/azure/cloud-adoption-framework/manage/considerations/criticality#criticality-scale). The table should be customized as needed. More suggestions and insights can be found in this article: 69 | 70 | **[Business criticality in cloud management](https://learn.microsoft.com/azure/cloud-adoption-framework/manage/considerations/criticality)** 71 | 72 | The Criticality Model is a table to be used to summarize the different levels of criticality and the associated business view (what’s going to be impacted in case of outages). Criticality should be identified and classified to direct investment of business continuity, monitoring, support, and other resources appropriately. It should be noted that certain business functions within applications may also be more critical than others. 73 | 74 | ![Criticality Model (example)](media/Prepare-Criticality_Definitions.png) 75 | 76 | Creating a criticality scale is the first important step in building the BCDR strategy. It helps in: 77 | 78 | - **Understanding priorities:** identify which system, processes or assets are essential for the operations and which ones are less critical (and allocate resources accordingly during a disaster). 79 | - **Allocating Resources:** ensure that the most critical elements are protected to a higher degree, considering that not all parts of the business can receive the same level of investment. 80 | - Facilitating quick, informed decisions during disasters. 81 | - Establishing a clear hierarchy of priorities for better response and recovery. 82 | 83 | #### Business Commitment Model 84 | 85 | When implementing a BCDR strategy it is important to build a detailed view of all the various aspects of business commitment required for each level of criticality. This is important to ensure that the plan is comprehensive and tailored to the specific needs of each application (according to its criticality level requirements). 86 | 87 | Defining business commitments for each application will facilitate a more efficient allocation of resources and a targeted response to potential disruptions, protecting the organization's operations and reputation. 88 | 89 | ***How to use this template*** 90 | 91 | For each Criticality Level, define if a specific aspect needs to be calculated or documented and which type of tests are required. Each aspect or test type should be labeled as "Required", "Not Required" or "As Required". 92 | 93 | ![Business Commitment Requirements Legend](media/business-commitment-requirements.png) 94 | 95 | When filling out the template, you can use the following cell values to indicate Required, Not Required or As Required: 96 | 97 | ✅(Required) = 1
98 | ❌(Not Required) = 2
99 | ➖(As Required) = 3 100 | 101 | 🔍**ATTENTION:** 102 | The Business Commitment Model template contains several vertical sections that are hidden by default. Be sure to expand the sections to see the full list of requirements. When all the sections are collapsed you can see the condensed topics in a "page size" view and the tables might look empty (as seen below). 103 | 104 | ![Business Commitment Model - Collapsed by Default](media/business-commitment-model-collapsed.png) 105 | 106 | As you can see, for each tier a criticality level is defined and the corresponding commitment level is indicated as follows: 107 | 108 | - Enhanced 109 | - Standard 110 | - Base 111 | - None 112 | 113 | ##### General Requirements 114 | 115 | The General requirements are expanded by default with all the considerations that need to be defined. This includes a list of the most important metrics to be defined and all details that needs to be discussed and documented. For example, an SLA of 99.999% being required for your mission critical applications. Mission critical would also have MTD (Maximum Tolerable Downtime), RPO and RTO optionally required. 116 | 117 | Some of the headings in general requirements refer to the need to prepare a specific document (and later in the BCDR strategy implementation, you can reuse examples or fill out templates provided within the ABC Guide – e.g. Business Impact Analysis, Contingency Plan…) 118 | 119 | ![Business Commitment Model - General Requirements](media/business-commitment-model-general-requirements.png) 120 | 121 | ##### Availability Requirements 122 | 123 | Availability refers to the degree to which a system or service is operational and accessible when needed. High availability is crucial for mission-critical applications as it minimizes downtime and ensures that users can access services without disruption. Achieving high availability involves redundancy, failover mechanisms, and proactive monitoring. 124 | 125 | The aim of the availability requirements is to help you keep track of how you plan to achieve Availability for the different aspects of all the applications belonging to the same criticality group. 126 | 127 | ![Business Commitment Model - Availability Requirements](media/business-commitment-model-availability-requirements.png) 128 | 129 | ##### Recoverability Requirements 130 | 131 | Recoverability is the ability to restore a system or service to its normal state after a disruption or failure. It encompasses the processes and technologies used to recover data, applications, and infrastructure. 132 | In a BCDR strategy, recoverability is essential for business continuity. It includes backup and restoration procedures, disaster recovery plans, and redundancy to minimize data loss and downtime. 133 | 134 | With the recoverability requirements you can keep track of the backup retention period required, the recovery architecture and if cross region replication needs to be implemented for a specific group of applications (with the same criticality level). 135 | 136 | ![Business Commitment Model - Recoverability Requirements](media/business-commitment-model-recoverability-requirements.png) 137 | 138 | ##### Deployment Requirements 139 | 140 | Deployment refers to the process of setting up and configuring software applications, infrastructure, and resources to make them operational. Deployment can be done manually or automated, such as through Infrastructure as Code (IaC). Discussing deployment methods is crucial for ensuring consistency and repeatability. Automation, like deploying resources and configurations from a code repository, can help in rapidly restoring systems to their pre-disruption state. 141 | 142 | Use the deployment requirements to define what will be implemented for each criticality level according to the business commitment. 143 | 144 | ![Business Commitment Model - Deployment Requirements](media/business-commitment-model-deployment-requirements.png) 145 | 146 | ##### Monitoring Requirements 147 | 148 | Monitoring involves continuous tracking and observation of the health, performance, and security of systems, applications, and infrastructure. It includes the collection of metrics and alerts for proactive issue detection. Monitoring is essential for identifying anomalies and taking proactive measures to maintain system health and performance. It's a key component for early detection of potential disruptions and planned maintenance. 149 | 150 | As it pertains to BCDR planning, you should define the monitoring requirements in detail to ensure that the right metrics and logs are available to support the recovery process. The alerting requirements should include the notification methods and severity thresholds for each criticality level. 151 | 152 | ![Business Commitment Model - Monitoring Requirements](media/business-commitment-model-monitoring-requirements.png) 153 | 154 | ##### Security Control Requirements 155 | 156 | Security control refers to measures and procedures put in place to safeguard data, systems, and infrastructure from threats and vulnerabilities. This includes access controls, encryption, firewall rules, and more. 157 | 158 | Discussing security controls is vital to prevent security breaches and data loss during and after disruptions. Security measures should be integrated into the BCDR strategy to protect business assets. For example, you may decide to require DDoS Protection for all critical applications, but leave it as optional for all other applications. 159 | 160 | ![Business Commitment Model - Security Control Requirements](media/business-commitment-model-security-requirements.png) 161 | 162 | ##### Validation and Testing Requirements 163 | 164 | Validation and testing processes should be considered for each criticality level. Keep in mind that the highest criticality levels are likely to require the highest level of testing and validation. Types of tests will vary by criticality level too. For example, a mission critical application may require failover testing, load testing, chaos testing, penetration testing and more. A non-critical application may only require failover testing. The frequency of testing should also be defined for each criticality level. 165 | 166 | ![Business Commitment Model - Validation and Testing Requirements](media/business-commitment-model-testing-requirements.png) 167 | 168 | #### Fault Model and Resilience Strategies (example) 169 | 170 | A useful preparation step that the organization should consider is to define common types of failures along with agreed resiliency strategies that should be implemented. Documenting types of failure with pre-approved mitigation strategies for each application criticality tier simplifies the tasks of creating business commitment models, performing application fault tree analysis and designing BCDR solutions. 171 | 172 | In the example you can see how recovery is planned for different types of scenarios/events to achieve resiliency. The guide provides a good example of what a typical fault model may look like for cloud-based workloads. It is recommended to use a similar approach to document the fault model for your organization. As an alternative, you may simply document the failure modes and mitigation strategies in a document similar to the following article: 173 | 174 | **[Failure mode analysis for Azure applications](https://learn.microsoft.com/azure/architecture/resiliency/failure-mode-analysis)** 175 | 176 | #### RACI 177 | 178 | The RACI table is a project management tool used to clarify roles and responsibilities for each task, activity or decision in a project. This template can be used to define both the application and organization BCDR roles and responsibilities. 179 | 180 | ![RACI Legend](media/RACI-legend.png) 181 | 182 | #### Application Requirements (template) 183 | 184 | A workshop (or series of workshops) with all relevant stakeholders is recommended to gather relevant information for each application. 185 | 186 | In the template you’ll find a list of requirements grouped by category. You can click on one of the categories listed to automatically filter the requirements listed in the table. You can use this template to assess each application's BCDR requirements for a new or existing system. The responses can then be used in the other templates in this guide. 187 | 188 | You will find an example of how this template can be used later in [Phase 2: Application Continuity](#requirements-and-architecture-decision-record). 189 | 190 | #### Test Plans (template) 191 | 192 | This template defines the types of tests that need to be considered for each application, depending on its criticality and the related business commitment. You will find built-in instructions for each of the mentioned test. A description of the type of test and links are also available in the same table. 193 | 194 | - Production Redeployment Test 195 | - Failover + Failback Test 196 | - Recovery Test 197 | - Unit Test 198 | - Smoke test 199 | - UI Test 200 | - Load Test 201 | - Stress Test 202 | - Performance Test 203 | - Chaos Test (also to validate impact on specific components like Entra ID or DNS outage) 204 | - Penetration Test 205 | - User acceptance Test 206 | - Contingency Test 207 | 208 | For each test it’s important to define and keep track of the following: 209 | - Frequency / Last Test Date / Next Test Date / If automation and a test schedule are in place. 210 | - Outcome of the tests (functional results, performance results, Duration, RTA, RPA…) 211 | - Owner / people involved 212 | 213 | ## Phase 2: Application Continuity 214 | 215 | In this part of the guide, you’ll find a set of examples you can use as a reference to create your own documentation. Each of the documents in the Application Continuity phase should be edited for each application that needs it (as per discussed while documenting artifacts). 216 | 217 | ### Assess 218 | 219 | In this section we are doing information gathering about each individual application. It is also recommended to complete a [landing zone review](https://aka.ms/review-checklists) at this time. 220 | 221 | #### Requirements and Architecture Decision Record 222 | 223 | This example is based on the template named "Application Requirements" in the supporting artifacts section of Phase 1. It's filled in with some details to provide a concrete example on how to use it. For each application, a list of requirements should be documented. A workshop (or series of workshops) with all relevant stakeholders is recommended to gather relevant information for each application. The sample questions provided can be used to assess the application BCDR requirements for a new or existing system. The requirements should be marked as required, not required or not applicable. 224 | 225 | ![Requirements and Architecture Decision Record](media/application-requirements.png) 226 | 227 | Details that were used in the decision for a requirement to be included (or not) can be noted in the column “Architecture Decision Record”. If necessary, this column can also have hyperlinks out to other records (i.e. [ADRs](https://github.com/joelparkerhenderson/architecture-decision-record)). The responses can then be used in the other templates in this guide. This list of requirements will be decomposed into architectural considerations for each application later in this phase. 228 | 229 | #### Service Map 230 | 231 | A Service Map provides a comprehensive view of your organization's IT infrastructure and the interdependencies between services. This understanding is essential for effective BCDR planning. 232 | 233 | Creating a Service Map as part of your Business Continuity and Disaster Recovery (BCDR) strategy is a crucial step in understanding and planning for the resilience of your organization. It helps you visualize your IT environment and the dependencies among various services and components. It's a critical component of your BCDR strategy, helping you build resilience and minimize downtime in the face of disruptions. 234 | 235 | The images in this example visualize the dependencies for a single application. Customers are encouraged to use a service map template or tools outside of the ABC Guide to build these visualizations. The guide can still be used to document a list of the components that are part of the service map. Two links at the bottom (in the notes) are helpful to discover dependencies that may need to be included in a good service map: 236 | 237 | - [Application Insights](https://learn.microsoft.com/azure/azure-monitor/app/app-map?tabs=net) shows dependencies that are discovered for an application (e.g. databases, storage accounts, APIs) 238 | - [VM Insights](https://learn.microsoft.com/azure/azure-monitor/vm/vminsights-maps?source=recommendations) shows network dependencies that are discovered for a VM (e.g. ports and network addresses) 239 | 240 | #### Business Impact Analysis 241 | 242 | A Business Impact Analysis is an activity used to determine the criticality of an application. On top of the document we suggest to add: 243 | 244 | - A recap of the application details and its architectural diagram to help understanding the scenario. 245 | - An impact summary that explains how much an application is used and the “positive impact” generated by the application (e.g. revenue per hour). This help explain the negative impact and the financial loss in the case of a 1 hour outage and define the impact cost. 246 | 247 | Required Metric Values to be defined are (most of these terms can also be found in the glossary): 248 | 249 | - Composite Service Level Objective 250 | - Recovery Time Objective 251 | - Recovery Point Objective 252 | - Throughput Objective (example: minimum transactions per minute/second/hour before it is impactful to business) 253 | - Response Objective (example: maximum response time before it is impactful to business) 254 | - Maximum Tolerable Downtime 255 | 256 | Use this tool to keep track of assessment history and dependencies. **Upstream dependencies** (which the application depends on) should be documented as well as **downstream dependencies** (which depend on the application) in terms of how they meet the objectives. The BIA needs to be reviewed routinely. Including the key findings of test results and metrics provides context to the business decision makers. In essence, equating desired metrics to achieved metrics while balancing impact and risk. 257 | 258 | At the bottom of this example there is a link to a [Sample Business Impact Assessment template](https://learn.microsoft.com/compliance/assurance/assurance-developing-your-ebcm-plan) that can be used to document assessments for each application. 259 | 260 | #### Fault Tree Analysis (-BCDR) 261 | 262 | The fault tree analysis is a top-down approach you can use to determine the cause of a specific event that caused an application to stop working as expected. It’s a powerful tool for improving the reliability of cloud applications. 263 | 264 | Break out the root cause of a (potential) failure into its contributing factors and represent it through a graphical model known as a fault tree. This helps identify potential failure modes and the related probability for reliability analysis. The goal is to break down a complex issue into manageable parts to help: 265 | - Understand potential causes of failures. 266 | - Identify potential failures point and mitigate risks. 267 | 268 | It’s a proactive approach to identifying potential issues before they occur, helping you build more reliable and resilient applications on Azure. 269 | 270 | #### Architecture | Continuity Gap Assessment (-BCDR) 271 | 272 | This template can be used to document the current application availability and recovery configuration (or planned configuration) by component and critical business function. At the bottom of the sheet, the total cost of ownership (including any existing availability and recoverability components) is also calculated. 273 | 274 | At the time of the assessment the application in the example is made up by several components (MS Entra ID, Azure DNS, App Service Plan, Azure Service Bus, etc). For each of the component, all the requirements need to have an associated value. This document contains built-in guidance. 275 | 276 | #### Metric Analysis 277 | 278 | This template is used to record various metrics and calculate composite scores across the metrics. The information is then presented on the Fault Tree Analysis and BCDR Dashboard. 279 | 280 | Metric Analysis will help in calculating a reliability score (and the secure score) for the application itself and for the different service involved. 281 | 282 | This tool contains several tables to provide different aggregated views: 283 | 284 | - Summary 285 | - All Services related to the application 286 | - Services involved per specific business functions 287 | 288 | ### Implement 289 | 290 | After completing all the tasks in the “Assess” section of this phase, the work of designing BCDR components can begin. Many of the examples you see here are “future state” versions of the templates that were created during Assess. For example, you will see a new version of the Architecture which now includes BCDR changes to address any gaps that were found. Another example will be the metrics should now be recalculated to show estimated improvements based on the architecture design changes. 291 | 292 | #### Response Plan by Scope 293 | 294 | Different disaster events will have a different scope of impact and, therefore, a different response. 295 | 296 | A response plan defines the types of disaster events, their scope of impact, along with the planned recovery response and preparation activities. 297 | 298 | For the application consider: 299 | 300 | 1) The scope of events that may affect the application continuity. 301 | 2) The responses that needs to be planned for each event scope. Include details for availability, recoverability and the resources that will be involved in recovery. 302 | 3) The preparation that the business will commit to for the application. 303 | 304 | Disaster Event: 305 | 306 | | Impact Scope | Possible Causes | 307 | | --- | --- | 308 | | - Global
- Azure Geography
- Azure Region
- Azure Zone
- Azure Service Impact | natural disaster, internet, power grid, service failures, etc | 309 | | - Data integrity issue | human error, transfer errors, bugs and viruses, data corruption, etc | 310 | 311 | Refer to the [Business Risk](#business-risk) example in Phase 3: Business Continuity for more information and related types of disasters that may lead to the defined event scopes. 312 | 313 | #### Architecture | Continuity Design (+BCDR) 314 | 315 | This document is the same as the “[Architecture | Continuity Gap Assessment](#architecture--continuity-gap-assessment--bcdr)”, but it contains additional elements that are needed to improve the BCDR strategy. Please note the blue dotted line that highlights what was modified/introduced (compared with the current state design from the assessment section): 316 | 317 | ![Architecture | Continuity Design](media/architecture-continuity-design.png) 318 | 319 | Please ensure to scroll to the right and notice the remediation summary notes that were added for the application in the example. You should consider documenting the changes in a similar way. Another important aspect to note is the last column “Gap Analysis” in the example has been updated compared to the assessment document mentioned above. 320 | 321 | #### Cost Comparison (-BCDR vs. +BCDR) 322 | 323 | This example shows how to calculate and compare the application costs before and after BCDR components are added. 324 | 325 | It shows the overall additional cost of improving BCDR, a recap of the costs of the whole application (all the services) before the resilience remediation and after. Then it replicates the same approach and calculations for the different business functions. 326 | 327 | #### Metric Comparison (+BCDR) 328 | 329 | This template is used to record various metrics and calculate composite scores across the metrics. The information is then presented on the Fault Tree Analysis and BCDR Dashboard. 330 | 331 | This example leverages similar concepts to the [Metric Analysis](#metric-analysis) that was done as part of the Assess section but aims to show benefits of adding BCDR solutions. 332 | 333 | #### Fault Tree Analysis (+BCDR) 334 | 335 | This sample fault tree analysis represents the fault tree after BCDR remediation. This data, along with the defined requirements, and Business Impact Analysis are the essential inputs to create a business case for Application Continuity. 336 | 337 | For a better understanding, please consider comparing the animation in the guide with the one in the [Fault Tree Analysis (-BCDR)](#fault-tree-analysis--bcdr) example from the Assess section. 338 | 339 | #### Contingency Plan 340 | 341 | A contingency plan defines how operations will be continued in the event that the system cannot be restored back to operation. 342 | 343 | In this guide you find an example that describe how employees should respond in case the application is not working (e.g., manage request using the phone, collecting information manually...) 344 | 345 | #### Role Assignment 346 | 347 | This template can be used to assign application and organization BCDR roles. The roles and responsibilities should be defined in the RACI template from the Prepare phase. This template can be used to assign specific people to each role. Important contact details such as phone, email and time zone should be included. 348 | 349 | ### Test 350 | 351 | After completing the implementation of the BCDR strategy, it is important to test the solution to ensure that it meets the requirements. Keep in mind that the documented implementation must be executed (aka "deployed") in order to realize the design components that were detailed in the previous section. The following templates can be used to plan and document the testing activities. 352 | 353 | #### Test Summary 354 | 355 | The example here is based on the [Test Plan template](#test-plans-template) but with concrete examples. Particular attention should be given to the Notes section under the table in this worksheet. The notes describe the difference between shift right (testing in production) vs. shift left (testing in pre-production) and full scale vs. review plan vs. simulation testing activities. 356 | 357 | #### Continuity Drill (Failover Test) 358 | 359 | The example describes failover and failback procedures / tasks needed for the application. 360 | 361 | A list of business functions that are provided by the application is included at the top along with the criticality for each function. This will dictate which functions are included in the failover procedure. Next (below the table of business functions) it gives a summary of the steps that need to be completed in sequence to perform the failover and failback. It is usually necessary to include a link to more detailed procedure documentation that would be followed during a failover event. 362 | 363 | #### Test Plan (UAT) 364 | 365 | Again we start by listing the business functions, the same as we did on the Continuity Drill example. Next we give a summary of the test steps that should be taken during UAT testing by the QA professional (or similar role). The detailed steps should be linked from this example to whatever documentation is used for UAT testing by the QA role. 366 | 367 | #### Outage Communication Plan 368 | 369 | The Outage Communication Plan template should be used during application outages to track what happened (it’s organized by event scope). The customer should define their own set of questions to be completed before an outage, and questions to complete after. We have provided some examples of this but each customer may need to consider additional questions. 370 | 371 | #### Maintain Application Continuity 372 | 373 | A maintenance plan for application continuity is provided as an example. All documents that should be regularly reviewed and updated are listed. 374 | 375 | For each application consider: 376 | 377 | - The documents, activities or automation artifacts that need to be reviewed on a regular basis 378 | - Frequency / next planned review 379 | - Owner of the review process 380 | - Approver of the completed review 381 | 382 | ## Phase 3: Business Continuity 383 | 384 | ### Business Continuity Plan 385 | 386 | A Business Continuity Plan (BCP) is a document that outlines how a business will continue its operations in the event of an unplanned disruption to its business-critical applications. Building a BCP document is a critical process for ensuring an organization's ability to maintain essential business functions in the face of disruptions or disasters. 387 | 388 | Industry-standard and jurisdiction-specific BCP templates are available on the internet. Consider the items listed in the ABC Guide when developing a Business Continuity Plan. 389 | 390 | In this document you’ll find all the important considerations to take into account and a link to the documents (included in the ABC Guide) that are meaningful to implement a good BCP. 391 | 392 | #### Business Risk 393 | 394 | The organization should define risks that are most likely to impact the business. Risk is based on the hazard being assessed and the organization's exposure to the risk. 395 | 396 | Risk associated with an incident can be defined as “the impact of that incident multiplied by the probability of the incident happening”. 397 | 398 | An example of **High Risk** (High Probability and High Impact) is data breach. Given the increasing number of cyber attacks, the probability of a data breach is relatively high. If an attacker gains unauthorized access to your application, they could potentially access sensitive data, modify your application’s behavior, or even cause downtime. The impact of such an event is also high, as it could lead to significant financial losses, damage to your company’s reputation, and loss of customer trust. 399 | 400 | An example of **Low Risk** (Low Probability but High Impact) could be a major natural disaster such as an earthquake or a flood affecting the physical location of Azure data centers. While Azure has multiple data centers around the world to ensure redundancy and minimize the impact of such events, the possibility still exists. The probability of this happening is extremely low, but if it were to occur, the impact could be huge, potentially causing significant downtime. However, Azure’s extensive disaster recovery and backup strategies would likely mitigate this risk. 401 | 402 | ![Business Risk](media/business-risk-calculation.png) 403 | 404 | #### Minimum Business Continuity Objective (MBCO) 405 | 406 | This document outlines how a business will continue its operations in the event of an unplanned disruption to its business-critical applications. The business is recommended to determine the Minimum Business Continuity Objective (MBCO). This represents the minimum number of applications and/or business functions that need to be available or made available before the maximum tolerable downtime (MTD) is reached in order for the business to achieve its objectives during a disruption. 407 | 408 | It’s important to note that a recovery order needs to be defined in order to respect dependencies and define the responsible recovery teams that might be involved. Applications with the same recovery order can be recovered at the same time. 409 | 410 | #### Business Critical Function Calendar 411 | 412 | A Business Critical Function Calendar lists all critical business events for the organization. These are business activities and processes that must be restored in the event of a disruption to ensure the ability to protect the organization’s assets, meet organizational needs, and satisfy regulations. Critical dates must be considered when scheduling BCDR drills. 413 | 414 | You can consider adding Azure Planned Maintenance events to this calendar. Azure offers a suite of experiences to keep you informed about the health of your cloud resources. This information includes current and upcoming issues such as service impacting events, planned maintenance, and other changes that may affect your availability. 415 | 416 | Although you see the calendar in an excel format (as this made it easier to include the example in the guide), please consider evaluating the use of a calendar tool. 417 | 418 | #### Business Impact Analysis | Portfolio Summary 419 | 420 | This page represents a summary of the Business Impact Analysis for all the applications in the portfolio. It’s a good way to have a quick overview of the criticality of the applications and the related business impact. In the provided example, it is a static view of the data that was collected in the [Business Impact Analysis](#business-impact-analysis) template. 421 | 422 | #### Business Continuity and Disaster Recovery | Dashboard 423 | 424 | The Business Continuity and Disaster Recovery dashboard captures all relevant application architecture, requirements, processes, plans, policies, test schedules, metrics, current and historical status to help you recover or remain operational in the case of a disaster. 425 | 426 | In the provided example, the content of the dashboard is not automatically updated. In a real scenario, you should consider using a tool that can automatically pull data from the different sources and provide a dynamic view of the data. 427 | 428 | #### Maintain Business Continuity 429 | 430 | An example of the maintenance plan for business continuity. All documents that should be regularly reviewed and updated are listed. 431 | 432 | For the business, consider: 433 | 434 | 1. The documents, activities or automation artifacts that need to be reviewed on a regular basis. 435 | 2. The frequency of review. 436 | 3. The owner of the review process. 437 | 4. The approver of the completed review. 438 | -------------------------------------------------------------------------------- /media/Business_Continuity-Minimum_Business_Continuity_Objective.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/Business_Continuity-Minimum_Business_Continuity_Objective.png -------------------------------------------------------------------------------- /media/Implement-Impact_Scope.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/Implement-Impact_Scope.png -------------------------------------------------------------------------------- /media/Prepare-Criticality_Definitions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/Prepare-Criticality_Definitions.png -------------------------------------------------------------------------------- /media/RACI-legend.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/RACI-legend.png -------------------------------------------------------------------------------- /media/application-requirements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/application-requirements.png -------------------------------------------------------------------------------- /media/architecture-continuity-design.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/architecture-continuity-design.png -------------------------------------------------------------------------------- /media/autosave.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/autosave.png -------------------------------------------------------------------------------- /media/business-commitment-model-availability-requirements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/business-commitment-model-availability-requirements.png -------------------------------------------------------------------------------- /media/business-commitment-model-collapsed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/business-commitment-model-collapsed.png -------------------------------------------------------------------------------- /media/business-commitment-model-deployment-requirements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/business-commitment-model-deployment-requirements.png -------------------------------------------------------------------------------- /media/business-commitment-model-general-requirements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/business-commitment-model-general-requirements.png -------------------------------------------------------------------------------- /media/business-commitment-model-monitoring-requirements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/business-commitment-model-monitoring-requirements.png -------------------------------------------------------------------------------- /media/business-commitment-model-recoverability-requirements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/business-commitment-model-recoverability-requirements.png -------------------------------------------------------------------------------- /media/business-commitment-model-security-requirements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/business-commitment-model-security-requirements.png -------------------------------------------------------------------------------- /media/business-commitment-model-testing-requirements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/business-commitment-model-testing-requirements.png -------------------------------------------------------------------------------- /media/business-commitment-requirements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/business-commitment-requirements.png -------------------------------------------------------------------------------- /media/business-risk-calculation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/business-risk-calculation.png -------------------------------------------------------------------------------- /media/category-filter-off.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/category-filter-off.png -------------------------------------------------------------------------------- /media/category-filter-on.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/category-filter-on.png -------------------------------------------------------------------------------- /media/collapse-button.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/collapse-button.png -------------------------------------------------------------------------------- /media/expand-button.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/expand-button.png -------------------------------------------------------------------------------- /media/glossary-button.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/glossary-button.png -------------------------------------------------------------------------------- /media/home-button.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/home-button.png -------------------------------------------------------------------------------- /media/navigation-buttons.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/navigation-buttons.png -------------------------------------------------------------------------------- /media/personas-button.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/personas-button.png -------------------------------------------------------------------------------- /media/references-button.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/references-button.png -------------------------------------------------------------------------------- /media/reliability-trade-offs-footnote.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Azure/BusinessContinuityGuide/195548f301c6c400b57bfbc5421253d893ad08ea/media/reliability-trade-offs-footnote.png --------------------------------------------------------------------------------