What Is a Business Associate Agreement (BAA)?

Key takeaways

A Business Associate Agreement (BAA) is a contract HIPAA requires before any outside vendor can store, transmit, or even touch your patients’ or clients’ health information.
It makes the vendor legally accountable for protecting that data and for reporting breaches. Without it, putting protected health information on that tool is a HIPAA violation, no matter how secure the tool is.
The fastest way to vet any tool for healthcare work: ask “will you sign a BAA?” If the answer is no, you can’t use it for protected data. Full stop.
One unsigned vendor anywhere in your stack breaks compliance for the whole chain. Encryption is a security control; a BAA is the legal one. You need both.

If you run anything in healthcare and you’ve started looking at software, you’ve hit the term: BAA. It shows up in vendor docs, sales calls, and every “is this tool HIPAA compliant?” thread online. It’s also the single concept that decides whether a tool is even allowed to touch your data, so it’s worth understanding properly.

A Business Associate Agreement is a contract required by HIPAA between you (a healthcare provider or “covered entity”) and any third party that will handle protected health information on your behalf. That third party is the “business associate” the name comes from. The BAA is what legally binds them to protect that data the way HIPAA demands, and to tell you if something goes wrong. No signed BAA means that vendor cannot legally hold your data, period.

Here’s what a BAA actually does, who needs one, and the part most people get wrong: which common vendors will and won’t sign one.

What a BAA actually does

HIPAA splits the world into two roles. A covered entity is the provider, plan, or clearinghouse that owns the relationship with the patient. A business associate is any outside company that handles protected health information (PHI) to do work for that covered entity: your cloud host, your billing tool, your email service, the developer who built your portal.

The moment a vendor touches PHI on your behalf, HIPAA treats them as a business associate, and the law requires a signed contract before that happens. That contract is the BAA. It does three things:

Pins down responsibility. The vendor agrees in writing to safeguard PHI under HIPAA’s Security and Privacy Rules, not just their own terms of service.
Creates breach accountability. If the vendor has a breach, they’re contractually and legally on the hook to report it to you within a set window so you can meet your own breach-notification duties.
Limits use. The vendor can only use the data to perform the service you hired them for. They can’t mine it, resell it, or repurpose it.

A BAA is a legal control. Encryption, access logs, and SOC 2 reports are security controls. People constantly confuse the two. A vendor can have flawless encryption and still be illegal to use for PHI if they won’t sign a BAA, because HIPAA requires the legal accountability, not just the technical safeguards.

Who needs a BAA, and when

You need a BAA with a vendor whenever that vendor will store, transmit, process, or even just have access to PHI in the course of working for you. A few things people miss:

It applies even if the vendor never “looks at” the data. A cloud host that stores encrypted PHI it can’t read still needs a BAA, because it holds the data.
It applies to subcontractors too. If your business associate uses another vendor that touches PHI, that chain needs BAAs all the way down.
PHI is broader than diagnoses. A name tied to an appointment date and a provider is PHI. The fact that someone is a patient at all is protected. So the threshold for “this vendor touches PHI” is lower than most people assume.

If a vendor genuinely never touches PHI, you don’t need a BAA with them. The hard part is that in a connected system, more tools touch PHI than you’d think.

Which vendors will and won’t sign a BAA

This is where healthcare teams get tripped up, because the answer doesn’t track with how big or “secure” the company is. Some specifics that hold true as of 2026 (always confirm in writing, because vendor policies change):

Will sign, on the right plan:

AWS, Google Cloud, Microsoft Azure sign BAAs, but only specific HIPAA-eligible services are covered. A BAA with AWS does not bless every AWS service. Confirm each one you use is on the eligible list.
Stripe signs a BAA for payments and invoicing, which makes it the cleaner path when a payment ties to a patient or a health service.
Twilio and some other communication providers sign BAAs for HIPAA-eligible messaging, though you have to configure the eligible products.
Anthropic (Claude) and OpenAI sign BAAs for their enterprise API tiers with the right agreement. The consumer apps (ChatGPT.com, Claude.ai) do not. So AI on PHI is possible, but only through the right door.

Will not sign (so they can’t hold PHI):

QuickBooks does not sign BAAs, which rules it out the moment an invoice ties a payment to a patient or a health-related service.
Zapier does not sign a BAA on any plan, and its native storage runs on non-eligible infrastructure. The convenient “just Zap it over” step is a very common place PHI quietly leaks out of an otherwise-compliant stack.
Most consumer email tools and default transactional senders don’t qualify either.

The pattern: capability and security don’t decide it. The willingness to sign the contract does. That’s why “will you sign a BAA?” is the first question to ask any vendor, before you evaluate features.

One unsigned link breaks the whole chain

This is the trap that catches teams who did the hard part right. You can pick a compliant database, a compliant host, a compliant portal, and still be non-compliant because one tool in the data flow doesn’t have a BAA.

Walk the path your data actually takes: the app, the database, the host, email and SMS notifications, payments, the automation glue connecting them, any AI feature. Every stop that touches PHI needs its own signed BAA. Miss one and the whole stack is non-compliant, no matter how clean the rest of it is. We go deep on this stack-by-stack in our guide to building a HIPAA compliant portal, which names the specific tools that pass and fail at each layer.

A few common questions

Is a BAA the same as a terms of service or a DPA? No. A terms of service governs general use. A Data Processing Agreement (DPA) is a GDPR concept for personal data. A BAA is HIPAA-specific and carries HIPAA’s exact obligations. A vendor offering a DPA but not a BAA hasn’t met the HIPAA requirement.

The vendor says they’re “HIPAA compliant” or “HIPAA ready.” Is that enough? Those phrases mean nothing on their own. The only question that matters is whether they will sign a BAA. Ask directly and get the signed document. Don’t accept a sales rep’s or a support chatbot’s word for it.

Do I need a BAA if I’m a small practice? Yes. HIPAA’s requirements don’t scale with your size. A solo practice using a vendor that touches PHI needs the same BAA a hospital would.

What happens if we skip it? Using a vendor without a required BAA is itself a HIPAA violation, separate from any breach. If a breach then happens through that vendor, you have far less protection and far more exposure.

If you’re standing up healthcare software and trying to figure out which vendors you actually need BAAs with, that’s exactly the mapping we do for clients building HIPAA-aware systems and client portals. The stack-level walkthrough is in our HIPAA compliant portal guide, and if you’re weighing AI on protected data specifically, that lives in our AI implementation work. Want a second opinion on your own stack? Book a call and we’ll tell you where the gaps are.