CP-9: System Backup

Quick-reference card

NIST SP 800-53 Revision 5 Contingency Planning LOW MODERATE HIGH

What this control requires

CP-09 requires organizations to back up user data, system software, and documentation at defined intervals and protect those backups from compromise. The control covers three distinct categories of information: user-level data (business records, application data, user files), system-level information (operating system images, middleware, application binaries, license files), and security and privacy documentation. Each category must follow a backup schedule aligned to the organization’s contingency plan.

Specifically, the core problem CP-09 addresses is survivability. Without verified, protected backups, any disruptive event (ransomware, hardware failure, insider sabotage) becomes a permanent data loss event rather than a recoverable one. The control doesn’t just mandate that backups happen; it requires that backup information itself be treated as a protected asset. That means encryption at rest and in transit, integrity verification through cryptographic hashes or digital signatures, and access controls that prevent attackers who compromise primary systems from reaching backup repositories.

In practice, this means sector-specific regulations add further requirements on top of CP-09’s baseline. Organizations handling health data (HIPAA), education records (FERPA), or criminal justice information (CJIS) should confirm that their backup practices also satisfy any additional retention, encryption, or handling rules imposed by those frameworks.

Why it matters

Backup failures don’t announce themselves during normal operations. They surface at the worst possible moment, when the organization is already under attack or recovering from a disaster and the backups it assumed were intact turn out to be missing, corrupted, or inaccessible. The gap between “we run backups” and “we can actually recover from backups” is where CP-09 failures cause the most damage.

City of Atlanta SamSam ransomware (2018)

On March 22, 2018, the SamSam ransomware encrypted systems across the City of Atlanta’s municipal government. The DOJ attributed the attack to Iranian nationals Faramarz Shahi Savandi and Mohammad Mehdi Shah Mansouri, who demanded $51,000 in bitcoin. Atlanta refused to pay.

The consequence of that refusal exposed the backup gap. SamSam’s operators had specifically targeted and deleted Veeam backup repositories before triggering encryption, eliminating the recovery path for significant portions of the affected systems. The City Attorney’s office permanently lost ten years of documents and all but six of its 77 computers. The Atlanta Police Department permanently lost all stored dashcam recordings. Emergency consulting and IT contracts cost approximately $17 million in total recovery expenses, 333 times the ransom demand.

Specifically, backup infrastructure sat on the same domain as production systems, accessible to the same credentials the attackers had compromised. A city auditor’s report issued just two months before the attack had flagged nearly 100 servers running unsupported Windows versions and identified significant security vulnerabilities, indicating that backup and business continuity practices were not part of a functioning security program. The DOJ indicted the two Iranian nationals in November 2018.

What attackers exploit

• Backup repositories on the same network segment or domain — attackers with domain-level access delete or encrypt backups before detonating ransomware
• Lack of immutable or air-gapped backup copies — if every backup can be modified by an administrator account, every backup can be destroyed by an attacker using that account
• No backup integrity verification — corrupted or incomplete backups discovered only during a restoration attempt, when it’s too late
• Missing backup coverage for system-level information — organizations back up databases but skip OS images, middleware configurations, and application binaries, extending recovery timelines from hours to weeks
• Unencrypted backup media — backup tapes or cloud storage containing sensitive data become a data breach vector when physically stolen or misconfigured

How to implement

The most common CP-09 failure isn’t skipping backups entirely. It’s treating backup as an infrastructure task that runs automatically and never testing whether recovery actually works. Organizations discover the gap when an incident response plan requires a restore and the backup either doesn’t exist, can’t be decrypted, or restores to an unusable state.

For your organization

1. Define backup scope and frequency. Map every system component that contains user-level data, system-level information, or security/privacy documentation. Assign backup frequencies based on recovery point objectives (RPOs) from your contingency plan. User data in transactional systems may need daily or continuous backup; system documentation may need weekly snapshots.

2. Separate backup infrastructure from production. Store backup copies in a location that cannot be reached through the same credentials or network paths as production systems. Use immutable storage (write-once, read-many), air-gapped media, or cloud-based backup services with separate authentication. The Atlanta breach proved that on-domain backup repositories provide no protection against domain-level compromise.

3. Encrypt and verify integrity. Apply encryption to backup data at rest and in transit. Use cryptographic hashes or digital signatures to verify that backup files haven’t been modified. Automated integrity checks should run after every backup job completes.

4. Test restoration regularly. Conduct periodic restore tests using actual backup data, not just verifying that backup jobs completed without errors. Include system-level restores (OS, middleware, application binaries) in addition to data restores. Document results and remediate any failures.

5. Protect backup documentation. The backup procedures themselves (schedules, encryption keys, storage locations, access credentials) must be backed up and stored separately from the systems they protect.

Common mistakes:

• Running backup verification only at the job level (checking that the job completed) without ever performing a test restore
• Storing backup encryption keys on the same systems being backed up
• Excluding system-state information from backup scope, leaving only data backups
• Maintaining a single backup copy with no geographic or logical separation from production

For your vendors

What to ask in a security questionnaire:

• What categories of information are included in your backup scope (user data, system images, documentation)?
• Where are backup copies stored, and are they logically and/or physically separated from production systems?
• Do you use immutable or append-only storage for any backup tier?
• How frequently do you test backup restoration, and can you provide recent test results?
• Are backups encrypted at rest and in transit? Who controls the encryption keys?

What evidence to request:

• Backup policy and procedures document
• Most recent backup restoration test report with scope and results
• Architecture diagram showing backup storage separation from production
• Encryption standards applied to backup media

Red flags:

• Vendor cannot produce a backup restoration test report from the last 12 months
• Backup storage resides on the same cloud account or network as production with shared credentials
• No encryption applied to backup media or encryption keys stored alongside backups
• Backup scope excludes system-level information (only databases are backed up)

How to verify beyond self-attestation: Request evidence of a recent tabletop or live restoration exercise. Ask for the scope of the test. A vendor that only restores a single database table hasn’t demonstrated full system recovery capability. If the vendor operates in a shared responsibility model (IaaS/PaaS), confirm whether backup responsibilities fall to the vendor or to your organization.

Evidence examples

Cross-framework mapping

Related controls

• CP-02 — Contingency Plan: Defines the recovery objectives and requirements that drive backup scope and frequency under CP-09.
• CP-06 — Alternate Storage Site: Specifies where offsite backup copies are stored, directly supporting CP-09’s availability requirement.
• CP-10 — System Recovery and Reconstitution: Depends on CP-09 backups as the input for restoring systems to a known operational state after a disruption.
• MP-04 — Media Storage: Governs physical and environmental protections for backup media in storage.
• MP-05 — Media Transport: Addresses confidentiality and integrity protections for backup media during transport between locations.
• SC-08 — Transmission Confidentiality and Integrity: Protects backup data during electronic transfer to alternate storage sites or cloud repositories.
• SC-12 — Cryptographic Key Establishment and Management: Governs the lifecycle of encryption keys used to protect backup information.
• SC-13 — Cryptographic Protection: Specifies the cryptographic algorithms and implementations used to encrypt and verify backup data.
• SI-04 — System Monitoring: Detects unauthorized access to or modification of backup repositories, providing early warning of backup compromise.
• SI-13 — Predictable Failure Prevention: Identifies storage media degradation or system failures that could affect backup reliability before data loss occurs.

Frequently asked questions

What is NIST SP 800-53 CP-09

CP-09 is the NIST SP 800-53 control that requires organizations to conduct regular backups of user-level data, system-level information, and system documentation, and to protect those backups against unauthorized disclosure, modification, and loss. It applies across LOW, MODERATE, and HIGH baselines, making it one of the foundational controls in the Contingency Planning family. The control explicitly separates backup into three categories: user data (business records, application content), system data (OS images, middleware, application binaries, licenses), and documentation (including security and privacy plans). Each category has different recovery implications and may require different backup frequencies.

What happens if CP-09 is not implemented

Without CP-09 controls in place, any disruptive event (ransomware, hardware failure, natural disaster, or insider action) can cause permanent data loss. The City of Atlanta’s 2018 experience demonstrates the worst case: attackers destroyed backup repositories before encrypting production systems, resulting in the permanent loss of ten years of legal documents and all police dashcam footage, with recovery costs reaching $17 million. Even outside of adversarial scenarios, organizations without verified backups face extended outages because they cannot restore system-level information (operating system configurations, middleware, application binaries) and must rebuild from scratch rather than restore from images.

How do you audit CP-09

Auditors assess CP-09 by examining the backup policy and procedures for completeness (all three information categories covered), reviewing backup job logs for adherence to defined schedules, and verifying that restoration tests have been conducted and documented. They check whether backup storage is separated from production systems, whether encryption is applied to backup data at rest and in transit, and whether integrity verification mechanisms (cryptographic hashes, digital signatures) are in use. Auditors also interview personnel responsible for backup operations and contingency planning to confirm that backup practices align with the contingency plan’s recovery point and recovery time objectives.

What is the difference between CP-09 and CP-10

CP-09 governs the creation and protection of backup information, making sure recoverable copies of data, system images, and documentation exist and are intact. CP-10 governs what happens after a disruption, covering the process of using those backups and other mechanisms to restore the system to a known, operational state. In practice, CP-09 ensures you have something to recover from, while CP-10 ensures you have a tested process to recover with. A failure in CP-09 (no usable backups) makes CP-10 impossible to execute, which is why the two controls are tightly coupled in every contingency plan.