HIPAA Compliant CRM: What to Look For
There is no such thing as a CRM that is certified HIPAA compliant out of the box. HIPAA does not certify software. What exists is a vendor willing to sign a business associate agreement (BAA), a set of technical and administrative safeguards configured correctly, and a covered entity that uses the tool the way its own policies require. A CRM is compliant, or is not, based on all three of those together, not on a badge on a pricing page.
That distinction matters because many CRM shopping guides skip it. They list feature checkboxes instead of asking the two questions that actually determine risk: will this vendor sign a BAA, and can the account be configured so that protected health information (PHI) is handled the way the HIPAA Security Rule, at 45 CFR Part 164, Subpart C, requires.
What "HIPAA compliant CRM" really means
Under HIPAA, a vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate. The covered entity is required to have a signed BAA with that vendor before PHI touches the system, per 45 CFR 164.502(e) and 164.308(b). No BAA means the arrangement is not permitted, regardless of how the software is described in marketing copy.
Once a BAA is in place, compliance shifts to configuration and use. The Security Rule requires administrative, physical, and technical safeguards, but it does not name a specific product. A CRM can be used in a compliant way or a non-compliant way depending on how access is granted, how data is logged, and how long records are kept.
Five things to verify before you buy
Ask a vendor these questions directly, and get the answers in writing before any PHI enters the system.
| Requirement | What to check | Why it matters |
|---|---|---|
| BAA availability | Will the vendor sign a BAA on your current plan tier, not only an enterprise tier you have not purchased | No signed BAA means the vendor cannot legally handle PHI for you |
| Access controls | Role-based permissions, unique user IDs, and the ability to restrict who sees which records, per 45 CFR 164.312(a) | Limits exposure if one login is compromised |
| Audit logging | Does the system log who accessed or modified a record and when, per 45 CFR 164.312(b) | Needed for breach investigation and periodic access review |
| Retention and disposal | Can you set retention schedules and confirm secure deletion when records are purged, matching your own retention policy | Keeping PHI longer than necessary increases breach exposure |
| Workforce training support | Does the vendor document the shared-responsibility split so staff know what they still control | Workforce training is required under 45 CFR 164.308(a)(5), and it is the covered entity's obligation, not the vendor's |
None of these are optional extras. A CRM missing any one of them is not ready for PHI, however it markets itself.
General marketing CRMs need a closer look
Many popular marketing and sales CRMs were built for retail and B2B use cases, not healthcare. Whether a widely used platform offers a BAA, and on which pricing tier, changes over time and can vary by product line within the same company. The Mailchimp HIPAA compliance breakdown is a good example of how this plays out in practice: a tool can be strong for general marketing and still be the wrong choice for a workflow that touches PHI, depending on what its current BAA terms actually cover. Always verify current BAA availability directly with the vendor, in writing, rather than relying on a sales page or a third-party summary, including this one, since terms change.
CRM plus EHR: where the real risk shows up
The highest-risk moment for most healthcare CRMs is not storage, it is integration. When a CRM pulls appointment data, diagnosis codes, or patient contact preferences from an electronic health record (EHR), PHI is now flowing through two systems and an interface between them. Each hop needs its own safeguards, and the BAA needs to cover the integration itself, not only the CRM in isolation. If your CRM strategy includes syncing with an EHR, review how that data path is secured before you connect it. See how EHR-to-SMS integration is typically structured for a walkthrough of what a compliant data path looks like from end to end.
Building the internal checklist your team can actually use
Once the vendor answers are in hand, translate them into an internal checklist that your compliance and IT teams review together, not something that lives only in a sales conversation. Confirm the BAA is signed and names the specific CRM product in scope, since some vendors sell multiple products under one brand and only cover certain ones. Document which fields in the CRM are expected to hold PHI, since not every field needs the same level of scrutiny; a contact's name and phone number carries different risk than a free-text notes field where a staff member might paste clinical detail.
Confirm who inside your organization has access to PHI-bearing records in the CRM, and whether that access list is reviewed on a schedule rather than set once and forgotten. Confirm the retention settings match your organization's documented retention policy, not the vendor's default, since defaults are often set for general business use rather than healthcare recordkeeping requirements. Finally, confirm that offboarding a staff member actually revokes their CRM access immediately, since a lingering login is a gap that commonly surfaces during internal reviews.
Reading a vendor's security page correctly
Most CRM vendors publish a security or trust page, and it is worth reading closely rather than skimming for reassuring language. Look for the word "available" next to a BAA, not just "supported" or "compliant," since those softer terms often describe a feature set rather than a signed contractual commitment. A page that lists encryption at rest, encryption in transit, and general industry security certifications is describing overall security posture, which is a different question from whether the vendor will actually execute a BAA with your organization on your plan.
It also helps to ask how the vendor itself uses subprocessors, meaning other companies it relies on for hosting, email delivery, or analytics. Under HIPAA, those subprocessors may also need to be covered by downstream agreements if they will have access to PHI flowing through the CRM. A vendor that cannot explain its subprocessor chain, or that treats the question as unusual, is a signal to look more closely before committing PHI to the platform.
What a compliant rollout actually looks like
Once a vendor clears the five checks above, the rollout itself still needs structure. Start with a pilot group and a limited set of PHI fields rather than migrating every record on day one, so any configuration gaps surface with a small, correctable blast radius instead of an organization-wide exposure. Assign one person as the owner of the CRM's access list, responsible for reviewing who has permissions on a set schedule, and for revoking access the same day someone leaves the organization or changes roles.
Document the rollout decisions as they are made, including which fields are treated as PHI, who approved the BAA, and what retention schedule was configured, so a future compliance review or OCR inquiry can be answered from records rather than from memory. Treat the first ninety days after go-live as an active monitoring period, checking audit logs regularly rather than assuming the initial configuration will hold without drift as new staff are added and new workflows get built on top of the CRM.
Where FRANSiS fits
For healthcare organizations that need patient text communication layered on top of a CRM or EHR, rather than a general-purpose marketing CRM stretched to cover PHI, FRANSiS's healthcare messaging tools are built around a signed BAA and configurable access controls from the start, rather than added on top of a platform designed for retail marketing.
This article is general information, not legal advice. Requirements vary by jurisdiction and change over time, so confirm your own obligations with qualified counsel or the relevant regulator.
Frequently Asked Questions
What makes a CRM HIPAA compliant?
No CRM is compliant by default. It becomes usable for PHI when the vendor signs a BAA, when access controls and audit logging are configured correctly, and when staff follow the workforce training and retention policies HIPAA requires. Compliance is a combination of vendor agreement, configuration, and use, not a single feature.
Does every CRM vendor offer a BAA?
No. BAA availability varies by vendor and often by pricing tier within the same vendor, and it changes over time. Never assume a BAA is included just because a product is marketed toward healthcare. Ask directly and get the answer in writing before entering any PHI.
Can I use a free or standard-tier CRM plan for patient data?
Only if that specific tier includes a signed BAA and the safeguards HIPAA requires. Some vendors reserve BAAs for higher-priced or enterprise tiers, so confirm per plan tier. Using a lower tier without a BAA to handle PHI creates a compliance gap regardless of how capable the software otherwise is.
What is a business associate agreement?
A BAA is a contract required under 45 CFR 164.502(e) between a covered entity and any vendor that creates, receives, maintains, or transmits PHI on its behalf. It defines how the vendor will safeguard the data and what happens in the event of a breach. Without one, the vendor legally cannot handle PHI for the covered entity.
Do I still need staff training if the CRM is compliant?
Yes. Workforce training is a separate requirement under 45 CFR 164.308(a)(5) and is the covered entity's responsibility, not the vendor's. A well-configured CRM does not remove the need to train staff on access limits, minimum necessary use, and reporting suspected breaches.
How is a HIPAA compliant CRM different from a regular CRM with security features?
Encryption and login security alone do not make a system HIPAA compliant. The defining requirement is the signed BAA plus the full set of administrative, physical, and technical safeguards in 45 CFR Part 164, Subpart C. A regular CRM can have strong security and still be the wrong tool if the vendor will not sign a BAA.
What happens if a non-compliant CRM is used for PHI by mistake?
It is treated as an unauthorized disclosure and a potential reportable breach under the HIPAA Breach Notification Rule, 45 CFR Part 164, Subpart D. The response depends on the scope of data exposed. Involve a privacy officer and counsel immediately rather than assessing the situation informally.
Should healthcare organizations use one system for CRM and EHR data?
Not necessarily. Many organizations keep clinical records in the EHR and use a CRM for scheduling, outreach, and communication preferences, connected through a secured, BAA-covered integration. What matters is that every system, and every connection between systems, has its own safeguards, not that everything lives in a single platform.
Text patients without gambling on compliance
FRANSiS gives healthcare teams a messaging layer built for PHI from the ground up, with a signed BAA included and access controls you configure to match your own policies. Contact us to see how it fits alongside your existing CRM or EHR.
