← Journal

Compliance

What a Business Associate Agreement actually covers (and why some CRMs charge extra for one)

A Business Associate Agreement is the legal mechanism that makes any vendor — your CRM, your SMS provider, your email host — responsible for protecting patient data. HIPAA §164.504(e) sets out eight things every BAA must address. Most operators have never read theirs. Here is the plain-language version, the loopholes that hide inside, and the questions to ask before signing one.

The Lumè team8 min read

Most medspa operators discover the words "Business Associate Agreement" the same way: they open a sales call with a CRM vendor, mention HIPAA, and the rep says "yes, we sign a BAA." The reassurance feels enough. It is not.

A BAA is not a checkbox. It is a contract that allocates specific HIPAA obligations between you (the Covered Entity) and the vendor (the Business Associate). The OCR has been clear in enforcement actions that the existence of a BAA is not what protects you — the quality of the BAA is. A vague BAA that gives the vendor a lot of carve-outs and the Covered Entity a lot of residual risk is worse than useless, because it creates the impression of compliance without the substance.

This piece walks through what the BAA actually has to do, in plain language.

What HIPAA requires from a Business Associate

45 CFR §164.504(e)(2)(ii) lists the substantive obligations. Every BAA must address each of these — in some form, with some level of specificity:

1. Permitted uses and disclosures of PHI

The BAA must specify exactly what the vendor is allowed to do with PHI. The narrower the better: "to provide the contracted CRM service" is good; "for any purpose related to Lumè's business" is alarming. Vendors who use PHI for product analytics, AI training, or marketing must disclose that here.

2. A prohibition on using PHI for the vendor's own purposes

Outside what is permitted in clause 1, the vendor must agree not to use or disclose PHI. The classic loophole: vague "service improvement" language. If you cannot tell from the BAA whether your patient data could end up in a vendor's analytics product, the language is too vague.

3. Appropriate safeguards

The vendor must implement administrative, physical, and technical safeguards required by the HIPAA Security Rule. Strong BAAs reference specific controls (encryption, audit logging, access management). Weak BAAs use the phrase "industry-standard safeguards" with no further definition.

4. Reporting requirements

The vendor must report any use or disclosure of PHI not permitted by the BAA, including any security incident. Strong BAAs specify a timeline (e.g., "within 48 hours of discovery"). Weak BAAs say "promptly" and let the vendor define the word.

5. Subcontractor flow-down

Any subcontractor the vendor uses to create, receive, maintain, or transmit PHI must agree in writing to the same restrictions and conditions. This is the BAA cascade. Ask vendors for the list of subprocessors they use, in writing.

6. Individual rights support

The vendor must make PHI available to the Covered Entity to support a patient's rights to access (§164.524), amendment (§164.526), and accounting of disclosures (§164.528). The operational question: if a patient asks for their records, can the CRM produce them in a reasonable time?

7. HHS audit cooperation

The vendor must make its internal practices, books, and records relating to PHI use available to HHS for purposes of determining the Covered Entity's compliance with HIPAA. Important if you are ever investigated: your vendor's practices may be part of the audit.

8. Return or destruction on termination

At the end of the contract, the vendor must return or destroy all PHI in its possession. A surprisingly common gap: vendors that retain PHI in backups indefinitely with no destruction commitment. Strong BAAs require destruction within a specified window (often 30 days for primary data, 90 days for backups).

The four loopholes to watch for

1. The "secure plan" upsell

Some platforms market HIPAA-compliance as a premium feature. The BAA is gated behind the Premier-and-up tier; the Essentials customer is on a different architecture without equivalent safeguards. Functionally, this means: the BAA exists, but only if you pay 2x for it. It also means the vendor maintains two products in parallel — one compliant, one not — and you should ask what guarantees exist that the non-compliant version cannot accidentally process PHI.

2. "Industry-standard safeguards"

The phrase appears in almost every weak BAA. It is legally ambiguous enough to mean anything. Strong BAAs name controls: AES-256 encryption at rest, TLS 1.2+ in transit, SOC 2 Type II audit, append-only audit logging. If the BAA does not name controls, ask the vendor to add them as an exhibit.

3. Indemnification carve-outs

