A BAA Is a Contract, Not a Badge: What Your Software Vendor Is Really Signing Up For

A signed Business Associate Agreement tells you that a vendor has accepted legal responsibility for protected health information. It does not tell you that the vendor is able to meet that responsibility. Treating the two as the same thing is the most common mistake buyers make, and reading the agreement as an engineer would read a specification is the most reliable way to avoid it.

This article is general information for technology and operations leaders. It is not legal advice. The terms of your own agreement and the advice of your counsel govern your situation.

Start with what does not exist

Vendors often describe themselves as "HIPAA compliant" or "HIPAA certified". It is worth being precise about those phrases. The US Department of Health and Human Services, which enforces HIPAA through its Office for Civil Rights, does not certify products or companies and does not endorse any private certification. Third-party assessments and attestations exist, and some are rigorous, but none of them is an official HIPAA seal.

Compliance under HIPAA is a continuing condition of an organization: its policies, its safeguards, its training, its risk analysis, its handling of incidents. Software cannot be compliant on its own. It can only be used in a compliant way, by an organization that has done the surrounding work.

What does exist, and what the regulations require, is a written contract between the party responsible for the data and any outside party that handles it on their behalf. The name for this document is a Business Associate Agreement, usually shortened to BAA.

Who is who

Three terms carry most of the weight.

Protected health information (PHI) is individually identifiable health information held or transmitted by a covered entity or its business associate. A diagnosis linked to a name is PHI. So, in many contexts, is the bare fact that a named person is a patient of a particular clinic. An appointment reminder or a billing record can qualify without containing any clinical detail.

Covered entities are health plans, health care clearinghouses, and health care providers that conduct certain standard transactions electronically.

Business associates are people or organizations that create, receive, maintain or transmit PHI on behalf of a covered entity. A billing company, a hosting provider, a software consultancy with production access, and an analytics vendor processing patient records can all fall into this category.

Two points surprise people.

First, status follows function, not paperwork. A vendor that handles PHI on a covered entity's behalf is a business associate whether or not anyone signed an agreement. The missing agreement is then a violation in itself. It is not an exemption.

Second, the definition reaches downstream. A subcontractor that handles PHI for a business associate is itself a business associate, and so is that subcontractor's subcontractor. The obligations follow the data all the way down the chain.

What the agreement commits the vendor to

The Privacy Rule lists what a BAA must contain. In plain terms, the vendor agrees to the following.

1. Keep every use and disclosure of PHI inside what the contract permits or the law requires. The agreement defines the permitted purposes. Anything outside them is off limits, including the vendor's own analytics, product improvement and marketing, unless the contract and the rules specifically allow it.
2. Apply appropriate safeguards. For electronic PHI this means complying with the Security Rule: administrative, physical and technical safeguards. Since the HITECH Act and the 2013 Omnibus Rule, business associates are directly liable for this under the law, in addition to being bound by contract.
3. Report problems to the covered entity. That covers uses or disclosures the agreement does not permit, security incidents, and breaches of unsecured PHI.
4. Bind subcontractors to the same terms. Any subcontractor that creates, receives, maintains or transmits PHI on the vendor's behalf must agree to the same restrictions and conditions.
5. Support individuals' rights. The vendor must make PHI available so the covered entity can satisfy a patient's right to access their records, to request amendments, and to receive an accounting of disclosures.
6. Open its books to the regulator. Internal practices and records relating to PHI must be available to HHS for determining compliance.
7. Return or destroy PHI when the contract ends, where feasible. Where it is not feasible, the protections continue for as long as the vendor holds the data.

The agreement must also allow the covered entity to terminate if the vendor materially violates it.

Of these, the fourth is the one most often satisfied on paper and missed in practice. A modern application is assembled from other companies' services. If your vendor's system sends PHI to a hosting provider, a managed database, an email or SMS service, an error tracker, a log platform and a language model API, each of those is a link in the chain. Each needs its own agreement, or it must never receive PHI.

What a signed BAA leaves unproven

The agreement allocates liability. It is not evidence about the system. After signing, you still do not know several things.

Whether the safeguards are implemented. The contract says they will be. Evidence comes from elsewhere: an independent security assessment, an audit report such as SOC 2, penetration test results, a documented risk analysis, or your own technical review. None of those is a HIPAA certificate either, but each tells you something a signature cannot.

