Every auditor eventually asks the same thing about backups: show me one that works. CP-9 is the control behind that question. It requires backups of three kinds of information, and it requires that you protect the confidentiality, integrity and availability of the backups.
NIST 800-53 binds US federal systems and anyone contractually held to it. If you sit outside that group, treat it as a reference. Customers and auditors reach for the same ideas under different names.
What the control asks
The statement breaks into four parts:
- Back up user level information in the system, at a frequency you define.
- Back up system level information, at a frequency you define.
- Back up system documentation, including security and privacy documentation.
- Protect the confidentiality, integrity and availability of backup information.
The frequencies are left to you. NIST ties them to your contingency plan and any legal requirements for specific data, such as health information.
What it means in practice
NIST describes system level information as system state, operating system software, middleware, application software and licenses. User level information is everything else. In a modern stack that means databases and object storage, but also infrastructure code, container images, secrets managers and CI configuration. If you cannot rebuild the platform, a database dump alone will not save you.
The guidance names digital signatures and cryptographic hashes as ways to protect backup integrity. Protection in transit is handled by MP-5 and SC-8, so expect those to come up in the same conversation.
Evidence to collect
- Backup policy or schedule per system, with the frequency and retention you chose.
- Job logs showing recent successful runs and alerts on failures.
- A restore test record: what was restored, from which date, how long it took, who verified it.
- Proof of protection: encryption settings, access lists on the backup store, hash or signature checks, and immutability or versioning settings.
- The location of the documentation backup, including runbooks and security policies.
Automating the collection matters here, because backup evidence ages fast. A screenshot from March says nothing about October.
Click through it at your own pace, or open it full screen.
Common gaps
Backups that run but have never been restored. Backups stored in the same account and with the same admin credentials as production, so one compromise reaches both. Documentation left out entirely. And retention set by default rather than by decision.
Several enhancements cover these. CP-9.1 Testing for Reliability and Integrity and CP-9.2 Test Restoration Using Sampling are about proving restores work. CP-9.3 Separate Storage for Critical Information and CP-9.5 Transfer to Alternate Storage Site address location. CP-9.7 Dual Authorization for Deletion or Destruction and CP-9.8 Cryptographic Protection address tampering and theft.
How to implement it
Start with an inventory of what the system needs to be rebuilt, not only what holds customer data. Set a frequency per class of data from the recovery point you can tolerate. Store copies in a separate account or region with separate credentials. Turn on encryption and versioning or object lock. Schedule a restore test each quarter on a sample, and keep the result as a ticket.
Quick check
Which three kinds of information does CP-9 require you to back up?
User level information, system level information, and system documentation including security and privacy documentation.
What is the best single piece of evidence for CP-9?
A dated restore test with the outcome and the person who verified it. Job logs show backups ran. A restore shows they work.
