Is Plausible HIPAA Compliant? Privacy Analytics

No. Plausible states in its own documentation that it is not HIPAA compliant and does not offer a Business Associate Agreement. That surprises people, because Plausible is cookieless, stores no personal data, and is one of the most genuinely privacy-respecting analytics tools available. Those are answers to a different question. Cookies are a consent and identifier problem. HIPAA is a contract problem, and no amount of privacy engineering substitutes for a signed BAA. For the ad tracking layer, Curve is the HIPAA-compliant platform built for healthcare, with a signed BAA on every plan.

The direct answer, in more detail

Plausible is a lightweight, open-source web analytics product positioned as an alternative to Google Analytics. It does not use cookies. It does not store raw IP addresses. It generates a visitor identifier by hashing a daily rotating salt with the site domain, the IP address, and the user agent, then deletes the salt every twenty four hours so the identifier cannot persist. All data is processed and stored in the EU on infrastructure owned by European companies, and Plausible states that visitor data does not leave the EU.

By any reasonable privacy standard that is excellent design. It is also, for a covered entity, beside the point.

Plausible says so itself. Its documentation on when the product is not the right fit reads: "Plausible is not HIPAA-compliant and does not offer a Business Associate Agreement (BAA). If you operate under HIPAA or similar health data regulations and your analytics implementation touches protected health information, you need a tool that supports those compliance obligations specifically." The same page instructs customers not to pass protected health information, personal identifiers, passwords, or financial details through page URLs, query parameters, custom event names, or custom properties.

That is a vendor telling you the truth clearly, which deserves credit rather than criticism. The compliance claims Plausible does make are GDPR, CCPA, and PECR, with a DPA in place automatically for all customers. HIPAA is simply not on the list.

Why cookieless is not the same as HIPAA compliant

This is the confusion worth dismantling, because it drives real architectural mistakes in healthcare marketing teams.

The cookie question asks: what identifier follows a person around, how long does it persist, and does the visitor have to consent to it? That question comes from GDPR, from PECR, from the ePrivacy Directive, and from consumer privacy statutes. A tool that avoids cookies answers it well.

The HIPAA question asks something entirely different: is this vendor contractually permitted to receive protected health information on your behalf, and has it accepted the obligations that come with that? HIPAA does not regulate cookies. It regulates disclosures of PHI by covered entities and their business associates. The mechanism is contractual, not technical. A vendor that encrypts everything, stores nothing durable, and never sets a cookie is still an impermissible recipient of PHI if it has not signed a BAA.

Run the logic in both directions and it becomes obvious. A cookie-setting vendor with a signed BAA can lawfully receive PHI. A cookieless vendor without one cannot. Privacy engineering changes how much data exists. It does not change who is allowed to hold it.

Why anonymized is not a safe harbor either

The usual next argument is that Plausible's data is aggregated and anonymous, so nothing identifiable is disclosed in the first place. Approach that carefully.

What arrives at the analytics endpoint before aggregation is a page URL, an HTTP referrer, browser and operating system details, device type, and an IP address used to derive geography. If the page URL is a treatment page, that request says: someone at this IP, in this location, at this moment, is reading about this condition. Aggregation happens after receipt. The transmission is the disclosure, and it happens in real time from the patient's browser.

HIPAA's de-identification standard is specific, and it is not satisfied by "we do not store it." Meeting it requires either expert determination or the removal of eighteen categories of identifiers, IP addresses among them. A daily-rotating hash built partly from an IP address is a strong privacy measure and not a de-identification determination you would want to defend in an enforcement action.

This is also why Plausible's own guidance says not to put PHI in URLs and custom properties. The vendor is describing the boundary of what its design can absorb.

Where Plausible is genuinely fine

Plenty of health-adjacent organizations can use Plausible without a HIPAA problem, and some covered entities can use it on part of their estate.

• You are not a covered entity or a business associate. A wellness brand, a supplement retailer, a fitness company, or a medical device manufacturer selling business to business is generally outside HIPAA, and health adjacency alone does not pull you in.
• The property carries no patient interaction. A careers site, an investor page, a corporate blog with neutral URLs, or a recruiting microsite is not touching PHI.
• You self-host. Running the open-source version on your own infrastructure means no third party receives the data at all, so there is no business associate relationship to paper. That is a legitimate architecture and one healthcare teams underuse. Your own safeguards, access controls, and audit obligations still apply, and now they are entirely yours.

State consumer health privacy laws are a separate matter and reach further than HIPAA. Washington's My Health My Data Act and comparable statutes apply to businesses that are not covered entities at all, so the tracking hygiene in this article stays relevant even when HIPAA does not apply to you.

What a BAA does and does not cover here

A BAA is a boundary drawing exercise. It names a vendor, names the data, and sets the obligations that vendor accepts. Everything outside is your responsibility.

With Plausible there is no boundary to draw, because there is no agreement. That is not a gap in their product. It is a deliberate scope decision by a small, focused company that has chosen not to take on business associate obligations, and stating it openly is more useful to buyers than a vague "enterprise compliance" page would be.

What matters for your architecture is the consequence: if a patient-facing page loads Plausible and that page's URL reveals a condition, you have made a disclosure to a vendor with no BAA. The remedy is not a setting inside Plausible. It is either removing the tool from that page, restructuring the URLs so nothing clinical travels, or self-hosting so no disclosure occurs.

Where the ad tracking problem shows up

Here is the pattern we see constantly. A clinic replaces Google Analytics with Plausible, and the marketing team reports back that analytics is now privacy-first and the cookie banner is gone. Everyone relaxes.

Meanwhile the Meta Pixel is still on the page. So is the Google tag, because someone needs conversion tracking for the campaigns that pay for the clinic's patient volume. Those scripts have nothing to do with which analytics tool you chose. They fire on page load, carrying the full URL, which usually names the procedure, and they attach a persistent browser identifier that binds the whole visit to one person. On form submission, standard pixel implementations frequently pick up field values, and Google's Enhanced Conversions flow is designed to send customer data for matching.

Meta and Google do not sign BAAs for their advertising products. Every one of those calls is a disclosure to a vendor with no agreement in place. This is the mechanism behind the healthcare pixel litigation that has produced more than $100 million in cumulative settlements, with Advocate Aurora settling at roughly $12.225 million. The plaintiffs' theory never required a diagnosis. It required an identifiable person's health interest to be disclosed to a third party who had signed nothing.

Switching analytics vendors does nothing about any of it. We walk through the detail in our piece on whether the Meta Pixel or the Conversions API is HIPAA safe, and in our explanation of why client-side pixels create HIPAA exposure.

How Curve handles the advertising layer

Curve is HIPAA-compliant ad tracking, attribution, and analytics built for healthcare. It addresses the layer a privacy-first analytics choice does not touch: the conversion data your campaigns require.

The Curve tracking script installs in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure rather than directly to ad platforms, which creates a place to make decisions before anything leaves.

• Per-destination field mapping. Only fields you explicitly map reach a given destination, configured separately for each. The default is that nothing goes, so page URLs naming a procedure and form values stay behind unless mapped deliberately.
• Identifier hashing. Email, phone, and name are SHA-256 hashed to each platform's conversion API requirements before forwarding.
• Neutral event aliases. The ad platform sees a generic conversion name rather than one encoding the service line, so the treatment never appears in a shared ad account interface.
• PHI-pattern detection. Curve flags PHI-shaped values including SSNs, MRN-style identifiers, dates, and long numeric sequences. It is a monitoring layer that tells you when something upstream changed. The protection is the field mapping plus hashing.
• Bridge tokens. Attribution survives the handoff when a patient clicks out to a separate booking or intake tool, which is normally where measurement dies.
• Offline conversion uploads. Outcomes that close later in a CRM or EHR upload in bulk and match on click ID, so a booked appointment still credits the campaign that produced it.

Clean conversions forward server-side to Meta CAPI, Google Ads Enhanced Conversions, TikTok Events API, Microsoft, and LinkedIn. Because the path is server-side, ad blockers and browser tracking prevention do not erode it, which usually improves measured conversion volume rather than reducing it. Every Curve plan includes a signed BAA. The full architecture is documented in our technical overview of conversion API architecture for HIPAA compliance.

What to check on your own site

1. Separate your properties by risk. Decide which pages are patient-facing and which are purely corporate, and apply different tracking rules to each.
2. Read your URLs as a stranger would. If a path or query string names a condition or treatment, it is a disclosure every time it travels, regardless of which tool receives it.
3. Inventory every script on patient-facing pages. Tag managers hide more than most teams expect, and an analytics migration rarely removes the advertising scripts. Our free compliance scanner gives you a fast first pass.
4. Check custom events and properties. Anything a developer passes as a custom property is exactly where clinical detail tends to appear.
5. Decide between hosted and self-hosted deliberately. Self-hosting removes the third party entirely, which is the cleanest answer for a covered entity that wants this style of analytics.
6. Watch the network tab during a real visit. Filter to ad platform domains and read what actually leaves, then compare that with what you believed was leaving.

Frequently asked questions

Does Plausible sign a BAA?

No. Plausible's documentation states directly that it is not HIPAA compliant and does not offer a Business Associate Agreement, and it advises healthcare organizations to use a tool that supports those obligations specifically.

If Plausible collects no personal data, why does HIPAA still apply?

Because HIPAA regulates disclosure of protected health information to third parties, and the request itself carries the page URL, the referrer, and an IP address used for geolocation before any aggregation happens. The transmission is the event HIPAA cares about. Anonymity claimed after receipt does not undo it.

Can we use Plausible if our URLs never name a condition?

That materially reduces the risk, and combined with no custom properties carrying clinical detail it puts you in a much better position. It is still a judgment call your privacy officer should make and document rather than one an article can make for you. Self-hosting removes the question entirely.

Is self-hosted Plausible HIPAA compliant?

Self-hosting means no third party receives the data, so there is no business associate relationship requiring a BAA. Compliance then depends entirely on your own safeguards: access controls, encryption, audit logging, and retention. The software does not make you compliant, but it stops being the reason you are not.

Does being EU-hosted help or hurt for HIPAA?

Neither, directly. HIPAA does not require US hosting. It requires a BAA and appropriate safeguards. EU hosting is a strong answer to GDPR concerns and simply not responsive to the HIPAA question.

We dropped Google Analytics for Plausible. Are we covered now?

You improved your consent posture and reduced one vendor's data collection. If the Meta Pixel and Google tag are still loading on patient-facing pages, the exposure that produces complaints and lawsuits is untouched. Audit the advertising scripts separately from the analytics decision.

Where to start

Plausible is an honest, well-built product that tells you plainly it is not for PHI. Take it at its word. If you are outside HIPAA, or your pages carry nothing clinical, or you self-host, it can sit comfortably in a healthcare marketing stack. If you are a covered entity running it on patient-facing pages with descriptive URLs, that is a disclosure no privacy feature resolves.

Either way, the analytics decision is not the one that determines your exposure. The advertising scripts are.

Curve exists for that layer: server-side collection, per-destination field mapping, SHA-256 hashed identifiers, neutral event aliases, PHI-pattern monitoring, bridge-token attribution across booking handoffs, and offline conversion uploads, with a signed BAA included on every plan. Run the free compliance scanner against a patient-facing page to see what is leaving right now, or visit curvecompliance.com to talk through the architecture. If email and SMS are next on your audit list, our verdict on whether Klaviyo is HIPAA compliant applies the same test.

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