No, Google Analytics is not HIPAA compliant, and unlike a lot of privacy questions, you cannot configure your way to a yes. Google will not sign a Business Associate Agreement for Analytics, and its own terms forbid sending protected health information to it. That is the short answer. The longer one matters more, because most of what a healthcare site actually uses Google Analytics for is not health information, and there the real obligation is consent. This page draws that line: where Google Analytics is a hard no, where it is a consent problem you can solve, and where a consent platform does and does not help.
Key Takeaways
- 01No. Google Analytics is not HIPAA compliant, and it cannot be configured into compliance for protected health information. Google will not sign a Business Associate Agreement for Analytics and prohibits sending PHI to it.
- 02There are really two problems. On pages that can expose PHI, like patient portals, scheduling, and intake forms, Google Analytics has to be removed. On ordinary marketing pages, the obligation is consent: GA should not fire until the visitor agrees.
- 03Google's own guidance points site owners to a Consent Management Platform to collect and honor that consent. A CMP does not make GA HIPAA compliant. It governs when GA is allowed to run.
- 04ConsentStack gates Google Analytics until consent, keeps it off on Reject, and offers a self-serve BAA on its $79 a month Business plan for the consent layer it operates, not for GA itself. The free scanner shows which trackers fire before consent.
Is Google Analytics HIPAA compliant?
No. For any page that touches protected health information, called PHI, Google Analytics is not an option, and no setting changes that. Two facts put it out of bounds. Google refuses to sign a Business Associate Agreement, a BAA, for Analytics, and HIPAA requires one with every vendor that handles PHI on your behalf. On top of that, Google's own Analytics terms prohibit sending PHI to the service at all. So the path of configuring your way to compliant, the one that works for the GDPR version of this question, is closed here. There is no configuration that makes Google Analytics lawful for PHI.
That is narrower than it sounds, though. HIPAA only governs protected health information. A clinic's public homepage, its blog, a careers page: those usually carry no PHI, and Google Analytics on them is a consent question, not a HIPAA violation. The trouble starts on the pages where health information and tracking meet.
Why Google Analytics cannot be made HIPAA compliant for PHI
It comes down to two things HIPAA treats as non-negotiable, and Google declines both.
First, there is no BAA on offer. HIPAA requires a signed Business Associate Agreement with any third party that creates, receives, or maintains PHI for you. Google states plainly that it will not enter one covering Google Analytics. Without that contract, there is no lawful way to let Analytics touch PHI, no matter how the tool is configured.
Second, PHI is prohibited outright. Separate from the BAA question, Google's Analytics terms ban sending protected health information to the service. Data that looks harmless in a report, the full URL of a scheduling flow, an IP address captured on a patient portal, can count as PHI once it is tied to someone's care. That is exactly the kind of data Analytics collects by default.
HIPAA compliance for any vendor starts with a signed BAA. Because Google will not sign one for Analytics, there is no version of GA plus the right settings that clears the bar for protected health information. That is what makes HIPAA different from GDPR here. Under the GDPR, a correctly configured GA4 can run lawfully. For HIPAA and PHI, the answer stays no.
Where Google Analytics puts healthcare sites at risk
The risk is not spread evenly across a site. It concentrates on the pages where a visitor's activity reveals something about their health. Federal health regulators have said as much in guidance on the use of online tracking technologies, warning that tools like Google Analytics embedded on pages that handle health information can disclose PHI to third parties without a person's authorization. In practice, it becomes a page-by-page judgment.
| Page type | PHI risk | What to do |
|---|---|---|
| Public marketing pages (home, blog, careers) | Low, usually no PHI | Keep GA, but only behind consent. This is a consent obligation, not a removal one. |
| Symptom checkers and condition pages | Elevated: the page itself signals a health concern | Treat as PHI-adjacent. Keep Google Analytics and ad tags off. |
| Appointment scheduling and intake forms | High: ties a person to seeking care | Remove Google Analytics. No configuration makes this compliant. |
| Patient portals and logged-in areas | High: protected health information by definition | Remove Google Analytics entirely. |
The test is whether the page, combined with what Analytics captures, can reveal that a specific person is seeking or receiving care. When it can, there is no BAA to cover it, so the tag has to come off.
The part most sites get wrong: consent on the pages GA can stay
On the marketing pages where Google Analytics is allowed to stay, HIPAA is not the active concern, but privacy consent still is. Those visitors are protected by state privacy laws and by Google's own consent requirements, and Analytics should not fire until they agree. Google is direct about how to handle it: its guidance tells site owners to use a Consent Management Platform to collect consent and pass each visitor's choice to Analytics.
That splits the healthcare tracking problem cleanly in two, and the halves have different fixes.
| The problem | The fix |
|---|---|
| Google Analytics on pages that can expose PHI | Remove it. There is no compliant configuration and no BAA to fall back on. |
| Google Analytics on ordinary marketing pages | Gate it behind consent so it holds until the visitor agrees and stays off on Reject. |
How to handle Google Analytics on a healthcare website
Putting both halves together, here is the order that works:
- Map your pages. Flag anything that could expose PHI: patient portals, appointment scheduling, intake and eligibility forms, symptom or condition pages, and any logged-in area.
- Remove Google Analytics and advertising tags from those pages. This is the step with no substitute, and no setting stands in for it.
- On the remaining marketing pages, put Analytics behind a consent banner so it does not load until the visitor opts in, and stays off when they click Reject.
- Wire up Google Consent Mode v2 so a decline still models conversions instead of leaving you blind.
- If you need analytics on pages that handle PHI, use a tool built for healthcare that will sign a BAA. Google Analytics is not one of them.
- Get a BAA from every vendor that handles PHI or operates part of your data and consent layer, and name your tracking in your privacy policy. Here is which consent tools actually sign a BAA.
How ConsentStack fits
ConsentStack is a consent platform, so it does not replace Google Analytics or turn it into a HIPAA-safe tool. What it does is govern when Analytics and other tags are allowed to run. It holds them until a visitor consents, keeps them off when someone clicks Reject, and ships Google Consent Mode v2 by default, which covers the consent half of the problem across your marketing pages. It is the same consent layer behind our setup for healthcare and wellness sites.
It also signs a Business Associate Agreement, and does it differently from most of the market. Instead of an enterprise contract and a procurement cycle, the BAA comes with the $79 a month Business plan and is issued on request. Be clear on what it covers: ConsentStack as your business associate for the consent layer it operates, across your properties. It does not cover Google Analytics, and no consent tool's BAA can, because Google will not sign one for GA.
And a BAA on its own, from us or anyone else, does not make a site HIPAA compliant. HIPAA is a whole program of safeguards, training, and agreements. The consent layer is one piece of it, and it is the piece ConsentStack takes off your plate.
Check what your site sends before consent
Before you change anything, see what your site does right now. Run it through our free compliance scanner and it will show you exactly which trackers, Google Analytics included, fire before and after someone clicks Reject. It takes about a minute and does not ask for an email. That report is the fastest way to find where Analytics is loading that it should not be.
Google Analytics and HIPAA FAQ
No. Google will not sign a Business Associate Agreement for Google Analytics, and its terms prohibit sending protected health information to the service. For any page that handles PHI, Analytics cannot be used, and no configuration changes that.
No. Google offers BAAs for parts of Google Workspace and Google Cloud, but explicitly not for Google Analytics. HIPAA requires a signed BAA with any vendor that handles PHI, so without one, GA is off limits for those pages.
No, not for protected health information. Settings like IP masking and shortened retention reduce data, but they do not create a BAA or lift Google's ban on PHI. On pages that can expose PHI, Google Analytics has to be removed.
No. A CMP governs when Analytics is allowed to run and holds it until a visitor consents, which solves the consent obligation on ordinary marketing pages. It does not make GA safe for PHI, and it does not replace removing GA from pages that handle health information.
Use an analytics tool designed for healthcare that will sign a BAA, and keep it off any page unless that BAA and your safeguards are in place. Many teams keep Google Analytics on their public marketing pages, behind consent, while using a separate HIPAA-eligible tool elsewhere.
No. The move to GA4 did not change Google's position. Google still will not sign a BAA for Analytics and still prohibits PHI, so GA4 is no more usable on PHI pages than Universal Analytics was.
See what fires before anyone clicks Accept
Run a free compliance scan and see exactly which trackers, including Google Analytics, load before and after Reject. No signup.
Related Posts
Which Cookie Consent Tools Sign a BAA? (2026)
Most cookie banners won't sign a BAA, and the ones that do usually gate it behind an enterprise contract. Here's who signs one, what it takes, and how ConsentStack does it on a published $79/mo plan.
Is Google Analytics GDPR Compliant? (2026)
Not by default. GA4 can be used lawfully in the EU, but only if you get consent before it fires, run Consent Mode v2, accept Google's data terms, and rely on the Data Privacy Framework. Here is the full checklist, and the one step most sites get wrong.
A Consent Management Platform (CMP) May Be Blocking Tags: What It Means and How to Fix It
Seeing "A Consent Management Platform (CMP) may be blocking tags" in Google Tag Assistant? It usually means your CMP is working correctly. Here is when it is a real problem, and how to fix it.