Does Your Med Spa Need a BAA With Every Software Vendor?

Quick summary

Not every vendor, but almost certainly more of them than you currently have agreements with. The test is whether the vendor creates, receives, stores, or transmits protected health information on your practice's behalf. How medical the tool feels has nothing to do with it. Run that test across your actual stack and it is common to find tools handling patient data with nothing signed. This guide covers the test, which common med spa tools usually need one, which do not, how to find the gaps, and what to do when a vendor refuses.

What makes a vendor a business associate

A vendor is a business associate if it creates, receives, maintains, or transmits PHI on your behalf. If it is a business associate, you need a signed Business Associate Agreement before it touches patient data.

Two clarifications do most of the work.

PHI is broader than clinical notes. A patient's name attached to the fact that they inquired about or received treatment at your practice is health information. So an appointment reminder with a name and a date is PHI. A marketing list segmented by treatment received is PHI. A photo that can identify a patient is PHI.

Storage is not the only trigger. A vendor that can access the data while transmitting or processing it is still a business associate. The narrow exception is a true conduit, the classic example being a telecom carrier or the postal service, which moves data without accessing it beyond temporary storage in transit. Most software vendors are not conduits, because they store the data at least temporarily and can access it.

The question to ask about every tool is simple: can this vendor, or its staff, see or hold anything that identifies one of my patients?

Which of your tools usually need one

Applying that test to a typical aesthetic practice stack:

Almost always yes.

• Practice management, EMR, or EHR. Obvious, and normally already in place.
• Booking and scheduling software, since an appointment ties a name to a treatment.
• Patient communication: two-way texting, patient portals, reminder services.
• Clinical photography and consent tools.
• Digital intake and form tools.
• Payment processing where it stores patient identity alongside treatment detail. Card data is PCI, and the linkage to a named patient and a service is the PHI question.
• Answering services and AI receptionists, since they handle patient calls.
• Cloud storage or backup holding any patient file.
• Any CRM holding patient records.
• Telehealth platforms.
• Transcription or AI scribe tools.

Usually not.

• Accounting software, where it holds transaction totals rather than named patient services.
• Payroll.
• General business email between staff that contains no PHI, though this collapses the moment someone sends a patient's information on.
• Website hosting for a purely informational site with no forms.
• Design tools, project management, and internal chat, so long as nobody puts patient information in them. That proviso fails more often than practices expect.

The ones that get missed.

• Email marketing platforms. If you segment by treatment received, or send to a list of patients, that list is PHI.
• Review request tools, since asking a named person to review their visit discloses that they were a patient.
• Analytics and advertising pixels on pages where patients enter information. This has drawn regulator attention and litigation against healthcare organizations, and it is the gap almost nobody checks.
• Anything an integration connects to. A form tool piping submissions into a spreadsheet means the spreadsheet vendor now holds PHI.
• Call tracking and recording.
• The AI tool somebody on your team started using to draft patient messages.

How to find your gaps in an afternoon

List every tool that touches a patient. Walk one patient from first inquiry to second treatment and write down every system anyone touches. Then check the card statement for subscriptions nobody mentioned.

Apply the test to each. Can this vendor see anything identifying a patient?

Check what you have signed. Most vendors publish a BAA or provide one on request. Some require you to accept it explicitly in account settings rather than providing it by default, so having an account is not the same as having an agreement. Keep executed copies in one place.

Check the plan, not just the vendor. Several vendors offer a BAA only on specific tiers. A practice on a free or starter plan can be out of compliance with no visible change to the product.

Check the integrations. Every connection is a potential onward disclosure to a vendor you never evaluated.

Write down the answer. A simple list of vendor, what it holds, BAA status, date, and where the copy lives. This is the document you would want if anyone ever asks, and it takes an afternoon once.

What a BAA actually commits them to

Worth knowing what you are getting, since practices often treat it as a formality.

A BAA obliges the vendor to safeguard PHI, to use and disclose it only as the agreement permits, to report breaches to you within a defined period, to ensure their own subcontractors are bound by equivalent terms, to make records available for compliance purposes, and to return or destroy PHI when the relationship ends.

Two points deserve attention when you read one. Breach notification timing varies and matters, because your own obligation to notify patients runs on a clock that starts when you learn of it. And subcontractors matter, since your vendor's vendors are handling your patients' data. Ask who those are, and note that some vendors publish a subprocessor list.

One thing a BAA does not do: it does not make an insecure product secure, and it does not transfer your responsibility. You remain accountable for choosing vendors appropriately.

When a vendor will not sign

Some will not, and that is informative rather than an obstacle to negotiate around.

If the vendor is handling PHI and will not sign, the tool cannot be used for that purpose. The options are to find a replacement, restrict the tool so it never touches patient data and confirm that restriction actually holds, or accept a compliance gap, which is not really an option.

The most common version of this in aesthetic practices is a general-purpose tool with a healthcare landing page. It markets to medical practices, it looks capable, and the BAA is either unavailable or gated behind an enterprise plan. Ask early, in writing, before you build a workflow on it. Discovering the answer eighteen months in, with three years of patient data inside, is a far more expensive conversation.

How PatientNow approaches this

PatientNow is built for aesthetic and elective practices, operates under a BAA, and publishes its agreement and its subprocessor list rather than providing them on request.

The wider point for a practice doing this audit is that consolidation shrinks the problem. Every additional vendor holding patient data is another agreement to execute, another access list to understand, another subprocessor chain, and another party to contact during a breach or a records request. A practice running its scheduling, clinical record, photos, consent, payments, and patient communication in one platform has one primary agreement instead of six, and one place to look when someone asks where the data is.

That is a real reduction in administrative risk rather than a feature claim, and the argument worth weighing once you see your own vendor list written down.

Related reading

• The complete guide to med spa HIPAA compliance
• How PatientNow approaches HIPAA and security

Frequently asked questions

Do we need a BAA with our email marketing platform?

If you send to patients, or segment lists by treatment received, then yes. The fact that a named person is a patient of your practice is health information, so the list itself is PHI regardless of what the email says. Several mainstream marketing platforms will not sign a BAA on standard plans, which is why practices sending patient campaigns often need a healthcare-specific tool.

What about Google Workspace or Microsoft 365?

Both can be brought under a BAA, and coverage depends on the edition and which services are included. A personal or free consumer account is not covered. If patient information passes through email, shared drives, or forms, confirm your specific configuration is in scope rather than assuming the brand is.

Is a BAA the same as saying a product is HIPAA compliant?

No, and the distinction matters. A BAA is a contract allocating responsibility. It says nothing about whether the product is well built. A vendor can sign one and still have weak access controls or no audit logging. Ask both: will you sign, and how is the data actually protected.

Do we need one with our answering service?

Yes. Anyone handling patient calls is handling PHI, whether the answering is done by people or software. Any hesitation on the BAA from an answering service or AI receptionist vendor should end the evaluation.

What if a vendor only sees data occasionally, like during support?

That still counts. Support staff who can access your account can access PHI, which makes the vendor a business associate. This is often the trigger for tools people assume are outside scope, so ask specifically what support can see.

Who signs it, and where do we keep it?

Whoever can bind the practice, usually the owner or a designated officer. Keep executed copies together with your vendor list, and record the date and plan each was signed under, since a plan change can move you outside the terms.

This guide is general information about HIPAA business associate requirements. It is not legal advice, and your obligations depend on your specific arrangements. Have a healthcare attorney review your vendor list once.