Encryption and key management: what agencies should require

Reference article · 5 min read

"Is the data encrypted?" appears on nearly every security questionnaire, and the answer is almost always yes, because nearly every system encrypts something. Yes by itself says little about who can read agency records, under what circumstances, and what happens when a key is lost or a credential is stolen.

The useful questions are narrower: which data, at which point in its life, protected by which keys, held by whom, and recoverable how.

In transit and at rest protect against different things

Encryption in transit protects data moving across a network, which in practice means TLS. What matters is which protocol versions are allowed, whether certificates are validated, and whether the protection covers internal traffic between the vendor's application tiers, not only the public website.

Encryption at rest protects data written to storage. It defends against a drive leaving the data center, a decommissioned server, a stray backup copy. It does not defend against a request that arrives through the application normally, because the system decrypts for authorized requests by design.

Full disk, database, and field level protection

Full disk or volume encryption. The storage layer encrypts everything written to it, which protects against physical loss of media. Once the system is running, every process with access reads plaintext.
Database encryption. Often called transparent data encryption. The engine encrypts its files and usually its backups. It protects files, not queries: any account the database will answer receives decrypted results.
Field or column level encryption. Chosen values, such as Social Security or driver license numbers, are encrypted separately under separate keys and access rules. This narrows what one compromised account exposes, at the cost of searching and reporting on those fields.

Many products answer "encrypted at rest" on the strength of full disk encryption alone, so ask which layer covers which data.

Who holds the keys

Provider managed keys. The vendor generates, stores, and uses the keys. Nothing for the agency to operate, and the vendor can decrypt agency data, as can anyone who compels or compromises the vendor.
Customer managed keys. The agency controls a key inside the provider's key management service, sets policy on it, sees a log of its use, and can disable it, which makes the data unreadable to the service. The provider's software still calls that key and handles plaintext while processing, so this is control over revocation, not physical exclusion.
External key stores. The key stays in a system the agency runs and the service calls out to it. Closest to genuine exclusion, and it moves availability risk to the agency, because an unreachable key service stops the application.

What differs is who can be compelled, who can make a mistake, and whether the agency can end access on its own.

Rotation, escrow, and losing keys

Most systems use envelope encryption: data is encrypted with a data key, and the data key is encrypted with a master key. Rotating the master key is fast, while re-encrypting stored data is not. When a vendor says keys rotate annually, ask what actually rotates, whether records are re-encrypted or only re-wrapped, and what triggers rotation besides the calendar.

Escrow is the counterweight. A key that exists in one place only is a single point of failure for every record it protects, so an agency holding keys needs documented backup, dual control, and a tested recovery procedure. Losing a key is not an outage, it is destruction of the data. The same mechanism used on purpose at end of contract is called crypto-shredding.

What encryption does not stop

A stolen valid credential. If an attacker signs in as a user or presents a working API key, the system decrypts on request as designed. Multi-factor authentication and session monitoring are the controls that matter here.
Authorized insiders. Staff and vendor administrators see plaintext; least privilege and access logging address this.
Copies that leave. Exports, reports, and integration feeds are often unprotected once outside the system.
Misconfiguration. Storage that is encrypted at rest and also readable by the public internet is still exposed.

Validated cryptography and compliance references

Ask whether the cryptography is validated, not merely modern. For federal and criminal justice data that means FIPS 140 validated modules listed by the Cryptographic Module Validation Program. A claim of being FIPS compliant is not the same as a module holding a certificate, so ask for the certificate number and module version, and confirm the deployed configuration runs in the module's approved mode.

The CJIS Security Policy sets encryption expectations for criminal justice information, IRS Publication 1075 covers federal tax information, and the HIPAA Security Rule covers health data. These requirements change between revisions, so confirm the current text with the official source, the state CJIS Systems Officer, or agency counsel.

What to ask, and what to require in the contract

Questions for the vendor:

Which data is encrypted at which layer, including backups, snapshots, logs, and non-production copies.
Which algorithms and key lengths, in which validated modules, with certificate numbers.
Which vendor roles can reach plaintext or keys, under what approval, and whether that access is logged.
Whether customer managed keys are available, and what happens to the service when the agency disables the key.

Terms worth placing in the agreement:

Encryption in transit and at rest using validated cryptography, with the standard named rather than called industry standard.
Agency access to key usage and administrative access logs.
Breach notification within a defined period that expressly includes compromise of keys.
Return of data in a usable format and certified destruction of data and keys at termination, flowed down to subcontractors.

HQT works with state and local agencies on security architecture, cloud configuration review, and technical evaluation of vendor claims during procurement.

Frequently asked questions

Is encryption at rest enough to protect agency data?

No. Encryption at rest protects data written to storage, which addresses lost drives, decommissioned hardware, and stray backup copies. It does not stop a request that comes through the application in the normal way, so a stolen password, session, or API key still returns readable records. Encryption belongs alongside multi-factor authentication, least privilege, and access logging rather than in place of them.

What is the difference between provider managed keys and customer managed keys?

With provider managed keys the vendor generates, stores, and uses the keys, so the vendor can decrypt agency data and so can anyone who compels or compromises the vendor. With customer managed keys the agency controls a key inside the provider's key management service, can see a log of its use, and can disable it, which makes the data unreadable to the service. The provider's software still handles plaintext while processing, so this is control over authorization and revocation rather than physical exclusion.

Does the CJIS Security Policy require FIPS validated encryption?

The CJIS Security Policy sets encryption expectations for criminal justice information and points to validated cryptography rather than to any strong looking cipher. The specific settings and thresholds change between policy revisions, so confirm the current text with the published policy and your state CJIS Systems Officer. When evaluating a product, ask for a Cryptographic Module Validation Program certificate number rather than accepting a claim of being FIPS compliant.

What happens if an agency loses an encryption key?

Data encrypted under that key becomes unrecoverable, which is data destruction rather than an outage. Agencies that hold their own keys need documented key backup, dual control for recovery, and a recovery procedure that someone has actually tested. The same effect used deliberately at the end of a contract, destroying keys so ciphertext cannot be read, is sometimes called crypto-shredding.

What should an encryption clause in a technology contract cover?

Name the standard rather than referring to industry practice, and state which data and which layers are covered, including backups, logs, and non-production copies. Include notice before material changes to the encryption or key management design, agency access to key usage and administrative access logs, and breach notification that expressly includes compromise of keys. Add return of data in a usable format and certified destruction of data and keys at termination, with the same obligations flowed down to subcontractors.