Is Mailchimp HIPAA Compliant? The BAA Answer

The short answer: as of this writing, no. Mailchimp has not made business associate agreements (BAAs) available, and Intuit Mailchimp's own terms have long directed users not to process sensitive health information through the platform. Vendor terms change, so confirm current terms with Mailchimp before relying on this. Without a BAA, no service can be used for protected health information (PHI), so Mailchimp cannot serve as a patient communication or patient marketing tool for HIPAA-covered organizations, regardless of plan tier.

That is a narrower verdict than "healthcare can't use Mailchimp." The platform remains usable for genuinely non-PHI audiences. The compliance work is knowing exactly where that line runs, because email marketing is where practices cross it without noticing.

The Deciding Rule: No BAA, No PHI

Under HIPAA, a vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate, and a signed business associate agreement is required before PHI touches the service (45 CFR 164.502(e); 164.308(b)). The BAA binds the vendor to the Security Rule's safeguards and breach notification duties. Mailchimp's standard terms offer no such agreement and explicitly discourage sensitive health data on the platform, which settles the question: the tool is uncovered.

What counts as PHI is broader than most marketers assume. Under the Privacy Rule's identifier framework (45 CFR 164.514), a patient's name and email address held by a medical practice are identifiable health information, because the list itself reveals that these people receive care from this provider. A "patient newsletter" list uploaded to Mailchimp is PHI in bulk, even if no message ever mentions a condition. Specialty practices sharpen the exposure: membership on an oncology center's mailing list discloses something meaningful by itself.

Our explainer on business associate agreements covers why encryption and security certifications never substitute for the contract.

Where the Line Actually Runs

Cannot run through Mailchimp:

Patient newsletters, recall campaigns, appointment-related email, health tips sent to patient lists.
Any list segmented by condition, treatment, medication, or visit history.
Prospective-patient nurture lists built from consultation inquiries, since intake inquiries carry health information too.

Can run through Mailchimp:

Referring-provider newsletters sent to physicians and clinics as business contacts.
Community education lists built from public signups where subscribers are not identified as patients and no health data is collected: a hospital foundation's donor newsletter, a wellness blog's public list.
Recruiting, vendor, and press communications.

The public-signup case needs honest scrutiny. A list is only non-PHI if nothing about its construction or content ties subscribers to care. The moment a front desk "adds patients to the newsletter," the list is patient-derived and belongs on covered infrastructure.

HIPAA Marketing Rules Reach Further Than the Tool

Even on covered infrastructure, patient marketing has its own gate. HIPAA generally requires patient authorization before PHI is used for marketing communications, with limited exceptions for treatment and care-related messaging (45 CFR 164.508(a)(3)). Treatment reminders, recall notices, and information about a patient's own care flow without marketing authorization; promotion of services beyond that relationship needs the signed authorization. Classify every campaign before it sends: the same message can be a treatment communication to one list and marketing to another.

On the texting side, the parallel gate is the TCPA (47 U.S.C. 227): marketing texts require prior express written consent, while consented healthcare messages ride on the consent given at intake.

What Compliant Patient Outreach Looks Like

The compliant stack replaces the uncovered generalist with covered channels:

A patient communication platform under BAA for email and SMS to patient lists, with consent records and audit trails.
Minimum necessary content. Even on covered channels, the Security Rule's transmission-risk analysis (45 CFR 164.312(e)) favors logistics-first messages, with clinical depth behind the portal. Neutral bodies, authenticated depth.
Segmentation inside the covered system, so condition-based targeting never exports to marketing tools.
Documented consent per channel: email preferences and TCPA texting consent tracked per patient, opt-outs honored across every workflow.

For many practices, the honest discovery is that most of what they wanted from email marketing, reminders, recalls, seasonal campaigns, education, works better as consented texting anyway, because texts are read quickly and answered. Our pillar guide to HIPAA-compliant text messaging covers the channel requirements, and this piece is part of the same series as Is DocuSign HIPAA compliant?, where the vendor does offer a BAA and the analysis flips.

Migrating Off Mailchimp Cleanly

If patient data is already in an uncovered Mailchimp account:

Pause patient campaigns immediately; stop new inflow from signup forms connected to patient touchpoints.
Export the lists, then delete them from the platform, and document the remediation with dates.
Reclassify every list: patient-derived lists move to covered infrastructure; genuinely public lists may remain.
Assess notification obligations. Whether historical use is a reportable breach is fact-specific under the Breach Notification Rule (45 CFR Part 164, Subpart D); involve your privacy officer and, where scale warrants, counsel.
Update the risk analysis (45 CFR 164.308(a)(1)) so email marketing is a covered, assessed channel going forward.

How to Audit Your Existing Lists in One Sitting

Most practices cannot say offhand which of their audiences are patient derived, because lists accrete over years and staff turnover. One structured pass settles it:

Inventory the audiences before the contacts. Export the list of lists, tags, and segments, including archived ones. Data you still hold counts, whether or not you still send to it.
Trace every list to its intake form. A list is only as clean as its signup point. A public blog footer is one thing; a waiting room tablet, a post-visit email, or a front desk workflow is patient derived by definition.
Read the segments, not only the audience name. A general community list carrying a "diabetes education" tag is a condition segment, and the tag itself is the disclosure.
Look at the merge fields. Last visit date, provider name, chart or account number, and insurance carrier are identifying elements under the Privacy Rule's identifier framework (45 CFR 164.514). Their presence settles the classification on its own.
Review the last ten campaigns per list. Content reveals how the list was really used. Reminder, recall, or pre-visit language means it was functioning as a patient list whatever it was named.
Write the finding down. A short memo per list with the date, the classification, and the reasoning is what makes the decision defensible later, and it feeds the risk analysis required by 45 CFR 164.308(a)(1).

Edge Cases Worth Deciding in Advance

The hospital or clinic foundation list. A donor list built from public giving is not patient derived. It changes character the moment clinical staff hand development a list of grateful patients, a transfer with its own Privacy Rule analysis that should never be improvised at the staff level.
Cosmetic and self-pay services. Covered entity status attaches to the provider and its transactions, not to how a particular visit was paid for. A practice that bills electronically for any of its services does not get a carve-out for its cash-pay patients.
Combined contact forms. A single "contact us" form feeding both prospective patient inquiries and vendor questions produces a mixed list. Split the form at the source, or treat the whole list as patient derived.
Personal staff accounts. A practice manager's own free account used for a "patient tips" newsletter sits outside every agreement your organization holds, because vendor coverage follows the organizational contract rather than the individual.
Former patients. Information about past care stays protected, so a list of people who used to be patients is still a patient list.
Referring provider lists that name patients. A newsletter to referring physicians is a business communication. A referral tracking list with patient names or case notes in the merge fields is not, and merge fields are exactly where this distinction breaks quietly.
Recall campaigns that feel like marketing. A hygiene recall or an annual exam reminder to an existing patient is care-related communication; an offer for a new elective service is closer to marketing and may need signed authorization. The texting parallel is worked through in our guide to HIPAA marketing rules for texting.

What to Ask a Patient Communication Vendor

Once patient outreach has to move, the vendor conversation is short if you ask the right questions. This is a procurement checklist, not legal advice; your privacy officer and counsel own the final call.

Will you sign a business associate agreement for the plan we are actually buying, and may we review the template before we commit?
Which parts of the product are inside that agreement, and which integrations or add-ons fall outside it?
Where is patient data stored, which subcontractors touch it, and are they bound by your agreement?
How do you capture and store consent per patient and per channel, and can we export that record?
Can you produce a full message history for a named patient on request, with timestamps and staff attribution?
How are opt-outs honored, and do they carry across email, SMS, and every campaign type automatically?
What access controls and audit logs exist, and can permissions be scoped by role and location?
What is the retention setting for message bodies, and can we configure it to match our record retention policy?
How do you support breach investigation, and what notification timelines does the agreement commit you to?
What happens to our data at the end of the contract, in what format, and on what timeline?

Frequently Asked Questions

Does Mailchimp offer a BAA on any plan?

Not that the company has published. Mailchimp has not made BAAs available on any plan tier, and its terms direct users not to process sensitive health information. Because vendor terms change, confirm directly before assuming coverage either way. No plan tier changes that, which is why patient lists cannot run through the platform.

Can a medical practice use Mailchimp at all?

Yes, for audiences that are not patients: referring providers, community education lists built from public signups, donors, press, and recruiting. The test is whether the list or content connects identifiable people to care. Patient-derived lists always fail that test.

Is a patient email list really PHI if the emails only contain wellness tips?

Yes. The list itself is identifiable health information held by a covered entity, because inclusion reveals a care relationship. Content neutrality does not cure list exposure, and specialty practices disclose the most through mere membership.

What should practices use instead of Mailchimp for patient outreach?

A communication platform that signs a BAA, keeps segmentation inside covered infrastructure, tracks consent per channel, and supports both email and SMS. For reminder, recall, and education workflows, consented texting typically outperforms email on speed of reading and response.

Do wellness newsletters to patients require marketing authorization?

It depends on classification. Communications about a patient's own treatment and care logistics generally proceed without marketing authorization; promotion of additional services generally requires signed authorization under 45 CFR 164.508(a)(3). Classify each campaign before sending and document the reasoning.

Is it automatically a HIPAA violation if patient emails were already uploaded to Mailchimp?

Disclosing PHI to a vendor with no business associate agreement is an impermissible disclosure, but whether it is a reportable breach is a separate, fact-specific determination under the Breach Notification Rule (45 CFR Part 164, Subpart D). Stop the inflow, remediate, document what happened and when, and let your privacy officer make the notification call.

Can we keep a public wellness newsletter if some patients sign up for it themselves?

Generally yes, provided the list is built only from public self-signup, no staff ever adds patients from the chart or the front desk, and no field or segment ties a subscriber to care. Write that rule into the intake process, because the exposure comes from one well-meaning addition rather than from the design.

Patient Outreach on Covered Rails

FRANSiS runs patient campaigns, recalls, reminders, education, and two-way conversations, on infrastructure built for healthcare: signed BAA included, consent documented per patient, and an AI Powered Helper managing replies. Contact us to move your patient outreach onto covered rails.