HIPAA Security Rule: Encryption and ePHI Safeguards

Introduction

In 2023, HHS OCR investigated 867 large healthcare data breaches affecting 500 or more individuals each. Those investigations resulted in USD 4.18 million in settlements in that year alone. The common thread across the majority of large breaches: unencrypted ePHI on a stolen laptop, an unencrypted backup drive, or a misconfigured cloud storage bucket. Understanding encryption at rest vs in transit is essential for HIPAA compliance.

The HIPAA Security Rule at 45 CFR Part 164, Subpart C, has been in force since 2005. It requires every covered entity — hospitals, physician practices, health plans, and healthcare clearinghouses — and every business associate to implement administrative, physical, and technical safeguards for electronic protected health information. The technical safeguards under 45 CFR § 164.312 are where encryption, access control, and audit logging live.

The word “addressable” in the Security Rule has been consistently misread as “optional.” It is not. HHS has explicitly stated in guidance that addressable specifications require a risk-based analysis: if the safeguard is reasonable and appropriate, you must implement it. In virtually every case involving storage or transmission of ePHI, encryption is the reasonable and appropriate answer. Organizations that have argued otherwise have found themselves in enforcement proceedings.

This article maps the Security Rule’s technical safeguard specifications to the controls your organization must implement, with precise 45 CFR citations and the evidence your compliance officer needs to document.

What Is the HIPAA Security Rule?

The HIPAA Security Rule (45 CFR Part 164, Subpart C, §§ 164.302–164.318) applies to covered entities and their business associates. It establishes three categories of safeguards:

• Administrative Safeguards (§ 164.308): Security management process, assigned security responsibility, workforce security, information access management, security awareness training, security incident procedures, contingency plan, evaluation, and business associate contracts.
• Physical Safeguards (§ 164.310): Facility access controls, workstation use, workstation security, and device and media controls.
• Technical Safeguards (§ 164.312): Access control, audit controls, integrity controls, authentication, and transmission security.

Required vs Addressable Specifications:

• Required: Must be implemented as stated; no flexibility in whether to implement.
• Addressable: Must conduct a risk assessment. If reasonable and appropriate given your size, complexity, and risk environment: implement it. If not, document why and implement an equivalent alternative.

HHS guidance is explicit: “An addressable implementation specification is not optional.” The determination is context-dependent, but rejecting encryption without documented justification and an equivalent alternative constitutes a HIPAA violation.

How HIPAA Technical Safeguards Work

45 CFR § 164.312(a) — Access Control (Required)

The access control standard requires implementing technical policies and procedures that allow only authorized persons or software programs to access ePHI. Four implementation specifications follow:

• Unique User Identification (Required): Assign a unique name or number to each user for tracking identity — shared accounts are prohibited.
• Emergency Access Procedure (Required): Document procedures for obtaining access to ePHI during an emergency when normal access controls cannot be used.
• Automatic Logoff (Addressable): Implement electronic session termination after a period of inactivity.
• Encryption and Decryption (Addressable): Implement a mechanism to encrypt and decrypt ePHI.

This is the primary location of the ePHI-at-rest encryption requirement. HHS guidance at 45 CFR § 164.312(a)(2)(iv) specifies that for data at rest, NIST-validated encryption using algorithms meeting FIPS 140-2 or higher qualifies. In practice, AES-128 is the minimum — AES-256 is the recommended standard.

45 CFR § 164.312(b) — Audit Controls (Required)

Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems containing or using ePHI. This is a required specification — there is no addressable alternative. Every access, modification, and deletion of ePHI must be logged, and logs must be reviewed.

45 CFR § 164.312(c) — Integrity (Addressable)

Implement policies and procedures to protect ePHI from improper alteration or destruction. Includes authentication mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

45 CFR § 164.312(d) — Person or Entity Authentication (Required)

Implement procedures to verify that a person or entity seeking access to ePHI is who they claim to be. This drives the requirement for strong authentication — passwords alone are increasingly insufficient, and HHS has pointed to multi-factor authentication as the current standard of care.

45 CFR § 164.312(e) — Transmission Security

The transmission security standard requires technical security measures to guard against unauthorized access to ePHI transmitted over electronic communications networks. Two specifications:

