Protection of Information at Rest | Cryptographic Protection

To meet the Protection of Information at Rest | Cryptographic Protection requirement, you must define which data and system components are in scope, then implement cryptographic mechanisms that prevent unauthorized disclosure and modification of that data while it is stored. Operationally, this means enforcing encryption at rest with sound key management, plus configuration and evidence that prove coverage across databases, disks, backups, and managed cloud services. ¹

Key takeaways:

• Scope first: formally define “organization-defined information” and “system components” before you encrypt. ¹
• Encryption must address disclosure and modification risk, so pair encryption-at-rest with integrity protections and controlled key access. ¹
• Audits fail on gaps: backups, snapshots, logs, and unmanaged storage are the common miss zones; prove coverage with inventories and config evidence. ¹

This requirement is straightforward in text and unforgiving in audits: you must implement cryptographic mechanisms for defined information at rest on defined system components to prevent unauthorized disclosure and modification. ¹ The work is not “turn on encryption” in one place; it is an end-to-end scoping, configuration, and evidence problem across storage layers and service models.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SC-28(1) as a coverage map and an evidence package. You decide what data classes are in scope (for example, federal data, regulated data, customer content, secrets) and which components store it (VM disks, object storage, database storage, file shares, backup repositories, snapshot services, logging sinks). Then you enforce encryption at rest everywhere that data can land, control key access, and retain proof that the configuration is consistent and monitored.

If you support a FedRAMP environment, expect assessors to ask for clean scoping decisions, repeatable technical enforcement, and artifacts that show encryption is not a one-time setting but an operational state you maintain.

Regulatory text

Requirement: “Implement cryptographic mechanisms to prevent unauthorized disclosure and modification of organization-defined information at rest on organization-defined system components.” ¹

Operator interpretation:

1. You must define the information at rest that needs protection and the components where it resides. “Organization-defined” is a scoping decision you document and keep consistent across policy, system boundaries, and data flows. ¹
2. You must implement cryptographic mechanisms (typically encryption at rest, sometimes with authenticated encryption or cryptographic integrity checks) that reduce two risks:

• Unauthorized disclosure (someone reads stored data without approval).
• Unauthorized modification (someone alters stored data without approval). ¹

Auditors will read this as a requirement for technical enforcement plus proof that the enforcement covers the defined scope.

Plain-English requirement: what “good” looks like

You can explain compliance in one sentence: “Any place our in-scope data is stored is encrypted at rest, keys are controlled and access is logged, and we can prove coverage for disks, databases, object storage, backups, and snapshots.” ¹

In practice, strong implementations have:

• A written scoping statement tied to data classification and system boundary.
• Standard encryption configurations for each storage type (block, file, object, database, backup).
• Central key management controls (ownership, rotation approach, access approvals, logging).
• Continuous detection for drift (unencrypted resources or wrong key policies).
• Evidence that matches reality (inventory + configuration output + monitoring results).

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers and Federal Agencies implementing NIST SP 800-53 controls, including FedRAMP-aligned environments. ¹

Operational context where it matters most:

• Multi-tenant or shared infrastructure environments.
• Systems that store sensitive customer content, federal information, or regulated records.
• Data platforms with many storage endpoints (data lakes, analytics, logging, CI/CD artifacts).
• Backup and disaster recovery architectures, where copies multiply quickly.

If you have third parties handling any in-scope stored data (managed database providers, backup processors, support tooling), treat them as extensions of the storage surface: require encryption-at-rest guarantees and key-handling expectations in contracts and due diligence.

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

1) Define scope: “information at rest” and “system components”

Create two lists and get them approved:

• In-scope information at rest: map to your data classification scheme (examples: customer content, federal data, authentication secrets, regulated records, audit logs).
• In-scope system components: anything that stores, queues-to-disk, snapshots, or backs up in-scope data (VM disks, container volumes, managed databases, object stores, file shares, backup vaults, log indexes). ¹

