HIPAA-Compliant Document Storage and File Sharing
Is OneDrive HIPAA compliant? What actually makes document storage and file sharing HIPAA-compliant — BAAs, configuration, and the mistakes that void both.
“Is OneDrive HIPAA compliant?” is the wrong question, asked thousands of times a month.
No storage product is HIPAA compliant on its own, and none can be. Compliance is a property of how you contract for, configure, and use a system — which means the same OneDrive tenant can be compliant in one practice and a violation waiting to be discovered in the practice next door.
Here is what actually determines which one you are.
Key takeaways
- No product is “HIPAA compliant” by itself. Vendors offer HIPAA-capable services; compliance is contract plus configuration plus behaviour.
- A BAA is necessary and nowhere near sufficient. Most failures we find happen in tenants that have a perfectly valid BAA.
- Under the 2026 HIPAA Security Rule, encryption is mandatory, not addressable. So is MFA.
- Anonymous sharing links are the single most common failure. Disable them at tenant level rather than training against them.
- Retention has two separate clocks — Florida medical record retention and the HIPAA six-year documentation requirement — and they are frequently confused.
The four things that make storage HIPAA-compliant
1. A Business Associate Agreement
Any vendor storing, processing, or transmitting PHI on your behalf is a business associate and needs a signed BAA. Microsoft and Google both offer them for their business tiers. Consumer accounts are never covered — a personal Gmail or a free Dropbox is outside the framework entirely, regardless of how careful the user is.
The subtlety people miss: BAA coverage is service-by-service, not account-wide. A covered Workspace or Microsoft 365 tenant can still include services that fall outside the BAA. Using one of those with PHI puts you outside compliance while every other part of the tenant looks fine.
2. Encryption at rest and in transit
The 2026 HIPAA Security Rule moved encryption from “addressable” to required, which removed the documented-justification escape hatch practices had been relying on. Both major platforms encrypt at rest by default and enforce TLS in transit, so this element is usually satisfied — provided nothing is being exported to unencrypted local storage, which is where it commonly breaks.
3. Access controls with unique user identification
Every person needs their own account. Shared logins — the front desk password everyone knows — defeat the entire audit model, because an access record that says “frontdesk” tells you nothing about who actually opened a chart.
Access should also be scoped to role. Minimum necessary is a HIPAA principle, not a nice-to-have, and “everyone can see everything” is difficult to defend when someone asks why a billing clerk could reach clinical notes.
4. Audit logging with real retention
After any incident, the question is always the same: what was actually accessed?
A practice that can answer precisely is in a completely different position from one that can only say it does not know. Undeterminable scope tends to force notification of everyone potentially affected — which is far more expensive, and far more damaging, than notifying the people genuinely involved.
Logging has to be enabled, retained long enough to be useful, and reviewed occasionally. Default retention on some tiers is shorter than the window in which breaches are typically discovered.
Not sure whether your current setup would survive that question? Our healthcare IT team runs configuration reviews against the 2026 Security Rule and produces a written findings document — yours whether or not you engage us.
Is OneDrive HIPAA compliant? Is Google Drive?
Both can be. Neither is by default.
| Requirement | Microsoft 365 / OneDrive | Google Workspace / Drive |
|---|---|---|
| BAA available | Yes, business and enterprise plans | Yes, covering core services |
| Consumer accounts covered | No | No |
| Encryption at rest and in transit | Yes, by default | Yes, by default |
| Anonymous link sharing | On by default — disable it | On by default — disable it |
| Audit logging | Available; check retention on your tier | Available; check retention on your tier |
| MFA | Available; must be enforced | Available; must be enforced |
The pattern is identical for both: the platform gives you the capability, the default configuration is tuned for convenience rather than compliance, and the gap between those two is where practices get hurt.
The failure we find most often
Anonymous sharing links.
Someone needs to get records to an outside party quickly. They use “anyone with the link” because it works immediately and involves no back-and-forth about accounts. The recipient gets the file, the problem is solved, everyone moves on.
The link, however, does not expire. It requires no authentication. It can be forwarded to anyone. It will not appear in a permissions review of the folder, because it is not a permission granted to a person. Months later, nobody remembers it exists.
Fix it technically, not through training. Disable anonymous link creation at the tenant level so the option is not offered. Then provide the alternative that works — a secure share to an authenticated recipient — so nobody has to improvise under pressure. Controls that depend on busy people remembering a rule fail on the day they are most needed.
Sending records: portal, not attachment
Encrypted email addresses transmission, but attachments have a structural problem: you cannot take them back. A misdirected message is gone, and misdirected email remains one of the most common causes of reportable healthcare breaches.
The defensible pattern is a link to access-controlled storage or a secure portal. The recipient authenticates, the access is logged, and permission can be revoked if the wrong person receives it. It is marginally less convenient and dramatically more defensible.
Retention: two clocks, frequently confused
- Medical records. Florida requires licensed physicians to retain records for at least five years from last patient contact, with longer periods for minors and different rules for hospitals and other facility types. Verify against current statute and your specific licensure.
- HIPAA documentation. A separate six-year requirement covering policies, procedures, risk analyses, and BAAs — not the records themselves.
These get conflated constantly, and the failure mode runs both directions: practices deleting records too early, and practices keeping everything forever, which quietly expands the blast radius of any future breach.
Your storage configuration should implement both clocks deliberately rather than by accident.
A short self-check
Answer these about your current setup:
- Do you have a signed BAA with every vendor that touches PHI, including the ones nobody thinks of as vendors?
- Is anonymous link sharing disabled at tenant level, not merely discouraged?
- Does every person have a unique account, with no shared logins anywhere?
- Is MFA enforced on every account that can reach PHI?
- If you were breached tomorrow, could you determine exactly which records were accessed?
- Do you know your audit log retention period without looking it up?
A “no” or an “I’d have to check” on any of these is worth resolving before someone else asks the question in a less comfortable setting.
Where to start
Most practices we assess have the right products and the wrong configuration. That is genuinely good news: the expensive part — licensing a platform that supports compliance — is usually already done, and what remains is settings, documentation, and a few habits.
We run configuration reviews for Florida practices against the 2026 Security Rule, covering storage, sharing, email, access control, and logging. You get a written findings document with each gap and what it takes to close it.
If you cannot answer question five, start there. Book a HIPAA configuration review →
Related reading: HIPAA encryption requirements in 2026 · HIPAA BAA requirements and vendor verification · the complete healthcare IT compliance guide