Where the data physically lives. HIPAA does not, as a general matter, dictate a geographic location for PHI. Your own policies, your customers' contracts or state law may. If location matters to you, including the location of backups and of support staff with access, it has to be negotiated separately.

Which of the vendor's people can open your records. Access controls are mandatory under the Security Rule, but you will not find names or roles written into a BAA. Ask how many people have production access, how it is granted, whether it is time-limited, and whether every access is logged.

How fast you will hear about an incident. The Breach Notification Rule requires a business associate to notify the covered entity without unreasonable delay and sets an outer time limit. Many covered entities negotiate a much shorter window in the agreement, because their own notification duties start running. Read this clause closely, along with the definition of what counts as a reportable "security incident".

What happens to derived data. This is the gap that has widened fastest. Aggregated statistics, search indexes, vector embeddings, cached model inputs, fine-tuned model weights and application logs can all be derived from PHI. De-identification is a defined concept under HIPAA with two recognized methods (removal of a specified list of identifiers, or a formal expert determination), and a business associate may de-identify PHI only if the agreement permits that use. "We anonymize it" is not the same statement. Ask which method, and ask what the contract says about data that has been transformed.

Whether the vendor considers itself outside the rules. Some providers argue that they are a mere conduit, or that they cannot read the data because it is encrypted. The conduit exception is narrow and covers pure transmission services. HHS guidance on cloud computing states that a provider storing encrypted PHI is a business associate even if it does not hold the decryption key. A vendor that maintains your PHI and declines to sign a BAA is giving you a reason to look elsewhere.

AI in the stack raises the stakes

Adding a language model to a workflow that touches patient data creates new places for PHI to land. A prompt containing a clinical note is a disclosure to the model provider. So is a document sent for transcription or summarization.

Before any PHI reaches such a service, establish the following:

• Is the provider willing to sign a BAA for the specific product and configuration you are using? Offerings from the same company can differ.
• Are prompts and outputs retained, for how long, and for what purpose (for example, abuse monitoring)?
• Is your data used to train or improve models?
• Do people at the provider review content, and under what conditions?
• Where do embeddings and caches live, and can they be deleted on termination?

The answers vary by vendor and change over time, so verify them against current contract terms and not against a blog post, including this one.

Questions that separate real controls from reassurance

Precise answers across the board suggest the controls exist and someone owns them. Vagueness on any single row is useful information about where the risk sits.

Read the commercial terms as well. Indemnification, liability caps, insurance and audit rights are not required BAA content, but they decide who pays when something goes wrong.

What changes in the build

Once a system is going to handle patient data, the BAA stops being paperwork and starts constraining the architecture. It is far cheaper to design for it than to retrofit it.

Map the data flows first. Draw every path PHI takes: browser, API, queue, database, cache, backup, export, email, support tool. Most surprises are found at this step, usually in a place nobody thought of as storage.

Treat every third-party service as a decision. Error trackers, product analytics, session replay tools, chat widgets and log aggregators will collect whatever passes through them, including request bodies and form fields. For each one: sign an agreement, or prove PHI cannot reach it. Scrubbing sensitive fields before they leave your system is safer than trusting a setting on someone else's.

Design access around minimum necessary. The standard is not "encrypt everything and move on". It is that each role, human or machine, reaches only the data its task requires. That shapes the data model: separating identifiers from clinical content, scoping queries by tenant and role, and keeping service accounts narrow.

Make audit logging a feature. You need to answer who viewed or changed which record, when, and from where. That means structured, tamper-resistant logs, kept for a period your counsel specifies, and reviewed by someone. Keep PHI out of the general application logs themselves.

Control production access. Named accounts, multi-factor authentication, time-limited elevation, and a record of every session. Use synthetic or properly de-identified data in development and test environments. Copies of production in a developer's laptop are a recurring source of incidents.

Plan for the exit on day one. Know how you would export all PHI in a usable format, and how you would delete it from primary storage, replicas, backups and third-party services.

Rehearse an incident. Detection, containment, assessment, and notification to the covered entity within the contractual window. A plan that has never been run is a guess.

Retrofitting these into a working product means reworking the data model, the logging pipeline and half the vendor list at once. Raising them in the first design conversation costs an afternoon.

Do you know everywhere PHI lands in your system?

If you are building or buying software that will handle patient data, the most useful artifact is a data flow map showing where PHI goes and which vendors sit on each path. Trivo can build that map with you, identify which parties need an agreement, and translate the safeguards into concrete engineering work before the first line of production code.