SC-28(1): Cryptographic Protection

SC-28(1) is a requirement-level control enhancement focused on cryptographic protection for information at rest. Your job as a Compliance Officer, CCO, or GRC lead is to translate the control’s intent into an operational standard that engineering, IT operations, and third parties can implement consistently, then generate evidence that withstands assessment scrutiny.

This control is usually assessed in real environments where data is dispersed: endpoints, virtual machines, databases, object storage, SaaS applications, backups, logs, and developer tooling. The hardest part is rarely “turning encryption on.” The hard part is proving that the specific information types you declared in-scope are protected everywhere they reside, and that cryptographic controls also prevent unauthorized modification, not just disclosure.

This page gives you a quick path to operationalize SC-28(1): define scope, map storage locations, enforce encryption baselines, implement key management expectations, test coverage, and retain evidence that an assessor can verify without reverse-engineering your architecture. Source references are limited to NIST SP 800-53 Rev. 5 materials provided. ¹

Regulatory text

Requirement (excerpt): “Implement cryptographic mechanisms to prevent unauthorized disclosure and modification of the following information at rest on {{ insert: param, sc-28.01_odp.02 }}: {{ insert: param, sc-28.01_odp.01 }}.” ²

Operator interpretation of the placeholders: those parameters are where your program defines (1) which information requires protection (e.g., CUI, PII, secrets, financial records, regulated datasets), and (2) which information systems / components / storage technologies must enforce it (e.g., “all production databases,” “employee laptops,” “all backup media,” “cloud object storage buckets in accounts X and Y”).

What you must do in practice:

1. Make an explicit scoping decision for in-scope information types and at-rest locations.
2. Implement encryption (and integrity protection where applicable) so an unauthorized party cannot read or modify stored data.
3. Operate the control: key custody, rotation, access controls, monitoring, and exception handling.
4. Keep assessor-ready evidence that coverage is complete and sustained.

Plain-English interpretation

SC-28(1) requires you to apply cryptography to sensitive information while it is stored so that:

• Confidentiality is protected (unauthorized disclosure is prevented), and
• Integrity is protected (unauthorized modification is prevented).

In practical terms, you should treat this as “encryption at rest with proper key management and integrity controls” across the systems that store your in-scope data. “At rest” includes primary storage plus copies: backups, snapshots, replicas, archives, and exported datasets.

Who it applies to (entity and operational context)

SC-28(1) commonly applies in environments aligned to NIST SP 800-53, including:

• Federal information systems and programs assessed against NIST SP 800-53. ³
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down contractually or used as the security baseline. ³

Operationally, you should assume it applies wherever your organization stores in-scope information, including:

• Cloud services (IaaS/PaaS), SaaS data stores, and managed databases
• On-prem servers, SAN/NAS, hypervisor disks
• Endpoints (laptops, mobile devices, removable media)
• Backups and DR environments
• Logs, analytics warehouses, and data lakes
• Third parties that store or process your data

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

1) Define scope in business language (the two parameters)

Create a short scoping statement your teams can execute:

• In-scope information: list your categories (e.g., “CUI and customer PII,” “authentication secrets,” “security logs containing identifiers”).
• In-scope at-rest locations: list your system classes (e.g., “production databases,” “end-user endpoints,” “object storage,” “backup repositories”).

Deliverable: a one-page “SC-28(1) encryption-at-rest scope” standard that engineering can map to assets. Tie it to your data classification standard.

2) Build an authoritative inventory of at-rest data stores

You need an inventory that answers: “Where can in-scope information exist at rest?” Minimum set:

• Databases (managed and self-hosted)
• Object storage and file storage
• VM/block volumes
• Backup systems and snapshot tooling
• Endpoint storage (including developer workstations, if they hold production extracts)
• SaaS repositories (ticketing attachments, CRM exports, file collaboration tools)

A common audit hangup: teams inventory “systems” but miss “copies” (exports, backups, analytics pipelines). Treat copies as first-class storage locations.

