Is Heap HIPAA Compliant?

A product manager at a growing telehealth company drops a single JavaScript snippet into the site header. The goal is straightforward: understand how patients navigate the symptom checker, where they drop off during appointment booking, and which features drive engagement. Within minutes, Heap is live. And within those same minutes, Heap's auto-capture engine is recording every click, every form submission, every page URL, and every text input across the entire application. The symptom checker where patients describe their conditions. The insurance form where they enter member IDs. The appointment confirmation page with provider names and visit types. All of it, captured automatically, with no manual instrumentation required.

That is the value proposition of Heap (now owned by Contentsquare): capture everything, ask questions later. For a SaaS company or e-commerce brand, it is a powerful approach to product analytics. For a HIPAA-covered entity, it is a compliance scenario that demands careful evaluation.

When "Capture Everything" Meets Protected Health Information

Heap's defining feature is auto-capture. Unlike traditional analytics tools that require developers to define specific events, Heap records every user interaction by default. Every click on a button. Every keystroke in a form field. Every page URL visited. Every element a user interacts with on the page.

On a standard website, this means Heap collects things like navigation patterns and feature usage. On a healthcare website, the data changes character entirely. Form fields contain patient names, dates of birth, insurance IDs, and descriptions of symptoms. Page URLs often encode health conditions directly: /conditions/diabetes, /providers/oncology, /appointments/mental-health-intake. Button labels reveal treatment selections. Search queries describe symptoms.

HIPAA defines Protected Health Information (PHI) as any individually identifiable health information created, received, maintained, or transmitted by a covered entity. When Heap auto-captures a form submission on a telehealth intake page, it is collecting PHI. When it records a click on a page whose URL contains a condition name alongside a logged-in user's session, it is transmitting PHI to Heap's servers.

The challenge is structural. Most analytics tools require you to explicitly send data, which means a compliance team can review exactly what gets transmitted. With auto-capture, the default is to collect everything, and the burden falls on your team to identify and suppress every field, page, and interaction that could contain PHI. On a healthcare site with hundreds of pages and dozens of forms, that suppression effort is enormous and must be maintained every time the site changes.

The BAA Question and Why It Matters Here

A Business Associate Agreement is the legal foundation for sharing PHI with any third-party vendor. Under HIPAA, if a tool processes, stores, or transmits PHI on behalf of a covered entity, the vendor must sign a BAA and accept legal responsibility as a Business Associate.

As of this writing, Heap does not appear to offer a BAA for its analytics product. Without a BAA in place, any transmission of PHI to Heap's servers puts the covered entity at risk of a HIPAA violation, regardless of how the data is used after collection.

This is particularly significant given Heap's auto-capture architecture. With a tool that requires manual event instrumentation, you might argue that PHI was never intentionally sent to the vendor. With auto-capture, the tool is designed to collect everything. The absence of a BAA means there is no contractual framework governing what happens to that data once Heap has it: no defined retention policies, no breach notification obligations, and no HIPAA-specific security commitments.

Some organizations attempt to work around the BAA gap by configuring Heap to suppress sensitive fields. Heap does offer data governance controls that allow teams to block specific CSS selectors, form fields, or page sections from capture. But suppression is an opt-out model applied on top of a capture-everything default. It requires your team to identify every single location where PHI might appear, configure suppression rules for each one, and verify those rules every time your site changes. A single missed field, a newly added form, or a URL restructuring can reintroduce PHI into the data stream without anyone noticing.

How Client-Side Collection Creates Exposure

Heap operates entirely through client-side JavaScript. When a patient visits your site, Heap's script runs in their browser, captures interaction data, and sends it directly from the browser to Heap's servers. This architecture has a specific implication for healthcare compliance.

With client-side collection, data leaves the patient's browser and travels to a third-party domain before your organization has any opportunity to inspect, filter, or redact it. The browser is the point of collection, and Heap's servers are the destination. Your backend systems are not in the middle.

Server-side architectures work differently. Data flows from the user's browser to your servers first, and then your servers decide what to forward to analytics platforms. This gives you a chokepoint where you can strip PHI, validate consent, and control exactly what reaches any third party. With client-side collection, that chokepoint does not exist.

This distinction matters because every major tracking technology enforcement action has involved client-side data transmission. The tools themselves were not malicious. They were simply collecting data in the browser and sending it to third-party servers, exactly as designed.

$193 Million in Lessons About Analytics on Healthcare Sites

The pattern is consistent across enforcement cases: a healthcare organization installs a standard analytics or marketing tool, the tool collects patient data through normal operation, and the organization faces regulatory action or litigation years later.

Advocate Aurora Health ($12.25M settlement, 2024): Advocate Aurora installed Meta Pixel and Google Analytics on its website, app, and patient portal specifically to "better understand patient needs." The tools exposed data of approximately 3 million patients to Meta and Google without consent. The intent was benign. The architecture made the outcome inevitable. (Source)

Kaiser Permanente ($47.5M settlement, 2025): From 2017 to 2024, Kaiser's websites, patient portals, and mobile apps used third-party tracking code that transmitted health information to Google, Microsoft, Meta, and X. The breach affected 13.4 million members. Data included search terms, medical histories, and communications with healthcare professionals. The tracking ran for seven years before the full scope was discovered. (Source)

Sutter Health ($21.5M settlement, 2025): Sutter Health implemented Google Analytics, Meta Pixel, and other tracking tools on its MyHealthOnline patient portal. The tools tracked and disclosed private patient data to Google and Facebook without authorization over a period spanning from 2015 to 2020. (Source)

