CP-9(6): Redundant Secondary System

The cp-9(6): redundant secondary system requirement is a continuity and resilience expectation, not a paperwork exercise. NIST is asking for an operationally viable secondary environment that is physically separated from the primary and can be turned on fast enough to avoid meaningful business interruption, while keeping data complete and consistent. The shortest path to compliance is to treat CP-9(6) as an engineering and operations control with compliance-grade evidence: architecture that shows separation, replication that protects data, and exercises that demonstrate you can actually switch over.

For a Compliance Officer, CCO, or GRC lead, the practical work is coordinating decisions across infrastructure, application owners, security, and third parties (cloud, colocation, managed service providers). You need to translate “redundant” and “activated without loss of information or disruption” into measurable recovery objectives, then require implementation teams to meet them and produce repeatable evidence. This page gives you requirement-level guidance you can drop into a control procedure, an audit request list, and an execution plan aligned to NIST SP 800-53 Rev. 5. ¹

Regulatory text

NIST requirement (CP-9(6)): “Conduct system backup by maintaining a redundant secondary system that is not collocated with the primary system and that can be activated without loss of information or disruption to operations.” ²

What an operator must do (from that text)

You must:

1. Maintain a redundant secondary system (not only backup media). The intent is an alternate system capable of running workloads or restoring service rapidly.
2. Ensure the secondary system is not collocated with the primary system. The separation must mitigate shared building, shared campus, and shared infrastructure failures you deem credible.
3. Demonstrate activation of the secondary system without loss of information or disruption to operations. Practically, you need defined recovery objectives, replication and integrity controls, and evidence from exercises that show the switch works.

Plain-English interpretation

CP-9(6) expects “hot/warm standby” capability appropriate to your mission. If your plan is “restore from backups into a new environment,” that may satisfy baseline backup controls, but it often fails CP-9(6) because the secondary system is not truly maintained as a ready alternate. Your design should survive loss of the primary site and keep data complete enough that the business can continue with minimal interruption.

Key terms to translate into operational criteria:

• Redundant secondary system: an environment with compute, storage, network, identity dependencies, and configuration needed to run critical services or quickly take over.
• Not collocated: not subject to the same site-level hazards (power, floodplain, local outage, building access, single ISP meet-me room, same cloud region/zone).
• Activated without loss/disruption: proven failover with data consistency checks and runbooks that reduce manual improvisation.

Who it applies to

Entity scope

• Federal information systems and contractors operating systems that handle federal data under NIST SP 800-53-aligned obligations. ¹

Operational context

• Systems where downtime or data loss materially affects mission delivery, customer commitments, safety, or regulatory obligations.
• Environments with single-site concentration risk: on-prem data centers, single-region cloud deployments, or managed hosting where your “DR” is in the same facility or metro area.
• Third-party dependencies that can undermine “not collocated,” such as the same hosting provider, the same upstream network, or the same identity control plane.

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

Step 1: Define recovery objectives per system (governance first)

Create a simple system-by-system table:

• Tier (critical / important / standard)
• RTO (time to restore service) and RPO (max tolerable data loss)
• Data integrity requirements (transactional consistency, ordering, reconciliation needs)
• Dependencies (IdP, DNS, KMS/HSM, CI/CD, secrets, monitoring, ticketing)

Your CCO/GRC role: force explicit sign-off by the business owner and system owner. CP-9(6) becomes testable once objectives exist.

Step 2: Select a secondary-system pattern that can meet those objectives

Use a decision matrix:

Pattern	Typical fit	Compliance risk vs. CP-9(6)
Active/active multi-site	Highest criticality	Strong, if separation is real
Active/passive warm standby	Most regulated production apps	Strong, if routinely exercised
Pilot-light (minimal services always on)	Some internal apps	Medium, depends on activation time and data integrity
Backup-only restore into new infra	Low criticality	Often weak for CP-9(6) “redundant secondary system”

If engineering pushes “backup-only,” require a written rationale tied to system criticality and a mapping showing how it still qualifies as a maintained redundant system per CP-9(6). ²

Step 3: Prove “not collocated” with architecture evidence

Document separation in a way an assessor can validate:

• Primary and secondary sites/regions/zones with clear labels.
• Shared dependencies analysis: power, network carriers, identity, key management, admin access paths.
• Third party contracts or cloud configuration that shows the two environments are distinct.

One common audit hangup: “different availability zone” is not always persuasive if the threat model is a regional outage. Your documentation should explain why your chosen separation meets your continuity requirements.

Step 4: Implement replication and backup to support “no loss of information”

Design for data completeness and integrity:

• Replicate critical databases/storage to the secondary system with a method that matches RPO.
• Protect encryption keys so the secondary environment can decrypt data after failover.
• Include configuration, infrastructure-as-code, and secrets so “activation” is not blocked by missing dependencies.

Add integrity checks:

• Checksums, database consistency checks, reconciliation jobs, or application-level validation.
• Logging/audit trails preserved across sites so you can demonstrate what happened during failover.

Step 5: Build activation runbooks that reduce improvisation

Create runbooks that are specific and testable:

