Negotiating HIPAA Business Associate Agreements with Digital Health Vendors

Why BAAs Are Where Healthcare AI Deals Live or Die

A Business Associate Agreement is not a compliance checkbox. Under 45 CFR §§ 164.308(b), 164.502(e), and 164.504(e), a BAA is the contract that allocates liability when protected health information is mishandled — and its terms directly control who absorbs civil monetary penalties when OCR comes knocking. HIPAA mandates that the agreement exist. It does not mandate that it protect you.

That distinction matters because vendors carry independent liability under HITECH. Business associates are directly and personally exposed to OCR enforcement regardless of what any BAA says — which gives every vendor a strong financial incentive to minimize their written obligations at the negotiating table. They know exactly where the statutory floor is. The goal is to stay as close to it as possible.

The enforcement environment makes this concrete. OCR announced multiple multi-million-dollar HIPAA settlements in 2024, maintaining its aggressive enforcement posture. Those settlements don't land evenly — they track the language in the underlying agreements. Covered entities and business associates who negotiated weak BAAs found themselves holding ambiguous indemnification clauses and unenforceable breach-response timelines precisely when specificity mattered most.

What follows is a provision-by-provision map of where vendors typically push back and what you should be fighting for on each one. The statute sets the floor. Your BAA determines everything above it.

Permitted Uses and Disclosures — What Vendors Want to Do With Your Data

Under 45 CFR §164.504(e), a BAA must enumerate the specific permitted and required uses and disclosures of PHI. Any use beyond that enumerated list is unauthorized — regardless of what the commercial agreement, the vendor's privacy policy, or the master services agreement says. This is the clause vendors most aggressively draft in their own favor, because what they can do with your data commercially depends entirely on what they can get you to agree to in writing here.

The core problem is that business associates have no HIPAA authority to use PHI for product development or AI model training. HIPAA permits a BA to use PHI for its own purposes only in two narrow exceptions: data aggregation to support covered entity healthcare operations, and the BA's proper management and administration. Neither encompasses training a commercial AI model. There is no HHS guidance that stretches these exceptions to cover product improvement or building generalized clinical AI — and vendors know this, which is why they draft permitted-use clauses with language like "service improvement," "anonymized analytics," or "aggregate insights" without defining what those terms actually mean operationally.

"We de-identified it" is not a complete answer. Proper HIPAA de-identification requires either removal of all 18 specified Safe Harbor identifiers or a qualified expert's statistical determination under 45 CFR §164.514. AI systems routinely use quasi-identifiers — combinations of age, diagnosis, geography, and clinical features — that survive standard de-identification but remain vulnerable to re-identification by the same ML techniques that trained on them in the first place. The Safe Harbor standard was not designed with modern inference attacks in mind.

This is an evolving enforcement area, and OCR has not yet issued definitive AI-specific guidance on where the line falls. That uncertainty cuts both ways: it gives vendors room to argue, but it gives you equal room to demand clarity in the contract. Specific language to flag in vendor drafts includes any permitted use that references "product improvement," "model training," "de-identified derivatives," or "aggregate benchmarking" without a contractual definition. Push back with language that limits permitted uses to services performed directly on behalf of your covered entity and requires written notice and your approval before any secondary use of PHI or purported de-identified data.

Subcontractor Chains and Downstream BAAs

In 2023, OCR settled with MedEvolve — a billing and practice management vendor — for $350,000 after finding that MedEvolve had granted a subcontractor access to PHI without executing a BAA with that subcontractor. MedEvolve had a BAA with its covered entity client. That wasn't enough. The missing link one level down was the violation, and OCR pursued it directly against the BA, not the covered entity.

The legal mechanism behind that case matters for how you negotiate. Under 45 CFR §§ 164.308(b)(2) and 164.314(a), business associates must execute BAAs with every subcontractor that creates, receives, maintains, or transmits PHI on the BA's behalf. Since the 2013 Omnibus Rule, subcontractors carry direct liability for Security Rule violations and certain Privacy Rule requirements — so a subcontractor operating without a compliant BAA creates independent regulatory exposure, not just a contractual gap the BA can patch after the fact.

