CP-10 System recovery: requirements and evidence

What CP-10 system recovery and reconstitution asks for in plain terms

When an auditor or contract asks whether a system can be rebuilt to a trustworthy state after a failure, CP-10 is the control they are testing. It requires you to recover and reconstitute the system to a known state within a defined period, and that period has to be consistent with your recovery time objective (RTO) and recovery point objective (RPO). The control applies after a disruption, a compromise or a failure, and the organization must define the thresholds itself, so the assessor will ask where those values are written down and whether the system can meet them.

A known state means you can name exactly what the system should look like after recovery: which software versions, configurations, data and security settings are in place, and that you can prove it. Recovery and reconstitution are related but not identical. Recovery brings services back, while reconstitution returns the system to its authoritative configuration and verifies it. A compromise makes this harder than a simple restore. A clean backup may already contain the attacker's persistence, a backed-up configuration may have been altered, and credentials may need rotation before anything is trusted. The team therefore has to decide what it can restore from, how it confirms integrity, and what gets rebuilt from known-good sources rather than from the last snapshot. The control is selected in the low, moderate and high baselines of SP 800-53B but not in the privacy baseline. Organizations usually find it hard in three places: RTO and RPO values that were never agreed with the business owners, backups that have never been restored end to end, and no documented rebuild path for systems whose configuration lives only on the running host. Start by confirming each target value, then run a restore test and record how long it actually took. Assessors will compare those results with the plan.

Which systems, data and teams CP-10 applies to

CP-10 applies to whatever the organization defines as the system, so the first work is deciding the boundary and impact level. The decisions below connect: each one changes which components must reach a known state, how fast, and who signs off on that recovery. Settle them in writing before estimating effort.

Authorization boundary

CP-10 is assessed against the system inside the authorization boundary, so every component outside it is out of scope for recovery evidence. Identity providers, DNS, hypervisors and managed database services either sit inside the boundary or are inherited from another authorization. Confirm which of these the recovery procedure must restore and who can prove it. Each boundary change alters which recovery tests must be repeated.

Backup repositories and keys

Backup repositories, their catalogs and their encryption keys determine whether recovery can happen at all. If a repository sits outside the boundary but holds the only copy of user data, the assessor will still ask how reconstitution works. Decide whether the key custody process is in scope, because a restore that depends on a missing key is a failed recovery. Ask who holds the key material and how it is restored.

Impact level and baseline

The impact level selects the baseline, and CP-10 is selected in the low, moderate and high baselines but not in the privacy baseline. Moderate adds transaction recovery, and high adds restore within a time period on top of that. A system categorized as low has fewer enhancements to evidence, so categorization decisions directly change the testing scope. Confirm the categorization with the authorizing official before scoping recovery tests.

Transactional and database systems

Systems that commit transactions need recovery to a consistent point, not just a restored file set. If the system is moderate or high, the transaction recovery enhancement applies, and the team must show that partially committed work is handled correctly after a restore. Identify which applications write to databases, queues or ledgers inside the boundary. These systems usually need the longest and most involved recovery exercises.

Recovery responsibilities across teams

Recovery work usually spans platform engineering, application owners, database administrators, security and the business owner who accepts data loss. Each role needs a named responsibility in the contingency plan and a person who can take it on during an event. Gaps often appear where the platform team restores infrastructure but no one owns application verification. Assessors interview these people, so their roles must match the written procedure.

Third parties with recovery duties

Cloud providers, managed hosting, backup services and software vendors may hold parts of the recovery path. Their contracts and support commitments decide what the organization can actually restore and how quickly. If a provider controls the reconstitution steps, the organization still owns the outcome and needs evidence of the provider's role. Confirm which recovery steps each third party performs and what documentation they supply.

Which baselines select CP-10 and its enhancements

The low baseline selects CP-10 itself, so a system categorized at low impact must provide for recovery and reconstitution of the system to a known state within a defined period, consistent with its recovery time and recovery point objectives. The baseline does not select any CP-10 enhancement in the current release, so the obligation is the base control only. An assessor will still expect the defined period, the objectives and the evidence that a recovery was performed and checked.

