Get started
All articles
HIPAAHealthcareSFTPCompliance

Does HIPAA Require On-Premises File Transfer?

No - the HIPAA Security Rule is technology-neutral and never says where your SFTP server has to run. It asks for safeguards, a business associate agreement with anyone who handles PHI, and documentation. What the Rule actually says, three questions for any file-transfer vendor, and how DocEvent fits.
DocEvent Engineering·Sep 12, 2026·7 minute read

Does HIPAA require on-premises file transfer? No. The Security Rule requires safeguards, a BAA with vendors that handle PHI, and documentation - not a particular hosting model. The real questions are who holds the data, keys, and audit evidence.

Does HIPAA require on-premises file transfer?

The HIPAA Security Rule, 45 CFR Part 164 Subpart C, does not require on-premises hosting and does not prohibit cloud services. It names no product, architecture, data centre or country. It is technology-neutral and scalable by design: it sets standards for administrative, physical and technical safeguards and leaves the method to the regulated organisation, sized to its own risk analysis. That is why a rule finalised in 2003 still governs systems its authors never saw.

What HIPAA requires from file-transfer services

Three things, none of which names a location.

Safeguards. Administrative ones in §164.308 (risk analysis, workforce training, contingency plans), physical ones in §164.310 (facility and device controls) and technical ones in §164.312 (access control, audit controls, integrity, authentication, transmission security). Encryption sits in the last group, and its status surprises people: both encryption specifications, at rest in §164.312(a)(2)(iv) and in transit in §164.312(e)(2)(ii), are marked Addressable, not Required.

Addressable does not mean optional. Under §164.306(d)(3) you must assess whether the specification is a reasonable and appropriate safeguard in your environment; implement it if so; and if not, document why not and implement an equivalent alternative measure. For files crossing the public internet there is rarely a defensible reason not to encrypt, which is why plaintext FTP is not a realistic option for PHI whatever the Rule technically permits.

Accountability. Anyone who creates, receives, maintains or transmits PHI on your behalf is a business associate, and you need a business associate agreement (BAA) with them before they handle it. The HHS Office for Civil Rights set out how this applies to cloud vendors in its guidance on HIPAA and cloud computing, published in October 2016:

  • A cloud provider holding your PHI is a business associate “even if it does not hold a decryption key and therefore cannot view the information”. Encrypting before upload does not remove the need for a BAA.
  • The “conduit” exception “is limited to transmission-only services for PHI… including any temporary storage of PHI incident to such transmission”. A service that stores your files does not qualify.
  • The vendor is “both contractually liable for meeting the terms of the BAA and directly liable for compliance with the applicable requirements of the HIPAA Rules”.

All three points apply to vendors, including DocEvent. A BAA is not a courtesy; it is the line between a vendor that can handle PHI and one that cannot.

Documentation. §164.316 requires written policies and procedures, plus a record of the actions, activities and assessments the Rule requires, retained for six years from creation or from when they were last in effect, whichever is later. That period applies to compliance documentation. HIPAA sets no national retention period for clinical medical records; that is state law, and it varies. A vendor telling you “HIPAA requires seven years” has it wrong on both counts.

Why custody - not location - is the real issue

The on-premises preference usually rests on a sound instinct: patient data should not sit on a vendor’s disk, under a vendor’s keys, subject to a vendor’s retention policy and readable by its support staff. That is a custody concern, and for most of the industry’s history running your own server was the only way to address it.

It no longer is. You can hold the storage, keys and logs in your own cloud account while a vendor provides the endpoint. So the useful question is not “cloud or on-premises?” but the three below, which apply to any vendor, including systems you already run.

Three questions to ask any file-transfer vendor

  1. Who holds the data at rest? Not “is it encrypted” but whose bucket, whose keys, whose account. If the answer is the vendor’s, they are storing PHI and the BAA is not optional. If the answer is yours, ask what the vendor holds instead - usually configuration, credentials and logs - and review those.
  2. Is there a BAA? If the vendor will create, receive, maintain or transmit PHI, the answer must be yes, in writing, before go-live. If they say their architecture means they never handle PHI, ask them to walk you through the byte path and show where file contents and file names go.
  3. Can you prove what happened? §164.312(b) requires audit controls that record activity in systems holding PHI, and the six-year documentation period applies to the records you rely on. Ask who owns the log, where it lives, what it records per file, and whether it survives the vendor.