None of these organizations set out to leak patient data. They installed widely used analytics tools for legitimate business purposes. The tools functioned exactly as designed: collecting data in the browser and transmitting it to third-party servers. The compliance failure was architectural, not intentional.

Heap's auto-capture compounds this risk. Where Google Analytics and Meta Pixel collect specific pageviews and predefined events, Heap captures every interaction on the page by default. The surface area for inadvertent PHI collection is broader from the moment the script loads.

Building an Analytics Stack That Withstands Scrutiny

For healthcare organizations that need product analytics (and most do), the question is not whether to measure user behavior. It is how to do so within an architecture that protects patient data by default rather than relying on manual suppression.

A healthcare-grade analytics architecture includes several components that work together:

A signed, comprehensive BAA. The vendor accepts liability as a Business Associate and the agreement covers the full data pipeline: collection, processing, storage, and transmission. Not all BAAs are equal. Some exclude analytics data or marketing data from their scope, which defeats the purpose.

Server-side data collection. Data flows from the browser to your servers, where it can be filtered and redacted before reaching any analytics platform. The browser never communicates directly with third-party analytics domains. This is not a preference; it is the architectural difference between "we configured suppression rules" and "PHI cannot reach the vendor's servers."

SOC 2 Type II certification with all five trust criteria. Most vendors certify only Security (one of five). A complete SOC 2 Type II covering Security, Availability, Processing Integrity, Confidentiality, and Privacy means independent auditors verified the vendor handles data with the rigor healthcare requires. Type II (not Type I) means sustained compliance over a review period, not a point-in-time snapshot.

Consent-gated data flows. Data only moves to downstream destinations after patient consent is verified server-side. This is different from a JavaScript consent banner that can be bypassed, cached, or ignored by other scripts on the page. As state privacy laws expand and patient expectations evolve, consent-gated architecture is becoming the baseline, not a bonus.

Continuous compliance monitoring. Installing a compliant analytics tool does not mean your entire website is compliant. Marketing teams add scripts. Plugins update. Third-party tags load other tags. A web scanner crawls your site on an ongoing basis and detects every cookie, script, localStorage entry, and tracking pixel across every page. It flags which scripts lack a BAA, which cookies are set by third parties, and which tracking pixels are sending data to ad platforms. Every enforcement case in the reference data involved tracking that ran for years before anyone noticed.

Five Questions to Ask Before Using Heap in Healthcare

Before deploying Heap (or any auto-capture analytics tool) in a healthcare context, work through these questions with your compliance and engineering teams:

1. Can you get a signed BAA from Heap? Without one, any PHI transmission to Heap's servers is a potential HIPAA violation. Contact Heap directly and ask whether they will sign a BAA that covers analytics data collection, processing, and storage.

2. Can you guarantee complete PHI suppression across every page? Auto-capture means every form field, URL, button label, and text input is collected unless explicitly suppressed. Audit every page on your site for PHI exposure and determine whether your team can maintain suppression rules as the site evolves.

3. How does Heap's client-side architecture affect your risk posture? Data travels directly from the patient's browser to Heap's servers. Evaluate whether your organization is comfortable with PHI leaving the browser without passing through your own infrastructure first.

4. What happens when your site changes? New pages, new forms, and redesigned flows can introduce PHI into Heap's data stream without triggering any alert. Determine whether you have a process to re-audit suppression rules with every deployment.

5. Does your broader tracking stack compound the risk? Heap is rarely the only script on a healthcare site. Consider how Heap interacts with your tag manager, consent banner, and other analytics tools. Each additional client-side script increases the surface area for unintended data collection.

Frequently Asked Questions

Does Heap sign a BAA for healthcare customers?

As of this writing, Heap does not appear to publicly offer a BAA. Organizations considering Heap for healthcare use should contact Heap's sales team directly to confirm current availability. Without a BAA in place, transmitting any PHI to Heap would put the covered entity at risk of a HIPAA violation.

Can Heap's data governance controls prevent PHI collection?

Heap offers suppression features that allow you to block specific form fields, CSS selectors, and page elements from auto-capture. However, these controls operate on an opt-out basis. The default is to capture everything, and your team must identify and suppress every location where PHI could appear. This requires ongoing maintenance as your site evolves.

Is Heap's auto-capture fundamentally incompatible with HIPAA?

Auto-capture is not inherently illegal, but it shifts the compliance burden significantly. Instead of choosing what data to send (opt-in), you must identify everything that should not be sent (opt-out) across your entire site. For healthcare organizations with complex sites and multiple forms containing PHI, this creates a large and ongoing compliance surface.

Does Contentsquare's acquisition of Heap change anything for HIPAA?

Contentsquare acquired Heap in 2023. While Contentsquare may bring additional enterprise compliance capabilities, the core auto-capture architecture and client-side data collection model remain the same. Healthcare organizations should evaluate the current product configuration, BAA availability, and security certifications rather than assuming the acquisition automatically improved HIPAA readiness.

What analytics alternatives work for HIPAA-covered entities?

Healthcare organizations should look for analytics platforms that offer signed BAAs covering the full data pipeline, server-side data collection (so PHI never leaves your infrastructure), SOC 2 Type II certification across all five trust criteria, and consent-gated data dispatch. Ours Privacy provides a healthcare-grade analytics suite built on server-side architecture with a comprehensive BAA, giving organizations product analytics without the compliance exposure of client-side auto-capture tools.

Looking for a deeper evaluation framework? Read our guide on HIPAA-compliant analytics tools for the full checklist, or explore how organizations are replacing client-side analytics with server-side tracking architectures. You can also see how Heap compares to other product analytics platforms in our evaluations of Mixpanel, Amplitude, and FullStory.