Some BAAs include a clause that the vendor's total liability for a breach involving PHI is capped at the fees you paid in the preceding twelve months. For a $5,000-per-year CRM, that is $5,000 of indemnification against what could be a million-dollar HIPAA penalty. Read the limitation-of-liability section carefully; an unlimited carve-out for HIPAA-related damages is the strong position.

4. The "service improvement" exception

Watch for language that lets the vendor use de-identified or aggregated PHI for "service improvement," "analytics," or "AI training." Once data is genuinely de-identified per §164.514(b), HIPAA stops applying — but the standard for de-identification is high (Expert Determination or Safe Harbor), and vendors sometimes claim de-identification without meeting it.

What "BAA included at every tier" actually means

Several CRM platforms now market "BAA included," but the substance varies. Three patterns we have seen:

  • BAA included, single architecture. Every customer is on the HIPAA-compliant infrastructure because there is only one infrastructure. The BAA covers everyone equally.
  • BAA included, premium tier required. The BAA is "included" in the sense that the vendor will sign one — but only on the Premier-and-up plan. The Essentials customer cannot get a signed BAA.
  • BAA included, no encryption commitment. The signed BAA exists but lacks specific safeguard commitments. The vendor satisfies §164.504(e)(2)(ii)(B) in form but not in substance.

Ask vendors: "What does the BAA you sign with my plan commit you to, specifically?" If the answer is general or evasive, you are buying the impression of compliance.

Where the BAA does not protect you

Two limits worth understanding clearly:

The BAA does not make the vendor the Covered Entity. Your obligations under HIPAA Privacy Rule — to provide a Notice of Privacy Practices to patients, to train your staff, to maintain a written authorization on file for any non-treatment disclosure — remain yours. The BAA covers the vendor's piece; it does not cover yours.

The BAA does not preempt state law. California's CMIA, Texas's HB 300, New York's SHIELD Act, and Massachusetts 201 CMR 17.00 all impose obligations that the BAA does not address. State-specific clauses can be added to a BAA, but most vendor templates do not include them by default.

How to read a vendor BAA in 15 minutes

The structured read:

  1. Section 1 (Definitions): skim for any customized definition of "PHI." Standard definitions reference §160.103.
  2. Permitted Uses: read every word. Anything ambiguous here is a question for the vendor.
  3. Safeguards: look for specific controls named — encryption, audit logging, access management. Lack of specificity is a weak signal.
  4. Breach Notification: confirm the notification window. HIPAA allows up to 60 days; the stronger BAAs commit to faster (30 or 15 days, often "without unreasonable delay").
  5. Subcontractors: confirm flow-down language and ask for the current subprocessor list as a separate document.
  6. Term and Termination: confirm return/destruction obligations with a specific timeline.
  7. Liability: look at the Master Services Agreement, not the BAA, for the liability cap on PHI breaches. If the cap is "12 months of fees" with no carve-out for willful misconduct or gross negligence, ask about that.

Fifteen minutes spent reading the BAA before signing is the cheapest insurance available in this entire category.

How Lumè's BAA is structured

We publish a summary of what our BAA covers at /baa. The short version:

  • One architecture, one BAA. Every Lumè customer is on the HIPAA-compliant infrastructure because there is only one infrastructure. The BAA is included in the standard contract at every tier — not a premium-tier feature, not a separate negotiation.
  • Named controls. Tenant isolation at the database, role-based permissions resolved per request, append-only audit logging, AES-256 at rest via AWS KMS, TLS 1.2+ in transit. These are written into the BAA exhibits, not gestured at as "industry-standard."
  • Disclosed subprocessor list. AWS, Twilio, and our payment processor operate under BAAs with Lumè. Resend (used only for marketing-site forms) does not handle PHI. We update the list when a subprocessor changes.
  • No data-export fee, ever. Return on termination is one-click CSV across every report. We do not gate export behind a paid plan or a separate fee.

We share the BAA template before contracting so your counsel can review it alongside the Master Service Agreement. Email legal@lumecrm.com for a copy, or request it during your demo and we will send it before the follow-up call.


References: 45 CFR §160.103 (Business Associate definition); 45 CFR §164.502(e) (BAA requirement); 45 CFR §164.504(e) (BAA contractual contents); 45 CFR §164.410 (Business Associate breach notification); HHS Office for Civil Rights sample BAA provisions.

Get a demo

See Lumè running on your medspa, not a generic one.

Send us your service menu. We configure the demo on your real data. Thirty minutes. The first call is the demo.