A Business Associate Agreement (BAA) is a HIPAA-required written contract between a covered entity and a vendor that handles protected health information (PHI) on its behalf. It legally binds that vendor, the business associate, to safeguard the PHI, use it only as permitted, and report breaches. Without a signed BAA, sharing PHI with the vendor is itself a HIPAA violation.
TL;DR: the HIPAA contract for PHI vendors
- What it is: A BAA is a HIPAA-required contract binding a vendor that handles PHI to safeguard it, use it only as permitted, and report breaches.
- Who needs one: Every covered entity needs a BAA with each business associate, and the obligation flows down to any subcontractor that touches PHI.
- The website gap: Advertising and analytics vendors (Google, Meta) will not sign a BAA for tracking pixels, so PHI sent to them is uncovered and a HIPAA violation.
Short on time? See browser-layer privacy monitoring. It surfaces a pixel sending PHI to a no-BAA vendor before it becomes a reportable breach.
Covered entity vs business associate
HIPAA splits the world into two roles, and the BAA is the contract between them:
| Covered entity | Business associate | |
|---|---|---|
| Who | Health plans, clearinghouses, providers transmitting health data electronically | Any vendor creating, receiving, maintaining, or transmitting PHI for a covered entity |
| Examples | Hospitals, clinics, insurers | Cloud hosts, billing firms, analytics vendors, transcription services |
| HIPAA obligation | Full Privacy + Security Rule compliance | Safeguard PHI per the BAA and applicable rules |
| Needs a BAA with | Every business associate | Every subcontractor that touches PHI |
The chain matters: a business associate that hands PHI to its own subcontractor needs a BAA with that subcontractor too. HIPAA's obligations flow all the way down.
What a BAA must contain
HIPAA prescribes the required elements. A compliant BAA sets out the permitted and required uses of PHI, requires the business associate to implement appropriate safeguards, obligates it to report security incidents and breaches, requires it to bind its subcontractors to the same terms, and provides for the return or destruction of PHI at contract termination. It is the instrument that makes a vendor legally accountable for ePHI it would otherwise handle with no HIPAA duty at all.
The website-tracking BAA gap
Here is where BAAs collide with the modern web. A hospital can have airtight BAAs with its EHR vendor, its cloud host, and its billing company, and still be exposed, because a marketing tag on its website transmits patient data to a vendor that has no BAA and will not sign one.
Google's standard Analytics and Ads products and Meta's pixel are not offered under a BAA for this use, and their terms generally prohibit sending them PHI. So when a tracking script on a patient-facing page captures an identifier alongside health context, turning it into ePHI, and beacons it to those platforms, there is no agreement protecting it, and structurally cannot be. This is the core of the HIPAA website-tracking problem and the OCR enforcement that followed.
Closing the gap
A BAA is a legal control; it cannot stop a transmission it never covered. Closing the gap requires knowing which scripts run on health-context pages and where they send data: browser-layer privacy monitoring that surfaces a pixel sending PHI to a no-BAA vendor before it becomes a reportable breach. Teams evaluating options here often compare cside and Feroot, the two client-side monitoring vendors positioned for healthcare compliance.
The takeaway
A BAA extends HIPAA's protections to vendors you don't control, but only to the vendors who sign one. The dangerous vendors are the ones handling PHI without a BAA, and on healthcare websites those are usually the advertising and analytics scripts nobody classified as business associates in the first place.
