Most practice owners can name half of their marketing vendors and almost none of their Business Associate Agreements. That asymmetry is one of the most common sources of avoidable compliance risk in healthcare marketing today.
The Business Associate Agreement, or BAA, is the document that turns a vendor relationship into a HIPAA-defensible one. It is not a formality. It is not a checkbox. It is the legal instrument that assigns responsibility for protected health information when that information flows from the medical practice — the covered entity — to a third-party vendor that handles, processes, transmits, or could touch that data on the practice’s behalf.
Almost every modern marketing setup involves multiple vendors who, in some configuration, touch data that could be PHI. The question of which ones have BAAs in place, and which ones should, is one of the most important inventories a practice can maintain. It is also one of the most commonly neglected.
What a BAA Actually Does
At a structural level, a BAA does three things.
It commits the vendor — now a Business Associate of the practice — to safeguard PHI in accordance with HIPAA standards. The vendor agrees to specific security practices, access controls, and breach notification procedures.
It allocates legal responsibility. If a breach occurs at the vendor’s level, the BAA defines who notifies whom, who bears what cost, and how the consequences are shared. Without a BAA, the practice often bears responsibility for a breach that occurred entirely on the vendor’s infrastructure.
And it creates the legal basis for the data flow to occur at all. Without a BAA, transmitting PHI to a vendor is, by default, an impermissible disclosure under HIPAA — full stop. The BAA is what makes the transmission legal in the first place.
This third point is the one most often misunderstood. The BAA does not just protect the practice if something goes wrong. It is the prerequisite for the data flow being permissible in the ordinary course of business.
Which Marketing Vendors Need One
The principle for deciding which vendors need a BAA is straightforward. If the vendor handles, processes, transmits, or could plausibly come into contact with PHI as part of providing services to the practice, the vendor needs a BAA.
In a typical medical practice’s marketing setup, that principle sweeps in more vendors than most owners expect. The list usually includes the CRM, the email marketing platform if patient identifiers are stored there, the SMS platform if it handles patient communications, the call tracking provider, the chat widget vendor if it captures inquiries from the website, the analytics tool if it processes identifiable visitor data, the form provider if forms collect health-context information, and any hosting or data warehousing arrangement where lead data sits at rest.
Some vendors are less obvious. The ad platform itself may need BAA coverage for certain enterprise data products even if the basic ad service does not. The website hosting provider, if patient identifiers are stored on the host, may require coverage. Backup and disaster recovery vendors who store copies of any of the above need to be in scope.
The simplest way to build the inventory is to follow the patient identifier. Wherever a name, email, phone number, or other identifiable patient data goes — even briefly — that endpoint needs to be checked for BAA coverage.
Which Vendors Will and Will Not Sign
Not every marketing vendor will sign a BAA. Their willingness, and the substance of what they sign, is a key piece of information for the practice.
Major CRM platforms designed for healthcare or that have built healthcare-friendly tiers — including platforms commonly used in the medical practice space — will sign BAAs as a standard part of their enterprise contracts. The practice typically needs to be on the appropriate tier and request the BAA explicitly. It is not always offered by default.
Many email marketing platforms will sign BAAs only on their higher tiers and may charge extra. Some will not sign at all. A practice using a non-BAA platform to send identifiable communications to patients is operating outside HIPAA expectations regardless of how routine the communication looks.
Most consumer-grade ad platforms — Meta, Google’s standard advertising products, TikTok, and similar — do not sign BAAs for their general ad services. Some of their enterprise data products have BAA paths. The implication is not that healthcare practices cannot use these platforms. It is that the data flowing to them must be designed not to include PHI, which is what the server-side and pixel-architecture work in this category addresses.
Call tracking platforms vary widely. Some sign BAAs and have purpose-built healthcare configurations. Others refuse on policy grounds. The choice of provider matters more than most practices realize.
Chat widgets, session recording tools, and form builders likewise vary. The vendor selection at this layer is where many practices accumulate exposure they did not know existed.
Building the BAA Inventory
The practical exercise is to build a simple register. List every marketing-adjacent vendor the practice uses. For each, note what kind of data the vendor touches, whether a BAA is in place, where the executed BAA is stored, when it was last reviewed, and who at the vendor signed it.
Most practices have never assembled this register. The first time they do, several gaps usually appear. Vendors that should have BAAs do not. Vendors that have BAAs cannot produce the executed copy on request. Old BAAs sit on file from agencies the practice no longer works with, while current vendors operate without one.
The register itself is the deliverable. Once it exists and is maintained, the practice can see its actual BAA posture at a glance, identify gaps, and address them in order of priority. Counsel can review the register quickly without having to reconstruct it from scratch every time a question arises.
What to Do When a Vendor Will Not Sign
A vendor’s refusal to sign a BAA is not necessarily a deal-breaker. It depends on whether the vendor actually needs to touch PHI in the way the practice is using it.
If the vendor’s services can be configured so that no PHI ever flows to them — through data minimization, anonymization, or scope restriction — then a BAA may not be required. The configuration becomes the safeguard. But this requires careful design and ongoing discipline, not a casual assumption that the data does not really count.
If the vendor’s services genuinely require touching PHI and the vendor will not sign, the practice needs a different vendor. Continuing the relationship without BAA coverage is not a sustainable compliance posture, regardless of how convenient the vendor is or how long the relationship has lasted.
Healthcare-friendly alternatives exist in almost every category. They sometimes cost more. They are almost always worth it relative to the alternative.
The Annual Review
BAAs are not set-and-forget documents. Vendors get acquired. Service offerings change. Subprocessors get added or removed. A BAA executed three years ago may no longer accurately describe the data flow that actually exists today.
An annual review — verifying that each BAA is still in force, still accurate, and still appropriate to the current configuration of the vendor’s services — is one of the lowest-effort, highest-value compliance disciplines a practice can adopt. Most practices do not do this. The ones that do find issues every year, address them promptly, and avoid the larger problems that accumulate from years of unreviewed agreements.
