Is Drift HIPAA Compliant?

Your growth team just installed Drift on the hospital website. The goal is simple: convert more anonymous visitors into booked appointments. A chatbot greets everyone on the homepage, the orthopedics landing page, the dermatology service line. Patients who engage get routed to a live agent or a scheduling link. Within the first week, conversion rates climb. The VP of Marketing is thrilled.

Then a patient types into the chat widget: "I need to see a dermatologist about a suspicious mole on my left shoulder."

That message travels from the patient's browser, over a connection your organization does not control, to Drift's servers. It is stored in a chat transcript alongside the patient's IP address, the page they were viewing, the referring URL, and any behavioral data Drift's JavaScript captured during the session. Nobody on the compliance team was consulted before the widget went live. And the chat transcript now sitting on Drift's infrastructure almost certainly contains protected health information.

This is not a hypothetical edge case. It is the predictable outcome of putting a conversational interface on a healthcare website without evaluating how the underlying technology handles data.

What Drift's Chat Widget Actually Does to Patient Data

Drift (now owned by Salesloft) is a conversational marketing platform that combines live chat, chatbots, meeting scheduling, and visitor intelligence. Understanding how data moves through Drift is essential before evaluating it for healthcare use.

When Drift is installed on a website, a JavaScript snippet loads in every visitor's browser. That script does several things simultaneously:

Chat transcript capture. Every message the visitor types and every response from a bot or agent is sent to Drift's servers in real time. On a healthcare site, patients routinely type symptoms, conditions, medication questions, insurance details, and appointment requests directly into the chat window. Unlike a page view or a button click, chat messages are free-text fields where patients describe their health concerns in their own words.

Behavioral tracking for lead scoring. Drift's JavaScript monitors which pages the visitor views, how long they spend on each page, and what actions they take. This data feeds Drift's lead scoring and routing engine. On a healthcare website, page views carry context. A visitor who browses the oncology page, then the insurance FAQ, then opens the chat widget has created a behavioral trail that reveals health information, even if the chat transcript itself is benign.

Visitor identity resolution. Drift connects chat interactions to email addresses, form submissions, and CRM records. Once a visitor identifies themselves (by providing an email in the chat widget, for example), Drift links that identity to their entire browsing history on your site.

The combination is what creates compliance exposure. It is not just that a patient might type something sensitive into the chat. It is that Drift simultaneously captures the message content, the health context of the pages the patient visited, and an identity that ties it all together. All of this data flows from the visitor's browser to Drift's infrastructure through a client-side JavaScript connection.

Why Chat Widgets Create a Different Category of Risk

Most of the healthcare tracking enforcement cases to date have involved passive data collection: pixels and analytics scripts quietly transmitting page URLs, click events, and browsing behavior to third parties. Chat tools introduce something those passive tools do not: an active invitation for the patient to disclose health information.

When a chatbot on a dermatology page asks "How can we help you today?", it is prompting the patient to describe their reason for seeking care. When a scheduling bot asks what type of appointment the patient needs, it is collecting information about a medical condition. The tool is not passively observing behavior. It is actively soliciting data that, on a healthcare website, will frequently constitute PHI.

This distinction matters because it changes the nature of the exposure. With a tracking pixel, a health system might argue that it did not intend to share health data with a third party. With a chat tool, the organization deployed an interface specifically designed to collect information from patients and chose to route that information through a third party's infrastructure.

Drift does not sign Business Associate Agreements. Their public documentation does not reference HIPAA as a supported compliance framework. There is no enterprise tier or configuration that introduces BAA coverage. Without a BAA, Drift has no legal obligation under HIPAA to safeguard any patient data that reaches its servers, to notify you if that data is breached, or to limit how it uses the information.

How Regulators Have Treated Direct Health Disclosures on Digital Platforms

The enforcement landscape provides specific guidance on how regulators view platforms that collect health information directly from patients through digital interfaces.

BetterHelp paid $7.8 million to the FTC after tracking pixels shared email addresses, IP addresses, and mental health intake questionnaire responses with Facebook, Snapchat, Criteo, and Pinterest. BetterHelp used the fact that users had previously been in therapy to build Facebook lookalike audiences. A recent college graduate with no marketing training had been placed in charge of deciding what user data was uploaded to Facebook. The FTC found that BetterHelp's platform actively collected sensitive health disclosures and then routed that data to advertising platforms without adequate controls or consent. The parallels to a chat widget collecting patient messages and sending them to a third party's servers are direct.

Cerebral faced a $7 million FTC enforcement action after tracking pixels transmitted patient names, medical histories, prescription information, insurance details, and mental health symptom questionnaire answers to Meta from 2019 to 2023. Cerebral reported the breach to HHS as affecting 3.2 million individuals. The FTC imposed a first-of-its-kind ban on using health information for most advertising. Like a chat widget that captures patient messages, Cerebral's platform collected health information through a digital interface and then allowed that data to reach third parties through client-side tracking technology.

Both cases share a critical characteristic with chat tools on healthcare websites: the platform actively collected health disclosures from patients, and that data ended up on third-party infrastructure without a BAA or appropriate safeguards. The total enforcement actions across healthcare tracking cases now exceed $193 million since 2023, covering 15 major cases and more than 20 million affected individuals.

The Compliance Bar for Conversational Tools in Healthcare

Healthcare organizations that want to use live chat, chatbots, or scheduling widgets on their websites need to evaluate vendors against specific requirements.

A BAA that covers chat transcripts and behavioral data. Any vendor receiving patient messages must sign a Business Associate Agreement that explicitly covers the content of chat conversations, associated metadata, and behavioral tracking data. A BAA that carves out "marketing data" or "analytics data" provides no coverage for the exact information a chat tool collects.