Base control only: CP-10 is the sole CP-10 item selected for low impact systems.
No enhancements selected: Transaction recovery and timed restore are not required at this level.
Defined values still matter: The recovery period and objectives must be set by the organization, even though the baseline does not add enhancements.
Evidence of a real recovery: Records of a restore or rebuild to a known state carry more weight than a written procedure alone.
Shared responsibility: Cloud or hosting providers may own parts of recovery, so document which party performs each step.

Confirm in your own baseline profile that CP-10 is selected at low impact and that no enhancement appears for your system.

How an assessor tests CP-10 recovery and reconstitution

This table walks through the two determination statements SP 800-53A attaches to CP-10, the examine, interview and test methods used for each, and the objects an assessor pulls. Read each row as a question the assessor asks and the evidence that answers it. The main takeaway is that a plan on paper is not enough: assessors look for recent recovery tests and records that show the system returned to a known state.

Assessment method	Assessment objects named in SP 800-53A	Evidence an assessor expects	Common findings
Examine: contingency plan	Contingency plan with recovery and reconstitution procedures	Current plan that states recovery steps, sequence, roles and the known-state definition for each system	Plan describes restore steps but never defines what a known state is for the system
Examine: system backup test results	Results from backup restore tests tied to recovery objectives	Dated restore test records showing files or systems returned and checked against recovery point objectives	Backups run on schedule but no restore has been tested in the review period
Examine: contingency plan test results	Recorded outcomes of recovery exercises, including failed steps	Exercise reports with measured recovery times, issues found and corrective actions with owners	Results are summarized as passed without times, or failed steps are not tracked to closure
Examine: contingency plan test documentation	Test scripts, scenarios and scope for recovery exercises	Written test plans that name the system, scenario, success criteria and participants	Tests are ad hoc, so an assessor cannot tell which system state was verified
Examine: redundant secondary system for backups	Secondary or redundant system used to hold or restore backups	Configuration and inventory records showing where backups are held and how a secondary system is kept current	Secondary copy exists but is out of date or was never used in a restore test
Interview: personnel with recovery and reconstitution responsibilities	Staff who run restores, validate systems and decide when service returns	Staff can describe their steps, their authority and how they reach the known-state checks	Responsible staff differ from those named in the plan, or they have never run the procedure
Test: organizational processes for system recovery and reconstitution	Operational process for bringing a system back to a known state	Observed restore or reconstitution run, or a supervised walkthrough, compared with the documented process	Process works only with the engineer who wrote it, and steps depend on undocumented access

How to implement CP-10 recovery and reconstitution in order

This sequence moves from defining recovery targets to proving that a system can be rebuilt to a known state within those targets. Each step produces a record an assessor can examine, interview against or test.

Define recovery objectives for each system
The system owner, with the business owner of each service, sets a recovery time objective and a recovery point objective for every system in scope of CP-10. The objectives come from the impact of losing the system, not from what the backup tool happens to deliver. Done means each system has approved objectives recorded in the contingency plan, with the approver and date shown. Assessors will ask for the signed objectives and trace them into the plan and the test records.
Define the known state for each system
For each system, the technical owner writes down what a correct recovered state means. That covers the approved configuration baseline, the data set and its consistency points, cryptographic keys and certificates needed to start services, and the versions of operating systems, middleware and application components. Done means a reconstitution definition exists per system that someone other than its author could check against. The assessor will look for these definitions and compare them with the configuration baseline records.
Document reconstitution procedures
The technical team writes step-by-step procedures that take a system from bare infrastructure or a clean image to the known state. The procedures name the backup sets or configuration records used as inputs, the order of rebuild, the validation checks after each stage and the point where service is handed back. Done means each procedure is version-controlled and tied to a specific system. The assessor will ask to see the current procedure and the change history that shows it was reviewed after system changes.
Assign recovery roles and contacts
The incident or continuity lead assigns named people to each recovery task, including who declares recovery, who runs each rebuild procedure, who approves the restored system and who communicates with business owners. Each role has a primary and an alternate, and contact details are kept outside the systems being recovered. Done means the role matrix is current and staff have acknowledged their roles. The assessor will interview these personnel to confirm they know their responsibilities and can find the procedures.
Run recovery tests from backups and configuration records
The recovery team runs a test that rebuilds a representative system from its backups and configuration records, following the documented procedure without relying on the original host. The test runs in an isolated environment that matches production as closely as the plan requires. Done means the rebuilt system is checked against the known state definition and the elapsed time is measured against the recovery time objective. Assessors will examine the test plan, the test log and the restored system's validation output.
Verify the restored data and transactions
Where the system handles transactions, the team checks that recovered data reaches a consistent point, that no committed transactions are lost beyond the recovery point objective, and that in-flight transactions are rolled back or completed as the procedure states. Backup integrity checks, such as a verification of backup data or a read-back of stored blocks, support this check. Done means the verification results are recorded with the point in time the data reached. The assessor will compare these results with the recovery point objective.
Record results and correct gaps
The team writes up each test with the systems covered, the procedure version used, the measured recovery time and data point, every deviation and the owner and due date of each fix. Gaps feed back into the objectives, known state definitions, procedures and role matrix, and the next test confirms the fixes. Done means a signed test report exists and open findings are tracked to closure. The assessor will ask for the test results, the test documentation and evidence that problems were corrected.

