Building a Business Associate Agreement (BAA) Programme: What HealthTech CTOs Get Wrong

In March 2026, OCR settled with software vendor MMG Fusion following a breach that affected roughly 15 million individuals. The root cause was vendor management failure. Not a sophisticated cyberattack. Not a zero-day exploit. A breakdown in how PHI-handling relationships were documented and managed.

That settlement is not an outlier. Third-party involvement in healthcare data breaches doubled from 15% to 30% year over year in 2025. The Office for Civil Rights collected over $9.9 million in HIPAA settlements across 22 enforcement actions in 2024 alone, with business associate agreement deficiencies cited as a contributing factor in numerous cases.

For HealthTech CTOs and founders, this is the compliance problem hiding in plain sight. Most teams know they need BAAs. Far fewer have a programme that is current, complete, and structured to hold up when OCR or a hospital security team looks closely.

This guide covers what a real BAA programme looks like, where most HealthTech teams fall short, and how to fix the gaps before they show up in enforcement.

What a BAA Actually Is and Why It Matters More Than Ever in 2026

A Business Associate Agreement is a written contract between a HIPAA covered entity and any vendor, partner, or subcontractor that creates, receives, maintains, or transmits Protected Health Information (PHI) on its behalf.

Under HIPAA, a business associate is any person or organization that performs functions or activities on behalf of a covered entity that involve the use or disclosure of protected health information. This definition was significantly expanded by the HITECH Act of 2009 and formalized in the Omnibus Rule of 2013.

Since the HITECH Act, business associates are directly liable for HIPAA violations. They are not protected by the covered entity's compliance programme. If your product handles PHI and lacks a signed BAA with a vendor that touches that data, both you and that vendor face enforcement exposure.

What must be in every BAA under 45 CFR 164.504(e):

The mistakes that actually trigger OCR enforcement are simpler than most compliance teams expect: vendors handling PHI with no BAA at all, missing subcontractor agreements, and breach-reporting language too vague to act on.

5 Major BAA Mistakes HealthTech Teams Make

Mistake 1: Incomplete Vendor Inventory

You cannot have a BAA with a vendor you do not know is handling PHI.

This is the most common root cause of BAA programme failures and the one OCR finds most often during audits. Most teams know their primary vendors: their cloud provider, their EHR integration partner, their analytics platform. What they miss are the vendors that handle PHI indirectly.

Vendors that are commonly missed:

• Video consultation platforms (even if they claim HIPAA compliance, you need a signed BAA)
• Customer support tools that your team uses to help patients or clinicians (Intercom, Zendesk, Freshdesk)
• Email platforms used to send any patient-related communications
• AI tools your team uses to draft clinical documentation or summarize patient notes
• Log management and monitoring platforms that ingest application logs containing patient data
• Development and testing tools if real PHI is ever used in non-production environments
• Subcontractors your own team uses: freelancers, QA firms, offshore engineering teams

How to fix this:

Conduct a data flow mapping exercise that follows PHI from the point it enters your system through every service, tool, and environment it touches before it is deleted or returned. Every stop on that map that is handled by a third party is a potential BAA requirement. This exercise should happen before you sign your first hospital contract and be repeated annually as your vendor stack changes.

Mistake 2: Missing Subcontractor Flowdown

Missing subcontractor flowdown, where your business associate's subcontractors operate on a handshake, is one of the most frequently cited deficiencies in OCR audits.

If your vendor uses a subcontractor that handles PHI on their behalf, that subcontractor must also sign a BAA with your vendor. You are responsible for confirming this happens. "My vendor said they handle it" is not a defence in an OCR investigation.

What to do:

• Request a subprocessor list from every PHI-handling vendor annually
• Confirm in writing that each vendor has BAAs in place with all subprocessors that handle your PHI
• Include a subcontractor flowdown requirement as a contractual obligation in your own BAA template, not just a reference to HIPAA requirements

Mistake 3: Outdated BAAs That Predate the 2013 Omnibus Rule

Care New England Health System received a $400,000 settlement for using outdated BAAs that did not reflect current HIPAA requirements. Many organizations sign BAAs once and never review them.

If your company launched before 2015 or has been using the same BAA template for more than two to three years, there is a strong chance it is missing Omnibus Rule requirements: specifically breach notification timelines, subcontractor flowdown obligations, and updated individual rights provisions.

What to do:

Review every BAA signed before 2015 and any template in use today. Confirm each one contains a breach notification deadline measured in days with a named contact, explicit subcontractor flowdown language, and a security incident definition that matches your actual incident response procedure. Re-paper any BAA that is missing these elements.

Mistake 4: AI Tools Without BAA Coverage

Organizations are introducing AI-powered tools into clinical and administrative workflows without a clear understanding of whether those vendors qualify as business associates.

This is the newest and fastest-growing BAA gap in HealthTech. If your team is using any of the following with PHI, a BAA is required before the first use:

• LLMs via API for clinical documentation, summarization, or coding
• AI scribing or ambient documentation tools
• AI-powered patient communication platforms
• Machine learning tools processing clinical data for risk scoring or triage
• AI analytics platforms ingesting EHR-sourced data

