CP-9 System backup: requirements and evidence

What CP-9 system backup requires and why assessors test restores

If you are preparing a system for an SP 800-53 assessment, CP-9 asks you to back up three things at frequencies you define: user-level information on the components you name, system-level information, and system documentation, including security and privacy documentation. It also asks you to protect the confidentiality, integrity and availability of those backups. The control exists because a system that cannot be restored after data loss, corruption, ransomware or a failed change cannot meet its recovery objectives, whatever its other controls look like. Your assessor will expect the backup scope, schedule and protection to be written down, approved and visible in the backup platform's own records, not described from memory.

The three parts deserve separate attention because teams usually cover only the first. User-level information is the business data held by the system. System-level information includes configuration, operating system state and the parameters needed to rebuild the system. Documentation covers the security and privacy plans and related records you would need after a rebuild. For each part, record the components in scope, the frequency you have defined for it, and the owner who signs off on that frequency. The frequencies are organization-defined parameters, so an assessor will compare what your plan says with what the backup job actually runs, and any gap will be recorded as a finding.

The protection requirement is where programs most often fall short. A backup that anyone with the storage credentials can read or silently alter does not satisfy the confidentiality or integrity expectations, and an unencrypted off-site copy is a common finding. Ask your team to show, for each backup repository, who can read it, how encryption keys are stored and rotated, and how corruption is detected. Open-source tools can supply part of this evidence: restic's check command with --read-data-subset can verify that stored pack files are unmodified, and OpenBao's transit engine can hold versioned keys outside the backup server. Confirm the exact behavior of each tool in your environment before you cite it, because the assessor will test what you say the tool does.

Which systems, data and third parties CP-9 covers in your boundary

CP-9 work is decided before any backup job is configured. The boundary choices below determine which components, data types, impact levels and providers the control reaches, and each one changes what an assessor will ask you to show.

User-level information on defined components

CP-9 requires backups of user-level information on the components you define, so the first decision is which hosts, databases, file stores and object buckets hold user data inside the boundary. List each one by name and owner. Check for data that lives outside the obvious stores, such as collaboration file shares, exports and caches that users rely on. An assessor will compare your component list against where user data actually resides.

System-level information and configuration

System-level backups cover the information that lets you rebuild the platform, such as configuration files, audit logs, and where applicable the keys needed to decrypt protected data. Backing up encrypted data without a recoverable key path is a common gap. Confirm which system-level items you back up, where they are stored, and who can restore them.

System and privacy documentation in scope

CP-9 also reaches system documentation, including security and privacy documentation. Decide whether runbooks, architecture records, the contingency plan itself and privacy artifacts are copied into backup storage and at what frequency. Keep a current copy outside the primary environment so recovery teams can work when the primary site is unavailable.

Impact level selects CP-9 and its enhancements

SP 800-53B selects CP-9 in the low, moderate and high baselines, and the enhancements vary by level. CP-9(1) and CP-9(8) appear in moderate and high, while CP-9(2), CP-9(3) and CP-9(5) appear only in high. Confirm your system's impact categorization with your authorizing official before you size the backup program, because it sets which enhancements an assessor will test.

Privacy baseline exclusion

CP-9 is not selected in the privacy baseline. If a system is scoped only to privacy controls, CP-9 does not apply on that basis alone, but personal data it holds may still be covered by the security baseline it runs under. Document which baseline applies to each system so the scoping decision is traceable.

Hosted backup providers as third parties

Cloud or hosted backup services become part of your supply chain and must be covered by agreements that define retention, location, access and deletion. Ask providers for their own backup testing evidence and for how they protect your backup data. Where you run self-hosted tools such as Bareos or restic in your own accounts, the provider relationship changes, but the storage target still needs review.

Which CP-9 enhancements apply at moderate and high impact

