CP-2(7): Coordinate with External Service Providers

CP-2(7) requires you to coordinate your contingency plan with each external service provider’s contingency plan so your recovery objectives, dependencies, and handoffs still work during a disruption. Operationalize it by identifying which third parties are required for recovery, obtaining and reviewing their resilience/DR materials, and documenting tested failover and communication procedures that meet your contingency requirements. ¹

Key takeaways:

• Your contingency plan is incomplete unless it explicitly accounts for third-party dependencies and provider recovery capabilities. ¹
• “Coordinate” means documented alignment on RTO/RPO expectations, roles, communications, and recovery sequences, not a one-time questionnaire. ¹
• The pass/fail risk is evidence: auditors look for proof you reviewed provider plans and validated recovery handoffs via tests, exercises, or documented walk-throughs. ²

CP-2(7): coordinate with external service providers requirement shows up as an uncomfortable truth during outages: your internal DR plan can be solid and still fail if a cloud host, managed security provider, payroll processor, or critical SaaS can’t recover on the timeline your mission needs. This enhancement to CP-2 focuses on aligning plans across organizational boundaries so contingency requirements can actually be satisfied, end to end. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing CP-2(7) is to treat it as a dependency management control within contingency planning. You build a complete list of external services required to run “minimum viable operations,” map each dependency to recovery requirements, then obtain and validate the third party’s ability to meet them. You do not need to rewrite your provider’s DR plan. You do need written coordination points: contacts, escalation, recovery order, data restoration assumptions, and evidence that both sides can execute those steps under stress. ²

Regulatory text

Requirement (verbatim): “Coordinate the contingency plan with the contingency plans of external service providers to ensure that contingency requirements can be satisfied.” ¹

Operator interpretation: You must be able to show that your contingency plan accounts for external service providers’ recovery capabilities and procedures, and that you have aligned expectations and handoffs so your own contingency requirements are achievable. Coordination must be specific to the services you depend on for recovery, not generic statements that “vendors have DR.” ¹

Plain-English interpretation

• If a third party is part of your recovery path, their recovery plan becomes an input to your contingency plan.
• Your plan must reflect real dependencies (identity, network, hosting, backups, ticketing, call center, payments) and the sequence needed to restore operations.
• You need documented proof that you reviewed the provider’s contingency posture and that gaps are tracked and treated as risk (mitigation, compensating controls, alternative providers, or business decision). ²

Who it applies to

Entities

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data (common in FedRAMP-like and agency contractual flows) where 800-53 controls are inherited or required. ²

Operational context (where CP-2(7) becomes “exam visible”)

Applies whenever you rely on external service providers for any of the following:

• Core infrastructure (IaaS/PaaS hosting, DNS, CDN, network connectivity).
• Enterprise SaaS needed for operations (identity provider, email, collaboration, CRM/ERP).
• Managed services (MSSP, SOC, managed backups, managed endpoint).
• Data processors (payments, claims processing, payroll, benefits, healthcare clearinghouse).
• Support channels (call centers, ticketing platforms, incident notification vendors).

If the service is required to meet an RTO/RPO, it belongs in CP-2(7) scope.

What you actually need to do (step-by-step)

Step 1: Define “contingency requirements” in operator terms

Pull the recovery expectations you already claim internally:

• System/service tiering (critical, important, non-critical).
• Target recovery objectives you use internally (RTO/RPO or equivalent internal time/data loss expectations).
• Minimum viable business services list (what must run first).

If those don’t exist, document them as part of CP-2 and treat CP-2(7) as dependent on that foundation. ²

Step 2: Build a third-party dependency map for recovery

Create a simple table that answers: “If this provider is down, what cannot recover?” Minimum columns:

• Business service / system
• External service provider
• Dependency type (hosting, identity, data, support)
• Recovery requirement (what you need from them)
• Workaround (manual process, alternate provider, degrade mode)

This becomes your coordination index and your evidence backbone.

Step 3: Classify which third parties require coordination

Not every third party warrants deep DR alignment. Create tiers:

• Tier A (must coordinate): failure blocks recovery of critical services or violates contingency requirements.
• Tier B (coordinate lightly): failure causes material degradation but workarounds exist.
• Tier C (monitor only): minimal contingency impact.

Auditors generally expect Tier A to have the strongest artifacts.

Step 4: Obtain provider contingency artifacts (right-sized)

Request and retain what you need to prove alignment. Common acceptable inputs:

• Provider DR/BCP summary or resilience whitepaper.
• Incident response and customer notification commitments tied to outages.
• Service availability architecture overview (regions, backups, redundancy) at a level they can share.
• Recent test/exercise attestation or executive summary.
• Contract exhibits addressing disaster recovery support and restoration responsibilities.

If a provider refuses to share details, document the refusal, your compensating controls, and the business decision.

Step 5: Perform a coordination review against your contingency plan

For each Tier A provider, document a short “coordination memo” that answers:

• Assumptions: What does your plan assume the provider will do during an outage?
• Capabilities: What does the provider say they can do?
• Gaps: Where they do not meet your contingency requirements.
• Mitigations: Alternate processing, secondary region, data export cadence, escrow, manual procedures, or alternate provider path.
• Handoffs: Who calls whom, how escalation works, how status is tracked.

This is the heart of “coordinate” for CP-2(7). ¹

Step 6: Make coordination real in your runbooks

Update internal runbooks so responders can execute:

• Provider contact methods and escalation paths.
• Authentication access during outages (break-glass accounts, emergency admin procedures where permitted).
• Restoration sequence dependencies (e.g., identity must return before app admin; DNS before cutover).
• Data restore steps and validation criteria (what “good” looks like after provider restoration).

If runbooks do not mention the provider, you have not operationalized CP-2(7).

Step 7: Validate coordination via exercises and documented walk-throughs

You are not required to co-run a full DR test with every provider, but you should validate at least one of:

• Tabletop exercise that includes provider outage scenarios.
• Internal DR test that confirms your side of the handoff (failover steps, DNS changes, credential access, data restoration procedures).
• Documented review of provider test results plus your internal dependency validation.

Capture lessons learned and track actions to closure.

Step 8: Put it on a cadence and tie it to change management

Coordination breaks when vendors change platforms, regions, subcontractors, or account teams. Set triggers:

• Major provider change (architecture, region, backup approach).
• Contract renewal or material SLA change.
• After a real incident affecting availability.
• After your own contingency plan update. ²

Required evidence and artifacts to retain

Keep artifacts in an audit-ready folder mapped to each Tier A provider and each critical system.

Core evidence set (what assessors ask for first):

• Dependency map showing third parties tied to critical services and recovery assumptions.
• Provider contingency/DR documentation received (or documented refusal).
• Completed coordination memos with gap analysis and mitigations.
• Updated contingency plan sections/runbooks referencing provider roles and contact paths.
• Exercise/test records showing third-party dependency scenarios were considered, with after-action items.
• Risk acceptance or remediation tickets for unresolved gaps (with approvals).

Contract and governance evidence (often requested next):

• Contract clauses/exhibits for DR support, notification, and restoration responsibilities.
• Third-party risk assessment results specifically covering resilience and recovery.
• SLAs/SLOs relevant to continuity expectations (if applicable to your program).

Common exam/audit questions and hangups

Use these as your pre-audit checklist:

1. “Which external service providers are required to recover your top systems?”
   Hangup: teams list “critical vendors” but cannot show dependency-to-recovery mapping.

2. “Show me where your contingency plan references provider recovery and your internal handoffs.”
   Hangup: vendor info sits in procurement files, not in the contingency plan or runbooks.

3. “How did you determine the provider can meet your recovery requirements?”
   Hangup: questionnaire answers without review notes, gap treatment, or approval trail.

4. “What happens if the provider has a regional outage? What’s your workaround?”
   Hangup: no documented degrade mode or manual processing, and no decision record.

5. “Prove the process runs on a cadence and updates after changes.”
   Hangup: evidence exists once, but no refresh triggers or ownership.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails CP-2(7)	Better approach