How Bareos and restic produce recovery evidence

Self-hosted backup tools can produce much of the restore and integrity evidence an assessor asks for under CP-10, but they do not satisfy the control on their own. The organization still owns the recovery objectives, the procedure for reconstituting the system to a known state, and the decision about what counts as a successful recovery. Treat each tool as a source of records that feed those decisions. Bareos is an open-source backup system released under AGPL-3.0-only. Its Director schedules and supervises backup, restore, verify and archive jobs, and it keeps a SQL catalog of the files it has backed up. That catalog lets an operator restore selected files from the current backup or from the state at a given date and time, which is the kind of point-in-time restore a recovery point objective depends on. Confirm which job types, catalog database and storage backends your deployment uses, and whether a restore job log is retained in a form your assessor can read. Bareos restores files and job records; it does not, by itself, rebuild an operating system, its configuration or its application dependencies to a known state.

restic is a backup program under the BSD-2-Clause license. Running restic check verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset makes it read pack files back and confirm that the stored data has not been modified, which is useful evidence for backup integrity and for the backup testing that CP-10 scenarios rely on. Record the command, the options used, the repository identifier, the date and the output, and keep those records with the contingency plan test results. Decide how much of the repository to read on each run, since a full data read takes longer and touches more storage. Confirm the flags and retention behavior against the version you deploy, as the restic documentation on working with repositories describes them. The gap between restore and reconstitution is where most assessments fail. A successful Bareos restore or a clean restic check shows the data is available and intact, but it does not show that the system returned to a documented, approved baseline within the defined time. Write the reconstitution procedure, name the people who run it, define the acceptance checks, and run a test that measures elapsed time against the recovery time objective. Keep the restore logs, check output and test write-ups together so that one recovery exercise can be traced from the disruption scenario to the final verified state.

What evidence passes a CP-10 assessment

An assessor testing CP-10 looks for proof that recovery and reconstitution work in practice, not only on paper. The cards below cover the documents, test records and logs that connect a plan to a demonstrated known state, measured against the recovery objectives the organization has set. Each artifact needs an owner and a refresh routine so it still describes the system an assessor samples.

Recovery procedures for each system

Write one recovery procedure per system in scope, naming the systems it restores, the order of restoration, the backup sources used, the people who act and the point at which recovery is declared complete. Assessors compare these procedures against the system inventory, so a procedure for a retired server or a missing dependency is an immediate finding. Tie each procedure to the recovery time and recovery point objectives set in the contingency plan. Keep it current by re-reading every procedure after each significant change and recording the review date and reviewer in the document history.

Recovery test records with objectives and measured results

A test record should state the scenario, the objective it was checked against, the start and end times, what was restored and what the measured result was. Assessors look for a gap between the target and the measured value and for the corrective action that followed any miss. Record failed steps as well as passed ones, because a clean history with no failures often prompts questions about how the test was run. Keep it current by logging each exercise as it happens, not reconstructing it later from memory.

Reconstitution checklists tied to a known-state definition