CP-9 is selected in the low, moderate and high baselines, but CP-9 enhancements are where moderate and high systems take on extra work. SP 800-53B Release 5.2.0 selects CP-9(1), testing backups for reliability and integrity, and CP-9(8), cryptographic protection of backup information, in both the moderate and high baselines. CP-9(2), test restoration using sampling, CP-9(3), separate storage for critical information, and CP-9(5), transfer to an alternate storage site, appear only in the high baseline. CP-9 is not selected in the privacy baseline. CP-9 has eight numbered enhancements in Release 5.2.0, but CP-9(4) is withdrawn, so seven are current. Confirm the selected baseline and the enhancement list in your system security plan against the OSCAL profiles before you scope the work, because tailoring can add or remove items.

Reliability and integrity testing under CP-9(1) means proving that backups can actually be read and are not silently corrupted. In practice, the operator schedules verification runs against the backup repository and records the results. Sampled restore testing under CP-9(2) goes further: the team restores a selected set of files or systems into a non-production environment and checks that they work. Tools such as restic can verify structural consistency and, with --read-data or --read-data-subset, read pack files back to confirm the stored data is unmodified. Bareos keeps a catalog of backed-up files and restores from a chosen point in time, which supports the sampling record. Ask the team who selects samples, how often restores run, and where the results are kept.

Separate storage for critical information under CP-9(3) and cryptographic protection under CP-9(8) each add design decisions. Separation means keeping critical backups apart from the primary system's failure domain, such as separate accounts, credentials or storage media, and documenting the rationale. Cryptographic protection needs key management: an encrypted backup is only recoverable if its keys are held securely and can be restored. Nextcloud server-side encryption keeps keys on the server and does not encrypt file names or folder structure, so confirm how metadata is protected. OpenBao's transit secrets engine supports versioned keys and rotation, which can separate key custody from the backup system. Confirm with each product's documentation how it handles keys before relying on it.

How an assessor tests CP-9 with examine, interview and test methods

This table breaks down how SP 800-53A Rev. 5 assesses CP-9 System backup, grouping the six determination statements by what they check and listing the examine, interview and test objects an assessor uses. Read each row as a question the assessor will ask, then confirm the matching evidence exists in your environment before the assessment starts.

Assessment element	What the assessor checks	Evidence to have ready
Backup scope and frequency	Whether user-level information, system-level information and system documentation are defined for backup, and whether each has a defined frequency	Backup policy or contingency plan section listing scope and frequency per data class, with the component inventory it references
Backup protection	Whether confidentiality, integrity and availability of backup information are protected in storage and transit	Access control lists on backup repositories, encryption configuration, and documented protection of backup media
Backup storage location	Whether backup storage locations are defined and matched to the plan	Documented backup storage location(s), with any offsite or separate location identified
Backup execution records	Whether backups actually run at the defined frequency and are logged	System backup logs or records covering a sample period, with failures and reruns shown
Backup testing and restore	Whether backup information is tested for reliability and integrity, and whether restoration is exercised (CP-9(1), CP-9(2) at high baseline)	Test plans, verification job reports, restore test results and tickets for corrective action
Personnel responsibilities	Whether named personnel with system backup responsibilities know their duties and can explain the process	Role assignments and interview notes from staff who run, monitor and restore backups
Backup processes in practice	Whether organizational processes for conducting backups are documented and followed as written	Runbooks, job schedules and change records showing the process as operated

How to implement CP-9 in sequence, with the output of each step

This sequence takes CP-9 from a scope decision to a tested, documented backup capability that feeds the system contingency plan. Each step produces an artifact an assessor can examine, so the chain from requirement to evidence stays visible.

