Protection of Information at Rest

“Protection of information at rest” becomes hard in real programs for one reason: data rests in more places than your diagrams admit. It sits in managed databases, object storage, VM and container disks, SaaS export files, backups, snapshots, CI/CD artifacts, developer laptops, and third-party support bundles. SC-28 is a short requirement, but it forces a decision you must make explicitly: what information is “organization-defined” and therefore must be protected for confidentiality and integrity at rest.

For FedRAMP Moderate environments, you should treat SC-28 as a build-and-prove control. Build means you implement consistent at-rest protections across your storage stack, including key management and strict access paths. Prove means you can show an assessor how you know the protections are enabled, how you prevent drift, how you detect exceptions, and how you handle edge cases like logs, exports, and backups.

This page gives you requirement-level guidance you can execute quickly: who is in scope, what to do step-by-step, what evidence to retain, and where audits usually get stuck.

Regulatory text

Requirement (excerpt): “Protect the confidentiality and integrity of organization-defined information at rest.” (NIST Special Publication 800-53 Revision 5)

What an operator must do:

1. Decide which stored information is covered (“organization-defined information at rest”).
2. Implement technical and procedural safeguards that protect confidentiality (prevent unauthorized disclosure) and integrity (prevent unauthorized modification or detect it) for that information wherever it is stored.
3. Demonstrate the safeguards are consistently applied across systems, backups, and supporting processes. (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation

SC-28 requires you to prevent someone from reading stored sensitive data and to prevent (or reliably detect) unauthorized changes to it. In most FedRAMP Moderate implementations, encryption at rest is the default method for confidentiality, paired with access controls, key management, and integrity mechanisms (for example, authenticated encryption modes, hashing/signing where appropriate, database integrity controls, and immutable logging for critical records). The control is outcome-based: you can use different technical patterns, but you must be able to show the outcome is achieved for the data you defined as in scope. (NIST Special Publication 800-53 Revision 5)

Who it applies to (entity and operational context)

In scope entities

• Cloud Service Providers (CSPs) operating a FedRAMP Moderate authorized system, including the platform components, management plane, and supporting services that store customer or agency data. (NIST Special Publication 800-53 Revision 5)
• Federal Agencies operating information systems aligned to NIST SP 800-53 controls, including agency-managed storage and agency-managed keys where applicable. (NIST Special Publication 800-53 Revision 5)

In scope operational contexts (typical)

• Persistent storage: block volumes, database storage, object storage, file shares, data lakes/warehouses.
• Backups and replicas: backup vaults, snapshots, cross-region replication, archive tiers.
• Derived data: exports, ETL outputs, analytics extracts, debug dumps.
• Endpoints and removable media if they store covered data (for example, admin workstations used to administer the system).
• Third parties: any external provider that stores your covered data (support tooling, log processors, backup providers, managed database services).

A fast scoping test: if the system can “write it to disk,” assume SC-28 applies until you document why it does not.

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

Step 1: Define “organization-defined information at rest”

Write a short SC-28 scoping statement that names:

• Data classes (for example: CUI, FCI, agency data, secrets, audit logs, credentials).
• Systems and components in scope (production, staging, DR, logging, analytics).
• Explicit exclusions (if any) with justification.

Deliverable: SC-28 Scope Statement approved by the system owner and security.

Step 2: Build an inventory of all “resting places”

Create a storage-centric inventory that includes:

• Data store name, owner, environment, region, and service type.
• Encryption-at-rest capability and status (enabled/disabled/conditional).
• Key source (provider-managed keys vs customer-managed keys) and key location.
• Backup/snapshot behavior and where backups land.
• Data flows that generate resting artifacts (exports, reports, batch jobs).

Tip from audits: assessors trust inventories that tie to configuration evidence (screenshots, API outputs, IaC) more than spreadsheets that only list names.

Deliverable: Information-at-Rest Inventory mapped to systems and data types.

Step 3: Implement confidentiality controls (commonly encryption at rest)

For each storage type, choose a standard pattern and make it the default:

• Managed databases/object storage/block storage: enable platform encryption at rest; forbid unencrypted resources by policy.
• Application-layer storage: encrypt sensitive fields or payloads before writing, when platform encryption is not sufficient for your threat model or tenancy model.
• Backups/snapshots: ensure encryption follows the backup path, not just primary storage.

Operational requirement: define what “enabled” means and how you prevent drift (guardrails, policy-as-code, CI checks, or provisioning controls).

Deliverables:

• Encryption Standard for Data at Rest (what must be encrypted, acceptable mechanisms, where keys live).
• Configuration baselines (IaC modules, golden templates, or hardening standards).

Step 4: Implement integrity protections appropriate to the data

SC-28 explicitly calls out integrity. Don’t treat it as implied.

• For databases, use strong authentication/authorization, least privilege, change auditing, and database integrity features.
• For critical files/blobs, use checksums/hashes, object versioning, write-once/immutable storage where appropriate, and strong access controls to prevent tampering.
• For configuration and artifacts, protect integrity with signed builds, artifact repositories with immutability, and restricted write paths.

Deliverable: Integrity Protection Design Notes that map key repositories and record types to specific integrity controls.

Step 5: Key management and access control (where audits focus)

Encryption at rest fails in practice when key management is weak. Establish:

• Key ownership and administration model (who can create, rotate, disable, and decrypt).
• Separation of duties for key admins vs data admins where feasible.
• Logging and monitoring for key usage, policy changes, and decrypt operations.
• A defined process for key rotation, compromise response, and access review.

Deliverables:

• Key Management Procedure (creation, rotation, access approval, emergency access).
• KMS/key inventory with ownership and rotation expectations.
• Access control matrix for key permissions vs roles.

Step 6: Cover the “forgotten” data at rest locations

This is where SC-28 programs break:

• Logs and traces that include identifiers, tokens, payload snippets.
• Support bundles and diagnostic dumps.
• Data exports to third parties or customer delivery locations.
• CI/CD artifacts and test datasets.

Create a rule: if production data can land there, it is in scope and must be protected.

Deliverable: Edge-case register listing locations, controls, and owners.

Step 7: Exceptions, compensating controls, and continuous verification

You will have exceptions (legacy systems, performance constraints, third-party limitations). Document:

• Business justification.
• Compensating controls (access restrictions, segmentation, monitoring, reduced retention).
• Sunset plan.

Then implement continuous verification:

• Periodic configuration checks for encryption settings and key policies.
• Alerts for unencrypted resource creation and key policy changes.
• Evidence collection that is repeatable.

Deliverables:

• SC-28 Exception Register with approvals.
• Continuous control monitoring checks (queries, scripts, or tool outputs).

Where Daydream fits

Most teams lose time chasing evidence across cloud consoles, tickets, and spreadsheets. Daydream can act as the system of record for your SC-28 scope, storage inventory, exceptions, and recurring evidence requests so you can answer assessors with consistent artifacts and a clear control narrative.

Required evidence and artifacts to retain

Keep evidence that proves scope, implementation, and ongoing operation:

• SC-28 scope statement and data classification mapping.
• Storage inventory with encryption and key settings per data store.
• Configuration evidence: screenshots or exports showing encryption-at-rest enabled, plus key policy settings.
• KMS/key inventory, role-based access mappings, and access review records.
• Monitoring/alerting evidence for encryption drift and key policy changes.
• Backup and snapshot configuration evidence showing encryption persists through backups.
• Exception register with approvals and compensating controls.
• Procedures: encryption standard, key management procedure, incident runbook for key compromise.

Common exam/audit questions and hangups

Expect assessors to ask:

• “What is your organization-defined information at rest, and where is it stored?” (Scope clarity problem)
• “Show me that encryption at rest is enabled for this database, its backups, and its snapshots.” (Backup gap)
• “Who can decrypt data, and how is that access approved and reviewed?” (Key access gap)
• “How do you know a team can’t create an unencrypted storage resource?” (Drift prevention)
• “What integrity protections exist beyond encryption?” (Integrity is often under-documented)

Frequent implementation mistakes and how to avoid them

• Mistake: Defining scope as ‘all data’ but not backing it with an inventory.
  Fix: define scope, then prove it with a storage map tied to owners and systems.

• Mistake: Encrypting primary storage but missing backups, snapshots, replicas, and exports.
  Fix: require encryption on every persistence mechanism and validate end-to-end.

• Mistake: Treating integrity as “covered by encryption.”
  Fix: document integrity controls per data type (immutability, versioning, signed artifacts, database audit controls).

• Mistake: Weak key governance (too many admins, no monitoring, no access reviews).
  Fix: restrict key permissions, log key events, and review key access on a defined cadence.

• Mistake: Third-party storage blind spots.
  Fix: require third parties that store covered data to meet your at-rest protection standard contractually and validate during due diligence.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources. Practically, SC-28 failures increase breach impact (confidentiality) and data reliability risk (integrity), and they complicate incident response because you cannot credibly state what was exposed or modified without strong controls and logs. (NIST Special Publication 800-53 Revision 5)

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Publish the SC-28 scope statement and encryption standard.
• Build the information-at-rest inventory for production and DR.
• Identify top-risk gaps: any unencrypted storage, unmanaged keys, and backup paths without clear protection.
• Stand up the exception register and require approvals for any uncovered stores.

By 60 days (Control implementation and drift prevention)

• Enforce defaults: provisioning guardrails that block unencrypted storage where feasible.
• Implement key management procedure, roles, and logging/monitoring for key events.
• Close backup/snapshot/export gaps for in-scope data stores.
• Document integrity protections per major repository (databases, object stores, artifact stores).

By 90 days (Audit-ready operations)

• Run a full evidence dry run: pick representative systems and produce the complete evidence set quickly.
• Operationalize continuous checks for encryption posture and key policy drift.
• Complete access reviews for key administrators and sensitive data store admins.
• Review third-party arrangements where they store covered data; align contractual requirements to your SC-28 standard.

Frequently Asked Questions

Does SC-28 require encryption at rest specifically?

SC-28 requires protection of confidentiality and integrity for organization-defined information at rest, but it does not mandate a single method. Encryption at rest is the most common way to meet confidentiality expectations, and you still need integrity and key governance evidence. (NIST Special Publication 800-53 Revision 5)

What counts as “information at rest” in cloud environments?

Any covered data written to persistent storage is “at rest,” including databases, object storage, block volumes, file shares, backups, snapshots, replicas, and exported files. Treat derived artifacts (reports, debug dumps) as in scope if they contain covered data.

Are backups and snapshots always in scope?

If backups and snapshots contain organization-defined information, they are in scope because the requirement applies to information at rest regardless of whether it is primary or secondary storage. Audits commonly test backup encryption explicitly. (NIST Special Publication 800-53 Revision 5)

How do we show “integrity” for SC-28 without over-engineering?

Start by documenting integrity controls that already exist: access restrictions, change auditing, object versioning/immutability for critical stores, and signed/immutable build artifacts. Then map each high-value repository to one or more integrity mechanisms and keep evidence.

What evidence do assessors actually want to see?

They want to see (1) your definition of covered data, (2) an inventory of where it rests, (3) configuration evidence that encryption and key controls are enabled, and (4) operational evidence like monitoring, access reviews, and exception approvals.

How should we handle third parties that store our covered data?

Treat the third party as an extension of your storage footprint. Contractually require protections aligned to your SC-28 standard, validate during due diligence, and keep documentation showing where the data rests and how it is protected.