Does a BAA Make Software HIPAA Compliant?

You asked the vendor for a BAA. They signed it. The tool is now compliant.

Not quite, and the gap is worth understanding before you build patient intake on top of it.

We have written separately about whether you need a BAA with your web team and what one covers. This is the narrower question underneath it: what a signed agreement actually does to a piece of software.

A BAA cannot authorise what you could not do yourself

This is the load-bearing rule, and it is written into the regulation in plain terms. A business associate contract may not authorise the business associate to use or disclose information in a manner that would violate the rules if the covered entity did it directly.

Read that twice, because it inverts how people use BAAs.

A BAA is not permission. It cannot make a data flow acceptable that would not have been acceptable if you had built it yourself. If a tool's architecture sends patient information somewhere it should not go, a signature does not fix the architecture. It just means somebody has now promised, in writing, to do something the rules do not allow.

Practically: if a form product's design is to pass submissions through an advertising platform, no signature makes that fine. The contract and the product are simply in conflict, and the contract loses.

A BAA covers what it says it covers

The second gap is narrower and catches more people.

Vendors sign BAAs for their product. Products have features. The agreement covers the features named in it, and the newer or more peripheral the feature, the more likely it sits outside.

This is not hypothetical or rare. It is ordinary practice, and it is usually disclosed if you read carefully. One widely used AI vendor's BAA states explicitly that it does not apply to the product's web search functionality. The agreement is real, the coverage is real, and there is a hole in the middle of it that you would only find by reading.

So the question is not "will you sign a BAA." It is "which parts of your product does this BAA cover, and is the part I actually use one of them."

The chain does not stop at your vendor

Your form tool runs on somebody's hosting. That hosting sits behind somebody's content network. Each of them may touch what your patients submit.

The rules follow the data rather than the contract. Any subcontractor that creates, receives, maintains or transmits protected health information on a business associate's behalf needs written assurances of its own, from the party above it. Your vendor is responsible for papering their side, but you are the one exposed if they have not.

This is the question almost nobody asks, and it is the fastest way to find out whether a vendor has thought seriously about compliance or bought a template. Ask them to describe the chain behind their product. The good ones answer immediately, because they had to work it out to sign anything at all.

A BAA describes the product on the day you signed it

The three gaps above are all things you could find by reading carefully. This one you cannot, because it has not happened yet.

A BAA is a document with a date on it. Everything it covers is the product as it existed that morning. Software does not hold still: features ship, integrations get added, subcontractors change, and the useful new thing your team starts using in March was not in the agreement you signed in January. Vendors are not hiding this. Most of them disclose subprocessor changes somewhere. It is simply that nobody at a practice is watching for it, and no email arrives.

The same drift happens on your side of the contract. We scanned 4,601 independent practice websites in July 2026, and 88.0% produced at least one finding while 10.7% came back with nothing to report. Almost none of them launched broken. An agency added a conversion tag to the appointment page. Somebody built a new location page and copied the old contact form onto it. A form tool was swapped for a better one and nobody re-asked the five questions.

None of that voids a BAA. It just moves the data outside what the BAA describes, which produces the same result with none of the warning.

So a signed agreement is a snapshot, and the useful question is not only "what does this cover" but "who is checking whether it still does."

What a BAA is genuinely worth

Having said all that, get one. A BAA is not decorative.

It creates a legal obligation where previously there was only a terms-of-service page. It puts a clock on breach notification. It limits what the vendor may do with the data, including using it to improve their own product. It obliges them to hold their subcontractors to the same terms. And it gives you something to point at when a patient, an insurer or an acquirer asks who was responsible.

The mistake is treating it as the end of the question rather than the beginning.

The short version

A BAA tells you somebody has accepted responsibility. It does not tell you the product is well designed, that the feature you use is covered, that the companies behind your vendor have signed anything at all, or that any of it is still true a year later.

Four questions get you most of the way:

1. Does this BAA cover the specific feature I am using?
2. Who else touches this data, and have they signed?
3. If the data flow itself is questionable, does a signature actually resolve it, or just document it?
4. Who re-checks the first three, and how would I find out if an answer changed?

The fourth is the one with no vendor-side answer. A vendor can only speak for their own product. Nobody but you is looking at the whole chain, which is precisely why most practices are not looking at it either.

If you want to know which of your current form and hosting vendors will sign at all, that is what our scan reports, alongside what it cannot determine from outside your systems.

See my exposure now

And if the answer to question four is that nobody is doing it, that is the job our Managed Plan exists to hold: one company accountable for the whole path, with the chain rechecked rather than assumed.