If your company touches Protected Health Information on behalf of a healthcare client — hosting it, processing it, even just having technical access to it — HIPAA requires a signed Business Associate Agreement before that relationship can legally exist. This isn’t a best practice or a nice-to-have. It’s a legal requirement, and it’s one of the first things a healthcare buyer’s procurement team checks before signing anything.
What a BAA actually is
A Business Associate Agreement is a legally binding contract between a covered entity (a healthcare provider, insurer, or clearinghouse) and a business associate (any vendor handling PHI on that covered entity’s behalf) that spells out how PHI will be protected, used, and reported on if something goes wrong. It’s required under HIPAA’s Privacy Rule whenever PHI changes hands between these two parties, and it exists specifically because HIPAA’s enforcement reach follows the data, not just the original covered entity.
Who counts as a business associate
The definition is broader than most non-healthcare vendors expect. A software company hosting patient records is a business associate. A cloud provider storing backups that include PHI is one too, even if no one at that company ever looks at the data directly. A billing service, a transcription vendor, an analytics platform, even a law firm reviewing records for litigation — all are business associates if PHI passes through their hands as part of the relationship. The test isn’t whether you intend to use the data; it’s whether you have access to it at all.
What happens without one
Operating without a required BAA isn’t a paperwork gap — it’s a HIPAA violation in its own right, independent of whether any actual breach occurs. For the covered entity, it means they’ve failed to obtain “satisfactory assurances” that their vendor will protect PHI, which is itself a compliance failure they’re accountable for. For the vendor, once they’ve received PHI, they’re bound by HIPAA’s business associate obligations whether or not a BAA was ever signed — the agreement doesn’t create the obligation, it documents that both parties acknowledged it. In practice, this is exactly why healthcare buyers ask about BAA availability before signing anything: it’s not a formality, it’s the artifact that proves the vendor understands what they’re taking on.
What a BAA needs to include
At minimum, a compliant BAA describes the permitted uses of PHI, requires the business associate to implement appropriate safeguards, obligates the business associate to report any breach or unauthorized use, and requires that PHI be returned or destroyed at the end of the relationship. It also has to extend the same requirements to any subcontractor the business associate brings in — the obligation follows the data through every hand it passes through, not just the first one.
The practical takeaway
If your company is being evaluated by a healthcare buyer, having a BAA ready to sign — and being able to show exactly what technical safeguards back it up — is often the difference between moving forward and stalling at procurement. It’s worth treating BAA readiness as a sales asset, not a legal afterthought.
FAQ
- Do we need a BAA if we only have indirect access to PHI? Yes. Access, not intent to use, is what triggers the requirement.
- Can a BAA be a generic template? It needs to cover the required elements, but generic templates often miss subcontractor flow-down language — worth a legal review rather than a pure copy-paste.
- What happens if a vendor won’t sign one? That vendor relationship can’t legally proceed if PHI is involved — this is one of the most common deal-blockers in healthcare procurement.