What HIPAA actually requires for file sharing
HIPAA's Security Rule does not specify a product, platform, or file transfer method. It specifies administrative, physical, and technical safeguards for any system that creates, receives, maintains, or transmits electronic protected health information (ePHI).
For file sharing, the relevant technical safeguard is clear: ePHI transmitted over open networks must be encrypted. What counts as adequate encryption, how access is controlled, and how access is audited are the practical questions that determine whether a workflow is compliant.
Who needs HIPAA-compliant file sharing
The requirement extends well beyond healthcare providers. Any organization that handles ePHI on behalf of a covered entity is a Business Associate under HIPAA and subject to equivalent safeguards.
This includes:
- Hospitals, clinics, and individual practitioners
- Health insurance companies and managed care organizations
- Medical billing and revenue cycle management firms
- Healthcare IT vendors and SaaS providers with access to ePHI
- Legal and accounting firms advising healthcare clients when they have access to patient records
- HR departments sharing employee health information with benefits providers
Business Associates must sign a Business Associate Agreement (BAA) with covered entities and maintain the same safeguard standards.
The specific file sharing risks in healthcare
High-value breach targets. A complete electronic health record contains enough data for medical identity theft, insurance fraud, and medication manipulation. Healthcare records consistently command higher prices on criminal markets than financial data.
Complex external recipient networks. Clinical files often move among providers, specialists, insurers, legal representatives, and patients themselves. Each external transfer is a potential disclosure violation.
Long retention requirements. Adult patient records must generally be retained for six years under federal standards. A shared link active for an engagement in 2020 may still represent a live access point in 2026 if it was never revoked.
What technically adequate file sharing requires
For ePHI, four controls must be active simultaneously.
End-to-end encryption. The file must be encrypted before it leaves the originating system. Server-side encryption — where the vendor holds the keys — is not adequate, because the vendor has potential access to plaintext. Client-side encryption, where keys never leave the user's device, closes this gap — the best zero-knowledge cloud storage providers are compared here.
Access controls at the file level. Each shared file must have explicit expiry, download limits, and revocability. A patient record shared with an insurer for a claims dispute should expire when the dispute resolves, not persist indefinitely.
Unique user identification. HIPAA requires that access to ePHI be tied to a unique identifier for the accessing individual or system. Anonymous link access without recipient identification creates audit gaps.
Audit controls. Every access to a shared ePHI file must be logged with timestamps and sufficient context to reconstruct who accessed what, when, and for what purpose. This log must be producible within the timeframe required for breach investigation.
Mapping to 45 CFR §164.312 technical safeguards
The Security Rule's technical safeguards are codified at 45 CFR §164.312. For a file sharing workflow, each provision maps to a concrete control.
| Provision | Requirement | File sharing control |
|---|---|---|
| §164.312(a)(1) | Access control | Per-recipient identity, role-based permissions, automatic logoff |
| §164.312(a)(2)(iv) | Encryption and decryption of ePHI at rest | Client-side encryption before upload; no plaintext on storage |
| §164.312(b) | Audit controls | Immutable log of every read, download, and share event |
| §164.312(c)(1) | Integrity | Cryptographic verification that ePHI has not been altered in transit or storage |
| §164.312(d) | Person or entity authentication | Multi-factor authentication on every account with ePHI access |
| §164.312(e)(1) | Transmission security | TLS 1.2+ for transport; end-to-end encryption for the payload |
| §164.312(e)(2)(ii) | Encryption of ePHI in motion | Encrypted payload independent of transport encryption |
The addressable versus required distinction in §164.306(d) does not mean encryption is optional. It means a covered entity must implement encryption or document why an equivalent alternative is reasonable. In a 2024 enforcement context where breach reports routinely cite unencrypted ePHI, "we chose not to encrypt" is not a defensible position.
The Business Associate Agreement
Any platform that stores, transmits, or has potential access to ePHI must sign a BAA with the covered entity before use. The BAA is required by 45 CFR §164.504(e) and must address:
- Permitted uses and disclosures of ePHI by the Business Associate
- The Business Associate's obligation to safeguard ePHI to the same standard as the covered entity
- Reporting of any use or disclosure not permitted by the agreement
- Subcontractor obligations — flow-down of safeguard requirements to any downstream processor
- Termination conditions and return or destruction of ePHI at the end of the relationship
A vendor that refuses to sign a BAA cannot lawfully handle ePHI on behalf of a covered entity. A vendor that signs a BAA but cannot demonstrate the technical safeguards has not eliminated the legal exposure — they have only consolidated it.
A zero-knowledge architecture changes the BAA calculus. When the platform cannot decrypt customer content, the vendor's exposure to ePHI is structural rather than procedural, and the BAA documents that structural boundary rather than a set of access promises.
How common tools compare for ePHI workflows
| Tool | BAA available | Encryption model | Audit logging | Suitable for ePHI |
|---|---|---|---|---|
| Email attachment | No | TLS transport only; provider has plaintext | None on recipient side | No |
| Consumer Dropbox / Google Drive | No | Server-side; provider has keys | Limited | No |
| Dropbox Business / Google Workspace with BAA | Yes (paid tier) | Server-side; provider can access content | Account-level | Conditional — depends on configuration discipline |
| Encrypted email (S/MIME, PGP) | Not applicable to the protocol | End-to-end | Sender-side only | Partial — no expiry or revocation |
| Zero-knowledge file sharing platform | Depends on vendor | Client-side, per-file keys | Per-access link log | Conditional — requires a signed BAA |
A zero-knowledge architecture removes the vendor-access risk class, but it does not by itself satisfy HIPAA: ePHI handling still requires a signed BAA with the specific vendor and an audit log that ties each access to an identified recipient. Confirm both before storing ePHI.
A note on ShieldFive's own scope: ShieldFive provides the technical primitives this page describes — client-side encryption and per-file access control, with link expiry and revocation — under EU data residency. Share access is recorded server-side, but there is no access log you can view or export yet. ShieldFive does not sign US HIPAA Business Associate Agreements and is not a HIPAA-certified service, so it is not a turnkey answer for US covered entities that need a BAA. If your obligation is US HIPAA compliance, treat the requirements above as the checklist and confirm BAA availability with whichever vendor you choose.
The conditional case is the dangerous one. A BAA from a major cloud provider creates the legal foundation for ePHI handling, but if the underlying access controls are configured permissively — broad sharing defaults, inactive 2FA, no expiry on external links — the safeguards exist only on paper.
Risk assessment before deployment
HIPAA requires a risk analysis before implementing any system that handles ePHI. For file sharing, the relevant questions:
- What categories of ePHI will be transmitted? (clinical records, billing records, imaging, correspondence)
- Who are the recipients? (other providers, insurers, patients, legal, external vendors)
- What is the transmission channel? (internet, direct connection, patient portal)
- What are the consequences of unauthorized access for each file category?
The risk analysis drives safeguard selection. A system adequate for sharing billing records with an insurer may not meet the bar for sharing surgical records with an external specialist.
Deployment checklist
- Confirm whether your organization is a covered entity or business associate. Both require equivalent safeguards.
- Sign BAAs with any file sharing platform that handles ePHI.
- Define which file categories require encrypted sharing: clinical notes, imaging studies, lab results, billing records, insurance correspondence.
- Set expiry defaults for each category: claims documents 30 days, surgical records 7 days, patient consent forms 14 days.
- Assign a HIPAA security officer with ownership of the access audit function.
- Document the risk analysis — this is a requirement, not a recommendation.
The enforcement context
HHS Office for Civil Rights has consistently pursued enforcement actions where organizations failed to implement encryption, lacked audit controls, or permitted access beyond the minimum necessary standard. Penalties range from $100 to $50,000 per violation, with annual caps.
The organizational risk of a HIPAA violation is not only financial. Patient notification requirements, reputational damage, and operational disruption from a breach investigation are compounding consequences that far exceed most technology investment decisions.
Frequently asked questions
Is Dropbox HIPAA compliant for file sharing?
Dropbox Business signs a BAA on paid plans and supports the technical baseline for ePHI handling. Whether a given deployment is compliant depends on configuration — sharing defaults, expiry, 2FA, and audit log retention all have to be set correctly. The product's default settings are not HIPAA-aligned out of the box.
Does HIPAA require end-to-end encryption?
HIPAA does not name end-to-end encryption specifically. It requires encryption adequate for the risk profile under 45 CFR §164.312(a)(2)(iv) and §164.312(e)(2)(ii). Server-side encryption with vendor-held keys satisfies the letter of the rule when paired with strong access controls and a BAA. End-to-end encryption removes the vendor as a potential disclosure path, which is the stronger safeguard.
Can I use Gmail or Outlook to send ePHI?
Standard consumer Gmail and Outlook accounts cannot. Google Workspace and Microsoft 365 with a signed BAA can be used for ePHI when properly configured, including disabling integrations that would route content through services not covered by the BAA. The compliance failure mode is usually downstream — a forwarding rule, a third-party plugin, or an attachment scanner outside the BAA scope.
How long must HIPAA audit logs be retained?
HIPAA does not set a single retention period for audit logs. It requires that documentation of policies, procedures, and required records be retained for six years from the date of creation or last effective date under 45 CFR §164.316(b)(2). Most compliance programs treat access audit logs as falling under this six-year standard.
What happens if a Business Associate has a breach?
The Business Associate must notify the covered entity, which then has obligations to notify affected individuals, HHS, and in some cases the media under the Breach Notification Rule (45 CFR §164.400-414). The covered entity remains responsible for the breach response, but the BAA typically passes downstream costs and indemnification to the Business Associate.
Is zero-knowledge file sharing better than a HIPAA-compliant cloud provider?
Zero-knowledge architecture means the platform operator cannot read the encrypted content, even under subpoena, because no keys exist on the server side. For ePHI, this collapses an entire class of vendor-access risk that a BAA otherwise has to manage contractually. The trade-off is operational: features that require server-side processing of file contents (server-side search, malware scanning, content previews for some formats) are either disabled or run client-side.