What a Business Associate Agreement actually obligates a vendor to do
A signed BAA is not a compliance certificate. What it commits your software vendor to, what it does not cover, and the questions to ask before signing one.
"We are HIPAA compliant" is a sentence with no legal meaning. There is no HIPAA certification, no issuing body, and no audit that produces a badge. What exists is a set of obligations under the Privacy, Security, and Breach Notification Rules, and a contract that passes some of them to vendors.
That contract is the Business Associate Agreement. If you are buying software that will touch protected health information, understanding what the BAA does and does not do is more useful than any vendor's compliance page.
What the BAA is for
Under HIPAA, a covered entity (a provider, a health plan, a clearinghouse) remains responsible for protected health information even when a vendor handles it. The BAA is the instrument that makes the vendor directly liable for a defined set of obligations, rather than leaving all exposure with the covered entity.
In practice it commits the business associate to five things:
- Use and disclose PHI only as the agreement permits. Not for the vendor's own purposes, not to improve their product, not to train a model, unless the agreement explicitly says so.
- Apply the Security Rule safeguards. Administrative, physical, and technical. The vendor is directly subject to these, not merely contractually promising them.
- Report breaches and security incidents. Within a defined window, which is a negotiated term worth reading closely.
- Flow the obligations down to subcontractors. Anyone the vendor uses who touches PHI needs an equivalent agreement. This is where the chain most often breaks.
- Return or destroy PHI at termination. With a documented process, not a promise.
What it does not do
A BAA is not evidence that any of it is true. It is a contract that creates liability if it is not.
Specifically, a signed BAA does not tell you:
- Whether the safeguards are actually implemented. That is what an independent assessment, a SOC 2 report, or a technical review is for.
- Where the data lives. Data residency is a separate negotiation. So is whether backups leave the country.
- Who at the vendor can see it. The Security Rule requires access controls; the BAA does not enumerate them. Ask.
- What happens to derived data. Aggregate statistics, embeddings, model fine-tunes, and audit logs derived from PHI are a real gap in many agreements. If it can be re-identified, it is still PHI.
That last one has become sharply more important with AI in the stack. A model provider that retains prompts for abuse monitoring is retaining PHI, and needs to be under a BAA like any other subcontractor. Our position on that is written down in our AI policy.
Questions worth asking before you sign
These are the ones that produce useful answers rather than reassuring ones.
| Question | What a good answer sounds like |
|---|---|
| Which subcontractors touch PHI? | A named list, with BAAs on file, available on request |
| What is your breach notification window? | A specific number of days, and who is notified |
| Who on your team can access production data? | A named role, time-limited access, and logged |
| Is PHI encrypted at rest and in transit? | Yes, with the mechanism named, including backups |
| What does termination return look like? | A format, a timeline, and a destruction certificate |
| Is any PHI used to improve your product? | No, unqualified, or a specific and narrow exception |
For engineering teams: what changes in the build
If PHI is in scope, the agreement changes the architecture, not just the paperwork. The specifics are in the technical safeguards checklist, but three consequences show up in every project:
Audit logging becomes a feature, not an afterthought. You need to be able to answer who accessed which record when, and retain that answer.
Every third-party service becomes a decision. Error trackers, analytics, session replay, and log aggregators all cheerfully capture whatever is on screen. Each needs to be either under a BAA or fed scrubbed data.
Minimum necessary shapes the data model. The rule is not "encrypt everything". It is that each role should be able to reach only the information needed for its function, which is a schema and permissions question you want to answer early.
Retrofitting these into a working system is one of the more expensive ways to discover a requirement, which is why compliance sits so high in what drives custom software cost.
We take HIPAA engagements under a signed BAA, and how we handle access, logging, and subcontractors is described in our security practices.