1. The list
Verified against vendor documentation on 6 August 2026. Where we could not confirm a current position we have said so rather than guessed — a wrong “yes” in this table is worse than a blank.
| Vendor | Signs a BAA? | What to know |
|---|---|---|
| Google Workspace | Yes — paid editions | Accepted by a super admin in Admin console → Account settings → Legal and compliance. Free and personal accounts never qualify. |
| Google Cloud (GCP) | Yes — separate agreement | A different BAA from Workspace, with its own covered-services list. Signing one does not cover the other. |
| AWS | Yes — self-serve | Available through AWS Artifact. Only HIPAA-eligible services may handle PHI. |
| Stripe | No | Stripe’s documented position is that it is not a business associate and does not offer a BAA. Payment card data alone, isolated from clinical information, is generally not PHI — but nothing clinical may go in metadata, descriptions or receipts. |
| Zoom | Yes — eligible plans | Requires a healthcare or eligible business/enterprise plan, not the free tier. |
| Twilio | Yes — via sales | Not self-serve, and scoped to specific products. Name the products you will use with PHI when you ask. |
| Supabase | Yes — paid tiers | A fully executed BAA covering the services and regions you use is required before any ePHI. |
| Square | Verify directly | Treat payment-only scope the same way as Stripe and confirm the current position before assuming either answer. |
| Calendly | Verify directly | Could not confirm a current published position. Ask before any appointment data with clinical detail goes near it. |
Vendor positions change. This table is a starting point and a prompt for the right questions — not a substitute for getting the executed agreement in your own hands. If a vendor is material to your operation, ask them in writing and keep the reply.
2. The four traps
1. “HIPAA compliant” on a marketing page is not a BAA
The phrase appears constantly and means nothing on its own. Encryption, access controls and SOC 2 are all good, and none of them is a business associate agreement. The only question that matters is whether the vendor will execute one. Ask that question in those words.
2. One company can have several BAAs
The clearest example is Google: the Workspace BAA and the Google Cloud BAA are separate agreements, accepted in different consoles, covering different services. A clinic that accepted one and assumed it covered the other has a gap it does not know about. The same pattern appears wherever a vendor sells distinct product lines.
3. Coverage is scoped to a list, not to the company
Almost every BAA covers named services only. Using an unlisted feature from a covered vendor puts you outside the agreement while feeling exactly the same. Find the covered-services list, not just the BAA.
4. Signing is the beginning
A BAA does not configure anything. Most vendors publish an implementation guide describing the settings required for their agreement to mean what you think it means — restricting non-covered services, enforcing MFA, controlling sharing, setting retention. Default settings are rarely compliant settings.
3. The payments exception worth understanding
Payment processors are the most common source of confusion, because the honest answer is not simply “no, therefore forbidden”.
Card data on its own — a number, an amount, a name on a card — is not protected health information. That is why a clinic can legitimately use a processor with no BAA to take payment. The exposure appears the moment clinical context travels alongside it: a medication name in a line item, a diagnosis in a description field, a treatment in a receipt or a webhook payload.
The practical control is at the boundary. Send the processor an amount and an internal reference, never a clinical description. If your EMR writes “Semaglutide 1.0mg — weight management” into a payment descriptor, that is a design decision someone made and it should be changed.
Related: transaction descriptors should carry the clinic name only, never medication names. A drug name on a patient’s bank statement is both a privacy problem and an unnecessary invitation to card-brand scrutiny.
4. How to ask, so you get a usable answer
Send this, in writing, and file the response:
1. Will you execute a HIPAA business associate agreement with us? 2. Which plan or tier is required? 3. Which of your services does it cover, and where is that list published? 4. Where do we accept or countersign it? 5. Do you publish an implementation guide for the settings it assumes?Then keep a register: vendor, status, date signed, where the executed copy lives, and who owns the relationship. Sign proactively, before onboarding a client who will ask — a per-client scramble is how vendors end up in production without paper.
This is not legal advice. It is what we have learned building software for prescribing clinics, written down plainly because almost nobody publishes it. Fee schedules and federal rules change — every figure here was checked on 6 August 2026 and linked to its source. Confirm the live position with the regulator, the vendor, or your own counsel before you act on it.
5. Frequently asked questions
Does Stripe sign a BAA?
No. Stripe’s documented position is that it does not act as a business associate and does not offer a BAA. Using it for payments is generally acceptable because card data isolated from clinical information is not PHI — but no clinical detail may travel in metadata, descriptions, receipts or webhooks.
Does Google sign a BAA?
Yes, on paid plans — and there are two. The Google Workspace BAA is accepted in the Workspace Admin console under Account settings, Legal and compliance. Google Cloud has a separate agreement with its own covered-services list. Signing one does not cover the other.
Is a vendor saying they are “HIPAA compliant” enough?
No. That phrase has no fixed meaning and is not an agreement. Ask specifically whether they will execute a BAA, on which tier, and covering which services.
Do I need a BAA if I am a cash-pay clinic?
It depends on whether you are a covered entity, which is a narrower test than most cash-pay clinics assume. We cover it in a separate article — but note that your obligations to patients under state law exist regardless of the federal answer.
What if a vendor will not sign one?
Then PHI must not reach that vendor. Sometimes the fix is architectural rather than a switch — tokenise, send a reference instead of a description, and keep clinical context on your own systems.
How often should the register be reviewed?
At least annually, and whenever you add a vendor or change a plan tier. Coverage is frequently tier-gated, so a downgrade can silently end an agreement.