Is FullStory HIPAA Compliant?

Between December 2022 and mid-2024, the regulatory landscape for healthcare tracking technology changed more than it had in the previous decade. HHS Office for Civil Rights issued guidance clarifying that tracking pixels, session replay tools, and fingerprinting technologies can create impermissible PHI disclosures. The FTC brought its first enforcement actions under the Health Breach Notification Rule. OCR and FTC jointly sent warning letters to approximately 130 hospital systems and telehealth providers. And across 15 major enforcement cases, healthcare organizations paid more than $193 million in settlements and penalties for tracking technology that had been running on their websites for years.

All of this raises an immediate question for enterprise healthcare teams evaluating digital experience analytics: where does a tool like FullStory fit in this new landscape?

The Regulatory Shift That Changed Session Replay Risk

Before the OCR's December 2022 guidance on tracking technologies, most healthcare organizations treated web analytics as a marketing concern, not a compliance one. Session replay tools, heatmap platforms, and behavioral analytics were deployed by marketing and product teams with little to no involvement from privacy or legal departments.

The OCR guidance changed that calculation. It clarified that HIPAA-regulated entities may not use tracking technologies in ways that disclose PHI to tracking vendors, and that even IP addresses on unauthenticated public pages could constitute PHI when combined with health context. While portions of this guidance were vacated by a Texas federal court in June 2024, and OCR withdrew its Fifth Circuit appeal in August 2024, the enforcement trajectory has not reversed. The FTC continues to pursue cases under the Health Breach Notification Rule, state attorneys general have opened their own investigations, and the class action pipeline shows no signs of slowing.

The settlements tell the story. Kaiser Permanente reached a $47.5 million settlement affecting 13.4 million members after its websites, patient portals, and mobile apps used third-party tracking code that transmitted health information to Google, Microsoft, Meta, and X from 2017 to 2024. Advocate Aurora Health settled for $12.25 million after installing Meta Pixel and Google Analytics on its website, app, and patient portal, exposing data of approximately 3 million patients. In both cases, the organizations installed widely used tools for legitimate analytics purposes. The enforcement actions followed not from malicious intent, but from the architectural reality of client-side data collection.

For session replay tools specifically, the stakes are higher than for standard analytics. A pageview event captures a URL. A session recording captures everything visible on screen: appointment types, provider names, condition searches, medication information, and patient portal content. The surface area for inadvertent PHI capture is inherently larger.

Where FullStory Fits Among Session Replay Vendors

FullStory is the most compliance-aware session replay tool on the market. That distinction matters, and it is worth understanding what FullStory does differently before evaluating where the remaining gaps are.

FullStory offers a private-by-default mode that suppresses all text and input content from recordings unless an element is explicitly allowlisted. This inverts the model used by most competitors, where everything is captured unless you manually configure masking rules. Private-by-default is a meaningful improvement: instead of hoping your team identified every sensitive element on every page, FullStory captures interaction patterns (clicks, scrolls, navigation) without recording on-screen content unless you opt specific elements in.

FullStory also provides element-level exclusion rules and PII detection that can flag potential personally identifiable information before it enters their system. Their SOC 2 Type II certification demonstrates sustained, audited security controls. And for enterprise healthcare customers, FullStory does offer a Business Associate Agreement, which places them ahead of competitors like Hotjar and Crazy Egg that do not sign BAAs at all.

These are real advantages. A healthcare organization evaluating FullStory is starting from a stronger compliance baseline than with most alternatives in this category.

The Client-Side Architecture Question

The compliance question that remains is architectural, and it applies even to FullStory's most privacy-conscious configuration.

FullStory operates client-side. When you deploy FullStory, its JavaScript loads in the visitor's browser. That script observes DOM mutations, captures interaction events, and transmits recording data from the browser to FullStory's servers. Private-by-default mode controls what content the script captures, but the script still runs in the browser, still observes the DOM, and still sends data over a connection between the visitor's browser and FullStory's infrastructure.

This means two things for healthcare organizations:

