SC-28: Protection of Information at Rest

Quick-reference card

What this control requires

SC-28 requires organizations to protect the confidentiality and integrity of information stored on system components using cryptographic mechanisms or equivalent safeguards. That protection applies to every location where data comes to rest, from internal hard drives and storage area networks to databases and backup media. The control doesn’t distinguish by storage type or access frequency. What matters is the state of the data: if it isn’t actively being processed or transmitted, SC-28 applies.

The scope extends beyond user data. System-related information that requires protection includes firewall configurations, intrusion detection and prevention system rule sets, filtering router configurations, and authentication credentials. Organizations can choose among several mechanisms to meet this requirement, including encryption, file share scanning, and write-once-read-many (WORM) technologies for integrity protection.

Where cryptographic protections aren’t feasible, you can apply compensating controls such as frequent malware scanning of stored data or moving sensitive information to secure offline storage. The key point is that SC-28 demands an affirmative, documented decision about how each category of information at rest is protected. Leaving data unprotected by default, then hoping no one accesses it, doesn’t satisfy the control.

Why it matters

Unprotected data at rest is one of the highest-yield targets in any compromise. Once an attacker gains access to a system, stored data that lacks encryption or integrity controls can be exfiltrated, modified, or weaponized without triggering additional defenses. The control exists because perimeter defenses alone don’t protect data after an adversary is inside.

The risk isn’t theoretical. Stolen laptops, decommissioned drives, misconfigured storage buckets, and compromised backup systems all expose data at rest. In each scenario, the presence or absence of SC-28 protections determines whether an incident becomes a reportable breach.

U.S. HealthWorks encrypted laptop with password stored on-device

In July 2016, a laptop issued to a U.S. HealthWorks employee was stolen. Unlike the company’s 2015 laptop incident, where the device was unencrypted, this laptop had full disk encryption enabled. The company nonetheless filed a HIPAA breach notification affecting approximately 1,400 patients because the decryption password had been stored with the device.

This incident is a more instructive SC-28 failure than a straightforward unencrypted device case precisely because it shows that encryption alone doesn’t satisfy the control. SC-28 requires that information at rest be protected using cryptographic mechanisms, but that protection is only meaningful if the cryptographic keys are managed separately from the data they protect. Storing a decryption password on or with an encrypted device negates the encryption entirely.

U.S. HealthWorks committed to audits to ensure compliance with its laptop encryption policy following the 2015 incident. The 2016 recurrence, technically compliant with an “encryption required” policy but not with sound key management practice, illustrates that SC-28 compliance requires both implementation and operational discipline around key handling. You can check every box on an encryption policy and still fail SC-28 if key management doesn’t receive equal rigor.

What attackers exploit

• Unencrypted storage media. Stolen or decommissioned devices without full disk encryption expose all stored data, including credentials, configurations, and personally identifiable information.
• Keys stored alongside encrypted data. Encryption that can be bypassed because the decryption key, password, or certificate is stored on the same device or in the same directory as the protected data.
• Misconfigured cloud storage. Object storage buckets or database snapshots left with default access controls, allowing unauthorized parties to read or download data at rest without authentication.
• Unprotected backup media. Backup tapes, disk images, or cloud-based snapshots that lack encryption, giving attackers access to historical data sets even after production systems are hardened.
• Integrity gaps in stored configurations. Firewall rule sets, router configurations, and authentication databases modified without detection because no integrity verification mechanism (checksums, digital signatures, WORM storage) is in place.

How to implement

The most common SC-28 failure isn’t the absence of encryption technology. It’s the gap between encryption policy and encryption practice, where organizations deploy cryptographic tools but fail to enforce consistent key management, coverage validation, or evidence collection across all storage locations.

For your organization

Start by building a complete inventory of where information comes to rest. This inventory should cover endpoints (laptops, workstations, mobile devices), servers, databases, network-attached storage, removable media, and cloud storage services. Map each storage location to the data classification of what it holds.

Deploy full disk encryption on all endpoints and servers using validated cryptographic modules. For Windows environments, BitLocker with TPM-backed key storage is standard. For Linux systems, LUKS provides equivalent protection. Confirm that encryption is active, not just installed, by collecting enforcement evidence from your endpoint management platform.

Protect databases and cloud storage at the application layer. Enable transparent data encryption (TDE) for relational databases. For cloud object storage, enforce server-side encryption with customer-managed keys through your cloud provider’s key management service. Configure bucket policies to deny unencrypted uploads.

Implement a centralized key management strategy that separates keys from the data they protect. Use a dedicated hardware security module (HSM) or cloud-based key management service. Rotate keys on a defined schedule and revoke keys promptly when personnel with access leave the organization. Document your key lifecycle procedures as part of your system and communications protection policy.

Address integrity protections alongside confidentiality. Deploy file integrity monitoring on critical system configurations, including firewall rule sets and authentication databases. For records that must remain unaltered, consider WORM storage or cryptographic hash verification.

Common mistakes include encrypting production databases but leaving backup copies unprotected, relying on vendor-default encryption settings without verifying algorithm strength, and failing to test recovery procedures after encrypting storage volumes.

For your vendors

When assessing a vendor’s SC-28 posture, your questionnaire should include these questions.

• What encryption standards and algorithms do you use for data at rest (for example, AES-256)?
• How are encryption keys managed, stored, and rotated? Are keys stored separately from the encrypted data?
• Do you encrypt all backup media and database snapshots, or only production environments?
• What integrity controls protect system configurations and stored credentials?
• Can you provide third-party audit evidence (SOC 2 Type II, ISO 27001 certificate) confirming encryption at rest is implemented?

Request specific evidence rather than attestation alone. Look for screenshots of encryption configuration dashboards, key management policy documents, and independent audit reports that reference encryption at rest controls. Verify that the vendor’s NIST SP 800-53 compliance documentation covers SC-28 explicitly.

Red flags include vendors who claim encryption is “enabled by default” but can’t produce configuration evidence, vendors whose key management relies on shared or hardcoded credentials, and vendors who encrypt primary storage but exclude backups, disaster recovery sites, or development environments. If a vendor can’t demonstrate that encryption keys are managed independently from the data they protect, their SC-28 posture is incomplete regardless of what their policy states.

Evidence examples

Cross-framework mapping

Related controls

• AC-03 (Access Enforcement): Restricts who can access stored data. SC-28 protects the data itself, while AC-03 controls the access paths to it.
• AC-04 (Information Flow Enforcement): Governs how data moves between system components. SC-28 addresses data once it stops moving.
• AC-06 (Least Privilege): Limits user permissions to the minimum necessary. Combined with SC-28, it reduces both who can reach data at rest and what they can do with it if they do.
• AC-19 (Access Control for Mobile Devices): Addresses the elevated risk of mobile endpoints, where SC-28 encryption is critical because devices are more likely to be lost or stolen.
• CA-07 (Continuous Monitoring): Provides ongoing verification that SC-28 protections remain active. Without continuous monitoring, encryption gaps can go undetected.
• CM-03 (Configuration Change Control): Ensures that changes to encryption settings, key management configurations, and storage protections follow a controlled process.
• CM-05 (Access Restrictions for Change): Limits who can modify the system configurations that SC-28 protects, preventing unauthorized weakening of encryption or integrity controls.
• CM-06 (Configuration Settings): Defines the baseline configuration standards that include encryption-at-rest requirements for each system component.
• CP-09 (System Backup): Requires that backup data receive the same SC-28 protections as production data, preventing a common gap where backups are stored unencrypted.
• MP-04 (Media Storage): Governs the physical and logical protection of storage media, complementing SC-28’s focus on the data stored on that media.

Frequently asked questions

What is NIST SP 800-53 SC-28?

SC-28 is the NIST SP 800-53 control that requires organizations to protect the confidentiality and integrity of information at rest using cryptographic mechanisms or equivalent safeguards. The control covers both user data and system-level information such as firewall configurations, intrusion detection rule sets, and authentication credentials stored on system components. It applies to the MODERATE and HIGH baselines, meaning any federal system or organization using NIST 800-53 at those levels must implement it.

What happens if SC-28 is not implemented?

Without SC-28 protections, stored data on any compromised, stolen, or improperly decommissioned system component is exposed in cleartext. This gap turns routine incidents like a stolen laptop or a misconfigured storage bucket into reportable breaches. Auditors will flag the absence of encryption-at-rest configuration documentation and key management procedures as a direct control failure during NIST SP 800-53 assessments.

How do you audit SC-28?

Auditing SC-28 starts with verifying that your cryptographic mechanisms match what your system security plan documents. Assessors review encryption configuration settings across endpoints, databases, and cloud storage, then confirm that key management procedures separate keys from the data they protect. They also examine your data-at-rest inventory to validate that every storage location with confidentiality or integrity requirements has a documented protection mechanism applied.

Does encryption at rest satisfy SC-28?

Encryption at rest is the most common mechanism for meeting SC-28, but encryption alone doesn’t satisfy the control. The protection is only meaningful when encryption keys are managed separately from the encrypted data. SC-28 also addresses integrity, not just confidentiality, so organizations may need additional safeguards like file integrity monitoring or WORM storage for system configurations and stored credentials.