Why Your BAA Template Is Probably Not Enough

You downloaded a BAA template. Maybe from a compliance blog, maybe from your law school classmate, maybe from a SaaS tool that promised "HIPAA-ready docs in minutes." You filled in the blanks, both parties signed it, and you moved on.

That BAA is almost certainly not protecting you.

I've reviewed hundreds of Business Associate Agreements for health tech companies. The template versions consistently miss the same critical provisions — provisions that determine whether your BAA actually shields you in a breach investigation, an audit, or a lawsuit. (For a broader look at common compliance pitfalls, see What Health Tech Founders Get Wrong About HIPAA Before Launch.)

Here are the six gaps I see most often, and exactly how to fix each one.

1. No AI Usage Provisions

This is the biggest blind spot in 2026. Your health tech product likely uses AI — whether it's OpenAI's API for clinical documentation, a machine learning model for diagnostics, or an NLP engine for patient intake.

Template BAAs were written before AI became embedded in health tech stacks. They don't address:

• Whether your vendor can use PHI to train AI models. If your AI provider is ingesting patient data to improve their algorithms, that's a HIPAA violation unless explicitly authorized in the BAA.
• Who owns AI-generated outputs. If an AI processes a patient's speech sample and generates a clinical assessment, who owns that output? What happens to it?
• Third-party AI subprocessors. Your vendor might use a different AI provider under the hood. Your BAA needs to flow down to every layer.

2. The Subcontractor Chain Is Missing

HIPAA's Omnibus Rule (2013) requires your Business Associate to ensure that any subcontractor handling PHI also signs a BAA. This creates a chain of accountability. See 45 CFR § 164.502(e)(1)(ii) and § 164.314(a)(2)(i) — the HIPAA Omnibus Rule requires Business Associates to obtain satisfactory assurances from subcontractors.

Template BAAs often include a generic line about subcontractors. But they rarely require:

• Written notification before engaging new subcontractors
• Your right to approve or reject subcontractors
• Flow-down of the same security obligations to every level
• Direct liability if a subcontractor causes a breach

In practice, your BAA might be with a health tech vendor who subcontracts data processing to a cloud provider, who uses a third-party analytics tool, who sends data to an AI API. If any link in that chain fails, you bear the liability as the covered entity or upstream Business Associate.

3. Cloud Provider BAAs Have Hidden Conditions

AWS, Google Cloud, and Microsoft Azure all offer BAAs. Health tech founders often treat these as comprehensive coverage. They're not.

Each major cloud provider's BAA contains conditional compliance clauses that most founders don't read:

• AWS: Their BAA requires you to properly configure encryption, audit logging, and access controls. If you misconfigure, the BAA's protections may not apply.
• Microsoft: Their BAA includes a clause excusing Microsoft from responding to patients' access requests. That responsibility falls entirely on you.
• Google Cloud: Their BAA covers only HIPAA-eligible services. If you use a Google service that isn't on their eligible list, PHI on that service isn't covered.

4. Breach Notification Terms Are Too Vague

HIPAA requires notification to affected individuals within 60 days of discovering a breach. But your BAA needs to define when your vendor must notify you — because the 60-day clock starts when you become aware, not when the breach occurs.

Template BAAs often say the Business Associate must notify you "promptly" or "without unreasonable delay." These terms are meaningless in an enforcement action. Under 45 CFR § 164.410, a Business Associate must notify the Covered Entity without unreasonable delay and no later than 60 days from discovery.

5. Termination and Data Return Are Afterthoughts

What happens to PHI when you end a vendor relationship? Template BAAs typically include a generic "return or destroy" clause. But they rarely address:

• Timeline: How quickly must the vendor return or destroy PHI? 30 days? 90 days? Templates often don't specify.
• Certification: Who certifies that destruction actually happened? A template might say "destroy" but never require written certification.
• Backups: PHI often lives in backup systems, disaster recovery environments, and archived logs. The BAA needs to cover these explicitly.
• AI models: If your vendor used PHI to train an AI model, is that model now "contaminated"? Can they continue using a model that was trained on your patients' data? Your BAA should address this.

6. No Audit Rights

You have a BAA with a vendor. They say they're HIPAA compliant. How do you verify? Template BAAs rarely give you the right to audit your vendor's security practices, policies, or infrastructure.

Without audit rights, you're taking your vendor at their word. In an OCR investigation, "we trusted our vendor" is not a defense. While HIPAA doesn't explicitly mandate audit rights, 45 CFR § 164.314(a)(2)(i)(C) requires that BAAs authorize termination if the Covered Entity determines the Business Associate has violated material terms.

Sample BAA Language for AI Provisions

"Business Associate shall not use, disclose, or permit any subcontractor or AI system to use Protected Health Information for the purpose of training, developing, improving, or fine-tuning any artificial intelligence model, machine learning algorithm, or automated decision-making system, unless Covered Entity provides prior written authorization specifying the permitted use, scope, and duration. Any AI-generated outputs derived from PHI shall be treated as PHI and subject to all protections under this Agreement."

Note: This is sample language for reference only. Your BAA should be drafted by qualified counsel to reflect your specific data flows, vendor relationships, and regulatory requirements.

The Cost of Getting This Wrong

A BAA isn't just a compliance checkbox. It's a liability allocation document. When a breach happens — and in health tech, the question is when, not if — your BAA determines who pays, who notifies, who investigates, and who faces enforcement.

A template BAA with generic terms gives you the illusion of protection. A properly drafted BAA gives you actual protection — and the documentation trail that OCR expects to see.

The difference between the two is usually a few hours of attorney time. The difference in a breach scenario is potentially millions of dollars.

Frequently Asked Questions

Is a BAA template from the internet legally sufficient?

Almost never for health tech companies. Templates miss AI provisions, subcontractor chains, cloud-specific conditions, and modern breach notification requirements. They provide a starting point but require significant customization.

Do I need a BAA with every SaaS tool my team uses?

If the tool can access, store, process, or transmit PHI — yes. This includes your CRM, analytics, email service, customer support platform, and any AI API. If it can touch PHI, it needs a BAA.

What happens if my vendor refuses to sign a BAA?

You cannot use that vendor for any function involving PHI. Find an alternative vendor that offers a BAA, or restructure your data flows so PHI never reaches that vendor's systems.

How often should I review my BAAs?

At minimum annually, and immediately when: you change vendors, your vendor changes subcontractors, you add AI integrations, or regulations are updated. Most companies should build BAA review into their quarterly compliance cycle.

Can my cloud provider's BAA protect me from a breach?

Only partially. Cloud provider BAAs contain conditional compliance clauses — they protect the provider's infrastructure, not your configuration. If a breach results from your misconfiguration, the cloud provider's BAA won't shield you.

Ankita (Ann) Srivastava is the founder of Gavel Speaks Inc., a cross-border healthcare compliance practice. She has drafted and reviewed hundreds of BAAs for health tech companies integrating AI, multi-cloud infrastructure, and cross-border data flows. Harvard LL.M., 500+ global clients.