Server-side message processing. In a compliant architecture, the chat interface on the page sends data to your server first. Your server processes, filters, and routes the data before it reaches any downstream system. The patient's browser never communicates directly with a third-party chat vendor. This eliminates the client-side data path that has been at the center of every enforcement action.

SOC 2 Type II across all five trust criteria. Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most vendors certify Security alone (1 of 5). That confirms basic access controls and encryption. It says nothing about how chat transcripts are processed, whether they remain confidential, or how the vendor meets privacy commitments. All five criteria, verified by independent auditors over a sustained review period, demonstrate the level of rigor healthcare data demands.

Consent verification before data collection begins. Consent and privacy are rapidly becoming the next frontier of healthcare compliance. State privacy laws are expanding, and patient expectations around data handling are rising. A compliant chat implementation verifies consent server-side before the chat widget activates or before any behavioral tracking begins. A JavaScript consent check can be bypassed or misconfigured. Server-side consent gating cannot.

Continuous monitoring of your entire site. Adding a compliant chat tool does not make your website compliant. Marketing teams install scripts, plugins auto-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 identifies which scripts lack a BAA, which cookies are set by third parties, and which data flows are not gated by consent. Every enforcement case in the public record involved tracking that had been running for months or years before anyone noticed.

Building a Compliant Conversational Experience

The goal is not to abandon live chat or chatbot functionality. Patients genuinely benefit from being able to ask questions and schedule appointments through conversational interfaces. The goal is to deliver that experience through an architecture that protects the data patients share.

A compliant approach starts with first-party infrastructure. Data collection happens on your domain, through your DNS, using server-set cookies. No third-party JavaScript needs to load in the visitor's browser to power the chat experience. No chat vendor endpoints are visible in browser developer tools. This is the architectural difference between hoping sensitive data does not leak and ensuring it cannot.

From there, a customer data platform with a signed BAA can serve as the routing layer. Patient interactions flow through your server-side infrastructure, where consent is verified, data is filtered, and only the appropriate information reaches downstream systems like your CRM, scheduling tool, or marketing automation platform. Each destination in the pipeline operates under its own BAA coverage.

Ours Privacy provides server-side data infrastructure with a signed BAA, SOC 2 Type II across all five trust criteria, and consent-gated dispatch built into the architecture. Combined with continuous web scanning to monitor your full site for compliance gaps, it gives healthcare organizations the foundation to deploy patient-facing tools without the compliance exposure that client-side chat widgets introduce.

Evaluating Drift for Your Healthcare Website

If your organization is considering Drift or currently has it installed, these questions will clarify your compliance posture:

1. Will Drift sign a BAA? As of this writing, Drift does not offer BAAs. Without one, any PHI in chat transcripts or behavioral data creates an impermissible disclosure.

2. What data is Drift's JavaScript capturing? Beyond chat messages, Drift tracks page views, session behavior, and visitor identity. On a healthcare site, this behavioral data carries health context.

3. Can you prevent patients from typing PHI into the chat? Practically, no. A chat widget on a healthcare page is an open invitation for patients to describe symptoms, conditions, and health concerns. You cannot control what patients type.

4. Who reviews new scripts before they go live? The BetterHelp case revealed that a recent college graduate was making decisions about what patient data was shared with advertising platforms. If your organization lacks a formal review process for marketing technology, the risk is not limited to Drift.

5. Do you have visibility into every script on your site today? If Drift is installed, there may be other tools collecting data without a BAA. A comprehensive compliance audit of your entire tracking surface is the starting point.

FAQ

Does Drift sign a Business Associate Agreement?

No. Drift does not offer a BAA and does not position itself as a HIPAA-compliant platform. The Salesloft acquisition has not changed this. Without a BAA, there is no legal framework under HIPAA governing how Drift handles patient data that reaches its servers through chat transcripts or behavioral tracking.

Can I configure Drift to avoid capturing PHI?

There is no reliable way to prevent PHI from entering Drift's system on a healthcare website. Chat widgets are free-text input fields where patients describe health concerns in their own words. You cannot predict or control what a patient will type. Even if chat transcripts were somehow sanitized, Drift's behavioral tracking captures page views on health-related pages, which can constitute PHI when combined with visitor identity.

Is Drift's behavioral tracking a separate compliance concern from chat transcripts?

Yes. Even if a patient never types anything sensitive into the chat widget, Drift's JavaScript tracks which pages they visit, how long they stay, and what actions they take. On a healthcare website, a visitor who views pages about specific conditions, treatments, or providers is generating behavioral data that reveals health information. This data flows to Drift's servers alongside any identity information the visitor provides, creating a compliance exposure independent of the chat content itself.

How is a chat tool different from a tracking pixel for HIPAA purposes?

A tracking pixel passively collects browsing data. A chat tool actively solicits information from the visitor and provides a free-text field for them to respond. On healthcare websites, patients will use that field to describe symptoms, ask about conditions, and share insurance details. This means chat tools have a higher likelihood of capturing explicit PHI compared to passive tracking technologies. Regulators have already penalized platforms like BetterHelp and Cerebral for collecting health disclosures through digital interfaces and routing that data to third parties.

What should I use instead of Drift on a healthcare website?

Look for a conversational platform that operates through server-side architecture, signs a BAA covering chat transcripts and behavioral data, and holds SOC 2 Type II certification across all five trust criteria. Consent should be enforced server-side before the chat interface collects any data. Pair this with a web scanner that continuously monitors your site for non-compliant scripts and third-party tracking. The objective is to keep the patient experience (live chat, scheduling, self-service) while ensuring the data never touches infrastructure that lacks HIPAA safeguards.