Define backup scope and frequencies per component
The organization owns this decision, with system owners and the people accountable for the contingency plan. List every component that holds user-level information, system-level information and system documentation, including security and privacy documentation, then set a backup frequency for each one and record which components are covered. Assign each frequency to a named owner. The step is done when the organization approves a backup scope document that maps each component to its frequency and owner, because CP-9 requires the frequency to be defined rather than implied.
Select backup tooling and storage locations
Choose the backup software and the storage targets that will hold copies, then confirm each choice against the scope from the previous step. Open-source options such as Bareos, which keeps a SQL catalog of backed-up files and supports restore from a chosen point in time, and restic, which supports repository integrity checks, are candidates to evaluate in the client environment. Confirm storage locations, including any that are separate from the primary system. The output is a tooling decision record and a storage location register, with each location named and its owner recorded. Confirm licensing and operational fit with the vendor or project before adoption.
Configure encryption, access control and separation
Protect backup information before the first job runs. Enable encryption for backup data and decide where keys are held, using a key management service that supports versioned keys and rotation, such as the OpenBao transit secrets engine, if it fits the environment. Restrict who can read, change or delete backup data, and keep administrative access to backup systems apart from day-to-day operations. For the high baseline, plan separate storage for critical backup information as CP-9(3) requires. The output is a configuration record and an access review listing who holds each permission, which supports the confidentiality, integrity and availability goal of the control.
Run backups and log every job
Schedule the backup jobs defined in step one and run them under the configured controls. Keep logs of each job, including start and end times, the components covered, the outcome and any errors. Store these logs where the backup administrators cannot quietly alter them, so that an assessor can compare the logs with the defined frequencies. Review failed jobs on a set cadence and record the corrective action. The output is a backup log set and an exception register, which is the main evidence an examiner will request to confirm that backups happen as defined.
Test backup integrity and restores
Verify that backups can be read and used. For the moderate and high baselines, plan reliability and integrity testing under CP-9(1). For the high baseline, plan restore tests that use sampling under CP-9(2), so a defined share of backups is restored and compared with the source. Tools with verification modes, such as restic check with its data read options, can confirm that stored pack data is unmodified. Record the test scope, the sample selected, the restored result and any discrepancies. The output is a restore test report with pass or fail results per sample, which shows that backups work as well as exist.
Document results and update the contingency plan
Bring the findings into the system contingency plan that CP-2 requires, updating recovery procedures, roles, contacts and recovery objectives where backup testing showed gaps. Record each finding in the plan of action and milestones with an owner and a closure check. Confirm that the backup procedures match what the tools actually do. The output is an updated contingency plan version, a list of tracked findings and an approval record from the accountable official. Assessors use these records to judge whether backup results shape recovery planning or sit in isolation.
Prepare evidence for independent assessment
Assemble the evidence package an assessor will examine, mapped to the CP-9 assessment objects in SP 800-53A: the contingency plan, backup storage location records, backup logs and the staff with backup responsibilities. Ask the assessor to confirm the required evidence before fieldwork. DeployOpen can prepare systems and evidence, but only an independent assessor issues the assessment result. The output is an evidence index that links each claim about backup scope, frequency, protection and testing to a file the assessor can open.

Which backup evidence shows CP-9 is met, by system type

For self-hosted file and server backups, an assessor typically starts with the backup schedule and works backward to the records that prove the schedule ran. CP-9 expects user-level information, system-level information and system documentation to be backed up at defined frequencies, so the evidence should show each of those three categories, not only the operating system images. Bareos is one example of open-source software whose Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files. Those records can serve as the core evidence set.

Job schedules: Exported schedule definitions showing frequency for each defined component, matched to the frequencies in the contingency plan.
Job logs and catalog entries: Completion records showing which files or volumes were backed up and when, drawn from the backup catalog.
Restore records: Documented restores of selected files from a current backup and from a prior point in time, with dates and results.
Scope mapping: A list tying each defined component to its backup job, so gaps are visible.
Documentation backups: Evidence that security and privacy documentation is included in the job scope.

Confirm with your auditor which frequencies the organization has defined, since those values come from your own contingency plan and not from the standard.

Evidence that passes a CP-9 assessment and how to keep it current

An assessor testing CP-9 looks for documents that define what gets backed up and how often, records that prove backups ran and restores work, and controls over where backups live and how they are protected. Each card below covers one evidence item and the routine that keeps it accurate between assessments.

Defined backup frequency documentation

CP-9 requires backups at defined frequencies, so the organization must state those frequencies per component, per data class and for system documentation. Keep the schedule in the system security and privacy plan and the contingency plan, and tie each frequency to a recovery point objective. Review it whenever a system is added, a data store moves or a recovery objective changes. Check that the schedule in the backup software matches the written schedule, because drift between the two is a common finding.

