CP-4(4): Full Recovery and Reconstitution

CP-4(4) sits inside NIST SP 800-53’s Contingency Planning family and raises the bar on what “testing the contingency plan” means in practice. Many programs can show they have backups, a DR site, and an annual test. Fewer can show a controlled, repeatable ability to rebuild production-grade capability from scratch and return it to a verified baseline. That gap is exactly what CP-4(4) targets.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this requirement is to treat it as an engineering-backed control with audit-ready outputs: define the recovery scope (what “full” means for the system), define the “known state” (what you consider clean and correct), run a test that performs an end-to-end restoration or rebuild, validate the state, and document variances and fixes.

This page translates the requirement into execution steps, assigns clear ownership, and lists the artifacts you should retain so an assessor can trace the control from policy intent to test execution to outcomes. Source references are limited to the NIST SP 800-53 Rev. 5 catalog and landing page. ¹

Regulatory text

Requirement (verbatim): “Include a full recovery and reconstitution of the system to a known state as part of contingency plan testing.” ²

What the operator must do: Your contingency plan test program must include at least one test scenario that performs a complete recovery and rebuild (“reconstitution”) of the system and confirms the system is returned to a defined, verifiable known-good baseline. A test that only restores a database, only fails over traffic, or only validates backups exist does not satisfy the enhancement by itself. ²

Plain-English interpretation

CP-4(4) requires you to prove, through testing, that you can:

1. Recover the system after a disruptive event (restore services and data), and
2. Reconstitute the system (rebuild it into a clean, expected configuration),
3. Validate it matches a known state (an approved baseline you can check objectively).

“Known state” is the operational crux. It is not “whatever is running today.” It is a defined target state you can recreate and verify: OS and application versions, hardened configuration baselines, identity and access configuration, network controls, secrets handling, monitoring agents, logging pipelines, and required integrations.

Who it applies to

Entities: This applies to federal information systems and contractor systems handling federal data that have adopted NIST SP 800-53 controls through an authorization boundary, contract requirements, or an internal security framework mapping. ²

Operational context: Apply CP-4(4) to any system where downtime, data loss, or integrity compromise is material, including:

• Systems processing or storing federal data.
• Shared services inside an authorization boundary (identity, logging, key management, CI/CD, virtualization platforms).
• Third-party-hosted environments where you still own recovery outcomes (cloud, managed hosting, SaaS components inside your system boundary).

Rule of thumb for scoping: If the system is in your SSP/control boundary, your test must demonstrate you can restore and rebuild it to the approved baseline, even if a third party performs some actions under contract.

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

1) Name a control owner and define test governance

• Assign an accountable owner (often BC/DR lead, SRE/Infra lead, or System Owner) and a GRC facilitator responsible for evidence quality.
• Define how test results are approved (System Owner sign-off plus security review for “known state” validation).

Deliverable: CP-4(4) control implementation statement with named roles, escalation path, and evidence list.

2) Define “full recovery” for the system (scope and completion criteria)

Write a one-page “recovery scope” that lists:

• In-scope components (compute, storage, database, queue, identity dependencies, secrets vault, logging/monitoring, network controls).
• Recovery objectives you will test (qualitative is fine if you cannot commit to numeric RTO/RPO in this document).
• “Done means” criteria: service reachable, data restored, access controls enforced, logging active, security agents running, integrations functional.

Practical tip: Tie “full recovery” to what users and downstream systems need, not to infrastructure checkboxes.

3) Define the “known state” (baseline) and make it testable

A known state must be documented and checkable. Build it from:

• Approved configuration baselines (hardening standards, secure configs).
• Golden images or hardened AMIs/templates.
• Infrastructure-as-code and configuration-as-code (so the build is deterministic).
• Backup integrity requirements (what backups exist, what is included/excluded, encryption expectations, restore prerequisites).

Then define verification checks:

• Baseline conformance checks (e.g., config scan outputs, signed build artifacts, policy-as-code results).
• Security controls present and functioning (logging/monitoring hooks, EDR agents, key rotation, MFA enforcement, privileged access paths).

Deliverable: “Known State Definition” document plus verification checklist that can be executed during tests.

4) Build (or refine) a recovery runbook that can rebuild from scratch

Your runbook should read like an operator playbook:

• Preconditions (access, break-glass accounts, keys, network prerequisites).
• Restore steps in order, with who performs them.
• Reconstitution steps: patching, baseline configs, secrets provisioning, identity and RBAC restoration, monitoring/logging enablement, dependency reintegration.
• Validation steps mapped directly to the “known state” checklist.
• Stop/go decision points and rollback paths.

Make it audit-friendly: Each step should have an expected output (command output, ticket evidence, system screenshot, log excerpt).

5) Execute a contingency plan test that includes full recovery and reconstitution

Design a scenario that forces real actions, for example:

• Restore into an isolated recovery environment (preferred for safety).
• Rebuild a representative production stack from images/IaC and restore data from backups.
• Validate functional outcomes and baseline conformance.

Capture evidence in real time:

• Change tickets, war-room notes, runbook timestamps.
• Backup restore logs, pipeline logs, build logs.
• Validation outputs (config checks, monitoring dashboards showing log ingestion, access control tests).

6) Document results, gaps, and corrective actions

Your test is not “pass/fail and done.” Treat it as a control operation:

• Record what worked and what did not.
• Open corrective actions with owners and due dates.
• Update runbooks, baselines, and training based on findings.
• Feed material issues into risk acceptance or POA&M processes as appropriate.

