CP-8(3): Separation of Primary and Alternate Providers

The cp-8(3): separation of primary and alternate providers requirement is about preventing a single point of telecommunications failure from undermining continuity capabilities. In practice, teams often buy a backup internet circuit and stop there. CP-8(3) pushes you further: you must ensure the alternate service is meaningfully separated from the primary service so the two services are not susceptible to the same threats, including common carrier infrastructure, common physical routes, common facilities, or common upstream providers.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat CP-8(3) as a sourcing and verification control with clear acceptance criteria. You define “separated” for your environment, require proof from third parties during procurement, validate the technical design at each location, then test that operational failover works under realistic conditions. The control is “medium” severity in many baselines because telecommunications dependencies frequently become enterprise-wide dependencies; failure modes cascade quickly and are hard to mitigate after the fact.

This page gives requirement-level implementation guidance you can hand to network, infrastructure, and procurement teams and then assess with clean, assessor-ready evidence.

Regulatory text

Requirement (excerpt): “Obtain alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats.” ¹

Operator interpretation: You need an alternate telecommunications service (for example, secondary internet/WAN/voice connectivity) and that alternate service must be sourced from a provider that is separated from your primary provider in a way that reduces common-mode failure. “Separated” must be defensible with evidence, not a verbal assurance. ²

Plain-English interpretation

• You must have a backup telecom option.
• The backup cannot share critical dependencies with the primary option such that one incident plausibly disrupts both.
• You must be able to show how you determined separation, how you implemented it, and that it works.

Think “common-mode failure”: same carrier backbone, same last-mile path, same building demarc, same metro fiber ring, same upstream transit provider, same central office, or the same managed service provider reselling the same underlying carrier.

Who it applies to

Entities

• Federal information systems and programs adopting NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is imposed by contract, authorization boundary, or flowdown requirements. ²

Operational contexts where CP-8(3) shows up

• Data centers, cloud connectivity points, and key offices with on-prem network dependencies.
• Identity, security tooling, and business systems where loss of connectivity equals loss of mission capability.
• Call centers, SOCs, and operations teams that must remain reachable during incidents.
• Any environment with a continuity plan that assumes network reachability during a disruption.

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

1) Assign ownership and define scope

1. Name a control owner (usually Network/Infrastructure) and a governance owner (GRC).
2. Define in-scope locations and services: list sites, circuits, and telecom-dependent services that require alternate connectivity to meet your continuity objectives.
3. Set a “separation standard” you will enforce during procurement and design reviews.

Practical separation criteria you can use (pick what matches your risk):

• Different provider at the contract level and different underlying carrier (avoid reseller-to-same-carrier scenarios).
• Diverse last-mile entry points into the building (different conduit, different building entrance, different demarc room where feasible).
• Diverse physical routes (documented path diversity, not marketing language).
• No shared single CPE device that can fail both paths (or redundant CPE with clean failover).

2) Build a telecom dependency map (primary and alternate)

Create a simple dependency record per site:

• Primary provider, circuit ID, handoff type, demarc location.
• Alternate provider, circuit ID, handoff type, demarc location.
• Known shared dependencies (building MPOE, shared riser, shared fiber provider, shared upstream, same LEC/ILEC, same managed network provider).

If you cannot see upstream dependencies, document what you asked for and what you received. Auditors reward structured diligence even when providers cannot disclose everything.

3) Procure an alternate provider that is demonstrably separated

Update procurement intake and third-party due diligence so “separation” is a hard requirement, not a preference:

• Require the provider to state whether it is the underlying carrier or a reseller.
• Require written attestation of path diversity and facility diversity where applicable.
• Require circuit details (IDs, demarc, delivery media) before acceptance.

Decision matrix (use in selection):

Selection question	Pass looks like	Red flag
Is the alternate a different underlying carrier?	Carrier-of-record differs	Same carrier via reseller
Is last-mile diverse?	Different entry point or medium	Same conduit/entry point
Is the demarc independent?	Separate demarc or separate hardware	Same demarc/CPE only
Can we test failover without provider intervention?	Yes, operational runbook supports it	Failover requires ticket/escalation

4) Implement network failover with clear operational runbooks

Work with network engineers to implement:

• Dual WAN routing (BGP, SD-WAN, or policy-based routing) appropriate for your architecture.
• DNS and remote access behavior that survives ISP failover (critical for VPN/ZTNA, logging, and monitoring paths).
• Monitoring that distinguishes “primary degraded” vs “primary down,” so you can prove the alternate can carry load.

Then document:

• “Normal state” routing and “failure state” routing.
• Who approves switching, who executes, and how you communicate during an outage.

5) Test it and capture results as evidence

Test scenarios should match the threats CP-8(3) addresses:

• Hard down of the primary circuit.
• Failure of primary edge device (if shared, this is a design issue).
• Site power event with telecom impact (if alternate depends on same power and no backup, it may still be a common-mode failure).

Record:

• What failed, what shifted, time to restore connectivity, and any degraded services.
• Tickets, screenshots, and monitoring graphs demonstrating traffic moved to the alternate circuit.

6) Periodically revalidate separation (providers change)

Telecom providers merge, re-route, or change upstream relationships. Add a recurring check:

• Reconfirm underlying carrier and path diversity at renewal.
• Confirm circuit IDs and demarc locations have not changed.
• Review incident history for correlated outages that suggest shared dependencies.

Required evidence and artifacts to retain

Keep evidence in a single CP-8(3) folder (or control record) so you can answer assessors quickly.

Procurement and third-party artifacts

• Executed contracts/MSAs and order forms for primary and alternate services.
• Provider letters/attestations describing separation (carrier-of-record, route diversity, facility diversity).
• Due diligence questionnaire responses focused on telecom dependency and resilience.

Technical artifacts

• Network diagrams showing primary and alternate paths, demarc points, and edge devices.
• Circuit inventory: provider names, circuit IDs, install addresses, handoff types.
• Configuration excerpts (SD-WAN policy, routing configuration) sufficient to show failover exists.

Operational artifacts

• Failover runbook (who/what/when) tied to your continuity plan.
• Test plans and completed test results with timestamps, tickets, and monitoring outputs.
• Incident records where failover occurred in production (if applicable) and post-incident review notes.

Common exam/audit questions and hangups

Assessors tend to press on “separated.” Prepare crisp answers to:

• How did you determine the alternate is separated from the primary? Expect to show carrier-of-record evidence, attestations, and diagrams.
• Is your alternate truly independent, or is it the same provider under a different brand/reseller? Have order forms and provider statements ready.
• Show me failover testing. They will ask for the last test results, scope, and what you fixed.
• Which sites are in scope and why? Tie scope to mission/business impact and continuity planning.

Hangup you will see: teams equate “two circuits” with compliance. CP-8(3) is about threat susceptibility. Two circuits can still fail together.

Frequent implementation mistakes (and how to avoid them)

1. Buying a backup line from a reseller that rides the same underlying carrier.
   Avoidance: require carrier-of-record disclosure and document it before acceptance.

2. Assuming wireless (LTE/5G) equals separation.
   Avoidance: verify power dependency, antenna placement, and whether the wireless router backhauls over the same local infrastructure; treat it as an alternate only after a real failover test.

3. Single shared edge device for both connections.
   Avoidance: design redundant edge devices or validate that the device is highly available and does not create a new common-mode failure.

4. No evidence.
   Avoidance: create a standard evidence checklist and attach it to the procurement closeout and the continuity test cycle. Daydream can track the CP-8(3) control owner, implementation procedure, and recurring evidence artifacts so the record stays audit-ready. ¹

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source material. Practically, CP-8(3) risk shows up as:

• Extended outages because a “redundant” circuit fails in the same event as the primary.
• Business continuity plans that assume network availability but cannot execute due to telecom common-mode failure.
• Authorization or customer assessment findings when independence claims are not supported by contracts, diagrams, and test results.

Treat CP-8(3) as a resilience control with third-party dependency risk at its center: your alternate provider is a third party, and “separation” is a third-party risk requirement you must verify.

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign control owner and approvers (Network + GRC).
• Identify in-scope sites/systems and current primary/alternate circuits.
• Write your separation acceptance criteria and add it to procurement intake.
• Build the initial circuit inventory and collect existing contracts and diagrams.

By 60 days (close the biggest gaps)

• For sites without a true separated alternate, start sourcing options and require carrier-of-record and path details.
• Update network design/runbooks so failover is controlled, repeatable, and monitored.
• Implement evidence collection: attestations, order forms, diagrams, and configuration snapshots.

By 90 days (prove operation and make it repeatable)

• Execute failover tests for in-scope sites and store results with tickets and monitoring outputs.
• Remediate issues found in tests (routing, DNS, remote access dependencies).
• Set a recurring revalidation cadence tied to renewals, major network changes, and continuity testing cycles.
• In Daydream, map CP-8(3) to the control owner, implementation procedure, and recurring evidence artifacts so audits pull from a single system of record. ¹

Frequently Asked Questions

Does CP-8(3) require two different ISPs at every location?

CP-8(3) requires an alternate telecommunications service from a separated provider where continuity needs demand it. Scope it based on mission impact and document which sites require separation and which do not, with rationale.

Is a second circuit from the same provider compliant if it’s a “diverse route” product?

It can be, but you must prove separation from the same threats. If the same provider controls both, you need strong evidence of physical and facility diversity plus proof from testing that a single event is unlikely to take down both.

Can LTE/5G be the alternate provider?

Yes if it is operationally viable for your critical services and is not subject to the same failure modes as the primary. Validate performance and execute a failover test, then document constraints (for example, which applications are supported during failover).

What evidence do assessors accept for “separation” when carriers won’t disclose routes?

Keep what you can obtain: carrier-of-record documentation, written attestations, demarc details, and acceptance tests. Also document your request for route diversity information and the provider’s response to show diligence.

How do we handle SD-WAN where both circuits are managed by one MSP?

Treat the MSP as a third party dependency and verify the underlying carriers for each circuit. Require the MSP to contractually commit to separated underlying providers for primary and alternate, and retain circuit IDs and carrier documentation.

What’s the fastest way to get audit-ready if we already have two providers?

Build the evidence package: contracts/order forms, a circuit inventory, network diagrams, and a completed failover test record. Most “audit pain” comes from missing artifacts, not missing technology.

Footnotes

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

2. NIST SP 800-53 Rev. 5