Protected health information (PHI) rarely leaks from inside the EHR. It leaks on the way out: the lab result emailed to a specialist, the records export sent to a billing vendor, the research dataset uploaded to a consumer file share. That is why "HIPAA file transfer" is one of the most searched topics for healthcare IT and compliance teams.
This guide explains what HIPAA actually requires when you transfer files containing PHI, which audit logs you need, why FTP and email often fall short, and how to set up a HIPAA compliant file transfer process.
Is there such a thing as a "HIPAA compliant" file transfer tool?
Strictly speaking, no software is HIPAA compliant on its own. HIPAA applies to covered entities (providers, health plans, clearinghouses) and their business associates. A tool can provide safeguards that support your compliance, and a vendor can sign a Business Associate Agreement (BAA), but compliance depends on how you configure, govern, and use it.
When a vendor says "HIPAA compliant," read it as "we provide safeguards and will sign a BAA." Then verify the safeguards.
HIPAA file transfer requirements
The HIPAA Security Rule (45 CFR Part 164, Subpart C) does not name specific technologies. It sets standards, some "required" and some "addressable." Addressable does not mean optional: you must implement the specification if it is reasonable and appropriate, or document why not and implement an equivalent alternative.
These are the Security Rule technical safeguards (45 CFR 164.312) that matter most for file transfer:
Access control (164.312(a))
- Unique user identification (required): every person who sends or receives PHI should have their own identity, not a shared login.
- Emergency access procedure (required).
- Automatic logoff (addressable).
- Encryption and decryption (addressable) for PHI at rest.
Audit controls (164.312(b), required)
You must implement mechanisms that record and examine activity in systems containing ePHI. For file transfer, that means the system must log who sent what, to whom, and when, and who accessed it afterwards.
Integrity (164.312(c))
Protect PHI from improper alteration or destruction. A mechanism to verify that a file has not been altered (addressable) is relevant for transfers.
Person or entity authentication (164.312(d), required)
Verify that the person or system seeking access is who it claims to be. Strong authentication such as MFA is a common way to meet this.
Transmission security (164.312(e))
Guard against unauthorized access to PHI being transmitted over a network. Integrity controls and encryption in transit are both addressable specifications, but in practice it is very hard to justify sending PHI over the internet unencrypted.
Encryption and breach notification. Under the Breach Notification Rule, PHI encrypted consistent with HHS guidance is considered "secured," so a loss of properly encrypted data may not be a reportable breach. That is a strong practical reason to encrypt PHI in transit and at rest.
A note on rule changes: HHS published a proposed update to the Security Rule in January 2025 that would remove most of the distinction between required and addressable specifications, including for encryption. Check the current status of that rulemaking with your compliance counsel.
Business associate agreements
If a file transfer vendor creates, receives, maintains, or transmits PHI on your behalf, it is a business associate and you need a BAA (45 CFR 164.502(e) and 164.504(e)). The narrow "conduit" exception covers transmission-only services such as an ISP; it does not cover vendors that store files, even temporarily.
Minimum necessary
The Privacy Rule's minimum necessary standard means you should limit disclosures to what the recipient needs. In file transfer terms: send the specific records, not the whole archive, and limit how long the recipient can access them.
What file transfer audit logs are needed for HIPAA?
HIPAA requires audit controls but does not prescribe a log format. For file transfer, a defensible audit trail captures:
- Identity of the sender and recipient (person, partner, or system)
- The file or package transferred, ideally with an integrity hash
- Timestamp for upload, send, delivery, and each later access or download
- Policy decision: was the action allowed, denied, or approved by someone
- Changes to access: link creation, expiry, revocation
- Deletion and retention events
HIPAA requires you to retain required documentation (policies, procedures, and records of required actions and assessments) for six years (45 CFR 164.316(b)(2)). Many organizations align audit log retention with that window; decide your retention period with counsel and document it.
Ask one question of any tool: can it show the complete history of a single file, from intake to final access, in one export? If you have to stitch email logs, SFTP logs, and a share report together, the trail will not hold up well in an investigation.
Is FTP or email HIPAA compliant?
Plain FTP transmits data and credentials unencrypted, so it does not meet reasonable transmission security for PHI. SFTP or FTPS add encryption, but encryption alone does not give you per-user identity, recipient access limits, revocation, or a file-level audit trail. Shared SFTP credentials across a vendor team undermine unique user identification.
Email can be used for PHI if appropriately secured and, for patients, if they have been informed of risks and requested it. But attachments are hard to revoke, easy to forward, and difficult to reconstruct in an audit. For anything beyond small, occasional exchanges, a dedicated secure transfer path is easier to defend.
HIPAA compliant external file transfer: the high-risk path
External transfers to specialists, payers, billing vendors, research partners, or patients carry the most risk because the file leaves your boundary. Controls that matter most here:
- Recipient identity: named recipients, not anyone-with-the-link.
- Time-bound access: links that expire.
- Revocation: the ability to cut off access after a mistaken send.
- View-only options where the recipient does not need to download.
- Approval for large or sensitive outbound packages.
- No-account intake so patients and partners can send records to you without using consumer file shares.
How to set up a HIPAA compliant file transfer system
- Map PHI flows. List where PHI leaves and enters your organization: referrals, records requests, payer submissions, vendor exports, research data.
- Include it in your risk analysis. File transfer paths should be in your Security Rule risk analysis, with identified risks and controls.
- Pick a platform and sign a BAA. Confirm the vendor signs a BAA and review its security documentation (for example, a SOC 2 Type II report).
- Configure least privilege. Unique identities, MFA/SSO, role-based permissions, and per-file or per-folder policies.
- Enforce encryption in transit and at rest by default, not as a user choice.
- Set external sharing rules: expiry, download limits, and approval for sensitive packages.
- Retire side channels. Block or discourage consumer file shares and unmanaged email attachments for PHI.
- Test your audit trail. Pick a file and reconstruct its history before an auditor asks you to.
- Train staff and review regularly.
HIPAA secure file transfer checklist for vendors
- Will you sign a BAA?
- Is encryption in transit (TLS 1.2+) and at rest enforced automatically?
- Does every user have a unique identity, with MFA and SSO support?
- Can access be scoped per file or folder, with external sharing restricted?
- Can links expire and be revoked?
- Can external parties send files without creating an account?
- Does the audit trail cover upload, access, policy decisions, transfers, and deletion?
- Can you export audit logs to our SIEM?
- What independent assessments (SOC 2 Type II, penetration testing) can you share?
- Can it be self-hosted if our requirements call for it?
How Stellarbridge helps
Stellarbridge provides governed storage and transfer for PHI with HIPAA-aligned safeguards. Data is encrypted in transit (TLS 1.2+) and at rest (AES-256 or equivalent). A policy engine decides whether each action is allowed, denied, or requires human approval before a file moves. Access is least-privilege and scoped at the file level, with secure-view workflows and time-bound external delivery. Governed file requests let patients, providers, and partners upload records without creating an account, and uploads, access, policy decisions, transfers, and deletion stay tied to one attributable history.
A BAA is available for qualifying Enterprise deployments, and Stellarbridge has completed a SOC 2 Type II examination (the report is available under NDA). Like any vendor, Stellarbridge does not make you HIPAA compliant on its own; it provides safeguards that support your broader program.
See the HIPAA use case or request security documentation through the Trust Center.
FAQ
What are the HIPAA file transfer requirements?
HIPAA requires safeguards for access control, audit controls, integrity, person or entity authentication, and transmission security, plus a BAA with any vendor handling PHI. Encryption is addressable but is the standard practical choice for PHI in transit.
What file transfer audit logs are needed for HIPAA?
Logs should show who sent or received each file, what was transferred, when, every subsequent access, policy decisions, link changes, and deletion. Retain them according to a documented policy; many organizations align with HIPAA's six-year documentation retention.
Is FTP HIPAA compliant?
Plain FTP is unencrypted and not appropriate for PHI. SFTP or FTPS encrypt the connection, but you still need unique user identities, access controls, audit logging, and a BAA.
How can I set up a HIPAA compliant file transfer system?
Map PHI flows, include them in your risk analysis, choose a vendor that signs a BAA, enforce encryption and least privilege, set rules for external sharing, retire side channels, and test that you can reconstruct a file's full history.
Is a HIPAA compliant external file transfer different from an internal one?
The same rules apply, but external transfers carry more risk because the file leaves your boundary. Named recipients, expiring links, revocation, and approval for sensitive packages are especially important.
Does using a HIPAA compliant secure file transfer tool make us compliant?
No. The tool supports compliance; your policies, configuration, risk analysis, training, and BAAs complete it.