Skip to main content
Digital Compliance Bureau
Dark green background, "Weak Application Security Can Cost You Millions," 3 slanted images of fingers pointing to digital locks, and a "Learn the Basics" button
Category: Third-Party & Vendor

Business Associate Agreement (BAA)

Also known as: BAA, Business Associate Contract, HIPAA Business Associate Agreement
Simply put

A Business Associate Agreement (BAA) is a written contract between a HIPAA-covered organization (a 'covered entity') and a business associate—a vendor or partner that handles protected health information (PHI) on the covered entity's behalf. It sets out each side's responsibilities for safeguarding that health information. It is generally required whenever a covered entity shares PHI with a business associate.

Formal definition

A BAA is a contractual instrument required under the U.S. Health Insurance Portability and Accountability Act (HIPAA) framework that governs the relationship between a covered entity (or, in some cases, another covered entity) and a business associate that creates, receives, maintains, or transmits protected health information (PHI) on the covered entity's behalf. The agreement allocates responsibilities for permitted uses and disclosures of PHI and related safeguards. It is distinct from HIPAA itself: HIPAA is the binding federal law, while the BAA is the contract used to satisfy certain of its obligations. Notably, a business associate is directly liable under the HIPAA Rules and may be subject to civil and, in some cases, criminal penalties for impermissible uses or disclosures, independent of the contract terms. This entry addresses the U.S. HIPAA context only and does not cover analogous arrangements in other jurisdictions; specific required provisions, applicability, and enforcement should be verified against the current official HHS text.

Why it matters

The BAA is the mechanism through which HIPAA's protections extend beyond the covered entity itself to the wider ecosystem of vendors and partners that touch protected health information (PHI). Modern healthcare operations rely heavily on third parties—cloud hosting providers, billing companies, analytics vendors, and IT service firms—many of which create, receive, maintain, or transmit PHI. Without a BAA in place, a covered entity that shares PHI with such a party generally falls short of HIPAA's requirements, and the arrangement itself may constitute an impermissible disclosure.

Critically, the BAA is not merely a paperwork formality that shifts all risk onto the vendor. Under the HIPAA Rules, a business associate is directly liable and may be subject to civil and, in some cases, criminal penalties for impermissible uses or disclosures of PHI—independent of what the contract itself says. This means both parties carry regulatory exposure. A covered entity cannot fully contract away its obligations, and a business associate cannot rely on the absence or weakness of a BAA to escape statutory liability for its own conduct.

Because the BAA defines each side's safeguarding responsibilities and permitted uses and disclosures, its presence, scope, and accuracy are routinely examined in HIPAA compliance reviews and in the aftermath of data breaches involving vendors. Organizations should treat the BAA as a live compliance control rather than a one-time signature, and should verify required provisions against the current official HHS text, as guidance and interpretation evolve over time.

Who it's relevant to

Covered entities (healthcare providers, health plans, clearinghouses)
Organizations subject to HIPAA that intend to share PHI with vendors or partners generally must have a BAA in place before disclosure. They are responsible for ensuring the agreement addresses permitted uses, disclosures, and safeguards, but should understand that executing a BAA does not eliminate their own HIPAA obligations.
Business associates and their subcontractors
Vendors and partners that create, receive, maintain, or transmit PHI on a covered entity's behalf are bound by the BAA and are also directly liable under the HIPAA Rules. They may face civil and, in some cases, criminal penalties for impermissible uses or disclosures, independent of the contract's terms, and should not treat the agreement as their only source of obligation.
Compliance officers and privacy professionals
Those responsible for HIPAA compliance programs use BAAs as a control for managing third-party PHI risk. They should track which relationships require a BAA, verify that provisions align with the current official HHS text, and treat the agreements as living documents subject to review as regulations and vendor relationships change.
Legal counsel and contract managers
Attorneys and contracting teams draft, negotiate, and maintain BAAs. They can reference HHS sample provisions and the model agreement as a starting point, while tailoring terms to the specific PHI and services at issue and confirming applicability against current authoritative sources.

Inside BAA

Permitted Uses and Disclosures
Provisions specifying how the business associate may use or disclose protected health information (PHI), generally limited to the purposes necessary to perform the services described in the underlying service arrangement and as permitted or required by the HIPAA Privacy Rule.
Safeguards Obligation
A commitment by the business associate to implement appropriate administrative, physical, and technical safeguards to protect PHI, reflecting requirements associated with the HIPAA Security Rule for electronic PHI. The specific controls generally depend on the nature of the services and a risk assessment.
Subcontractor Flow-Down
Terms requiring the business associate to ensure that any subcontractors that create, receive, maintain, or transmit PHI on its behalf agree to substantially similar restrictions and conditions, typically through subcontractor business associate agreements.
Breach and Incident Reporting
Provisions obligating the business associate to report to the covered entity (or upstream business associate) security incidents and breaches involving PHI, generally within timeframes and in a manner specified by the agreement and applicable HIPAA breach notification requirements.
Individual Rights Support
Terms addressing the business associate's role in helping the covered entity meet obligations regarding individual rights, such as access to and amendment of PHI and accounting of disclosures, to the extent the business associate holds relevant information.
Return or Destruction on Termination
Provisions requiring the business associate, upon termination of the agreement, to return or destroy PHI where feasible, and to extend protections to any PHI retained where return or destruction is not feasible.
Termination for Breach of Terms
Language permitting the covered entity to terminate the arrangement if the business associate materially breaches the agreement, subject to any cure provisions the parties negotiate.

