PR.DS-01 asks you to protect stored data: files, databases, virtual machine disk images, container images, laptops and backups. Protection covers three properties. Others should not read it (confidentiality), nobody should change it unnoticed (integrity), and you should be able to get at it when you need it (availability).
CSF is voluntary guidance. There is no CSF certification and no one can call you "NIST compliant" for meeting this outcome. What you can do is show a customer or auditor a clear, tested set of controls.
What good looks like
Every place data rests has a known protection. Databases and object storage are encrypted with keys you manage or at least control through your cloud provider. Laptops and phones use full disk encryption. Container images and software packages are checked by signature or hash before they run. Removable media is restricted, and where it is allowed the sensitive contents are encrypted and physically secured.
You also know where your data is. Encryption on a database nobody remembers is no help, so a basic data inventory sits behind the controls.
How to implement it
- Inventory the stores. List databases, buckets, disk volumes, backup targets, endpoints and container registries. Mark which hold sensitive data.
- Turn on encryption at rest for each store. For cloud services this is usually a setting and should be on by default in new infrastructure code.
- Enforce full disk encryption on every laptop through device management, and report on exceptions.
- Manage keys deliberately. Decide who can use, rotate and delete keys, and keep key access separate from data access.
- Verify software integrity. Validate signatures or checksums on downloaded installers and packages, and pin dependency versions with lockfiles.
- Restrict removable media. Block it by policy where you can, and lock up any sensitive media that must exist.
- Protect availability. Keep backups, and see PR.DS-11 for testing them.
Try it yourself
Software integrity starts with knowing what you ship. You can run a free, in browser dependency scan at https://gold.safeguard.sh/scan to see which packages your project pulls in and which have known vulnerabilities. It is a quick first look, and it does not replace signature checks on what you install.
Evidence to collect
- Data store inventory with encryption status for each entry
- Cloud configuration exports or policy checks showing encryption at rest is on
- Device management report showing disk encryption coverage and exceptions
- Key management policy and a sample of key rotation records
- Documented process for verifying signatures or hashes on software
- Removable media policy and enforcement settings
Common gaps
- Encryption is on for production but not for snapshots, backups or analytics copies
- Laptop encryption is a policy but nobody checks coverage
- Keys sit in the same account and role as the data they protect
- Package integrity relies on trust in the registry with no lockfile or signature checks
- Old disk images and test databases hold real data and are never cleaned up
Quick check
Is cloud provider default encryption enough?
It is a good start and often satisfies the confidentiality part for that store. You still need to cover endpoints, backups, copies and key control, and you should be able to show it on request.
What does integrity mean for data at rest?
It means you can tell if stored data or software was changed. Hashes, digital signatures and signature validation on software are the usual tools.
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-01: https://csrc.nist.gov/projects/cybersecurity-framework/filters
