The Startup MDVisit Website →
← Back to blog

HIPAA BAA Requirements: What Every Contract Must Include

August 28, 2026
HIPAA BAA Requirements: What Every Contract Must Include

A written Business Associate Agreement (BAA) is required whenever a vendor creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity, and HHS/OCR enforces this directly against the vendor, not just the healthcare organization that hired it. The HITECH Act made business associates independently liable for specific HIPAA provisions, and that liability flows downstream to every subcontractor touching PHI. Skipping a BAA is not a paperwork gap. It is a compliance failure with its own enforcement track.

TL;DR:

  • A BAA must clearly specify permitted uses of PHI, include safeguards, and detail breach reporting timelines to ensure compliance and audit readiness.
  • HITECH grants direct OCR liability to business associates for security lapses, breach notification failures, and subcontractor violations, extending enforcement beyond contracts.
  • Subcontractors handling PHI require their own signed BAAs, with flow-down provisions, audit rights, and secure technical segmentation to prevent compliance gaps.
  • Using limited data sets with a DUA can replace a full BAA when only de-identified or limited PHI is involved in research or analytics activities.
  • Operational readiness, including technical capabilities like data access controls and breach detection, is crucial to meet BAA obligations and avoid audit failures.

Table of Contents

What Counts as a Business Associate Under HIPAA BAA Requirements?

A covered entity is a health plan, health care clearinghouse, or health care provider that transmits health information electronically in connection with a covered transaction. A business associate is any person or company that performs a function or service involving PHI on that entity's behalf, without being part of the covered entity's own workforce.

The trigger is activity, not job title. If a vendor creates, receives, maintains, or transmits PHI to do its job, it is a business associate under HHS guidance, and a BAA is required before that data changes hands. Common examples include:

  • A cloud hosting provider storing a patient portal's database
  • A medical billing company processing claims on a practice's behalf
  • An analytics vendor running population health models on clinical data
  • A transcription service converting dictated notes into text
  • A call center handling patient scheduling or appointment reminders

Not every vendor touching a healthcare organization needs a BAA. Incidental exposure, where a cleaning contractor might glimpse a paper chart on a desk, does not create business associate status because there is no intentional use of PHI to perform a service. Vendors that never access PHI, like an office furniture supplier or a general IT contractor who only touches hardware without ever viewing data, also fall outside the requirement. The distinction that trips up most founders is treatment, payment, and operations disclosures between two covered entities. A hospital sending records to a specialist for patient treatment does not need a BAA for that exchange, since both parties are covered entities acting in a treatment relationship, not a vendor arrangement.

What Must a HIPAA-Compliant BAA Include?

The Privacy Rule spells out the minimum contract terms in 45 CFR §164.504(e), and sample provisions from HHS translate that regulation into contract language. Every BAA needs to address six core elements.

  1. Permitted and required uses of PHI. The agreement must specify exactly what the business associate is allowed to do with the data, and prohibit any use beyond that scope. Vague language like "as needed to perform services" invites scope creep and audit findings.
  2. Appropriate safeguards. The vendor must implement administrative, physical, and technical safeguards consistent with the Security Rule, even if the BAA itself doesn't reprint the Security Rule's technical specifications.
  3. Breach and security incident reporting. The contract must require the business associate to report unauthorized uses, disclosures, and security incidents, generally including a defined notification window.
  4. Subcontractor flow-down. Any subcontractor that creates, receives, maintains, or transmits PHI on the business associate's behalf must sign an agreement with the same restrictions that apply to the business associate itself.
  5. Return or destruction of PHI. When the relationship ends, the business associate must return or destroy PHI where feasible, and explain in writing if destruction isn't possible.
  6. Availability for HHS audits. The business associate must make its internal practices, books, and records available to HHS to determine Privacy Rule compliance.

Pro Tip: Watch for BAAs that describe safeguards in generic terms like "commercially reasonable security measures" without tying them to specific administrative, physical, and technical safeguard categories. That phrasing sounds fine to a business team and means almost nothing to an auditor.

Where template BAAs tend to fail is the breach notification clause. Many vendor-drafted agreements borrow language that says the business associate will report breaches "promptly" or "as required by law" without stating a number of days. That ambiguity becomes a real problem the moment a breach actually happens and the covered entity is racing its own 60-day notification clock to individuals and HHS.

How Does HITECH Create Direct Liability for Business Associates?

Before HITECH, business associates faced contractual liability only, meaning the covered entity could sue for breach of contract but OCR generally couldn't fine the vendor directly. That changed. HITECH made business associates directly liable to OCR for a defined set of failures, described in HHS's factsheet on direct liability.

