BAA structuring for healthtech startups: what your template is missing

A founder messaged me last quarter asking if I could review a Business Associate Agreement (BAA) before she signed it. Her startup had been in conversations with a large health system for four months. The deal was close. Legal on the health system side had sent over their BAA that morning with a note: “Please sign and return by Friday.”

She had never seen a BAA before. Neither had her attorney, who was a startup generalist comfortable with SAFEs and employment agreements but unfamiliar with the Health Insurance Portability and Accountability Act (HIPAA). The BAA was 14 pages, and as Holland & Knight’s analysis of these agreements makes clear, the perceived simplicity of BAAs is exactly what trips people up. It included a 24-hour breach notification clause, uncapped indemnification for any breach involving protected health information (PHI), and a $5 million insurance minimum. She was 48 hours from signing all of it.

That is not unusual. Most healthtech startups encounter their first BAA when a health system sends one. They either sign whatever arrives or send back a generic template downloaded from the internet. Neither position is good, because the BAA is not a formality. It is the first document a health system’s legal and compliance team reads to evaluate you as a vendor. It tells them whether you understand HIPAA, whether you have thought through your data handling, and whether you are a liability. If you have ever watched a deal stall because procurement flagged your compliance posture, you know the compliance wall is real.

The Change Healthcare breach (approximately 190 million individuals affected) has made health systems dramatically more careful about vendor BAA chains. Business Associate (BA) breaches have increased 337% since 2018. The Office for Civil Rights (OCR), the agency responsible for HIPAA enforcement, collected $9.9 million in settlements across 22 enforcement actions in 2024 alone. Health systems are paying attention, and the BAA is where that scrutiny starts.

TL;DR: Your BAA is a signal of compliance maturity, not a checkbox. The statutory requirements are narrower than most people assume, but health systems add breach notification timelines, indemnification clauses, and insurance minimums that go well beyond the regulation. Before a health system sends you theirs, arrive with your own draft. Know your subcontractor BAA chain, align your incident response plan with the notification timeline you are signing, and cap your liability in a way that does not create problems at acquisition. The BAA is the first impression your compliance posture makes.

What the regulation actually requires

The statutory floor for BAAs lives in 45 CFR 164.504(e). It defines eight core elements. They are narrower than most people assume.

The regulation requires that the BAA establish:

1. The permitted and required uses of PHI by the Business Associate
2. That the BA will not use or disclose PHI other than as permitted by the contract or required by law
3. That the BA will implement appropriate controls to protect ePHI (electronic Protected Health Information)
4. That the BA will report any use or disclosure not provided for by the agreement
5. That the BA will ensure any subcontractors who access PHI agree to the same restrictions
6. That the BA will make PHI available for individual access rights
7. That the BA will make PHI available for amendment
8. That the BA will make its internal practices and records available to the Department of Health and Human Services

The HHS sample BAA provisions reflect this statutory floor. Notice what is absent. The statute does not specify breach notification timelines. It does not require specific insurance limits. It does not mandate indemnification. Those come from the contract, not from HIPAA. Understanding this distinction changes how you approach the negotiation. Everything above the statutory floor is a business term, and business terms are negotiable.

Statutory requirements vs. common contractual additions

The table below summarizes the gap between what HIPAA actually mandates and what health systems typically negotiate into their BAA templates. Everything in the right column is a business term, not a regulatory one.

Element	Required by HIPAA (45 CFR 164.504(e))	Commonly added by health systems
Breach notification timeline	“Without unreasonable delay” (up to 60 days)	24-72 hours contractually
Indemnification	Not required	Broad, often uncapped for PHI breaches
Insurance minimums	Not required	$1-3M per claim (smaller vendors), $5M+ (high-risk)
Audit rights	HHS access only	Third-party audits, SOC 2 reports, on-site inspection
Subcontractor verification	Flow-down requirement only	Evidence of downstream BAA chain
State law compliance	Not addressed	California, Texas, and other state provisions
AI/ML data handling	Not addressed	Restrictions on model training, PHI use in analytics
Data residency	Not addressed	US-only or region-specific requirements

The subcontractor chain problem

Here is a sentence I hear constantly from healthtech CTOs: “We have a BAA with AWS.”

That is usually true. Amazon Web Services offers a HIPAA BAA through AWS Artifact, and it covers 166 or more eligible services. But there is a meaningful difference between “we have a BAA with AWS” and “we have inventoried every service that touches PHI and confirmed each one is HIPAA-eligible.”

AWS explicitly states that PHI may only be processed and stored on HIPAA-eligible services. If your engineering team is using a service that is not on that list, your BAA with AWS does not cover it. S3, RDS, Lambda, and ECS are eligible. Not every service is. Most startups assume blanket coverage. That assumption is wrong.

