last sync: 2024-Nov-25 18:54:24 UTC

Develop and document a business continuity and disaster recovery plan | Regulatory Compliance - Documentation

Azure BuiltIn Policy definition

Source Azure Portal
Display name Develop and document a business continuity and disaster recovery plan
Id bd6cbcba-4a2d-507c-53e3-296b5c238a8e
Version 1.1.0
Details on versioning
Versioning Versions supported for Versioning: 1
1.1.0
Built-in Versioning [Preview]
Category Regulatory Compliance
Microsoft Learn
Description CMA_0146 - Develop and document a business continuity and disaster recovery plan
Additional metadata Name/Id: CMA_0146 / CMA_0146
Category: Documentation
Title: Develop and document a business continuity and disaster recovery plan
Ownership: Customer
Description: Microsoft recommends that your organization develop, document, maintain, and distribute a Business Continuity Plan to provide guidance and information regarding responding to disruption and assisting in recovery. It is recommended that the plan include the purpose, scope, objectives, roles and responsibilities with contact information, resource availability, supply chains, and essential missions and business functions. It is also recommended to include recovery time and point objectives, response process flows, exclusions, notification/warning and communication procedures, and plan activation procedures during a disruption to the business. Based on various regulatory requirements, your organization is recommended to have or do the following: - A response structure that identifies teams responsible for disruption response, impact assessment, response initiation according to pre-defined thresholds, and priorities establishment - Coordinate with external service providers to ensure consistency of contingency plan requirements - A warning and communication procedure to communicate with relevant internal and external parties, facilitate structured communication with emergency responders, provide details of the organization's media response and communication strategy, and record details of disruption, actions taken, and decisions made - Implement the capability to activate alternative communications protocols to support the continuity of operations - Plan and prepare for circumstances that preclude returning to the primary processing site - Implement and activate business continuity solutions at the time of the disruption to continue and recover prioritized activities, such as entering a safe mode of operation - Conduct periodic reviews and approvals of the Business Continuity and Disaster Recovery Plans - Update the Business Continuity and Disaster Recovery Plans to address changes to the organization, information system, or environment of operation and problems encountered during execution or testing - Communicate changes in the Business Continuity and Disaster Recovery Plans to key contingency personnel and relevant interested parties - Protect Business Continuity and Disaster Recovery Plans from unauthorized disclosure and modification - Create and distribute Disaster Recovery Plan defining the procedures to restore hardware, applications, and data in time to meet the needs of the business recovery determined by the business impact assessment - Review and approve the Business Continuity and Disaster Recovery Plan by organization-defined personnel or roles It is recommended that your organization resume all missions and business functions within the time period defined in service provider and organization Service Level Agreement (SLA) of Business Continuity Plan / contingency plan activation. It is recommended that your organization replicate the successfully implemented changes to disaster recovery systems or applications for uniformity. The Reserve Bank of India Cyber Security framework states that the Business Continuity and Disaster Recovery Plan should consider and address cyber risks. NIST 800-184: Guide for Cybersecurity Event Recovery act requires that the organizations integrate their Cyber Incident Response Plan (CIRP) into its enterprise-wide Business Continuity Plan (BCP). The New Zealand Information Security Manual (NZISM) requires Agencies to document procedures relating to securing classified information and systems when required to evacuate a facility in the event of an emergency.
Requirements: The customer is responsible for implementing this recommendation.
Mode All
Type BuiltIn
Preview False
Deprecated False
Effect Default
Manual
Allowed
Manual, Disabled
RBAC role(s) none
Rule aliases none
Rule resource types IF (1)
Microsoft.Resources/subscriptions
Compliance
The following 15 compliance controls are associated with this Policy definition 'Develop and document a business continuity and disaster recovery plan' (bd6cbcba-4a2d-507c-53e3-296b5c238a8e)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
FedRAMP_High_R4 CP-2 FedRAMP_High_R4_CP-2 FedRAMP High CP-2 Contingency Planning Contingency Plan Shared n/a The organization: a. Develops a contingency plan for the information system that: 1. Identifies essential missions and business functions and associated contingency requirements; 2. Provides recovery objectives, restoration priorities, and metrics; 3. Addresses contingency roles, responsibilities, assigned individuals with contact information; 4. Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure; 5. Addresses eventual, full information system restoration without deterioration of the security safeguards originally planned and implemented; and 6. Is reviewed and approved by [Assignment: organization-defined personnel or roles]; b. Distributes copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; c. Coordinates contingency planning activities with incident handling activities; d. Reviews the contingency plan for the information system [Assignment: organization-defined frequency]; e. Updates the contingency plan to address changes to the organization, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing; f. Communicates contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; and g. Protects the contingency plan from unauthorized disclosure and modification. Supplemental Guidance: Contingency planning for information systems is part of an overall organizational program for achieving continuity of operations for mission/business functions. Contingency planning addresses both information system restoration and implementation of alternative mission/business processes when systems are compromised. The effectiveness of contingency planning is maximized by considering such planning throughout the phases of the system development life cycle. Performing contingency planning on hardware, software, and firmware development can be an effective means of achieving information system resiliency. Contingency plans reflect the degree of restoration required for organizational information systems since not all systems may need to fully recover to achieve the level of continuity of operations desired. Information system recovery objectives reflect applicable laws, Executive Orders, directives, policies, standards, regulations, and guidelines. In addition to information system availability, contingency plans also address other security-related events resulting in a reduction in mission and/or business effectiveness, such as malicious attacks compromising the confidentiality or integrity of information systems. Actions addressed in contingency plans include, for example, orderly/graceful degradation, information system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By closely coordinating contingency planning with incident handling activities, organizations can ensure that the necessary contingency planning activities are in place and activated in the event of a security incident. Related controls: AC-14, CP-6, CP-7, CP-8, CP-9, CP-10, IR-4, IR-8, MP-2, MP-4, MP-5, PM-8, PM-11. References: Federal Continuity Directive 1; NIST Special Publication 800-34. link 8
FedRAMP_Moderate_R4 CP-2 FedRAMP_Moderate_R4_CP-2 FedRAMP Moderate CP-2 Contingency Planning Contingency Plan Shared n/a The organization: a. Develops a contingency plan for the information system that: 1. Identifies essential missions and business functions and associated contingency requirements; 2. Provides recovery objectives, restoration priorities, and metrics; 3. Addresses contingency roles, responsibilities, assigned individuals with contact information; 4. Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure; 5. Addresses eventual, full information system restoration without deterioration of the security safeguards originally planned and implemented; and 6. Is reviewed and approved by [Assignment: organization-defined personnel or roles]; b. Distributes copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; c. Coordinates contingency planning activities with incident handling activities; d. Reviews the contingency plan for the information system [Assignment: organization-defined frequency]; e. Updates the contingency plan to address changes to the organization, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing; f. Communicates contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; and g. Protects the contingency plan from unauthorized disclosure and modification. Supplemental Guidance: Contingency planning for information systems is part of an overall organizational program for achieving continuity of operations for mission/business functions. Contingency planning addresses both information system restoration and implementation of alternative mission/business processes when systems are compromised. The effectiveness of contingency planning is maximized by considering such planning throughout the phases of the system development life cycle. Performing contingency planning on hardware, software, and firmware development can be an effective means of achieving information system resiliency. Contingency plans reflect the degree of restoration required for organizational information systems since not all systems may need to fully recover to achieve the level of continuity of operations desired. Information system recovery objectives reflect applicable laws, Executive Orders, directives, policies, standards, regulations, and guidelines. In addition to information system availability, contingency plans also address other security-related events resulting in a reduction in mission and/or business effectiveness, such as malicious attacks compromising the confidentiality or integrity of information systems. Actions addressed in contingency plans include, for example, orderly/graceful degradation, information system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By closely coordinating contingency planning with incident handling activities, organizations can ensure that the necessary contingency planning activities are in place and activated in the event of a security incident. Related controls: AC-14, CP-6, CP-7, CP-8, CP-9, CP-10, IR-4, IR-8, MP-2, MP-4, MP-5, PM-8, PM-11. References: Federal Continuity Directive 1; NIST Special Publication 800-34. link 8
hipaa 1602.12c1Organizational.4567-12.c hipaa-1602.12c1Organizational.4567-12.c 1602.12c1Organizational.4567-12.c 16 Business Continuity & Disaster Recovery 1602.12c1Organizational.4567-12.c 12.01 Information Security Aspects of Business Continuity Management Shared n/a The contingency program addresses required capacity, identifies critical missions and business functions, defines recovery objectives and priorities, and identifies roles and responsibilities. 3
hipaa 1667.12d1Organizational.4-12.d hipaa-1667.12d1Organizational.4-12.d 1667.12d1Organizational.4-12.d 16 Business Continuity & Disaster Recovery 1667.12d1Organizational.4-12.d 12.01 Information Security Aspects of Business Continuity Management Shared n/a When new requirements are identified, any existing emergency procedures (e.g., evacuation plans or fallback arrangements) are amended as appropriate. 4
ISO27001-2013 A.17.1.1 ISO27001-2013_A.17.1.1 ISO 27001:2013 A.17.1.1 Information Security Aspects Of Business Continuity Management Planning information security continuity Shared n/a The organization shall determine its requirements for information security and the continuity of information security management in adverse situations, e.g. during a crisis or disaster. link 11
ISO27001-2013 A.17.2.1 ISO27001-2013_A.17.2.1 ISO 27001:2013 A.17.2.1 Information Security Aspects Of Business Continuity Management Availability of information processing facilities Shared n/a Information processing facilities shall be implemented with redundancy sufficient to meet availability requirements. link 17
ISO27001-2013 A.6.1.1 ISO27001-2013_A.6.1.1 ISO 27001:2013 A.6.1.1 Organization of Information Security Information security roles and responsibilities Shared n/a All information security responsibilities shall be clearly defined and allocated. link 73
mp.eq.3 Protection of portable devices mp.eq.3 Protection of portable devices 404 not found n/a n/a 71
mp.eq.4 Other devices connected to the network mp.eq.4 Other devices connected to the network 404 not found n/a n/a 35
mp.info.6 Backups mp.info.6 Backups 404 not found n/a n/a 65
NIST_SP_800-53_R4 CP-2 NIST_SP_800-53_R4_CP-2 NIST SP 800-53 Rev. 4 CP-2 Contingency Planning Contingency Plan Shared n/a The organization: a. Develops a contingency plan for the information system that: 1. Identifies essential missions and business functions and associated contingency requirements; 2. Provides recovery objectives, restoration priorities, and metrics; 3. Addresses contingency roles, responsibilities, assigned individuals with contact information; 4. Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure; 5. Addresses eventual, full information system restoration without deterioration of the security safeguards originally planned and implemented; and 6. Is reviewed and approved by [Assignment: organization-defined personnel or roles]; b. Distributes copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; c. Coordinates contingency planning activities with incident handling activities; d. Reviews the contingency plan for the information system [Assignment: organization-defined frequency]; e. Updates the contingency plan to address changes to the organization, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing; f. Communicates contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; and g. Protects the contingency plan from unauthorized disclosure and modification. Supplemental Guidance: Contingency planning for information systems is part of an overall organizational program for achieving continuity of operations for mission/business functions. Contingency planning addresses both information system restoration and implementation of alternative mission/business processes when systems are compromised. The effectiveness of contingency planning is maximized by considering such planning throughout the phases of the system development life cycle. Performing contingency planning on hardware, software, and firmware development can be an effective means of achieving information system resiliency. Contingency plans reflect the degree of restoration required for organizational information systems since not all systems may need to fully recover to achieve the level of continuity of operations desired. Information system recovery objectives reflect applicable laws, Executive Orders, directives, policies, standards, regulations, and guidelines. In addition to information system availability, contingency plans also address other security-related events resulting in a reduction in mission and/or business effectiveness, such as malicious attacks compromising the confidentiality or integrity of information systems. Actions addressed in contingency plans include, for example, orderly/graceful degradation, information system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By closely coordinating contingency planning with incident handling activities, organizations can ensure that the necessary contingency planning activities are in place and activated in the event of a security incident. Related controls: AC-14, CP-6, CP-7, CP-8, CP-9, CP-10, IR-4, IR-8, MP-2, MP-4, MP-5, PM-8, PM-11. References: Federal Continuity Directive 1; NIST Special Publication 800-34. link 8
NIST_SP_800-53_R5 CP-2 NIST_SP_800-53_R5_CP-2 NIST SP 800-53 Rev. 5 CP-2 Contingency Planning Contingency Plan Shared n/a a. Develop a contingency plan for the system that: 1. Identifies essential mission and business functions and associated contingency requirements; 2. Provides recovery objectives, restoration priorities, and metrics; 3. Addresses contingency roles, responsibilities, assigned individuals with contact information; 4. Addresses maintaining essential mission and business functions despite a system disruption, compromise, or failure; 5. Addresses eventual, full system restoration without deterioration of the controls originally planned and implemented; 6. Addresses the sharing of contingency information; and 7. Is reviewed and approved by [Assignment: organization-defined personnel or roles]; b. Distribute copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; c. Coordinate contingency planning activities with incident handling activities; d. Review the contingency plan for the system [Assignment: organization-defined frequency]; e. Update the contingency plan to address changes to the organization, system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing; f. Communicate contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; g. Incorporate lessons learned from contingency plan testing, training, or actual contingency activities into contingency testing and training; and h. Protect the contingency plan from unauthorized disclosure and modification. link 8
org.1 Security policy org.1 Security policy 404 not found n/a n/a 94
org.4 Authorization process org.4 Authorization process 404 not found n/a n/a 126
SWIFT_CSCF_v2022 9.3 SWIFT_CSCF_v2022_9.3 SWIFT CSCF v2022 9.3 9. Ensure Availability through Resilience Service bureaux must ensure that the service remains available for their customers in the event of a disturbance, a hazard, or an incident. Shared n/a Service bureaux must ensure that the service remains available for their customers in the event of a disturbance, a hazard, or an incident. link 7
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
HITRUST/HIPAA a169a624-5599-4385-a696-c8d643089fab Regulatory Compliance GA BuiltIn
ISO 27001:2013 89c6cddc-1c73-4ac1-b19c-54d1a15a42f2 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
Spain ENS 175daf90-21e1-4fec-b745-7b4c909aa94c Regulatory Compliance GA BuiltIn
SWIFT CSP-CSCF v2022 7bc7cd6c-4114-ff31-3cac-59be3157596d Regulatory Compliance GA BuiltIn
History
Date/Time (UTC ymd) (i) Change type Change detail
2022-09-27 16:35:32 change Minor (1.0.0 > 1.1.0)
2022-09-19 17:41:40 add bd6cbcba-4a2d-507c-53e3-296b5c238a8e
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC