CP-6(1): Separation from Primary Site

CP-6(1) sits in the Contingency Planning family and focuses on a single failure pattern: common-mode loss. If your primary storage and your backup storage sit in the same risk envelope, a single incident (regional outage, hurricane, wildfire, civil emergency, extended ISP failure, ransomware blast radius, or shared admin compromise) can remove both your production data and your recovery data. The enhancement is short, but assessments are rarely forgiving because the control is easy to “say” and surprisingly easy to implement incorrectly.

This requirement shows up most often in federal system assessments and contractor environments that handle federal information, where continuity and recoverability expectations are formalized. For a CCO or GRC lead, the fastest path to operationalizing CP-6(1) is to treat it as a decision plus proof: pick the alternate storage site, define what “sufficiently separated” means for your threat model, and keep artifacts that demonstrate the separation decision is intentional and reviewed.

You do not need a perfect DR program to satisfy CP-6(1). You do need a defensible separation rationale and repeatable evidence that your alternate storage is not exposed to the same threats as the primary site.

Regulatory text

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

Operator meaning: You must (1) name the alternate storage location(s), (2) show they are separated from the primary storage site in ways that matter for your risks, and (3) retain documentation that supports that determination and its ongoing validity. This is an identification-and-justification control, not a vague aspiration. ²

Plain-English interpretation

“Alternate storage” is where your protected copies live (backups, snapshots, replicated object storage, offline media, immutable vaults). “Sufficiently separated” means a credible disruptive event is unlikely to take out both your primary storage and your alternate storage at the same time.

Separation is broader than miles. Assessors commonly expect you to consider:

• Geographic separation: different region, metro area, or hazard zone.
• Infrastructure separation: different power grid, flood plain, seismic zone, carrier/ISP, or data center campus.
• Administrative separation: separate privileged access paths, accounts, keys, and break-glass procedures so the same compromise can’t delete both copies.
• Logical separation: network segmentation and immutability so a ransomware event doesn’t encrypt primary and backup together.

CP-6(1) does not prescribe a specific distance or topology. It requires a reasoned determination that separation reduces exposure to the same threats. ¹

Who it applies to

Entity types and environments

• Federal information systems with NIST SP 800-53 controls in scope. ²
• Contractor systems handling federal data, including environments assessed against NIST-based baselines. ²

Operational contexts where CP-6(1) commonly becomes a finding

• Single data center plus “backups” stored in the same facility.
• Cloud deployments where backups are in the same cloud region and share the same admin plane.
• Managed service arrangements where the third party’s backup location is undisclosed or not contractually committed.
• M&A or rapid migrations where storage patterns drift without governance.

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

1) Set the scope: what “storage” is in-bounds

Create a short in-scope inventory:

• Primary storage systems (databases, file storage, object storage, storage arrays).
• Backup/replication mechanisms (backup tool, snapshot policy, replication targets, vault/immutable storage).
• Data classifications relevant to contingency requirements (federal data types, mission-critical datasets).

Deliverable: Storage & backup scope statement tied to your system boundary.

2) Define “sufficient separation” for your threat model

Write criteria that an assessor can follow. Keep it practical:

• Which threats you are explicitly trying to avoid being “shared” (regional natural disasters, prolonged grid outage, shared admin compromise, shared network provider, shared facility access).
• What separation attributes count as strong evidence (separate cloud region; separate provider; separate data center campus; separate privileged identities and keys; immutability).

Deliverable: Separation criteria memo approved by the control owner.

3) Identify the alternate storage site(s)

Document:

• The alternate storage site name and type (cloud region, colocation facility, tape vault vendor, secondary data center).
• What data is stored there (which systems/datasets) and how it gets there (replication, backup jobs, snapshot replication).
• Retention and immutability properties where applicable.

Deliverable: Alternate storage site register (one page is fine if complete).

4) Prove the separation decision is defensible

For each primary-to-alternate pairing, document:

• Geographic separation (region/metro/hazard zone reasoning).
• Independence of critical dependencies (power, network, management plane).
• Admin separation (who can delete/alter backups; use of separate accounts; key separation; MFA and logging expectations).
• Single points of failure you accept and why (some shared risk is normal, but you must name it).

Deliverable: Common-mode failure analysis (lightweight table works well).

Example decision table (adapt to your environment):

Dimension	Primary storage	Alternate storage	Shared threat reduced?	Evidence you will keep
Location/hazard zone	Region A	Region B	Yes	Cloud region settings screenshot/export
Admin plane	Prod admin group	Backup admin group	Yes	IAM role policy + access review
Immutability	Writable	Immutable vault	Yes	Vault policy + retention config
Network dependency	ISP 1	ISP 2	Partially	Network diagrams + provider contract

5) Operationalize ownership and cadence

Assign a control owner who can answer: “Where are backups stored and why is this separated?” Then set recurring checks:

• Review separation assumptions when you change regions/providers, add new systems, or restructure IAM.
• Validate restore feasibility from the alternate site through recovery exercises tied to CP/DR activities.

Deliverable: Control operating procedure with triggers for review.

6) Make third parties part of the control (if applicable)

If a third party hosts your backups or your alternate site:

• Contractually require disclosure of backup location(s) and separation properties.
• Require notification before moving backup locations.
• Obtain evidence (attestation, architecture letter, or equivalent artifacts) that supports separation.

Deliverable: Third-party due diligence addendum for backup/DR providers.

Required evidence and artifacts to retain

Keep artifacts that show both the design and the operating reality:

Design-time

• Separation criteria memo and threat assumptions.
• Alternate storage site register.
• Architecture diagrams showing primary vs alternate storage flows.
• Common-mode failure analysis table (or equivalent write-up).

Operational

• Configuration exports/screenshots proving alternate-site settings (region, replication destination, vault configuration).
• Backup job configuration showing destination and retention.
• Access control evidence (IAM policies, separate roles, access reviews, break-glass procedures).
• Restore test records demonstrating you can restore from the alternate site (tie to your contingency plan artifacts under CP controls).

Tip for audit readiness: in Daydream, map CP-6(1) to a named owner, the exact implementation procedure, and a recurring evidence checklist so evidence collection is repeatable and not a scramble during assessments. ¹

Common exam/audit questions and hangups

Assessors and auditors tend to ask:

• “Show me where the alternate storage site is and why it’s sufficiently separated.”
• “Are primary and backup in the same cloud region or same facility?”
• “Who can delete backups, and is that access separated from production admin access?”
• “What threats did you consider for common-mode failure?”
• “Show evidence from the last period that backups were written to the alternate site and were restorable.”

Hangups that trigger findings:

• “We have backups” without naming the alternate site.
• “Different account” but still same region, same keys, same admin group.
• A DR site exists, but backups are still stored locally in the primary site.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating “cloud” as automatically separated.
   Avoidance: Document region-level separation and management-plane separation explicitly. “Same provider, different region” can be acceptable if you justify the threats you are reducing and the residual shared risks you accept. ¹

2. Mistake: Same credentials can destroy both primary and backup.
   Avoidance: Use separate privileged roles for backup administration, enforce strong authentication, log all destructive actions, and restrict delete permissions.

3. Mistake: Replication to a nearby site that shares the same hazard zone.
   Avoidance: Tie separation to hazards that matter in your BIA/threat assumptions, then pick an alternate site outside that envelope.

4. Mistake: No durable evidence.
   Avoidance: Store configuration exports, diagrams, and restore records in a controlled repository with versioning and a review cadence.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CP-6(1). Treat this as an assessment and mission risk control: a weak separation design can convert a manageable incident into an unrecoverable data loss event. The practical risk is that a single disruptive event affects both copies, defeating your contingency plan and creating downstream compliance exposure (availability commitments, incident response obligations, and contractual SLAs).

Practical execution plan (30/60/90)

Use phased execution without assuming fixed completion times for every environment. The goal is to reach “defensible and evidenced” quickly, then mature.

First 30 days (Immediate stabilization)

• Assign CP-6(1) control owner and backup technical owner.
• Inventory primary storage and current backup/replication targets.
• Identify whether any “backup” lives in the same facility/region/admin plane as primary.
• Draft separation criteria memo and get it approved.
• Choose the alternate site(s) for each in-scope dataset and document in a register.

By 60 days (Design closure + evidence)

• Implement or adjust replication/backup destinations to align to the separation criteria.
• Implement admin separation (separate roles, least privilege for deletes, documented break-glass).
• Capture baseline evidence: configuration exports, diagrams, access policy screenshots/exports.
• Add third-party contract/due diligence requirements where a third party provides backup/DR storage.

By 90 days (Operational validation)

• Run a restore exercise from the alternate storage site for representative systems.
• Record outcomes, gaps, and remediation actions.
• Set the ongoing review triggers (change management events) and a recurring evidence collection routine.
• In Daydream, map CP-6(1) to your owner, procedure, and recurring evidence artifacts so your next assessment is a packaging exercise, not a rebuild. ¹

Frequently Asked Questions

Does CP-6(1) require a specific minimum geographic distance?

No distance is specified in the control text. Your job is to define “sufficiently separated” based on the threats you are reducing and keep documentation that supports the rationale. ¹

If my backups are in the same cloud region as production, can I still comply?

It will be difficult to justify separation from many regional threats if both are in the same region. If you keep them in-region for technical reasons, document the residual risks and add other separation controls (immutability, admin separation), but expect scrutiny. ²

Is “a different account” enough separation?

Sometimes it helps, but CP-6(1) is about susceptibility to the same threats. If the same regional outage or hazard event can impact both, or the same privileged compromise can delete both, a different account alone is usually not a complete argument. ¹

What evidence is most persuasive to auditors?

A named alternate site, a written separation rationale, and configuration evidence showing replication/backups land there. Pair that with restore records that prove you can recover from the alternate site under realistic conditions.

How does CP-6(1) relate to third-party risk management?

If a third party provides storage or backup services, you still own the requirement. Build contract clauses and due diligence requests that force transparency on backup location and separation properties, then store that evidence with your control artifacts.

How often should we review the separation decision?

Review it whenever you change regions, providers, identity models, or backup architecture, and whenever your threat assumptions change (for example, new site risk information or updated BIA inputs). Tie the review to change management so it happens by default.

Footnotes

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

2. NIST SP 800-53 Rev. 5