Reconstitution means returning the system to a state the organization has defined as trustworthy, which usually includes verified configuration, patched software, restored access controls and confirmed data integrity before return to service. The checklist should reference that definition explicitly and require a sign-off for each item. Without this link, an assessor cannot tell whether the system was restored or merely started again. Keep it current by updating the checklist whenever the baseline configuration or the definition of a known state changes.

Backup restore logs

Restore logs show that backups can actually be read and returned to a working system, which is the proof behind any recovery claim. For open-source tools such as Bareos, the job and restore history in the catalog shows which files were restored, from which backup and at what time. For restic, the output of restic check with the read-data option shows that stored pack files were read back and verified. Keep it current by scheduling restore jobs and integrity checks and retaining their logs under the same retention rule as the backups themselves.

Transaction recovery test records for moderate and high systems

Moderate and high baselines select the transaction recovery enhancement, so the assessor will expect evidence that transactions in flight at the time of a disruption are either completed or rolled back to a consistent state. A test record for this should show the transaction types tested, how partial transactions were identified and how data consistency was confirmed afterward. Ask the application owner to confirm the expected outcome for each transaction type before the test runs. Keep it current whenever a database engine, application version or transaction flow changes.

Restore-within-time test results for high systems

The high baseline adds the restore-within-time enhancement, which asks whether recovery completes within a defined period. Evidence is a timed test result for each high-impact system, showing the defined period, the measured restoration time and the date of the test. Record the conditions under which the test ran, such as data volume and network path, because an assessor will question a timing that was measured under easier conditions than a real event. Keep it current by repeating the timed test on a defined schedule and after any change that affects data volume or the restore path.

What CP-10 recovery testing costs in money and effort

This table breaks down the cost components of meeting CP-10 recovery and reconstitution, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to shape the questions you put to a written quote. No figures are given because none are supplied for this topic, so the right column tells you what to request.

Cost component	Who is paid and for what	One-time or recurring	What drives it, and what to ask for in a quote
Backup and recovery tooling or licenses	Software vendor or none if self-hosted open source is used	Licenses recur if commercial; open-source software carries no license fee but still needs hosting and staff	Number of systems and data volume in scope. Ask whether the quote includes licensing, support subscriptions and hosting separately.
Engineering time to build recovery procedures	Implementation partner or internal platform engineers	One-time for initial runbooks and reconstitution build-out, then recurring updates	Count of in-scope systems, dependency complexity and number of defined recovery objectives. Ask for the deliverables list and the acceptance criteria.
Recurring recovery tests	Internal operations staff, with an optional partner running or observing the exercise	Recurring at the frequency the organization defines for CP-10 testing	Scope of each test (single component or full rebuild to a known state), environment availability and staff time. Ask how each test is scoped and what the report contains.
Transaction recovery and restore-within-time testing	Internal database and application owners, possibly a partner	Recurring where the moderate or high baseline enhancements apply	Transaction volume, database size and how restore timing is measured. Confirm whether the quote covers timed restore exercises.
Evidence upkeep	Internal compliance or platform staff, or a partner preparing evidence	Recurring after every test and every significant system change	Retention rules, the number of systems and how automated the evidence capture is. Ask whether evidence collection is included or billed separately.
External testing or review	Independent testing firm or consultant reviewing the recovery design	Recurring if reviews repeat each cycle, one-time for initial design review	Depth of review and whether tests are unannounced. Ask for the scope statement and who issues the written findings.
Auditor or assessor sampling	Independent assessor, paid by the organization under its engagement terms	Recurring at each assessment cycle	Number of samples the assessor selects, which is set by the assessor, not the organization. Ask the assessor how many recovery test records they will request and how they will select them.
Replacing or upgrading recovery infrastructure	Hardware, cloud or hosting provider and implementation staff	One-time for initial build, recurring for refresh cycles	Storage capacity, alternate environment needs and hardware age. Ask for the sizing assumptions behind the quote.

Who owns CP-10 recovery: your team, a partner and the auditor

Your organization owns CP-10. The control asks that the system can be recovered and reconstituted to a known state within a defined period, and only your leadership can set that period, because it depends on your business impact, your recovery time objective and your recovery point objective. Your staff also decide what counts as a successful restore and who accepts the results. An outside partner can draft material, but the accountable decisions stay inside your organization.

