ePHI that should be encrypted at rest.
164.312(a)(2)(iv) (encryption and decryption) is the HIPAA Security Rule's addressable specification for encrypting electronic protected health information (ePHI). Addressable means you implement it where it is reasonable and appropriate, or document why not and put an equivalent safeguard in place. In practice, for most systems holding ePHI, that means encryption at rest, and it is decided by how your stores are provisioned in code.
The shapes the same control failure takes.
Encryption at rest weakens when a store of ePHI ships, or is changed, without it. The recurring shapes:
A new ePHI store has no encryption
A database, bucket, or volume that will hold ePHI is provisioned with encryption at rest off and no documented alternative safeguard.
An encryption config is removed
A server-side encryption or key configuration on an ePHI store is deleted in a cleanup, on the assumption the default is fine.
ePHI lands somewhere unprotected
ePHI starts being written to a cache, log, temp file, or export that is not encrypted, spreading it into an unprotected store.
A backup or export is unencrypted
A backup or data export of ePHI is created with no encryption, so a copy sits unprotected outside the main store.
Key handling makes the encryption ineffective
Encryption is nominally on but the key is mishandled (hardcoded, shared too widely), so the protection it is supposed to provide does not hold.
Encryption at rest, turned off on a patient database.
A Postgres database holds patient records. To simplify a restore from an unencrypted snapshot, a change flips the instance to storage_encrypted = false. The restore gets easier, and the patient records now sit unencrypted at rest (an RDS instance is not encrypted by default).
resource "aws_db_instance" "patient_records" { engine = "postgres"- storage_encrypted = true+ storage_encrypted = false}This turns off encryption at rest on a database holding patient records (ePHI). 164.312(a)(2)(iv) is the addressable specification for encrypting ePHI, so disabling it without a documented equivalent safeguard leaves ePHI unencrypted at rest. Keep storage_encrypted on, or document why an equivalent measure is in place.
Encryption of ePHI is checked at the store, and at the decision.
A HIPAA review checks how ePHI is protected at rest: whether stores are encrypted, and, because the specification is addressable, whether any decision not to encrypt was assessed and documented with an equivalent safeguard. A change that turned encryption off, or stood up an ePHI store without it, is the gap behind that, and it is visible in the diff to the infrastructure or storage config.
A review, not a HIPAA program.
heygrc flags changes that touch a HIPAA technical safeguard and cites the CFR reference so the fix happens in the pull request. It does not perform your risk analysis or document your addressable-specification decisions. It catches the moment a store of ePHI loses, or never had, encryption at rest, at the diff. heygrc is in early access.