Is Looker Studio HIPAA Compliant? Reporting Risks

No, Looker Studio is not HIPAA compliant in the way most healthcare marketers assume. Google does not list Looker Studio among the products covered by its Google Cloud HIPAA BAA, and the standalone Looker Studio business associate addendum is no longer available to new customers. That does not make Looker Studio unusable in healthcare. It makes the question one of what you put in the dashboard. Curve is the HIPAA-compliant tracking and attribution layer that produces reportable marketing data without protected health information in it, with a signed BAA on every plan.

The direct answer, in more detail

Google's HIPAA program works by list. The Google Cloud BAA covers Google's infrastructure plus an enumerated set of covered products, and Google's own guidance to customers is blunt about what happens outside that set: disable or otherwise ensure that you do not use Google Cloud products that are not explicitly covered by the BAA when working with PHI.

Read that list and you find Looker, described as Google Cloud core. You do not find Looker Studio. They are different products with confusingly similar names, and only one of them is on the list.

There is history here that muddies the picture. Google previously published a product-specific business associate addendum for Looker Studio, back when it was called Data Studio, along with a HIPAA implementation guide. That guide still exists and still tells customers they must execute a Google Cloud Platform BAA before using the product with PHI. The addendum itself defined its covered services to include Looker Studio but to exclude Looker Studio Pro. And Google's documentation now states that the previous Looker Studio BAA can no longer be accepted by new customers.

The practical result for a healthcare organization signing up today is that there is no clean, self-serve path to bring Looker Studio under a BAA. If you are an existing customer who accepted the older addendum, your position is genuinely different from a new customer's, and you should confirm the current scope with your Google account team rather than relying on any article, including this one. Google's public documentation on this point is not internally consistent, which is exactly the situation where you get the answer in writing from the vendor before you build on it.

Looker, Looker Studio, and Looker Studio Pro are three different answers

The naming is doing real damage in healthcare marketing teams, so it is worth separating carefully.

• Looker (Google Cloud core) is the enterprise business intelligence platform. It is provisioned as a Google Cloud service, it sits inside your Google Cloud project, and it appears on Google's HIPAA covered products list.
• Looker Studio is the free, self-serve dashboard tool that anyone with a Google account can open in a browser. It was called Data Studio until 2022. It is not on the covered products list.
• Looker Studio Pro adds team workspaces, content management, and Google Cloud support on top of Looker Studio. The legacy addendum explicitly excluded it from covered services, so paying for Pro does not buy BAA coverage.

A marketer who reads "Looker is HIPAA eligible on Google Cloud" and then opens lookerstudio.google.com has not used the product that sentence was about. That single confusion is the most common way PHI ends up in an uncovered dashboard.

Where Looker Studio is genuinely fine

Most healthcare marketing reporting does not involve PHI at all, and Looker Studio handles it well. Campaign names, ad group structure, spend, impressions, clicks, cost per acquisition, conversion counts, channel mix, and month-over-month trend lines are aggregate business metrics. An aggregate count of appointments booked is not protected health information. A row per patient is.

That is the whole line, and it is a useful one because it is easy to test. Ask of every field in the report: can this be traced to one identifiable person, and does it say something about that person's health, care, or payment for care? If both answers are yes, it does not belong in Looker Studio.

Three ways teams cross that line without noticing:

• Row-level CRM exports. Someone connects a Google Sheet of leads so the team can see which ones converted. The sheet has names, emails, phone numbers, and the service line requested. That is a patient list in a dashboard tool with no BAA behind it.
• Landing page URL dimensions. A page path report is harmless on a plumbing site. On a clinic site where the slug names the condition, every row is a statement about what a visitor was looking for, and it becomes a disclosure the moment it sits next to anything identifying.
• Free-text form fields. Any report that surfaces "tell us what brings you in" answers is surfacing clinical narrative, often the most sensitive text in the entire stack.

Filter and segment definitions deserve a mention of their own. If a saved dashboard filter is named after a specific medication or diagnosis, the report structure itself encodes clinical meaning before a single row loads.

What a BAA does and does not cover here

Suppose Google did extend BAA coverage to Looker Studio tomorrow. It would not solve the problems that actually bite reporting teams, because a BAA governs the vendor's handling of data, not your handling of it.

A BAA does not cover who you share the dashboard with. Looker Studio's sharing model is built for frictionless distribution: link sharing, broad access settings, scheduled email delivery of report PDFs to whoever is on the list. Scheduled delivery is particularly easy to get wrong, because the recipient list outlives the person who created it. A report emailed weekly to an agency distribution list is a standing disclosure that no contract repairs.

A BAA also does not fix Looker Studio's credential model. Data sources can run under the owner's credentials, which means every viewer of the report reads the underlying data with the owner's level of access. That is convenient and it is the opposite of the minimum necessary standard. Access control is a HIPAA requirement in its own right, independent of whether the vendor has signed anything.

Community connectors are a third gap. They are built by third parties, they authenticate to your systems, and they are entirely outside any agreement you have with Google. Every connector in a healthcare reporting stack is a separate vendor question.

The general principle is worth stating plainly, because it applies far beyond this one product. A BAA is a contract, not a control. It allocates liability and imposes obligations. It does not stop anyone from pasting a patient list into a dashboard.

The architecture that works

The workable pattern is to keep the identity layer out of the reporting layer, and to do the aggregation before the data reaches Looker Studio rather than inside it.

• Aggregate at the source. Whatever system holds patient-level records should emit counts, not rows. If Looker Studio never receives an identifier, the sharing model stops mattering.
• Name events neutrally. A conversion called "consultation request" reports just as well as one that names the treatment, and it does not turn a chart legend into a clinical statement.
• Run two dashboards, not one. Clinical and operational reporting belongs in a system whose vendor has signed a BAA. Marketing performance reporting belongs in the marketing stack. The temptation to join them into one executive view is where most exposure originates.

The failure mode is always convenience creep. Someone adds an email column so the report can be deduplicated. Someone adds a service-line breakdown so the team can see which offers work. Each step is small, sensible, and cumulative.

Where the ad tracking problem shows up

Looker Studio sits at the end of the pipeline, which means by the time a compliance problem is visible in a dashboard, the disclosure has usually already happened upstream.

Think about what feeds the report. Google Ads. GA4. A Meta connector. Your CRM. If the site is running a standard Meta Pixel or a raw Google tag, condition-revealing page URLs and a persistent browser identifier have already gone to platforms that do not sign BAAs for their advertising products. Meta and Google are explicit about this. The report is downstream of a disclosure that already occurred.

This is the mechanism behind healthcare pixel litigation that has cumulatively crossed $100 million in settlements, including Advocate Aurora at roughly $12.225 million. The plaintiffs' theory does not require that a diagnosis was transmitted. It requires that an identifiable person's health interest was disclosed to a third party. A page path plus a browser identifier does that on its own.

GA4 deserves specific attention because it is the most common Looker Studio data source in healthcare. GA4 is not covered by a BAA either. A Looker Studio dashboard built on GA4 is a report about data that was already handed to an ad and analytics platform. Fixing the dashboard without fixing the collection layer is rearranging the furniture. We cover the collection side in detail in our piece on why client-side pixels create HIPAA exposure and what server-side tracking changes.

How Curve produces reporting data that is safe to chart

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare. It sits where the pixel used to sit, so the decisions about what data exists get made before anything reaches a reporting tool.

The Curve tracking script installs in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure rather than straight to the ad platforms. From there:

• Per-destination field mapping controls what forwards. Only fields you explicitly map reach a given destination, configured separately for each one. The default is that nothing goes, so page URLs, form field values, and service-line detail stay behind unless you deliberately send them.
• Identifiers are hashed. Email, phone, and name are SHA-256 hashed to meet each platform's conversion API requirements before forwarding.
• Neutral event aliases replace descriptive names. The ad platform, and every report built on ad platform data, sees a generic conversion name rather than the service line.
• PHI-pattern detection monitors payloads. Curve flags PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences. This is a monitoring layer that tells you when something upstream changed. The protection itself is the field mapping plus the hashing.
• Bridge tokens preserve attribution across handoffs. When a patient clicks out to a separate booking or intake tool, attribution normally breaks at the moment it becomes valuable. Bridge tokens carry it across.
• Offline conversion uploads close the loop. Bulk CRM or EHR outcomes match back to the original ad click by click ID, so revenue reporting does not require exporting a patient list anywhere.

Curve also includes its own analytics dashboard, Google Ads campaign reporting with reconciliation between what Curve sent and what Google received, and Google Search Console reporting. For a lot of healthcare marketing teams that removes the reason to build a Looker Studio dashboard at all, and where you still want one, you are exporting aggregates rather than rows. Every Curve plan includes a signed BAA.

What to check in your own reporting stack

1. Open every data source in every report and read the field list, not the chart. Charts hide columns that the underlying source still carries.
2. Check the sharing settings and the scheduled delivery lists. Look specifically for link-based access and for recipient lists nobody has reviewed in a year.
3. Check whose credentials each data source uses. Owner credentials mean viewers inherit the owner's access.
4. Inventory community connectors and treat each vendor as its own contractual question.
5. Read your page path report as a stranger would. If a slug names a condition or medication, that is a disclosure every time it travels with an event.
6. Watch the network tab during a test visit and read what actually leaves for ad platform domains. Our free compliance scanner does the first pass of this automatically.
7. Confirm your conversion tracking is server-side before you worry about the dashboard. See our walkthrough of HIPAA-compliant conversion tracking setup across Google, Meta, and Microsoft.

Frequently asked questions

Is Looker Studio covered by the Google Workspace BAA?

No. Google's Workspace BAA covers a defined list of included functionality and explicitly does not extend to Additional Google Services. Looker Studio is not part of Workspace's covered functionality, so having a Workspace BAA in place tells you nothing about Looker Studio.

Does Looker Studio Pro change the answer?

Not favorably. The legacy Looker Studio business associate addendum defined its covered services to include Looker Studio while specifically excluding Looker Studio Pro. Paying for the Pro tier buys team management and support, not BAA coverage.

Can I use Looker Studio if I only report aggregate numbers?

Generally yes, and that is how most healthcare marketing teams should use it. Aggregate counts that cannot be traced to an identifiable individual are not PHI. The discipline required is ongoing, because the pressure to add one more identifying column never goes away.

Is connecting GA4 to Looker Studio a HIPAA problem?

The connection is not the problem. The collection is. GA4 is not covered by a BAA, so if condition-revealing URLs and identifiers reached GA4 in the first place, the disclosure already happened upstream of the dashboard. Fix the tracking layer first.

What about community connectors and third-party data sources?

They are separate vendors with separate terms and no coverage under anything you have signed with Google. If a connector touches data that could identify a patient, you need that connector vendor's own BAA, and most of them do not offer one.

Can I make it safe by restricting the dashboard to internal staff only?

Restricting access is genuinely worth doing, and it is not the same as compliance. HIPAA governs what data you may disclose to a vendor, not only who sees a screen. If the report causes PHI to be processed by a system with no BAA, tightening the viewer list does not resolve that.

Where to start

Looker Studio is a good marketing reporting tool that Google has not brought under its HIPAA program, and the older product-specific addendum is closed to new customers. Treat it as an aggregate-only surface, keep patient-level rows out of it entirely, and confirm current terms with Google directly if your situation depends on the answer.

The deeper fix is upstream. If the data flowing into your reports was collected by pixels that already sent condition-revealing URLs and browser identifiers to Meta and Google, the dashboard was never the exposure. Curve replaces that collection layer with server-side tracking, per-destination field mapping, hashed identifiers, and neutral event aliases, then gives you campaign reporting and reconciliation without a patient list ever entering a BI tool. A signed BAA is included on every plan. Run the free compliance scanner against your site to see what is leaving right now, or visit curvecompliance.com to walk through your reporting architecture.

Reviewed August 2026. Vendor BAA policies change. Confirm current terms with the vendor.