It’s easy to think of file sharing as a brief technical event: one person sends a file, another receives it, and the connection is secure. In practice, the exchange starts earlier and lasts longer.
Someone has to decide whether the information should be shared at all. Someone has to verify the recipient, choose what they’re allowed to reach and decide when that access should end. Copies may remain in storage, on a laptop or inside another healthcare system long after the transfer finishes.
So, the real task is to keep control of electronic protected health information (ePHI) throughout the exchange. That means combining appropriate technology with sound judgment, clear responsibilities and a process people can follow when work is moving quickly.
No platform can do all of that for a healthcare organization. A service can provide encryption, authentication, permissions and useful records. The covered entity or business associate still has to assess its risks, configure those controls properly and decide how ePHI may be used before and after it moves.
Let’s look at what that involves in practice.
What does HIPAA-compliant file sharing actually mean?
HIPAA-compliant file sharing is the permitted exchange of ePHI between authorized people or systems using reasonable and appropriate administrative, physical and technical safeguards.
That definition is deliberately broader than “use an encrypted service.” The HIPAA Security Rule doesn’t approve a particular product or protocol. Instead, it asks regulated organizations to protect the confidentiality, integrity and availability of ePHI in ways that make sense for their size, circumstances and risks.
For file sharing, that usually comes down to seven questions:
- Is the disclosure permitted?
- Which organizations and systems will handle the file?
- Is the recipient and destination correct?
- What’s the least access the recipient needs?
- How will the file be protected while it moves and wherever it’s stored?
- What activity will be recorded, and who’ll review it?
- When will access end, and what happens to the remaining copies?
These questions are connected. Encryption can stop someone from reading an intercepted file, but it can’t correct a mistyped address. A strong password won’t help if the account can browse an unrelated patient directory. And a detailed audit log has limited value if nobody looks at it.
That’s why good file sharing is better understood as a controlled process than as a single security feature.
What does HIPAA require when ePHI is shared?
The current Security Rule requires regulated entities to use safeguards that are reasonable and appropriate for their risks. Its technical safeguards cover access control, audit controls, integrity, person or entity authentication and transmission security. Administrative safeguards bring in risk analysis, access management, workforce training, incident procedures and business associate arrangements.
Some current implementation specifications are described as addressable. That word causes a fair amount of confusion. It doesn’t mean an organization can ignore the control. The organization has to decide whether it’s reasonable and appropriate in its environment. If it isn’t, that decision must be documented, and an appropriate alternative must be used where required.
You may also have seen references to proposed changes to the Security Rule. HHS has proposed more explicit requirements for controls such as encryption and multi-factor authentication, with limited exceptions. Those proposals may influence security planning, but they aren’t the rule currently in force. HHS confirms that the existing Security Rule remains in effect while rulemaking continues.
It’s worth keeping that in mind. Healthcare teams should prepare for stronger cybersecurity expectations without treating a proposed requirement as settled law.
Which file-sharing method is right for the job?
HIPAA doesn’t prescribe one file-sharing method. Nor should every exchange be forced through the same route.
A laboratory sending a results file to an application every morning has a different need from a patient collecting one document. The first exchange calls for stable, attributable machine access. The second may be better served by temporary browser access that disappears when it’s no longer needed.
| Sharing method | Where it fits | What to check |
|---|---|---|
| SFTP or FTPS | Recurring transfers between systems, suppliers or technical users | Separate credentials, SSH keys or strong passwords, restricted directories, narrow permissions, network restrictions and activity records |
| HTTPS web portal | Staff, patients or external users who need browser access | Individual accounts, MFA, home-directory restrictions, permissions, access expiry and activity records |
| Controlled share link | Temporary access to one file or folder | Password, short expiration, access limit, permitted actions, recipient verification, revocation and recorded link activity |
| API or managed integration | Authorized application-to-application exchange | Scoped authentication, secrets management, authorization, logging, error handling and BAA review for services handling ePHI |
| Approved secure email | Occasional messages or attachments within an established secure email process | Encryption, recipient verification, access controls, retention, approved procedures and appropriate BAA coverage |
The safest choice is the method that gives the intended recipient enough access to complete the task without leaving more access behind than the work requires.
Personal cloud drives, consumer messaging tools, unrestricted public links and ordinary email attachments shouldn’t become the default just because they’re convenient. The service, configuration and surrounding workflow all need to make sense within the organization’s risk analysis.
For recurring machine-to-machine exchanges, our guide to HIPAA-compliant SFTP and managed storage looks more closely at the managed environment around the connection. If you’re comparing providers rather than designing the exchange itself, see the healthcare MFT selection guide.
How should healthcare teams share ePHI securely?
The safest process tends to be one that people can repeat without having to improvise. These seven steps give staff and technical teams a common route from the first decision to the final access review.
1. Start with permission, not technology
Before choosing SFTP, a portal or a sharing link, establish why the recipient needs the information and whether the use or disclosure is permitted.
Then consider the Privacy Rule’s minimum necessary standard where it applies. If a billing service needs five fields, don’t send a complete patient export simply because it’s easier to generate. Reducing the data at the start narrows the consequences of every mistake that could follow.
It’s also useful to record the purpose of the exchange and who approved it. That decision gives the rest of the setup something concrete to follow: the recipient, the access method, the permissions and the period for which access is justified.
2. Follow the file through every service
Healthcare files rarely move straight from one clearly defined system to another. They may pass through cloud storage, a managed transfer service, an integration platform and a receiving application before anyone considers the exchange complete.
Map that route. Identify every organization and system that will create, receive, maintain or transmit the ePHI, including subcontractors where relevant. A file doesn’t stop being ePHI because it has moved from one piece of software to another.
This is also where the BAA question comes in. Assess the specific service and plan you’ll use, not just the vendor’s general position on HIPAA. If a provider is acting as a business associate, the required agreement needs to be in place before it handles the information.
3. Verify the person and the destination
Many damaging file-sharing mistakes arise as a result of mundane actions. The wrong contact is selected. An old distribution list is reused. A file lands in the correct server but the wrong directory.
Check the person, organization, username, address, endpoint and folder before the first live file is sent. For a recurring workflow, test with a harmless sample file and confirm where it appears and who can reach it.
Each outside organization or automated process should have its own credential. Shared credentials may feel simpler at first, but they make almost everything harder later. You can’t easily tell who performed an action, rotate one party’s secret or remove one organization without affecting another.
4. Give the recipient enough access, and no more
Access should match the work. A claims intake process may need write-only access to one directory, while a laboratory may need to read results without deleting them. A temporary reviewer may need one file for two days, not an account that remains active indefinitely.
Start with the narrowest permissions that allow the exchange to work. Bind the credential to the correct home directory so the recipient can’t browse unrelated folders. Then match the duration of the access to the duration of the need.
This is where choosing the right method pays off. A permanent credential makes sense for a daily system transfer while, for a one-time delivery, a protected sharelink with a short expiry may create far less standing access.
5. Protect the connection and the file
The file needs protection while it’s moving and while it’s waiting to be collected or processed. Those are different points in the journey, so they call for different controls.
SFTP, FTPS and HTTPS can encrypt the network connection. Storage encryption protects the copy held by the service. In workflows that need the file to remain independently encrypted, PGP can protect the file itself before and after transfer.
It’s tempting to treat these as interchangeable forms of “encryption,” but they aren’t. A secure connection ends when the transfer ends. Storage encryption doesn’t decide which credential can open a directory. PGP can protect the contents of a file, but it won’t tell you whether it was sent to the right endpoint.
The aim is to protect each part of the exchange without assuming one control has done the work of all the others.
6. Keep records that answer essential audit questions
An audit record should help someone reconstruct what happened. Who signed in? Which file did they reach? What did they do with it? When did it happen, and what changed before or after the event?
For a file-sharing workflow, the useful details commonly include:
| Record element | What it tells you |
|---|---|
| User, credential, administrator, link or system | Who or what performed the action |
| Successful or failed authentication | Whether access was attempted or obtained |
| File or directory path | Which information was affected |
| Upload, download, move, copy or deletion event | What happened to the file |
| Timestamp | When the action occurred |
| Source IP or available connection details | Where the activity originated |
| Credential, permission or sharing change | Whether the access conditions changed |
| Automation event | Whether a configured workflow acted on the file |
There’s little value in collecting a mountain of records that nobody examines. Decide who reviews them, which events call for investigation, how long the records are kept and where evidence should be preserved after an incident.
Notifications and audit logs also shouldn’t be confused. A notification draws attention to a selected event, such as a download or deletion. The audit log preserves the underlying record. SIEM streaming serves another purpose again, bringing file activity into centralized security monitoring where it can be examined alongside events from the rest of the environment.
7. End access deliberately
Access has a habit of outliving the work that justified it. Projects finish, staff change roles and outside providers are replaced, but old credentials and sharing links are easily forgotten.
Set an expiry where the platform allows it, and schedule a review where it doesn’t. Remove credentials, links and permissions as soon as they’re no longer required. An access review should look for dormant accounts, old external organizations, excessive directory access and links that have remained active beyond their original purpose.
Remember the copies too. The transfer may be over while ePHI remains on a workstation, in an export folder or inside the receiving system. Retention and disposal rules have to follow the information, not just the connection used to send it.

