A HIPAA business associate agreement (BAA) is a written contract required by 45 CFR §164.502(e) and §164.504(e). Before a covered entity may disclose protected health information (PHI) to a vendor that creates, receives, maintains, or transmits it, the vendor must give “satisfactory assurances” — documented in that contract — that it will safeguard the PHI, limit its use, report breaches, and bind its own subcontractors to the same terms.
A BAA is not a certification and not a substitute for actual safeguards: since the 2013 Omnibus Rule, business associates are directly liable to OCR whether or not a BAA was ever signed.
Key takeaways
- A BAA is legally mandatory before PHI changes hands. §164.502(e)(1) requires documented “satisfactory assurances”; disclosing PHI without a required BAA is itself a HIPAA violation.
- The required terms are enumerated at §164.504(e)(2)(ii)(A)–(J) — permitted uses, safeguards, breach and security-incident reporting, subcontractor flow-down, individual-access support, and return-or-destroy at termination.
- Subcontractors are business associates too. Under §160.103 and §164.504(e)(5), the obligation flows down the entire chain, and each downstream party is directly liable to OCR.
- A signed BAA is not proof of safeguards. There is no HIPAA “certification”; OCR can penalize a business associate directly, and the required safeguards must be backed by a real risk analysis.
What is a business associate agreement, and what law requires it?
Two provisions of the HIPAA Privacy Rule work together. 45 CFR §164.502(e)(1) permits a covered entity to disclose PHI to a business associate only if it first obtains “satisfactory assurances” that the business associate will appropriately safeguard the information. §164.504(e) then requires those assurances to take the form of a written contract — the BAA — and specifies the terms that contract must contain. In other words, the BAA is the legal instrument that makes an otherwise-prohibited disclosure of PHI permissible.
The terms of art matter. Under §160.103, protected health information (PHI) is individually identifiable health information held or transmitted by a covered entity or business associate, and electronic PHI (ePHI) is the subset held or transmitted in electronic form. When ePHI is involved, the BAA also has to satisfy the Security Rule’s organizational requirements at §164.314(a), which is why cloud and SaaS BAAs read differently from a paper-records vendor’s.
Practically, the BAA is only one leg of compliance. The safeguards a BAA promises must be grounded in a documented security risk assessment feeding the safeguards a BAA requires (§164.308(a)(1)). A contract that pledges “appropriate safeguards” while the organization has never performed a risk analysis is exactly the pattern OCR flags in enforcement.
Who counts as a business associate vs. a covered entity vs. a subcontractor?
Getting these roles right is the first step, because the wrong classification cascades into missing contracts and misplaced liability. A covered entity is a health plan, healthcare clearinghouse, or a healthcare provider that transmits health information electronically. A business associate is anyone outside the covered entity’s workforce that creates, receives, maintains, or transmits PHI on its behalf. A subcontractor is a business associate’s own downstream vendor that touches that PHI — and, under §160.103, is itself a business associate.
| Role | Definition | Example | Needs a BAA with | Directly liable to OCR? |
|---|---|---|---|---|
| Covered entity | Health plan, clearinghouse, or provider transmitting health info electronically | Hospital, telehealth clinic, health insurer | Each of its business associates | Yes |
| Business associate | Creates, receives, maintains, or transmits PHI on a covered entity’s behalf | SaaS EHR vendor, medical-billing firm, cloud host storing ePHI | The covered entity above and each subcontractor below | Yes (since 2013) |
| Subcontractor (downstream BA) | A business associate’s vendor that handles that same PHI | Cloud provider under a SaaS EHR, offsite records-storage firm | The business associate above and any further subcontractors | Yes |
| Mere conduit | Transports PHI but does not access it other than transiently | ISP, postal/courier service | No BAA required | No (if truly a conduit) |
The conduit exception — and why cloud storage doesn’t qualify
The conduit exception is real but narrow. OCR limits it to entities that merely transport PHI — internet service providers, and the postal or courier services and their electronic equivalents — and that access the information only on a random or infrequent, transient basis. The moment a vendor stores ePHI persistently, it is no longer a conduit. In its Guidance on HIPAA & Cloud Computing, OCR is explicit that a cloud service provider that maintains ePHI is a business associate even when it only stores encrypted data it cannot read — the so-called “no-view” arrangement does not escape the requirement. That conclusion has not been rescinded as of mid-2026. For the architecture-level implications, see how we treat BAAs with cloud service providers like AWS and Azure.
The mandatory BAA clauses under §164.504(e)(2), one by one
Section 164.504(e)(2) sets the floor. It first requires the contract to establish the permitted and required uses and disclosures of PHI at §164.504(e)(2)(i), then enumerates the specific obligations at §164.504(e)(2)(ii)(A)–(J). How many discrete “clauses” that adds up to is editorial — what matters is that every item below appears. A BAA missing any one of them is deficient on its face.
| Required provision | CFR citation | What it obligates the BA to do | Common drafting mistake |
|---|---|---|---|
| Permitted uses & disclosures | §164.504(e)(2)(i) | Use/disclose PHI only as the contract or law permits | Open-ended “for any business purpose” language |
| No improper use | (e)(2)(ii)(A) | Not use or disclose PHI beyond the contract or as required by law | Silent on the “required by law” carve-out |
| Appropriate safeguards | (e)(2)(ii)(B) | Use safeguards, and comply with the Security Rule for ePHI | Promising safeguards with no risk analysis behind them |
| Report improper use, breaches & security incidents | (e)(2)(ii)(C) | Report unauthorized use/disclosure, breaches (§164.410) and security incidents (§164.314(a)) | Collapsing security incidents into breach reporting |
| Flow-down to subcontractors | (e)(2)(ii)(D) | Ensure subcontractors agree to the same restrictions via their own BAA | Omitting the flow-down entirely |
| Individual access | (e)(2)(ii)(E) | Make PHI in a designated record set available for individual access (§164.524) | No process for records held only by the BA |
| Amendment | (e)(2)(ii)(F) | Make PHI available for amendment (§164.526) | Ignoring amendments the BA holds exclusively |
| Accounting of disclosures | (e)(2)(ii)(G) | Provide information for an accounting of disclosures (§164.528) | No disclosure logging by the BA |
| Availability to HHS | (e)(2)(ii)(H) | Make internal practices and records available to HHS for compliance review | Confidentiality clauses that block HHS access |
| Return or destroy PHI | (e)(2)(ii)(I)–(J) | Return or destroy all PHI at termination; if infeasible, extend protections and limit further use | No return/destroy clause, or ignoring the infeasibility carve-out |
HHS publishes model language for exactly these provisions in its Sample Business Associate Agreement Provisions. Note the return-or-destroy term carries a genuine drafting nuance: §164.504(e)(2)(ii)(J) applies “if feasible,” and where return or destruction is not feasible, the BAA must extend the protections to the retained PHI and limit further uses and disclosures for as long as it is held. Do not delete that carve-out for backups and immutable logs.
Required vs. optional and negotiated terms
This is where most guides stop — and where the “liability” in this article’s title actually lives. HIPAA sets the minimum mandatory terms; it does not dictate the commercial risk allocation. HHS itself says its sample provisions are only a starting point and that a BAA may include optional terms — for example, permission for the business associate to de-identify PHI, or to use PHI for its own proper management and administration. Everything else that lawyers fight over is negotiated on top of the statutory floor.
| Term | Required by HIPAA? | Why it appears in real BAAs |
|---|---|---|
| §164.504(e)(2)(ii)(A)–(J) obligations | Yes — mandatory | The regulatory floor; a BAA without them is deficient |
| Security-incident reporting cadence/threshold | Reporting required; frequency negotiated | §164.314(a)(2)(i)(C) requires reporting; parties set the threshold and timing |
| Indemnification | No | Allocates who pays for a breach the other party caused |
| Limitation of liability / caps | No | Bounds the vendor’s financial exposure; heavily negotiated |
| Cyber-insurance requirements | No | Ensures a solvent counterparty to fund breach costs |
| Breach-cost allocation (notification, credit monitoring) | No | Assigns notification and remediation expense |
| Audit / assessment rights | No | Lets the covered entity verify safeguards (e.g., request a SOC 2 report) |
| Optional PHI de-identification / BA management use | No — permitted option | Expands what the BA may do with data if both parties agree |
Two points buyers routinely miss. First, contractual indemnification is separate from HIPAA’s statutory penalties — you can be indemnified by a vendor and still owe OCR a civil money penalty. Second, an audit-rights clause is where vendor-diligence evidence lands in practice: many covered entities satisfy it by requiring a SOC 2 report as vendor-diligence evidence alongside a BAA rather than performing an on-site audit.
The subcontractor chain: how obligations flow down
HIPAA follows the data, not the contract tier. Under the definition of “business associate” at §160.103, a subcontractor that creates, receives, maintains, or transmits PHI on behalf of a business associate is itself a business associate. Section 164.504(e)(5) then requires each business associate to obtain satisfactory assurances — its own BAA — from that subcontractor, on terms at least as protective as those it agreed to with the covered entity above it.
The chain has no floor. Consider a typical stack:
- Covered entity (a telehealth provider) → BAA with →
- Business associate (a SaaS EHR platform) → BAA with →
- Subcontractor (the cloud host storing ePHI, e.g. AWS) → BAA with →
- Further subcontractor (a managed backup or SIEM provider that touches that ePHI).
Every link needs its own BAA, and — critically — each party is directly liable to OCR for its own compliance, not merely to the party that hired it. A covered entity does not have to sign a BAA directly with the cloud host four tiers down, but it should confirm through its direct business associate that the flow-down actually happened.
Direct liability under HITECH and the 2013 Omnibus Rule
Before 2013, a business associate’s HIPAA exposure was almost entirely contractual — it answered to the covered entity, not the government. The HITECH Act (2009) changed that, and the HIPAA Omnibus Final Rule (78 Fed. Reg. 5566, Jan. 25, 2013; compliance date Sept. 23, 2013) implemented it. Today, business associates and their subcontractors are directly liable to the HHS Office for Civil Rights (OCR) for the Security Rule and for specified Privacy Rule provisions (see 42 U.S.C. §§17931, 17934). The consequence buyers most often overlook: OCR can pursue a business associate even where no BAA was ever signed — the missing contract is a separate violation, not a shield.
Civil money penalties (CMPs) are tiered by culpability under 45 CFR §160.404 and are adjusted for inflation annually. The figures below reflect the HHS adjustment effective January 28, 2026.
| Culpability tier | Minimum per violation | Maximum per violation | Annual cap per identical provision |
|---|---|---|---|
| Tier 1 — No knowledge | $145 | $71,162 | $2,190,294 † |
| Tier 2 — Reasonable cause | $1,424 | $71,162 | $2,190,294 † |
| Tier 3 — Willful neglect, corrected | $14,232 | $71,162 | $2,190,294 † |
| Tier 4 — Willful neglect, not corrected | $71,162 | $2,190,294 | $2,190,294 |
† The Federal Register inflation table lists a single statutory annual cap of $2,190,294 across all tiers. Under HHS’s 2019 Notification of Enforcement Discretion (84 Fed. Reg. 18151, Apr. 30, 2019), OCR applies lower annual caps to Tiers 1–3 as a matter of enforcement discretion pending future rulemaking — so the regulation shows one number while OCR’s practice may be more lenient for the lower tiers. Always confirm the current-year figures against the latest Federal Register adjustment (2026 amounts per FR Doc. 2026-01688). Separately, State Attorneys General may bring civil actions under HITECH §13410(e).
Real OCR enforcement for missing or deficient BAAs
Two settlements are the canonical examples, and both should be described the way OCR frames them — as resolution agreements settling potential violations, with no admission of liability. In 2016, Raleigh Orthopaedic Clinic agreed to pay $750,000 after disclosing the PHI of roughly 17,300 patients to a vendor (for X-ray film silver recovery) without first executing a BAA. In 2017, Center for Children’s Digestive Health settled for $31,000 over the absence of a BAA with a records-storage vendor (FileFax). Both cases turned on the same failure: PHI left the covered entity before the required contract was in place.
BAA vs. DPA vs. DUA vs. NDA — which instrument you actually need
These are not interchangeable, and swapping one for another is a frequent, expensive mistake. A BAA governs PHI under HIPAA. A Data Processing Agreement (DPA) governs personal data under the GDPR. A Data Use Agreement (DUA) is a narrower HIPAA instrument for limited data sets. An NDA is a confidentiality contract that satisfies none of these regulatory requirements on its own.
| Instrument | Governing law | When it’s required | What data it covers | Substitutes for a BAA? |
|---|---|---|---|---|
| BAA | HIPAA — 45 CFR §164.504(e) | Vendor handles PHI for a covered entity/BA | Full protected health information | — |
| DPA | GDPR Article 28 | Processor handles EU personal data | EU/EEA personal data | No |
| DUA | HIPAA — 45 CFR §164.514(e) | Disclosure of a limited data set for research, public health, or operations | Limited data set (specified identifiers removed) | No |
| NDA | General contract law | Any confidential business information | Any confidential data | No |
A vendor that handles both PHI and EU personal data typically needs both a BAA and a GDPR data processing agreement (Article 28). If you are mapping obligations across regimes, our guide on how a BAA compares to a GDPR Art. 28 DPA when mapping controls shows where the two overlap and where they diverge.
Breach and security-incident reporting inside a BAA
A BAA must obligate the business associate to report two distinct things, and strong agreements keep them separate. Breaches of unsecured PHI are governed by §164.410: the business associate must notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery, identifying the affected individuals. Security incidents are the broader category required by §164.314(a)(2)(i)(C) — attempted as well as successful unauthorized access — and their reporting cadence and threshold are negotiated, since reporting every unsuccessful probe is impractical.
The most commonly miscalculated deadline is when the covered entity’s own §164.404 clock starts. The answer depends on an agency test under federal common law: if the business associate is the covered entity’s agent, the CE’s 60-day clock runs from the BA’s discovery; if the business associate is an independent contractor — the default for arm’s-length SaaS and cloud vendors — the CE’s clock runs from the date the BA notifies the covered entity. Most enterprise vendor relationships are independent-contractor, so the notification date generally controls.
| Party → recipient | Obligation | Deadline | Citation |
|---|---|---|---|
| Business associate → covered entity | Report breach of unsecured PHI | Without unreasonable delay; ≤ 60 calendar days from discovery | §164.410 |
| Covered entity → affected individuals | Notify individuals of a breach | Without unreasonable delay; ≤ 60 calendar days (from discovery if BA is an agent; from notification if independent contractor) | §164.404 |
| Covered entity → HHS | Notify HHS (timing depends on breach size) | ≤ 60 days for 500+ individuals; annually for smaller breaches | §164.408 |
| Business associate → covered entity | Report security incidents (broader than breaches) | Per negotiated cadence/threshold | §164.314(a)(2)(i)(C) |
Do you need a BAA with this vendor? A decision table
The test is simple to state and easy to get wrong: does the vendor create, receive, maintain, or transmit PHI on your behalf? If yes, you need a BAA — and you cannot send it PHI until the BAA is signed. Major cloud and communications providers now self-serve a BAA; some consumer-tier services will not sign one at all, which means PHI must never flow through them.
| Vendor / example | Handles PHI? | BAA required? | Notes |
|---|---|---|---|
| AWS | Yes (if storing ePHI) | Yes | Self-serve BAA via AWS Artifact; only HIPAA-eligible services in scope |
| Google Cloud / Workspace | Yes | Yes | Customer accepts a BAA covering covered services; core Workspace supported |
| Microsoft Azure | Yes | Yes | BAA available to enterprise customers; no-view storage still requires it |
| Twilio | Yes (if PHI in messages/calls) | Yes | Offers a BAA for eligible products; enable HIPAA-compliant configuration |
| Stripe | Payment data, not typically PHI | Generally no | Stripe does not sign BAAs for standard use; do not route PHI through it |
| A penetration-testing firm | Yes (may access ePHI during testing) | Yes | A pen-test vendor that touches ePHI also needs a BAA |
| A courier / postal service | Transports only | No | Conduit exception (transient transport only) |
| An internet service provider (ISP) | Transports only | No | Conduit exception; transmission without persistent storage |
Vendor postures change, so confirm current terms before you rely on this table — but the principle is stable: persistent storage or access to PHI means a BAA, and a vendor that refuses to sign one is a vendor you cannot send PHI to.
What’s changing for business associates: the 2025 Security Rule NPRM
A significant change is on the horizon, and it is proposed, not final. On January 6, 2025, OCR published a Notice of Proposed Rulemaking to strengthen the HIPAA Security Rule; the comment period closed March 7, 2025, and finalization has been targeted for around mid-2026. Because it is an NPRM, none of it is enforceable today — but it would reshape what BAAs require, so it belongs in current diligence conversations.
Among the proposals most relevant to business associates: removing the long-standing distinction between “required” and “addressable” implementation specifications (making more safeguards mandatory), requiring business associates to provide written verification of their safeguards to covered entities, mandating an annual compliance analysis, and requiring notification to covered entities within 24 hours of activating a contingency plan. If finalized substantially as proposed, these obligations would flow directly into BAA drafting. Treat them as directional, not settled, until a final rule publishes.
How to put a compliant BAA program in place
A BAA program is an operating discipline, not a one-time signature drive. The sequence below scales from a first HIPAA vendor to a full third-party register.
- Inventory PHI-handling vendors. List every vendor that creates, receives, maintains, or transmits PHI or ePHI on your behalf, including the cloud and infrastructure providers underneath your own product.
- Confirm business associate status. For each vendor, decide whether it is a business associate, a mere conduit, or handles no PHI — the classification determines whether a BAA is required at all.
- Execute a BAA with every required clause. Sign a BAA containing all §164.504(e)(2) terms before any PHI is disclosed. Start from the HHS sample provisions and add negotiated terms (liability, insurance, audit rights) on top.
- Flow the obligations down. Require each business associate to obtain equivalent BAAs from its subcontractors, and confirm the flow-down happened rather than assuming it.
- Track renewals, terminations, and return-or-destroy. Maintain a BAA register with effective and renewal dates, re-execute on material changes, and enforce return or destruction of PHI at termination (extending protections where destruction is infeasible).
A signed BAA promises safeguards; an audit verifies they exist. That verification is where a HIPAA assessment closes the loop between contract language and operating reality.
Common BAA mistakes and how to avoid them
The first mistake is using an NDA where a BAA is required. An NDA protects confidentiality but contains none of the §164.504(e)(2) obligations, so it leaves the covered entity in violation the moment PHI is disclosed. The fix is to classify the vendor by data flow, not by the contract someone already had on the shelf.
The second is forgetting the subcontractor flow-down. Teams sign a clean BAA with a direct vendor and never confirm that the vendor’s own cloud host or backup provider is under an equivalent agreement. Because liability follows the data down the chain, that gap is a live exposure.
The third is omitting or mishandling the return-or-destroy clause — particularly the “if infeasible” carve-out in §164.504(e)(2)(ii)(J), which must extend protections to PHI that genuinely cannot be returned or destroyed (backups, immutable logs). The fourth is treating a signed BAA as proof of actual safeguards; it is a promise, not evidence, and OCR penalizes the reality, not the paperwork. The fifth is signing safeguard commitments with no security risk assessment feeding the safeguards a BAA requires (§164.308(a)(1)) behind them — the single most common root cause in OCR enforcement.
Frequently asked questions
What is a HIPAA business associate agreement (BAA)?
A BAA is a written contract required by 45 CFR §164.502(e) and §164.504(e) between a HIPAA covered entity (or business associate) and a vendor that handles protected health information. It obligates the vendor to safeguard PHI, limit its use, report breaches and security incidents, and flow the same terms down to any subcontractors that touch the data.
Who needs to sign a HIPAA BAA?
Any covered entity must sign a BAA with every business associate that creates, receives, maintains, or transmits PHI on its behalf — including SaaS vendors, cloud hosts, billing firms, and IT providers. Business associates must in turn sign BAAs with their subcontractors, so the obligation extends down the entire chain, no matter how many tiers.
What clauses are required in a HIPAA BAA?
Under 45 CFR §164.504(e)(2), a BAA must define permitted PHI uses, require appropriate safeguards and Security Rule compliance for ePHI, mandate breach and security-incident reporting, require subcontractor BAAs, make PHI available for individual access and HHS review, and require PHI return or destruction at termination (with protections extended if destruction is infeasible).
Do I need a BAA with AWS, Google Cloud, or Azure?
Yes. Under OCR’s Cloud Computing guidance, a cloud provider that stores or processes ePHI is a business associate and requires a BAA — even for encrypted, “no-view” storage it cannot read. The narrow conduit exception covers only transmission-only services like ISPs and couriers, not persistent cloud storage. AWS, Google Cloud, and Microsoft Azure all offer BAAs to eligible customers.
Are business associates directly liable under HIPAA?
Yes. Since the 2013 Omnibus Rule implementing the HITECH Act, business associates and their subcontractors are directly liable to the HHS Office for Civil Rights for HIPAA Security Rule compliance and certain Privacy Rule provisions. OCR can impose civil money penalties even when no signed BAA exists — the missing contract is itself a violation, not a defense.
What is the difference between a BAA and a DPA?
A BAA governs protected health information under US HIPAA law (45 CFR §164.504(e)); a Data Processing Agreement governs personal data under GDPR Article 28. They serve different legal regimes and are not interchangeable. A vendor handling both PHI and EU personal data typically needs both instruments, since neither one satisfies the other’s requirements.
What happens if you disclose PHI without a BAA?
Disclosing PHI to a vendor without a required BAA is itself a HIPAA violation. OCR has settled cases citing missing BAAs, including Raleigh Orthopaedic Clinic ($750,000, 2016) and Center for Children’s Digestive Health ($31,000, 2017). Civil money penalties are assessed per violation by culpability tier under 45 CFR §160.404, with amounts adjusted for inflation annually.
How fast must a business associate report a breach?
Under 45 CFR §164.410, a business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 calendar days after discovery, identifying the affected individuals. When the BA is an independent contractor — typical for SaaS vendors — the covered entity’s own 60-day clock to notify individuals runs from that notification date.
Sources & further reading
- HHS / eCFR — 45 CFR §164.504(e) — Business associate contracts (and §164.502(e), §160.103 definitions).
- HHS Office for Civil Rights — Sample Business Associate Agreement Provisions (model BAA language).
- HHS Office for Civil Rights — Guidance on HIPAA & Cloud Computing (business associate status of CSPs and no-view storage).
- Federal Register — HIPAA Omnibus Final Rule, 78 Fed. Reg. 5566 (Jan. 25, 2013), implementing the HITECH Act.
Make sure your BAAs are backed by real safeguards
A BAA promises safeguards; an audit proves they exist. Auditsuisse is a US & Swiss licensed CPA firm that runs HIPAA compliance audit services validating the technical and administrative safeguards your BAAs commit to — so the contract and the operating reality match.
Request Consultation