7) Operationalize recurrence and evidence hygiene

CP-4(4) fails in practice when evidence is scattered. Establish:

• A standard evidence package per test.
• A retention location aligned to your audit model (GRC system, controlled repository).
• A mapping from CP-4(4) to test instances, owners, and artifacts.

Where Daydream fits naturally: If your team struggles with “what evidence is enough” and “how do we keep it consistent across systems,” Daydream can be used to map CP-4(4) to an owner, an implementation procedure, and recurring evidence artifacts so each test produces an assessor-ready packet instead of a pile of notes. ²

Required evidence and artifacts to retain

Use this as your minimum evidence checklist:

Evidence artifact	What it should show	Owner
Contingency plan test plan	Scenario, scope, success criteria, roles	BC/DR lead + System Owner
“Known state” definition + baseline references	What “good” is, and how you verify it	Security/Platform
Recovery & reconstitution runbook	Step-by-step procedures with expected outputs	SRE/Infra
Backup/restore logs and outputs	What was restored, from where, errors/warnings	Backup admin
Build/IaC pipeline logs or change records	Rebuild steps and versioned artifacts	Platform/DevOps
Validation checklist outputs	Proof system matches baseline and is functional	Security + System Owner
Issues list + corrective action tickets	Gaps found, ownership, remediation status	GRC facilitator
Final after-action report	Summary, decisions, approvals, lessons learned	System Owner

Common exam/audit questions and hangups

Assessors tend to probe four areas:

1. “Show me full recovery.”
   They will look for proof you restored the system, not just tested a backup file exists.

2. “What is the known state?”
   If you cannot point to a defined baseline and verification method, CP-4(4) becomes subjective.

3. “Did you actually reconstitute?”
   They will ask whether you rebuilt system configuration, controls, and integrations, not only data.

4. “Is this repeatable?”
   They will look for versioned runbooks, consistent evidence, and a cadence that matches your contingency planning program. ²

Frequent implementation mistakes and how to avoid them

• Mistake: Treating a tabletop exercise as CP-4(4) evidence.
  Fix: Keep tabletops for broader CP testing, but schedule at least one test that performs a real restore/rebuild and captures logs and outputs.

• Mistake: “Known state” equals “latest production.”
  Fix: Define a baseline: hardened images, configuration standards, and approved versions. Add objective checks.

• Mistake: Restoring data without restoring security controls.
  Fix: Include reconstitution steps for IAM, secrets, logging, monitoring agents, and network policies.

• Mistake: Evidence is incomplete or non-verifiable.
  Fix: Pre-build an evidence packet template. Require artifacts (logs, tickets, outputs) as part of the test definition of done.

• Mistake: Third-party dependencies are ignored.
  Fix: If a third party hosts or operates part of recovery, define contractual responsibilities and collect their evidence (reports, tickets, attestations) into your packet.

Enforcement context and risk implications

No public enforcement case references were provided in the supplied source catalog for CP-4(4), so this page does not cite specific enforcement actions.

Operationally, failure modes are predictable: during an incident, teams discover backups are incomplete, restore procedures are out of date, or “rebuild” requires tribal knowledge. CP-4(4) reduces that risk by forcing a realistic test that validates you can restore service and return to a clean, approved configuration baseline. ²

Practical 30/60/90-day execution plan

First 30 days (establish control design)

• Assign CP-4(4) control owner and GRC evidence owner.
• Draft “full recovery scope” and “known state definition.”
• Inventory what you need to rebuild: images, IaC repos, backup sets, secrets, dependencies.
• Create an evidence packet template and store it in a controlled repository.

Days 31–60 (build runbooks and verification)

• Write or refine recovery + reconstitution runbooks with expected outputs.
• Implement baseline verification checks you can run during a test (configuration checks, logging validation, access checks).
• Coordinate third-party roles for hosted components and define what evidence they must provide.

Days 61–90 (execute and close gaps)

• Run a CP-4(4) test that performs end-to-end recovery and reconstitution in a safe environment.
• Produce an after-action report and track remediation items to closure.
• Update runbooks and baselines based on findings.
• Put the next test on the calendar and standardize evidence capture so it becomes routine.

Frequently Asked Questions

Does CP-4(4) require restoring production in a real outage?

No. It requires contingency plan testing that includes full recovery and reconstitution. Most teams do this in a recovery or isolated environment to avoid production risk. ²

What counts as a “known state” in practice?

A known state is a defined baseline you can rebuild and verify, such as hardened images, approved configuration standards, versioned IaC, and explicit validation checks that confirm the system matches that baseline. ²

Can we satisfy CP-4(4) if a third party runs our disaster recovery?

Yes, if you can show the system was fully recovered and reconstituted to a known state and you retain evidence. You may need contractual language and test artifacts from the third party to complete your evidence packet.

Is restoring the database enough for “full recovery”?

Usually not. CP-4(4) expects full system recovery and reconstitution, which includes required services, security controls, configurations, and integrations, not only the data layer. ²

What evidence do auditors ask for most often?

They typically ask for the test plan, runbook, logs showing restore and rebuild actions, proof of baseline verification (the “known state”), and documented remediation for gaps found during the test.

How do we keep CP-4(4) evidence consistent across many systems?

Standardize a control mapping, evidence checklist, and test packet template per system. A GRC workflow tool such as Daydream can help by mapping CP-4(4) to owners, procedures, and recurring artifacts so each test produces a consistent assessor-ready package.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON; Source: NIST SP 800-53 Rev. 5

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