Backup job logs and catalog records

Job logs and catalog entries show which backups ran, when, against which components and whether they succeeded. Bareos keeps a SQL catalog of backed-up files and runs backup, restore, verify and archive jobs under its Director, so its job history and catalog are primary evidence. Export or retain these records on a schedule that covers the assessment period, and alert on failed or missed jobs. Confirm that log retention is longer than your review cycle.

Restore test records and sampled restores

Assessors look for proof that backups can be restored, not only that they were taken. Keep dated restore tests with the scope, the person who ran them, the result and the time taken against the recovery objectives. Sampled restores support the CP-9(2) enhancement, which is selected in the high baseline only. Rotate samples across systems and data types so every tier is exercised over time, and record failures with the corrective action.

Integrity verification output

CP-9(1) relates to testing backups for reliability and integrity, so the output of verification runs is evidence. restic check verifies the structure of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm stored data is unmodified. Save the command output with the repository identifier and date. Decide how often full reads run, because reading all data is slower than structural checks alone, and document that choice.

Protection and key management records

CP-9(8) requires cryptographic protection of backup information, so assessors ask how keys are generated, stored, rotated and who can use them. Record the encryption method, the key-management configuration and the key rotation history. OpenBao's transit secrets engine supports versioned keys and rotation, and Nextcloud server-side encryption keeps keys on the server but does not encrypt file names or folder structure, which should be stated in the evidence. Review access to keys and the rotation log at each review cycle.

Storage location documentation

Assessors check where backup copies are kept, including whether any copy is separated from the primary environment, as CP-9(3) and CP-9(5) require in the high baseline. Maintain an inventory of each backup repository, its location, its access path and its owner, and update it when storage moves or a new alternate site is added. Confirm that the storage agreements and alternate site records referenced in CP-6 still match what is actually in use.

What meeting CP-9 costs in tooling, engineering time and assessor effort

This table breaks the cost of meeting CP-9 into its components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request, because no price or duration is published for CP-9 and every figure depends on your own environment and scope. The main takeaway: dropping a license fee by choosing open-source tooling does not remove the engineering and restore-testing effort that an assessor will sample.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it
Backup storage and infrastructure	Cloud provider, data center operator or hardware vendor	Recurring	Volume of user-level and system-level data, retention periods, number of copies and offsite capacity
Tool licenses	Software vendor, if a commercial product is chosen	Recurring	Number of protected systems and agents; open-source options such as Bareos or restic remove license spend but not labor
Engineering time to configure and test	Internal staff or implementation partner, under a written scope	One-time	Number of systems in scope, backup frequency defined by the organization, and whether enhancements such as CP-9(8) cryptographic protection are required
Restore testing effort	Internal operations team or retained partner	Recurring	Test frequency, number of restore samples chosen for CP-9(2), and size of the restored data sets
Evidence upkeep	Internal compliance or security staff	Recurring	Frequency of backup logs and job reports, how often the contingency plan changes, and how many systems are reviewed
External review	Independent assessor or consultant	Recurring at each assessment cycle	Impact level of the system, which baseline applies (low, moderate or high), and how many enhancements are assessed
Assessor sampling	Independent assessor, billed under the engagement terms	Recurring at each assessment cycle	Number of backup jobs, storage locations and restore records the assessor samples, as set by the assessment plan

Who owns CP-9 and what an implementation partner can take on

Your organization owns CP-9 in full. Backup is a control you are accountable for, so the decisions that define it belong to you: what must be backed up, how often, how long copies are kept, who may authorize a restore, and which residual risks you accept when a backup falls short of the target. An implementation partner can draft proposals for these decisions, but the approval and the signature on the policy sit with your management.

Backup policy and scope: Define which user-level information, system-level information and system documentation fall under CP-9, and which components hold them.
Defined frequencies: Set the backup frequency for each category, since CP-9 requires a defined frequency and an assessor will test against the value you wrote down.
Restore decisions: Decide who can authorize a restore, under what conditions, and how restores are recorded.
Risk acceptance: Document any gaps, such as a backup target that cannot be met on a given component, and the owner who accepts that risk.