Enforceable failures now include Security Rule noncompliance, breach notification lapses, impermissible uses or disclosures of PHI, failing to provide individuals access to their records when the BAA requires it, and failing to obtain BAAs with the vendor's own subcontractors. That last one catches founders off guard constantly. A startup can have a flawless BAA with its hospital customer and still face OCR enforcement for never papering the agreement with the cloud vendor storing that hospital's data underneath it.

The operational consequences extend past fines. OCR can require corrective action plans that mandate specific remediation steps, timelines, and reporting, effectively putting a compliance officer inside the company for months or years. For a healthcare SaaS company mid-fundraise, a corrective action plan on the cap table narrative is its own kind of damage, separate from any dollar penalty. Direct liability also changes vendor due diligence from a legal checkbox into operational risk management, since the covered entity's exposure now depends partly on decisions the vendor made about its own subcontractors.

How Does HITECH Create Direct Liability for Business Associates? — overview diagram

Do Subcontractors Need Their Own BAAs?

Yes, and this is where most compliance programs quietly break down. A business associate must obtain a BAA from any subcontractor before disclosing PHI to it, with the same restrictions and conditions that apply to the business associate itself. That obligation exists whether or not the covered entity ever sees or signs off on the subcontractor agreement.

Practical controls that keep this chain intact:

  • Contract flow-down language requiring the vendor to warrant, in writing, that every subcontractor with PHI access has signed an equivalent BAA
  • Audit rights letting the covered entity request evidence of subcontractor agreements on demand, not just at signing
  • Annual attestations from vendors confirming their subcontractor list and BAA status haven't changed
  • Technical segmentation limiting which subcontractors can access PHI in the first place, reducing how many downstream agreements are even necessary
  • Minimum-security baselines applied uniformly across the vendor's own supply chain

One of the most frequent findings in HIPAA audits is exactly this gap: covered entities confirm their primary vendor signed a BAA but never verify that vendor secured BAAs from its own subcontractors. The remediation is straightforward once discovered, requiring the vendor to produce its subcontractor BAA inventory, but discovering the gap usually happens during a breach investigation, which is the worst possible time.

Pro Tip: Triage subcontractors by PHI exposure rather than treating them all the same. High-risk vendors handling large volumes of PHI warrant onsite or remote evidence collection and real audit rights; low-risk vendors can be monitored through attestations and periodic sampling instead of a full audit cycle every time.

When Does a Limited Data Set Replace a BAA With a DUA?

A limited data set (LDS) strips PHI of 16 direct identifiers, including names, addresses more specific than state, phone numbers, email addresses, Social Security numbers, and medical record numbers, while retaining dates and city or zip-level geography for research or analytics purposes. Because an LDS still counts as PHI under HIPAA, its use isn't unrestricted, but the governing instrument changes.

When PHI disclosed is limited to an LDS for research, public health, or health care operations, a Data Use Agreement (DUA) can satisfy HIPAA's requirements instead of a full BAA. A DUA restricts how the recipient can use and disclose the limited data set and requires reasonable safeguards, but it's a narrower instrument built specifically for that reduced dataset.

Legal teams frequently choose to layer a DUA and a BAA together, or scope the BAA broadly enough to cover potential future uses, when a partnership might expand beyond the initial limited data set arrangement. That avoids renegotiating contracts every time a research collaboration grows into a full data-sharing relationship. If your healthtech company is only ever going to receive de-identified or limited datasets from a single, narrowly defined source, a DUA alone may be sufficient. If there's any chance the relationship expands to full PHI access, the combined approach costs little upfront and saves a contract cycle later.

When Does a Limited Data Set Replace a BAA With a DUA? — overview diagram

Why Do Signed BAAs Still Fail HIPAA Audits?

A signed BAA is a necessary condition for compliance, not a sufficient one. Auditors routinely find organizations with a fully executed agreement and no underlying policies, no documented risk assessment, and no employee training program to back it up. The contract exists. The operational reality behind it doesn't.

For healthcare SaaS products specifically, the gaps tend to be technical:

  • No ability to export, amend, or delete a patient's data on request, which breaks the BAA's commitment to help the covered entity honor individual Privacy Rule rights
  • No role-based access controls, meaning any employee with system access can see PHI regardless of whether their job requires it
  • No audit logging, so there's no way to reconstruct who accessed what data after a suspected incident
  • Contractual promises that outpace the product, such as a BAA committing to a breach notification timeline the engineering team has no monitoring system to actually meet

The prioritization for compliance owners fixing this should start with logging and access controls, since those are the two gaps that turn a minor incident into an unexplainable one. A health IT vendor readiness checklist built around these exact technical capabilities catches most of this before a contract is even signed. The HIPAA Security Rule provides the underlying technical safeguard categories that a BAA references but doesn't itself spell out, and it's worth reviewing alongside any BAA draft.