The data path runs through a third party. Even with private-by-default enabled, behavioral data (click positions, scroll patterns, navigation sequences, page URLs, element interactions) flows from the visitor's browser to FullStory's servers. On a healthcare website, page URLs alone can reveal condition names, provider specialties, or appointment types. Navigation sequences can indicate that a patient visited a specific department page, then an appointment booking flow, then a billing page. This behavioral data, even without on-screen text content, can carry health context.

The privacy controls are enforced client-side. Private-by-default mode and element exclusion rules run in the JavaScript executing in the browser. FullStory's controls are more robust than manual CSS selector masking, but they still depend on client-side execution. The healthcare organization trusts FullStory's JavaScript to correctly suppress content before transmission. If a JavaScript error, browser extension conflict, or configuration drift alters that behavior, data may be captured that was intended to be suppressed. Server-side enforcement removes this class of risk entirely because the browser never has the opportunity to send data to a third party in the first place.

This is not a critique of FullStory's intentions or engineering. It is a description of the fundamental trade-off in client-side session replay architecture. Every enforcement case in the healthcare tracking landscape involved client-side tools sending data to third-party servers. FullStory mitigates this risk more effectively than its competitors, but it does not eliminate the architectural pattern that regulators and plaintiffs have targeted.

Reading the BAA Carefully

FullStory's willingness to sign a BAA is a significant step that most session replay vendors have not taken. For healthcare teams conducting a vendor evaluation, the BAA itself deserves careful review.

Not all BAAs are equal. A legitimate healthcare BAA covers the full data pipeline: collection, processing, storage, and transmission of all data the tool handles. Some vendor BAAs carve out specific data categories, such as behavioral data, analytics data, or data collected on unauthenticated pages. Healthcare teams should confirm that FullStory's BAA covers session recording data, heatmap interactions, frustration signal detection data, and any page content captured through allowlisted elements. A BAA that excludes the tool's core data collection from its scope provides less protection than it appears to offer.

Beyond the BAA itself, healthcare organizations should evaluate the full compliance posture. FullStory holds SOC 2 Type II certification, which confirms sustained security controls verified by independent auditors. The next question is which trust service criteria that certification covers. SOC 2 Type II can cover up to five criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most vendors certify Security only (1 of 5). All five criteria mean auditors verified not just that access controls exist, but that data is processed accurately, remains confidential, and that privacy commitments are honored. Healthcare organizations should request the specific trust criteria covered by FullStory's SOC 2 report.

What a Server-Side Alternative Looks Like

For healthcare organizations that want session replay and behavioral analytics without the client-side architecture question, the alternative is server-side collection.

Server-side session recording means behavioral data is collected on your infrastructure and processed before it ever leaves your environment. The visitor's browser never communicates with a third-party analytics server. There is no JavaScript observing the DOM and transmitting recordings to an external endpoint. You control what data is captured, how it is processed, and where it is stored.

First-party infrastructure means data collection happens on your domain, through your DNS, using server-set cookies. No third-party JavaScript appears in the page source. No tracking endpoints are visible in browser developer tools. This eliminates the browser-to-third-party data path entirely.

Server-side consent enforcement is becoming increasingly important as state privacy laws expand and patient expectations around data handling continue to rise. Consent and privacy represent the next frontier of healthcare compliance. When consent is verified server-side, data only flows to analytics destinations after your infrastructure confirms the patient has opted in. A JavaScript consent banner can be bypassed, fail to load, or be misconfigured. A server-side consent gate cannot.

Continuous site monitoring addresses a risk that no single analytics tool can solve. Installing one compliant tool does not mean your entire site is compliant. Marketing teams add scripts, plugins update, and third-party tags load additional tags. A web scanner that crawls your site on an ongoing basis detects every cookie, script, localStorage entry, and tracking pixel across every page. It flags healthcare-specific risks: which scripts lack a BAA, which cookies are set by third parties, and which pixels send data to ad platforms. Every enforcement case on record involved tracking that ran for years before anyone at the organization noticed.

