CP-9(3): Separate Storage for Critical Information

The cp-9(3): separate storage for critical information requirement is a resilience control with a simple intent: a single building-level event (fire, flood, power incident, suppression discharge, localized sabotage) should not destroy both your operational system and the backups you need to recover it. CP-9(3) pushes you past “we take backups” into “our backups survive the same disaster that takes production down.”

For a Compliance Officer, CCO, or GRC lead, the fastest path to implementation is to treat CP-9(3) as a scoping and evidence problem. First, decide what qualifies as “critical information” for your system boundary (data sets, system images, configurations, crypto materials, and recovery runbooks). Second, confirm that at least one backup copy is stored either (a) in a separate facility, or (b) in a fire-rated container that is not collocated with production. Third, document the design choice and run a restore test that proves the separated copy is usable.

This page gives requirement-level guidance you can hand to IT/Cloud Ops, Infrastructure, and Facilities and then audit quickly.

Regulatory text

Requirement (quoted): “Store backup copies of {{ insert: param, cp-09.03_odp }} in a separate facility or in a fire rated container that is not collocated with the operational system.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do: ensure that backup copies of the defined critical information exist in a storage location that is not collocated with the operational system. You meet this by:

• Storing backups in a separate facility (common for offsite tape vaulting, secondary datacenters, or physically distinct storage sites), or
• Storing backups in a fire-rated container that is not collocated with the operational system (a physical control typically relevant for on-prem media handling).

This is an enhancement to CP-9 in NIST SP 800-53 Rev. 5, so assessors typically expect you to show both: (1) the underlying backup program exists, and (2) CP-9(3) adds survivability through physical separation. (NIST SP 800-53 Rev. 5)

Plain-English interpretation

If the server room (or primary hosting location) is destroyed or inaccessible, you still need a backup copy of the information that matters most to restore operations. CP-9(3) is satisfied only when you can point to a backup copy that would survive a facility-level incident affecting production.

Two practical interpretations that hold up in audits:

• “Separate facility” means a different physical site with independent exposure to building-level hazards.
• “Not collocated” means the backup cannot be in the same room, cage, suite, or building as the production system if the common disaster scenario would take both out.

Who it applies to (entity and operational context)

You should treat CP-9(3) as in-scope when you operate or manage:

• Federal information systems, or
• Contractor systems handling federal data where NIST SP 800-53 is contractually flowed down or mapped into your control baseline. (NIST SP 800-53 Rev. 5)

Operationally, the requirement commonly lands on:

• Data center / infrastructure teams (on-prem and colocation)
• Cloud platform teams (if you treat “separate facility” as distinct physical location under the provider’s controls, you still need to document how your design meets the intent)
• Backup administrators (backup architecture, retention, encryption key handling)
• Facilities and physical security (fire-rated containers, access controls, offsite media logistics)
• GRC (scoping, policy language, evidence, assessment support)

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

Step 1: Define “critical information” for your system boundary

CP-9(3) references a parameter for what counts as critical information. Don’t leave it implied. Create a short, explicit scope statement that names the categories you will protect, for example:

• Tier-0 operational data stores (customer records, mission data)
• System images or golden AMIs (if used for rebuild)
• Configuration backups (network device configs, IaC state, secrets manager exports where permitted)
• Identity and key material needed for restore (with special handling)

Deliverable: Critical Information Backup Scope (one page) tied to the system inventory. Keep it assessor-readable and aligned to your BIA/impact analysis if you have one.

Step 2: Inventory backup sets and map each to a separated storage location

Build a mapping table that answers, for each critical data set:

• What is backed up?
• Where is the backup copy stored?
• Is that storage “separate facility” or “fire-rated container not collocated”?
• Who owns it?
• How do you restore from that copy?

A lightweight table is enough, but it must be complete for the critical scope.

Step 3: Choose the separation method and document the rationale

You have two compliant design patterns under the text:

1. Separate facility: back up to a physically distinct site.
2. Fire-rated container (not collocated): store backup media in a fire-rated container that is not collocated with production.

Document:

• The chosen method per backup set
• The “non-collocation” reasoning (what constitutes collocation in your environment)
• Any dependencies (e.g., if restoring requires specific network paths, credentials, or key access procedures)

Assessors will look for your reasoning to match real failure modes. If your backup is in the same facility as production, you should assume you do not meet CP-9(3), even if it is on different hardware.

Step 4: Implement access controls and handling requirements for the separated copy

CP-9(3) is about location, but audits often expand into “show me it’s protected.” Minimum operational controls you should standardize:

• Restricted access to backup storage locations (physical and/or administrative)
• Change control for backup configuration
• Documented chain-of-custody for removable media (if used)
• Clear restore authorization path (who can initiate a restore, who approves)

If a third party stores or transports backups (vaulting, offsite storage, managed backup), fold this into third-party due diligence: contract terms, access controls, incident reporting, and evidence rights.

Step 5: Prove recoverability from the separated copy

A separated backup that cannot be restored is dead weight in an assessment. Run and record a restore test that:

• Uses the separated backup location as the source, and
• Demonstrates you can recover the critical information within your operational expectations.

Keep the evidence tightly tied to the CP-9(3) scope. Don’t drown the assessor in generic DR testing if it doesn’t show the separated copy worked.

Step 6: Operationalize recurring evidence collection (so you’re always audit-ready)

