Is Drift HIPAA Compliant? Website Chat and PHI

No, Drift is not HIPAA compliant, and its own terms of service say so in capital letters. Drift's agreement defines Sensitive Personal Information to include data subject to HIPAA, then states that you agree not to use the platform or any services to collect, manage, or process it, and disclaims liability if you do. There is no business associate agreement on offer. Curve is the HIPAA-compliant tracking and attribution layer that lets healthcare advertisers measure conversions from chat-driven funnels without patient data reaching vendors that never agreed to hold it, with a signed BAA on every plan.

The direct answer, in more detail

Drift is a conversational marketing and website chat platform built for business-to-business sales. Its terms of service handle regulated data by exclusion rather than accommodation.

The agreement defines Sensitive Personal Information as personal data subject to specialized security regimes, naming HIPAA and the PCI standards explicitly. It then prohibits use of the platform to collect, manage, or process that data, and adds that Drift will not be responsible for any liability resulting from a customer doing it anyway. The document contains no reference to a business associate agreement at all.

So this is not the common case of a vendor that simply has not built for healthcare. It is a vendor that has anticipated the question and answered no in the contract. Deploying Drift on a page that collects health information puts you in breach of your agreement with Drift before any regulator or plaintiff is involved, and leaves you with no contractual recourse when they are.

Chat is different, because the visitor supplies the PHI

Most compliance analysis of a marketing tool asks what your team configures it to collect. Chat inverts that. The visitor types whatever they want into a free-text box, and healthcare visitors type extraordinary things.

A clinic runs a chat widget to help people book. A visitor opens it and writes: "I was diagnosed with hypothyroidism last year and my endocrinologist retired, can you take new patients." Nobody designed a field for that. No form validation caught it. The transcript now contains a diagnosis, a treatment relationship, and enough context to identify the person once they leave an email address in the next message, and it is sitting in a system whose terms prohibit exactly this.

The distinguishing feature is that you cannot prevent it by configuration. You can shorten forms, remove condition dropdowns, and sanitize URLs. You cannot stop a person from describing their symptoms in a chat box. Any control has to be procedural: what the bot says, how quickly a human intervenes, how transcripts are retained, and whether the widget appears on clinical pages at all.

Modern AI chat agents raise the stakes further. An assistant designed to qualify visitors will ask follow-up questions, and a well-tuned qualification flow in healthcare drifts naturally toward clinical detail because that is what determines fit. The better the bot, the more PHI it elicits.

Where Drift is genuinely fine

Drift's home territory is B2B, and plenty of healthcare-sector businesses live there without touching PHI.

A health tech vendor selling software to hospitals. A revenue cycle management company selling to practice groups. A medical device manufacturer talking to procurement. A staffing firm recruiting clinicians. A payer selling group plans to employers. In all of those cases the person in the chat is a professional buyer discussing a commercial matter, not a patient discussing their care, and HIPAA is not engaged.

The line is the audience, not the industry. A hospital's careers site and its patient portal are the same domain and completely different risk profiles. A device manufacturer's distributor page and its patient support page are the same thing. Widget placement, not company category, decides the answer.

Two more facts worth knowing before you build on it

Compliance analysis of a vendor is also a durability analysis, and Drift's situation has changed materially.

Drift was acquired by Salesloft in February 2024. Following Salesloft's combination with Clari, the company announced in March 2026 that Drift would be sunset, pointing existing customers toward a partner product. Public reporting indicates no hard end-of-life date has been published. If you are evaluating Drift for a healthcare site today, you are evaluating a product with an announced end, and migration planning is part of the decision. Confirm the current status with the vendor directly, since this is a moving situation.

Separately, in August 2025 attackers obtained OAuth tokens associated with the Salesloft Drift integration and used them to reach data in connected systems at a large number of downstream organizations. That incident is a useful illustration of a structural point rather than an indictment of one vendor: a chat widget is not an isolated tool. It authenticates into your CRM and other systems, and the blast radius of a compromise follows those connections. Any tool holding chat transcripts and holding tokens into your CRM deserves the scrutiny you would give a system of record.