Change Healthcare set the scale. The 2024 breach — described as the largest healthcare data breach in U.S. history — prompted OCR to open a broad HIPAA compliance investigation into whether the company's vendor relationships met regulatory standards. OCR's response confirmed that downstream vendor oversight is a core compliance obligation, not an administrative formality.

What this requires in your BAA negotiations is concrete and non-negotiable. Vendors will push back on all three of the following demands — push back harder:

• Subcontractor disclosure: The vendor must provide a current list of all subcontractors that access PHI, updated on request.
• Pre-engagement notice: The vendor must notify you before engaging any new subcontractor that will touch PHI, with enough lead time for you to object.
• Flow-down equivalence: The vendor's BAA with each subcontractor must contain substantially the same protections as your primary BAA — vendors cannot use thinner contracts downstream to dilute obligations they've accepted upstream.

A BAA that omits these terms leaves your subcontractor chain invisible to you and legally unanchored — exactly the conditions OCR found in MedEvolve, and exactly the conditions that produced the largest healthcare breach on record.

Breach Notification Windows — The 60-Day Problem and What to Negotiate

Under 45 CFR §164.410, a business associate must notify the covered entity of a breach without unreasonable delay and no later than 60 calendar days after discovery. That clock starts running on the day the BA discovers the breach — not the day it tells you about it. A vendor who sits on a breach for 45 days and then notifies you has consumed 75% of the shared compliance window before you knew anything was wrong.

The regulation defines discovery as the first day the breach is known, or would have been known through reasonable diligence — which means vendor-side delays in internal escalation do not pause or reset the clock. Slow triage procedures inside the BA's incident response team are the BA's problem legally, but they become your problem operationally. Your obligation to notify affected individuals and HHS also runs from that same discovery date, capped at the same 60 days. If a vendor notifies you on day 52, you have eight days to identify every affected individual, draft the notice, and file with HHS — an operational impossibility in any breach affecting more than a handful of records.

Vendors will argue they cannot notify until their forensic investigation is complete. That argument has no regulatory basis. HHS has long permitted a business associate to provide an incomplete initial breach notice and supplement it as investigation progresses. The BA is not required to have every detail before picking up the phone. The "we need to finish the investigation first" position is a stall tactic, not a compliance requirement.

Audit Rights and Security Assessment Provisions

HIPAA does not require your vendor to let you audit them. There is no provision in the statute or implementing regulations that gives a covered entity the right to inspect a business associate's security controls on demand. That right exists only if you negotiated it into the BAA — and most standard vendor templates omit it entirely.

Vendors resist audit provisions for two straightforward reasons: audits are expensive to facilitate, and a formal security assessment creates documented evidence of vulnerabilities that could surface in litigation or regulatory proceedings. The path of least resistance for a vendor's legal team is a BAA that says nothing about audit access at all.

But for covered entities, silence on audit rights is not a neutral choice. Your HIPAA risk analysis must account for the security posture of every vendor touching your PHI — which means you need a mechanism to actually verify that posture. A BAA that grants no audit rights leaves your own Security Rule compliance on shakier ground than most compliance teams realize. The proposed 2025 HIPAA Security Rule amendments reinforce this direction: they would require business associates to verify their subcontractors' safeguards at least annually, making some form of vendor security verification a regulatory expectation rather than a negotiating luxury.

The specific documentation package to require is not ambiguous. Demand, in writing, annual delivery of:

