SC-28 Protection of Information at Rest asks you to protect chosen properties of chosen information at rest, such as confidentiality and integrity. You select the properties and the information.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog you borrow from, so check which parts your customer or auditor actually expects.
The guidance defines information at rest as information not in process or in transit, located on system components such as hard drives, storage area networks and databases. The focus is the state of the information, not the type of device or how often it is accessed. It covers user information and system information. Examples of system information to protect include configurations or rule sets for firewalls, intrusion detection and prevention systems and filtering routers, and authentication information. Mechanisms include cryptography and file share scanning. Integrity protection can use write once read many technologies. When adequate protection cannot be achieved otherwise, the guidance mentions frequent scanning for malicious code at rest and secure offline storage in place of online storage.
What it means in practice
Wherever data is stored, ask who could read or change it if they got hold of the storage itself: a stolen laptop, a copied snapshot, a misconfigured bucket, a former administrator with a backup. Encryption at rest is the usual answer for confidentiality. Integrity needs different tools such as checksums, versioning and immutable storage.
Three enhancements apply. SC-28.1 is cryptographic protection. SC-28.2 is offline storage. SC-28.3 is cryptographic keys, which asks you to manage the keys used for protection at rest.
Encrypting data and leaving the key next to it gives little protection. Keys deserve as much attention as the data.
Evidence to collect
- A data inventory showing where sensitive data is stored.
- Encryption settings for each store: database, object storage, volumes, backups, laptops and mobile devices.
- Key management configuration: where keys live, who can use them, rotation schedule and logging of use.
- Disk encryption reports from device management for laptops and phones.
- Backup encryption and access control settings.
- Bucket and share policies showing public access is blocked.
- Evidence of integrity controls, such as object versioning, object lock or WORM storage for logs and backups.
- Exceptions with approval where data is not encrypted and the compensating control.
Common gaps
Encryption enabled on the main database but not on replicas, backups, exports or analytics copies. Laptops without full disk encryption. Developer machines holding production data extracts. Keys shared across environments. Key access given to broad groups. Log archives that administrators can delete. Secrets in plain text in configuration files or repositories. Third party tools storing copies of your data with no known encryption.
Teams also treat default cloud encryption as a complete answer. It protects against physical theft in the provider's facility, but if your own accounts allow broad reads, access control matters more.
How to implement it
Begin with the inventory. You cannot protect what you have not found. Note each store, the type of data and the owner.
Turn on encryption by default. Most cloud services offer it with a setting or a policy. Enforce it with guardrails so new resources start encrypted. Require full disk encryption on every endpoint through device management and report on compliance.
Use a managed key service. Create separate keys per environment and data class, restrict who can use them, enable rotation and log usage.
Protect integrity for the data that needs it. Turn on versioning and object lock for backups and audit logs. Restrict deletion rights.
Block public access at the account level. Scan for exposed buckets and shares on a schedule.
Handle exceptions. If a system cannot be encrypted, record the reason, the compensating controls and a review date.
Finally, collect evidence automatically. Configuration exports and compliance reports on a schedule produce dated proof with little effort, and the walkthrough below shows how collection can be automated across many systems.
Test recovery as well. An encrypted backup that cannot be restored because the key was lost is a failure of availability. Include key recovery in your continuity tests.
One example of how the evidence tends to go wrong. A company shows an auditor that its production database is encrypted with a customer managed key, which is correct. The auditor then asks about the nightly export to a reporting bucket, the laptop of the analyst who downloads it, and the vendor tool that copies it again. Each of those copies is information at rest, and the control applies to all of them. The company had only looked at the primary store.
A useful habit is to trace one sensitive field from creation to deletion and list every place it lands: primary database, replicas, caches, search indexes, backups, logs, analytics, exports, tickets and email. Mark each as encrypted or not, and note who can read it. The result is a one page map that answers most questions.
For keys, aim for a small number of people who can administer and a different, small set of services that can use. Log key usage and alert on unusual patterns, such as bulk decryption outside business hours.
If a store cannot be encrypted, compensate honestly. Access restriction, scanning and offline storage are the options the guidance itself mentions, and a signed exception with a review date turns a finding into a managed risk.
Try it yourself
Encryption settings change quietly over time. This demo shows how evidence collection can be automated so the proof stays current.
Click through it at your own pace, or open it full screen.
Quick check
Is default cloud encryption enough?
It is a good start and often satisfies the setting check, but also show who can read the data through access control and how keys are managed.
What about integrity at rest?
Use versioning, object lock or write once storage for data that must not be changed, as the guidance describes with WORM technologies.
