Is Amplitude HIPAA Compliant?

Before you ask whether a specific product analytics tool can work in healthcare, it helps to know what "work in healthcare" actually means. The compliance bar for analytics platforms has shifted dramatically since 2022. HHS issued guidance on tracking technologies, the FTC began enforcing the Health Breach Notification Rule for the first time, and over $193 million in settlements have followed. The question isn't whether Amplitude has good features. The question is whether those features, in practice, prevent PHI from reaching places it shouldn't.

This article starts with the checklist every healthcare organization should use when evaluating any analytics vendor. Then we'll measure Amplitude against each requirement.

Five Requirements for Healthcare Analytics Compliance

Any analytics platform used by a HIPAA-covered entity or its business associates needs to meet all five of these criteria. Missing even one creates legal exposure.

1. A Business Associate Agreement that covers the full data pipeline. The BAA must cover collection, processing, storage, and transmission. BAAs that carve out marketing data or certain event types leave gaps that regulators have already exploited in enforcement actions.

2. SOC 2 Type II certification across all five trust criteria. The five criteria are Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most analytics vendors certify only Security. That's table stakes, not proof of compliance. Type II (not Type I) means sustained compliance over a review period, verified by independent auditors.

3. Server-side data collection architecture. Client-side JavaScript sends data through the visitor's browser. That means the browser communicates directly with the analytics vendor's servers, transmitting URLs, page content, user properties, and event metadata. Server-side architecture routes data from your server to destinations. The browser never talks to a third party.

4. Consent-gated data flows enforced at the infrastructure level. Consent shouldn't rely on a JavaScript check that can be bypassed, cached, or ignored by other scripts on the page. Server-side consent verification means data physically cannot flow to a destination until consent is confirmed.

5. Continuous compliance monitoring across your entire site. Installing one compliant tool does not make your website compliant. Marketing teams add scripts, plugins update, third-party tags load other tags. A web scanner that crawls your site on an ongoing basis and flags every cookie, script, and tracking pixel is the only way to know whether your site is still compliant today, not just on the day you configured it.

How Amplitude Handles Healthcare Data

Amplitude is a product analytics platform built for tracking user behavior: page views, button clicks, feature adoption, conversion funnels, and custom events. It competes with Mixpanel, Heap, and similar behavioral analytics tools.

Here's how Amplitude typically handles data in practice.

Client-side SDK is the default. Amplitude's primary implementation is a JavaScript SDK that runs in the visitor's browser. When a user visits your site, the SDK captures events and sends them directly to Amplitude's servers. This means Amplitude's endpoints are visible in browser DevTools, the data leaves the browser before your server can inspect or filter it, and every event carries the user's IP address, device fingerprint, and session context.

Behavioral data easily becomes PHI on healthcare sites. Amplitude tracks granular behavioral data by design. On a healthcare website, that means page URLs containing condition names (e.g., /services/oncology/treatment-options), custom event names like "Appointment Booked" or "Prescription Refill Requested," user properties that may include patient identifiers, and search queries for symptoms or providers. None of this requires misconfiguration. It's what the tool is built to do.

Server-side SDK exists but isn't the norm. Amplitude offers an HTTP API for server-side event tracking. In theory, this lets you filter data before it reaches Amplitude. In practice, most Amplitude implementations rely on the client-side SDK because it captures richer behavioral signals with less engineering effort. The server-side option requires your team to build and maintain the integration, decide what data to include or exclude, and keep that filtering logic current as your site evolves.

Evaluating Amplitude Against the Compliance Checklist

Let's walk through each requirement.

Requirement 1: Business Associate Agreement

Amplitude does offer a BAA for customers on its Growth and Enterprise plans. This is a meaningful step that many analytics vendors still refuse to take. Having a signed BAA means Amplitude accepts liability as a Business Associate under HIPAA for the data it processes.

However, a BAA is a legal contract. It defines responsibilities. It does not change the underlying architecture. If your implementation sends PHI to Amplitude through a client-side SDK, the BAA covers the data after it arrives at Amplitude's servers. It does not prevent the exposure that happens during transmission, when data flows through the browser and across the open internet to a third-party domain.

Requirement 2: SOC 2 Type II Certification

Amplitude holds SOC 2 Type II certification. This is a strong signal that the company takes security seriously and has sustained operational controls verified by independent auditors. Healthcare organizations should request the full report to confirm which of the five trust criteria are covered. SOC 2 reports that only address Security (1 of 5) are common in the analytics industry and fall short of what healthcare-grade compliance requires.

Requirement 3: Server-Side Architecture

This is where the gap becomes significant. Amplitude's standard implementation is client-side JavaScript. The browser sends event data directly to api2.amplitude.com or a similar endpoint. Your server never sees the data, never filters it, and never decides whether it should be sent.

Amplitude does offer a server-side HTTP API. But using it means rebuilding your analytics implementation: capturing events on your server, filtering out anything that could constitute PHI, and forwarding only safe data to Amplitude. This is possible, but it's a custom engineering project, not a product feature you toggle on.

The distinction matters because every major tracking technology enforcement case has involved client-side data collection. The data flows through the browser, reaches the vendor, and by the time anyone notices what was included, it's too late.

Requirement 4: Consent-Gated Data Flows

Amplitude provides data governance features including a taxonomy system and the ability to block specific properties. These are useful tools, but they are opt-in configurations. They require your team to correctly identify every property that could contain PHI, configure blocking rules for each one, and maintain those rules as your product and site evolve.

There is no architectural barrier that prevents unconsented data from flowing to Amplitude. If a new event is added by a developer or a marketing team member, and it happens to contain PHI, it will reach Amplitude unless someone has proactively configured a rule to block it. The default is open, not closed.

