SC-28: Protection of Information at Rest

To meet the sc-28: protection of information at rest requirement, you must protect the confidentiality (and, where applicable, integrity) of sensitive data stored on systems, databases, endpoints, backups, and portable media by using strong encryption, sound key management, and controlled access. Operationalize SC-28 by scoping “data at rest,” enforcing encryption-by-default, and retaining repeatable evidence. ¹

Key takeaways:

• Scope the control to where data is stored (databases, file stores, backups, endpoint disks, removable media), not where it moves.
• Encryption is necessary but incomplete without key management, access control, and coverage validation.
• Audits fail on evidence: prove encryption status, key custody, exceptions, and ongoing monitoring. ¹

SC-28 is a requirement-level control focused on “information at rest,” meaning data stored on any persistent medium: cloud disks, database volumes, object stores, file shares, endpoint drives, backup repositories, snapshots, and removable media. The control’s plain intent is simple: an attacker (or an unauthorized insider) should not be able to read protected data just because they gained access to storage. In practice, teams miss SC-28 because they treat encryption as a checkbox and do not define scope, classification triggers, key ownership, or exception handling.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate SC-28 into three operational deliverables: (1) a clear data-at-rest scope tied to your data classification and system boundary, (2) technical enforcement that makes encryption the default state, and (3) audit-ready evidence that shows coverage and control operation over time. NIST expects you to “protect” specified information at rest; your job is to define what “protect” means for your risk context and prove it is consistently implemented. ¹

Regulatory text

NIST SP 800-53 SC-28 excerpt: “Protect the {{ insert: param, sc-28_odp.01 }} of the following information at rest: {{ insert: param, sc-28_odp.02 }}.” ²

What the operator must do with this text

Because the excerpt is parameterized, you must explicitly define two things in your implementation:

1. What security property you are protecting (commonly confidentiality; sometimes integrity too, depending on your categorization and system risk decisions).
2. Which information types are in scope (for example: federal information, regulated personal data, authentication secrets, cryptographic key material, mission data, or other organization-defined sensitive data).

Your SC-28 implementation is complete when your defined in-scope data at rest is protected by enforceable technical controls, and you can prove coverage, exceptions, and ongoing operation. ¹

Plain-English interpretation (sc-28: protection of information at rest requirement)

If someone steals a disk, copies a snapshot, downloads a backup, or gets storage-level access, they still should not be able to read the sensitive data you store. You accomplish this primarily with encryption (or equivalent protective mechanisms), backed by key management, strict access control, and monitoring that validates the protection stays enabled.

Who it applies to (entity and operational context)

SC-28 commonly applies to:

• Federal information systems and programs aligning to NIST SP 800-53. ¹
• Contractor systems handling federal data, including environments where you store federal information in cloud services, managed databases, endpoints, or backups. ¹

Operationally, it applies anywhere your environment persists data, including:

• Infrastructure storage (block volumes, disks, SAN/NAS)
• Databases (managed or self-hosted)
• Object storage and file repositories
• Backup systems, snapshots, archives, disaster recovery replicas
• End-user devices and removable media
• Log stores that may contain sensitive fields (tokens, identifiers, payload fragments)

What you actually need to do (step-by-step)

1) Define SC-28 scope in writing

Create a short SC-28 scoping statement that answers:

• What information types are “the following information at rest” in your environment (tie to your data classification standard).
• What systems and storage locations are in scope (tie to your system boundary and asset inventory).
• What “protect” means for you (encryption at rest with defined crypto modules, plus access control and key management expectations).

Practical tip: Don’t scope by department. Scope by where the data is stored and replicated.

2) Establish minimum protection standards (your control “rules”)

Document enforceable requirements that engineering can implement consistently:

• Encryption at rest required for in-scope data stores (databases, volumes, object stores, backups).
• Central key management expectations (key ownership, rotation triggers, access approval, separation of duties where feasible).
• Secure handling of secrets and keys (keys are not stored in code repositories, tickets, or plaintext configuration files).
• Exception process (who can approve, compensating controls, time-bound review).

Map these rules to platform patterns (for example: “managed database encryption enabled,” “disk encryption for endpoints,” “backup encryption enabled with customer-managed keys where required”).

3) Implement encryption-by-default across storage tiers

Work with infrastructure and application owners to confirm and enforce:

• Cloud storage encryption: ensure encryption is enabled for object storage, managed disks, and database services.
• Database encryption: confirm encryption at rest configuration and that backups/snapshots inherit encryption.
• Endpoint and server disk encryption: confirm full-disk encryption policies for laptops and baseline hardening for servers/VM images.
• Backup encryption: ensure backup repositories and exported backup files are encrypted, including offline copies.

Where possible, enforce via policy-as-code and guardrails (for example, platform controls that prevent creating unencrypted storage).

4) Key management: assign ownership and prove custody

Encryption fails audits when key ownership is unclear. Define:

• Key owners (platform team, security team, or service owners depending on model).
• Approved key management systems and access paths.
• Logging requirements for key access/administration events.
• Break-glass procedures and post-use review.

Even if you use provider-managed keys, document who can change encryption settings and who can export or access decrypted data.

5) Validate coverage continuously (don’t rely on “we turned it on once”)

Build a recurring validation mechanism:

• Configuration scans for encryption settings on storage resources.
• Sampling checks for databases, backups, and endpoints.
• Monitoring and alerting for noncompliant storage creation or encryption disablement.