What Should a BAA Drafting Checklist Include?

Legal and compliance teams reviewing a vendor-supplied BAA, or drafting their own, should work through a specific set of negotiable items rather than accepting boilerplate at face value.

  1. Permitted uses stated narrowly. The agreement should list specific purposes, not open-ended language covering "any business purpose."
  2. Minimum necessary standard. The vendor should only access the PHI required to perform its specific function, not the full dataset by default.
  3. Security safeguards tied to specifics. Look for explicit references to encryption, access controls, and the Security Rule's administrative, physical, and technical safeguard categories.
  4. Breach reporting timeline with detail requirements. The clause should specify a number of days and what information the notification must contain, not just "prompt notice."
  5. Return or destruction language with a documented exception process. If destruction isn't feasible, the agreement should require the vendor to explain why in writing and continue protecting the data indefinitely.
  6. Subcontractor obligations mirrored exactly. The flow-down clause should require subcontractor BAAs with identical restrictions, not a lighter version.
  7. Termination rights for material breach. The covered entity should be able to terminate immediately, not just at contract renewal, if the vendor violates its BAA obligations.
  8. Audit and evidence rights. The covered entity should retain the right to request compliance evidence on a defined cadence, not just at signing.
  9. Indemnity considerations scoped to the actual risk. Indemnification language should reflect who controls the systems where a breach is most likely to originate.

The biggest red flag in vendor-supplied drafts is a BAA that reads like it was copied from a generic template five years ago, with no reference to current breach notification norms or subcontractor flow-down language at all. If a vendor pushes back hard on adding audit rights, that resistance itself is worth noting during due diligence.

How Do You Manage BAAs After Signing?

A BAA that sits in a shared drive after execution protects no one. Vendor onboarding should start with due diligence: a security questionnaire, a review against a minimum-security checklist, and BAA signature only after both are satisfied, not before.

Ongoing management requires:

  • Periodic reassessments, typically annual, confirming the vendor's security posture hasn't degraded
  • Evidence collection tied to specific BAA commitments, not a general "trust us" attestation
  • Audit rights actually exercised on a sample of vendors each year, not just written into the contract and never used
  • KPIs tracking vendor response times to security questionnaires and incident reports

Breach response should map directly to what the BAA promises. If the agreement requires notification within a specific number of days, the covered entity needs a process for confirming that timeline gets met, who owns the investigation, and what remediation plan follows. A healthcare SaaS customer success framework built around these operational checkpoints turns vendor management from a once-a-year contract review into a continuous control.

Why Founders Underestimate BAA Complexity Until It's Too Late

Most healthcare SaaS founders treat the BAA as a legal formality to clear before a sales contract closes, and that mindset is exactly what creates enforcement exposure later. The agreement itself is the easy part. What I see founders miss is that a BAA is a promise about technical capability, not just legal intent. If your contract commits to breach notification within a set number of days, your engineering team needs monitoring infrastructure that can actually detect an incident that fast. If it commits to supporting a patient's right to access or amend their records, your product needs an export and correction workflow, not a support ticket queue.

The subcontractor gap is the one that catches even sophisticated teams. I've reviewed vendor stacks where the primary BAA was airtight and the cloud infrastructure agreement underneath it was either missing or years out of date. That's not a legal oversight. It's a vendor management program that never scaled past its first few contracts. Startups that treat BAA compliance as a technical readiness question from day one, not a legal afterthought bolted on before a big customer signs, end up with far less rework when they scale past their first enterprise deals.

— Paul Bergeron MD, MBA

How The StartupMD Helps You Operationalize BAA Compliance

Most healthcare SaaS teams don't need another law firm memo explaining HIPAA. They need someone who has sat on both sides of the table, clinical and operational, to translate a BAA into product requirements, vendor selection criteria, and a due diligence process that actually holds up under investor and enterprise customer scrutiny.

The StartupMD

The StartupMD, led by Paul Bergeron, MD, MBA, works with healthcare SaaS founders and executives as a fractional Chief Medical Officer and strategic advisor, bringing many years of combined medical and business experience to vendor risk assessments, clause-level contract review, and remediation roadmaps when a BAA program has gaps. That dual clinical and technology background means the advice accounts for both the regulatory text and what your engineering team can realistically build to support it. If your company is preparing for a fundraise or an enterprise deal and your vendor management program needs a hard look before due diligence starts, review The StartupMD's healthcare SaaS revenue model evaluation guide or visit the services page to schedule a consultation.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources