- A BAA is a liability contract, not a technical safeguard. It doesn't filter data, gate consent, or stop PHI from hitting a vendor's servers. Your tag configuration still has to do that work.
- Google Ads, GA4, the Meta Pixel, and Meta CAPI have no BAA available at any tier. If you're using them on pages where PHI could appear, no amount of paperwork fixes that.
- A signed BAA only covers the specific service listed in it. Google's Cloud BAA covers Cloud Platform. It does not extend to Analytics, Ads, or Tag Manager, even though they share a login.
- Check your vendor list against your BAA list line by line. If a marketing tool touches a page with PHI and isn't on the signed BAA list, that tool needs to come off the site, not get a policy update.
A health system's compliance team asked me to review their marketing stack after a routine audit flagged "potential PHI exposure in third-party tools." Their response was to email their agency: "Do we have BAAs with our vendors?"
The agency said yes. They had a signed BAA with their EHR vendor, their patient portal provider, and their fax-to-email service. All current. All filed correctly.
None of that covered the problem. The flagged exposure was Meta Pixel firing on a symptom-checker quiz, sending page URLs like /symptom-checker/results?condition=chest-pain to Facebook on every submission. There is no BAA available for the Meta Pixel. There never has been. The compliance team had BAAs for tools that weren't the problem, and no BAA for the tool that was.
This mix-up is common. Teams treat "we have a BAA" as a finish line instead of one item on a longer checklist. A BAA covers a specific relationship with a specific vendor for a specific service. It does not cover your tag configuration, your URL structure, or your consent banner.
What a BAA Actually Is
A Business Associate Agreement is a contract required under HIPAA whenever a vendor (the "business associate") creates, receives, maintains, or transmits PHI on behalf of a covered entity. It's not a security certification. It's not a technical audit. It's a legal document that assigns liability and obligates the vendor to specific safeguards.
The BAA typically covers:
- The vendor's obligation to implement safeguards for PHI (encryption at rest, access controls, breach notification timelines)
- What the vendor is permitted to do with PHI (only what's needed to provide the contracted service)
- Breach notification requirements (usually 60 days under HIPAA, though many BAAs specify faster timelines like 10-15 days)
- Subcontractor requirements (if the vendor uses a sub-processor that touches PHI, that sub-processor needs its own BAA)
- Termination provisions (what happens to PHI if the relationship ends)
None of that touches your implementation. A BAA with a hosting provider doesn't stop your developer from hardcoding a chat widget that captures form input before consent loads. A BAA with an email platform doesn't stop your GTM container from pushing a patient's search query to a conversion tag.
Signing a BAA means the vendor is contractually obligated to protect PHI and notify you of breaches. It does nothing to prevent misconfigured tracking from sending PHI to a vendor in the first place. The BAA and the tracking implementation are two separate problems that require two separate fixes.
The BAA Only Covers the Service Named In It
This is the part that trips up marketing teams working with the two biggest platforms.
Google signs BAAs for Google Workspace and Google Cloud Platform. If your organization uses Gmail, Google Drive, or BigQuery under a Cloud BAA, those services are covered for PHI handling, assuming you've configured them correctly.
Google does not sign a BAA for Google Analytics (GA4), Google Ads, or Google Tag Manager. There is no tier, no enterprise contract, no workaround. I've had marketing directors tell me "we have a BAA with Google" as if that covers everything under the Google umbrella. It doesn't. The BAA names the specific service. GA4 isn't on it, no matter how many other Google products you have under contract.
Meta is simpler because there's nothing to misread: Meta does not offer a BAA for the Pixel, Conversions API, or Business Manager, at any tier, for any account size. If PHI could reach Meta through your tracking, there is no contract that makes that acceptable. The tool has to come off pages where PHI could appear, full stop.
Pull your signed BAAs and read the scope section. It will list specific products or services, not "everything this company offers." If GA4, Google Ads, or Meta Pixel aren't named, they aren't covered, even if you have another agreement with the same parent company.
Same logic applies further down the vendor list. HubSpot signs BAAs for its Enterprise tier CRM and marketing hub, but the specific data flows covered depend on the contract terms you negotiate, not a blanket assumption. Mailchimp, as of recent terms, does not offer BAAs at all. Hotjar, FullStory, and most session-recording tools don't either. If you're running any of these on a page that touches PHI, a BAA conversation with the vendor isn't going to solve it. The tool doesn't qualify for a BAA because the vendor doesn't operate at the compliance tier needed.
What Still Breaks Even With a Signed BAA
Say you've done the vendor-side work. You have a Cloud BAA with Google, and you're routing analytics through BigQuery instead of GA4. You've replaced Meta Pixel with a server-side integration through a HIPAA-eligible platform. The BAAs are signed and filed.
Your tracking can still leak PHI.
URL parameters. A BAA doesn't inspect what data you're sending. If your server-side tagging setup forwards the full page URL, and that URL is /appointments/confirm?provider=dr-chen&specialty=oncology, you're still transmitting PHI through a covered vendor relationship, just without an unauthorized third party involved. The BAA covers the vendor's handling of it. It doesn't mean you should be sending it at all, and unnecessary PHI transmission is itself a minimum-necessary violation.
Consent gating. A signed BAA with an analytics vendor doesn't require that vendor to check user consent before receiving data. That's your job, configured in your tag manager, enforced before the request leaves the browser or your server.
Sub-processors. If your BAA-covered vendor uses a sub-processor (a CDN, a queueing service, a data warehouse) that also touches PHI, that sub-processor needs its own BAA. Most marketing teams never check this. I've seen a BigQuery setup that was technically covered under Google's Cloud BAA, feeding into a third-party BI tool for dashboarding that had never signed anything.
Hardcoded scripts. A BAA with your tag management platform doesn't cover a <script> tag a developer pasted directly into the page template six months ago that bypasses the tag manager entirely. Nobody remembers it's there until an audit finds it.
The Checklist That Actually Matters
Skip the "do we have a BAA" question. Ask these instead:
- List every vendor receiving data from any page where PHI could appear. Not just analytics and ads. Chat widgets, heatmap tools, form platforms, CDNs.
- Pull the signed BAA for each one and check the named services. Confirm the specific tool you're using is listed, not just the parent company.
- For any vendor without a BAA, or without the specific service covered, remove the tool from PHI-adjacent pages. No exceptions, no "we'll add it to next quarter's contract renewal."
- For vendors with a valid BAA, check what data is actually being sent. Open DevTools, look at the request payload, confirm you're not forwarding URL paths, form field values, or query parameters that constitute PHI.
- Check sub-processors. Ask each BAA-covered vendor which downstream services touch the data. Get BAAs for those too, or stop using features that route through them.
A BAA tells you who's liable if something goes wrong. It doesn't tell you whether something is going wrong right now. That second question only gets answered by opening the network tab and looking at what's actually being sent, vendor by vendor, page by page.
Run the vendor list against the BAA list this week. Anything without a match comes off pages where PHI can appear, before the next audit finds it for you.