CP-10: System Recovery and Reconstitution

Quick-reference card

What this control requires

CP-10 requires organizations to recover and reconstitute systems to a known operational state after a disruption, compromise, or failure. The control mandates that you define specific recovery time and recovery point objectives, then build the capabilities to meet them through a combination of automated mechanisms and documented manual procedures.

In practice, this means your contingency plan can’t stop at “restore from backup.” Recovery covers the initial actions to bring mission-critical functions back online, including activating alternate processing sites, restoring data from backups, and standing up interim capabilities. Reconstitution goes further. It’s the disciplined process of returning systems to their fully operational, pre-disruption state and confirming that security controls haven’t degraded in the process.

Where most organizations fall short is treating reconstitution as an afterthought. Reconstitution includes deactivating any temporary workarounds deployed during recovery, reassessing system capabilities, reestablishing continuous monitoring, reauthorizing systems if needed, and capturing lessons learned to strengthen the organization against future incidents. Without defined recovery time objectives (RTOs) and recovery point objectives (RPOs), you have no way to measure whether your recovery capability actually works.

Why it matters

Most organizations test whether backups exist. Far fewer test whether those backups can actually restore operations under the conditions that matter most: when the threat actor has specifically targeted backup infrastructure. Ransomware operators have made backup destruction a standard phase of their attack playbooks, and the gap between “we have backups” and “we can recover” has become the difference between a contained incident and a catastrophic one.

Wood Ranch Medical permanent closure

Take Wood Ranch Medical as an example of what this gap costs in practice. On August 10, 2019, ransomware struck the family practice in Simi Valley, California, encrypting the servers containing patient medical records. Wood Ranch had backup hard drives, but the backup system was connected to the same network as the primary systems. The ransomware encrypted those too. The practice confirmed the situation in its breach notification: “With our backup system encrypted as well, we cannot rebuild our medical records.”

The result was no viable path to recover patient histories, medication lists, and treatment records accumulated over years of practice. The clinic had no choice but to permanently close. The closure announcement came in September 2019, and the practice stopped seeing patients on December 17, 2019. A total of 5,835 patients were left to seek care elsewhere, many without access to their medical histories.

Where the failure stood out wasn’t the absence of backups. It was the absence of isolated, offline, or air-gapped backup copies that ransomware cannot reach. A backup that shares network connectivity with the systems it protects provides no recovery capability against ransomware, which specifically targets backup infrastructure to maximize leverage. A related case at Springhill Medical Center in Mobile, Alabama reinforces the stakes from a different angle. Ransomware there knocked clinical monitoring systems offline for three weeks, and the failure to reconstitute fetal monitoring equipment in time allegedly contributed to an infant’s death, making it the first ransomware attack to result in a settled death liability claim.

What attackers exploit:

• Network-connected backups. Ransomware variants specifically enumerate and encrypt backup shares, NAS devices, and shadow copies accessible from the compromised network.
• Missing recovery testing. Organizations that never validate restoration under realistic conditions discover their backups are corrupted, incomplete, or incompatible only during an actual incident.
• Flat network architecture. Lack of segmentation between production systems and backup infrastructure gives attackers lateral movement paths to backup repositories.
• Absent reconstitution procedures. Even when data is recoverable, organizations without documented reconstitution steps reintroduce vulnerabilities or skip security control validation during restoration.
• Single-site backup storage. Collocating primary and backup systems in the same physical or logical environment means a single event can destroy both.

How to implement

The most common CP-10 failure isn’t a missing backup policy. It’s the gap between documented recovery procedures and tested recovery capability. Organizations write contingency plans that describe what should happen, then never validate whether the people, processes, and technology can actually execute under pressure.

For your organization

Define recovery objectives first. Establish RTOs and RPOs for every system based on mission criticality, not vendor defaults. Your disaster recovery plan should specify the maximum tolerable downtime and the maximum acceptable data loss for each system tier.

Isolate your backup infrastructure. Maintain at least one backup copy that is offline, air-gapped, or stored in an immutable format that cannot be modified or deleted from the production network. Follow the 3-2-1 backup rule as a baseline: three copies of data, on two different media types, with one stored offsite.

Test recovery, not just backups. Conduct full restoration tests at least annually, and tabletop exercises quarterly. Verify that restored systems boot, that applications function, that data integrity checks pass, and that security controls remain intact after restoration. Document the actual time each restoration takes and compare it against your stated RTOs.

Document reconstitution procedures. Create step-by-step runbooks for returning systems from interim recovery mode to full operational status. Include checkpoints for deactivating temporary workarounds, reestablishing continuous monitoring, validating security configurations, and conducting post-recovery system reauthorization.

Build your incident response plan to integrate with recovery. Recovery doesn’t happen in isolation. Your contingency plan should define handoff points between incident response, recovery, and reconstitution phases, with clear roles and communication protocols for each.

Common mistakes:

• Storing all backup copies on the same network segment as production systems
• Testing backup creation without testing full restoration workflows
• Failing to update recovery procedures after infrastructure changes
• Omitting reconstitution steps, leaving systems in a degraded security posture after recovery
• Not defining RTOs and RPOs at the system level, defaulting to one-size-fits-all targets

For your vendors

What to ask in security questionnaires:

• What are your defined RTOs and RPOs for systems that process our data?
• How are backup copies protected against ransomware and insider threats?
• When was the last full recovery test performed, and what were the results?
• Do you maintain offline or air-gapped backups?
• What is your reconstitution process for validating security controls after a recovery event?

What evidence to request:

• Contingency plan or disaster recovery plan with defined recovery objectives
• Most recent recovery test results, including actual restoration times
• Backup architecture documentation showing isolation from production networks
• Post-recovery validation procedures and recent execution records

Red flags:

• Vendor cannot provide specific RTOs or RPOs for your data
• Recovery testing is conducted annually or less, with no documentation of results
• Backup infrastructure shares the same network, cloud account, or administrative credentials as production systems
• No documented reconstitution process exists
• Vendor describes backups but cannot describe how they validate restored system integrity

Request evidence of the most recent recovery test beyond self-attestation, including timestamps, scope, and any gaps identified. Ask for network diagrams showing backup isolation. If the vendor holds a SOC 2 Type II report, review the availability criteria for recovery-related controls and any noted exceptions.

Evidence examples

Cross-framework mapping

Related controls

• CP-02, Contingency Plan. Establishes the overarching plan that CP-10’s recovery and reconstitution activities execute against.
• CP-04, Contingency Plan Testing. Validates that the recovery and reconstitution capabilities required by CP-10 actually work under realistic conditions.
• CP-06, Alternate Storage Site. Provides the geographically separated storage locations that protect backup data from single-site failures.
• CP-07, Alternate Processing Site. Supplies the infrastructure where recovered systems operate when the primary site is unavailable.
• CP-09, System Backup. Creates the backup copies that CP-10’s recovery procedures restore from, including retention schedules and integrity verification.
• IR-04, Incident Handling. Coordinates the incident response activities that trigger and run alongside CP-10’s recovery and reconstitution phases.
• SA-08, Security and Privacy Engineering Principles. Informs system design decisions that make recovery and reconstitution more reliable, such as modular architecture and fail-safe defaults.
• SC-24, Fail in Known State. Ensures systems default to a secure configuration during failure, supporting CP-10’s requirement to restore to a known state.
• SI-13, Predictable Failure Prevention. Identifies components likely to fail and replaces them proactively, reducing the frequency of disruptions that require CP-10 activation.

Frequently asked questions

What is NIST SP 800-53 CP-10?

CP-10 requires organizations to recover and reconstitute information systems to a known operational state within a defined time period after a disruption, compromise, or failure. Recovery restores mission-critical functions using contingency plan procedures, while reconstitution returns systems to their fully operational state, including reestablishing continuous monitoring, deactivating interim capabilities, and validating that security controls haven’t degraded. The control applies at the LOW, MODERATE, and HIGH baselines, meaning every federal system and most regulated environments must implement it.

What happens if CP-10 is not implemented?

Without CP-10, you have no documented, tested capability to restore systems after an incident. The consequence extends beyond prolonged downtime: unrecoverable data loss, regulatory findings for failure to maintain continuity controls, and potential permanent loss of business operations. The Wood Ranch Medical closure demonstrated the extreme end of this spectrum, where network-connected backups provided no recovery capability against ransomware. Auditors assessing CP-10 verify that recovery time objectives exist, that recovery tests have been performed, and that reconstitution procedures produce a validated, fully operational system state.

How do you audit CP-10?

Auditors assess CP-10 by examining contingency planning policies, reviewing documented recovery time and recovery point objectives, and testing whether the organization can demonstrate actual recovery capability. Specifically, they review contingency plan test results to verify that systems were restored within stated time periods, examine backup architecture documentation to confirm backup isolation from production networks, and interview personnel responsible for recovery and reconstitution. They also verify that reconstitution procedures exist and have been executed, including post-recovery security control validation, continuous monitoring reestablishment, and system reauthorization documentation.

What is the difference between recovery and reconstitution in NIST 800-53?

Recovery is the initial phase: executing contingency plan activities to restore mission-critical functions and bring systems back online after a disruption. Reconstitution follows recovery and focuses on returning systems to their fully operational, pre-disruption state. This includes deactivating any interim capabilities or workarounds used during recovery, reassessing restored system capabilities, reestablishing continuous monitoring, completing system reauthorization if required, and conducting activities to prepare the organization for future disruptions. Think of recovery as “get the lights back on” and reconstitution as “confirm everything works the way it did before, and make sure your defenses are fully restored.”