For consent management specifically, Amplitude relies on your implementation to gate when the SDK initializes. If your consent tool fails, loads slowly, or is bypassed, events can fire before consent is recorded. Server-side consent enforcement eliminates this category of risk entirely because data never leaves your infrastructure until consent is confirmed at the server level.

Requirement 5: Continuous Compliance Monitoring

Amplitude is an analytics tool. It does not scan your website for compliance risks. It cannot tell you whether other scripts on your site are leaking data to ad platforms, whether a WordPress plugin introduced a new tracking pixel last week, or whether a third-party tag is setting cookies without a BAA.

This is not a criticism of Amplitude specifically. No analytics tool provides this capability. But it means that using Amplitude in a compliant way is only one piece of a much larger compliance picture. Without ongoing scanning, you're relying on the assumption that nothing on your site changed since your last manual audit.

What Enforcement Cases Reveal About This Architecture

The pattern across enforcement actions is consistent: client-side tracking on healthcare websites captures PHI and transmits it to third parties without adequate controls.

Advocate Aurora Health ($12.25M settlement, 2024). Advocate Aurora installed analytics and advertising pixels on its website, app, and patient portal specifically to "better understand patient needs." The intent was good. The architecture was the problem. Client-side tracking exposed data for approximately 3 million patients to Meta and Google from 2017 to 2022. The lesson: well-intentioned analytics deployments still cause breaches when data flows through the browser.

Kaiser Permanente ($47.5M settlement, 2025). Kaiser's websites, patient portals, and mobile apps used third-party tracking code that transmitted health information to Google, Microsoft, Meta, and X without consent. The breach affected 13.4 million members. Search terms, medical histories, and communications with providers were all captured and sent to advertising platforms. This is the largest tracking technology settlement to date and it started with standard analytics and marketing tools doing exactly what they were designed to do.

Sutter Health ($21.5M settlement, 2025). Sutter Health implemented Google Analytics, Meta Pixel, and other tracking tools on its patient portal. Patient data was shared with Google and Facebook without authorization. The class period spans June 2015 through March 2020, a reminder that tracking exposure often runs for years before anyone discovers it.

In every case, the organization had security practices, vendor agreements, and compliance teams. What they lacked was an architecture that made PHI exposure structurally impossible.

Building a Compliant Analytics Stack

If your organization needs product analytics and operates under HIPAA, the architecture should make compliance the default rather than something that depends on perfect configuration.

Server-side collection on your domain. Data flows from the visitor's browser to your server. Your server decides what to capture, what to filter, and where to send it. No third-party endpoints are visible in the browser. No data leaves your infrastructure without your explicit routing.

Consent enforcement at the server level. Consent status is verified server-side before any data is dispatched to any destination. This eliminates the class of bugs where client-side consent tools load after tracking scripts, or where consent state is cached incorrectly.

First-party infrastructure. Custom domains for data collection mean cookies are server-set (immune to Safari ITP and ad blockers) and no vendor fingerprint appears in your page source. The analytics implementation is invisible to anyone inspecting your site.

SOC 2 Type II across all five trust criteria. Independent auditors verify Security, Availability, Processing Integrity, Confidentiality, and Privacy on a sustained basis.

Continuous web scanning. An automated scanner crawls your site on a schedule and reports every cookie, script, localStorage entry, and tracking pixel. It flags which scripts lack a BAA, which cookies come from third parties, and which tracking pixels send data to ad platforms. This is how you catch the compliance drift that caused every enforcement case in this article.

Ours Privacy was built from the ground up with this architecture: server-side collection, first-party infrastructure, SOC 2 Type II with all five trust criteria, consent-gated dispatch, and continuous web scanning. If you're evaluating analytics platforms for healthcare, request a demo to see how the architecture works.

Frequently Asked Questions

Does Amplitude sign a BAA?

Yes. Amplitude offers a Business Associate Agreement for customers on Growth and Enterprise plans. A signed BAA is a necessary starting point for HIPAA compliance, but it covers the vendor's handling of data after receipt. It does not change how data is collected or what data is transmitted from the browser.

Can I use Amplitude's server-side SDK to avoid PHI exposure?

Amplitude's HTTP API allows you to send events from your server rather than from the browser. This gives you control over what data reaches Amplitude. However, this requires custom engineering: your team must build the integration, decide what to include or exclude, and maintain filtering logic over time. Most Amplitude implementations use the client-side SDK because it requires less effort and captures richer behavioral data.

What makes Amplitude different from Google Analytics for HIPAA purposes?

Both tools use client-side JavaScript to collect behavioral data. The core architectural risk is the same: data flows through the browser to a third-party server. Amplitude's advantage is that it offers a BAA (Google Analytics does not for the standard product) and has data governance features for managing event properties. The disadvantage is that those governance features are opt-in rather than default-safe. For a deeper comparison, see our guide on Google Analytics HIPAA compliance.

Is Amplitude's taxonomy feature enough to prevent PHI from being collected?

Amplitude's taxonomy and data governance tools let you define approved event names, block specific properties, and enforce naming conventions. These are valuable for data quality. For compliance, they are necessary but not sufficient. They require proactive configuration for every event and property, and they cannot block data that a developer sends before it's been added to the taxonomy. A server-side architecture prevents PHI from leaving your infrastructure regardless of what developers or marketing teams configure on the front end.

What should I ask Amplitude before signing a healthcare contract?

Ask which SOC 2 trust criteria their Type II report covers. Ask whether the BAA covers all data processed through their platform or carves out certain categories. Ask for documentation on configuring their server-side SDK for healthcare use cases. And ask what happens if a client-side event accidentally captures PHI before your team blocks it. The answers will tell you whether their compliance posture matches your risk tolerance.