The subcontractor chain extends beyond your cloud provider. If you use a compliance platform, an analytics tool, or any third-party service that touches PHI, each one needs its own BAA. And each of those vendors has their own subcontractors. Your health system customer is increasingly asking to see this full chain, not just the top-level agreement.

The practical step here is an inventory. Before you send or sign any BAA, document every service and vendor that processes, stores, or transmits PHI. Confirm that a BAA is in place for each one. Confirm that every cloud service you are using for PHI is on the HIPAA-eligible list. This inventory becomes an exhibit to your BAA and a signal to the health system that you have thought this through.

Breach notification: the gap between what you sign and what you can execute

The statutory timeline

The 60-day figure that everyone cites in HIPAA conversations is the covered entity’s obligation to notify affected individuals. It is not the Business Associate’s timeline.

The BA’s obligation under the HIPAA Breach Notification Rule is to notify the covered entity “without unreasonable delay” and no later than 60 days after discovery. But in practice, health systems do not wait 60 days. They contractually impose much shorter windows.

The typical range I see in health system BAAs is 24 to 72 hours. The large systems push for 24. The mid-size systems often land at 48. These are contractual requirements, meaning you are agreeing to them when you sign the BAA, and they carry whatever penalties the indemnification clause attaches to a breach of the agreement.

The operational reality

Here is the problem: most startups cannot actually execute a 24-hour notification.

Think about what 24 hours requires. Someone detects the incident. That person triages it and confirms it involves PHI. They escalate to the right people. Someone drafts the notification to the covered entity with the required details (nature of the breach, types of PHI involved, steps being taken). Legal reviews it. It gets sent.

At a 20-person startup without a dedicated security team, without pre-written notification templates, without an on-call escalation process, and without a triage playbook, 24 hours is not realistic. And signing a clause you cannot operationally execute is creating a future contract violation by agreement.

There is also a regulatory development worth tracking. The proposed HIPAA Notice of Proposed Rulemaking (NPRM) published in December 2024 would codify a 24-hour BA notification requirement as a regulatory obligation, not just a contractual one. As of April 2026, this has not been finalized. But the direction is clear, and health systems are already building these timelines into their contracts in anticipation. I wrote about the broader implications of these proposed changes in my post on the HIPAA 2026 rule changes.

The fix is straightforward. Before you agree to any notification timeline in a BAA, build the incident response plan that makes the timeline possible. Write the notification templates. Define the escalation path. Run a tabletop exercise. Then sign the clause, because now you can actually honor it.

Liability and indemnification: the clauses that matter at acquisition

HIPAA does not require indemnification. This surprises most founders, because every health system BAA they have seen includes it. Indemnification is a contract term, not a regulatory one.

What health systems add

• Broad indemnification for any breach of the BAA
• Cyber insurance minimums ($1 to $3 million per claim for smaller vendors, $5 million or more for high-risk engagements)
• Uncapped general liability for PHI breaches
• Survival clauses that extend obligations beyond contract termination

The indemnification language is where I spend the most time during BAA reviews, because the default language in most health system templates is heavily tilted toward the covered entity. That is expected. They are the larger party, they are the ones facing regulatory scrutiny, and they are the ones whose patients are affected.

The uncapped liability distinction

There is a distinction that matters for your startup’s future: uncapped breach-specific indemnification is different from uncapped general liability.

Breach-specific indemnification is manageable. You can insure against it. Cyber liability policies are built for exactly this exposure. A startup with a $2 million cyber policy can absorb a breach-specific indemnification clause that caps at the policy limit.

Uncapped general liability is a different exposure entirely. It means the health system can come after you for consequential damages, lost revenue, reputational harm, and anything else a court will allow. This creates a line item in due diligence during an acquisition. I have seen M&A attorneys flag uncapped general liability in vendor BAAs as a material risk during Series B and later transactions. It does not kill the deal, but it slows it down and can affect valuation.

What you can negotiate

• Cap total liability to aggregate fees paid under the contract (common and usually accepted)
• Exclude consequential damages (both parties benefit from this)
• Limit indemnification to direct acts or omissions (rather than any breach, however minor)
• Align insurance requirements with what is actually available and affordable at your stage

The health system will not accept all of these. But arriving with specific redlines, rather than signing the default, signals that you understand the exposure and have thought about it. That is the kind of signal that helps you close the deal, not delay it.

Additional clauses beyond the statutory floor

Health system BAAs have grown significantly in the last three years. Beyond the core regulatory requirements and the indemnification language, here are the clauses I see most frequently:

Audit rights

Nearly every health system BAA includes a right to audit the BA’s security practices. For startups, a SOC 2 (System and Organization Controls 2) Type II report satisfies this in almost every case. If you are unfamiliar with how SOC 2 applies when PHI is in scope, I covered this in detail in my post on SOC 2 Trust Service Criteria and PHI. The clause to watch for is one that allows on-site audits with short notice. Negotiate to make SOC 2 Type II the primary mechanism, with on-site audits limited to situations where the report is insufficient or a breach has occurred. Choosing the right auditor matters here too, and I have written separately about how to approach that decision.