• Trigger criteria (who declares failover, what signals qualify)
• Step-by-step activation (DNS, routing, scaling, service start order)
• Security steps (break-glass access, logging, key access)
• Data validation steps (what “no loss” means and how you verify it)
• Failback procedure (return to primary safely)

Tie each runbook to a system owner and an on-call role. CP-9(6) is operational; ownership has to be operational too.

Step 6: Test failover and retain evidence

Run exercises that demonstrate:

• Secondary system can be activated.
• Services function at an acceptable level.
• Data is intact ².
• Lessons learned are tracked to remediation.

If your organization uses Daydream for control operations, configure CP-9(6) as a control with a named owner, a written procedure, and recurring evidence tasks so testing artifacts and architecture proof are collected on a schedule and ready for audits.

Required evidence and artifacts to retain

Maintain an “audit-ready packet” per in-scope system:

• Architecture diagrams showing primary vs. secondary location and separation rationale.
• Inventory mapping of critical services and dependencies to secondary equivalents.
• Replication configuration evidence (screenshots/exports/config files) and data flow diagrams.
• Runbooks for failover/failback, including roles and approvals.
• Test plans and results: date, scope, success criteria, issues found, remediation tickets.
• Data integrity proof from tests (validation logs, reconciliation outputs).
• Access controls for DR: break-glass procedure, audit logs of privileged actions.
• Third-party attestations/contract terms relevant to DR location and availability, when the secondary system is hosted externally.

Common exam/audit questions and hangups

Auditors typically press on four points:

1. Is the secondary system truly “maintained,” or is it just backups?
2. Is it actually not collocated? Show clear separation and address shared dependencies.
3. Can you activate it fast enough for your business needs? This is where your RTO/RPO and test evidence matter.
4. How do you know there was no data loss? Provide your validation method, not just “replication was enabled.”

Expect requests for the most recent failover test and evidence that issues were closed, not just recorded.

Frequent implementation mistakes and how to avoid them

• Mistake: Secondary site shares a hidden single point of failure. Example: same identity provider tenant without DR access plan, or same KMS boundary with no cross-site recovery.
  Avoidance: dependency mapping with explicit recovery steps for each shared service.

• Mistake: “Not collocated” is interpreted narrowly as “different rack.”
  Avoidance: document credible site-level failure scenarios and show how the secondary system remains available.

• Mistake: Runbooks exist but are untested or outdated.
  Avoidance: require evidence from exercises and track runbook review as a recurring control activity.

• Mistake: Data integrity is assumed rather than verified.
  Avoidance: define “no loss of information” per system and implement a verification checklist (transaction counts, reconciliation, consistency checks).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat CP-9(6) as an assessment-driven expectation rather than a penalty-cited rule. The practical risk is straightforward: if a site outage or ransomware event occurs, inability to activate a non-collocated secondary system can turn an incident into prolonged downtime, contractual breaches, and reportable operational disruption. The control also reduces concentration risk introduced by third parties hosting your primary environment.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and decisions)

• Confirm in-scope systems and rank them by criticality.
• Set RTO/RPO targets and obtain business owner sign-off.
• Document current-state architecture and identify whether your “DR” is truly non-collocated.
• Assign a control owner and define the evidence you will produce each cycle.

Days 31–60 (build the secondary system capability)

• Choose a secondary-system pattern per system tier.
• Implement or tighten replication, key availability, and dependency readiness in the secondary site.
• Draft failover/failback runbooks with named roles and approval workflow.
• Stand up monitoring that proves replication health and readiness.

Days 61–90 (prove it works and make it repeatable)

• Execute failover tests for the highest-criticality systems first.
• Capture evidence: test plan, logs, data integrity checks, issues, and remediation tickets.
• Update runbooks and architecture documentation based on findings.
• Operationalize recurring evidence collection in a GRC workflow (Daydream fits well here when you want owners, procedures, and evidence tasks in one place).

Frequently Asked Questions

Does CP-9(6) require a hot site?

CP-9(6) requires a maintained redundant secondary system that can be activated without information loss or operational disruption. Whether that is “hot” depends on your recovery objectives and what your test evidence shows. ²

Is “a different availability zone” considered not collocated?

It can be, but you need a defensible separation rationale. Document what failures you are designing for (zone, region, metro outage) and show the secondary system remains viable under those scenarios.

Can we meet CP-9(6) with backups plus infrastructure-as-code?

Sometimes, but assessors often view “backup-only restore” as weaker than a maintained standby system. If you take this approach, document how the secondary system is maintained and prove activation and data integrity through exercises. ²

What evidence is most persuasive in an audit?

Recent failover test results tied to defined RTO/RPO, plus data integrity validation outputs and updated runbooks. Architecture diagrams that clearly show non-collocation prevent long debates.

How do third parties affect CP-9(6)?

If a third party hosts the primary system, your secondary system design must address shared-provider and shared-region risk. Keep contracts, service descriptions, and configuration proof that demonstrate separation and recoverability.

How should a GRC team operationalize CP-9(6) without owning infrastructure?

Make CP-9(6) measurable: set recovery objectives, require architecture and test evidence, and assign accountable technical owners. Track testing and remediation in a control workflow so evidence is produced on a predictable cadence.

Footnotes

1. NIST SP 800-53 Rev. 5

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