Before you engage anyone, confirm that these decisions exist in writing and that the owners named in them have agreed to their roles.

Where CP-9 programs usually fall short and how to close each gap

Most CP-9 findings are not about whether backups run at all. They come from backups that were never proven to restore, frequencies nobody defined, and copies that depend on the same keys and credentials as production. Each card names one gap, what an assessor will look for, and the closing action to take before the assessment.

Backups configured but never restored

A backup job that reports success proves only that data was written somewhere. CP-9 expects the organization to show that the data can be recovered. Pick a defined sample of systems each cycle, restore them to an isolated environment, and record the time taken and whether the application starts. Keep the restore tickets as evidence, because a job log alone rarely satisfies an assessor.

Undefined or inconsistent backup frequencies

CP-9 requires backup at a frequency the organization defines, so an unwritten or inconsistent schedule is a finding on its own. Compare the schedule in the backup server with the frequency in the system security plan and the contingency plan. Mismatches often appear when a system was moved to a new platform and the old job stayed in place. Record one frequency per component and review it after each significant change.

System documentation left out of backups

CP-9 covers system-level information and system documentation, including security and privacy documentation, not only application data. Teams often back up databases and file shares but omit configuration files, infrastructure-as-code, runbooks, key recovery material and the contingency plan itself. Build an inventory of documentation sources, assign each one to a backup job, and confirm during a restore that the documents are readable offline.

Backup copies sharing keys with production

When backup encryption keys, admin credentials or the backup repository password live in the same vault or account as production, one compromise can reach both copies. This weakens the integrity and availability protections CP-9 expects. Store backup keys separately with their own access policy, and consider enhancement CP-9(8) for cryptographic protection where the moderate or high baseline applies. Test that a restore works after rotating production credentials.

No evidence that backups are verified

A verification step only counts if its output is kept. Scheduled integrity checks on backup repositories show that stored data is structurally intact, and periodic read-back of data confirms it has not been modified. Record the check command, its date, the repository checked and the result. Where a full read is too costly for each run, document the subset strategy and its coverage so an assessor can judge the sampling.

Backups not linked to the contingency plan

The contingency plan should name which backups recover which systems, who starts a restore, and the recovery objectives the backups must support. When these live in separate documents, the restore procedure in CP-2 and the backup catalog in CP-9 drift apart. Map each critical system to its backup job, retention set and alternate storage location, then confirm the mapping during contingency plan testing.

CP-9 questions buyers ask before bringing in outside help

How much effort does meeting CP-9 system backup take?

Effort depends on how many systems are in scope, how much data each one holds, how many backup frequencies the organization has defined, and how much of the backup estate already runs on tooling. No effort figure is supplied for this control, so treat any number you hear as unverified until it is tied to a written scope. The main effort drivers are: defining which user-level data, system-level data and documentation must be backed up and how often; configuring the backup jobs and their retention; producing logs that show the jobs ran; and testing restores. Restore testing and cryptographic protection (CP-9(1), CP-9(2), CP-9(8)) usually add more work than the basic backup job. Ask any provider to split effort into design, build, evidence collection and recurring operation.

How long does CP-9 implementation take?

The timeline depends on scope, and no duration is given here because none has been supplied. A system with a single backup target and existing jobs moves much faster than an estate with several databases, legacy storage and undocumented backup schedules. Time is usually spent on agreeing the defined frequencies, getting access to the systems being backed up, building the backup and catalog infrastructure, and running at least one full restore test before anyone can show evidence. Ask for a timeline in the written scope that lists each milestone, the client dependencies behind it, and what happens if a dependency slips.

What does the organization need to provide for CP-9 work?

The work needs decisions and access that only the organization can provide. Expect to supply a list of the systems and data that count as user-level information, system-level information and system documentation; the defined backup frequencies; the retention and storage locations the business accepts; and named owners who will answer for backup results. The team also needs administrative access to the systems being backed up, the backup storage, and the key management service used for encryption. Without these inputs, an implementation partner can build the mechanics but cannot confirm that the backups meet the organization's own definitions.

