What does HIPAA require of your CRM?
A signed Business Associate Agreement (BAA) with the vendor, plus access control, audit logs, encryption and set retention rules. No CRM meets HIPAA by itself.
Want to see it first? Book a demo
The short answer
- HIPAA governs protected health information (PHI). When a CRM stores or handles PHI, the rules attach to the deal between your business and the vendor, not to the software on its own.
- A Business Associate Agreement (BAA) is a signed contract between your practice and the vendor. It has to be in place before any PHI touches the system.
- Beyond the BAA, the system needs the safeguards HIPAA is read to require: access control over who can see records, audit logs of who opened what, encryption at rest and in transit, and set rules for how long you keep data.
- A name tied to any health or appointment context generally counts as PHI. That surprises businesses that thought only diagnosis or treatment fields carried the risk.
Why 'HIPAA compliant CRM' is a misleading phrase
Some software ads call a CRM "HIPAA compliant" as if it were a fixed part of the product. That's not how the rule works. Compliance describes an arrangement: a signed BAA between your practice and the vendor, plus a system set up the right way for that use. The same software can be part of a compliant setup for one customer, with a signed BAA and the right access controls on. For another customer who never signed a BAA or turned on the settings, it isn't.
If you're thinking of storing patient or client health details in a CRM, start by asking the vendor two things. Will you sign a BAA? Which safeguards can I turn on, such as access control, audit logs and encryption? A vendor that can't or won't answer both clearly isn't a safe choice for that data, however good the rest of the product is.
What a HIPAA-covered CRM arrangement requires
| Requirement | What it means in practice |
|---|---|
| Signed BAA | A contract with the vendor, signed before any PHI is stored |
| Access control | Only the right users can view or change records that hold PHI |
| Audit logging | Tracking who accessed which records and when |
| Encryption | Data protected both at rest and in transit |
| Retention rules | Set rules for how long records are kept and how they're deleted |
What to check before storing health information in a CRM
Check that the vendor offers a BAA, and get it signed before any PHI enters the system. Turn on access control, so only the people who need health records can see them. Make sure audit logs and encryption are actually switched on, since an option buried somewhere in settings protects nothing until someone enables it.
Disclosure: SalesCrew is our product. SalesCrew makes no HIPAA claim; it holds enquiry and scheduling data, and clinical records stay in your practice system. Each practice gets its own database, with row-level security and a full export whenever it wants one.
A name plus appointment context is often already PHI
Questions
- Is any CRM 'HIPAA compliant' by default?
- No. Compliance describes an arrangement: a signed BAA plus safeguards that are set up right. Software doesn't have it on its own, apart from how you set it up and use it.
- What if the CRM only stores names and appointment times, not diagnoses?
- It's likely still covered. A name tied to any appointment or treatment context generally counts as protected health information (PHI) under HIPAA. 'We don't store medical details' covers much less than most businesses think.
- Does every CRM vendor offer a Business Associate Agreement?
- No. Ask each vendor directly before you store any health details in their system. A vendor that can't or won't sign a BAA isn't a safe place for PHI, whatever else it does well.