What makes a CRM HIPAA compliant?
Nothing about the brand. Compliance is a property of the arrangement, and it has three parts: the vendor signs a business associate agreement that covers the specific product and plan tier you deploy; the implementation applies minimum necessary so the system holds only what its workflows genuinely need; and the organization can verify who and what can read, sync, or export the data. A vendor page that says "HIPAA compliant" speaks to the first item only - the other two are always your work.
The unit of evaluation is the plan tier and product line, not the logo. Several mainstream CRM vendors offer BAAs, but typically on specific editions, sometimes with features contractually switched off, and generally not on free tiers. Two organizations can run the same brand-name CRM where one is covered and the other is not.
The evaluation checklist
| Criterion | What to require | How to verify |
|---|---|---|
| BAA scope | Covers the exact product, edition, and add-ons you deploy | Read the agreement against the subscription invoice, line by line |
| Access control | Role-based access; marketing roles see marketing data, not chart-adjacent detail | Log in as an ordinary marketing user and test what opens |
| Audit logging | A record of who read and exported what, and when | Pull the log and confirm export events actually appear in it |
| Encryption | In transit and at rest, vendor-attested | Security documentation (SOC 2 or equivalent), not the sales deck |
| The CRM's web script | The sitewide visitor beacon treated as its own data flow | Runtime capture on your own pages, before and after consent |
| Outbound integrations | Every connected app reviewed as a new recipient | Inventory the marketplace connections and syncs, then re-check quarterly |
| Retention and deletion | Records leave when they should, everywhere they were copied | Run one deletion end to end and look for the survivors |
The CRM's own tracking script is a separate question
Most marketing CRMs ship a website beacon that joins anonymous browsing to the contact record the moment a visitor becomes known - that join is the product. On a healthcare site it means a browsing history across condition and service-line pages, attached to a name, held in a marketing database. The BAA may squarely cover the stored records; whether it covers the sitewide beacon, and whether that beacon should run on sensitive paths at all, are separate determinations that most procurement processes never make.
From the field: the CRM beacon is one of the most common finds in runtime audits on pages the marketing team believes are untracked - it ships inside the form embed or chat widget and defaults to sitewide.
Where CRMs leak: the integrations
The database itself is usually the best-governed part of the system. The exposure is what it is connected to: enrichment vendors that receive contact lists and return demographics, audience syncs that push segments to advertising platforms, email tools, spreadsheet exports, and automation bridges wired up long ago. Each connection is a recipient of whatever the CRM knows - and an audience sync of an oncology-interest segment to an ad platform is a disclosure to a vendor that has no BAA path at all.
The marketing CRM and the clinical record
A defensible design draws the boundary explicitly: the EHR is the clinical record; the CRM holds the marketing-consented slice - identity, source, service-line interest, communication history - and the flows between them are one-directional, documented, and minimal. When the boundary is undrawn, the CRM accretes clinical detail one convenient import at a time, and its risk profile quietly becomes the EHR's without the EHR's controls.
What order should selection follow?
Classify the data first: write down what the workflows actually need the CRM to hold. Then shortlist vendors by BAA availability at the tier you would really buy. Then, before go-live, verify at runtime - the beacon, the integrations, the notification emails - and put the re-check on a calendar. Teams that start from a feature matrix end up negotiating compliance retroactively, from the weaker position.