Protecting CJI at Rest: What SC-28 Requires

SC-28 requires protection of CJI at rest. The control is marked Existing, which means it was in place before v6.1 and remains sanctionable today under §1.4.

Most agencies with a cloud deployment believe they have satisfied it. Their provider encrypts data. The checkmark seems self-evident.

The requirement is more specific than that.

What the control actually specifies

SC-28, read with SC-13, requires that CJI stored at rest be protected using FIPS 140-3 certified cryptographic modules, or a FIPS-validated algorithm for symmetric key encryption using AES-256 with at least a 256-bit key.

The September 21, 2026 deadline matters here. FIPS 140-2 certificates are not acceptable after that date. An agency or a service provider relying on FIPS 140-2 validated modules after September 21, 2026 is out of compliance with SC-13 and by extension SC-28 on any system that stores CJI.

That is not a future concern. The date has passed.

The key custody question

The policy addresses key management directly, and the language is precise: individuals with access to the encryption keys can decrypt the stored files and therefore have access to unencrypted CJI.

That sentence changes how cloud deployments need to be evaluated. The relevant question for SC-28 compliance is not whether the provider encrypts CJI. It is who holds the decryption keys.

If a cloud provider holds the keys — which is the default in most managed cloud deployments — then personnel at that provider with key access have effective access to unencrypted CJI. That access triggers the full suite of CJIS personnel screening, Security Addendum, and training requirements for anyone at the provider who could reach those keys. A provider that has not addressed this is not a CJIS-compliant deployment regardless of what its marketing materials say about encryption.

The alternative is that the agency holds its own keys, which means the provider encrypts data the agency has already encrypted, or the agency manages key material separately from the provider. This is technically feasible, operationally complex, and uncommon in standard cloud deployments. Agencies that have chosen this path generally know it. Agencies that have not generally do not know which model they are in.

The cloud responsibility split

The Requirement Companion Document distinguishes between IaaS, PaaS, and SaaS deployments, and the SC-28 responsibility assignment differs by model. In an IaaS deployment, the agency typically retains more control over the encryption layer. In a SaaS deployment, the service provider typically manages it, which puts the key custody question squarely on the provider and the agreement between the parties.

The agreement between an agency and a cloud provider should specify: which party manages encryption, what the key management lifecycle is, what happens to keys upon contract termination, and whether the provider's encryption configuration meets the FIPS 140-3 requirement. An agreement that does not address these terms leaves the agency without the evidence it needs to demonstrate SC-28 compliance.

What an auditor is looking at

An auditor reviewing SC-28 compliance is looking for: documentation of the encryption configuration; confirmation that the cryptographic modules in use are FIPS 140-3 certified (or that the algorithm is FIPS-validated AES-256 with a 256-bit key); documentation of the key management arrangement; and, in a cloud deployment, documentation that the key access implications have been addressed for provider personnel.

Producing a cloud provider's service page describing their encryption practices is not the same thing as producing evidence your deployment satisfies the control. Those are two different documents and most agencies have only the first.

SC-28 compliance in a cloud environment requires knowing your deployment model, knowing who holds your keys, having documentation that the cryptographic configuration meets the post-September 2026 standard, and having addressed the personnel implications of key access at the provider. If any of those four is missing, the control cannot be rated complete.