BAA availability by major AI provider in 2026:

If your team is using OpenAI's direct API and passing any patient data in prompts, you are in violation right now. Switch to Azure OpenAI, which provides the same models with a BAA available through Microsoft's enterprise agreement.

Read More: LLMs in Clinical Settings: What the FDA, HIPAA, and Your Hospital Client Actually Require

Mistake 5: No Annual Review or Renewal Process

BAAs should be reviewed annually and updated whenever the scope of services changes, regulations are updated, or a vendor's data handling practices change.

The first proposed update to the HIPAA Security Rule since 2013, published in the Federal Register on January 6, 2025, proposes a requirement that business associates verify, at least once every twelve months, that they have deployed the technical safeguards required by the Security Rule.

A BAA signed in 2022 for a vendor that has since changed its infrastructure, expanded its subcontractors, or modified its data handling practices may no longer accurately reflect how your PHI is being managed. An outdated BAA provides limited protection in enforcement even if it was compliant when signed.

What a proper annual review looks like:

• Confirm the vendor still handles PHI on your behalf in the same way
• Request updated subprocessor list
• Confirm no changes to data storage location or residency
• Verify the breach notification contact information is still current
• If the vendor's services expanded, confirm the BAA scope covers the new activities
• Request the vendor's current SOC 2 report or equivalent as evidence of ongoing security posture

What OCR Looks For During BAA Enforcement

Understanding what OCR actually investigates helps you prioritise which gaps to close first.

OCR's enforcement run through 2025 and into 2026 keeps returning to vendor-management failures. Five mistakes account for most findings: no BAA at all with an active PHI vendor; missing subcontractor agreements; breach-reporting language too vague to act on; open BAAs from before March 2013 that are missing Omnibus-era elements; and breach clauses that lack a deadline measured in days, a named contact, and a security-incident definition.

OCR's investigation process typically covers:

• Completeness: Do you have a BAA with every vendor that handles PHI?
• Currency: Are your BAAs current and reflective of the Omnibus Rule?
• Specificity: Are breach notification timelines, contacts, and incident definitions specific enough to act on?
• Consistency: Are BAAs applied uniformly across all vendor types or only to obvious vendors while others are missed?
• Follow-through: When a vendor reports a security incident, was it handled correctly under the BAA terms?

Building Your BAA Programme: A Practical Framework

A BAA programme is not a folder of signed documents. It is an ongoing operational process. Here is what it needs to include.

Step 1: Complete Vendor Inventory

Build a full list of every third party that handles PHI in any form. Include:

• Cloud providers and specific services used
• EHR and health data vendors
• Communication and patient engagement tools
• AI and analytics services
• Support and ticketing tools
• Development, testing, and DevOps tools that touch PHI environments
• Any offshore or contract engineering teams

Step 2: BAA Gap Assessment

For each vendor on your list, confirm:

• Is a BAA in place?
• When was it signed?
• Does it contain all required Omnibus Rule elements?
• Has the scope of services changed since signing?
• Is the breach notification contact still current?

Step 3: BAA Template Standardisation

Maintain one current BAA template that includes all required elements under 45 CFR 164.504(e) and your organization's specific requirements. Include:

• A breach notification deadline of 24 to 72 hours (more specific than HIPAA's 60-day maximum)
• A named security contact at your organization
• Explicit subcontractor flowdown language
• Data return or destruction timeline on termination
• Your right to audit vendor compliance

Step 4: Tracking and Renewal System

Use a dedicated BAA tracking tool or a structured spreadsheet that records:

• Vendor name and PHI handling scope
• BAA date and template version
• Next review date (annual minimum)
• Breach notification contact at the vendor
• Subprocessor confirmation status
• Latest SOC 2 or equivalent report date

Tools like Vanta, Drata, and Medcurity can automate much of this tracking alongside your broader compliance programme.

Step 5: New Vendor Onboarding Process

Before any new vendor receives access to systems that handle PHI:

• Legal or compliance review to determine BAA requirement
• BAA negotiation and signature before system access is granted
• Subprocessor list requested at onboarding
• Vendor added to tracking system with renewal date set

BAA Compliance Checklist for HealthTech Teams

Conclusion

A BAA programme that was built two years ago and has not been touched since is not a BAA programme. It is a liability waiting to be found.

OCR's enforcement pattern in 2025 and 2026 is consistent: the organisations getting hit are not the ones with no compliance intentions. They are the ones whose vendor management programmes fell behind their product growth. Every new AI tool, every new integration, every new offshore contractor that touches PHI without a signed and current BAA is a gap that OCR can and does act on.

The fix is not complicated. It is a matter of treating your BAA programme as a live operational process, not a box to check at launch. A complete vendor inventory, current BAAs with explicit breach timelines, subcontractor flowdown confirmation, and an annual review cycle are all that separates a programme that holds up under scrutiny from one that does not. Build it correctly and it protects you. Leave it incomplete and it will cost you significantly more to clean up than it ever would have to get right the first time.