CP-9(2): Test Restoration Using Sampling

CP-9(2) requires you to prove backups are restorable by restoring selected system functions using a representative sample of backup data during contingency plan testing. Operationalize it by defining a sampling method, running scheduled restore tests into a controlled environment, validating functional outcomes, and retaining evidence that links each test to the backups and systems in scope. ¹

Key takeaways:

• Your test must restore real system functions using sampled backup data, not just verify backup job success. ¹
• Sampling must be intentional and repeatable: define what you sample, why, and how often, then document results and corrective actions.
• Auditors look for end-to-end proof: backup selection → restore execution → functional validation → exceptions and remediation.

CP-9(2): test restoration using sampling requirement is a common gap because teams treat “backup” as an IT operations checkbox rather than a recoverability control. The enhancement is explicit: during contingency plan testing, you must restore selected system functions using a sample of backup information. ¹ That means your evidence has to show more than “the backup completed” or “we did a DR tabletop.” It must show that actual data from backups can be restored and that the restored system functions operate as expected.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn CP-9(2) into an executable test protocol with clear ownership, a defined sampling approach, and standardized artifacts. Your goal is assessment-ready proof that (1) your sampling is risk-based and repeatable, (2) restoration is performed as part of contingency plan testing, and (3) outcomes are validated and tracked to closure.

If you manage third-party hosted systems or rely on managed backup providers, you still own the control outcome: you must obtain evidence that restoration testing occurred with sampled backup data for your in-scope systems, or run the tests yourself in your tenant.

Regulatory text

Text (verbatim): “Use a sample of backup information in the restoration of selected system functions as part of contingency plan testing.” ¹

Operator interpretation: During contingency plan tests, you must actually restore from backups (using a sample of backup data) and bring up selected system functions to confirm they work. “Sample” is the key word: you do not need to restore everything every time, but you must restore enough, in a structured way, to credibly demonstrate recoverability for the system. ¹

Plain-English meaning (what auditors expect you to prove)

You should be able to demonstrate all of the following, in an evidence package:

1. Backups exist and are accessible for the system(s) in scope (baseline CP-9 expectation).
2. A defined sample of backup information was chosen for a test (what was sampled, from which backup sets, and why).
3. Restoration was executed (who ran it, when, where, what tool, what backup set).
4. Selected system functions were restored and validated (how you confirmed the function works, what “pass” means).
5. Issues were tracked and fixed (tickets, root cause, retest if needed).

Who it applies to

Entity scope

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data where NIST SP 800-53 is contractually flowed down (common in federal contracting and regulated ecosystems). ¹

Operational context (where CP-9(2) shows up in real life)

• Systems with centralized backup platforms (enterprise backup tools, snapshots, backup vaults).
• Systems hosted in cloud environments where restores require IAM permissions, KMS key access, network routing, and infrastructure-as-code changes.
• Environments with third parties operating parts of the stack (managed hosting, managed databases, SaaS platforms with export/restore options).

If a third party performs backups, your requirement becomes: obtain their restoration test evidence or conduct restoration tests in your environment using backup artifacts they provide. The control outcome remains yours.

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

1) Assign ownership and define the “selected system functions”

• Name a control owner (often Infrastructure/Platform, DR lead, or SRE manager).
• Define which functions matter for restore tests. Keep it concrete: authentication, API read/write, job scheduler, reporting pipeline, database query path, file retrieval, etc.
• Map functions to components: app tier, database, object store, secrets manager, queues, IAM/KMS dependencies.

Deliverable: a one-page “Restore Test Scope” sheet per system that lists functions, dependencies, and success criteria.

2) Define a sampling method that is repeatable

Sampling is where teams get sloppy. Document it like a testable rule:

• Backup sources to sample from: full backups, incremental chains, snapshots, database dumps, configuration backups.
• Selection logic: risk-based (critical data domains), randomness (rotate datasets), change-based (new releases), or coverage-based (ensure each major dataset is periodically exercised).
• Data types: structured (DB tables), unstructured (object storage), configs/secrets (where feasible and safe), system images.

Deliverable: “CP-9(2) Sampling Procedure” that answers: what gets sampled, how selected, and how selection is recorded. ¹

3) Build a controlled restore environment (or controlled restore mode)

A restore test that overwrites production is rarely acceptable. Most organizations use:

• An isolated test VPC/VNet or segregated subnet
• A non-production cluster with production-like configs
• Sanitized datasets where required, while still proving restoration mechanics

Key control detail: the environment must allow you to validate “selected system functions,” not merely confirm files can be copied.

Deliverable: restore runbook section describing environment prerequisites, access controls, and clean-up steps.

4) Execute restore test runs as part of contingency plan testing

Your test run should look like an operator play:

1. Record the test trigger (scheduled contingency test or event-driven).
2. Identify sampled backup artifacts (backup job ID, snapshot ID, vault object, timestamp).
3. Perform restore steps (commands, console actions, automation pipeline run).
4. Bring up selected functions (start services, connect dependencies, apply configs).
5. Validate outcomes against defined success criteria.
6. Document deviations (missing permissions, corrupted chain, KMS key issue, schema mismatch).
7. Open tickets and assign owners for fixes.

Deliverable: a completed “Restore Test Record” for each run, with attachments and sign-off.

5) Validate function, not just data presence

Common validation checks that auditors accept because they tie to function:

• App starts and passes health checks
• Database restores and passes integrity checks you already use operationally
• A controlled read/write transaction succeeds in the restored environment
• A batch job runs successfully using restored data
• Required configuration items are present and correct

