RC.RP-03 says the integrity of backups and other restoration assets is verified before using them for restoration. Before you restore anything, you check that the backup is intact, that it is not itself corrupted, and that it does not carry the thing you are recovering from.
Restoring a poisoned backup puts the attacker straight back in. Restoring a corrupted one wastes hours at the worst moment.
What good looks like
Backups are protected from tampering, with copies the production environment cannot overwrite or delete, such as offline, immutable or separately credentialed storage. Each backup has recorded integrity information, for example checksums. Before use, responders check restoration assets for indicators of compromise, file corruption and other integrity problems. Restoration assets include more than data: golden images, infrastructure code, container images, build artifacts, configuration, and the installers and packages used to rebuild systems.
You know which restore point predates the compromise, and you can explain how you know.
How to implement it
- Inventory restoration assets for each critical service: data backups, machine images, infrastructure code repositories, container registries, secrets recovery material, and documentation.
- Protect them. Use separate credentials, immutability or write once settings where your platform supports it, and offsite or offline copies.
- Record checksums or signatures at backup time and verify them before restore.
- Test restores on a schedule into an isolated environment. Time them and record the result.
- Scan restored data and images in the isolated environment for malware and indicators of compromise before they touch production.
- Establish the earliest known compromise time from logs, then choose a restore point before it. If unsure, restore the oldest usable point and replay data in a controlled way.
- For software assets, verify that dependencies and base images used in rebuilds are known and scanned. A rebuild that pulls an unpinned vulnerable package defeats the purpose.
- Document the verification steps in the recovery plan so they are done under pressure.
Evidence to collect
- Backup architecture showing separation and immutability.
- Restore test records with dates, sizes, durations and results.
- Checksum or signature verification logs.
- Scan results for restored assets in an isolated environment.
- Incident records where a restore point was chosen, with reasoning.
CSF has no certification. A restore test log with dates is the kind of evidence that tells a customer your backups actually work.
A worked example
A small software company is hit by ransomware that encrypts its file server and several build machines. Logs suggest the attacker first logged in nine days ago. The team has nightly backups for thirty days in separate storage that production credentials cannot reach.
The recovery lead chooses a restore point twelve days back, three days before the earliest evidence, and mounts it in an isolated network. Checksums recorded at backup time match. A malware scan finds nothing, and a review of scheduled tasks and new accounts in the restored copy shows none that the attacker added. The team also checks the source repository history against its signed tags to confirm no commits were altered.
For the build machines, the team does not restore images. It rebuilds from the infrastructure code, which it verified against the repository's tags, and installs dependencies from pinned versions that were scanned before use. Only after these checks do the restored data and rebuilt systems move toward production under the go live check in RC.RP-05.
The team notes the choice and the evidence in the incident record. If a customer asks later how the company knew its backups were clean, there is a straight answer.
How to start this week
- Pick one critical system and restore it into an isolated environment. Record the time and any surprises.
- Check whether your production credentials can delete your backups. If they can, add a copy they cannot touch.
- Turn on checksum recording or backup verification in your backup tool, if it is not on.
- List your restoration assets beyond data: images, infrastructure code, secrets recovery material.
- Write the restore point selection steps into the recovery plan.
Questions auditors and customers ask
- When did you last restore from backup, and how long did it take? Show the test log.
- Could ransomware delete your backups? Show the separation design.
- How do you know a restore is clean? Show the verification steps and a sample result.
Common gaps
- Backups exist but have never been restored.
- Production credentials can delete the backups, so ransomware deletes them first.
- Only data is backed up, and infrastructure code, images and secrets are not.
- No integrity record, so corruption is found at restore time.
- The restore point is picked by guess because the compromise time is unknown.
- Restored systems go straight to production with no scan.
Quick check
What counts as a restoration asset?
Anything you need to rebuild service: data backups, system and container images, infrastructure code, configuration, installers, packages, and the keys and secrets needed to use them.
Why test restores in isolation?
If the backup contains the threat, an isolated test shows it without exposing production. It also tells you how long recovery really takes.
How do you pick a safe restore point?
Work out the earliest evidence of compromise from logs and telemetry, then choose a point before it. Document the reasoning in the incident record.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST CSF 2.0 implementation examples for RC.RP-03, as listed in the CSF 2.0 Reference Tool: https://www.nist.gov/cyberframework
CSF is voluntary guidance. There is no CSF certification, so use it to organize and show your own work.
