What Does the HIPAA Security Rule Require for File Encryption and Access Controls?

There is a sentence in the HIPAA Security Rule that gets misread more often than almost any other provision in healthcare compliance: the one that calls encryption "addressable" rather than "required."

Healthcare organizations read "addressable" and hear "optional." The Office for Civil Rights does not. Since 2009, OCR has referenced unencrypted PHI in the majority of its significant enforcement settlements, including cases where the covered entity had reasonable security in other areas. The classification of encryption as "addressable" means organizations must formally assess it and document their reasoning. It does not mean they can skip it.

Understanding what the HIPAA Security Rule actually requires for file encryption and access controls is the difference between a compliance program that holds up under audit and one that generates expensive surprises.

What Is the HIPAA Security Rule and Who Does It Apply To?

The HIPAA Security Rule (45 CFR Part 164, Subpart C) establishes national standards for protecting electronic protected health information (ePHI). It applies to covered entities — healthcare providers, health plans, and healthcare clearinghouses — and to business associates who handle ePHI on their behalf.

Where the Privacy Rule covers all PHI in any form, the Security Rule covers only ePHI: protected health information that is created, received, maintained, or transmitted electronically. In 2026, that is most PHI. Files, emails, exports from EHRs, billing records, research data, claims documentation — all ePHI under the Security Rule's scope.

The rule is organized into three categories of safeguards: administrative, physical, and technical. Technical safeguards — the category that covers encryption, access controls, and audit logging — are where most file security obligations live.

What Are the HIPAA Security Rule's Technical Safeguard Requirements?

The technical safeguards are defined in 45 CFR § 164.312 and cover five areas. Two classifications apply to each requirement: "required" means the control must be implemented; "addressable" means it must be assessed, and if not implemented, the decision must be documented with an equivalent alternative.

Access Control (§ 164.312(a)(1)) — Required 

Covered entities must implement technical policies and procedures that allow only authorized persons or software programs to access ePHI. Four implementation specifications follow:

• Unique user identification (required): Each user must have a unique identifier to track their access activity.
• Emergency access procedure (required): Procedures for obtaining ePHI access during an emergency.
• Automatic logoff (addressable): Terminate electronic sessions after a defined period of inactivity.
• Encryption and decryption (addressable): Encrypt and decrypt ePHI where appropriate.

Audit Controls (§ 164.312(b)) — Required 

Implement hardware, software, and procedural mechanisms to record and examine activity in systems that contain or use ePHI. There are no sub-specifications — this is a single required control. What it means operationally: systems holding ePHI must generate logs of who accessed what, and those logs must be reviewable.

Integrity Controls (§ 164.312(c)(1)) — Required 

Implement security measures to ensure ePHI is not improperly altered or destroyed. One addressable sub-specification covers electronic mechanisms to corroborate that ePHI has not been altered or destroyed.

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

Verify that a person or entity seeking access is who they claim to be. No sub-specifications. The standard requires authentication before ePHI access.

Transmission Security (§ 164.312(e)(1)) — Required 

Guard against unauthorized access to ePHI transmitted over an electronic communications network. Two sub-specifications: integrity controls (addressable) and encryption (addressable).

Does HIPAA Actually Require Encryption for PHI Files?

Technically, no — encryption is listed as "addressable" under both § 164.312(a)(1) and § 164.312(e)(1). But that framing is more misleading than helpful.

"Addressable" under HIPAA means organizations must assess whether the implementation specification is reasonable and appropriate for their environment. If it is, they must implement it. If they determine it is not reasonable and appropriate, they must document that determination and implement an equivalent alternative measure. The decision must be in writing, tied to their risk analysis, and defensible under scrutiny.

OCR's enforcement record tells a consistent story: organizations that store or transmit ePHI in unencrypted form and suffer a breach face significant penalties. The 2024 Gulf Coast Pain Consultants settlement ($1.19 million) involved unencrypted EMR access. The 2023 Massachusetts Eye and Ear settlement ($1.5 million) involved a failure to encrypt ePHI on portable devices. The 2022 Oklahoma State University Medical Authority settlement ($875,000) cited the same pattern.

OCR's 2024 update to the Security Rule — published in the Federal Register in December 2024 — explicitly elevates encryption from "addressable" to closer to de facto required for most healthcare organizations, removing some of the ambiguity that had allowed organizations to document their way around implementation.

The practical standard for any healthcare organization with genuine ePHI exposure: encrypt ePHI files in storage and transmission. Document the decision either way. Do not rely on the "addressable" classification as permission to skip it.

What Access Control Requirements Does HIPAA Set for PHI Files?

The access control requirements under § 164.312(a)(1) establish the principle but leave implementation flexibility. What OCR and HIPAA guidance consistently expect in practice:

User-level traceability: Shared accounts or generic logins for systems holding ePHI do not satisfy the unique user identification requirement. Every access event must be traceable to a specific individual. In file sharing environments — shared drives, collaboration platforms, portals with team-level credentials — this is a common failure point.

Least privilege: Users should only have access to the ePHI they need for their role. In practice, file sharing platforms frequently over-provision access because restricting it requires ongoing administrative work. A billing team member having read access to clinical research files is a compliance gap even if the files are in the same storage system.

Authentication before access: Per § 164.312(d), person or entity authentication is required before ePHI access. MFA is not explicitly required by HIPAA, but OCR guidance strongly recommends it, and the 2024 Security Rule update moves closer to making it a standard expectation.

Access control that follows the file: This is where most technical safeguard programs stop short. HIPAA's access control requirement applies to ePHI wherever it exists, not just within the primary system. If a PHI file is downloaded from a compliant platform to a personal device, the platform's access controls no longer apply. The file is still ePHI. The access control requirement still applies. The protection has ended.

What Does HIPAA Require for Audit Logging of PHI Access?

The audit controls requirement under § 164.312(b) is required, not addressable — there is no documented-alternative pathway. Any system that contains or uses ePHI must have mechanisms to record and examine activity.

What audit logs for ePHI access should capture:

User identity: Who accessed the file? Unique user identification, linked to an individual. 

File identity: What file or record was accessed? Including file name, type, and sensitivity classification where available. 

Timestamp: When did the access occur? Time-synchronized, with timezone. 

Access type: What action was taken — read, write, download, modify, delete? 

Outcome: Was access granted or denied?

OCR does not specify a minimum log retention period in the Security Rule, but 6 years is the standard implied by the retention requirements in the Privacy Rule for HIPAA policies and documentation. Many legal advisors recommend aligning ePHI audit log retention to that period.

Common audit log failures in healthcare environments:

• Platform-level logs that show a user opened a folder but not which files were accessed
• Logs that cover the primary EHR system but not the shared drives, email servers, or file portals where extracted PHI lives
• No logging for files that have been downloaded to endpoints
• Logs that exist but are never reviewed — satisfying the letter of the control but not its accountability purpose

Where Do Most Healthcare Organizations Fall Short on HIPAA Technical Safeguards?

The gap is almost always the same: controls exist for ePHI inside the primary system and break down at the moment the file moves.

A file in the EHR is well-governed. A radiology image exported to a PACS system, a billing file emailed to a revenue cycle vendor, a clinical note downloaded to a physician's home laptop for after-hours charting — these are all ePHI. They are all subject to the same access control and audit logging requirements. Most organizations have no technical controls that follow these files beyond the system they were exported from.

The HIPAA Security Rule's technical safeguards are written to cover ePHI broadly — "created, received, maintained, or transmitted." That scope is not limited to the EHR. It applies to every format, every location, every system that touches electronic protected health information. A compliance program built around the EHR's built-in security satisfies some of that scope. It does not satisfy all of it.

What Does File-Level Encryption Look Like for HIPAA Technical Safeguard Compliance?

File-level encryption addresses the gap left by platform-level controls: it embeds protection in the file itself, so encryption and access controls apply wherever the file travels.

Theodosian applies this at the file layer using FIPS 140-3 validated AES-256 encryption with a unique key per file, combined with context-aware access controls that evaluate every access request in real time — identity, device compliance status, location, network, and behavioral patterns — regardless of which system the file currently lives in.

For HIPAA:

Access Control (§ 164.312(a)(1)): Every file access request is evaluated against policy before decryption. Access is granted to authenticated, compliant principals under expected conditions. A physician accessing a file from an unrecognized device or location triggers step-up verification, not automatic access.

Audit Controls (§ 164.312(b)): Every access event is logged at the file layer — user identity, file identity, device, timestamp, location, network type, and outcome — regardless of which platform the file is on. Logs are exportable and cover the full lifecycle of the file, including access outside the primary healthcare system.

Transmission Security (§ 164.312(e)(1)): Files transmitted to external parties — billing vendors, specialist referrals, legal holds, research partners — carry their encryption into the recipient's environment. The encryption does not end at the boundary of your network.

In-use encryption: Files decrypt in real-time only, never writing plaintext to disk. This closes the endpoint exposure window that most platform-level encryption leaves open when a file is actively being worked on.

Bridging the Gap in Healthcare File Security

Relying on the boundary security of an EHR or a secure portal is no longer enough to satisfy regulatory expectations or to protect your organization from a catastrophic breach. When ePHI inevitably leaves your primary systems for clinical collaboration, billing, or external sharing, compliance must travel with it. By implementing file-level encryption and continuous, context-aware access policies, healthcare entities can maintain control of their security and create a flawless audit trail—no matter where the data is stored, transmitted, or opened.

FAQs: HIPAA File Protection