On-premises answers all three well, and for some organisations it is the right choice: an air-gapped network, imaging volumes that make egress expensive, a security team that already runs everything in-house. The point is narrower: HIPAA does not require it, and these questions are what the requirement was standing in for.

HIPAA Security Rule update: what is proposed

On 6 January 2025 the Federal Register published HHS’s proposed rule, the first major overhaul of the Security Rule since 2013. It would remove the addressable/required distinction, making nearly every implementation specification mandatory, and would require encryption of ePHI at rest and in transit, multi-factor authentication and tighter documentation. The comment period closed on 7 March 2025 with more than 4,700 comments filed.

As of September 2026 it is still a proposal. No final rule has been published, the government’s regulatory agenda targets final action in July 2027, and such dates move. Until a final rule publishes, the existing Security Rule, with addressable encryption, is the law in force.

The direction still matters for the hosting question. Every proposed change lands on whoever operates the endpoint: encryption implemented rather than addressed, MFA on every access path, documentation produced rather than described. Running an ageing FTP server yourself was always a custody decision rather than a compliance requirement; under the proposed rule it also becomes more work.

How DocEvent supports a HIPAA-aligned file-transfer architecture

DocEvent is a business associate when it handles PHI for you, and DocEvent signs a BAA. Request one at support@docevent.io before any protected health information moves, and review the agreement as you would any vendor’s.

Against the three questions, with capabilities current as of September 2026:

  • Who holds the data at rest? You do. Every file lands in your own bucket - Amazon S3, Azure Blob, Google Cloud Storage, Cloudflare R2 or any S3-compatible store - under your keys, in your region, governed by your lifecycle and retention rules. That is the only way the platform works, for both services: the Simple FTP Service (managed SFTP and FTPS endpoints) streams each upload from the connection into your bucket rather than storing it, and Channels (routing files between partners, systems and storage) hold a file only while routing it, in encrypted non-public storage that is cleared once the file has reached every destination, failed its retries, or is a day old. That transit is why DocEvent is a business associate rather than a conduit, and why the BAA covers both services.
  • Is there a BAA? Yes. What DocEvent holds instead of your files is configuration, user credentials (stored hashed) and the audit log, which records file names, not file contents. Keep patient identifiers out of file names and the log holds no PHI either.
  • Can you prove what happened? Per file, for years. Every login, upload, download and delete is logged with user, source address, path and bytes, searchable in the console, exportable as CSV, and retained for up to seven years - past the six-year period the Rule sets for compliance documentation, with room for the longer windows some state laws impose. Channels add a per-file routing record with a status per destination, the receiving server’s verbatim response on any failure, and a Stuck files queue for anything undelivered (see File transfer audit trails). Because the bucket is yours, versioning on it gives you restore and reprocess of any file.

The access controls match the technical safeguards: SSH-key authentication, per-user home directories, per-service IP allow and deny lists, read-only users, and encrypted transport - use SFTP or FTPS and leave plain FTP switched off for anything carrying PHI. If your policy says file bytes must never transit a vendor at all, the same server runs self-hosted inside your own AWS account, with the console holding configuration only.

SFTP and file routing for PHI
Use managed SFTP over your own S3, Azure or GCS storage, or route files with Channels. SSH keys, IP controls and audit records support the safeguards you need; DocEvent signs a BAA when it handles PHI. Request the agreement before PHI moves.
Get started freeAsk for a BAA
This article is general information, not legal advice. Whether any arrangement satisfies HIPAA depends on your organisation’s own risk analysis; confirm it with your privacy or compliance officer or counsel. There is no HHS “HIPAA certification” for software or vendors, and DocEvent does not claim one.

References

All articles