Assign a control owner and set a recurring evidence cadence that captures:

• Backup job summaries showing completion for in-scope systems
• Storage location confirmations (offsite vault receipts, storage configuration snapshots, or provider attestations where applicable)
• Restore test results and issue remediation tickets

Daydream (as a GRC workflow layer) fits cleanly here: map CP-9(3) to an owner, document the procedure, then attach the same evidence types each cycle so assessments become retrieval, not archaeology.

Required evidence and artifacts to retain

Use this as your evidence checklist:

Control design (static)

• Backup policy or standard referencing separated storage for critical information
• “Critical information” scope definition for the system boundary
• Architecture diagram or written description showing backup copy separation approach
• Role/owner assignment for CP-9(3), with responsibilities

Control operation (recurring)

• Backup inventory / mapping table (critical dataset → backup set → separated location)
• Backup job success reports for in-scope assets
• Evidence of separate facility storage (contracts, receipts, storage location documentation) or fire-rated container controls (container specs, location, access list)
• Restore test records demonstrating restore from the separated copy
• Exceptions register (any systems not meeting separation, with risk acceptance and remediation plan)

Common exam/audit questions and hangups

Expect these questions, and prepare the “one-click” proof:

• “Define ‘critical information’ for this system. Where is it written?”
• “Show me that the backup copy is not collocated with production.”
• “Which backup copy would survive a facility-level incident?”
• “Can you restore from the separated backup? Show the last test.”
• “Who has access to the offsite backups, and how is that access reviewed?”
• “If you rely on a third party for storage or transport, what oversight evidence do you have?”

Hangups that stall audits:

• Confusing logical separation (separate account, separate subnet) with physical separation (separate facility). CP-9(3) is explicit about non-collocation.
• Having a policy statement but no mapping of which backup sets satisfy the requirement.

Frequent implementation mistakes and how to avoid them

1. Backups in the same building, different room.
   Fix: treat “collocated” as a building-level risk unless you have a documented and defensible separation boundary. If the same fire suppresses both rooms, you failed the intent.

2. Offsite copy exists, but it’s incomplete or excluded from critical scope.
   Fix: build the dataset-to-backup mapping and validate coverage for the defined critical information.

3. Restore depends on credentials/keys stored only in the primary facility.
   Fix: include recovery-critical credentials and key access procedures in the recovery plan, with protected, separated availability.

4. Third party stores backups, but oversight evidence is missing.
   Fix: keep contracts, service descriptions, and periodic confirmations. Tie them to the backup mapping table.

5. No assessor-friendly explanation.
   Fix: write a short “CP-9(3) implementation narrative” that points to the table, the diagram, and the restore test evidence.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat CP-9(3) primarily as an assessment and authorization risk: failure commonly results in audit findings, delayed ATO decisions, or remediation plans that force architectural change late in the lifecycle. (NIST SP 800-53 Rev. 5)

Operationally, the risk is straightforward: a localized disaster can destroy both production and backups, turning a routine recovery into a prolonged outage or permanent loss of critical records. CP-9(3) reduces that single-point-of-failure.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope + visibility)

• Name the CP-9(3) control owner and backups technical owner; record responsibilities.
• Publish a one-page definition of “critical information” for the system boundary.
• Build the mapping table: critical datasets → backup sets → storage locations → separation method.
• Identify gaps where backups are collocated with production; open remediation tickets and document interim risk acceptance where needed.

Day 31–60 (implement separation + tighten operations)

• Implement the selected separation method for every critical dataset (separate facility or fire-rated container not collocated).
• Update backup procedures so new critical systems cannot go live without a separated backup copy.
• Confirm access controls for offsite storage and define restore authorization steps.

Day 61–90 (prove + make it repeatable)

• Run a restore test that sources from the separated copy for representative critical datasets.
• Package evidence: scope statement, mapping table, separation rationale, and restore test report.
• Set a recurring evidence routine inside your GRC system (Daydream or equivalent) so each cycle produces the same artifacts without rework.

Frequently Asked Questions

What qualifies as “separate facility” for CP-9(3)?

The requirement calls for a location that is not collocated with the operational system, which generally means a different physical site. Document your definition and show how the separated backup would survive the same facility-level incident. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Do cloud backups automatically meet CP-9(3)?

Not automatically. You need evidence that your backup copy is stored in a way that is not collocated with the operational system and that it aligns to the requirement’s intent. Write down your architecture choice and keep restore test proof. (NIST SP 800-53 Rev. 5)

If we use a fire-rated container, can it be in the same building as production?

The text requires the container to be “not collocated with the operational system,” so placing it in the same facility usually creates a collocation problem. If you propose a same-building design, be ready with a defensible, documented separation boundary and assessor buy-in. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What evidence is most persuasive to an assessor?

A clean mapping of critical information to backup sets and storage locations, plus a restore test showing recovery from the separated copy. Pair that with a short narrative that explains your non-collocation logic. (NIST SP 800-53 Rev. 5)

How should we handle third parties that store or transport our backups?

Treat them as in-scope third parties for due diligence and oversight. Keep contracts, service descriptions, and any periodic confirmations that the separated storage requirement is met and access is controlled.

What if only some critical systems have separated backups today?

Document the gap as an exception with a time-bound remediation plan, and prioritize the systems that drive mission operations first. Keep the exception register and remediation tickets with your CP-9(3) evidence package so the risk is explicit.