HIPAA Compliant File Sharing: What It Actually Requires and Where Small Practices Get It Wrong

If you run a small healthcare or wellness practice, hipaa compliant file sharing is not a product category you shop for. It is a set of obligations you either meet or you do not, and the consequences for getting it wrong are specific and expensive. Most of what you read about this topic is vendor listicles dressed up as compliance guidance. This is a different kind of piece. We build a privacy-focused AI assistant, and in the course of that work we have had to think carefully about encrypted file transfer, access control, audit trails, and the gap between "we offer a BAA" and "your practice is actually compliant." Here is what we have learned, written for someone who does not have an IT department.

Key Takeaways

• A signed Business Associate Agreement (BAA) is the minimum threshold, not the finish line. Without one, no platform is compliant regardless of its encryption.
• The proposed HIPAA Security Rule overhaul (the first major update since 2013) has been delayed until at least July 2027, but the existing rule is actively enforced right now, with 21 OCR settlements in 2025 alone and rising penalty caps.
• Most small-practice breaches are not sophisticated attacks. They are misdirected emails, unsecured personal devices, and staff pasting patient notes into consumer AI tools that have no BAA and no data-handling guarantees.
• Compliant file sharing requires four things working together: encrypted transmission (TLS or SFTP), role-based access controls, audit logging, and a signed BAA. Miss any one and you have a gap.
• Product design matters more than product marketing. A tool that is "compliant by default" (correct settings out of the box) is worth more to a three-person practice than one that is "configurable for compliance" by someone who knows what they are doing.

What Does HIPAA Actually Require for File Sharing?

HIPAA requires that any system transmitting or storing protected health information (PHI) enforce four controls: access controls, audit logging, integrity controls, and transmission security. It also requires a signed BAA with whatever vendor touches that data. The BAA is not optional. It is not a nice-to-have. Without a BAA, no platform is HIPAA-compliant no matter how strong its encryption.

The specifics break down like this:

• Transmission security means encrypted transfer protocols. TLS 1.2+ for web-based transfers, SFTP for batch file movement. Standard FTP and unencrypted email attachments do not meet the bar.
• Access controls means role-based permissions. Not everyone in your practice should be able to open every file. The receptionist and the clinician have different roles, and the system should enforce that difference.
• Audit logging means a tamper-resistant record of who accessed what, when, and from where. If OCR shows up with questions, "I think Sarah opened it last Tuesday" is not an acceptable answer.
• Integrity controls means mechanisms that detect unauthorized alteration of PHI. Checksums, versioning, or similar.

These requirements exist under the current Security Rule, which has been in force since 2005. They are not new. They are not pending. They apply to you today.

What About the Proposed 2026 Security Rule Changes?

The proposed changes are not in effect. HHS published the Notice of Proposed Rulemaking on January 6, 2025, and the comment period closed March 7, 2025. A final rule was expected by May 2026. That date has slipped to at least July 2027, according to the Office of Management and Budget's regulatory agenda. HHS is now moving ahead with Privacy Rule changes separately, while the Security Rule overhaul waits.

The proposed rule would make several currently "addressable" requirements mandatory: multi-factor authentication, encryption at rest and in transit, network segmentation. But none of that is law yet. A lot of vendor marketing conflates "proposed" with "required," creating either false urgency or false complacency depending on which direction serves their sales cycle.

Here is what is actually true: the existing rule already requires you to perform a risk analysis, implement reasonable safeguards, and document your decisions. The word "addressable" in HIPAA does not mean "optional." It means you must either implement the control or document why an equivalent alternative is appropriate. Most small practices have done neither.

Is OCR Actually Enforcing Against Small Practices?

Yes. In 2025, OCR resolved 21 settlements and civil monetary penalties. In fall 2024, HHS launched a Risk Analysis Initiative specifically targeting enforcement of the risk-analysis provision, with seven enforcement actions announced in its first six months. State attorneys general now pursue HIPAA violations directly under HITECH Section 13410(e)(1), adding a second enforcement vector beyond OCR.

Penalty caps were adjusted effective January 28, 2026. The top tier now reaches $2,190,294 per violation category per year under OCR's enforcement discretion. That is the ceiling. Even the floor (Tier 1, lack of knowledge) starts in the tens of thousands.

Small practices are not exempt and are not overlooked. The latest report to Congress showed a 12% increase in small data breaches from 2020 to 2024, and the majority of those were unauthorized access and disclosure incidents: accidentally faxing, emailing, or mailing PHI to the wrong person. Not ransomware. Not nation-state actors. Misdirected emails.

Where Do Small Practices Actually Get Caught?

The breach that ends a small practice's compliance record is almost never dramatic. It is usually one of three things:

1. Emailing patient files from a personal account. Your clinician finishes charting at home. They email the file to themselves from their personal account so they can upload it tomorrow. That email traversed infrastructure with no BAA, no encryption guarantee, and no audit trail. Most violations stem from simple mistakes like these: using a free account with no BAA, saving records to a personal laptop, sending attachments over consumer email.