Deliverable: a short “SC-28(1) scope statement” referenced by policy, your system security plan, and architecture diagrams.

2) Build a storage inventory that includes “hidden” data stores

Do not start by changing configs. Start by discovering where data lands:

• Cloud asset inventory (accounts/subscriptions/projects).
• Storage services inventory (block/object/file/db).
• Backup/snapshot inventory.
• Logging and monitoring sinks that persist data.
• Developer tooling storage (artifact repositories, container registries, CI logs).

This inventory becomes your audit backbone. If you cannot enumerate it, you cannot prove encryption coverage.

3) Choose cryptographic mechanisms per storage type (standardize)

Define an implementation standard that engineers can follow repeatedly:

• Block storage / disk encryption: enable full-disk encryption for VM volumes and managed disk services.
• Database encryption: require managed database “storage encryption” settings and enforce them via policy-as-code.
• Object storage: require default bucket/container encryption; prevent public access separately, but keep it distinct from SC-28(1).
• Backups and snapshots: ensure backup vault encryption and snapshot encryption inherit from encrypted sources, and verify exceptions. ¹

Write these as “must” statements with verification methods (example: “Engineer must show service setting X enabled; Compliance verifies via configuration export Y”).

4) Key management: define ownership, access control, and logging

Encryption without controlled keys fails the intent. Your operating decisions should include:

• Key ownership model (platform security team, cloud security team, or centralized KMS admins).
• Access control: who can use keys to decrypt, who can administer keys, who can change policies.
• Separation of duties: avoid having the same role both manage keys and approve its own access.
• Logging: ensure key usage and administrative actions are logged and reviewed. ¹

Practical note: managed cloud KMS services reduce operational risk, but only if you lock down admin actions and monitor key policy changes.

5) Prevent drift: enforce and continuously detect

Assessors will test whether encryption can be bypassed by creating a new unencrypted resource.

• Add guardrails (for example, org-level policies, IaC checks, CI rules) to block unencrypted storage creation.
• Add detection (continuous configuration monitoring) to alert on any unencrypted at-rest store or weak key policy.
• Document the exception process for the rare case where encryption cannot be enabled, including compensating controls and an end date. ¹

6) Prove integrity protection (the “modification” clause)

SC-28(1) includes “modification” in addition to “disclosure.” ¹ Encryption helps confidentiality; integrity requires additional thought:

• For stored objects/files: consider immutable storage features, object versioning, write-once settings, or cryptographic checks (hashing, signed artifacts) where tamper evidence matters.
• For databases: rely on access controls, audit logging, and database integrity features; document how unauthorized modification is detected and investigated.
• For backups: use immutable backup settings where supported and log restore events.

Keep this requirement-level: you do not need to redesign everything as a cryptographic integrity system, but you do need a documented mechanism that reasonably addresses unauthorized modification risk for your in-scope stored data.

7) Operationalize: assign owners and make it reviewable

Tie each storage category to an operational owner:

• Engineering owner: implements baseline.
• Security owner: sets key policies and monitoring.
• GRC owner: maintains scope statement, evidence package, and exceptions register.

If you want this to move fast, Daydream can help you run the control as a living program: collect encryption configuration evidence on a cadence, track exceptions to closure, and keep the scope statement and inventory aligned with architecture changes.

Required evidence and artifacts to retain

Keep artifacts that answer three audit questions: scope, implementation, and ongoing assurance.

• SC-28(1) scope statement: defined information + defined system components. ¹
• Data classification policy excerpts showing what “in-scope” means in your environment.
• System boundary diagrams / data flow diagrams showing where data rests.
• Storage inventory export (asset list with owners and service types).
• Encryption configuration evidence per service (screenshots, CLI output, API exports, IaC modules showing encryption defaults).
• Key management procedures (access approvals, role definitions, logging configuration).
• Monitoring/detection evidence (policy rules, alerts, sample findings and closure records).
• Exceptions register with approvals, compensating controls, and removal plan.