Ours Privacy provides server-side session replay, heatmaps, and behavioral analytics with a signed BAA covering the full data pipeline, SOC 2 Type II certification across all five trust criteria, and consent-gated data dispatch built into the architecture. Data collection happens on your domain through first-party infrastructure. The visitor's browser never communicates with a third-party analytics server.

An Evaluation Framework for FullStory in Healthcare

FullStory is not a tool you can dismiss outright. It offers real compliance features that most competitors lack. The evaluation should be specific:

1. Review the BAA scope. Confirm it covers all data FullStory collects, including session recordings, heatmap data, frustration signals, and product analytics events. Identify any exclusions or carve-outs.

2. Verify the SOC 2 trust criteria. Request the specific criteria covered. Security only (1 of 5) is table stakes. All five criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy) represent the standard healthcare data demands.

3. Assess the client-side risk for your specific use case. Are you deploying FullStory on a marketing site with no authenticated content? Or on pages that include patient portals, appointment booking, or intake forms? The risk profile differs substantially.

4. Test private-by-default behavior. Deploy in a staging environment and verify that suppression works as expected across all page types, browsers, and device categories. Check that page URLs, navigation patterns, and element metadata do not expose health context even with content suppression active.

5. Evaluate consent architecture. How does FullStory integrate with your consent management? Is consent checked client-side (in the browser before the script loads) or server-side (before any data leaves your infrastructure)?

6. Audit your full tracking surface. FullStory may be compliant in isolation, but what about every other script, pixel, and cookie on your site? A web scanner provides visibility into the tracking technologies across your entire domain, not just the ones you intentionally installed.

FAQ

Does FullStory sign a Business Associate Agreement?

Yes. FullStory offers a BAA for enterprise healthcare customers, which distinguishes it from most session replay competitors. Healthcare teams should review the BAA carefully to confirm it covers all data types the tool collects, including session recordings, behavioral analytics, and any page content captured through allowlisted elements. A BAA's value depends on its scope.

Is FullStory's private-by-default mode sufficient for HIPAA compliance?

Private-by-default mode is a meaningful privacy control that suppresses on-screen text and input content unless explicitly allowlisted. It reduces the risk of inadvertent PHI capture compared to tools that record everything by default. However, private-by-default still operates within a client-side architecture where FullStory's JavaScript runs in the browser and captures behavioral data (clicks, scrolls, navigation patterns, page URLs) that can carry health context. The mode controls what content is recorded but does not change the underlying data path from browser to third-party server.

How does FullStory compare to Hotjar and Crazy Egg for healthcare compliance?

FullStory has a stronger compliance posture than Hotjar or Crazy Egg. FullStory offers a BAA (neither Hotjar nor Crazy Egg does), provides private-by-default recording (both competitors require manual masking configuration), and holds SOC 2 Type II certification. The shared limitation is that all three tools operate client-side, meaning JavaScript in the browser captures and transmits data to the vendor's servers. FullStory mitigates this risk more effectively, but the architectural pattern is the same.

What enforcement cases are relevant to session replay tools in healthcare?

Kaiser Permanente's $47.5 million settlement and Advocate Aurora Health's $12.25 million settlement are the most directly relevant. Both involved client-side tracking tools on healthcare websites and patient portals that captured and transmitted health information to third parties. Session replay tools capture more granular data than the analytics pixels involved in those cases, making the compliance stakes higher rather than lower.

Should I use FullStory or a server-side alternative for healthcare websites?

The answer depends on your risk tolerance and your deployment context. FullStory with private-by-default mode on a public marketing site with no authenticated content presents a different risk profile than FullStory on pages connected to patient portals or appointment booking. For organizations that want to eliminate the client-side architecture question entirely, a server-side session replay platform that collects data on your infrastructure, signs a BAA covering the full pipeline, and enforces consent server-side removes the class of risk that has driven $193 million in healthcare tracking settlements. Pair any solution with a web scanner that continuously monitors your full site for non-compliant scripts and tracking technologies.