If you use Daydream to manage control operation, treat SC-28 as a mapped control with a named owner, a written procedure, and recurring evidence artifacts so you can demonstrate ongoing compliance without rebuilding proof each audit cycle. ²

6) Manage exceptions like incidents

When encryption is infeasible (legacy systems, performance constraints, third-party constraints):

• Require documented risk acceptance and compensating controls (tight access control, segmentation, monitoring, tokenization, field-level encryption).
• Set an expiration and review cadence.
• Track exceptions in a register linked to assets and data types.

Required evidence and artifacts to retain

Auditors assess SC-28 on both design and operating effectiveness. Keep evidence that is easy to re-run and time-stamped.

Core artifacts

• SC-28 control statement: scope, protected property (confidentiality/integrity), in-scope info types, and protection method. ¹
• Data classification and handling standard tied to “information at rest.”
• Asset/system inventory showing in-scope stores (databases, buckets, volumes, backups, endpoints).
• Encryption configuration evidence: screenshots/exports of settings, IaC snippets, or configuration reports for representative systems.
• Key management evidence: KMS policies, access control lists, key ownership, rotation policy, and administrative logs.
• Exception register: approvals, compensating controls, expiry, and remediation plan.
• Recurring compliance checks: scan outputs, monitoring alerts, and remediation tickets that show issues are detected and fixed.

Common exam/audit questions and hangups

Expect assessors to probe “coverage” and “keys,” not just whether encryption exists.

1. “Show me all data stores with sensitive data at rest and their encryption status.”
   • Hangup: incomplete inventory or unknown shadow IT storage.
2. “Who can decrypt the data?”
   • Hangup: broad KMS permissions, unclear separation of duties, no review of key admin access.
3. “Are backups, snapshots, exports, and replicas encrypted too?”
   • Hangup: backups managed by separate tooling with different defaults.
4. “How do you prevent engineers from creating unencrypted storage?”
   • Hangup: no guardrails; only after-the-fact reviews.
5. “How do you know encryption stayed on?”
   • Hangup: no continuous validation or monitoring evidence.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails SC-28	Fix
Treating “encryption enabled” as the whole control	SC-28 is about protecting information at rest; encryption without key governance can still allow unauthorized decryption	Define key ownership, access pathways, logging, and reviews
Encrypting primary databases but forgetting backups/exports	Breach paths often target backups and snapshots	Include backup and snapshot tooling in scope and scans
No written scope for “information at rest”	Parameterized SC-28 requires organization-defined scope	Publish scope tied to classification and system boundary
Overbroad KMS admin rights	Too many people can decrypt or reconfigure	Restrict, log, and review key administration privileges
Exceptions are informal	Audits treat exceptions as control failure	Formal exception register with time bounds and compensating controls

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement expectations as audit/assessment-driven rather than case-driven for purposes of this page. The practical risk is consistent across sectors: unprotected storage increases breach impact because data disclosure becomes a storage-access problem instead of an encryption/key-custody problem. ¹

Practical execution plan (30/60/90-day)

First 30 days: establish scope and control ownership

• Assign a single accountable owner for SC-28 and named technical owners per platform (cloud, endpoints, backups).
• Publish SC-28 scope: in-scope data types and in-scope storage locations.
• Identify all storage systems and rank them by sensitivity and exposure.
• Decide on key management model per platform (provider-managed vs customer-managed) and document it. ¹

Days 31–60: enforce baseline protections and close obvious gaps

• Turn on encryption-by-default for major storage services and managed databases.
• Ensure backups/snapshots/replicas inherit encryption; fix tools that do not.
• Lock down KMS permissions and implement logging for key administration.
• Create the exception workflow and start tracking any noncompliant stores.

Days 61–90: make it repeatable and audit-ready

• Implement continuous checks (configuration scanning, drift detection, alerts).
• Build an evidence pack: inventory + encryption status reports + key access reviews + exception register extracts.
• Run an internal readiness review: pick sample systems and walk an auditor through end-to-end proof.
• In Daydream, map SC-28 to the control owner, implementation procedure, and recurring evidence artifacts so you can produce the same package each audit cycle with less scramble. ²

Frequently Asked Questions

Does SC-28 require encryption for every single system?

SC-28 requires you to protect the organization-defined information at rest, which means you must define what data is in scope and then protect it consistently. If something is out of scope, document why; if encryption is infeasible, document an exception with compensating controls. ¹

Are cloud provider “default encryption” settings enough?

They can be, but auditors still expect proof of coverage and key governance. You need evidence that defaults apply to your resources, that exceptions are prevented or detected, and that key administration access is controlled and reviewed. ¹

Do backups and snapshots count as information at rest?

Yes. Backups, snapshots, replicas, and exported database dumps are all stored data and must be included in your data-at-rest scope and protection checks. ¹

What’s the fastest way to get audit-ready evidence for SC-28?

Start with an inventory of storage locations tied to data classification, then attach configuration evidence that encryption is enabled, plus KMS access controls and an exception register. Automate recurring exports where possible so you can show ongoing operation, not a one-time screenshot. ¹

How should we handle third-party managed systems that store federal data?

Treat third-party storage the same way: define it in scope, require contractual/assessment evidence of encryption at rest and key management responsibilities, and document shared responsibility boundaries. If you can’t get evidence, track it as a risk and exception with a remediation plan. ¹

What evidence do auditors ask for most often?

They ask for proof that sensitive data stores are encrypted, proof that backups are encrypted, and proof that key access is restricted and monitored. They also ask how you detect drift or prevent teams from creating unencrypted storage. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON