CP-10 System Recovery and Reconstitution

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Low, Moderate, High	Organization	3 (2 in a baseline)

Related controls: CP-2, CP-4, CP-6, CP-7, CP-9, IR-4, SA-8, SC-24, SI-13

Control statement

Provide for the recovery and reconstitution of the system to a known state within [Assignment: organization-defined time period consistent with recovery time and recovery point objectives] after a disruption, compromise, or failure.

NIST discussion

Recovery is executing contingency plan activities to restore organizational mission and business functions. Reconstitution takes place following recovery and includes activities for returning systems to fully operational states. Recovery and reconstitution operations reflect mission and business priorities; recovery point, recovery time, and reconstitution objectives; and organizational metrics consistent with contingency plan requirements. Reconstitution includes the deactivation of interim system capabilities that may have been needed during recovery operations. Reconstitution also includes assessments of fully restored system capabilities, reestablishment of continuous monitoring activities, system reauthorization (if required), and activities to prepare the system and organization for future disruptions, breaches, compromises, or failures. Recovery and reconstitution capabilities can include automated mechanisms and manual procedures. Organizations establish recovery time and recovery point objectives as part of contingency planning.

Control enhancements

CP-10(2) Transaction Recovery

Baselines: Moderate, High

Implement transaction recovery for systems that are transaction-based.

Discussion and assessment objectives for CP-10(2)

Transaction-based systems include database management systems and transaction processing systems. Mechanisms supporting transaction recovery include transaction rollback and transaction journaling.

Determine if transaction recovery is implemented for systems that are transaction-based.

Examine: Contingency planning policy; procedures addressing system recovery and reconstitution; contingency plan; system design documentation; system configuration settings and associated documentation; contingency plan test documentation; contingency plan test results; system transaction recovery records; system audit records; system security plan; other relevant documents or records.

Interview: Organizational personnel with responsibility for transaction recovery; organizational personnel with information security responsibilities.

Test: Mechanisms supporting and/or implementing transaction recovery capability.

CP-10(4) Restore Within Time Period

Baselines: High

Provide the capability to restore system components within [Assignment: organization-defined restoration time periods] from configuration-controlled and integrity-protected information representing a known, operational state for the components.

Discussion and assessment objectives for CP-10(4)

Restoration of system components includes reimaging, which restores the components to known, operational states.

Determine if the capability to restore system components within [Assignment: organization-defined restoration time periods] from configuration-controlled and integrity-protected information representing a known, operational state for the components is provided.

Examine: Contingency planning policy; procedures addressing system recovery and reconstitution; contingency plan; system design documentation; system configuration settings and associated documentation; contingency plan test documentation; contingency plan test results; evidence of system recovery and reconstitution operations; system security plan; other relevant documents or records.

Interview: Organizational personnel with system recovery and reconstitution responsibilities; organizational personnel with information security responsibilities.

Test: Mechanisms supporting and/or implementing the recovery/reconstitution of system information.

CP-10(6) Component Protection

Baselines: Not in a baseline

Protect system components used for recovery and reconstitution.

Discussion and assessment objectives for CP-10(6)

Protection of system recovery and reconstitution components (i.e., hardware, firmware, and software) includes physical and technical controls. Backup and restoration components used for recovery and reconstitution include router tables, compilers, and other system software.

Determine if system components used for recovery and reconstitution are protected.

Examine: Contingency planning policy; procedures addressing system recovery and reconstitution; contingency plan; system design documentation; system configuration settings and associated documentation; logical access credentials; physical access credentials; logical access authorization records; physical access authorization records; system security plan; other relevant documents or records.

Interview: Organizational personnel with system recovery and reconstitution responsibilities; organizational personnel with information security responsibilities.

Test: Organizational processes for protecting backup and restoration of hardware, firmware, and software; mechanisms supporting and/or implementing protection of backups and restoration of hardware, firmware, and software.

Withdrawn enhancements: CP-10(1), CP-10(3), CP-10(5).

Assessment objectives (SP 800-53A)

Objectives and methods for CP-10

Determine if:

• CP-10[01] the recovery of the system to a known state is provided within [Assignment: organization-defined time period] after a disruption, compromise, or failure;
• CP-10[02] a reconstitution of the system to a known state is provided within [Assignment: organization-defined time period] after a disruption, compromise, or failure.

Examine: Contingency planning policy; procedures addressing system backup; contingency plan; system backup test results; contingency plan test results; contingency plan test documentation; redundant secondary system for system backups; location(s) of redundant secondary backup system(s); system security plan; other relevant documents or records.

Interview: Organizational personnel with contingency planning, recovery, and/or reconstitution responsibilities; organizational personnel with information security responsibilities.

Test: Organizational processes implementing system recovery and reconstitution operations; mechanisms supporting and/or implementing system recovery and reconstitution operations.

Policy statement