Treating coordination as a one-time vendor questionnaire	No linkage to contingency requirements or recovery execution	Write a coordination memo tied to specific systems, RTO/RPO assumptions, and runbook steps 1
Collecting provider DR docs but not reading them	You can’t explain gaps or mitigations	Record review notes: “what we need,” “what they provide,” “what we changed”
Ignoring subcontractors (fourth parties)	Your provider’s recovery may depend on another outage-prone dependency	Require disclosure where feasible and document critical chain dependencies in your memo
No plan for “provider won’t share”	Leaves an evidence gap	Document refusal, apply compensating controls, and record risk acceptance with rationale
Runbooks lack third-party contact and escalation	Responders can’t execute under pressure	Put provider escalation paths directly into the incident/DR runbook and test the call tree

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, CP-2(7) failures tend to show up as audit findings and as real outage impacts: missed restoration expectations, unclear responsibilities, slow escalation, and preventable downtime because third-party assumptions were wrong. This is a medium-severity requirement in NIST 800-53 terms, but it becomes high-impact when the third party supports mission-essential services. ²

Practical 30/60/90-day execution plan

You asked for speed; use phases you can execute without inventing calendar promises.

First 30 days (stabilize scope and ownership)

• Assign a control owner and name accountable approvers for risk acceptance tied to third-party recovery gaps.
• Build the dependency map for critical services and identify Tier A providers.
• Add a procurement intake trigger: “Is this third party required for recovery?” If yes, route to the CP-2(7) workflow.
• Create templates: coordination memo, evidence checklist, and runbook insert.

Days 31–60 (coordinate and document)

• Collect contingency/DR artifacts from Tier A providers and store them centrally.
• Complete coordination memos for each Tier A provider, including gaps and mitigations.
• Update contingency plan/runbooks with provider-specific contacts, escalation paths, and restoration sequencing.
• Open remediation items for gaps; document interim compensating controls.

Days 61–90 (validate and operationalize)

• Run an exercise that includes at least one Tier A provider outage scenario; capture after-action items.
• Validate access paths needed during outages (contacts, portals, break-glass procedures where allowed).
• Put refresh triggers into change management and vendor management workflows.
• Prepare an “assessor packet” per Tier A provider: dependency map extract, memo, artifacts, runbook section, test/exercise evidence.

How Daydream fits (without adding process overhead)

If your pain point is evidence sprawl, Daydream can act as the system of record for CP-2(7): map the requirement to an owner, store the dependency map and coordination memos, and schedule recurring evidence requests so your assessor packet stays current. That directly addresses the most common CP-2(7) risk factor: missing implementation evidence. ¹

Frequently Asked Questions

Do we need to get a full copy of every provider’s DR plan?

No. CP-2(7) requires coordination sufficient to ensure your contingency requirements can be satisfied, which can be met with summaries, attestations, and documented gap analysis tied to your dependencies. ¹

What counts as an “external service provider” for CP-2(7)?

Any third party whose service is required to recover or operate critical functions during a disruption. Include cloud, SaaS, managed services, and outsourced business processes when they are part of the recovery path. ²

Our provider won’t share recovery test results. Are we automatically noncompliant?

Not automatically, but you need documented coordination efforts, the provider’s stated capabilities, and a recorded decision on how you address the residual risk (compensating controls or acceptance). ¹

How do we show “coordination” in a way an auditor will accept?

Provide a dependency map, a provider-specific coordination memo with gaps and mitigations, and runbooks that include provider contacts and restoration handoffs. Add evidence of an exercise or walk-through that covered third-party outage scenarios. ²

Does CP-2(7) apply to low-impact systems?

Apply it based on whether the external dependency affects your ability to satisfy contingency requirements. Many programs focus on critical services first and document rationale for lighter treatment where contingency impact is minimal. ²

Who should own CP-2(7): BCP, IT, Security, or Vendor Management?

Put accountability with the contingency planning owner, but require execution support from vendor management/procurement for contracting and from system owners for technical recovery sequences. Make risk acceptance a business decision with documented approval. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5