CP-7(1): Separation from Primary Site

To meet the cp-7(1): separation from primary site requirement, you must designate an alternate processing site far enough from your primary site that the same disruptive event is unlikely to take out both, and you must be able to justify that separation against credible threat scenarios. Document the rationale, validate it in contingency testing, and keep evidence current. ¹

Key takeaways:

• CP-7(1) is a site-selection and risk-justification requirement, not a generic “have backups” checkbox. ¹
• “Sufficient separation” must be defensible against shared threats (power grid, flood plain, seismic zone, regional carrier outage, civil disruption). ¹
• Auditors look for documented threat-based reasoning, defined criteria, and test evidence tying the alternate site to recovery objectives. ²

CP-7(1) is one of the fastest ways a continuity program fails an assessment: teams can show backups, cloud redundancy, and DR runbooks, but cannot show that their alternate processing site is genuinely independent of the primary site’s risk envelope. The control language is short, but it forces a concrete operational decision: where recovery will occur, why that location is meaningfully separated, and how you know it reduces susceptibility to the same threats. ¹

For a Compliance Officer, CCO, or GRC lead, “operationalizing” CP-7(1) means turning an abstract phrase (“sufficiently separated”) into written criteria your infrastructure and procurement teams can follow, then capturing evidence that the criteria are met. This includes cloud deployments, colocation, on-prem data centers, and third-party hosted processing. If a single regional incident could impact both your primary and alternate site, you have a CP-7(1) exposure even if the environment is technically redundant. ²

This page gives requirement-level implementation guidance you can put into a control procedure, map to owners, and support in an audit with clean artifacts.

Regulatory text

Requirement (verbatim): “Identify an alternate processing site that is sufficiently separated from the primary processing site to reduce susceptibility to the same threats.” ¹

What the operator must do:

1. Identify the alternate processing site used for contingency operations (disaster recovery, major outage recovery, continuity of processing). ¹
2. Demonstrate “sufficient separation” between primary and alternate sites based on the threats that matter to your system and mission. ¹
3. Show the separation reduces shared susceptibility (same storm track, same flood plain, same regional power dependency, same carrier hotel, same geopolitical/civil risk area). Your justification must connect the location decision to threat reduction, not convenience. ¹

Plain-English interpretation of the requirement

CP-7(1) requires you to avoid “two sites, one disaster.” The alternate site has to be far enough, and independent enough, that a likely disruptive event at the primary site is unlikely to disable the alternate site at the same time. “Sufficiently separated” is intentionally flexible; your job is to define what it means for your environment and document the reasoning. ¹

This is not limited to physical distance. Separation can fail even with different buildings if both depend on:

• the same regional electrical grid and transmission corridor,
• the same metro-area telecom aggregation point,
• the same flood zone or wildfire interface,
• the same cloud region or shared control plane dependency.

Who it applies to (entity and operational context)

CP-7(1) commonly applies where NIST SP 800-53 is in scope, including:

• Federal information systems subject to NIST SP 800-53 controls. ²
• Contractor systems handling federal data, including systems supporting federal missions or storing/processing federal information under contract. ²

Operationally, it applies to any system where you claim you can recover processing at an alternate site, including:

• on-prem primary with colocation DR,
• dual data centers,
• cloud primary with “DR in another region,”
• SaaS/PaaS/IaaS where the alternate site is owned/operated by a third party and you must validate their location strategy.

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

1) Assign ownership and define scope

• Control owner: usually the BCDR lead, Head of Infrastructure/Cloud, or SRE manager; GRC owns oversight and evidence quality.
• System scope: list the systems and workloads that require alternate-site recovery, and explicitly name the “alternate processing site” per system (facility, region, or provider location construct).
  Practical tip: if you have multiple tiers, define “alternate site” for each tier that has distinct recovery patterns (for example, core transaction processing vs. analytics). Keep it simple enough to audit.

2) Define “sufficient separation” criteria you can defend

Write criteria that reflect your threat model. You do not need a single magic number; you need documented, repeatable decision rules.

A workable criteria set often includes:

• Geographic independence: different hazard region(s) relevant to your location risks (flood, hurricane, wildfire, seismic).
• Critical infrastructure independence: avoid shared single points like the same primary utility substation corridor or the same metro fiber aggregation point when feasible.
• Cloud independence (if applicable): separate cloud regions (and, where realistic, separate dependencies such as identity, DNS, and key management patterns).
• Third-party concentration risk: if both sites rely on the same colocation operator, carrier, or managed service provider, document why that does not recreate a shared failure mode.

Your criteria should be written as “must/should” statements with exceptions governed through risk acceptance.

3) Perform a shared-threat analysis (and keep it auditable)

Create a short analysis that ties credible threats to site separation choices. Keep it evidence-based and operationally legible:

• Identify the top shared-threat categories for the primary site (natural hazards, regional utilities, telecom concentration, civil disruption, regional cloud outage).
• For each threat category, state whether the alternate site is exposed to the same threat and why.
• If exposure remains (it often will), document compensating measures and whether the residual risk is accepted.

This becomes your “CP-7(1) separation rationale” artifact.

4) Select/design the alternate site and document it precisely

Your documentation should answer:

• What is the alternate site (address/facility or cloud region identifier)?
• What workloads fail over there?
• What are the dependencies needed for it to operate (identity, networking, encryption keys, upstream providers)?
• How do you activate it (manual vs. automated), and who approves?

If you rely on a third party (cloud, SaaS, DR provider), ensure the contract or service description identifies the location/region approach well enough to support your rationale. CP-7(1) is still your obligation when you are the system owner.

5) Integrate separation requirements into procurement and architecture review

