CP-6(2): Recovery Time and Recovery Point Objectives

CP-6(2) requires you to configure your alternate storage site so data backups, replication, access paths, and recovery procedures can meet defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). Operationally, you must translate system RTO/RPO targets into storage architecture settings, replication schedules, restore workflows, and test evidence that proves you can recover within those objectives. ¹

Key takeaways:

• Your alternate storage site design must be driven by documented RTO/RPO per system and data set, not by “standard backup settings.” ¹
• Auditors look for traceability: RTO/RPO → storage configuration → recovery runbooks → test results and corrective actions. ¹
• The fastest path is to assign a control owner, define recurring evidence, and operationalize testing so compliance is repeatable. ¹

The cp-6(2): recovery time and recovery point objectives requirement sits in Contingency Planning and focuses on one practical question: “Can we actually recover our data fast enough, and with acceptable data loss, using the alternate storage site we claim to have?” CP-6(2) is narrower than general disaster recovery planning. It is specifically about configuring the alternate storage site so recovery operations can meet the RTO/RPO your business and mission require. ¹

For a CCO or GRC lead, the work is mostly governance and evidence design, but you will need tight coordination with infrastructure, storage/backup engineering, cloud platform teams, application owners, and incident response/BCP stakeholders. The control fails most often for two reasons: (1) RTO/RPO exist on paper but do not drive real configuration decisions, or (2) the environment could meet objectives “in theory,” but you cannot prove it through repeatable testing and retained artifacts.

This page gives requirement-level implementation guidance you can put into a ticket queue and a control test plan. It emphasizes traceability, measurable outcomes, and the evidence package an assessor will expect.

Requirement focus: CP-6(2) in one line

Configure the alternate storage site to facilitate recovery operations in accordance with recovery time and recovery point objectives. ¹

Plain-English interpretation

You must set up the alternate storage location (cloud region, second data center, separate account, offsite backup vault, or managed backup service) so it can restore systems and data within your required:

• RTO: how quickly service/data must be recovered after an outage.
• RPO: how much data loss (time) is acceptable, measured from the last recoverable point.

CP-6(2) is not satisfied by “we have backups.” It requires that backup/replication configuration and recovery operations (access, restore, failover mechanics, and runbooks) are aligned to the RTO/RPO targets you claim to meet. ¹

Regulatory text

“Configure the alternate storage site to facilitate recovery operations in accordance with recovery time and recovery point objectives.” ¹

Operator translation (what you must do):

1. Define RTO/RPO targets for systems and the data they depend on (tiering is fine).
2. Engineer the alternate storage site (replication method, backup frequency, retention, immutability, access controls, connectivity, encryption, key availability, restore automation) so those targets are achievable.
3. Prove it works through recovery exercises and retain artifacts that show achieved recovery times and achieved recovery points match the objectives. ¹

Who it applies to

Entity scope

• Federal information systems and contractor systems that handle federal data commonly adopt NIST SP 800-53 controls, including CP-6(2). ²

Operational scope (what kinds of environments trigger the work)

• Central backup platforms (on-prem or cloud)
• Storage replication between regions/sites/accounts
• DR architectures using warm standby or active-active patterns
• Critical SaaS workloads where you control backup/exports into your own alternate storage site
• Any system where downtime or data loss creates mission, safety, legal, or contractual exposure

If a third party provides backup/DR services, CP-6(2) still lands on you. You can inherit capabilities, but you must collect evidence and ensure the third party’s design matches your RTO/RPO.

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

Step 1: Assign ownership and define the control boundary

• Name a control owner (often Infrastructure/DR lead) and a GRC owner responsible for evidence.
• Define what counts as the “alternate storage site” for each system (example: secondary cloud region plus backup vault, or separate provider).

Practical tip: If teams argue whether “the alternate site” is backups vs replicated disks vs snapshots, your scope is unclear. Resolve this in writing before you ask engineers for evidence.

Step 2: Establish RTO/RPO requirements per system (and per data class where needed)

Create a simple matrix:

System	Data store(s)	RTO target	RPO target	Basis (BIA/mission need)	Owner

Keep it operator-friendly. Assessors want to see that targets exist and are approved.

Common hangup: Teams set one RTO/RPO for an entire application but ignore dependencies (identity, DNS, key management, message queues). Your recovery will fail if the alternate storage site cannot restore the dependency chain.

Step 3: Translate RTO/RPO into storage configuration requirements

Convert targets into implementable settings. Examples you can put into tickets:

• Replication/backup frequency aligned to RPO (e.g., continuous replication vs periodic backups).
• Restore performance aligned to RTO (e.g., pre-provisioned capacity, scripted restores, tested throughput).
• Retention and versioning so you can recover from corruption/ransomware, not just outages.
• Immutability and access controls so backups cannot be modified by compromised admin credentials.
• Key availability (KMS/HSM) in the recovery context; encryption without recoverable keys breaks RTO.

CP-6(2) is explicitly about configuring the alternate storage site to facilitate recovery operations against RTO/RPO. That means configuration must reflect recovery reality, not only backup creation. ¹

Step 4: Implement and document the recovery workflow (runbooks)

For each in-scope system, document:

• Preconditions (network, identity, privileged access, break-glass)
• Restore steps (where data comes from, how to validate)
• Expected recovery point and recovery time based on test results
• Roles and escalation paths

Make it executable: runbooks should include exact console paths/commands where appropriate, plus decision points (restore vs failover vs rebuild).

Step 5: Test against objectives and record results