Common questions

Answers to the questions practitioners most commonly ask about BAA.

Does signing a Business Associate Agreement guarantee that a vendor is HIPAA compliant?
No. A BAA is a contractual instrument that establishes the obligations and permitted uses of protected health information (PHI) between a covered entity or business associate and the party acting on its behalf. It does not, by itself, demonstrate that the vendor has actually implemented compliant safeguards or maintains ongoing compliance with the HIPAA Privacy, Security, and Breach Notification Rules. The agreement allocates responsibilities and liability; verifying that those responsibilities are met generally requires separate due diligence, such as reviewing the vendor's security practices, assessments, or attestations. Compliance is an operational state, while a BAA is a legal precondition for permitting the disclosure of PHI to a business associate.
Is a BAA the same as a certification or an audit report showing a vendor meets HIPAA requirements?
No. A BAA is a contract, not a certification or an assessment. HIPAA does not establish a government-issued certification scheme, and no signed agreement functions as proof that an independent party has evaluated the vendor's controls. Third-party attestations, audits, or assessments (which are voluntary or contractual in nature) are distinct from the BAA itself. A covered entity should not treat the existence of a BAA as equivalent to evidence produced through an audit or assessment; the two serve different purposes and should be evaluated separately.
When is a Business Associate Agreement required, and when is it not?
Under HIPAA, which is a United States federal regulation applicable to covered entities and their business associates, a BAA is generally required when a person or entity creates, receives, maintains, or transmits PHI to perform a function or service on behalf of a covered entity. It is generally not required for parties who do not handle PHI, or for those who fall under recognized exceptions, such as certain conduit arrangements where an entity only transports data without routine access to it. Whether a given relationship triggers the requirement is fact-specific and depends on the nature of the service and the party's access to PHI. Readers should verify the current regulatory text and applicable guidance, as interpretations of borderline cases continue to evolve.
What obligations does a BAA typically need to address?
A BAA generally addresses the permitted and required uses and disclosures of PHI, the requirement that the business associate implement appropriate safeguards, obligations to report security incidents and breaches to the covered entity, terms governing subcontractors who handle PHI, and provisions for the return or destruction of PHI at the end of the arrangement. The precise required elements are defined in the applicable HIPAA rules, and the specific wording and additional negotiated terms vary by relationship. Because the regulatory requirements may be amended over time, the content of a BAA should be reviewed against the current authoritative text rather than assumed to be static.
How should the relationship with subcontractors be handled under a BAA?
Where a business associate engages a subcontractor that creates, receives, maintains, or transmits PHI on its behalf, HIPAA generally requires that satisfactory assurances be obtained through a written agreement that flows down comparable obligations. This means the chain of accountability extends beyond the direct relationship between the covered entity and the business associate. Organizations should map where PHI travels within their vendor chain and ensure that agreements exist at each tier where PHI is handled. The specific requirements applicable to subcontractor arrangements should be confirmed against the current regulatory text.
What steps are commonly taken when a BAA arrangement ends?
At termination, a BAA typically addresses the return or destruction of PHI held by the business associate, and where return or destruction is not feasible, it commonly provides that protections continue for as long as the PHI is retained. In practice, organizations often document how PHI was disposed of or returned, and confirm that subcontractors have done the same. Because implementation details and feasibility vary by arrangement and by the systems involved, the applicable termination provisions and their execution should be reviewed on a case-by-case basis. Application to a specific situation requires professional judgment.

Common misconceptions

A BAA is a voluntary contract that organizations may choose to sign as a best practice.
A BAA is a contractual instrument required under HIPAA when a covered entity or business associate engages another party to handle PHI on its behalf. While the document itself is a contract, entering into it in these circumstances is a legal obligation under U.S. federal law, not merely a discretionary measure. The precise triggering conditions are fact-specific, and readers should verify against the current regulatory text.
Signing a BAA means the business associate is 'HIPAA certified' or independently verified as compliant.
A BAA is a contract that allocates responsibilities and obligations between the parties; it is not a certification. HIPAA does not establish a government-issued compliance certification, and executing a BAA does not by itself demonstrate that either party has implemented adequate safeguards. Actual compliance depends on the controls and practices the parties maintain.
Once a BAA is signed, the covered entity transfers its compliance responsibility to the business associate.
A BAA allocates specific obligations but does not eliminate the covered entity's own responsibilities. Business associates may also bear direct liability under HIPAA for certain requirements. The distribution of obligations depends on the parties' respective roles and the terms negotiated, and does not amount to a wholesale transfer of accountability.

Best practices

Confirm whether a BAA is actually required by assessing whether the other party will create, receive, maintain, or transmit PHI on your behalf, and document that determination.
Ensure subcontractor flow-down provisions are in place so that any downstream parties handling PHI are bound by substantially similar obligations through their own agreements.
Define breach and security incident reporting expectations clearly, including notification content and timeframes, rather than relying on generic language.
Address return or destruction of PHI at termination, and specify how retained PHI will remain protected where return or destruction is not feasible.
Align the BAA's safeguards commitments with the outcome of a current risk assessment appropriate to the specific services and the type of PHI involved.
Review and update BAAs periodically, and verify terms against the latest authoritative HIPAA regulatory text, since requirements and enforcement practice can change over time.
Digital advertisement promoting the whitepaper “The State of Application Security in Modern Software,” showing the cover f the whitepaper and text highlighting AppSec risks, AI code threats, API vulnerabilities, and a button to download the whitepaper.