• Integrity Controls (Addressable): Implement security measures to ensure electronically transmitted ePHI is not improperly modified without detection.
• Encryption (Addressable): Implement a mechanism to encrypt ePHI whenever deemed appropriate.

HHS guidance explicitly states that encryption during transmission should be used whenever ePHI is transmitted over an open network (the internet, email, SMS). TLS 1.2 minimum — TLS 1.3 preferred.

VIDEO · READY 16:9

PLAY

HIPAA Security Rule Explained

HIPAA Security Rule Compliance Checklist

Use this checklist to prepare for an HHS OCR investigation, a HIPAA audit, or a BAA due diligence review. Every item cites the relevant 45 CFR section.

Administrative Safeguards (45 CFR § 164.308)

1. Security Risk Analysis completed and documented — covers all ePHI regardless of format or location (§ 164.308(a)(1)(ii)(A)) — REQUIRED
2. Risk Management Plan: documented mitigation for all risks identified in the risk analysis (§ 164.308(a)(1)(ii)(B)) — REQUIRED
3. Assigned Security Responsibility: one person named as HIPAA Security Officer (§ 164.308(a)(2)) — REQUIRED
4. Workforce Training: all workforce members with access to ePHI receive periodic security awareness training (§ 164.308(a)(5)) — ADDRESSABLE
5. Security Incident Procedures: documented process for identifying, responding to, and mitigating security incidents (§ 164.308(a)(6)) — REQUIRED
6. Contingency Plan: disaster recovery plan for systems containing ePHI, tested annually (§ 164.308(a)(7)) — REQUIRED
7. Business Associate Agreements: BAA signed with every business associate before sharing ePHI (§ 164.308(b)(1)) — REQUIRED

Physical Safeguards (45 CFR § 164.310)

1. Facility access controls: documented procedures for physical access to locations containing ePHI systems (§ 164.310(a)(1)) — ADDRESSABLE
2. Workstation use: documented policy on allowable uses of workstations that access ePHI (§ 164.310(b)) — REQUIRED
3. Device and media controls: inventory of hardware and media containing ePHI; documented disposal procedure using NIST SP 800-88 methods (§ 164.310(d)(1)) — REQUIRED
4. Encryption of portable media: laptops, USB drives, and mobile devices containing ePHI encrypted (§ 164.310(d)(2)(iv)) — ADDRESSABLE (effectively required in practice)

Technical Safeguards (45 CFR § 164.312) — Core

1. Unique user accounts: no shared or generic accounts for ePHI systems (§ 164.312(a)(2)(i)) — REQUIRED
2. Automatic logoff: workstation and session timeout after inactivity configured (§ 164.312(a)(2)(iii)) — ADDRESSABLE
3. Encryption at rest: all ePHI stored in databases, file systems, and backups encrypted with AES-128 minimum, AES-256 recommended (§ 164.312(a)(2)(iv)) — ADDRESSABLE (effectively required)
4. Audit logs: all access to ePHI logged with user, timestamp, action, and system (§ 164.312(b)) — REQUIRED
5. Log retention: audit logs retained minimum 6 years per HIPAA record retention rule (§ 164.530(j))
6. Integrity: mechanisms in place to detect unauthorized alteration of ePHI (§ 164.312(c)(2)) — ADDRESSABLE
7. Person authentication: MFA implemented for all access to systems containing ePHI (§ 164.312(d)) — REQUIRED
8. Transmission encryption: TLS 1.2 minimum on all connections transmitting ePHI over any open network (§ 164.312(e)(2)(ii)) — ADDRESSABLE (required whenever ePHI is on an open network)
9. Email: ePHI in email transmitted only over encrypted connections (TLS) — unencrypted email transmission of ePHI is a violation

Breach Safe Harbor Documentation

1. Encryption standard documented: confirm algorithm (AES-256), key length, and FIPS 140-2/3 validation of cryptographic module
2. Key management: documented separation of ePHI storage from encryption key storage
3. Lost device protocol: procedure documented for confirming encryption was enabled and key was not compromised before safe harbor claim
4. Breach risk assessment: four-factor test documented for any ePHI incident (nature, identity of person, whether ePHI was actually acquired, extent of mitigation)

Evidence Package for OCR Investigation