Run recovery exercises that measure:

• Achieved RTO: time from declaration/start to service/data availability (define start/stop points clearly).
• Achieved RPO: timestamp/sequence of last consistent recoverable data.

Record gaps and corrective actions. CP-6(2) becomes easy to assess when you can show “objective → test → result → fix.” ¹

Step 6: Operationalize recurring evidence

Define an evidence calendar and standard artifacts (see below). This is where many programs fail: they do the engineering once, then cannot reproduce proof during an assessment.

Where Daydream fits naturally: Daydream helps you map CP-6(2) to a named owner, a standard implementation procedure, and recurring evidence artifacts so the control remains testable across systems and third parties without rebuilding the story every audit. ¹

Required evidence and artifacts to retain

Keep artifacts tied to each in-scope system:

Governance

• Approved RTO/RPO matrix (system tiering and owners)
• Control narrative describing the alternate storage site design and how it meets RTO/RPO ¹

Technical configuration evidence

• Backup/replication configuration exports or screenshots (frequency, destinations, retention, immutability)
• Architecture diagrams showing primary to alternate storage flows
• Access control listings for backup vaults/storage accounts (who can delete, who can restore)

Recovery operations evidence

• Recovery runbooks with version history
• Test plans and test results showing achieved RTO and achieved RPO
• After-action reports with remediation tickets and closure evidence

Third-party evidence (if applicable)

• Contract/SLA language for recovery capabilities
• Third-party test reports or attestations tied to your RTO/RPO needs
• Your internal validation of restore access and procedures (tabletop or technical test)

Common exam/audit questions and hangups

Expect questions like:

• “Show me where RTO/RPO are defined and approved for this system.” ¹
• “Prove your alternate storage site configuration can meet the RPO you claim. What is the backup frequency and where is it enforced?” ¹
• “Walk me through a restore. Who can do it? How do you get credentials during an outage?”
• “Show the last recovery test result and the corrective actions.”
• “What is the scope of systems covered by this alternate storage site?”

Hangup to preempt: If the assessor asks for achieved RTO/RPO and you only have a policy statement, you will end up in a finding even if the technology is capable.

Frequent implementation mistakes (and how to avoid them)

1. RTO/RPO are generic and not tied to system criticality.
   Fix: require system owners to sign off on targets; tier systems and document rationale.

2. Backups exist, but restore time is untested.
   Fix: test restores under realistic constraints (access approvals, network restrictions, key retrieval).

3. Alternate storage is reachable only with normal SSO, which fails during outages.
   Fix: define break-glass access for restore operations and test it.

4. RPO is stated, but replication/backup jobs fail silently.
   Fix: implement monitoring and alerting tied to RPO risk (missed jobs, replication lag) and retain alert evidence.

5. Third-party dependency gap.
   Fix: if a third party hosts data, confirm export/backup pathways into your alternate storage site and test retrieval.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CP-6(2). Your risk is still concrete: failure to meet RTO/RPO turns incidents into prolonged outages, operational losses, and potential contractual non-performance. For federal systems and contractors, inadequate contingency capabilities commonly translate into assessment findings, remediation plans, and authorization delays under NIST-aligned assessment regimes. ²

Practical execution plan (30/60/90)

Use these as phases (not promises of duration).

First phase: Establish requirements and ownership

• Assign control owner and GRC evidence owner.
• Inventory in-scope systems and define the alternate storage site per system.
• Collect existing RTO/RPO statements; reconcile conflicts.
• Publish the RTO/RPO matrix and get approvals.

Second phase: Align configuration to objectives

• For each tier/system, create configuration standards (backup frequency, replication approach, retention, immutability, access model).
• Implement or remediate gaps in alternate storage configuration.
• Draft or update system recovery runbooks.

Third phase: Prove, document, and operationalize

• Execute recovery tests and record achieved RTO/RPO.
• Track remediation to closure; rerun tests where needed.
• Create the recurring evidence package and a review cadence.
• In Daydream, map CP-6(2) to the owner, procedure, and evidence checklist so audit prep is ongoing, not seasonal. ¹

Frequently Asked Questions

Do we need a separate alternate storage site for every system?

No. You can use shared backup/replication platforms, but you must show each system’s RTO/RPO is achievable with that platform’s configuration and recovery workflow. Keep evidence per system, even if the underlying service is shared. ¹

Is “multi-region storage” enough to satisfy CP-6(2)?

Only if the configuration and recovery operations meet documented RTO/RPO and you can prove it with test results. Multi-region without tested restore/failover procedures often fails the evidence standard. ¹

What evidence is most persuasive to an auditor?

A traceable chain: approved RTO/RPO, configuration showing how backups/replication meet those objectives, and a recent recovery test with achieved RTO/RPO plus remediation records. Policies alone rarely close the loop. ¹

How do we handle RTO/RPO when a third party hosts the application?

Treat the third party as part of your recovery design: confirm what you can restore independently (exports, backups to your storage) and what you inherit (provider DR). Document the dependency and keep the third party’s recovery evidence aligned to your objectives. ¹

What if we can’t meet the current RTO/RPO targets?

Document the gap, implement compensating steps where possible, and drive a formal decision: either fund remediation or revise the objective with business approval. Keep the decision record and a remediation plan tied to CP-6(2). ¹

How should we define “start” and “stop” for RTO measurement?

Define it in the test plan and keep it consistent. Common anchors are “incident declared” to “data available for application use,” but pick definitions that reflect operational reality and document them in the runbook and test report. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5