3) Set encryption-at-rest baselines by storage type

Write configuration baselines by technology class. Keep them enforceable:

• Endpoints: full-disk encryption + device management controls to enforce and report status.
• Databases: encryption at rest enabled (platform-native where available) and restricted admin access to storage/keys.
• Object storage: default encryption enforced at bucket/container level; prevent unencrypted uploads via policy where supported.
• Backups/snapshots: encryption enabled for backup media, repositories, and snapshot artifacts; verify restores maintain protections.

Integrity expectation: document how you prevent unauthorized modification. Examples include authenticated encryption modes, digital signatures for artifacts, database integrity features, and strict key access controls that prevent an attacker from writing valid ciphertext.

4) Define key management requirements (what assessors look for)

SC-28(1) doesn’t work without key governance. Document and implement:

• Key ownership and custody: who administers KMS/HSM and under what approvals.
• Access control: least privilege for key use and key administration; separation of duties where feasible.
• Key lifecycle: generation, storage, rotation, revocation, and destruction.
• Logging and monitoring: record key access and administrative actions; alert on anomalous key usage.

You do not need to overspecify algorithms in the control narrative unless your internal standards demand it. What matters most in assessments is demonstrable, consistent protection for the scoped data at rest plus controlled key access. ³

5) Implement enforcement and drift control

Auditors will test whether your baselines are continuously applied.

• Use policy-as-code or configuration rules where available (cloud policies, endpoint compliance, storage guardrails).
• Define exception handling: who can request an exception, acceptable compensating controls, and expiration/review requirements.
• Run periodic checks: encryption posture reports per environment, plus spot checks on high-risk stores (backups, object storage, endpoints).

6) Validate coverage with targeted testing

Perform practical validation that maps to your scope statement:

• Pick representative systems from each storage class.
• Verify encryption settings and that unencrypted writes are blocked (where supported).
• Validate key access restrictions with role testing (who can decrypt, who can administer keys).
• Confirm that restores and replicas don’t silently drop encryption.

7) Operationalize evidence production (make audits routine)

Turn SC-28(1) into a recurring evidence package, not a scramble:

• Monthly/quarterly posture exports (endpoint encryption compliance, cloud encryption compliance, database settings)
• Change management records for baseline updates
• Exception register and reviews
• Key management access reviews and logs

Daydream (as a GRC workflow layer) fits here when you need the control mapped to a clear owner, a repeatable procedure, and a scheduled evidence checklist that produces the same artifacts every cycle without rebuilding the story. ²

Required evidence and artifacts to retain

Retain artifacts that prove scope, implementation, and operation:

Scope & design

• SC-28(1) control narrative with the two scoping parameters filled in (information types; at-rest locations)
• Data classification standard and mapping of in-scope categories
• Architecture diagrams or data flow diagrams identifying storage locations for in-scope information

Implementation

• Configuration baselines (endpoint, database, object storage, backups)
• Screenshots/exports showing encryption enabled in representative systems
• Infrastructure-as-code snippets or cloud policies enforcing encryption defaults
• Backup encryption configuration and restore procedure documentation

Key management

• KMS/HSM configuration overview
• Key access control lists / role mappings
• Key management procedures (rotation, revocation, break-glass)
• Logs evidencing key usage and key administration events (or references to where logs are retained)

Operational proof

• Recurring compliance reports (encryption posture) and follow-up tickets for gaps
• Exception register with approvals, compensating controls, and expiration
• Access review evidence for key administrators and high-risk decryption roles

Common exam/audit questions and hangups

Expect these questions:

1. “Show me your scope.” Which data is covered, and where it is stored at rest?
2. “Prove coverage is complete.” How do you know there are no unencrypted buckets, disks, backup repositories, or endpoints?
3. “Who can decrypt?” Enumerate roles with decrypt permissions and key admin permissions. Show approval and review.
4. “How do you prevent unauthorized modification?” Encryption alone may not satisfy integrity expectations if key access is too broad.
5. “What about backups and exports?” Assessors routinely dig into snapshots, backup vaults, and analyst extracts.
6. “Show me exceptions.” If any system is not encrypted at rest, where is the risk acceptance and what compensates?