Recovery objectives: Set and approve the recovery time and recovery point objectives for each system in scope, and record them in the contingency plan that CP-2 requires.
Test execution: Schedule recovery and reconstitution tests, run them with your operations staff, and include transaction recovery scenarios where the baseline selects them.
Results and sign-off: Review test results against the objectives, record gaps, and assign owners and dates for corrective action.
Ownership of evidence: Keep the test records, backup logs and approvals in your own repositories, where your auditor can request them.
Change control: Update procedures after system changes so that recovery steps match the system as it runs today.

Before you accept any recovery procedure, confirm that your named owner has signed off on the objectives it targets.

Where organizations fall short on CP-10 and how to close each gap

Most CP-10 findings come from recovery commitments that exist on paper but were never tested against real systems. The cards below pair each common gap with a closing action and the evidence an assessor will ask to see, so the recovery claims in the contingency plan can be checked against measured results.

Recovery objectives not defined per system

Many organizations state one recovery time and one recovery point for everything, or leave the values to the application owner's memory. CP-10 ties reconstitution to recovery time and recovery point objectives, so each system in scope needs its own documented values, approved by the business owner. Check that the objectives in the contingency plan match the figures in the system security plan and the backup schedule. An assessor will compare them.

Backups never restored end to end

A backup job that reports success proves only that data was written. CP-10 expects the system to return to a known state, which requires restoring the operating system, configuration and data onto clean or alternate hardware. Schedule full restore exercises for each system tier and record the elapsed time, the steps that failed and the person who signed off. Open-source tools such as Bareos can drive restore jobs from its catalog, so the restore log becomes the evidence.

No written definition of the known state

Reconstitution is complete only when the system reaches a state the organization has defined and can verify. Without that definition, teams declare recovery finished when the service responds, while integrity, configuration and security settings remain unchecked. Write the known state for each system as a checklist: software versions, configuration baseline, account and key material, and data integrity checks. Attach the checklist to the recovery procedure so each restore run can be compared against it.

Backup integrity not verified before restore

A restore can fail or silently import corrupted data if nobody has checked the backup repository. Run integrity checks on a schedule and keep the output. For restic repositories, the check command verifies structural consistency, and adding the read-data option reads pack files back to confirm the stored data is unmodified. Keep these results with the restore records, because an assessor will ask whether the backup used for recovery was known to be sound.

Transaction recovery untested on moderate and high systems

CP-10(2) addresses transaction recovery and is selected for moderate and high baselines. Many teams restore the database and assume in-flight transactions are consistent, but partially committed transactions, queued messages and interface states can disagree after a restore. Test the rollback or replay procedure with a defined set of transactions and confirm that reconciliation with dependent systems matches the expected results. Record the transaction counts before and after the test.

Restore-within-time claims without measured results

CP-10(4) applies to the high baseline and asks the organization to restore within a defined period. A statement such as "restored within the target window" means nothing without timed evidence. Measure each restore from the start of the recovery decision to the sign-off of the known state, compare the result with the defined period, and document any variance with an action in the plan of action and milestones. Ask the auditor which restore records they will sample before the test begins.

CP-10 questions buyers ask before bringing in a partner

How much effort does CP-10 take to meet?

The effort depends mostly on how many systems fall under CP-10 and how mature their recovery design already is. CP-10 is selected in the low, moderate and high baselines, and the moderate and high baselines add transaction recovery (CP-10(2)), while the high baseline adds restore within a time period (CP-10(4)). The biggest drivers are the number of systems, whether recovery objectives are documented per system, how many restore paths exist (for example, full image restore versus file-level restore), and how much evidence of past restores already exists. Ask any partner to break the effort into discovery, recovery design, restore testing and evidence collection, and to state which parts are one-time and which recur with each test cycle.

Can our team meet CP-10 in-house without outside help?

Often yes, if the team already runs backups and restore tests and can document the results. CP-10 asks for recovery and reconstitution to a known state within a defined period, consistent with recovery time and recovery point objectives, so the core questions are whether your objectives are written down and whether you can demonstrate a restore against them. Teams that lack a restore history, have unclear system ownership, or have never measured restore duration usually need help designing the tests and collecting evidence. An outside partner can prepare systems and evidence, but your organization still owns the control and the decisions about its objectives.

