Can PHI Live In A Standard HubSpot Property?

HubSpot
Written By Anne Fellini

This comes up in almost every healthcare portal we audit… somebody built a field called "Condition" or "Medication" or "Diagnosis Date" three years ago, it filled up, and nobody flagged it. It looks like a normal property. It behaves like a normal property. It's a problem.

Here's what HubSpot actually gives you, what it costs to fix, and the handful of things that surprise people after they flip the switch.

What HubSpot offers, and who can use it

HubSpot has a Sensitive Data setting. You create a property, open the Sensitive Data tab, choose Sensitive Data or Highly Sensitive Data, and if the field holds HIPAA-protected health data you check the PHI box.

It's Enterprise only. Marketing, Sales, Service, Data, Content, Smart CRM, Revenue Hub... all Enterprise. There's no Professional tier for this.

So if you're on Professional and collecting health information, that data is in standard properties right now, because there's nowhere else for it to go. That's a licensing conversation before it's a build conversation.

The setup is a one-way door

Turning on Sensitive Data requires Super Admin permissions, and once it's on you can't turn it off. You pick data categories during setup, and you can add categories later but never remove one.

To store HIPAA-covered data specifically, you check two boxes: Health/Medical Data, and "we are a HIPAA-covered entity or business associate." That second one is how HubSpot tracks the BAA.

None of that is a reason to avoid it. It's a reason to make the call deliberately, with your compliance contact in the room, instead of during a Tuesday afternoon build.

The retrofit is a migration

Once a property is created, its Sensitive Data setting cannot be changed. A sensitive property can't be made non-sensitive, and a non-sensitive property can't be made sensitive.

There's no toggle, in either direction.

So fixing a standard property that's been holding PHI means creating a new property with the right designation. Migrating the values. Updating every workflow, list, form, integration, and report pointing at the old field. Deleting the original. Then confirming it's actually gone, including from exports.

For one field, that's an afternoon. For a portal with three dozen, that's a project. And every month you wait adds records to migrate and references to chase.

Worth knowing before you plan: calculation, rollup, property sync, and HubSpot user properties can't store Sensitive Data at all, and you can't require unique values on a Sensitive Data property. If you were using one of those as a dedupe key, that's a rebuild too.

What you give up

Sensitive Data isn't supported in chatbots, personalization tokens, playbooks, or sandboxes.

The sandbox one bites teams who test everything in a sandbox first. You can't, not for this.

Workflows mostly work, with specific carve-outs. You can use Sensitive Data properties in "when a filter criteria is met" enrollment triggers and in AND/OR branches, and you can use personalization tokens in the Edit record action to copy values. What doesn't work: copy property actions referencing a Sensitive Data property, personalization tokens that reference one, and "when an event occurs" triggers based on changes to a sensitive value.

That last one matters. If your automation depends on reacting the moment a clinical value changes, that pattern is off the table and you'll need a different trigger.

On AI: Breeze works with Sensitive Data turned on, but restrictions keep sensitive custom property values out of it. Your Sensitive Data properties won't be used to train Breeze models, though other customer data in your account may be, and you can opt out by emailing HubSpot's privacy team.

Three things nobody sees coming

Your data center gets locked. If you indicate you're storing HIPAA data, you can't migrate to another regional data center. Accounts that haven't indicated HIPAA storage are still eligible to move from North America to the EU. If a data residency requirement is anywhere in your future, sequence that decision first.

Data mirroring turns off. An account with Sensitive Data on can't be a source account for data mirroring in multi-account management. If yours already is one, turning on Sensitive Data automatically shuts it off. For a multi-brand or multi-region setup, that's a real architectural consequence.

Downgrading doesn't undo it, it strands it. If you drop off Enterprise with Sensitive Data on, Super Admins can delete existing Sensitive Data properties but can't create new ones or edit existing ones. Super Admins keep view and edit access to the values. Everyone else who had access loses it.

So the data stays, mostly frozen, and your team loses access to it. That's the worst version of this to discover during a renewal negotiation.

Attachments have a timing problem

Files get the extra encryption layer when uploaded to a record, via a note, from a contact's email, through the mobile app, into a file-type property, via form submission, or by import. But only files uploaded after Sensitive Data is turned on. Existing files stay at the standard security level.

So every lab result and intake PDF already sitting on your records is unprotected, and turning the setting on doesn't retroactively fix them.

Files in the files tool never get the protection, so sensitive files shouldn't live there. And attaching an existing file from the files tool to a record keeps it at standard security.

Forms are actually fine

Worth saying straight up, because people assume the opposite.

HubSpot forms and non-HubSpot forms can both collect sensitive information. It's encrypted and synced into the CRM securely, uploaded files associated with a Sensitive Data property are treated as sensitive, and only users with permission can view the submission values. Notifications follow the same rules.

So your intake form isn't the problem. Where the data ends up is the problem.

Where the info actually goes

HubSpot is built for patient relationship management, not clinical documentation. Engagement data can live there. Clinical records belong in your certified EHR or EMR.

That's the principle we build to. On one telehealth migration we pulled protocol and treatment properties out of the CRM entirely. Not a capability question... it's that clinical logic living in two systems gives you two answers to the same question and no way to know which is right.

Find out what you've got

HubSpot has a scan that looks for sensitive information sitting in CRM activities like notes, calls, tasks, emails, and meetings. You pick the data types to scan for, exclude keywords, and get an email when results are ready. Super Admins can redact flagged values once Sensitive Data is configured.

And you can review scan results even if Sensitive Data isn't turned on yet. Which makes it the right first move for anyone still deciding, including Professional customers building a case for the upgrade.

Then do the low-tech version too. Read every custom property name on the contact object out loud. You'll know the problem fields when you hear them.

Resources

Anne Fellini
Next

What Is Bot Filtering on HubSpot Emails? (And Should You Care?)