Do You Need a BAA? A Decision Guide for SaaS Vendors

You need a business associate agreement if your product creates, receives, maintains, or transmits protected health information on behalf of a covered entity or another business associate. The word that catches people is "maintains," and HHS closed the argument about it in the HIPAA Omnibus Final Rule preamble at 78 FR 5571 to 5572: "An entity that maintains protected health information on behalf of a covered entity is a business associate and not a conduit, even if the entity does not actually view the protected health information." Encryption does not change that. Not holding the key does not change that. If PHI can rest on your infrastructure, you are almost certainly a business associate, and the same terms flow down to your subprocessors.

The genuine exceptions are narrow, and this article is mostly about how narrow. Then the flow-down obligation, which is the part that actually breaks deals, because it is the one founders discover after signing.

Key takeaways

• You need a BAA if your product creates, receives, maintains, or transmits protected health information on behalf of a covered entity or another business associate. All four verbs count.
• Encryption is a safeguard, not an exemption. HHS closed the argument in the Omnibus preamble: an entity that maintains PHI is a business associate and not a conduit, even if it never views the information.
• The conduit exception is limited to transmission services and any temporary storage incident to transmission. A product with a database, retained logs, a queue or an analytics store is maintaining data, not conducting it.
• Flow-down is what breaks deals late. Every subprocessor that can touch PHI needs an agreement with you, and their subcontractors need one with them, all the way down.
• With a cloud provider, the common failure is not a missing agreement but a scope mismatch: the BAA is executed and PHI sits in a service the agreement does not cover.

The test, in the order a lawyer would run it

Does PHI touch you at all? Protected health information is individually identifiable health information held or transmitted by a covered entity or business associate. If your product handles appointment times tied to named patients, claims data, clinical notes, lab results, device telemetry linked to an individual, or even a support ticket whose body a nurse pasted a patient record into, PHI touches you.

Is it on behalf of a covered entity or business associate? A covered entity is a health plan, a health care clearinghouse, or a health care provider that transmits health information electronically in connection with a covered transaction. If a hospital, a health plan, or another vendor serving one is your customer, you are working on their behalf.

Do you create, receive, maintain, or transmit it? All four verbs count, and they are the same four the Security Rule uses at 45 CFR 164.308(b): "A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity's behalf only if the covered entity obtains satisfactory assurances ... that the business associate will appropriately safeguard the information."

Three yeses means you sign. Note what is not on the list: whether you look at the data, whether it is encrypted, whether it is a small volume, and whether it is incidental to your real product. None of those are elements of the test.

The conduit exception is not the exception you want it to be

Nearly every vendor that resists a BAA reaches for the conduit exception, and nearly every one of them is misreading it.

HHS wrote it plainly in the same preamble: "The conduit exception is limited to transmission services (whether digital or hard copy), including any temporary storage of transmitted data incident to such transmission." The examples HHS gives are the postal service, couriers, internet service providers, and their electronic equivalents. The distinguishing feature is transience. A conduit moves data past itself. It does not keep it.

So a telecom carrier is a conduit. A courier is a conduit. Your document storage vendor is not, and HHS says so directly: document storage companies "are considered business associates, regardless of whether they actually view the information they hold."

Apply that to a modern SaaS architecture and the exception almost never survives. Your product has a database. Your logs retain request payloads for two weeks. Your queue holds messages until a worker drains it. Your analytics pipeline keeps events for a year. Every one of those is maintenance rather than transmission, and each one on its own is enough.

There is one genuinely useful place the exception still lands: a pure relay with no retention beyond the transmission itself. If you are building one, the retention design has to be deliberate and documented, because you will be asked to prove it.

The two exclusions people forget

Workforce members are not business associates. Employees, volunteers, trainees and others whose conduct is under the direct control of the covered entity are workforce, and workforce is covered by the entity's own obligations rather than by a BAA. This matters for staffing arrangements: whether an embedded contractor is workforce or a business associate depends on control, not on which company issues the paycheck, and getting it wrong in either direction creates a real gap.

Treatment disclosures between providers are not business associate relationships. When one provider sends records to another for treatment, that is a permitted disclosure, not a service performed on the first provider's behalf. Two hospitals exchanging records do not sign a BAA with each other for that purpose.

Neither exclusion helps a SaaS vendor. Both come up constantly in the arguments SaaS vendors have with their own customers, which is why they are worth knowing.

Flow-down: the obligation that breaks deals late

This is the paragraph we wish more founders read before signature. The Security Rule at 164.308(b) does not stop at your contract with your customer. It says: "A business associate may permit a business associate that is a subcontractor to create, receive, maintain, or transmit electronic protected health information on its behalf only if the business associate obtains satisfactory assurances ... that the subcontractor will appropriately safeguard the information."

In plain terms: every vendor in your stack that can touch PHI needs a BAA with you, and their subcontractors need one with them, all the way down. The chain does not terminate at a company size or a hyperscaler's brand.

Run the inventory now rather than during a deal. The usual list:

• Cloud infrastructure. AWS, Google Cloud and Azure all offer BAAs, and on each of them you have to explicitly accept the agreement and then restrict yourself to the services the agreement covers. Signing the BAA and then putting PHI in a service outside its scope is a gap that looks compliant on paper.
• Managed databases, caches and search, wherever the record actually lands.
• Log aggregation and application performance monitoring, which is where PHI hides most often, because nobody chose to send it there. It arrives in a request body or a stack trace.
• Error tracking, which has the same problem for the same reason.
• Email and messaging providers, if any message can carry PHI.
• Customer support tooling, if an agent can see a record.
• Analytics and product telemetry, if events can be tied to an individual.
• Any AI or model-inference provider in the request path. This is the newest one and the most frequently missed, and the answer is not different because the vendor is fashionable.

If a vendor on that list will not sign, you have three options: stop sending them PHI, replace them, or design them out of the PHI path. There is no fourth option where you keep sending and hope.

What a BAA has to contain, and what negotiation is available

The required content is set by regulation, not by preference. Permitted uses and disclosures. An obligation to safeguard the information and to use appropriate safeguards. An obligation to report security incidents and breaches. An obligation to flow terms down to subcontractors. Return or destruction of PHI at termination where feasible. Making practices available to HHS. Termination rights on material breach.

What is genuinely negotiable in our experience: breach notification timing, where the regulatory floor for a business associate is no later than 60 days after discovery but most customers want far less and many BAAs specify 24 to 72 hours; audit rights and how they are exercised; indemnity and liability caps, which are contract terms rather than HIPAA terms; and the definition of a security incident, which matters more than it looks because an unqualified definition can obligate you to report every scanned port.

What is not negotiable: the existence of the agreement, the safeguard obligation, and the flow-down. Asking to strike those tells your customer's counsel that you have not read the rule.

Our vendor risk management program guide covers the register and review process this implies once you have more than a handful of subprocessors. For the notification clock itself, breach notification deadlines sets out how the HIPAA timeline interacts with the state and sectoral ones you are probably also subject to.

The honest caveat

Not every health-adjacent SaaS company needs a BAA, and being told you do when you do not is expensive. If your product genuinely handles de-identified data under the Privacy Rule's standard, or only aggregate statistics, or you sell to wellness companies that are not covered entities, you may be outside the regime entirely. That is a real analysis worth doing once, carefully, because the answer changes your entire compliance surface.

What we would not do is rely on a de-identification claim you have not tested. The two lawful methods are expert determination and the safe harbor removal of the specified identifiers, and "we stripped the names" is neither.

Where Top Floor fits

We do the PHI data-flow mapping, the subprocessor inventory, the BAA template review and the readiness work behind it under our HIPAA practice, and the ongoing vendor and evidence management under Compliance as a Service. We are not your lawyers, and the BAA is a contract: have counsel review the template you sign, particularly the liability and indemnity terms, which are the ones HIPAA does not dictate and the ones that cost real money.

How to decide this week

List every system where a PHI record can come to rest for longer than the moment it takes to pass through. Include logs, queues, caches, backups and error trackers. That list is your BAA list, and it is almost always longer than the one in your security questionnaire response.

For each entry, find the executed agreement. Not the vendor's marketing page saying they are HIPAA compliant, the countersigned agreement with a date on it. Missing ones are your project.

Then check your cloud provider's BAA scope against the services you actually run. That mismatch is the single most common finding we see, and it is unglamorous, cheap and fast to fix.

Frequently asked questions

Do we need a BAA if the data is encrypted and we never see it?

Yes, in almost every case. HHS addressed this directly in the HIPAA Omnibus Final Rule preamble at 78 FR 5571 to 5572: an entity that maintains protected health information on behalf of a covered entity is a business associate and not a conduit, even if the entity does not actually view the protected health information. Document storage companies are business associates regardless of whether they view what they hold. Encryption is a safeguard, not an exemption, and holding no key does not remove you from the definition.

What is the HIPAA conduit exception, exactly?

It is a narrow carve-out for transmission-only services. In the Department's words, the conduit exception is limited to transmission services, whether digital or hard copy, including any temporary storage of transmitted data incident to such transmission. The examples are the postal service, couriers, internet service providers and their electronic equivalents. The test is transience: a conduit moves data past itself rather than keeping it. A SaaS product with a database, retained logs, a message queue or an analytics store is maintaining data, not conducting it.

Do we need BAAs with our own vendors, or only with our customers?

Both. 45 CFR 164.308(b) says a business associate may permit a subcontractor to create, receive, maintain, or transmit electronic protected health information on its behalf only if it obtains satisfactory assurances that the subcontractor will appropriately safeguard the information. The chain runs all the way down, so every subprocessor that can touch PHI needs an agreement with you, and their subcontractors need one with them. Cloud infrastructure, log aggregation, error tracking, support tooling and any model-inference provider in the request path all belong on that list.

Is a cloud provider's HIPAA page enough, or do we have to sign something?

You have to sign something, and then stay inside its scope. AWS, Google Cloud and Azure each publish a business associate addendum that you must explicitly accept, and each one covers a defined list of services. The failure we see most often is not a missing agreement but a scope mismatch: the BAA is executed, and PHI is sitting in a service the agreement does not cover. Check the covered-services list against your actual architecture, and re-check it whenever you adopt a new managed service.