What SC-28 protection of information at rest requires in practice
If your system is rated moderate or high, or sits inside a FedRAMP boundary at Class B, C or D, SC-28 requires you to protect the confidentiality and, where defined, the integrity of the information you store. The control leaves it to you to decide which information needs that protection, and SC-28(1) then requires cryptographic protection for the defined information, using mechanisms you can justify. Unprotected stored data is a direct exposure: a stolen disk, a copied database file, an exposed backup or a misconfigured storage bucket can disclose records without any attacker ever touching the application. Encryption at rest limits that exposure because a copy of the raw storage is no longer readable on its own.
The hard part is rarely switching encryption on. It is knowing what is stored. Assessors work from a list of information at rest that requires protection, so your first deliverable is an inventory that covers relational and document databases, file shares, object storage, virtual disks, container volumes, search indexes, logs that carry personal or sensitive fields, caches, and the backup and snapshot copies of each. Backups and replicas are the usual gap, because teams often encrypt the primary store and forget the copies created by a scheduled job. Map each store to its owner, its data classification and its encryption mechanism, and record where keys are held. Confirm this inventory with the people who run storage, not only the architecture diagram.
Once the inventory exists, decide and document the cryptographic method for each class of data, then test it. Assessors examine the cryptographic mechanisms, the configuration settings for each store, and the system design documentation that explains where protection is applied. Server-side encryption in a self-hosted file platform such as Nextcloud protects file contents on local and external storage with keys kept on the server, but it does not hide file names or folder structure, so that metadata gap belongs in your risk record. For keys, a secrets engine such as OpenBao's transit engine can hold versioned keys and rotate them, while secret detection in your pipeline, such as GitLab's pipeline secret detection job, helps catch keys committed to repositories. Ask your implementation partner to produce the inventory, configuration exports and key rotation records together, because those three artifacts are what passes the examination.
Which stores, backups and teams fall under SC-28
SC-28 applies to every place defined information rests, not only the primary database. The cards below list the stores, copies and owning teams that an assessor expects to see in the system boundary, along with the scoping decisions that change how much work each one creates.
Application databases
Production and reporting databases are usually the first scope item because they hold the defined information. Confirm which tables hold information requiring confidentiality protection and which require integrity protection, since the two needs can lead to different mechanisms. The DBA team typically owns encryption settings, while the application team owns which fields are sensitive. Ask for the list of database instances, their storage engines and where the keys for each are held.
File and object storage
File shares and object buckets often hold copies of defined information that were never meant to be stored there, such as exports, attachments and uploads. Check whether encryption covers file contents only or also file names and folder structure, because some server-side encryption designs protect contents and leave metadata visible. Platform engineering usually owns these stores, so ask for an inventory tied to the data classification.
Backups and snapshots
Backup sets and point-in-time snapshots carry the same information as the source systems and are frequently forgotten during scoping. Backup operations teams should confirm that every backup target, replication copy and offsite archive is encrypted, and that backup encryption keys are governed separately from production keys. Ask whether restore tests exercise decryption, since a backup that cannot be read during recovery is a failed control.
Removable media and replicas
Replicas in secondary regions, read copies and removable media such as drives used for transport each create another location where information rests. Media handling is governed by the MP family, but SC-28 still applies to what is stored on that media. Ask who approves media leaving the facility, how it is encrypted before it moves, and whether replicas inherit the same encryption and key controls as their source.
Third-party hosts and managed encryption
Cloud provider managed encryption and third-party hosted stores change the boundary question. Decide whether the provider's encryption and key service sits inside the system boundary as an inherited control, or whether the organization must document its own key custody. Third-party teams and the contract should state who holds keys, where the cryptographic modules run, and what evidence the provider supplies for an assessor.
Scoping decisions that change the work
Two decisions change the workload most. The first is whether defined information needs confidentiality, integrity or both, because the SC-28 determination statement is assessed against the list of information that requires each protection. The second is whether managed encryption is part of the boundary. Document both choices in the system design documentation before the assessment, since assessors examine that list and the configuration settings tied to it.
How to implement SC-28 and SC-28(1) step by step
This sequence moves an organization from an unknown set of stored data to a documented, verified state in which every store and backup holding protected information is encrypted under controlled keys, with evidence an assessor can examine.
Define the information at rest requiring protection
The organization owns this step and decides which information must be protected for confidentiality, integrity or both, based on its system boundary and data categories. Security, data owners and the system owner agree the list in writing. Done means the information inventory names each data type, its classification and the reason it needs protection, and the assessor's examine object 'list of information at rest requiring confidentiality and integrity protections' exists and is approved.
Record every storage location and backup
Engineering teams trace where that information lives: databases, file stores, object storage, virtual disks, caches, logs, endpoints where permitted, removable media and backup repositories, including copies held by a third party. An implementation partner can help build the inventory from infrastructure-as-code and cloud account exports, but the organization confirms it. Done means each location has an owner, a system component reference and a data type, and the inventory is reconciled against the system boundary.
Choose and document cryptographic mechanisms
The security architect selects an encryption method for each location and records it in the system design documentation. Where the moderate or high baseline or a FedRAMP class applies, the mechanisms must be FIPS-validated, so the team confirms validation status from the module vendor's current certificate rather than from marketing material. Done means a design document maps each location to its algorithm, module, key type and the assessor-visible rationale for the choice.
Separate key management from the protected data
Engineers place encryption keys in a key management service or secrets engine that is administered apart from the storage platform, with access limited to named roles and key rotation defined. Where the platform keeps keys on the same server as the data, the design document must say so and state the residual risk. Open-source options such as OpenBao's transit secrets engine can hold keys and perform encryption and rotation, but the team must confirm each capability against its own configuration. Done means key custody, rotation and access roles are written down and tested.
Enable and verify protection on each store
Administrators turn on encryption for each store and backup from the inventory, then confirm it is active on the live system, not only in the configuration file. Verification includes reading back encryption status, testing that a restored backup remains encrypted and checking that unencrypted copies are not created during replication. Where a platform only protects file contents and not metadata, such as file names or folder structure, the gap is recorded for the risk owner. Done means each inventory row carries a dated verification result.
Protect transport media and removable storage
For SC-28(1), where media leaves controlled areas or is shipped, the team applies encryption or an equivalent protection and records the handling procedure. This step also covers secrets that could expose stored data, which can be scanned for in repositories and pipelines with tools such as GitLab's pipeline secret detection, which writes findings to a job artifact. Done means the media handling procedure references the encryption requirement and the scan results are retained as evidence.
Document the configuration and retain exports
The team exports configuration settings, key policy and encryption status from each platform and stores them with the system security plan. These exports, the design document and the inventory form the evidence set that an assessor uses to examine the control. An independent assessor performs the assessment and issues any report; the implementation partner and the organization only prepare the evidence. Done means every configuration export is dated, versioned and traceable to a row in the inventory.
How an assessor tests SC-28 under SP 800-53A
This table breaks down the single SC-28 determination statement in SP 800-53A Release 5.2.0 and the evidence an assessor examines, interviews and tests for each part. Read it as a checklist of what to have ready before an assessment begins, and note where a stale information list or partial encryption coverage usually causes findings.
| Assessment element | What the assessor does | Evidence to have ready |
|---|---|---|
| Determination statement | Decides whether the organization has protected the confidentiality and/or integrity of the defined information at rest, using examine, interview and test methods | A written statement of how each defined information type is protected at rest |
| Examine: cryptographic mechanisms | Reviews which cipher, key length and mode protects each store, and whether the mechanism matches the organization's stated requirement | Cryptographic configuration documentation, algorithm settings and any FIPS validation claims for each mechanism |
| Examine: list of information at rest | Compares the list of information requiring protection against the systems and data stores that actually hold it | A current, dated inventory of information at rest, including databases, file stores, backups and archives |
| Examine: system design documentation | Traces where protected data is written, copied and replicated to confirm the design covers every storage location | Architecture diagrams and data flow documents showing primary, replica, cache and backup locations |
| Examine: system configuration settings | Checks live or exported settings to confirm encryption is enabled on each in-scope store | Exported configuration files, encryption status reports and change records for key storage settings |
| Interview | Asks system owners, database administrators and backup operators how protection is applied and who can change it | Named owners for each store and documented procedures for enabling and verifying encryption |
| Test | Samples stores and backups, then checks whether stored data is unreadable without the keys, for example by inspecting raw storage | Test results from sampled volumes, database files and backup sets, with the method and date recorded |
| Common finding: outdated information list | Finds stores created after the list was last updated that hold sensitive data without documented protection | Evidence that the list is reviewed on a set schedule and after significant system changes |
| Common finding: partial coverage | Finds encryption enabled on primary databases but not on replicas, snapshots, log files or backups | A store-by-store coverage matrix that is reconciled against the information at rest list |
Evidence that passes an SC-28 assessment
An assessor testing SC-28 wants to see what information is stored, how it is protected, and whether the live environment still matches what the documents say. The cards below cover the artifacts that answer those questions and how to keep each one current between assessments, so the evidence does not drift from the system.
Information-at-rest inventory
This is the list of stores that hold defined information at rest: databases, file shares, object storage, volumes, caches, logs and backup repositories. SC-28 assessments start from this list because the examine procedure asks for the information requiring confidentiality and integrity protection. Keep it tied to the system boundary and the data categories defined in the system security plan. Reconcile it against the cloud account and hypervisor inventories each quarter, and whenever a new store is provisioned, so that no store exists outside the list.
Cryptographic mechanism documentation
This document names the algorithms, key lengths, modes and modules used to protect each store, and states whether the modules are FIPS-validated where the system's requirements call for it. Assessors compare it with the configuration settings to confirm the documented mechanism is the one in use. Update it when a library, cipher suite or module version changes, and record the validation status of each module version rather than the product name alone.
Configuration exports per store
Export the encryption setting for each store from the platform itself, such as volume encryption flags, database transparent encryption status and bucket default encryption. Store the exports with a timestamp and the system identifier so they can be compared across assessment periods. A screenshot of a console is weaker than a machine-readable export, because the export can be diffed against the previous quarter to show what changed.
Key management records
Key records show who created, rotated, accessed and retired each encryption key, and where the key material is held. They support the cryptographic protection enhancement by showing that keys are not stored beside the data they protect. Keep the rotation schedule, custodian assignments and access logs current, and regenerate the key inventory after every rotation event or custodian change so the record matches the key service.
Backup encryption settings
Backups copy the same information to other media and locations, so an assessor expects the same protection on them. Document the backup tool, the encryption setting for each backup target, and the key used to decrypt restores. Test a restore periodically and retain the result, since an encrypted backup that cannot be restored is an availability failure. Re-check backup targets whenever a new repository or offsite location is added.
System design document
The system design document explains where protected information resides, how data flows between components and which controls apply at each point. It gives the assessor the context needed to read the other artifacts. Review it at each significant architecture change and at the periodic control review, and confirm that its store list and data flows match the current inventory and network diagrams.
Why FedRAMP requires the cryptographic enhancement at every class
FedRAMP's Rev5 baselines require SC-28 and its enhancement SC-28(1) at Classes B, C and D, so a cloud service seeking any FedRAMP class cannot treat encryption of stored data as optional. The base control asks that defined information at rest be protected for confidentiality and, where defined, integrity. The enhancement goes further and requires that this protection use cryptographic mechanisms. FedRAMP's annual assessment rule also requires SC-28 to be tested in a FedRAMP independent assessment every year at these classes, so the encryption design is re-examined on each assessment cycle, not only at initial authorization. Confirm the current rule text in the FedRAMP Consolidated Rules and the FedRAMP Rev5 control reference before you finalize scope, because the wording and class applicability are what your assessor will use.
In practical terms, SC-28(1) means the organization can show which stored information is encrypted, which cryptographic mechanisms protect it, and how those mechanisms are configured. An assessor working from the SP 800-53A procedure will look for a list of information at rest that requires protection, the cryptographic mechanisms and their configuration documentation, the system design documentation, and the actual configuration settings. For a self-hosted platform, that means the documentation must match the running system: which volumes, database tables, object stores and backup targets are encrypted, which algorithms and key lengths are in use, and where keys live. Ask your implementation partner and your assessor to agree on this evidence list early, because a gap found at assessment usually traces back to an encryption setting nobody wrote down.
NIST SP 800-171 Rev. 3 expresses the same concepts for nonfederal systems that handle controlled unclassified information, deriving media transport and transmission and storage confidentiality requirements from SC-28 and SC-28(1). If your organization serves both FedRAMP and CUI contracts, one encryption design and one evidence set can often serve both, although each framework's assessor decides what satisfies it. Treat cryptographic key management as part of the same decision, since SC-12 and SC-13 determine how the keys that protect stored data are generated, rotated and destroyed. Confirm with your assessor which cryptographic modules and validation status they expect for your class.
What meeting SC-28 costs in money and effort
In this model your team turns on encryption features that the storage, database and backup products already provide, then documents how they are configured. The largest cost is staff time rather than licenses, and it sits mostly in inventory and evidence. Your organization owns every decision about where data sits, which keys protect it and who can reach them.
- One-time work: building the inventory of every store that holds defined information, mapping each to an encryption setting, and writing the design and configuration documents an assessor will request.
- Recurring work: checking that new volumes, snapshots and backup targets inherit encryption, reviewing key access, and refreshing evidence before each annual assessment.
- External costs: independent assessor fees, which are paid to the assessor and not to the platform vendor, plus any licensing for managed key services.
- Cost drivers: the number of data stores, how many teams create storage independently, and whether the product's encryption setting is enforced by policy or left to each administrator.
Ask the vendor which at-rest options carry the cryptographic protection enhancement and whether they are validated for your FedRAMP class. Ask your assessor for the evidence list before you estimate internal hours.
Here your engineers deploy open-source platforms in your own cloud accounts, data centers or air-gapped networks and handle encryption, key storage and evidence themselves. This moves cost from licenses into engineering time and operations capacity. The benefit is that you control the key boundary directly, and the cost is that every design choice, patch and audit artifact becomes your responsibility.
- One-time work: selecting encryption for each platform, such as server-side encryption in Nextcloud, which keeps keys on the server and does not encrypt file names or folder structure, then designing key storage and writing configuration baselines.
- Recurring work: rotating keys on a documented schedule, using transit encryption features such as versioned keys in OpenBao, reviewing key access logs, and updating procedures when platforms are upgraded.
- External costs: assessor fees and any third-party cryptographic validation you need. Open-source licenses carry no fee, but support contracts are optional and priced separately.
- Cost drivers: how many platforms hold defined information, whether key management is already mature, and how much engineering time is available for evidence collection.
Check whether the platforms you choose document their encryption limits, such as metadata that stays unencrypted, and budget engineering time to record those gaps in your risk register.
In a partner-supported model, an implementation partner prepares the systems, configuration and evidence for SC-28, while your organization keeps ownership of the controls and the risk decisions. The partner does not issue reports or certifications. An independent assessor still performs the assessment and issues the outcome. This model shifts some one-time effort into a fixed-scope engagement, which makes costs easier to compare across bids.
- One-time work: a scoped inventory of data stores, encryption design, hardening of the chosen platforms, and assembly of the evidence package for the assessor.
- Recurring work: either retained support for upgrades and evidence refresh, or internal staff taking over after handover. Confirm which one the written scope assumes.
- External costs: assessor fees, paid directly to the independent assessor, and any retainer that the partner charges for ongoing support.
- Cost drivers: the scope of the written agreement, the number of data stores, the FedRAMP class and whether the organization already has documented key management.
Ask for a quote built from a written scope with deliverables and timelines listed. Confirm that the handover includes the configuration baselines and evidence you will need for the next annual assessment, and that no part of the assessor's role is assumed by the partner.
Where SC-28 implementations usually fall short
Most SC-28 findings are not about whether encryption exists. They come from storage that was never inventoried, keys that sit next to the data, and evidence that describes a system that no longer exists. Each card below names one gap, what an assessor will look for, and the fix that closes it.
Incomplete storage inventory
The SC-28 assessment starts with a list of the information at rest that requires protection. Teams often list primary databases and file stores but omit backups, replicas, snapshots, log archives, caches and developer exports. Build the inventory from the system design documentation and from the cloud or hypervisor account, then reconcile it against what the storage services actually hold. Check that every backup target and replica appears with its owner and encryption state.
Encryption enabled without documentation
Storage encryption that is switched on but not written down fails the examine step, because the assessor needs the cryptographic mechanisms and their configuration documentation. Record the algorithm, the key management service or key store, the scope (volume, database, object or file), and the owner of each setting. Export the configuration settings as evidence rather than relying on screenshots taken during a one-off review.
Keys stored beside the data
When the encryption key sits in the same bucket, host, configuration file or database as the data it protects, encryption adds little protection against anyone who can read that location. Move key material into a dedicated key service with its own access policy, and separate the people who administer data from those who administer keys. Confirm the separation with an access review that lists both groups.
Undocumented backup encryption
Backups are frequently encrypted by a tool default that nobody recorded, or they are copied to a secondary location with a different setting. The assessor will ask for the same protection on backup media and replicas as on production storage. Document the backup tool, its encryption settings, where the decryption keys live, and who can restore. Test a restore in a controlled environment and keep the output as evidence.
Stale evidence after infrastructure changes
Evidence captured before a migration, a new storage tier or a key rotation describes a system that has changed. Assessors compare the documents against the current configuration, so an outdated diagram or settings export can produce a finding even when protection is correct. Tie the evidence to change control: when a storage component is added, retired or re-keyed, the inventory, configuration export and design document are updated in the same change record.
Unchecked secrets in code and pipelines
Storage credentials and encryption keys are sometimes committed to repositories or written into pipeline logs, which defeats protection at rest. Run secret detection on the repositories and pipelines that deploy storage so that exposed keys are found before they reach production. Keep the detection report as a dated artifact and document how each finding was rotated and closed.
SC-28 questions buyers ask before hiring help
How much does it cost to meet SC-28 before an assessment?
No supplied figure exists for SC-28 cost, so the answer depends on drivers you can size in your own environment. Cost comes from three places: the internal time to inventory where information at rest lives, the engineering time to enable and configure encryption across servers, databases, storage and backups, and the fees for any outside help and for the independent assessor. Encryption setup is largely one-time work, while key management, rotation, monitoring and evidence refresh recur every assessment cycle. Costs rise with the number of data stores, the number of key domains and whether you run FedRAMP Rev5 Classes B, C or D, where SC-28 and SC-28(1) are required and assessed every year. Ask any partner for a quote built from a written scope that lists each data store, the encryption method per store and the evidence set to be delivered.
How long does SC-28 implementation take for a typical system?
No supplied duration exists, so treat any timeline as something to confirm against your own inventory. The critical path is usually the data inventory rather than the encryption itself: you need to know every location where information at rest is stored, including backups, replicas, object storage and endpoints you manage. Enabling encryption on a system that already runs in production depends on the platform, the data volume and whether downtime or re-encryption windows are acceptable. Key management design and the documentation of cryptographic mechanisms and configuration settings add further time. Ask for a schedule that breaks the work into inventory, configuration, key management, testing and evidence collection, with dependencies and change windows named.
What does my internal team need to provide for SC-28?
Your team owns the control, so several inputs must come from inside the organization. Security or architecture staff need to name the defined information requiring confidentiality and integrity protection, since SC-28 has organization-defined parameters that you set. Platform and database owners must confirm where data at rest sits and which settings apply. Someone accountable must approve the key custody model, rotation expectations and access to keys, which ties into SC-12 and cryptographic mechanism selection under SC-13. Finally, you need system design documentation and configuration records that an assessor can read. An implementation partner can draft these, but the decisions and approvals stay with you.
Can we implement SC-28 ourselves without outside help?
Yes, an internal team can implement SC-28 if it has the skills in storage, database and key management and the time to produce evidence. The control itself is a requirement to protect the confidentiality or integrity of defined information at rest, so the decision is about method and proof rather than a single product. Teams that do it in-house usually struggle with three things: completing an accurate inventory of stores and backups, keeping key handling separate from the data it protects, and assembling configuration evidence in a form an assessor can sample. A partner can fill those gaps through a fixed-scope engagement, but only an independent assessor can test and report on the result.
What will an assessor sample when testing SC-28?
SP 800-53A assesses SC-28 through a determination statement and examine, interview and test methods. Expect the assessor to examine the cryptographic mechanisms and their configuration documentation, the list of information at rest that requires protection, the system design documentation and the system configuration settings. In practice, that means they will pick specific data stores, such as a database, an object store and a backup set, and ask you to show the configured protection, how keys are handled and whether the settings match what your documents say. They will also interview administrators about key custody and changes. Prepare a register of data stores with their encryption state, and keep configuration exports that can be traced to that register.
Can a partner certify that our system meets SC-28?
No. A partner can prepare systems, controls and evidence, but only an independent auditor, assessor or certification body issues reports or certificates. For FedRAMP, SC-28 must be covered in an independent assessment each year at the applicable classes, and that assessment is performed by an independent assessor, not by the implementation partner. Your organization remains accountable for the control, its configuration and its ongoing operation. When you select a partner, ask what they deliver (configuration, documentation, evidence packages, test support) and confirm in writing that the assessment and any attestation come from a separate party.
Which parts of SC-28 can open-source tools produce evidence for?
Open-source platforms can produce several kinds of SC-28 evidence, but you must confirm each capability against the version you run. Nextcloud's server-side encryption protects file contents at rest on local and external storage with keys kept on the server, though it does not encrypt file names or folder structure, so an assessor will want that gap documented. OpenBao's transit secrets engine encrypts and decrypts application data without storing it and supports versioned keys with rotation, which helps with key management evidence under related controls. Where a secret such as a key or token leaks into code, GitLab Community Edition's pipeline secret detection writes a report artifact in every tier. Map each tool to a named data store in your register, because a tool that encrypts one store does not cover the rest.
How DeployOpen prepares SC-28 systems and evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so encryption at rest for SC-28 is set up where the data actually lives. We prepare the systems, configuration and evidence an assessor will examine. The organization keeps ownership of its controls, and an independent assessor issues any report.
How we scope
- Written scope lists which stores, databases, backup targets and media fall under the SC-28 and SC-28(1) protections.
- We agree the organization-defined information at rest that requires confidentiality and integrity protection before any build starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing; ongoing support is available as a retainer.
How we build
- We configure encryption at rest on each in-scope platform, such as server-side encryption for file storage, and document which keys protect which data.
- We integrate a key management service such as OpenBao's transit engine so application data is encrypted with versioned keys and rotated.
- We test that stored data, backups and storage volumes are unreadable without authorized keys, and record the results for the assessor.
How we hand over
- Deliverables include configuration documentation, the cryptographic mechanisms in use, and a register of protected information stores.
- System design documentation maps where encryption occurs, which components hold keys, and what remains unencrypted, such as file names in some storage setups.
- The organization receives the evidence set in its own repositories, mapped to the SC-28 examine objects for the independent assessor.
How we support
- Retainers cover upgrades, key rotation procedures, backup verification and re-testing after significant configuration changes.
- We help the organization confirm which SC-28 evidence must be refreshed for its FedRAMP or other assessment cycle, with dates set by the assessor and program.
- Findings from testing are tracked to remediation, and the organization decides which residual risks to accept and document.