2. Sharing files through consumer-grade tools. Some large platforms can be configured for HIPAA use, but the configuration is not the default. The free tier of most services does not include a BAA. The paid tier may include one, but only if you find it, request it, and sign it. And even then, the covered entity (you) still bears responsibility for proper configuration.

3. Pasting patient notes into AI tools. This is the fast-growing category. A clinician copies a patient's intake notes into a general-purpose AI chatbot to generate a summary or a referral letter. That chatbot has no BAA. Its data may be used for model training. Its retention policies are opaque or indefinite. By 2026, "prompt leaking" is expected to become a recognized category of data breaches. General-purpose AI tools are not HIPAA compliant because they are built for general use, not regulated healthcare data, and most do not offer BAAs or the required safeguards.

What Should a Compliant File-Sharing Setup Look Like for a Small Practice?

It should look boring. Four components, each doing its job:

1. Encrypted transfer. Files in transit should be protected by TLS 1.2+ or SFTP. No exceptions, no fallbacks to unencrypted channels.
2. Role-based access. Each staff member gets permissions appropriate to their function. The billing person does not need access to clinical notes. The clinician does not need access to every patient's records, only their own panel.
3. Audit logs. Every access, download, share, and deletion is logged with a timestamp and user identity. Logs are retained long enough to satisfy OCR inquiries (the Security Rule does not specify an exact duration, but six years is the general retention standard for HIPAA documentation).
4. A signed BAA. With every vendor that touches PHI. Not just the file-sharing tool. The cloud storage provider. The email service. The fax service, if you still use one. The AI assistant, if you use one.

The hard part for a three-person practice is not understanding these requirements. It is implementing them without a full-time IT administrator. Which is why the design posture of the tool matters as much as its feature list.

Why Does "Compliant by Default" Matter More Than "Configurable for Compliance"?

Because configuration is where small practices fail. A tool that ships with open sharing permissions and expects you to lock them down is a tool that will be misconfigured. A tool that ships locked down and requires you to explicitly grant access is a tool that is harder to misuse.

The distinction matters operationally. When you read a buyer's guide comparing file-sharing tools, the checklist usually looks like: BAA available (yes/no), encryption (yes/no), audit logs (yes/no). That checklist is necessary but not sufficient. The question a small practice should ask is: if I hand this tool to my least technical staff member, what is the default state? Can they accidentally share a file publicly? Can they email a link that does not expire? Can they download PHI to an unmanaged device?

If the answers are "yes, unless you configure it otherwise," you have a compliance problem waiting for a Tuesday afternoon when someone is tired and clicks the wrong button.

How Does the BAA Actually Work?

A BAA is a contract between a covered entity (your practice) and a business associate (any vendor that creates, receives, maintains, or transmits PHI on your behalf). The BAA specifies what the vendor can and cannot do with the data, requires them to implement appropriate safeguards, and obligates them to report breaches.

A few things that are commonly misunderstood:

A BAA does not make you compliant. It makes the vendor accountable for their part. You are still responsible for your own risk analysis, your own access controls, your own staff training. The BAA creates shared responsibility, not transferred responsibility.

A BAA with a vendor that cannot actually perform is worse than no BAA at all. If you sign a BAA with a consumer tool that technically offers one but has no real access controls or audit logging, you have a piece of paper that creates a false sense of compliance. OCR will look at what you actually did, not just what you signed.

You need a BAA with every vendor in the chain. If your file-sharing tool stores data on a third-party cloud provider, that cloud provider also needs a BAA. If you use an AI tool that routes requests to a frontier model provider, the AI vendor's BAA should cover that relationship. Ask specifically about subprocessors.

What About Encryption? Is End-to-End Required?

The HIPAA Security Rule requires encryption of PHI in transit and considers encryption at rest an "addressable" safeguard (meaning you must implement it or document your equivalent alternative). The rule does not specify end-to-end encryption by name. But end-to-end or zero-knowledge encryption for file transfers is the strongest posture you can take, because it means even the vendor operating the transfer infrastructure cannot read the file contents.

For file sharing specifically, zero-knowledge encrypted transfer means the file is encrypted on your device before it leaves, and decrypted only on the recipient's device. The service provider handles routing and delivery but never has access to the plaintext. This matters because it limits your exposure if the vendor itself is breached.

We built SelinaSEND with this architecture. Files and transfers through SelinaSEND are zero-knowledge encrypted. The service routes the file; we cannot read it. This is a design decision, not a policy decision. The difference matters: a policy can be changed by an employee; an architecture cannot be changed by accident.

One thing worth being precise about: zero-knowledge encryption is achievable for file transfers in a way that it is not always achievable for other product functions. Selina's memory, for example, is encrypted at rest, but because a slice of each request reaches a frontier provider at inference, memory is not end-to-end encrypted. We are specific about this because the distinction matters for your risk analysis. A vendor that claims zero-knowledge everything, including AI inference, is either lying or not actually doing inference on your data (which means the AI is not very useful).

How Do I Evaluate Whether an AI Tool Is Safe to Use With Patient Data?