1. Current risk analysis document (not older than 12 months)
2. System inventory listing all ePHI systems and their encryption status
3. BAAs with all business associates, current and not expired
4. Workforce training records (name, date, training content, attestation)
5. Audit log samples showing access to ePHI
6. Incident response records for any security events in the past 6 years

HIPAA Security Rule vs GDPR Technical Controls

The most operationally significant difference is breach notification timing: HIPAA allows 60 days to notify HHS OCR after discovery, while GDPR mandates 72 hours for supervisory authority notification. Organizations subject to both (healthcare companies processing EU patient data) must comply with the 72-hour GDPR timeline.

Real-World Use Cases

Telehealth platforms: A video consultation platform transmitting ePHI (video, audio, chat, and diagnostic data) must use TLS 1.2 minimum for all transmission (§ 164.312(e)). The platform must also implement access controls preventing one patient’s ePHI from being visible to another’s provider session. Each security decision must be documented in the risk analysis.

Cloud EHR vendors: A cloud-based electronic health record system acting as a business associate must sign a BAA with every covered entity customer and implement HIPAA Security Rule controls across its infrastructure. The vendor’s SOC 2 Type II report does not substitute for HIPAA compliance — BAA obligations are legally distinct from SOC 2 attestations and must be independently satisfied.

Lost laptop scenario: A physician’s laptop containing patient appointment records and diagnosis notes is stolen from a car. If the laptop is encrypted with AES-256 and the decryption key was not stored on the device, the incident triggers the breach safe harbor under 45 CFR § 164.402: the ePHI is rendered unusable, unreadable, and indecipherable. No HHS OCR notification is required, and no patient notification is required. Without encryption, the same incident mandates notification to HHS OCR within 60 days, notification to all affected patients, and — if the breach affects 500 or more patients in a state — notification to a prominent media outlet.

Common Mistakes to Avoid

Treating “addressable” as “optional.” HHS has stated explicitly in multiple guidance documents and enforcement settlements that “addressable” requires a documented risk-based determination, not a free pass. Organizations that have skipped encryption of ePHI with no documented justification or equivalent alternative have been found in violation and faced seven-figure settlements. Document your risk analysis for each addressable specification.

Failing to include cloud storage in the risk analysis. ePHI in Amazon S3, Google Drive, Microsoft OneDrive, or any cloud service used by your organization is subject to HIPAA. Many organizations encrypt their on-premises databases but store ePHI in unencrypted cloud buckets used by clinical staff for file sharing. The 2023 breach report consistently identified misconfigured cloud storage as a top source of ePHI exposure.

No BAA with subprocessors. If your cloud EHR vendor uses AWS as its infrastructure provider, does AWS have a BAA with your EHR vendor? Does your EHR vendor have a BAA with you? The BAA chain must extend through every entity that touches ePHI. AWS, Google Cloud, and Azure all offer BAA-eligible services for covered entities and business associates — but you must execute the BAA; it is not automatic.

Insufficient audit log review. § 164.312(b) is a required specification. Enabling audit logging is insufficient — you must review logs. OCR investigators ask for both the log configuration and evidence of regular review. A SIEM with automated alerts for anomalous ePHI access patterns satisfies both the technical implementation and the review requirement.

Getting Started

Start with a comprehensive ePHI inventory. You cannot protect ePHI you do not know about. Survey every application, database, backup system, file share, email system, and cloud service. For each, confirm the encryption status of ePHI at rest and verify TLS is configured for any connections that transmit ePHI.

Conduct or update your Security Risk Analysis. NIST SP 800-66 Rev 2 (2024) provides specific guidance on implementing the HIPAA Security Rule and includes a risk analysis methodology. The risk analysis is the foundation of your entire compliance program — every addressable specification determination flows from it.

Review your business associate relationships. Confirm a current BAA is executed with every vendor, cloud provider, IT support firm, and analytics partner that touches ePHI. Request evidence of their HIPAA Security Rule controls — SOC 2 Type II reports, ISO 27001 certificates, or their own HIPAA compliance attestation.

For the technical encryption standards that satisfy HIPAA’s addressable specifications, see AES-256-GCM explained: authenticated encryption without the jargon. For the key management infrastructure behind encrypted ePHI storage, read hardware security modules: HSM vs KMS explained.