• A SOC 2 Type II report covering the prior 12-month period
• A HIPAA Security Rule assessment conducted by a qualified third party
• A penetration testing summary (executive summary is acceptable if the vendor won't share the full report)

If a vendor refuses to commit to annual delivery of these documents, treat that refusal as a substantive risk finding, not a negotiating position.

Termination and Return or Destruction of PHI

Every BAA negotiation focuses heavily on what happens during the vendor relationship. The provisions governing what happens after it ends receive far less attention — and vendors know it. Under 45 CFR § 164.504(e)(2)(ii)(J), a business associate agreement must require the vendor to return or destroy all PHI upon termination "where feasible." Where destruction is not feasible, the BAA's obligations must extend to any PHI the vendor retains. That is the regulatory floor — but it leaves two critical gaps: no timeline, and no definition of "feasible."

HIPAA sets no fixed deadline for PHI return or destruction. That silence is a negotiation variable vendors will fill in their own favor. Left to their own drafting, vendors insert language like "within a commercially reasonable time" or "as soon as practicable" — formulations that impose no real obligation. The BAA must specify the timeline explicitly: a hard deadline from the termination effective date, typically 30 to 60 days, with a written confirmation obligation that the return or destruction has been completed.

The more aggressive vendor tactic is the "technically infeasible" defense. Vendors routinely claim that backup systems, immutable archives, and multi-tenant cloud infrastructure make selective deletion impossible — and that HIPAA's "where feasible" carve-out therefore excuses them from any further obligation. This claim has some technical validity in narrow circumstances, but it is not a license to retain PHI indefinitely. HHS's cloud computing guidance confirms that a cloud service provider acting as a business associate remains subject to BAA obligations and HIPAA requirements for any ePHI it retains after contract termination, regardless of whether it can actually access encrypted data. When a vendor invokes infeasibility, the regulatory response is not exemption — it is a heightened set of controls: isolated storage, access restricted to named custodians, use of the retained data limited to the purpose that makes deletion infeasible, and a documented scheduled destruction date.

The practical remedy is a deletion certification requirement built into the BAA's termination clause. A well-structured deletion certification specifies scope — the data sets, date ranges, media types, and volumes covered — destruction method by medium type, and evidence of completion, including logs, ticket references, and hash manifests where applicable. It must also document any exceptions: what data is being retained, the legal basis for retention, who the named custodians are, and when the earliest feasible destruction date is. Critically, the certification obligation must extend to subcontractors. A certification from the primary vendor that leaves downstream processors unaccounted for closes the front door while leaving the back door open.

Actionable Next Steps

BAA negotiation outcomes are determined before the first call with a vendor — by who controls the paper and who has mapped their non-negotiables in advance. The steps below apply whether you are the covered entity demanding protections or the business associate building a BAA program that can survive due diligence.

1. Start with your own redline, not the vendor's draft. A vendor's standard BAA is written to satisfy the regulatory floor while minimizing vendor exposure. Covered entities that sign vendor paper without markup are not just accepting unfavorable terms — they are accepting a compliance risk, because the adequacy of BAA terms, not merely their existence, is what regulators evaluate.
2. Lock in an explicit AI training prohibition. Permitted use scope is the highest-leverage provision in any BAA involving a digital health vendor. Define permitted uses narrowly and include a standalone prohibition on using PHI to train, fine-tune, or improve AI or machine learning models — as a named carve-out, not buried in a general restriction.
3. Require a disclosed subcontractor list with advance notice of changes. Every subcontractor is a gap in your visibility over PHI. Require the vendor to disclose all current subcontractors that touch PHI and to provide written notice — with a meaningful window, not 24 hours — before onboarding a new one.
4. Set a tiered breach notification deadline with rolling updates. HIPAA's 60-day outer limit is a ceiling, not a target. Negotiate an initial notification of a potential breach within 72 hours, require full written notice within 14 days of discovery regardless of whether the investigation is complete, and require rolling updates as details develop. Specify the form and required content of each notice.
5. Require annual SOC 2 Type II delivery. Audit rights you never exercise are meaningless. Build in an obligation for the vendor to deliver its most recent SOC 2 Type II report — or an equivalent third-party attestation — annually, not just upon request.
6. Specify a PHI destruction timeline and require written certification. Data termination provisions without enforcement mechanics are aspirational at best. Set a concrete deletion deadline following contract end, and require the vendor to deliver written certification that destruction is complete, including any PHI held by subcontractors.
7. Anticipate the 2025 HIPAA Security Rule NPRM now. The proposed Security Rule amendments — the most significant since 2003 — would require business associates to verify subcontractor security safeguards on an annual basis, with no distinction between "required" and "addressable" specifications. BAAs executed today should build in annual subcontractor verification requirements rather than waiting for the final rule to force a renegotiation.

If any of these provisions are contested in negotiation, that friction is diagnostic — and health regulatory counsel should be involved before you sign.