Alternate Processing Site | Separation from Primary Site

CP-7(1) is a deceptively small requirement with outsized audit impact: you need an alternate processing site, and it must be separated from the primary site enough to avoid common-cause failure. In practice, this control fails when teams treat “alternate site” as a procurement checkbox (“we have another region”) without proving that the alternate location is meaningfully independent from the primary location’s threat profile.

For FedRAMP and NIST-aligned programs, examiners typically look for two things: (1) an explicit identification of the alternate processing site and (2) a defensible argument that it is “sufficiently separated” based on credible threat scenarios, supported by test results. The bar is higher for systems that support mission-critical services, have tight recovery objectives, or rely on shared infrastructure that can fail regionally (power grids, telecom backbones, cloud control planes, or the same third party).

This page gives you requirement-level implementation guidance you can act on immediately: scoping, a separation decision method, step-by-step tasks, concrete artifacts to retain, common audit questions, and a practical execution plan that prioritizes what auditors ask for first.

Regulatory text

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

Operator interpretation: You must (a) name the alternate site and (b) show that its location and dependencies reduce the chance that the same disruptive event takes out both the primary and alternate sites. “Separated” is not limited to physical distance; it includes shared utilities, shared providers, and correlated regional risks. Your evidence should show the decision process and the operational reality (you can actually process workloads there).

Plain-English interpretation of the requirement

You need a backup place to run your system if the primary place fails. That backup place can’t be “too close” in risk terms. If a likely event can hit both, your alternate site is not meaningfully alternate.

Think in “common-cause failure” terms:

• One hurricane zone, same floodplain, or same wildfire corridor.
• One regional power grid or major substation.
• One metro fiber ring or telecom carrier point of presence.
• One cloud region pair that shares a control plane dependency.
• One civil disruption footprint (evacuation, curfews, access restrictions).

Your job is to pick an alternate site, map the threats that matter to your service, and document why those threats are less likely to affect both sites at once.

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers (CSPs) delivering services to federal customers under FedRAMP Moderate baselines where CP-7(1) is in scope.
• Federal agencies operating systems aligned to NIST SP 800-53.

Operational contexts where this becomes urgent:

• You claim high availability, disaster recovery, or continuity commitments in customer-facing SLAs or system security plans.
• You rely on a single data center provider, single colocation campus, or single metro area.
• You run in public cloud but deploy “multi-AZ” within one region and treat that as disaster recovery.
• Your alternate environment exists but is not sized, licensed, or permissioned to run production workloads during a disruption.

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

1) Define what “processing” must continue

Create a short list of mission-essential services and system components that must run at the alternate site. Keep it practical:

• Customer-facing APIs / portals
• Authentication and directory services dependencies
• Data stores (and whether read-only is acceptable)
• Security logging/SIEM pipeline needed for incident response

Deliverable: a scoped “alternate processing site coverage” statement tied to your contingency plan.

2) Identify candidate alternate processing sites

List realistic candidates:

• Another physical data center (owned or colo)
• Another cloud region
• Another government-authorized environment if applicable (separate boundary considerations may apply)

Record: site name, provider/third party, location (region/metro), and what workloads it can run.

3) Perform a “same-threat susceptibility” assessment (the heart of CP-7(1))

Build a short threat table for your primary site and each candidate alternate site. The goal is not perfection; it is a defensible, reviewable rationale.

Use categories that drive correlated failures:

• Natural hazards (storm systems, seismic zones, wildfire areas)
• Regional infrastructure (power grid dependencies, water supply constraints)
• Telecom and network (carrier diversity, last-mile diversity, shared peering points)
• Cloud/provider common-cause (shared control plane, shared identity plane, shared management services)
• Access constraints (travel restrictions, regional emergencies affecting staff/third parties)

Decision rule: choose the site where credible scenarios are least likely to affect both at the same time, then document the rationale as your “sufficient separation” justification. This is what you will defend in an audit.

4) Validate that the alternate site can actually process

Separation without capability is a paper control. Confirm operational readiness:

• Capacity reserved or rapidly available
• Licenses, images, infrastructure-as-code templates ready
• Secrets management and key material available under controlled break-glass
• Connectivity (VPN/peering), DNS cutover plan, and routing changes defined
• Monitoring and logging works in the alternate environment
• Staff access paths (identity, MFA, privileged access) function during an outage

5) Update contingency planning documentation

At minimum, align these artifacts:

• Contingency plan: alternate site identification, activation triggers, roles, and procedures
• Disaster recovery runbook: cutover/failback steps
• Business impact analysis: what gets restored and in what order
• Configuration management: alternate site baseline configuration and drift management approach

6) Test and capture evidence

Run a test that demonstrates “processing” at the alternate site. Tabletop-only tests often fail to satisfy operators and auditors if there is no proof that workloads can run.

Good test evidence includes:

• Change records or tickets showing test execution
• System logs from alternate site showing successful startup and processing
• Screenshots or exports from monitoring showing service health in alternate location
• Post-test report listing gaps and remediation owners

7) Operationalize ongoing review

Threat profiles change. So do cloud architectures and third-party dependencies. Add a recurring review trigger:

• Major architecture changes (new region, new data store, new network topology)
• New third party providing critical infrastructure services
• Material change in hazard exposure or facility footprint

Required evidence and artifacts to retain

Auditors want a chain of evidence from decision → implementation → test.

Keep these artifacts in a single “CP-7(1) evidence pack”:

• Alternate processing site designation (name, address/region, provider, boundary mapping)
• Separation rationale memo tied to threat scenarios and shared dependencies ¹
• Network diagrams showing connectivity, carrier diversity assumptions, DNS strategy
• Architecture diagrams showing primary vs alternate stack and shared services
• Runbooks for failover and failback, including access and key management steps
• Test plan and results demonstrating alternate processing, plus after-action items
• Third-party contracts/SOW excerpts that support capacity, access, and recovery commitments (as applicable)

Common exam/audit questions and hangups

Expect questions like:

• “Where is the alternate processing site, exactly, and what workloads run there?”
• “What does ‘sufficiently separated’ mean for your system, and who approved that judgment?”
• “Show me the threats you considered and why they won’t impact both sites.”
• “What shared dependencies remain (identity provider, CI/CD, key management, logging), and what happens if they fail?”
• “Show the last test where you processed real workload (or a representative workload) from the alternate site.”

Hangups that slow audits:

• No written separation rationale, only architecture diagrams.
• Alternate site exists but is not in scope of the system boundary you claim can recover.
• “Multi-AZ in one region” presented as disaster recovery without explaining regional common-cause risk.
• Tests prove backup restoration but not end-to-end processing.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating “another data center” as separated without checking shared utilities.
   Avoid it: document power and telecom diversity assumptions and where you cannot prove them, treat as residual risk with compensating measures.

2. Mistake: Selecting an alternate cloud region but sharing critical control-plane dependencies.
   Avoid it: map dependencies that remain global or regional (identity, DNS, key management, CI/CD) and define what “degraded mode” looks like if those services are impaired.

3. Mistake: No activation criteria.
   Avoid it: define triggers (availability thresholds, facility outage declarations, provider incident states) and the authority to declare failover.

4. Mistake: Evidence scattered across teams.
   Avoid it: keep an auditor-ready evidence pack with the latest diagrams, runbooks, and the last successful test.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should not plan on “precedent-driven” thresholds. Your risk is more operational and audit-based: if your alternate site is plausibly subject to the same threats, a disruption can become a prolonged outage. In an assessment, lack of separation rationale and proof of processing capability commonly leads to control failures or remediation findings because the requirement is explicit about susceptibility to the same threats. ¹

Practical execution plan (30/60/90)

Use this as an operator’s sequencing guide, not a promise of elapsed time.

First 30 days (Immediate)

• Assign an owner for CP-7(1) evidence and decisioning.
• Identify primary site, current “alternate,” and all critical shared dependencies.
• Draft the separation rationale memo with your threat table and leadership sign-off path.
• Confirm alternate site can run at least the minimal critical processing set.

By 60 days (Near-term)

• Update contingency plan and DR runbooks to reflect the chosen alternate site and activation triggers.
• Close capability gaps that block real processing (access, keys, capacity, DNS, monitoring).
• Run a failover test scoped to the critical processing set and collect objective evidence.

By 90 days (Operationalize)

• Address test findings and re-test the fixed items.
• Put the separation review into change management (architecture changes trigger review).
• Centralize artifacts in an evidence pack and align it to your audit calendar.
• If you manage third parties for hosting, confirm contractual recovery commitments match your design assumptions.

Where Daydream fits: If you’re tracking multiple third parties (colocation, cloud providers, managed DNS, telecom) that create correlated failure risk, Daydream helps centralize the dependency map, evidence pack ownership, and recurring review triggers so CP-7(1) stays audit-ready after architecture changes.

Frequently Asked Questions

Does “sufficiently separated” require a specific distance between sites?

CP-7(1) does not provide a distance threshold. You need a documented rationale that separation reduces exposure to the same threats for your system. ¹

Is a second Availability Zone in the same cloud region an alternate processing site?

It can be part of resilience, but CP-7(1) is about avoiding the same threats. If regional incidents or shared regional dependencies can affect both zones, document that risk and consider a regionally separate alternate site. ¹

Can a third party provide the alternate processing site?

Yes, if the third party site is identified, sufficiently separated from your primary site, and contractually/operationally able to process your workloads during an event. Keep the contract excerpts and test evidence.

What evidence convinces auditors that the alternate site can “process”?

Test artifacts that show workloads started and delivered expected outputs from the alternate location, plus runbooks and monitoring/logging evidence from that environment. Pair the test report with remediation tracking.

How often do we need to re-assess separation?

Re-assess when something material changes: your architecture, your hosting footprint, or critical third-party dependencies. Also reassess after a major test failure or a real incident that reveals correlated risk.

What if we can’t eliminate all shared dependencies between primary and alternate?

Document the shared dependencies as residual risk, define compensating measures (degraded mode, manual workarounds, alternate communications paths), and test those procedures. Auditors respond better to transparent risk treatment than to missing analysis.

Footnotes

1. NIST Special Publication 800-53 Revision 5