Skip to main content

BCD-10.3: Provider Contingency Plan

BCD 5 — Medium Protect

Mechanisms exist to contractually-require external service providers to have contingency plans that meet organizational contingency requirements.

Control Question: Does the organization contractually-require external service providers to have contingency plans that meet organizational contingency requirements?

General (11)
Framework Mapping Values
CSA CCM 4 BCR-03
GovRAMP High CP-08(04)
NIST 800-53 R4 CP-8(4)
NIST 800-53 R4 (high) CP-8(4)
NIST 800-53 R5 (source) CP-8(4)
NIST 800-53B R5 (high) (source) CP-8(4)
NIST 800-82 R3 HIGH OT Overlay CP-8(4)
NIST 800-161 R1 CP-8(4)
NIST 800-161 R1 Level 2 CP-8(4)
NIST 800-161 R1 Level 3 CP-8(4)
SCF CORE Mergers, Acquisitions & Divestitures (MA&D) BCD-10.3
US (4)
Framework Mapping Values
US FedRAMP R4 CP-8(4)
US FedRAMP R4 (high) CP-8(4)
US FedRAMP R5 (source) CP-8(4)
US FedRAMP R5 (high) (source) CP-8(4)
EMEA (1)
Framework Mapping Values
EMEA EU EBA GL/2019/04 3.7.3(86)

Capability Maturity Model

Level 0 — Not Performed

There is no evidence of a capability to contractually-require telecommunications service providers to have contingency plans that meet organizational contingency requirements.

Level 1 — Performed Informally

C|P-CMM1 is N/A, since a structured process is required to contractually-require telecommunications service providers to have contingency plans that meet organizational contingency requirements.

Level 2 — Planned & Tracked

Business Continuity & Disaster Recovery (BCD) efforts are requirements-driven and 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, resilient and compliant practices.
  • IT/cybersecurity personnel identify cybersecurity and data protection 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).
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

See C|P-CMM3. There are no defined C|P-CMM4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to contractually-require telecommunications service providers to have contingency plans that meet organizational contingency requirements.

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 contractually-require telecommunications service providers to have contingency plans that meet organizational contingency requirements.

Assessment Objectives

  1. BCD-10.3_A01 the frequency at which to obtain evidence of contingency testing by providers is defined.
  2. BCD-10.3_A02 the frequency at which to obtain evidence of contingency training by providers is defined.
  3. BCD-10.3_A03 primary telecommunications service providers are required to have contingency plans.
  4. BCD-10.3_A04 alternate telecommunications service providers are required to have contingency plans.
  5. BCD-10.3_A05 provider contingency plans are reviewed to ensure that the plans meet organizational contingency requirements.
  6. BCD-10.3_A06 evidence of contingency testing by providers is obtained.
  7. BCD-10.3_A07 evidence of contingency training by providers is obtained.

Technology Recommendations

Micro/Small

  • Cybersecurity Supply Chain Risk Management (C-SCRM) program

Small

  • Cybersecurity Supply Chain Risk Management (C-SCRM) program

Medium

  • Cybersecurity Supply Chain Risk Management (C-SCRM) program

Large

  • Cybersecurity Supply Chain Risk Management (C-SCRM) program

Enterprise

  • Cybersecurity Supply Chain Risk Management (C-SCRM) program

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.