• The System owner shall provide for the recovery of the system to a known state within Fill in: time period consistent with recovery time and recovery point objectives for the recovery of the system Typical: the recovery time objective set in the contingency plan from the business impact analysis after a disruption, compromise or failure. (CP-10)
• The System owner shall provide for the reconstitution of the system to a known state within Fill in: time period consistent with recovery time and recovery point objectives for the reconstitution of the system Typical: the reconstitution time set in the contingency plan after a disruption, compromise or failure. (CP-10)

CP-10(2) Transaction recovery

• The System owner shall implement transaction recovery for a transaction-based system. (CP-10(2))

CP-10(4) Restore within time period

• The System owner shall provide the capability to restore system components within Fill in: restoration time period within which to restore system components to a known, operational state Typical: the recovery time objective set for each component in the contingency plan from configuration-controlled and integrity-protected information representing a known, operational state for the components. (CP-10(4))

From the Contingency Planning Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

CP-10 asks you to be able to recover and reconstitute the system to a known state, within set times, after a disruption, compromise or failure. NIST’s CP-10 discussion separates the two. Recovery carries out the contingency plan to restore mission and business functions. Reconstitution follows it and returns the system to a fully operational state: interim capabilities are shut down, the restored capabilities are assessed, continuous monitoring is reestablished, the system is reauthorized if required, and the system and organization prepare for the next event. CP-10 is in the Low, Moderate and High baselines.

NIST SP 800-34 Rev. 1 (May 2010, updated November 11, 2010; current as of October 2026), section 4.4, describes how the reconstitution phase validates the recovery:

• Validation data testing: the data is recovered completely and is current to the last available backup
• Validation functionality testing: all functions work and the system is ready for normal operations
• Concurrent processing, where used: the system runs at two sites until the recovered system is shown to work correctly and securely

Then the recovery is declared and the plan is deactivated. Users are notified, temporary arrangements are cleaned up and backup media is returned. A full backup is taken as soon as reasonable, and the event is documented in an after-action report with lessons learned. Section 4.4 also says the plan coordinator, the system owner and security staff, with the authorizing official’s concurrence, decide whether the recovery made a significant change that needs reassessment and reauthorization. Its examples are a new or upgraded hardware platform and a move to a new facility.

Common implementations. The contingency plan follows this structure: recovery in section 4, in the priority order from the business impact analysis, and reconstitution in section 5, with validation, the recovery declaration, cleanup, a new backup and event documentation. The known state is the system’s approved baseline configuration (CM-2) and its data as of the recovery point objective. After a compromise, rebuild from known-good images and restore from backups taken before the compromise, checked for the attacker’s persistence, in coordination with incident response (IR-4). Record the recovery in a contingency plan after-action report. If recovery moved the system to a new hosting environment, check it against the significant-change triggers in the Continuous Monitoring Strategy.

Organization-defined parameters. Typical values, from the Contingency Planning policy, which your organization may set differently:

Parameter	Typical value
Time period for recovery	The recovery time objective set in the contingency plan from the business impact analysis
Time period for reconstitution	The reconstitution time set in the contingency plan

In the policy, the system owner provides for recovery and reconstitution. NIST’s control statement asks for both times to be consistent with the recovery time and recovery point objectives. The contingency plan’s section 2.2 table holds the maximum tolerable downtime, recovery time objective and recovery point objective; add a row for the reconstitution time so the policy’s second value has somewhere to point. The CP decision worksheet gives who sets the objectives: typically the system owner, from a business impact analysis agreed with the business owner, approved by the authorizing official with the plan.

Evidence assessors ask for.

• The contingency plan’s recovery and reconstitution procedures, with the recovery objectives and restoration order
• Results of the last recovery test or real recovery, with measured times against the recovery time and recovery point objectives
• Validation records for the recovered system: data checks, functionality tests and the security checks showing controls work as before
• The recovery declaration and the plan deactivation record
• For a recovery that changed the platform or facility, the significant-change decision and any reassessment
• For CP-10(2), the database or application configuration for transaction logging and rollback, and a test of point-in-time recovery

Inheritance. A cloud provider’s recovery of its own infrastructure and managed services is inherited. The system owns recovering its own components, data and configuration, and validating them. Record the split in the system security plan.

Common findings.

• Recovery tested, but never timed against the recovery time objective, or the objective missed with no plan of action and milestones item.
• No validation step: the system is declared recovered when it starts, without checking its data or its security controls.
• Temporary accounts, firewall rules or workarounds from recovery left in place afterward.
• After a compromise, the system restored from a backup that still held the attacker’s foothold.
• No reconstitution time defined anywhere, so the second half of CP-10 cannot be assessed.

Enhancements in the Moderate baseline. CP-10(2) transaction recovery: implement transaction recovery for transaction-based systems. NIST’s discussion names database management systems and transaction processing systems, and transaction rollback and transaction journaling as the mechanisms. In practice, keep transaction logs with the backups so the database can be restored to a point in time within the recovery point objective. A system with no transaction-based components records that in the system security plan.

High adds CP-10(4) restore within time period: restore components within set times from configuration-controlled, integrity-protected images of a known operational state. CP-10(6) component protection is in no baseline.

Artifacts

• Contingency Planning Decision Worksheet
• Contingency Planning Policy
• Information System Contingency Plan