PR.DS-11 asks four things of your backups: they exist, they are protected, they are maintained, and they are tested. The last one is where most companies fall short. A backup you have never restored is a hope, not a control.
CSF is voluntary guidance. There is no CSF certification, and the way to meet this outcome is to be able to show a recent, successful restore.
What good looks like
Critical data is backed up continuously or close to it, and other data on an agreed schedule. Each backup system has an owner and defined recovery goals. At least some copies are offline and offsite, so a ransomware event or a disaster in one place cannot reach them. Backup storage is in a different location from the original, with geographic separation and any location limits your obligations require.
Restores are tested for every type of data source at least once a year. Failures get fixed and retested.
How to implement it
- List the data that matters and rank it by how long the business can live without it.
- Set a backup frequency for each tier. Critical systems get continuous or near real time backup, the rest daily or weekly.
- Keep at least one copy offline or immutable, and one offsite. Separate the credentials that manage backups from everyday admin accounts.
- Encrypt backups and restrict who can delete them.
- Schedule restore tests. Pick one source each quarter so that all types are covered within the year, and time each restore against your recovery goal.
- Alert on failed jobs and review the alerts weekly.
- Record each test and each fix.
Evidence to collect
- A backup inventory showing systems, frequency, retention and location
- Job success reports for the last quarter
- Restore test records with date, data source, time taken and result
- Configuration showing encryption, immutability or offline copies
- Access list for who can delete or alter backups
- Tickets showing failures that were fixed
Collecting these by hand each audit cycle is slow. This demo shows how evidence collection can be automated.
Click through it at your own pace, or open it full screen.
Common gaps
- Jobs succeed but nobody has ever restored from them
- Backups live in the same account as production, so one compromised admin deletes both
- Only databases are backed up, and SaaS data, configuration and source code are forgotten
- The restore takes three days and the business expected three hours
- Backup tests are run once and never repeated after architecture changes
Quick check
How often should we test restores?
NIST's example says at least annually for all types of data sources. Critical systems deserve more frequent tests, and any major change is a good trigger.
Does cloud replication count as a backup?
Usually not on its own. Replication copies deletions and corruption as fast as it copies good data. You need point in time copies that cannot be altered by the same accounts that run production.
Sources
- NIST Cybersecurity Framework 2.0 (CSWP 29): https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST CSF 2.0 Reference Tool, implementation examples for PR.DS-11: https://csrc.nist.gov/projects/cybersecurity-framework/filters
