CP-8: Telecommunications Services

CP-8 sits in the NIST SP 800-53 Contingency Planning (CP) family and is easy to misunderstand because it is not “just a network engineering control.” It is an availability commitment you operationalize through architecture, third-party contracting, and contingency planning discipline. The control is explicit that alternate telecommunications must work even if the outage affects either your primary site or your alternate processing/storage site. That clause catches teams that only plan for “primary site down” scenarios.

For a Compliance Officer, CCO, or GRC lead, the fastest path to implementation is to translate CP-8 into three decisions: (1) which business functions are “essential,” (2) how quickly they must resume, and (3) what telecom services (circuits, carriers, cloud connectivity, voice, messaging, remote access) those functions require to operate. Once those decisions are documented, you can assign owners to build redundancy, negotiate the right service terms with third parties, and run a realistic failover test that produces defensible evidence.

This page gives requirement-level implementation guidance you can hand to IT, Network, and Procurement, then audit against without guesswork.

Regulatory text

Requirement (excerpt): “Establish alternate telecommunications services, including necessary agreements to permit the resumption of [organization-defined operations] for essential mission and business functions within [organization-defined time period] when the primary telecommunications capabilities are unavailable at either the primary or alternate processing or storage sites.” ¹

Operator interpretation of what you must do:

1. Define the operations to resume (the essential mission/business functions and the telecom-dependent capabilities behind them).
2. Define the time period (your recovery time objective-style window for resuming those operations).
3. Provide alternate telecommunications services that are credible for those scenarios, not theoretical.
4. Put agreements in place so you can actually activate, prioritize, and pay for the alternate services under outage conditions.
   This control is part of NIST SP 800-53 Rev. 5 ².

Plain-English requirement statement (what CP-8 is really asking)

CP-8 requires you to plan and contract for telecom failover so that critical business functions can keep running (or restart quickly) when your normal connectivity is down. “Telecommunications services” includes the pathways your systems need to communicate: internet access, WAN links, carrier circuits, cloud direct connections, DNS, voice services, and remote access paths. The control also covers the uncomfortable scenario where your DR site connectivity is down or cannot support your recovery load.

Who it applies to

Entities: Federal information systems and contractor systems that handle federal data, where NIST SP 800-53 is a contractual or program requirement ².

Operational context:

• Systems with availability requirements (mission operations, regulated services, revenue-critical platforms, safety-impacting operations).
• Environments dependent on third parties for connectivity: carriers, ISPs, SD-WAN providers, colocation data centers, cloud providers, managed network service providers, voice/SMS providers.
• Organizations with an alternate processing or storage site (colocation, secondary data center, or cloud DR region), because CP-8 explicitly references primary and alternate sites ¹.

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

Step 1: Name the essential functions and the “resume within” window

Create a short CP-8 scope statement that answers:

• Which essential mission/business functions are in scope?
• What does “resumption” mean for each function (minimum viable operation)?
• What is the time window you commit to for resumption?

Practical artifact: a one-page CP-8 appendix in your contingency plan mapping essential functions to telecom dependencies and resumption targets.

Step 2: Map telecom dependencies to each essential function

For each essential function, document:

• Required network paths (internet, MPLS/WAN, VPN/remote access, DNS, cloud connectivity).
• Required providers (carrier A, ISP B, SD-WAN provider, colo cross-connect, cloud interconnect).
• Physical termination points (building entry, data hall meet-me room, cloud region).
• Hidden dependencies (voice/SMS provider used for MFA, upstream DNS hosting, managed firewall service).

Common hangup: teams stop at “we have dual ISPs” and miss dependencies like MFA SMS, upstream DNS, or a single SD-WAN controller.

Step 3: Design alternate telecom that survives the outage scenarios CP-8 calls out

Build (or validate) alternate telecom services that work when:

• Primary site telecom is unavailable.
• Alternate site telecom is unavailable.
• A regional carrier outage affects a “diverse” circuit that is not truly diverse.

Use a simple design checklist:

• Carrier diversity: different providers where feasible.
• Path diversity: separate last-mile routes and building entrances where feasible.
• Device diversity: redundant edge routers/firewalls, redundant power.
• Control plane resilience: redundant DNS, redundant VPN concentrators, redundant SD-WAN control components.
• Capacity planning: alternate links sized for degraded-but-acceptable operation.

Step 4: Put the “necessary agreements” in writing (this is where many programs fail)

CP-8 explicitly requires “necessary agreements” ¹. Work with Procurement and Legal to ensure agreements cover:

• Service descriptions for alternate connectivity (secondary circuits, on-demand bandwidth, backup internet, satellite, temporary MPLS, cloud interconnect redundancy).
• Activation terms (how to request failover, lead times, support model).
• Priority restoration or escalation paths (named contacts, 24/7 NOC, ticket SLAs).
• Any prerequisites (cross-connects, hardware, pre-provisioned ports, reserved IP space).
• Subcontractor visibility where your telecom provider depends on upstream carriers.

Third-party risk tie-in: treat telecom providers as availability-critical third parties and ensure your due diligence captures outage history, support model, and concentration risk.

Step 5: Write the runbooks and integrate with incident response and DR

Document how failover happens under pressure:

• Who declares telecom failover (Incident Commander, Network On-Call, DR Lead).
• How routing changes occur (BGP failover, DNS cutover, SD-WAN policy switch).
• How remote access is preserved (secondary VPN gateway, alternate IdP routing).
• How you communicate internally and to customers if primary comms are down.

Make sure runbooks work even when corporate email/Slack is unavailable (out-of-band contacts, phone trees, ticketing alternatives).

Step 6: Test, record results, and fix gaps

CP-8 is hard to defend without a test. Run an outage simulation that proves:

• Essential functions can resume within your defined window.
• The alternate telecom path actually carries required traffic.
• Support escalation works (you can reach providers and execute contract terms).

Capture failures as corrective actions with owners and due dates.

Required evidence and artifacts to retain

Auditors usually want proof of design, proof of contractual readiness, and proof of operation. Keep:

• CP-8 scope and dependency map (essential functions, dependencies, resumption window).
• Network architecture diagrams showing primary and alternate telecom paths, providers, termination points.
• Executed agreements: contracts, MSAs, SOWs, order forms for alternate services; any priority restoration language.
• Runbooks: failover procedures, contact lists, escalation paths, configuration references.
• Test evidence: test plan, screenshots/logs, change records, post-test report, remediation tickets.
• Change management records for telecom failover configurations (routing, DNS, VPN).
• Third-party due diligence artifacts for telecom providers (risk assessments, SLAs, support coverage).

If you use Daydream to track third-party risk and control evidence, map CP-8 to a control owner, an implementation procedure, and recurring evidence artifacts so the program does not depend on tribal knowledge.

Common exam/audit questions and hangups

Typical questions:

• “Show me the agreements that enable alternate telecommunications services.”
• “What essential functions depend on telecom, and what is your resumption timeframe?”
• “Demonstrate that your alternate path works if the DR site has a telecom outage.”
• “When did you last test failover, and what did you learn?”

Hangups that trigger findings:

• Alternate circuit exists but is not contracted, not provisioned, or not paid for.
• Diversity claims are undocumented (same carrier, same conduit, same building entry).
• Tests only prove link failover, not application resumption.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating CP-8 as “dual ISP” and moving on.
   Avoid it by mapping telecom dependencies per essential function, including DNS, MFA channels, and cloud interconnects.

2. Mistake: No “necessary agreements,” only technical intent.
   Avoid it by storing executed order forms and support terms, plus a runbook that references how to invoke them.

3. Mistake: Designing failover for the primary site only.
   Avoid it by explicitly testing scenarios where the alternate processing/storage site cannot reach required networks ¹.

4. Mistake: No evidence trail.
   Avoid it by defining the evidence set upfront (diagrams, contracts, tests) and collecting it on a recurring cadence in your GRC system.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CP-8. Practically, CP-8 failures show up as: downtime that breaches customer commitments, inability to execute DR, and adverse audit results when you cannot prove alternate telecom readiness. The risk is operational and contractual: outages become longer, recovery becomes chaotic, and third-party concentration risk becomes a single point of failure.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and evidence)

• Assign a CP-8 control owner (usually Network/Infrastructure) and a GRC coordinator.
• Document essential functions, “resume within” window, and telecom dependency map.
• Inventory existing telecom providers, circuits, cloud interconnects, DNS, voice/SMS, and remote access.
• Collect current contracts and confirm whether they cover alternate services and activation terms.

Next 60 days (close design and contracting gaps)

• Remediate single points of failure: last-mile diversity, alternate VPN/DNS paths, secondary provider where needed.
• Execute missing agreements or amend contracts for priority restoration and failover support.
• Publish runbooks and escalation contacts; align with incident response and DR procedures.

By 90 days (prove operability)

• Run a failover test that exercises alternate telecom under realistic conditions.
• Produce a test report, remediation plan, and change records.
• Stand up recurring evidence collection (quarterly or event-driven) so CP-8 stays audit-ready as telecom changes.

Frequently Asked Questions

Does CP-8 require two ISPs everywhere?

CP-8 requires alternate telecommunications services sufficient to resume essential functions within your defined window, not a specific topology ¹. In some locations, dual ISP is appropriate; in others, the alternate service may be a different connectivity method or an alternate site strategy.

What counts as “necessary agreements”?

Executed contracts, order forms, MSAs/SOWs, or written commitments that let you activate and support alternate telecom during an outage ¹. A design doc without enforceable terms usually fails this part.

If we are fully cloud-hosted, how do we meet CP-8?

Focus on alternate connectivity to your cloud environments: redundant internet egress, redundant VPN/remote access, and resilient name resolution, plus agreements that support rapid restoration. The “alternate processing or storage sites” concept still applies if you use multiple regions or DR patterns ¹.

Do we have to test CP-8?

The control text requires establishing alternate services and agreements ¹. Testing is how you prove the alternate services actually permit resumption within your defined time window during an assessment.

Can a managed service provider satisfy CP-8 for us?

A third party can operate the technical controls, but you still need documented dependencies, contractual commitments, and evidence that the alternate telecom path works. Treat the provider as an availability-critical third party and retain their test results and service terms.

What evidence is most persuasive in an audit?

A complete chain: dependency map, diagrams, executed agreements, a runbook, and a failover test report tied to corrective actions. Auditors reward coherence more than volume.

Footnotes

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

2. NIST SP 800-53 Rev. 5