Can self-hosted open-source tools produce CP-9 evidence?

Yes, open-source tools can generate much of the evidence CP-9 assessors look for, but the tool does not make the control compliant on its own. Bareos schedules backup, restore and verify jobs and keeps a SQL catalog of backed-up files, which provides job records and a restore history. restic's check command verifies the structure of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm the stored data is unmodified. Nextcloud server-side encryption protects file contents at rest but does not encrypt file names or folder structure, so confirm that gap against your data classification. OpenBao's transit engine can handle encryption of backup keys and key rotation. Confirm each tool's capabilities against your own environment before you rely on it in an assessment.

Will an assessor accept open-source backup evidence?

An assessor accepts evidence that shows the control operated, not evidence that a particular product was used. SP 800-53A directs assessors to examine the contingency plan, backup storage locations and backup logs or records, to interview the people with backup responsibilities, and to test the organization's backup processes. Open-source tools can supply the logs, catalog reports, check output and restore test records those steps require. The independent assessor decides whether the evidence is sufficient, and DeployOpen does not issue assessment results. Agree the evidence list with the assessor before building it, so the team does not produce logs that answer a question nobody asked.

How does CP-9 relate to CP-6 and CP-10?

CP-9 covers creating and protecting backups. CP-6 covers the alternate storage site where backup information is kept and retrieved, so it sets where copies must be stored and how they are reached. CP-10 covers recovering and reconstituting the system to a known state within recovery objectives, so it is where backups are actually used. CP-9 backups must be usable for CP-10 recovery, and the frequencies and retention you set in CP-9 need to fit the recovery time and recovery point objectives in your contingency plan. The SP 800-53 catalog names CP-6 and CP-10 as related controls for CP-9, so assessors often review the three together. Map these controls to one set of recovery objectives before defining backup frequencies.

Should we do CP-9 ourselves or hire a partner?

Teams with mature backup operations and a documented contingency plan can often build CP-9 evidence in house, while teams without restore testing history or with complex legacy systems usually benefit from outside help. The decision comes down to skills, capacity and how much independent confidence you need. A fixed-scope engagement lets a partner set up the backup platform, document it and prepare the evidence, while the organization keeps ownership of its definitions and controls. The independent assessor still verifies the result. Ask any provider to state in writing what they will deliver, what they will not do, and which parts you must keep running after handover.

How DeployOpen scopes, implements and prepares CP-9 evidence

DeployOpen plans, implements, hardens and documents the backup system that CP-9 requires, inside the client's own cloud accounts, data centers or air-gapped networks. In practice that means agreeing in writing which user-level data on which components, which system-level data, and which system documentation fall inside scope, setting the backup frequency the organization has defined for each class, and deploying the open-source backup tooling against that inventory. Most engagements are fixed-scope, so the written scope should name the components, the retention and encryption decisions, the restore test types and the evidence deliverables before work starts. Ask the implementation partner to show how each defined frequency maps to a job schedule and a catalog or repository record that an assessor can examine.

The organization keeps ownership of the control. Its own staff set the defined frequencies, approve the backup scope, accept the risk of any exclusions and decide who holds the keys for backup encryption, which is the part where CP-9(8) decisions are made. DeployOpen's role is to prepare the systems and the evidence: configuration records, job logs, restore test records and runbooks that show what was tested, by whom and with what result. DeployOpen does not issue assessment reports, attestations or certifications. Independent assessors, such as the auditor or assessment team the organization engages, examine the evidence against the SP 800-53A procedures and reach their own determinations.

Before signing, confirm three things with the implementation partner: who runs the restore testing after handover and at what frequency, which parts of the work are one-time (design, deployment, initial restore tests) and which recur (job monitoring, test cycles, key rotation, tooling upgrades), and what the assessor will receive at the end. Those answers determine whether the organization needs an ongoing support arrangement after delivery. Any cost or duration figure should come from the written quote for that scope, not from general estimates.

CP-9 System backup