Skip to main content

BCD-06: Ongoing Contingency Planning

BCD 8 — High Recover

Mechanisms exist to update contingency plans due to changes affecting: (1) People (e.g., personnel changes); (2) Processes (e.g., new, altered or decommissioned business practices, including third-party services) (3) Technologies (e.g., new, altered or decommissioned technologies); (4) Data (e.g., changes to data flows and/or data repositories); (5) Facilities (e.g., new, altered or decommissioned physical infrastructure); and/or (6) Feedback from contingency plan testing activities.

Control Question: Does the organization update contingency plans due to changes affecting: (1) People (e.g., personnel changes); (2) Processes (e.g., new, altered or decommissioned business practices, including third-party services) (3) Technologies (e.g., new, altered or decommissioned technologies); (4) Data (e.g., changes to data flows and/or data repositories); (5) Facilities (e.g., new, altered or decommissioned physical infrastructure); and/or (6) Feedback from contingency plan testing activities?

General (29)
Framework Mapping Values
AICPA TSC 2017:2022 (used for SOC 2) (source) CC7.5 CC7.5-POF4 CC7.5-POF5
COBIT 2019 DSS04.05
CSA CCM 4 BCR-05
ENISA 2.0 SO19 SO20
GovRAMP Low CP-02
GovRAMP Low+ CP-02
GovRAMP Moderate CP-02
GovRAMP High CP-02
ISO 22301 2019 6.3 7.5 7.5.1 7.5.3 7.5.3.1 7.5.3.2 8.4 8.4.1 8.4.2 8.4.2.1 8.4.2.2 8.4.4 8.4.4.1 8.4.4.2 8.4.4.3 8.4.5 8.6 10.1 10.1.1 10.1.2 10.1.3 10.2
NIST 800-53 R4 CP-2
NIST 800-53 R4 (low) CP-2
NIST 800-53 R4 (moderate) CP-2
NIST 800-53 R4 (high) CP-2
NIST 800-53 R5 (source) CP-2
NIST 800-53B R5 (low) (source) CP-2
NIST 800-53B R5 (moderate) (source) CP-2
NIST 800-53B R5 (high) (source) CP-2
NIST 800-82 R3 LOW OT Overlay CP-2
NIST 800-82 R3 MODERATE OT Overlay CP-2
NIST 800-82 R3 HIGH OT Overlay CP-2
NIST 800-161 R1 CP-2
NIST 800-161 R1 C-SCRM Baseline CP-2
NIST 800-161 R1 Level 2 CP-2
NIST 800-161 R1 Level 3 CP-2
NIST CSF 2.0 (source) ID.IM-04
SCF CORE Mergers, Acquisitions & Divestitures (MA&D) BCD-06
SCF CORE ESP Level 1 Foundational BCD-06
SCF CORE ESP Level 2 Critical Infrastructure BCD-06
SCF CORE ESP Level 3 Advanced Threats BCD-06
US (20)
EMEA (3)
Framework Mapping Values
EMEA EU EBA GL/2019/04 3.7.4(88) 3.7.4(90)
EMEA Germany C5 2020 BCM-04
EMEA Saudi Arabia ECC-1 2018 3-1-4

Capability Maturity Model

Level 0 — Not Performed

There is no evidence of a capability to update contingency plans due to changes affecting: (1) People (e.g., personnel changes); (2) Processes (e.g., new, altered or decommissioned business practices, including third-party services) (3) Technologies (e.g., new, altered or decommissioned technologies); (4) Data (e.g., changes to data flows and/or data repositories); (5) Facilities (e.g., new, altered or decommissioned physical infrastructure); and/or (6) Feedback from contingency plan testing activities.

Level 1 — Performed Informally

Business Continuity & Disaster Recovery (BCD) efforts are ad hoc and inconsistent. CMM Level 1 control maturity would reasonably expect all, or at least most, the following criteria to exist:

  • IT personnel work with business stakeholders to identify business-critical systems and services, including internal teams and third-party service providers.
  • IT personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical systems and services.
  • Business stakeholders develop limited Business Continuity Plans (BCPs) to ensure business-critical functions are sustainable both during and after an incident within Recovery Time Objectives (RTOs).
  • Backups are performed ad-hoc and focus on business-critical systems.
  • Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).
  • IT personnel work with business stakeholders to identify alternative or compensating controls to address control deficiencies, if the primary means of implementing the security function is unavailable or compromised.
