HIPAA Business Associate Agreement (BAA): Guide + Template

What a BAA is

A Business Associate Agreement is a written contract between a covered entity and a business associate (or between a business associate and its subcontractor) that governs how protected health information (PHI) may be used and protected. It is required by the HIPAA Privacy and Security Rules before any PHI is shared.

In essence, the BAA extends HIPAA’s obligations to the vendor by contract, ensuring that the data remains protected no matter whose systems it sits in. Without one, sharing PHI is simply not permitted.

Why BAAs exist

HIPAA recognizes that covered entities cannot do everything themselves — they rely on cloud providers, billing companies, IT firms, and many other vendors. The BAA exists to ensure that when PHI leaves the covered entity, the receiving party is contractually bound to safeguard it to the same standard.

This is how HIPAA’s protections follow the data through a complex supply chain rather than stopping at the covered entity’s walls. The BAA is the legal instrument that makes that possible.

When you need a BAA

You need a BAA whenever PHI will be created, received, maintained, or transmitted by another party on your behalf. A hospital using a cloud EHR, a clinic outsourcing billing, a health plan engaging an analytics vendor — all require BAAs. A business associate that hires a subcontractor to handle PHI must likewise sign a BAA with that subcontractor.

The trigger is the handling of PHI, not the size of the engagement. Even a small vendor that incidentally stores PHI generally needs a BAA in place before the data is shared.

What a BAA must contain

HIPAA specifies required elements for a valid BAA. It must describe the permitted and required uses and disclosures of PHI; prohibit uses or disclosures beyond what the contract or law allows; require the business associate to implement appropriate safeguards; and require it to report breaches and security incidents to the covered entity.

It must also require the business associate to ensure that subcontractors agree to the same restrictions, make PHI available for patient access and amendment, and return or destroy PHI at the end of the contract where feasible. These elements turn the agreement into an enforceable extension of HIPAA.

Permitted uses and disclosures

A core function of the BAA is to define exactly what the business associate may do with the PHI. The agreement should limit the vendor to the specific functions it was engaged to perform — hosting, processing, analytics — and prohibit any use beyond that purpose. Clear scoping protects the covered entity and keeps the vendor aligned with the minimum necessary principle.

Breach reporting obligations

The BAA must require the business associate to report breaches of unsecured PHI and security incidents to the covered entity. Well-drafted agreements specify the timing and content of these reports, so the covered entity can meet its own breach-notification deadlines. Because notification clocks are tight, the breach-reporting terms in a BAA are among its most operationally important provisions.

Subcontractor flow-down

HIPAA requires that obligations flow down the chain. A business associate that uses subcontractors to handle PHI must bind them by BAA to the same protections. This flow-down ensures that PHI remains protected even several layers removed from the original covered entity, and that no link in the chain becomes a weak point.

Common BAA mistakes

The most damaging BAA mistake is not having one at all — sharing PHI without a signed agreement is a violation regardless of whether a breach occurs. Other frequent errors include using outdated templates that predate the Omnibus Rule, failing to sign BAAs with every vendor that touches PHI, and neglecting subcontractor agreements.

Organizations also stumble by treating the BAA as a formality, signing without reading, or losing track of which BAAs are in place. Maintaining an inventory of executed BAAs is a simple but powerful safeguard against these failures.

BAA vs a standard contract

A BAA is not a substitute for a commercial contract, nor vice versa. The commercial agreement governs the business relationship — pricing, service levels, liability — while the BAA governs the handling of PHI specifically. Both are usually needed. Some vendors incorporate the BAA as an addendum to their main agreement, which is acceptable as long as all required HIPAA elements are present.

Getting a BAA signed

For covered entities, the process is to identify every vendor that will touch PHI, conduct basic due diligence on their security posture, and execute a BAA before sharing data. For vendors, it means having a ready, compliant BAA you can offer customers and the safeguards to back it up. Major cloud providers publish standard BAAs you can accept, which streamlines the process considerably.

Whoever drafts it, the agreement should be reviewed to confirm it contains all required elements and accurately reflects how PHI will actually be handled.

Using a BAA template

HHS provides sample BAA provisions, and many organizations build on these as a starting point. A template accelerates the process, but it should always be tailored to the specific relationship — the permitted uses, the breach-reporting timeline, and the return-or-destroy terms in particular. A generic template signed without review can leave gaps that surface at the worst possible moment.

Why BAAs matter

The BAA is the connective tissue of HIPAA’s ecosystem, allowing PHI to move between organizations while staying protected. For covered entities, it is essential due diligence; for vendors, it is both a legal obligation and a prerequisite to winning healthcare business. Managing BAAs carefully — signing the right ones, keeping them current, and tracking them — is one of the highest-leverage compliance activities an organization can undertake.

Who is responsible for providing the BAA

Either party can draft the BAA, and in practice it varies. Large covered entities often present their own standard BAA to vendors, while established vendors — especially cloud platforms — offer their own version that customers accept. What matters is not who drafts it but that the executed agreement contains all required HIPAA elements and accurately reflects how PHI will be handled.

When both parties have their own templates, the negotiation focuses on reconciling breach-reporting timelines, liability, and the return-or-destroy terms. Approaching this collaboratively, rather than as a battle of forms, gets the data flowing securely faster.

What happens when a contract ends

A BAA must address what happens to PHI when the relationship ends. Where feasible, the business associate must return or destroy all PHI it holds; where return or destruction is not feasible, the protections of the BAA continue to apply to that data for as long as it is retained. Defining this clearly prevents orphaned PHI from lingering unprotected in a former vendor’s systems.

Organizations should track offboarding as carefully as onboarding, confirming that departing vendors have actually returned or destroyed data and documenting that confirmation.

Liability and indemnification

While HIPAA defines the required protective terms, commercial considerations like liability caps and indemnification are negotiated between the parties. Because a breach at a business associate can expose the covered entity to notification costs and penalties, covered entities often seek indemnification for losses caused by the vendor’s noncompliance. These terms sit alongside the HIPAA-mandated provisions rather than replacing them.

Managing BAAs at scale

Organizations with many vendors can accumulate dozens or hundreds of BAAs, and managing them becomes a discipline of its own. Maintaining a central register of executed agreements — with renewal dates, scope, and the PHI involved — prevents gaps and makes audits far easier. As vendors and data flows change, this register should be reviewed so that every party touching PHI remains under a current, valid agreement.