When is a BAA required for file sharing?
A BAA is generally required when a service provider creates, receives, maintains or transmits PHI on behalf of a covered entity or another business associate and therefore acts as a business associate under HIPAA.
That can include a cloud storage provider, managed file-transfer service, billing company, claims processor or healthcare software vendor. It doesn’t mean that every company that encounters healthcare information in every circumstance automatically becomes a business associate.
The HHS guidance on business associates explains that the agreement must define permitted and required uses and disclosures and require the business associate to safeguard the information. Subcontractors that handle PHI on behalf of a business associate may need their own agreements.
There’s another detail that’s easily missed. According to HHS guidance on cloud computing, a cloud provider can still be a business associate when it stores encrypted ePHI without possessing the decryption key. Its inability to read the file doesn’t remove the fact that it maintains ePHI on the customer’s behalf.
A signed BAA is necessary when the relationship calls for one, but it isn’t evidence that the workflow has been configured properly. It can’t correct broad directory access, a shared credential or a forgotten public link. The customer still has to assess the service, select the appropriate plan and manage its own use of the platform.
What should you check before the first live file is shared?
A formal risk analysis reaches much further than a file-sharing checklist. Still, a short operational review can catch obvious weaknesses before they reach production.
Ask the people responsible for the workflow to confirm:
- Purpose: Is the disclosure permitted and documented?
- Data: Does the file contain only what the recipient needs?
- Recipient: Have the person, organization, account and destination been verified?
- BAA: Does the required agreement cover this service and relationship?
- Identity: Does each human or system use its own attributable credential?
- Access: Is the credential confined to the right directory with the right permissions?
- Duration: Will the credential or link expire, or is a review date recorded?
- Protection: Are the connection and stored copy protected appropriately?
- Auditability: Will the relevant authentication, file and access changes be recorded?
- Response: Does someone know what to do if the file goes to the wrong place?
Then test the actual route. Use the same credential type, folder structure and recipient actions that the live workflow will use. Check failure as well as success. What happens when a password is wrong, a user attempts to reach another folder, a link expires or access is revoked?
A diagram may look impeccable while the real configuration tells a different story.
Can healthcare teams use secure share links for ePHI?
Yes, a controlled share link can support an ePHI exchange when the organization has assessed the service, has a BAA where required and configures the link for the particular risk.
The word “secure” shouldn’t be relied on as a guarantee. A link that can be forwarded indefinitely, opens an entire folder and never expires isn’t tightly controlled simply because the page uses HTTPS.
For a limited exchange, share only the required file or folder and use the narrowest available permission. Set a short expiration and a sensible access limit. If password protection is appropriate, communicate the password through a separate approved channel rather than placing it beside the link in the same message.
Review the activity and revoke the link as soon as the exchange is complete. If the workflow requires stronger proof of individual identity, a dedicated portal account with MFA is usually more suitable than access based mainly on possession of a URL.
Who is responsible for keeping the exchange compliant?
Using a managed service changes who operates the infrastructure. It doesn’t transfer every HIPAA responsibility to the provider.
The most useful dividing line is control. The provider is responsible for the service and infrastructure it operates. The customer is responsible for deciding how its organization configures and uses that service.
| Service provider | Healthcare organization or business associate |
|---|---|
| Operate and secure the managed platform and infrastructure within its scope | Conduct an organization-specific risk analysis |
| Maintain the service’s authentication, authorization, encryption and logging capabilities | Decide what ePHI may be shared, with whom and for what purpose |
| Protect data according to the architecture and contractual commitments | Configure credentials, directories, permissions, MFA, network rules and sharing controls |
| Meet the responsibilities stated in the BAA and service agreements | Review activity, investigate alerts and remove stale access |
| Maintain platform security updates and recovery processes within the agreed scope | Secure endpoints, downloaded files, exports and connected systems outside the service |
| Supply the controls and records included with the selected plan | Train staff and maintain procedures for incidents, retention and disposal |
This division should be discussed during procurement, not discovered after an incident. It should also be revisited whenever the plan, workflow, configuration or participating organizations change.
How does SFTP To Go support healthcare file sharing?
SFTP To Go provides managed file transfer and Amazon S3-backed storage that healthcare organizations can configure for workflows involving ePHI. BAAs are available on eligible plans.
The service supports SFTP, FTPS and HTTPS for encrypted transfer, while stored files are encrypted on Amazon S3 using AES-256 server-side encryption. Each credential can be bound to its own home directory and given permissions suited to the workflow, including read-only, write-only, read and write, or read and write without delete.
For recurring technical transfers, credentials can authenticate with supported SSH public keys or strong passwords. Human users can work through the HTTPS web portal, where MFA can be enabled and enforced. Credentials can also be given an access expiry, while eligible plans can restrict inbound connections by IP range at either the organization or credential level. You can review the underlying controls in the SFTP To Go security documentation.
The method can change without abandoning the same controlled storage environment. A system can connect through SFTP, while a staff member or external user works through the web portal. Share Links can be limited by file or folder permissions, expiration, access count and password, then changed or revoked when the exchange is finished.
Audit logs record authentication, file and relevant administrative or automation activity. Separate notifications can report selected file events through email, Slack, Microsoft Teams or webhooks. Eligible plans can also stream audit events to supported SIEM and observability destinations for centralized monitoring.
When a workflow needs routine file processing, native file automations can respond to file events or schedules. They can move, copy, delete, PGP-encrypt or decrypt files, create files or folders, add delays, send notifications and trigger webhooks.
That doesn’t mean every healthcare process belongs inside the file-transfer service. Claims validation, EHR updates, billing decisions and other application logic should remain in the system equipped to perform them. The healthcare SFTP automation and iPaaS guide looks at where that boundary belongs.
SFTP To Go can supply the technical controls around the exchange. The customer still has to select the right plan, configure it carefully, test the real workflow and include it in the organization’s wider compliance program.
Why does staff training still decide whether the process works?
Technology can limit access and record activity, but people still make the decisions that surround the file. They choose the recipient, decide which document to send and react when something looks wrong.
Training should therefore use the organization’s real tools and real situations. Staff should know which methods are approved for ePHI, when to use a permanent credential or temporary link, how to verify a destination and how passwords or other secrets may be communicated.
They also need to know what happens after a mistake. Who should be told if a file reaches the wrong person? Can a link be revoked immediately? Which records should be preserved? How will downloaded copies be handled?
Vague reminders to “be careful” won’t answer those questions. Give staff a practical route for each common exchange and make that route easier to follow than the unapproved shortcut.
What does safer healthcare file sharing look like in practice?
The best file-sharing process doesn’t rely on one impressive security feature. It keeps hold of the file from the decision to share it through the end of the recipient’s access.
The disclosure has a legitimate purpose. The recipient and destination have been checked. The file contains only what’s needed. Access is narrow, attributable and temporary where possible. The connection and stored copy are protected. Useful events are recorded, and someone is expected to review them. When the work ends, so does the access.
That’s what HIPAA-compliant file sharing looks like in practice. It isn’t a badge attached to a protocol, a sharing link or a platform. It’s a repeatable way of working, supported by suitable technology and people who understand why each control is there.
SFTP To Go provides managed transfer, storage, access, sharing, audit and automation controls around that process without requiring a healthcare organization to run its own file-transfer infrastructure.
Explore the Complete HIPAA Checklist for healthcare providers and BAAs: our full and free downloadable guide to HIPAA compliant file sharing in healthcare.
Frequently asked questions
What is HIPAA-compliant file sharing?
HIPAA-compliant file sharing is the permitted exchange of electronic protected health information between authorized people or systems using reasonable and appropriate administrative, physical and technical safeguards. It covers the recipient, access, transfer, storage, activity records and removal of access, not only the encryption used during transfer.
Does HIPAA require a particular file-sharing platform?
No. HIPAA is technology-neutral and doesn’t approve or require a specific product or protocol. Each regulated organization must choose and configure reasonable and appropriate safeguards based on its risk analysis and comply with the applicable Privacy, Security and Breach Notification Rule requirements.
Can healthcare providers share ePHI through a secure link?
Yes. A controlled link can support an ePHI exchange when the organization has assessed the service, has a BAA where required and configures the link for the risk. Relevant controls include narrow permissions, a short expiration, an access limit, password protection, recipient verification, activity records and prompt revocation.
Is a BAA enough to make file sharing HIPAA compliant?
No. A BAA defines contractual responsibilities, but it can’t configure the service or control staff behavior. The customer must still perform its risk analysis, restrict access, train its workforce, review activity and manage ePHI throughout the workflow.
Can SFTP be used for HIPAA-compliant file sharing?
Yes. SFTP encrypts data in transit over SSH and can form part of a HIPAA-regulated workflow. The wider environment must still address authorization, stored-data protection, audit controls, business associate arrangements, endpoints and the organization’s administrative and physical safeguards.
What should a HIPAA file-sharing audit record contain?
The record should connect an identifiable user, credential, link or system to an action, affected file and time. Useful details include authentication attempts, file uploads or downloads, permission changes, timestamps, paths and available source connection information. The organization should also define who reviews the records and how long they’re kept.
