CP-9 is the federal control governing information system backup. For DoD components, civilian agencies, and their contractors, it defines not just what to back up — but how often, how securely, and how to verify that recovery is actually possible when it counts.
Key Takeaways
- CP-9 requires organizations to define, execute, and document backup procedures for all covered information system components — not just confirm that a backup tool is installed and running.
- Backup frequency, coverage, and testing requirements should be tied directly to the system’s FIPS 199 impact categorization and its documented Recovery Point Objective under CP-2.
- CP-9 enhancements address integrity testing, cryptographic protection, dual authorization, and separate storage — each targeting a distinct failure mode directly relevant to ransomware resilience and mission continuity.
- Producing backups is necessary but not sufficient. CP-9(1) and CP-9(2) exist because job completion logs do not demonstrate recoverability. Documented restoration testing is what closes that gap.
- DoD environments apply additional specificity through DISA STIGs, Mission Owner guidance, and program-level contingency requirements that may exceed the NIST baseline.
- Applicable enhancements must be validated against the system’s specific baseline, agency overlays, and AO expectations — they should never be assumed from a generic control table.
In This Article
Why CP-9 Matters for Federal Backup and Recovery
Federal missions do not pause for unplanned outages. Whether a system supports logistics, personnel records, financial operations, or national security functions, the ability to recover from disruption — hardware failure, human error, or deliberate attack — is a foundational mission assurance requirement, not an IT convenience.
CP-9 sits within the Contingency Planning family of NIST SP 800-53, which collectively governs an organization’s ability to sustain operations under adverse conditions. CP-2 establishes contingency planning strategy. CP-10 addresses system recovery and reconstitution. CP-9 provides the technical and procedural backbone that makes both executable: the backup itself. Without it, everything else in the contingency framework is theoretical — and assessors know it.
The adversarial context has also changed the stakes. Ransomware campaigns increasingly target backup infrastructure before deploying their primary payload — specifically because eliminating the recovery path extends dwell time, increases leverage, and delays mission restoration. An organization with untested, unprotected, or co-located backups is not in a better position than one with no backup at all. In some cases it is worse, because it carries false confidence into an incident response that quickly exposes the gap.
CP-9 provides the control structure to make backup operations auditable, consistent, and aligned with documented recovery objectives — and to give ISSOs, ISSMs, and AOs evidence they can actually stand behind during assessments and authorization decisions.
For most federal organizations, CP-9 should be understood as part of a broader backup, protection, and cyber recovery strategy — not a standalone checklist item that lives only in the SSP.
NIST 800-53 CP-9: The Requirement Explained
CP-9 — titled Information System Backup — requires organizations to conduct backups of user-level information, system-level information, and system documentation in a manner consistent with their recovery time and recovery point objectives. The control is deceptively simple at the base level; the implementation details and enhancements are where most programs either build real resilience or accumulate findings.
At its core, the base control establishes three requirements every covered system must address:
- User-level information must be backed up at an organizationally defined frequency — typically tied to the RPO in the contingency plan.
- System-level information — including OS configurations, software images, and operational state — must be backed up at a defined frequency. Many teams cover user data and neglect system-level configuration artifacts, which are equally essential to a full recovery.
- System documentation, including security-relevant documentation, must be backed up at a defined frequency. This is consistently underaddressed in SSP implementations.
The frequency and scope of those backups must be determined based on the system’s impact level and the RPO defined under CP-2. A system with a tight RPO requires more frequent backups. A High-impact system tolerates less data loss than a Low-impact one — and that difference should be reflected explicitly in both the SSP parameter values and the technical implementation.
The enhancements to CP-9 address failure modes the base control does not cover: backup integrity testing, restoration validation, physical separation, cryptographic protection, and dual authorization for deletion. Each enhancement targets a specific gap that organizations have discovered the hard way — through incidents or through assessment findings.
Applicable enhancements must be confirmed by reviewing the system’s baseline, agency overlays, and AO expectations. Baseline tables provide a starting point — they do not define the complete requirement set for any specific authorization context.
CP-9 Control and Enhancement Table
| Control | Title | What It Requires | Baseline |
|---|---|---|---|
| CP-9 | Information System Backup | Conduct backups of user-level information, system-level information, and system documentation at organizationally defined frequencies consistent with recovery objectives. | L, M, H |
| CP-9(1) | Testing for Reliability and Integrity | Test backup information to verify media reliability and data integrity at a defined frequency. Job completion logs alone do not satisfy this enhancement. | M, H |
| CP-9(2) | Test Restoration Using Sampling | Use a sample of backup information to exercise actual restoration procedures at a defined frequency. Results must be documented and retained as assessment evidence. | H |
| CP-9(3) | Separate Storage for Critical Information | Store backup copies of the OS and critical software in a separate facility or fire-rated container, distinct from the primary system location. | H |
| CP-9(5) | Transfer to Alternate Storage Site | Transfer backup information to the alternate storage site at a rate and frequency consistent with recovery objectives and the contingency plan’s alternate site strategy. | M, H |
| CP-9(7) | Dual Authorization | Enforce dual authorization for deletion or destruction of backup information. Directly addresses insider threat scenarios and privileged account compromise targeting backup repositories. | Selected |
| CP-9(8) | Cryptographic Protection | Implement cryptographic mechanisms — FIPS 140-validated where required — to prevent unauthorized disclosure or modification of backup information in transit and at rest. | Selected |
L = Low, M = Moderate, H = High. “Selected” enhancements are applied based on system categorization, mission requirements, overlay guidance, or AO direction. Always validate against your specific authorization package and applicable agency overlays — baseline tables are a starting point, not the complete requirement.
Federal and DoD Interpretation
NIST SP 800-53 establishes the foundational framework, but federal agencies and DoD components are not operating in a uniform environment. How CP-9 is scoped, implemented, and assessed varies meaningfully across authorization contexts — and treating the baseline table as the complete picture is one of the more common mistakes teams make when building SSP documentation. The sections below provide general orientation; organizations must validate specifics against their own guidance and AO expectations.
Civilian Federal Agencies (FISMA)
Under FISMA, agencies implement CP-9 according to their FIPS 199 system categorization. The applicable baseline — Low, Moderate, or High — drives which enhancements are required. Agency-defined parameter values in the SSP fill in backup frequency and scope. Independent assessors evaluate whether the documented approach is actually implemented and supported by current, verifiable evidence — not whether the SSP language sounds adequate. Organizations that have parameters in the SSP but no supporting logs, test records, or procedures typically receive findings regardless of how well the documentation reads.
DoD (RMF for DoD IT)
DoD programs operating under the RMF apply NIST 800-53 alongside DISA STIGs for specific platforms and Mission Owner guidance on Mission Impact Levels. CP-9 requirements in DoD environments may be more prescriptive than the civilian baseline — backup windows, media handling expectations, encryption standards, and testing cadences can vary significantly by program and Mission Owner. Teams should not assume NIST baseline guidance captures the full requirement set. ISSMs and ISSOs should confirm applicable requirements directly with their Mission Owner before finalizing SSP parameter values.
FedRAMP Cloud Environments
In cloud and FedRAMP environments, CP-9 implementation is divided between the CSP — which owns infrastructure-level backup — and the federal customer, which owns application and data-level backup within its authorization boundary. This shared responsibility must be explicitly documented in the SSP and Customer Responsibility Matrix. Agencies that assume the CSP’s native backup capabilities fully satisfy their CP-9 obligations without reviewing shared responsibility documentation are carrying an undocumented gap that will surface during assessment. The CSP’s FedRAMP authorization covers what the CSP controls — not what the agency controls within its boundary.
What CP-9 Looks Like in Practice
CP-9 is not satisfied by confirming that a backup tool is installed or that scheduled jobs are running without errors. Assessors look for a complete, operational backup program — one that can be traced from documented policy and SSP parameters through technical implementation to test results. Any break in that chain is a finding.
In practice, a defensible CP-9 implementation includes:
- Defined backup schedules — documented frequency for user data, system-level information, and documentation, explicitly aligned with the RPO in CP-2. Parameters left vague in the SSP create audit exposure.
- Confirmed scope — evidence that all in-scope components are covered: servers, databases, configuration artifacts, security-relevant documentation, and any system-level state required for full recovery. Gaps in scope are among the most common CP-9 findings.
- Integrity verification — logs or reports demonstrating that backup data integrity was validated, not just that the job completed without error codes. CP-9(1) requires this distinction.
- Off-site or alternate storage — documented evidence that backups are transferred to a location separate from the primary system, consistent with CP-9(5) and the contingency plan’s alternate site strategy. Backup-to-backup-server on the same network segment does not satisfy this.
- Restoration testing — documented results of actual restoration exercises conducted on a defined schedule. Job completion reports are not restoration tests. Assessors know the difference.
- Protection of backup media — encryption in transit and at rest using FIPS 140-validated mechanisms where required, with access controls and media handling procedures appropriate to the system’s classification level.
When any of these elements are absent, undocumented, or present only in SSP language without supporting evidence, assessors will typically identify a finding. In programs where CP-9 deficiencies are significant or systemic, the impact on authorization posture can be substantial — particularly for High-impact systems where contingency planning is a priority area.
Four Implementation Approaches
01 — Immutable Backups
Immutable Backup Architecture
Immutable backups are write-once copies that cannot be modified, overwritten, or deleted once created — including by accounts with elevated privileges. This capability directly addresses the ransomware scenario where an adversary with backup administrator access attempts to destroy recovery options before detonating the primary payload.
CP-9(7) (Dual Authorization) and CP-9(8) (Cryptographic Protection) together support the architectural case for immutability. Organizations should evaluate whether their current backup platform enforces immutability at the storage level — not just through access control policy — and document the capability explicitly in the SSP. Platform claims of immutability should be verified through testing, not assumed.
02 — Air-Gapped Recovery
Air-Gapped and Isolated Recovery Environments
An air-gapped backup is physically or logically isolated from the primary network, reachable only through a controlled, manual process. This limits the reach of a network-based attack by ensuring backup copies cannot be accessed through the same vector as production systems — even when management plane credentials are compromised.
CP-9(3) and CP-9(5) both point toward this architecture. For High-impact DoD systems and mission-critical federal environments, isolated recovery environments are increasingly expected in resilient system designs, not treated as optional enhancements. The isolation must be verified periodically — configuration drift and infrastructure changes can erode separation over time without anyone noticing.
03 — Testing & Validation
Backup Testing and Restoration Validation
The most common CP-9 gap is not that backups are absent — it is that they have never been tested under conditions that resemble a real recovery scenario. CP-9(1) requires integrity testing. CP-9(2) requires exercising actual restoration procedures using sample backup data. Both require documented results that an assessor can review.
An effective testing program defines what is being restored, how success is determined, who conducts the test, and what records are produced. Annual testing is a common minimum; Moderate and High systems with tight RTOs typically warrant more frequent validation of critical components. Test results belong in the authorization package as continuous monitoring evidence — they should be reviewed by ISSOs and ISSMs, not filed and forgotten.
04 — Retention Strategy
Backup Retention and Lifecycle Management
Retention periods must be consistent with the contingency plan, applicable records management requirements, and the system’s data classification obligations. What is retained and for how long must be defined explicitly — vague retention language in the SSP does not satisfy assessors and does not translate into operational procedures teams can actually follow.
Retention must also be operationally bounded. Indefinitely retained backup data without lifecycle management creates storage overhead, classification risk, and audit complexity. Organizations should document retention schedules in the SSP with specific values, enforce them through technical controls rather than manual procedures, and confirm that retention periods are sufficient to support the RPO across all relevant recovery scenarios — including those involving extended adversarial dwell time.
Common CP-9 Mistakes
Recommended Approach for Federal Organizations
Building a defensible CP-9 posture does not require a complex program — it requires a deliberate one. The steps below provide a practical starting point for ISSOs, ISSMs, system owners, and infrastructure teams. Adapt this framework to the specific authorization context, applicable baselines, and AO guidance for your environment. What matters is that the resulting program produces consistent, verifiable evidence — not just well-written SSP language.
Define scope and frequency explicitly in the SSP
Enumerate every in-scope component requiring backup — servers, databases, configuration artifacts, security documentation, and system-level state. Document backup type (full, incremental, differential), frequency with specific values, and retention period. Align frequency directly with the RPO defined in CP-2. SSP parameters that use vague language or reference undefined organizational values create audit exposure and are difficult to defend during assessments.
Establish off-site or alternate storage with documented transfer procedures
Ensure backups are transferred to a location logically or physically separate from the primary system. Document transfer frequency, the alternate site designation, and access controls in the SSP — consistent with CP-9(5) and the contingency plan’s alternate site strategy. Periodic verification that the transfer is actually occurring at the documented frequency, and that the alternate copy is accessible and intact, should be part of routine operational checks.
Protect backup data with encryption and access controls
Backup data should be encrypted in transit and at rest using FIPS 140-validated mechanisms where required. Confirm that the backup platform supports this natively rather than relying on transport-level encryption alone. Document the cryptographic approach in the SSP, evaluate CP-9(8) applicability against your baseline and AO guidance, and ensure backup management credentials are protected separately from production administrative accounts — not shared across the same credential store.
Build and execute a documented restoration testing program
Create a written test plan specifying what will be restored, how success is defined, who conducts the test, and how results will be documented and retained. Execute on a defined schedule — not just when assessments are approaching. Retain results as evidence in the authorization package. Align the testing program with CP-9(1) and CP-9(2) as applicable, and treat test failures or RTO exceedances as findings that require POA&M entries, not informal corrections.
Integrate CP-9 with the broader contingency and incident response framework
Backup procedures should not be isolated documentation. Assessors cross-reference CP-2 (Contingency Plan), CP-9 (Information System Backup), CP-10 (System Recovery and Reconstitution), and IR controls — and gaps between them are consistently cited. Verify that RPO values are consistent between CP-2 and CP-9 parameters, that recovery procedures reference actual backup capabilities, and that the incident response plan addresses how backup and recovery operations are coordinated during an active incident.
Maintain continuous, reviewable evidence — not point-in-time snapshots
Backup logs, integrity verification reports, and restoration test results should be retained continuously and accessible for ongoing monitoring review — not assembled on demand before an assessment. A single screenshot from a recent job is not evidence of an ongoing program. Build evidence collection into routine operations from the start, so that when an assessor asks for CP-9 evidence, the answer is a maintained record set, not a reconstruction effort.
Need help evaluating solutions for your environment?
Whether you’re modernizing infrastructure, improving cyber resilience, or evaluating technologies, Anchor Defense helps organizations align mission requirements with practical outcomes.