Backup policy checklist: what to back up and how to test restores

A backup policy should say what is backed up, how often, where copies live, who can delete them, whether they are encrypted, and how often restores are tested. The restore test is the part most teams skip, and it is the only proof a backup works.

What CP-9 covers

NIST SP 800-53 CP-9 asks for backups of user-level data, system-level data (system state, operating systems, middleware, applications, licences) and system documentation, including security and privacy documents, at defined intervals, and for keeping backup data confidential, intact and accessible.

Checklist: scope

• Customer and production data, databases, object storage.
• Configuration and infrastructure code, so you can rebuild.
• Identity provider configuration and recovery codes, kept safely.
• Secrets and keys, through a method that does not put them in plain text.
• Source code and CI definitions.
• Business documents and the continuity and incident plans themselves.

If a SaaS vendor holds the data, find out what the vendor backs up and for how long. Do not assume.

Checklist: frequency

Match frequency to your recovery point objective: the maximum data loss you accept. If you can lose an hour of orders, hourly backups or continuous replication are needed. Write one RPO per data set.

Checklist: protection

1. Encrypt. CP-9(8) describes encryption of designated backups to prevent disclosure or change.
2. Separate. CP-9(3) describes keeping copies of critical software and security information apart from the operational system. In cloud terms, use a separate account or region with separate credentials.
3. Limit deletion. CP-9(7) describes requiring two authorised people to approve deletion of designated backup data. Ransomware often targets backups first, so immutable or delayed-delete storage helps.
4. Limit access. Few people, logged.

Checklist: testing

CP-9(1) describes periodic testing to confirm the media works and data is uncorrupted. CP-9(2) describes restoring a sample during contingency plan tests to confirm functions can be recovered.

A restore test that counts:

1. Pick a backup at random, not the newest.
2. Restore to a clean environment, not over production.
3. Check data integrity and that the application starts.
4. Time it and compare to your recovery time objective.
5. Record who ran it, the date, the result and the issues.

Do this at least twice a year for critical data, and after any change to the backup system.

Retention

Decide how long to keep backups, balancing recovery needs, cost, and legal limits on holding personal data. Deleted-on-request data may persist in backups for a time, so write down your policy and tell people how it works. Ask counsel for the specifics in your jurisdictions.

Alerting

Alert on failed or missing backups. A silent failure for three months is the typical story.

For the wider plan see what goes in a business continuity plan.

Safeguard's compliance and evidence automation can store restore test records as evidence. A free scan is at gold.safeguard.sh/scan.

Quick check

Sources

• CP-9 System Backup, NIST SP 800-53 Rev. 5

Last reviewed: 19 October 2026.