Encryption is one of the most discussed safeguards in HIPAA compliance. It appears in the Security Rule as an addressable implementation specification, yet it plays an outsized role in breach response because of the way the Breach Notification Rule treats secured data.
Where encryption appears
The Security Rule references encryption in two places among the technical safeguards:
- Access control - encryption and decryption of ePHI (addressable).
- Transmission security - encryption of ePHI in transit where appropriate (addressable).
Because these are addressable, an organization must evaluate whether encryption is reasonable and appropriate. If it is, the organization implements it. If not, it must implement an equivalent alternative or document why neither is appropriate. In most modern environments, encryption is both feasible and expected, so failing to encrypt usually requires strong justification.
The breach safe harbor
The most compelling reason to encrypt is the breach safe harbor. The Breach Notification Rule applies to unsecured PHI. HHS guidance specifies that PHI is rendered secured, and therefore generally outside breach notification obligations, when it is encrypted using methods consistent with NIST guidance, or properly destroyed. In practical terms, a lost laptop with properly encrypted ePHI is far less likely to trigger breach reporting than an unencrypted one.
Data at rest vs. data in transit
| State | Typical measures |
|---|---|
| At rest | Full-disk encryption on laptops and mobile devices; encrypted databases, backups, and storage volumes. |
| In transit | TLS for web and email gateways; VPNs or secure tunnels for remote access; encrypted file transfer. |
Following recognized standards
HHS points to NIST publications for what counts as adequate encryption. Using current, well-vetted algorithms and key lengths, and managing keys securely, matters as much as turning encryption on. Outdated protocols or weak ciphers can leave data effectively unprotected even when encryption is nominally in place.
Beyond the minimum
Encryption is not a complete security program. It protects confidentiality but does little against an attacker who obtains valid credentials, and it does not by itself ensure availability or integrity. Treat encryption as one layer alongside access controls, audit logging, patching, and backups.
Practical checklist
- Encrypt all portable devices and removable media that may hold ePHI.
- Enforce TLS for data in transit, including email containing PHI.
- Encrypt backups and verify you can restore from them.
- Manage and protect encryption keys separately from the data.
- Document your encryption decisions, especially any addressable specification you choose not to implement.
Key management is the hard part
Turning encryption on is straightforward; managing keys well is where programs succeed or fail. If keys are stored next to the data they protect, written into source code, shared informally, or never rotated, the encryption may offer little real protection and may not satisfy the breach safe harbor. Sound key management means generating strong keys, restricting who can access them, storing them separately from the encrypted data, rotating them on a defined schedule, and planning for secure recovery so that encrypted backups remain usable. Many organizations rely on dedicated key management services or hardware security modules to handle this consistently. Documenting these practices is part of demonstrating that encryption was implemented in a way recognized standards would accept.
Encryption and de-identification are different tools
It is worth distinguishing encryption from de-identification, because they are sometimes confused. Encrypted PHI is still PHI: it remains identifiable to anyone with the key, and the Privacy and Security Rules continue to apply. De-identification, by contrast, removes or obscures identifiers so the data is no longer PHI at all. Encryption protects confidentiality while keeping data fully usable for care and operations; de-identification supports uses like research and analytics where identity is not needed. Choosing the right tool depends on whether you still need to connect the data to a specific person.
Because proposed updates to the Security Rule would, if finalized, place greater emphasis on encryption, organizations that already encrypt broadly are better positioned for whatever the final rule requires.