What a BAA would and would not cover here

Drift does not offer one, but the reasoning transfers to whatever you replace it with.

A BAA permits a vendor to receive and process PHI on your behalf and imposes safeguard, breach notification, and subcontractor obligations. It does not decide who inside your organization reads transcripts, how long they are retained, or whether they are exported to a CRM that a whole sales team can search. Chat transcripts are unusually broad in access by default, because the operating model assumes any available agent should be able to pick up any conversation.

A BAA also does not extend to the model provider behind an AI chat agent. If the assistant sends conversation content to a third-party language model, that is a separate vendor with separate terms, and coverage does not flow through automatically. Ask specifically about subprocessors for AI features rather than assuming the platform's agreement covers them.

And a BAA does nothing about what the rest of the page sends. Which is the part most healthcare advertisers underestimate.

Where the ad tracking problem shows up

A chat widget is a third-party script running on your page with full visibility into the page around it. It sees the URL. It typically knows the referrer and the campaign parameters. It fires its own events. In that respect it behaves like every other tag in your stack, and it shares the same exposure.

The bigger issue sits alongside it. If the site runs a standard Meta Pixel or a raw Google tag, condition-revealing page URLs and a persistent browser identifier are already going to platforms that do not sign BAAs for their advertising products. Meta and Google are explicit about this. On a clinic site where the page slug names a treatment, every page view is a statement about an identifiable person's health interest.

That is the mechanism behind healthcare pixel litigation, which has cumulatively crossed $100 million in settlements, with Advocate Aurora settling at roughly $12.225 million. The plaintiffs' theory does not require that a diagnosis was transmitted. It requires that an identifiable person's health interest was disclosed to a third party who had no right to it.

Chat then adds a conversion-tracking wrinkle. Teams want to know which campaigns produced chat-qualified leads, so they fire a conversion event when a chat converts, and the event often carries the conversation topic, the routing queue, or the page it started on. Each of those can encode the clinical reason. We walk through the collection layer in detail in our piece on why client-side pixels create HIPAA exposure and what server-side tracking changes.

The architecture that works

If you want conversational capability on a healthcare site, the workable pattern narrows the surface deliberately.

• Choose a vendor that will sign. Start with the contract, not the feature list. A chat tool that refuses PHI by contract cannot be configured into compliance.
• Keep the widget off clinical pages. Condition pages, symptom checkers, and treatment detail pages are where visitors are most primed to describe their situation.
• Design the bot to deflect, not to qualify. The opening message should route people to booking or to an authenticated channel rather than asking what brings them in. Every qualification question in healthcare is an invitation to disclose.
• Set aggressive transcript retention limits and restrict who can read them. Default retention on marketing tools is generous because marketing data is cheap to keep. Clinical text is not.
• Fire neutral conversion events. The event that tells your ad platform a chat converted should name nothing about the topic, the queue, or the page.
• Audit the CRM sync. Transcripts pushed into a CRM note field are PHI in a system that may not be scoped for it, readable by everyone with a seat.

For the page-level version of this discipline, our guide to building clinic landing pages that convert without collecting PHI covers the same tradeoffs in form design.

How Curve handles conversion tracking for chat-driven funnels

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare. It does not provide chat. It owns the measurement layer, so that whichever conversational tool you choose, the ad platforms receive a conversion signal and nothing else.

The Curve tracking script installs on your site in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure rather than straight to the ad platforms. From there:

