In August 2026 a sysadmin asked r/sysadmin for managed file transfer recommendations. They were running a desktop FTP client plus a pile of scheduled scripts, and their stated problem was not speed or cost. It was files they could not verify were sent. Partway down the thread someone asked what industry they were in. The reply, in full: “Healthcare so, on prem if possible.”
Six words, no reasoning attached, and nobody questioned them. The recommendations that followed were on-prem products. Healthcare, therefore on-prem, is one of the most durable reflexes in IT procurement. It is worth asking where it comes from, because the regulation it is usually attributed to does not say it.
The Security Rule does not say where the server goes
The HIPAA Security Rule, 45 CFR Part 164 Subpart C, does not require on-premises hosting. It does not prohibit cloud services. It does not name a product, an architecture, a data centre or a country. It was written to be technology-neutral and scalable: it sets standards for administrative, physical and technical safeguards and leaves the method to the regulated organisation, sized to its own risk analysis. “On-premises” appears nowhere in it as a requirement, because the drafters chose to regulate outcomes rather than hardware.
That is not a loophole. It is the design, and it is why a rule finalised in 2003 still governs systems its authors never saw.
What HIPAA actually asks for
Three things, broadly. None of them mentions a location.
Safeguards. Administrative ones in §164.308 (a 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 it is very hard to write down a defensible reason not to encrypt, which is why plaintext FTP is finished 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 touch it. The HHS Office for Civil Rights spelled out how this applies to cloud vendors in its guidance on HIPAA and cloud computing, published in October 2016, and the guidance is stricter than most vendors like to admit:
- 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 get a vendor out of the BAA.
- The “conduit” exception, the postal-service analogy some transfer services reach for, “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”.
Note that all three points cut against vendors, including this one. A BAA is not a courtesy a good vendor offers. 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 six years applies to compliance documentation. HIPAA sets no national retention period for clinical medical records; that is state law, and it varies widely. A vendor telling you “HIPAA requires seven years” has it wrong on both counts.
What the reflex is really protecting
If the Rule never asked for on-prem, why do healthcare teams keep reaching for it? Because the instinct underneath is sound. Patient data should not sit on some vendor’s disk, under some vendor’s keys, subject to some vendor’s retention policy and readable by some vendor’s support staff. That instinct is about custody, and for most of the industry’s history running your own server was the only way to keep it.
It has not been the only way for a decade. Custody and location have separated: you can hold the storage, the keys and the logs in your own cloud account while a vendor provides the endpoint. Which means the useful question is not “cloud or on-prem?” It is three narrower questions, and they work on any vendor, including ones you already run.
Three questions to ask any file-transfer vendor
- 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, which still deserve a look.
- 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 you where file contents and file names go. Then decide whether you believe it.
- Can you prove what happened? The r/sysadmin post was really about this. §164.312(b) requires audit controls that record activity in systems holding PHI, and the six-year documentation clock 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-prem answers all three well, and for some organisations it is the right answer: an air-gapped network, imaging volumes that make egress expensive, a security team that already runs everything in-house. The claim here is narrow. HIPAA does not require it, and the questions above are what it was standing in for.
What is changing, and what is not
On 6 January 2025 HHS published a notice of proposed rulemaking that would be 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, along with 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 in the Federal Register, the government’s own regulatory agenda now targets final action in July 2027, and dates like that move. Until a final rule publishes, the existing Security Rule, addressable encryption and all, is the law in force.
The direction is not in doubt, though, and it matters for the on-prem question. Every proposed change lands on whoever operates the endpoint: encryption that must be implemented rather than addressed, MFA on every access path, documentation that must be produced rather than described. “We’ll keep running the old FTP box ourselves” was always a custody decision dressed as a compliance one. Under the proposed Rule it also becomes more work.
Where DocEvent fits
Start with the question that decides everything else: yes, DocEvent is a business associate when it handles PHI for you, and DocEvent signs a BAA. Ask for one at support@docevent.io before you send a byte of protected health information, and do not take that step on our word alone: read the agreement, and put it through the same review as any other vendor’s.
Then the architecture, 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. This is not an option we offer alongside vendor storage; it is the only way the product works. The Simple FTP Service streams each upload from the connection into your bucket rather than storing it, and Channels 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 exactly why we are a business associate rather than a conduit, and why the BAA exists.
- Is there a BAA? Yes. And to answer the follow-up question from the list above: what we hold 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 - comfortably past the six-year clock the Rule puts on 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 that could not be delivered (the subject of a separate article). Because the bucket is yours, versioning on it gives you restore and reprocess of any file, on your terms.
The access controls are the ones the technical safeguards ask about: 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. And 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.
That is the answer the on-prem reflex was reaching for. Your custody, your keys, your evidence, without a server to patch.
References
- Guidance on HIPAA & Cloud Computing - HHS Office for Civil Rights, October 2016: cloud providers as business associates, no-view services, the conduit exception, dual liability.
- 45 CFR 164.306 - Security standards: general rules; paragraph (d)(3) defines what an addressable implementation specification requires.
- 45 CFR 164.312 - Technical safeguards; encryption is addressable at (a)(2)(iv) and (e)(2)(ii).
- 45 CFR 164.316 - Policies and procedures and documentation requirements; the six-year retention period at (b)(2)(i).
- The Security Rule - HHS overview page, including the January 2025 proposed rule.
- HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information - Federal Register, 90 FR 898, 6 January 2025 (proposed rule; comments closed 7 March 2025).