Common exam/audit questions and hangups

Expect questions like:

• “Show me the list of system components in scope and where it’s documented.” ¹
• “Prove encryption at rest is enabled for backups and snapshots, not only primary databases.” ¹
• “Who can decrypt data? How is key usage controlled and logged?” ¹
• “What prevents engineers from creating new unencrypted storage tomorrow?”
• “How do you address the ‘modification’ part of the requirement?”

Hangups that stall audits:

• You rely on “cloud provider encrypts everything” without scoping or evidence exports.
• Keys exist, but nobody can explain access paths, break-glass, or logging.
• You have drift: a few storage resources are not encrypted because they were created before guardrails.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Encrypting only primary storage.
   Fix: Put backups, snapshots, and log retention stores in the same inventory and test them explicitly.

2. Mistake: No documented “organization-defined” scope.
   Fix: Write the scope statement and get it referenced by your system security documentation. ¹

3. Mistake: Key administrator sprawl.
   Fix: Minimize key admin roles, separate admin from use where possible, and monitor policy changes.

4. Mistake: Assuming integrity is covered without explanation.
   Fix: Document how you detect and respond to unauthorized modification for each major storage type (immutability/versioning/audit logs), even if encryption is mainly confidentiality-focused. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat enforcement risk as indirect: failures typically surface during authorization assessments, customer audits, incident response, or as findings that delay go-live. The practical risk is simple: unencrypted stored data increases the impact of credential compromise, misconfiguration, theft of media, and unauthorized administrative access. ¹

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

Because fixed durations are not source-backed, treat this as a phased plan you can compress or expand based on system size and cloud footprint.

First 30 days (Immediate)

• Approve the SC-28(1) scope statement: in-scope data + in-scope components. ¹
• Produce the storage inventory, including backups, snapshots, and logs.
• Set encryption-at-rest baselines for each storage type and identify gaps.
• Decide key ownership, access model, and logging requirements.

By 60 days (Near-term)

• Remediate high-risk gaps (unencrypted databases, object storage defaults, backup vault settings).
• Implement guardrails that block creation of unencrypted storage where feasible.
• Stand up monitoring for encryption drift and key policy changes.
• Draft and run the exceptions process with at least one tabletop example.

By 90 days (Operational)

• Convert baselines into repeatable engineering patterns (IaC modules, golden templates, service catalog entries).
• Produce an audit-ready evidence pack: scope, inventory, configs, monitoring, and exceptions.
• Add periodic review: inventory reconciliation, exception aging review, and key access review.
• If you use Daydream, configure recurring evidence collection and exception tracking so the control stays current as systems change.

Frequently Asked Questions

Does “encryption at rest” mean I must encrypt everything everywhere?

You must encrypt the organization-defined information at rest on the organization-defined components you put in scope. The control expects a defensible scoping decision and consistent enforcement across that scope. ¹

Are backups and snapshots in scope?

If they store in-scope information, they are system components that hold information at rest and should be included. Auditors commonly test backups and snapshots because they are frequently missed. ¹

Can I rely on my cloud provider’s default encryption settings?

You can use managed encryption features, but you still need evidence that encryption is enabled for your specific resources and that key access is controlled. “Provider encrypts by default” is not a substitute for configuration proof and governance. ¹

What does the “modification” part require beyond encryption?

Document and implement mechanisms that reduce unauthorized changes to stored data, such as immutability/versioning for object stores, audit logging and access controls for databases, and tamper-evident handling for backups where needed. Tie the mechanism to your data types and threat model. ¹

Do we need customer-managed keys to pass?

The requirement mandates cryptographic mechanisms and does not state a specific key ownership model in the provided text. Choose a model you can govern, monitor, and explain clearly in audits. ¹

What evidence is usually most persuasive to assessors?

A reconciled storage inventory plus exported configuration proof that encryption is enabled across all in-scope storage types, supported by key management documentation and drift monitoring results. One-off screenshots without inventory context tend to raise questions. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5