Level 2 — Planned & Tracked

Business Continuity & Disaster Recovery (BCD) efforts are requirements-driven and formally governed at a local/regional level, but are not consistent across the organization. CMM Level 2 control maturity would reasonably expect all, or at least most, the following criteria to exist:

  • Business Continuity / Disaster Recovery (BC/DR) management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure and compliant practices.
  • IT/cybersecurity personnel identify cybersecurity and data privacy controls that are appropriate to address applicable statutory, regulatory and contractual requirements for BC/DR management.
  • BC/DR roles are formally assigned as an additional duty to existing IT/cybersecurity personnel.
  • Recovery Time Objectives (RTOs) identify business-critical systems and services, which are given priority of service in alternate processing and storage sites.
  • IT personnel develop Disaster Recovery Plans (DRP) to recover business-critical systems and services.
  • Data/process owners conduct a Business Impact Analysis (BIA) at least annually, or after any major technology or process change, to identify assets critical to the business in need of protection, as well as single points of failure.
  • IT/cybersecurity personnel work with business stakeholders to develop Business Continuity Plans (BCPs) to ensure business functions are sustainable both during and after an incident within Recovery Time Objectives (RTOs).
  • IT personnel use a backup methodology (e.g., grandfather, father & s on rotation) to store backups in a secondary location, separate from the primary storage site.
  • IT personnel configure business-critical systems to transfer backup data to the alternate storage site at a rate that is capable of meeting Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).
  • on at least an annual basis, or after any major technology or process change, the data/process owner updates the data mapping documentation.
Level 3 — Well Defined

Business Continuity & Disaster Recovery (BCD) efforts are standardized across the organization and centrally managed, where technically feasible, to ensure consistency. CMM Level 3 control maturity would reasonably expect all, or at least most, the following criteria to exist:

  • A formal Business Continuity & Disaster Recovery (BC/DR) program exists with defined roles and responsibilities to restore functionality in the event of a catastrophe, emergency, or significant disruptive incident that is handled in accordance with a Continuity of Operations Plan (COOP).
  • BC/DR personnel work with business stakeholders to identify business-critical systems, services, internal teams and third-party service providers.
  • Specific criteria are defined to initiate BC/DR activities that facilitate business continuity operations capable of meeting applicable RTOs and/or RPOs.- Application/system/process owners conduct a Business Impact Analysis (BIA) at least annually, or after any major technology or process change, to identify assets critical to the business in need of protection, as well as single points of failure.
  • Recovery Time Objectives (RTOs) are defined for business-critical systems and services.
  • Recovery Point Objectives (RPOs) are defined and technologies exist to conduct transaction-level recovery, in accordance with RPOs.
  • Controls are assigned to sensitive/regulated assets to comply with specific BC/DR requirements to facilitate recovery operations in accordance with RTOs and RPOs.
  • IT personnel work with business stakeholders to develop Disaster Recovery Plans (DRP) to recover business-critical systems and services within RPOs.
  • Business stakeholders work with IT personnel to develop Business Continuity Plans (BCPs) to ensure business functions are sustainable both during and after an incident within RTOs.
  • The data backup function is formally assigned with defined roles and responsibilities.
  • BC/DR personnel have pre-established methods to communicate the status of recovery activities and progress in restoring operational capabilities to designated internal and external stakeholders.
  • The integrity of backups and other restoration assets are verified prior to using them for restoration.
Level 4 — Quantitatively Controlled

Business Continuity & Disaster Recovery (BCD) efforts are metrics driven and provide sufficient management insight (based on a quantitative understanding of process capabilities) to predict optimal performance, ensure continued operations and identify areas for improvement. In addition to CMM Level 3 criteria, CMM Level 4 control maturity would reasonably expect all, or at least most, the following criteria to exist:

  • Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
  • Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
  • Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data privacy controls, including functions performed by third-parties.
  • Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
  • Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
  • Both business and technical stakeholders are involved in reviewing and approving proposed changes.
Level 5 — Continuously Improving

See C|P-CMM4. There are no defined C|P-CMM5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to update contingency plans due to changes affecting: (1) People (e.g., personnel changes); (2) Processes (e.g., new, altered or decommissioned business practices, including third-party services) (3) Technologies (e.g., new, altered or decommissioned technologies); (4) Data (e.g., changes to data flows and/or data repositories); (5) Facilities (e.g., new, altered or decommissioned physical infrastructure); and/or (6) Feedback from contingency plan testing activities.

Assessment Objectives

  1. BCD-06_A01 a contingency plan is developed that identifies essential mission and business functions and associated contingency requirements.
  2. BCD-06_A02 personnel or roles to review a contingency plan is/are defined.
  3. BCD-06_A03 the contingency plan is updated to address changes to the organization, system or environment of operation.
  4. BCD-06_A04 contingency plan changes are communicated to key contingency personnel.
  5. BCD-06_A05 the contingency plan is updated to address problems encountered during contingency plan implementation, execution or testing.
  6. BCD-06_A06 personnel or roles to approve a contingency plan is/are defined.
  7. BCD-06_A07 key contingency personnel (identified by name and/or by role) to whom copies of the contingency plan are distributed are defined.
  8. BCD-06_A08 key contingency organizational elements to which copies of the contingency plan are distributed are defined.
  9. BCD-06_A09 the frequency of contingency plan review is defined.
  10. BCD-06_A10 key contingency personnel (identified by name and/or by role) to communicate changes to are defined.
  11. BCD-06_A11 key contingency organizational elements to communicate changes to are defined.
  12. BCD-06_A12 a contingency plan for the system is developed that provides recovery objectives.
  13. BCD-06_A13 a contingency plan for the system is developed that provides restoration priorities.
  14. BCD-06_A14 a contingency plan for the system is developed that provides metrics.
  15. BCD-06_A15 a contingency plan for the system is developed that addresses contingency roles.
  16. BCD-06_A16 a contingency plan for the system is developed that addresses contingency responsibilities.
  17. BCD-06_A17 a contingency plan for the system is developed that addresses assigned individuals with contact information.
  18. BCD-06_A18 a contingency plan for the system is developed that addresses maintaining essential mission and business functions despite a disruption, compromise or failure of a system, application or service.
  19. BCD-06_A19 a contingency plan for the system is developed that addresses eventual, full-system restoration without deterioration of the controls originally planned and implemented.
  20. BCD-06_A20 a contingency plan for the system is developed that addresses the sharing of contingency information.
  21. BCD-06_A21 a contingency plan for the system is developed that is reviewed by personnel or roles.
  22. BCD-06_A22 a contingency plan for the system is developed that is approved by personnel or roles.
  23. BCD-06_A23 copies of the contingency plan are distributed to key contingency personnel.
  24. BCD-06_A24 copies of the contingency plan are distributed to organizational elements.
  25. BCD-06_A25 contingency planning activities are coordinated with incident handling activities.
  26. BCD-06_A26 the contingency plan for the system is reviewed frequently.
  27. BCD-06_A27 contingency plan changes are communicated to organizational elements.
  28. BCD-06_A28 lessons learned from contingency plan testing or actual contingency activities are incorporated into contingency testing.
  29. BCD-06_A29 lessons learned from contingency plan training or actual contingency activities are incorporated into contingency testing and training.
  30. BCD-06_A30 the contingency plan is protected from unauthorized disclosure.
  31. BCD-06_A31 the contingency plan is protected from unauthorized modification.

Evidence Requirements

E-BCM-05 COOP Updates

Documented evidence of a periodic review process for the organization's Continuity of Operations Plan (COOP) to identify necessary updates.

Business Continuity

Technology Recommendations

Micro/Small

  • Documentation change control

Small

  • Documentation change control

Medium

  • Documentation change control

Large

  • Documentation change control

Enterprise

  • Documentation change control

The Secure Controls Framework (SCF) is maintained by SCF Council. Use of SCF content is subject to the SCF Terms & Conditions.

Manage this control in SCF Connect

Track implementation status, collect evidence, and map controls to your compliance frameworks automatically.