Is HubSpot HIPAA Compliant? What Clinics Must Do First.

HubSpot can be run in a HIPAA-compliant way, but it is not HIPAA compliant by default. HubSpot offers a Business Associate Agreement (BAA) and sensitive-data features on eligible paid tiers (confirm current terms with HubSpot), and until you have the agreement signed and the settings switched on, you should not store protected health information in it at all. Compliance is a shared responsibility: HubSpot secures its platform, and you are responsible for what you put in it, who can see it, and what your website tags send to ad platforms. This piece covers what a clinic, med spa or telehealth company must do before patient data touches the CRM, why ad pixels are usually the larger exposure, how to track without leaking, and a decision table for what can and cannot go in the stack.

Protected health information (PHI) is any individually identifiable information about a person's past, present or future health condition, treatment or payment for care that is created or held by a covered entity or one of its business associates. A patient's name next to the word "consult" is contact data. The same name next to "testosterone consult, Thursday 2pm" is PHI.

What HIPAA compliant means for a CRM.

No software product is HIPAA compliant on its own, because HIPAA regulates organizations and their practices, not products. A vendor can be HIPAA-ready: it can sign a BAA, encrypt data, log access, and give you controls to restrict who sees what. Whether your use of it is compliant depends on the BAA being in place, the controls being configured, and your staff following written policies.

For a CRM that breaks into three questions. Is there a signed BAA with the vendor? Are the fields that hold PHI stored under the vendor's sensitive-data controls, with access limited to the people who need it? And does any connected system, from your website forms to your texting app to your ad accounts, receive that data without its own BAA or the patient's written authorization? In the medical practices we build systems for, the first question is usually handled and the third is where the problem lives.

What HubSpot offers and what it does not.

HubSpot will sign a BAA with customers on eligible paid tiers and provides a sensitive-data setting that lets you mark specific properties as sensitive, which adds restrictions on how those properties can be used in workflows, exports and integrations. Which tiers qualify and exactly what the sensitive-data feature covers has changed over time, so confirm the current terms with HubSpot before you plan a migration around them. The shape of the boundary has not changed.

• A BAA is a contract. It does not change how your portal behaves. You still have to turn on sensitive data, create the right properties and restrict access.
• Sensitive-data properties are the only properties that should ever hold PHI. Regular properties, notes, deal names, ticket subjects and email bodies are not covered by the same restrictions.
• Free and entry-level tiers have no BAA available. Using them for patient data is a violation regardless of how careful the team is.
• HubSpot's ads tools, which sync audiences and conversions to Meta and Google Ads, sit outside the protected boundary. Anything pushed through them has left the BAA.
• Connected apps are separate vendors. HubSpot's BAA does not cover Zapier, Make, a texting app or a call tracker; each one that touches PHI needs its own agreement.

The pixel problem is bigger than the CRM.

Most clinics worry about the CRM and forget the website. The Meta Pixel and Google tags on a typical medical site fire on every page, including condition and treatment pages and the booking confirmation. When a visitor lands on a URL like /services/weight-loss-injections and the pixel sends that URL with the visitor's browser identifiers to an ad platform, the platform now holds a record connecting an identifiable person to a health interest. If that visitor then books, the pixel on the thank-you page sends a conversion event, and the platform holds a record that the person became a patient. Nothing in the CRM had to be misconfigured.

This has drawn regulatory attention. The Department of Health and Human Services has published guidance on tracking technologies used by HIPAA-regulated entities, and the Federal Trade Commission has brought enforcement actions against digital health companies for sharing user health data with advertising platforms, alongside its own guidance under the Health Breach Notification Rule. A federal court later narrowed part of the HHS guidance for unauthenticated pages, but the FTC's position, state consumer health privacy laws and private lawsuits remain. The practical read: treat any page where a condition, treatment or appointment is implied as a page where standard pixels should not run unmodified.

How to set up HubSpot for PHI, step by step.

Tracking without leaking PHI.

You can still measure marketing. The rule is that the ad platform should learn that someone became a lead, not what they became a lead for. Four practices get you there, and they work together.

• Consent-gate every marketing tag. Load Google Tag Manager with all ad tags in a consent-required state and fire them only after an explicit opt-in. Keep ad tags off condition, treatment and booking pages regardless of consent.
• Move conversions server-side. Send a single generic conversion event from your server or a server-side Tag Manager container after a booking, stripped of URL, page title, service type and form values. Match on a hashed email only with documented consent.
• Keep PHI out of URLs, form field names and event parameters. Use /book rather than /book-ed-consult, name fields by function rather than by condition, and never pass service, provider or appointment time as an event parameter.
• Keep the CRM and the ad platform on separate rails. HubSpot can record the full lead under sensitive properties; the ad platform gets a count and nothing else.

Calls, texts and recordings.

Phone and text vendors become business associates the moment a patient says why they are calling. If you record calls with CallRail or a similar tool, or text patients from a platform connected to HubSpot, you need a BAA with that vendor and a documented consent practice. Call recording consent rules vary by state, and some states require every party to consent, so an announcement at the start of the call is the safe default everywhere. For texting, get written consent for appointment reminders and keep clinical detail out of the message: "your appointment is confirmed for Thursday at 2pm" rather than the name of the treatment. Do not pipe transcripts or SMS threads into non-sensitive properties or into notes the marketing team can read.

Telehealth companies have the hardest version of this because nearly every page implies a condition. The pattern that holds up is to separate the public marketing site from the authenticated patient portal, run pixels only on pre-condition pages, and let the portal report a single generic conversion through the server.

What can and cannot go in the stack.

The table below is the decision rule we use when configuring a CRM and ad stack for a med spa, clinic or telehealth company. The ad-platform column does not change with your HubSpot tier, because no ad platform signs a BAA for advertising use.

Mistakes we see most.

• Putting the treatment in the deal name or ticket subject. The name then shows up in notification emails, mobile alerts, exports and every connected app, none of which respect the sensitive-data flag.
• Leaving HubSpot's ads audience sync on for a lifecycle stage such as Booked or Patient. A list of patients has just gone to an ad platform as a custom audience.
• Running the Meta Pixel through Google Tag Manager on every page, including thank-you pages whose URL contains the service slug. The confirmation page is the most common leak we find in an audit.
• Assuming the HubSpot BAA covers connected tools. Zapier, Make, texting apps and call trackers each need their own agreement or need to be cut off from sensitive properties.
• Giving the marketing team or an outside agency full property access because it was easier than building permission sets. Agency logins should never see sensitive properties.
• Trusting a consent banner that loads tags before the visitor clicks. Many banners fire tags on page load and only stop after a decline, so the first page view has already leaked.