Operationalize the control by making it hard to violate:

• Add a DR site separation checklist to architecture review.
• Add location/separation requirements to third-party due diligence and contract intake for hosting providers.
• Require GRC sign-off for exceptions (documented risk acceptance).

Daydream (used appropriately) fits here as a workflow layer: map CP-7(1) to an owner, embed the separation checklist into intake, and set recurring evidence tasks so this does not degrade over time.

6) Validate through contingency testing and change management

Even though CP-7(1) is about site separation, auditors often test whether your DR posture actually corresponds to the site you claim.

• Ensure contingency test scopes include failover to the alternate site and confirm dependencies work there.
• Tie material changes (data center moves, cloud region changes, carrier changes) to a required update of the separation rationale.

Required evidence and artifacts to retain

Keep artifacts in a single “CP-7(1) evidence packet” per system:

1. Control statement / procedure describing how you identify and approve alternate sites and what “sufficient separation” means in your organization. ¹
2. Alternate site designation: named facility/region and the workloads covered.
3. Separation rationale (shared-threat analysis) showing how separation reduces susceptibility to the same threats. ¹
4. Network and dependency diagrams showing major dependencies that could reintroduce shared risk (identity, DNS, key management, connectivity).
5. Contingency test evidence demonstrating the alternate site is used as intended (test plan, results, issues, remediation tickets).
6. Exception log and risk acceptances for cases where full separation is not feasible.

Common exam/audit questions and hangups

Expect assessors to ask:

• “Show me where the alternate processing site is identified, by system.” ¹
• “Why is this separation sufficient? What threats did you consider?” ¹
• “Does your alternate site share the same power grid/telecom corridor/cloud region?”
• “How do you keep this current when architecture changes?”
• “Where is the evidence that DR tests actually exercised the alternate site?”

Common hangup: teams describe replication and backups, but cannot articulate the threat-based separation argument that CP-7(1) explicitly requires. ¹

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating “another availability zone” as an alternate site without threat analysis

Avoidance: document what threats are mitigated by AZ-level separation and which threats remain regional. If your threats include regional disruption, AZ separation alone may not satisfy your own criteria.

Mistake 2: Failing to account for shared dependencies

Two sites can fail together due to shared identity, DNS, key management, or a single network interconnect. Avoidance: include a dependency map in the evidence packet and test those dependencies during failover.

Mistake 3: Relying on third-party assurances without location clarity

If a third party says “we are resilient,” that is not a separation rationale. Avoidance: get clear region/site information and document how it reduces shared susceptibility, or record a risk acceptance.

Mistake 4: No operational trigger to re-evaluate separation

Separation decays when sites move or cloud regions change. Avoidance: add a change-management control: any change to hosting location, carrier, or DR strategy triggers an update to the CP-7(1) rationale.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific actions or penalties.

Practically, CP-7(1) failures show up as:

• continuity findings (unable to demonstrate survivability against plausible scenarios),
• authorization-to-operate friction (insufficient evidence for contingency planning controls),
• material operational risk: correlated regional failures that break both primary and recovery paths.

A practical 30/60/90-day execution plan

First 30 days (stabilize and document)

• Assign a control owner and backups; confirm system scope.
• Inventory each system’s stated alternate processing site (facility/region/provider).
• Draft “sufficient separation” criteria and an exception process.
• Create a standardized separation rationale template and evidence packet structure.

By 60 days (validate and close obvious gaps)

• Complete shared-threat analysis for highest-impact systems first.
• Review dependency diagrams for correlated failure paths; open remediation tickets where needed.
• Update third-party intake to capture site/region and separation commitments.
• Schedule or adjust contingency tests to include alternate-site activation where feasible.

By 90 days (operationalize and make it repeatable)

• Run at least one contingency exercise that demonstrates the alternate site path for in-scope critical systems, then document results and fixes.
• Finalize governance: architecture review gate, change-management triggers, and exception approvals.
• Implement recurring evidence collection (for example, quarterly evidence refresh tied to change events) in your GRC system; Daydream can track owners, tasks, and audit-ready packets without relying on institutional memory.

Frequently Asked Questions

Does CP-7(1) require a specific distance between sites?

The requirement does not specify a distance; it requires “sufficient” separation to reduce susceptibility to the same threats. Define defensible criteria based on your threat scenarios and document the rationale. ¹

If we are fully in cloud, what counts as an “alternate processing site”?

Typically it is a separate cloud region or equivalent construct you can name and test. You still need to show that the alternate site reduces exposure to the same threats and does not share critical dependencies that recreate correlated failure. ¹

Can a third party’s DR site satisfy CP-7(1) for us?

Yes, but you need enough transparency to identify the alternate site concept (region/facility) and justify separation. If the third party will not provide location details, document the limitation and route it through your exception process. ²

What evidence do auditors usually expect for “sufficiently separated”?

A written separation rationale tied to credible threats, plus documentation that names the alternate site and shows it is part of tested recovery procedures. Diagrams and test results help because they expose shared dependencies. ¹

Our alternate site is separated, but both sites depend on the same identity provider. Is that a CP-7(1) issue?

It can be, because shared dependencies can reintroduce susceptibility to the same threat. Document the dependency, add compensating controls (for example, break-glass access patterns), and test recovery with that dependency impaired.

How do we keep CP-7(1) current as architecture changes?

Tie CP-7(1) to change management: any change to hosting location, DR topology, carriers, or core shared services triggers an update to the separation rationale and evidence packet. Track ownership and recurring evidence tasks in your GRC workflow.

Footnotes

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

2. NIST SP 800-53 Rev. 5