Information blocking

If your product handles clinical data, the 21st Century Cures Act prohibition on information blocking may show up in the BAA. This is especially relevant for companies building on top of FHIR (Fast Healthcare Interoperability Resources) APIs or integrating with Electronic Health Record (EHR) systems.

State law provisions

HIPAA sets the floor, but states add their own requirements. California and Texas both have healthcare privacy laws that go beyond federal requirements. If your health system customer operates in those states, expect the BAA to reference state-specific obligations.

AI and machine learning data handling

This is the newest category. Post-2023, I see clauses restricting the use of PHI for model training, requiring disclosure of any AI or ML processing, and sometimes prohibiting the use of PHI in aggregate or de-identified datasets for product improvement. If your product uses AI, read these clauses carefully. They can restrict product functionality in ways the engineering team does not expect.

Termination and PHI return

The BAA should specify what happens to PHI when the contract ends. The standard approach is return or destruction, with certification. But the timeline and method matter. Some BAAs require destruction within 30 days. If your architecture makes that difficult (data spread across backups, logs, and analytics systems), you need to know before you sign.

Data residency

Some health systems require PHI to remain within specific geographic boundaries, usually the United States. If you are using a cloud provider with global infrastructure, confirm that your PHI processing is confined to the required regions.

How to structure your BAA before the health system sends theirs

The single most effective thing a healthtech startup can do in BAA negotiations is arrive with their own draft.

This is not standard practice. Most startups wait for the health system to send their template and then react. But arriving with your own BAA accomplishes several things at once. It shifts the negotiation starting point. It demonstrates that you have thought about HIPAA compliance before this specific deal required it. And it signals to the health system’s legal team that you are a serious vendor, not one they need to educate.

Your draft should include:

• Permitted uses scoped to your actual product function. Do not use broad language. If your product processes lab results, say that. If it does not store imaging data, exclude it. Specificity protects both parties.

• A breach notification timeline you can actually execute. If 24 hours is realistic for your team, offer it. If 48 hours is more honest, propose that with an explanation of your incident response process. Health systems respect a vendor who knows their own capabilities over one who agrees to everything and fails to deliver.

• Capped indemnification. Propose a cap tied to aggregate fees paid, with exclusions for consequential damages. The health system will counter, but you have established a reasonable starting position.

• Insurance requirements you can meet. If you carry $2 million in cyber liability, do not sign a clause requiring $5 million. Propose what you have with a commitment to increase coverage as the engagement grows.

• A subcontractor list with BAAs in place. This is the exhibit that most startups cannot produce. Having it ready is a strong signal.

• A clear PHI return and destruction process. Define the timeline and method. Reference your data retention policy.

The practical sequence

If you are a healthtech startup preparing for your first health system deal, here is the order I would follow:

First: Engage a healthcare attorney. Not your startup generalist. Someone who reviews BAAs regularly and understands both the regulatory requirements and the commercial norms. This is a one-time cost of $5,000 to $10,000 for a template BAA review and customization, and it pays for itself on the first negotiation.

Second: Inventory your BAA chain. Every vendor, every cloud service, every third party that touches PHI. Confirm BAAs are in place. Confirm HIPAA-eligible services are the only ones processing PHI. Document it.

Third: Build an incident response plan that matches the notification timeline you intend to offer. If you are running SOC 2 and HIPAA together, the 12-week preparation timeline I outlined here gives you the sequencing for how IR planning fits into the broader program. If you are going to propose 48-hour notification, your IR plan needs to demonstrate that 48 hours is achievable. Write the templates. Define the roles. Run through a scenario.

Fourth: Align your insurance with the indemnification language in your draft BAA. Talk to your broker before the negotiation, not after. Understand what your policy covers and what it excludes.

Fifth: Prepare the draft BAA and send it to the health system before they send theirs. Frame it as: “Here is our standard BAA. We are happy to review yours as well and work toward a mutual agreement.” That framing is collaborative, not adversarial.

The average healthcare data breach costs $10.22 million according to IBM’s 2025 report. Health systems know this number. They are not trying to be difficult with their BAA requirements. They are trying to protect their patients and their organization. When you arrive prepared, with a draft that shows you take that responsibility seriously, you change the dynamic of the entire procurement conversation.

The BAA as a signal

I keep coming back to the same observation after reviewing dozens of these agreements. The startups that close health system deals fastest are not the ones with the most permissive BAAs. They are the ones whose BAAs demonstrate that someone has actually thought about how PHI flows through their system, what happens when something goes wrong, and what the limits of their liability should be.

The BAA is not the last hurdle before the deal closes. It is the first real test of whether you understand the environment you are selling into.