Avoid weak validation like “restore completed successfully” without proof that system functions operate.

6) Close the loop: corrective actions and retesting

If a restore fails, you still get credit for testing if you:

• captured evidence of the failure,
• performed root cause analysis,
• remediated,
• re-ran the test (or scheduled an expedited retest).

Deliverable: ticket links, remediation notes, and retest record.

7) Operationalize the control in your GRC system

Turn CP-9(2) into a living requirement:

• Control statement (plain English)
• Owner and back-up owner
• Procedure links (sampling + restore runbook)
• Evidence cadence (aligned to your contingency plan testing schedule)
• Exception process (risk acceptance for systems temporarily unable to restore)

Daydream (as a practical resolution): if you use Daydream to manage control mapping and recurring evidence, set CP-9(2) to automatically request restore-test records, sampling logs, and remediation tickets on your defined cadence. This directly addresses the common risk factor of missing implementation evidence. ¹

Required evidence and artifacts to retain

Use an evidence checklist auditors can follow end-to-end:

Governance artifacts

• Contingency plan test plan that includes restore testing
• CP-9(2) sampling procedure (documented selection method)
• Restore test runbook (step-by-step execution instructions)
• Roles and responsibilities (RACI or ownership notes)

Test execution artifacts ¹

• Sampling log: what was selected and why (dataset IDs, backup timestamps, snapshot IDs)
• Change record or test calendar entry tying the activity to contingency plan testing
• Restore output: tool logs, pipeline run logs, screenshots, or console exports
• Functional validation results: test scripts, health check output, query results, app screenshots
• Evidence of access approvals if elevated access was required

Remediation artifacts (as needed)

• Incident/problem tickets
• Root cause analysis notes
• Follow-up test evidence after fixes

Common exam/audit questions and hangups

Auditors and assessors typically probe these points:

• “Show me the sample selection.” If your answer is “we picked something,” expect a finding. Provide a documented method and a selection record. ¹
• “Did you restore system functions or just restore files?” CP-9(2) explicitly ties restoration to “selected system functions.” ¹
• “Is this part of contingency plan testing?” A standalone restore drill may still count, but you must show it is executed under the contingency testing program and documented as such.
• “What happened when it failed?” They want to see governance: tracked issues, owners, and closure.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: equating backup monitoring with restoration testing.
   Fix: require at least one artifact that proves functional validation in a restored environment (health check output, transaction test results).

2. Mistake: sampling that is not defendable.
   Fix: document a method (risk-based + rotation) and keep a sampling log that shows coverage over time.

3. Mistake: restores work only with “tribal knowledge.”
   Fix: maintain a runbook that a different operator can follow. Test the runbook during the exercise.

4. Mistake: ignoring cryptographic key and identity dependencies.
   Fix: include IAM/KMS prerequisites in the restore plan and test that the restored workload can access what it needs in the test environment.

5. Mistake: third-party backups with no restoration evidence.
   Fix: add contract language and due diligence requirements for restoration testing evidence, or run restores yourself using exported backups where possible.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, CP-9(2) failures create two risks that matter to leadership:

• Operational resilience risk: backups that cannot restore turn an outage into prolonged downtime.
• Assurance risk: during assessments, the most common failure mode is missing evidence that restoration was tested with real backup data and functional validation. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable control)

• Assign control owner and approvers.
• Inventory in-scope systems and identify “selected system functions” per system.
• Draft sampling procedure and restore test record template.
• Pick one system as a pilot and run one sampled restore test end-to-end.
• Store evidence in a central repository with consistent naming.

Days 31–60 (scale and standardize)

• Expand restore testing to additional in-scope systems.
• Convert the runbook into automation where safe (pipelines, scripts) and keep logs.
• Add functional validation scripts to make results repeatable.
• Implement ticketing workflow for restore failures and remediation.

Days 61–90 (harden for audits and continuity)

• Align restore tests formally to the contingency plan testing schedule and approvals.
• Add management reporting: test completion, failures, remediation status.
• Validate third-party evidence collection where backups are outsourced.
• Operationalize evidence requests and reminders (for example, through Daydream workflows) so CP-9(2) artifacts arrive on cadence and stay audit-ready. ¹

Frequently Asked Questions

What counts as a “sample” for CP-9(2)?

A sample is a defined subset of backup information you select using a documented method (risk-based, rotating, or change-driven) and then restore during a test. The key is repeatability and traceability from selection to restored function. ¹

Do we have to restore the entire system every time?

CP-9(2) calls for restoring “selected system functions” using sampled backup information, so full restores are not required every time. Your sampling and function selection must still provide credible coverage for the system’s recoverability. ¹

Can a tabletop exercise satisfy CP-9(2)?

A tabletop alone usually lacks evidence of actual restoration from backups. CP-9(2) expects you to use backup information in restoration of selected functions as part of contingency plan testing. ¹

We use a managed backup provider. How do we meet CP-9(2)?

Require restoration testing evidence from the third party that ties to your tenant, backups, and functions, or perform restores yourself using exported backup artifacts where feasible. Keep the sampling record, restore logs, and functional validation results.

What evidence is strongest for auditors?

A complete packet: sampling log, backup identifiers, restore job logs, functional validation output, and remediation tickets if issues occurred. The evidence should allow an assessor to follow the chain without oral explanations.

What if the restore test fails?

A failure can still support compliance if you document the failure, track remediation, and retest. Auditors generally react poorly to undocumented failures or “we fixed it later” with no ticket trail.

Footnotes

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