Frequent implementation mistakes and how to avoid them

• Mistake: Treating “encryption enabled” as the finish line. Fix: require evidence of enforcement (policies/guardrails) and drift monitoring.
• Mistake: Missing non-obvious at-rest stores. Fix: explicitly include backups, snapshots, logs, analytics stores, and developer data extracts in the inventory.
• Mistake: Weak key access governance. Fix: separate key admin from key usage where feasible; run access reviews; document break-glass.
• Mistake: Undefined scope language. Fix: fill in the placeholders with concrete data types and system classes; avoid “all sensitive data everywhere” without a mapping.
• Mistake: Third-party blind spots. Fix: require third parties that store your in-scope data to attest to encryption at rest and key management controls, and collect their evidence or audit reports as appropriate.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not list enforcement actions.

Risk-wise, SC-28(1) is assessed because encryption at rest reduces exposure from lost devices, misconfigured storage, unauthorized administrative access, and backup/media compromise. The most common operational risk is a mismatch between your declared scope and your technical coverage, followed by insufficient key governance that allows unauthorized decryption or alteration.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Assign a control owner and technical owners per storage class (endpoints, databases, cloud storage, backups).
• Publish the SC-28(1) scope statement: in-scope data categories and at-rest locations. ²
• Build the inventory of at-rest stores for in-scope data, including backups and exports.
• Draft baseline standards and exception workflow.

Days 31–60 (implement and enforce)

• Enable encryption at rest across prioritized in-scope systems; address highest-risk stores first (portable endpoints, object storage, backups).
• Implement guardrails to prevent new unencrypted storage from being created.
• Stand up key management procedures and role-based access model; begin logging and monitoring for key events.
• Start evidence collection: posture exports and configuration proof.

Days 61–90 (validate and make it repeatable)

• Run targeted validation testing across each storage class; document results and remediation tickets.
• Conduct the first access review for key admins and decryption roles; capture approvals.
• Operationalize recurring evidence cycles in your GRC workflow (calendar-driven tasks, artifact checklists, exception reviews). Daydream is a natural place to keep the procedure and recurring evidence package tied to the control owner so audits do not become a one-off project. ²

Frequently Asked Questions

Does SC-28(1) require encryption for every system, or only certain data?

It requires cryptographic protection for the specific “information at rest” you define as in-scope and on the in-scope locations you specify. Your scope statement is part of the control and must be defensible and mapped to assets. ²

Are backups and snapshots included as “information at rest”?

Yes in practice, because they are stored copies of the same in-scope information. Auditors commonly test backup repositories and snapshot settings as part of encryption-at-rest coverage.

What evidence is usually most persuasive to an assessor?

A clear scope statement, an inventory mapping scope to actual storage services, and recurring posture reports that show encryption status with remediation tracking. Pair that with key access reviews and an exception register.

What does “prevent unauthorized modification” mean for encryption at rest?

You need cryptographic controls and key governance that stop an unauthorized party from altering stored data without detection or authorization. Tight key permissions and integrity-capable cryptographic mechanisms are the usual approach, backed by audit logs of key use.

How should we handle third parties that store our in-scope data?

Flow down encryption-at-rest and key management expectations contractually, then collect evidence appropriate to the relationship (attestation, audit report, or technical configuration proof). Track third-party exceptions the same way you track internal exceptions.

We have legacy systems that can’t encrypt at rest. Can we still comply?

You can document an exception with compensating controls and a remediation plan, but assessors will focus on whether the exception is time-bound, approved, and risk-managed. Keep the exception register and compensating control evidence ready.

Footnotes

1. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON

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

3. NIST SP 800-53 Rev. 5