Use a CRM for HIPAA-regulated work without guesswork

HIPAA, the Health Insurance Portability and Accountability Act, regulates protected health information, usually shortened to PHI. It applies directly to covered entities: health plans, health care clearinghouses, and health care providers that transmit health information electronically in connection with certain standard transactions. It also reaches business associates, meaning vendors and service providers that create, receive, maintain or transmit PHI on a covered entity's behalf. A CRM used by a clinic, a digital health company or a medical device seller can fall into the business associate category easily, because a person's name attached to health context is PHI even when the record looks like an ordinary sales contact.

The mechanism that matters between you and a vendor is the Business Associate Agreement. A BAA is a written contract that binds the business associate to safeguard PHI, limits how it may be used and disclosed, requires it to report security incidents and breaches, flows equivalent obligations down to subcontractors, and addresses the return or destruction of PHI when the relationship ends. Without a signed BAA in place, a covered entity generally may not disclose PHI to that vendor at all. The BAA is not paperwork you tidy up afterwards. It is the precondition for the arrangement existing.

HelloGrowthCRM supports HIPAA-regulated workflows, and a Business Associate Agreement is available. {{BAA_SCOPE_TBC}} Before you store any PHI in the platform, contact sales@hellogrowthcrm.com to request the BAA and the current scope statement in writing, and confirm which product features and integrations it covers. We would rather you ask and receive a precise answer than infer coverage from a web page. Do not load PHI into a trial account, or into a production account before the agreement is executed, on the assumption that a BAA can be applied retrospectively. It cannot, and the gap will show up in your own risk analysis.

The Privacy Rule sets national standards for how PHI may be used and disclosed, and gives individuals rights over their health information, including the right to access and obtain a copy of their records, to request amendments, and to receive an accounting of certain disclosures. It also imposes the minimum necessary standard: use or disclose only the amount of PHI needed for the purpose at hand. In a CRM, that argues strongly for careful field design and tight role-based visibility, so a salesperson sees the commercial record and not clinical detail that was never needed to close the deal.

The Security Rule applies specifically to electronic PHI and is organised into administrative, physical and technical safeguards. Administrative safeguards cover risk analysis, workforce training, sanction policies and contingency planning. Physical safeguards cover facility and device controls. Technical safeguards cover access control, audit controls, integrity, person or entity authentication, and transmission security. The Security Rule is scalable, and it marks some implementation specifications as addressable rather than required. Addressable is often misread as optional. It means you must implement the specification or document a reasoned alternative, not that you may quietly skip it.

The Breach Notification Rule requires covered entities to notify affected individuals without unreasonable delay and no later than 60 days after discovery of a breach of unsecured PHI, to notify the Secretary of Health and Human Services, and to notify prominent media outlets where a breach affects 500 or more residents of a state or jurisdiction. Business associates must notify the covered entity, generally within 60 days of discovery. An impermissible use or disclosure is presumed to be a breach unless a documented risk assessment shows a low probability that the PHI was compromised.

There is no HIPAA certification scheme. The Department of Health and Human Services does not certify, endorse or approve software products, and no government body issues a HIPAA certificate to a CRM. A vendor selling a HIPAA certified product is describing a private training course, a third-party assessment it chose to purchase, or nothing at all. Independent attestations can be genuinely useful evidence about a control environment, but they do not confer HIPAA compliance, and a covered entity cannot point at a vendor's badge to discharge its own obligations under the rules.

Compliance is a property of an organisation and its practices, not of a product. The same CRM can be used compliantly by one customer and non-compliantly by another, depending on what gets entered into it, who has access, whether a BAA is signed, whether a risk analysis was performed and whether workforce members were trained. Software can make compliance achievable through encryption, access control, logging and a reliable deletion path. It cannot make an organisation compliant by itself, and any vendor implying otherwise is selling comfort rather than actual capability.

The distinction matters commercially as well as legally. If a vendor overstates its HIPAA position during a sales cycle and you rely on it, you remain the party a regulator will examine. Ask for the BAA text, read the exclusions carefully, note which features and integrations are in scope, and file the executed agreement with your compliance records. Treat vague answers as a finding to be resolved, whether they come from us or from anyone else on your shortlist. Precision, rather than enthusiasm, is the thing actually worth buying here.

On our side of the line, HelloGrowthCRM protects data in transit with TLS and encrypts data at rest. Customer data sits in Supabase-managed Postgres on AWS, with row-level security enforcing tenant isolation between accounts. Role-based access control lets you decide which users see which records. Production access at Soor LLC is least-privilege, multi-factor gated, logged and reviewed periodically. Automated backups run with point-in-time recovery, and a documented incident-response workflow covers detection, containment and customer notification. Soor LLC completed a SOC 2 Type II examination covering a February to June 2025 observation window, available under NDA from sales@hellogrowthcrm.com.

On your side, the work is configuration and process. Decide what PHI, if any, genuinely needs to live in a sales CRM, because the minimum necessary standard usually means less than teams assume. Set roles so clinical or diagnostic detail is not visible to users who have no need for it. Control integrations closely, since an export to a spreadsheet, a marketing tool or a chat channel can move PHI outside the covered arrangement in seconds. Train the people who type into free-text notes, because notes are where unplanned PHI most often appears.

You also own the risk analysis, the policies, the sanction process, workforce training and your internal incident procedures. Administrators can export account data at any time and deletion requests are honoured, which supports individual access requests and record management, but the decision about what to release and to whom stays with you. Our subprocessor list is published at /subprocessors, a Data Processing Agreement is available, the data rights process is at /legal/data-rights, and security issues can be reported through /legal/vulnerability-disclosure. Review those documents alongside your own policies, because a HIPAA programme is judged as a whole rather than control by control.

Work through a short sequence before the first record lands. Confirm whether you are a covered entity or a business associate, and whether the data you intend to store actually meets the definition of PHI. Ask sales@hellogrowthcrm.com for the Business Associate Agreement and the current scope in writing. Read it against your intended use, including integrations, email, file attachments and any reporting you plan to run. Get it executed before configuring the account for PHI, and file the signed agreement somewhere your compliance team can retrieve it without asking around.

Then configure deliberately rather than copying a standard sales template. Create roles that reflect the minimum necessary standard. Restrict who can export data. Decide whether attachments are permitted at all, and enforce that decision with training as well as with settings. Document a retention and deletion approach that reflects your own regulatory obligations, since we do not set a retention period for you and any vendor quoting one without knowing your context is guessing. Confirm the hosting region for your account during onboarding or the security review and record the answer.

Finally, plan for the failure case while nothing is on fire. Know who at your organisation receives an incident notification from us and what they do in the first hour. Map the 60-day breach notification clock onto your internal process so it does not begin with a forwarded email that nobody owns. Rehearse an individual access request end to end, including the free-text notes. None of this is exotic work, but doing it before go-live costs far less than doing it while a regulator or an anxious customer is already asking questions.