Encryption at Rest and in Transit: What to Verify

Verify encryption at rest and in transit by checking the actual algorithm, key custody, endpoint, configuration, backup path, client behavior, and documented exception. Do not rely on a provider badge or a BAA. HHS treats encryption as an addressable Security Rule implementation decision, while NIST publications provide technical guidance for storage encryption and TLS configuration.

A defensible review records what is encrypted, where keys are held, who can decrypt, which protocols are accepted, how certificates are managed, and whether logs or backups bypass the intended boundary. Encryption reduces exposure but does not by itself establish compliance or remove incident and breach analysis.

What “at rest” covers

At-rest encryption can apply to database files, object storage, queues, backups, snapshots, temporary exports, caches, and disks. List each surface. A database may be encrypted while a debug export, support attachment, or local restore is not. The record should state algorithm, key type, service, region, owner, and evidence date.

Surface	Verify	Common gap
Database	Storage encryption and key scope	Unencrypted export or replica
Object store	Default and required encryption	Public or alternate bucket
Backups	Vault, key, and restore path	Different region or account
Queue	Message and dead-letter encryption	Payload copied to a global queue
Developer copy	Test data policy	Production records in local files

NIST SP 800-111 gives storage-encryption guidance. Use it to inform the control selection, then verify the provider setting and tenant policy. Do not claim an algorithm is present because a plan or tier advertises encryption.

What “in transit” covers

Trace every transport link: browser to edge, edge to API, service to database, worker to queue, backup to vault, support tool to service, and provider to provider. NIST TLS guidance can inform protocol and cipher choices. Record certificate issuance, expiry, trust chain, minimum version, client compatibility, and exception process.

Test the real endpoint. A browser may show HTTPS while an internal connection uses a different route. A queue client may negotiate an older protocol. A support tunnel may bypass the normal path. Capture configuration evidence without storing record content.

Use security monitoring alerts to detect failed handshakes, certificate expiry, and unexpected routes. Keep alert fields bounded and avoid request bodies.

Addressable does not mean optional without analysis

HHS guidance says the Security Rule’s encryption specification is addressable. Addressable does not mean “ignore it.” It means the regulated entity must assess whether the implementation is reasonable and appropriate, implement it when indicated, or document an equivalent alternative and the reasoning. The decision belongs in the risk analysis and should be revisited when threats or technology change.

Do not use “addressable” as a universal exemption. Record the data, threat, likelihood, impact, alternative safeguard, owner, and review date. If an exception is accepted, define compensating controls, monitoring, and a trigger for reconsideration.

Encryption is also not the only safeguard. Access authorization, audit controls, integrity, authentication, transmission security, workforce controls, incident response, and contingency planning must be considered. The least privilege and break-glass article covers identity controls that work with encryption.

Keys, rotation, and break-glass recovery

Key custody determines who can decrypt and how a system recovers after a key failure. Identify the key manager, administrators, service identity, region, rotation, backup, recovery, disablement, and destruction. Keep key permissions separate from data permissions where practical.

data service
  -> key-encryption key
  -> role-limited decrypt permission
  -> audit record
  -> rotation schedule
  -> emergency recovery with approval and expiry

Test key denial, rotation, expiry, restore, and compromise response. A key that cannot be recovered can destroy availability. A key that every operator can use destroys separation of duties. The regional backups and keys article adds location and restore checks.

Exceptions and evidence table

Control	Evidence	Exception decision
Storage encryption	Service configuration and key reference	Owner and compensating control
TLS minimum	Endpoint scan and client test	Legacy client expiry date
Backup encryption	Vault policy and restore test	Destination review
Key rotation	Schedule and execution log	Failure escalation
Support access	Role, session, and audit event	Time-bound approval

Keep a dated record for each control. Label provider feature coverage, region availability, and pricing as volatile. Remove unsupported claims from customer materials when evidence is missing.

Tenant approval checklist

Before launch, the tenant and security owner should approve the encryption scope, algorithms, key custody, transport requirements, backup policy, exceptions, and testing cadence. Privacy and legal owners should review how the controls affect breach analysis and contracts.

• At-rest surfaces inventoried.
• In-transit paths and TLS settings tested.
• Keys have owners, rotation, recovery, and destruction rules.
• Backups and restores follow the region policy.
• Break-glass access is approved, logged, and expires.
• Exceptions include risk reasoning and expiry.
• Monitoring detects drift and failure.
• Evidence has a retrieval date and next review.

Stop when encryption is asserted only by a vendor label or when key access cannot be explained. Verify the control before making a production claim.

FAQ

What is the first verification step for HIPAA encryption at rest and in transit?

Inventory every record, backup, queue, support, and transport surface. Then test the configured algorithm, key access, TLS endpoint, and exception path.

Which source or configuration detail could change this answer?

Provider service scope, key mode, region, client support, certificate policy, backup behavior, and current NIST or HHS guidance can change the evidence.

What must be approved before a production claim or outbound action?

Security should approve implementation and tests, while privacy and qualified counsel review the risk and contract implications. Customer wording must match verified scope.

References

• National Institute of Standards and Technology, SP 800-111 Guide to Storage Encryption, retrieved 2026-08-15, https://csrc.nist.gov/pubs/sp/800/111/final
• National Institute of Standards and Technology, SP 800-52 Revision 2 TLS Guidelines, retrieved 2026-08-15, https://csrc.nist.gov/pubs/sp/800/52/r2/final
• U.S. Department of Health and Human Services, Is Encryption Mandatory in the Security Rule, retrieved 2026-08-15, https://www.hhs.gov/hipaa/for-professionals/faq/2001/is-the-use-of-encryption-mandatory-in-the-security-rule/index.html