Who’s legally liable when your software vendor touches PHI?


The call that changes everything

It’s 2:17 AM on a Saturday when your phone rings.

On the other end: your security lead, voice tight.
“One of our vendors just confirmed a breach. They’re not sure how many records. They think PHI is involved.”

Your first instinct: “Good thing we have a BAA.”

Here’s the uncomfortable truth most healthcare CTOs learn the hard way: a signed Business Associate Agreement (BAA) does not transfer HIPAA liability away from you.

It creates obligations for the vendor, yes. But when regulators come knocking, both the covered entity and the business associate can be held liable.

This post is the guide I wish I had before that call: what BAAs really do, where subprocessors fit in, and the exact questions to ask before granting any vendor access to PHI.

What a BAA actually does (and doesn’t do)

Under HIPAA, a BAA is a legally binding contract between a covered entity (provider, health plan, clearinghouse) and any vendor that creates, receives, maintains or transmits PHI on its behalf.

A proper BAA must cover, at minimum:

  • Permitted and required uses/disclosures of PHI
  • Safeguards (encryption, access controls, audit logging)
  • Breach notification timelines (often tighter than HIPAA’s 60 days)
  • Audit rights for the covered entity / HHS
  • Subcontractor flow‑down requirements
  • Return or destruction of PHI at termination

But critically: a BAA is not insurance and not a liability shield.

If your vendor mishandles PHI, regulators will ask:

  • Did you perform due diligence before sharing data?
  • Did you have a BAA in place?
  • Did you monitor and enforce it?

A hollow BAA, or one that contradicts the vendor’s standard terms, can leave you with direct HIPAA liability and limited contractual recourse.

The hidden risk: subprocessor chains

Most healthcare CTOs focus on the primary vendor.
The real exposure often lives one or two layers deeper.

Under HIPAA, any subcontractor that touches PHI on behalf of a business associate is itself a business associate and must be bound by equivalent obligations.

That means:

  • Your analytics vendor uses a cloud logging provider → that provider is a subprocessor.
  • Your AI documentation tool sends data to a third‑party LLM API → that provider is a subprocessor.
  • Your billing platform uses a redaction service and cloud storage → both are subprocessors.

If PHI flows through that chain without proper BAAs at each level, you, the covered entity, are exposed, even if your direct vendor “has a BAA”.

Recent guidance is explicit: each subprocessor that handles PHI must have a BAA with the party above it, and the primary vendor is responsible for obtaining those downstream BAAs.

Case study: the “compliant” vendor that wasn’t

Let’s make this concrete.

Context:
A mid‑size specialty clinic (“MediCare Plus”) adopts a new patient communication platform for appointment reminders, secure messaging and education content. The platform will receive patient names, contact info, appointment details and diagnosis codes – clearly PHI.

What they did right:

  • Signed a BAA with the primary vendor.
  • Verified the vendor’s SOC 2 report.
  • Enabled encryption in transit and at rest.

What they missed:

  • The vendor’s marketing site claimed “HIPAA compliant” but their standard terms allowed use of multiple third‑party analytics and AI services.
  • The BAA mentioned “subcontractors” in general terms but did not:
    • require prior approval for new subprocessors
    • list current subprocessors touching PHI
    • flow down breach notification timelines and audit rights consistently
  • Logs containing PHI were sent to a third‑party logging provider without a BAA.

The incident:

A misconfigured analytics integration exposed a dataset with patient identifiers and appointment details. The logging provider, not under a BAA, had broader access than anyone realized.

Regulatory outcome:

  • The primary vendor was found liable as a business associate.
  • MediCare Plus, the covered entity, was also cited for insufficient due diligence on subprocessors and inadequate contractual controls.
  • Fines, remediation costs and reputational damage followed – despite the “signed BAA”.

The lesson: the BAA was necessary, but not sufficient. The missing pieces were subprocessor transparency, flow‑down controls and real technical due diligence.

The CTO’s checklist: questions to ask before granting PHI access

Use this as your pre‑PHI vendor gate.

  1. Data & architecture
  • Exactly which data elements will be PHI in your system?
  • Where is PHI stored and processed (regions, cloud providers)?
  • Is PHI ever sent to third‑party APIs (e.g., LLMs, analytics, logging)?
  1. Subprocessors
  • Can you provide a current list of all subprocessors that may touch PHI?
  • Do you sign BAAs with all of them? Can we see examples or attestations?
  • What is your process for adding new subprocessors? Do we have approval rights?
  1. Contractual terms
  • Does the BAA explicitly cover all permitted uses/disclosures of PHI?
  • Are breach notification timelines defined (e.g., notify us within X days, well before your HIPAA 60‑day deadline)?
  • Do we have audit rights (direct or via third party) over your PHI handling?
  • How is PHI returned or destroyed at contract end?
  1. Security & operations
  • What encryption do you use at rest and in transit? (e.g., AES‑256, TLS 1.2+)
  • How do you control and log access to PHI?
  • How often do you test backups, incident response and disaster recovery involving PHI?
  1. Liability & risk
  • What liability caps apply to breaches involving PHI? Are they sized to the data risk?
  • Is there indemnification for HIPAA penalties and notification costs caused by your breach?
  • If your standard terms conflict with the BAA, which prevails? (It must be the BAA.)

If the vendor hesitates on subprocessor lists, audit rights or breach terms, treat that as a red flag, not a negotiation detail.

Turning BAAs from paperwork into protection

A BAA should not be a “compliance checkbox”.
For healthcare CTOs, it’s a risk management tool that forces hard conversations before PHI leaves your environment.

Practical steps:

  • Maintain a live inventory of all vendors and subprocessors that touch PHI.
  • Require subprocessor lists and change notifications as part of onboarding and renewals.
  • Align your incident response plan with vendor breach timelines in BAAs.
  • Revisit high‑risk vendors annually: AI tools, analytics, logging, communications, billing.

When done right, BAAs don’t just protect you legally, they improve your architecture, visibility and resilience.

When your software vendor touches PHI, you remain legally exposed – BAA or not.

The organizations that survive breaches with limited damage are those that:

  • Treat BAAs as living contracts, not one‑time signatures
  • Map and control the entire subprocessor chain, not just the primary vendor
  • Use the BAA negotiation to drive real security and operational improvements

Next time a vendor says “Don’t worry, we’ll sign a BAA”, the right response is:
“Great. Now show us your subprocessors, your breach terms, and how you’ll actually protect our patients’ data.”