Ask five questions. Accept only specific answers.

1. Will you sign a BAA? If no, stop. If yes, read it. Look for carve-outs around AI model training.
2. Is my data used to train models? Many general-purpose AI tools use input data for model improvement by default. If patient data goes in and becomes part of a training corpus, you have a breach. The answer you need is an unambiguous no, backed by contractual language.
3. What is your data retention policy? "We delete everything immediately" is almost certainly false (operational metadata has to exist for some window for the service to function). A vendor that says "short retention window for non-content operational metadata" is being more honest than one claiming zero retention.
4. Where does inference happen? If the tool uses a frontier model provider via API, your data transits to that provider's infrastructure during inference. The vendor's BAA should cover this subprocessor relationship. If the vendor cannot tell you where inference happens, that is a red flag.
5. What access controls exist? Can you restrict which staff members use the tool? Can you audit what was submitted? Can you revoke access immediately if someone leaves the practice?

Selina is built as a privacy-focused AI assistant. Your account is protected, your content is encrypted, and files sent through SelinaSEND are zero-knowledge encrypted. We run on a stack of frontier models, routed per task, via API. We can sign a BAA. Non-content operational metadata is kept for a short retention window. We are specific about these boundaries because vague reassurances are what got the industry into its current mess.

What Does the Breach Landscape Actually Look Like Right Now?

It looks worse than last year. Healthcare organizations reported 770 HIPAA breaches in 2025, the highest annual total on record. Q1 2026 showed a 29.4% increase in individuals affected compared to the same period the previous year.

The large breaches get the headlines: ransomware, stolen databases, millions of records. But for a small practice, the relevant statistic is the small-breach trend. These are the incidents affecting fewer than 500 individuals, the ones that come from a misfaxed document, an unencrypted email, a lost USB drive. The 12% increase in small data breaches from 2020 to 2024 is your peer group's track record.

The pattern is consistent: unauthorized access and disclosure, not hacking. Someone who had access to PHI sent it somewhere it should not have gone. The fix is not a firewall. The fix is a system that makes it structurally difficult to send PHI to the wrong place.

What Is the "Encrypt Before Embed" Problem?

This is a bug class we encountered in our own engineering work, and it illustrates why building compliant systems is harder than it appears.

When an AI system processes a document, it typically converts the content into vector embeddings for search and retrieval. The naive approach: take the document, generate embeddings, store both. The problem: if you encrypt the document but store the embeddings in plaintext, the embeddings themselves are a compressed representation of the content. They are not human-readable, but they are queryable, and in some configurations they can leak semantic information about the source material.

This is the kind of vulnerability that does not show up on a compliance checklist. No auditor asks "are your vector embeddings encrypted?" because most auditors do not know what vector embeddings are. But if your system stores PHI-derived embeddings in a searchable index without encryption, you have created a side channel that technically constitutes unsecured PHI.

We caught this early and addressed it. I mention it not because it is a common attack vector today, but because it is the kind of thing that separates "we take compliance seriously" from "we checked the boxes on the form." If your AI vendor cannot explain how they handle embeddings of PHI, ask. The answer will tell you a lot about how deeply they have thought about the problem.

What Should I Do Today?

If you are a small practice sharing patient files in any digital format, here is a priority list. Not aspirational. Immediate.

1. Inventory every tool that touches PHI. Email, file sharing, fax, cloud storage, AI assistants, even your phone's messaging app if you have ever texted a patient's name. Write them down.
2. Check for BAAs. For each tool on that list, confirm you have a signed BAA. If you do not, either get one signed or stop using that tool for PHI immediately.
3. Verify encryption in transit. Every file transfer should happen over TLS 1.2+ or SFTP. If you are emailing unencrypted attachments, that is a violation today, not a violation when the new rule drops.
4. Lock down access controls. Review who can access what. Remove permissions that are broader than necessary. If your file-sharing tool does not support role-based access, it is the wrong tool.
5. Conduct (or update) a risk analysis. This is the single most enforced provision in HIPAA. OCR's Risk Analysis Initiative is specifically looking for practices that have never done one or have not updated theirs. It does not need to be hundreds of pages. It needs to be honest, specific to your practice, and documented.
6. Address AI use. If anyone in your practice is using a general-purpose AI tool with patient data, stop and evaluate. Get a compliant alternative or establish a clear policy prohibiting PHI in those tools.

The coalition of 100+ hospital and provider groups pushing back on the proposed rule changes is doing so partly because compliance costs are significant for under-resourced providers. That is a legitimate concern. But the existing requirements are not going away regardless of what happens with the proposed rule. The cheapest compliance investment is the one that prevents the breach you would otherwise have to report, remediate, and pay for.

Healthcare data breaches reached a record high in 2025. Enforcement is intensifying. The new rule is delayed but the old rule is not suspended. The gap between what is required and what most small practices actually do is wide, and it is filled mostly with good intentions and bad habits.

Close the gap with tools that are compliant by default, not compliant by configuration. And be specific about what your vendors can and cannot do. Vague claims about security are a liability, not a feature.

Start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io