HIPAA Encryption Requirements:

Where the standard actually lives

NIST Special Publication 800-111 governs encryption for data at rest. SP 800-52 Rev. 2 governs TLS for data in transit. SP 800-57 governs key management. When OCR asks for your encryption documentation, they are looking for direct or indirect references to these documents. (HIPAA fundamentals are in our BAA vs HIPAA explainer; this post drills into the encryption clause specifically.)

Use a managed KMS or an HSM — not a config file

AWS KMS, Google Cloud KMS, and Azure Key Vault are all HIPAA-eligible under their respective cloud BAAs. They handle key storage, rotation, access policy, and audit logging out of the box. For workloads that need FIPS 140-3 Level 3, use a CloudHSM-style hardware security module. Either way, application code never sees the master key — it asks the KMS to perform the decrypt.

Envelope encryption: rotate without re-encrypting petabytes

Envelope encryption uses two layers: a data encryption key (DEK) that encrypts the data, and a key encryption key (KEK) that encrypts the DEK. The KEK lives in the KMS; the encrypted DEK lives next to the ciphertext. To rotate, you re-encrypt the DEK with the new KEK — the underlying data does not have to move. Every cloud KMS supports this pattern; use it.

# AWS KMS — generate a data key and envelope-encrypt a row
$ aws kms generate-data-key \
    --key-id alias/health-prod-phi \
    --key-spec AES_256

# Returns: Plaintext (use, then discard) and CiphertextBlob (store)
# Decrypt path: aws kms decrypt --ciphertext-blob fileb://dek.bin

Customer-managed keys (BYOK) when required by contract

Some healthcare customers — particularly large health systems and government clients — contractually require that they own the master key. BYOK (Bring Your Own Key) lets them import a key generated on their own HSM into your KMS. Decryption still happens server-side, but the customer can revoke the key to render their data unreadable. AWS, GCP, and Azure all support BYOK on their KMS tiers.

Rotation policy you can actually defend

Rotate KEKs at least annually; 90 days is the modern norm for high-sensitivity workloads. Automatic rotation (KMS-managed) is fine for most cases. Document the cadence in your key management policy. The single most common audit finding in this area is "you say you rotate every 90 days, but the KMS console shows the master key has not changed in 2 years." Don't be that team.

A reference shape that passes audit

# Postgres / RDS — column-level for high-sensitivity PHI
CREATE EXTENSION pgcrypto;

CREATE TABLE patient (
  id            uuid PRIMARY KEY,
  mrn_encrypted bytea NOT NULL,       -- AES-256 via KMS DEK
  dek_ciphertext bytea NOT NULL,      -- KEK-wrapped DEK
  -- Disk encryption (RDS + KMS) sits underneath all of this
  ...
);

# At read time: KMS.Decrypt(dek_ciphertext) -> plaintext DEK,
# then AES-decrypt mrn_encrypted with DEK in app memory.

Mistake 1: Assuming disk encryption covers everything

Server-side encryption on RDS or S3 protects against the "someone steals the disk" threat. It does nothing for the realistic threats — credential leaks, SQL injection, over-privileged service accounts. For sensitive PHI fields, add application-level encryption that requires a separate KMS call to decrypt.

Mistake 2: Keys in environment variables or source control

A master key checked into a private git repo is still a finding. Worse, the moment any developer's laptop is compromised, every encrypted value in your stack is now plaintext to the attacker. Use a KMS. Always.

Mistake 3: Logging plaintext PHI in error messages

A try/except that logs the exception message, plus an SQL error that includes the queried PHI row, equals plaintext PHI in CloudWatch. Sanitize before logging. Treat your observability pipeline as PHI-eligible infrastructure or scrub at the source.

Mistake 4: Forgetting backups and replicas

The primary database is encrypted. The nightly backup that lands in a different account is not. The read replica that powers analytics is not. Audit every place PHI flows downstream, not just the front-line store. This overlaps with what we cover in HIPAA audit logging — the audit log itself often becomes the leak.

Mistake 5: Manual rotation that never actually happens

"We rotate keys every 90 days" is a policy until it is a ticket nobody picks up. Use the KMS-managed automatic rotation, and verify the rotation date in the console at least quarterly. Auditors check the console, not the policy doc.

Mistake 6: Trusting library defaults without reading the docs

Some popular libraries default to AES-128, ECB mode, or PKCS1v1.5 padding — all weaker than what HIPAA-grade work needs. Read the docs for every crypto primitive you call. Better, prefer high-level libraries (libsodium, AWS Encryption SDK) that make safe defaults the only path.