• Per-destination field mapping controls what forwards. Only fields you explicitly map reach a given destination, configured separately for each one. Page URLs, chat topics, routing queues, and form values stay behind unless you deliberately map them. The default is that nothing goes.
• Identifiers are hashed. Email, phone, and name are SHA-256 hashed to each platform's conversion API requirements before forwarding.
• Neutral event aliases replace descriptive names. A chat-qualified lead forwards as a generic conversion rather than one naming the service line, so the ad platform interface never displays the clinical reason.
• PHI-pattern detection monitors payloads. Curve flags PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences. It is a monitoring layer that tells you when something upstream started sending something new. The protection itself is the field mapping plus the hashing.
• Bridge tokens preserve attribution across handoffs. When a chat hands the visitor to a separate booking or intake tool, attribution normally breaks at exactly the moment it becomes valuable. Bridge tokens carry it across.
• Incoming webhooks match downstream outcomes back to the original click by email, click ID, or bridge token, and cannot override protected core attribution fields.
• Offline conversion uploads close the loop. Bulk CRM or EHR outcomes match to the originating ad click by click ID, so you can report on what chat actually produced without exporting anything sensitive to an ad platform.

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 stop suppressing it, which usually raises measured conversion volume. Every Curve plan includes a signed BAA. For the routing side, see our guide to HIPAA-compliant lead routing from ad click to CRM.

What to check on your own site

1. List every page the chat widget loads on and mark which of them are clinical.
2. Read a month of real transcripts. This is uncomfortable and it is the fastest way to learn what your visitors actually type.
3. Check who can read transcripts and how long they are retained by default.
4. Inspect the conversion event fired on chat completion and confirm it names nothing clinical.
5. Trace the CRM sync and see whether transcript text lands in a searchable note field.
6. Ask about AI subprocessors if the bot uses a language model, and get the answer in writing.
7. Watch the network tab during a test chat and read what leaves for third-party domains. Our free compliance scanner does the first pass automatically.

Frequently asked questions

Does Drift sign a BAA?

Its terms of service contain no reference to one and instead prohibit using the platform to collect, manage, or process data subject to HIPAA. If your situation depends on the answer, ask the vendor directly and get it in writing, because terms change.

Can I use Drift if I only run it on non-clinical pages?

That is the safer configuration, and it is not a guarantee. Visitors navigate, and a widget available anywhere on a healthcare domain will eventually receive an unprompted clinical disclosure. If you deploy it that way, pair it with tight retention, restricted access, and a bot script that redirects clinical questions immediately.

Is the risk really about what visitors type?

Largely, yes. Configuration controls what you ask for. It does not control what a person volunteers, and healthcare visitors volunteer a great deal. That is the defining property of chat as a channel and the reason contract coverage matters more here than for a form builder.

Does an AI chat agent change the analysis?

It sharpens it. Qualification-oriented assistants ask follow-up questions, and in healthcare those questions trend clinical. It also introduces a model provider as an additional recipient of conversation content, which is a separate vendor with separate terms.

What about the Drift sunset announcement?

Public reporting indicates Drift was announced for sunset in March 2026 following the Salesloft and Clari combination, with no published hard end-of-life date. Verify the current status with the vendor. Either way, a product with an announced end is a poor foundation for a regulated workflow.

If I replace Drift, what should I require from the alternative?

A signed BAA, documented subprocessors including any AI model provider, configurable transcript retention, role-based access to conversations, and a conversion event you control the contents of. Start with the contract and work backward to features.

Where to start

Drift is not HIPAA compliant, does not offer a BAA, and contractually forbids the exact data healthcare website visitors are most likely to type into it. For a covered entity the answer is to move conversational capability to a vendor that will sign, keep the widget away from clinical pages, and treat transcripts as clinical records rather than marketing artifacts.

The measurement problem survives whichever chat tool you pick, and that is what Curve solves. Server-side collection, per-destination field mapping, hashed identifiers, neutral event aliases, and bridge-token attribution let you prove which campaigns produced conversations that became patients, without a clinical signal reaching a platform that never agreed to hold it. A signed BAA is included on every plan. Run our free compliance scanner against your site to see what is leaving right now, or visit curvecompliance.com to walk through your stack.

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