What does CP-10 require from our staff day to day?

CP-10 needs named people who understand recovery and reconstitution, and it needs them to be able to show their work. The assessment procedure for CP-10 includes interviews with personnel who hold contingency planning, recovery and reconstitution responsibilities, so those people must know the procedure, the objectives and the test history. Your staff also need access to restore tooling, permission to run restores in a controlled environment, and time to perform and record tests. Ask a prospective partner which skills they will transfer to your team and which tasks stay with your staff after the engagement ends.

How long does a CP-10 engagement take?

No duration is fixed for CP-10, so the timeline should follow your own test cycle rather than a generic estimate. Start by listing how often you already run restore tests, how long a full restore of your most important system takes, and when your next assessment or audit is scheduled. Those three facts set the working window. A fixed-scope engagement should state its milestones, the restore tests it will run, and the evidence each milestone produces, all agreed in writing before work starts. Be wary of any timeline quoted before the scope and your restore data are known.

Do open-source backup tools remove the cost of licenses for CP-10?

Open-source tools can remove commercial backup license fees, but they do not remove the work of designing, testing and documenting recovery. Bareos is licensed under AGPL-3.0-only, and its Director schedules backup, restore and verify jobs, keeps a SQL catalog of backed-up files and restores files from the current backup or from one taken before a given date and time. restic is licensed under BSD-2-Clause, and its check command verifies snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm stored data is unmodified. Still, you pay for infrastructure, storage, staff time and any partner work. Ask for a quote that separates software, hardware, labor and recurring test costs.

What can an implementation partner not do for CP-10?

A partner cannot issue the assessment result. Independent auditors, assessors or certification bodies determine whether CP-10 is met, and they do so by examining documents, interviewing personnel and testing the recovery process. A partner can prepare the restore environment, run and record tests, draft recovery procedures for your review and organize the evidence an assessor will request, such as the contingency plan, backup test results and contingency plan test documentation. Your organization must own the control, approve the recovery objectives and accept the risk. Confirm with any partner, in writing, that the work product is preparation and that the assessment belongs to a separate, independent party.

Which CP-10 evidence should we gather before asking for a quote?

Gather the material that shows how recovery works today and where it falls short. Useful items include your recovery time and recovery point objectives for each system, the most recent restore test results, backup job logs, the contingency plan and its test documentation, and a list of systems that depend on each other. Also note any system that lacks a current restore test, because those gaps set much of the scope. Sharing this material lets a partner give a fixed-scope quote that reflects your actual environment instead of a generic template, and it helps your internal team see the same gaps the assessor will look for.

How DeployOpen scopes and prepares CP-10 evidence

DeployOpen works on CP-10 as part of a written, fixed-scope engagement inside your own infrastructure. We prepare the recovery and reconstitution capability and the evidence an assessor will examine, while your organization keeps ownership of its recovery objectives, controls and decisions.

How we scope

Confirm which systems fall within the CP-10 baseline selection, including whether the moderate or high enhancements apply.
Record your recovery time and recovery point objectives and the known-state definition each system must return to.
Agree in writing which recovery tests, documents and handover items are included and which remain your responsibility.

How we build

Configure self-hosted backup and restore tooling, such as Bareos or restic, to match the agreed recovery objectives in your environment.
Build restore procedures for the system state, transaction recovery and restore-within-time requirements in scope.
Run verification and restore tests and capture results so each determination statement in the assessment procedure has traceable output.

How we hand over

Deliver recovery procedures, runbooks and test records mapped to the CP-10 examine, interview and test objects.
Walk your contingency and operations staff through restore steps so the people named in the plan can perform them.
Provide a clear list of artifacts and the open items your independent assessor will ask about, without issuing any audit opinion ourselves.

How we support

Offer ongoing support and scheduled restore testing as a retainer after the fixed-scope work closes.
Update recovery procedures and test evidence when systems, backup targets or recovery objectives change.
Review results from periodic restore tests and help your team correct problems before the next assessment cycle.