BAAs Explained: When You Need One and What It Covers

The contract that makes HIPAA work in a supply chain

HIPAA does not just regulate hospitals and insurers (the covered entities). It reaches everyone they hand protected health information to — and everyone those vendors hand it to. The legal instrument that carries the obligations down the chain is the Business Associate Agreement, or BAA. If you build software that touches PHI on behalf of a healthcare customer, you are almost certainly a business associate, and you need to understand this contract.

Who is a business associate?

A business associate is any person or entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity to perform a function or service. That is broad. It includes:

• A SaaS product that stores patient records for a clinic.
• A cloud provider hosting infrastructure where PHI lives.
• An analytics, logging, or email vendor that processes PHI.
• A billing or claims-processing service.

A useful test: do you handle PHI as part of delivering a service to a covered entity (or to another business associate)? If yes, you are a business associate, whether or not anyone has sent you a contract yet. Note the "conduit" nuance — a pure transmission service that never accesses the data, like some postal or dumb-pipe telecom, may be exempt, but this exception is narrow and does not cover cloud vendors that store data, even encrypted.

What a BAA actually obligates

A BAA is not boilerplate to sign and forget. Signing one means you contractually agree to, among other things:

• Use and disclose PHI only as permitted by the agreement or as required by law — nothing more.
• Implement safeguards. Business associates are directly subject to the HIPAA Security Rule. The technical safeguards (access control, audit controls, integrity, transmission security, encryption) are your legal responsibility, not just your customer's.
• Report breaches and security incidents to the covered entity, within defined timelines.
• Ensure subcontractors comply (more on this below).
• Make PHI available for access, amendment, and accounting-of-disclosures requests.
• Return or destroy PHI at contract termination where feasible.

Crucially, since the HITECH Act, business associates have direct liability under HIPAA. Regulators can penalize you directly, not only your customer. The BAA is not just risk transfer from the covered entity — it documents obligations you are independently on the hook for.

Subcontractor flow-down

Here is the part engineers underestimate. If you are a business associate and you pass PHI to your vendors — your cloud host, your managed database, your email sender — those vendors become your business associates, and you must have a BAA with each of them. The obligations flow down the entire chain. A gap anywhere breaks it.

Practically: before you route PHI through any third-party service, confirm that vendor will sign a BAA. Major cloud providers offer them, but often only for a specific subset of their services, and sometimes only after you explicitly opt in. Sending PHI to a service you don't have a BAA with is itself a violation, even if nothing leaks.

Tracking the ones you have

BAAs are living obligations, and this is where compliance quietly fails. Common gaps:

• Missing BAAs for a vendor that started handling PHI after the initial vendor review.
• Expired or superseded agreements nobody renewed.
• Untracked subcontractors — a vendor swapped their sub-processor and never told you.

Maintain an inventory: every vendor that touches PHI, whether a signed BAA exists, its effective and expiration dates, and which services it covers. Review it on a schedule, and re-check whenever you add a data-handling vendor. This is exactly the kind of drift a compliance program should surface automatically rather than discover during an incident. Tools like KollGuard can help keep a vendor-and-agreement inventory visible alongside your technical posture, so a lapsed BAA is a flagged item, not a surprise in a breach investigation.