What is a BAA? Business Associate Agreement Explained

Last updated: 29 May 2026

If you run a clinic, a hospital billing team, a telehealth platform, or anything in between, somebody — usually a procurement manager halfway through a software trial — has probably asked you for a BAA. The acronym sounds harmless and the document looks like a standard contract addendum. It isn't either of those things. A BAA is the single piece of paper that decides whether your vendor relationship is a HIPAA compliance asset or a HIPAA enforcement action waiting to land.

We sit on the vendor side of a lot of those conversations because Paytia handles phone-based card payments for healthcare clinics and contact centres in the US, and PHI tends to live alongside payment card data in the same call. So we sign BAAs, we read BAAs, and we've watched perfectly competent IT teams get the basics wrong because nobody sat them down and explained what the document is actually for. This post is that sit-down.

What is a BAA? The plain-English answer#

A Business Associate Agreement is a written contract between a HIPAA-covered entity and a business associate. The covered entity is the regulated party — a healthcare provider, a health plan, or a healthcare clearinghouse. The business associate is any outside organisation that creates, receives, maintains, or transmits Protected Health Information (PHI) on the covered entity's behalf to perform a function or service for them. The BAA puts the business associate on the hook for HIPAA's Privacy, Security, and Breach Notification rules in the same way the covered entity is on the hook.

The regulation itself sits at 45 CFR 164.504(e) and 45 CFR 164.314(a). Those two sections list the clauses a BAA has to contain. Anything labelled "BAA" that's missing those clauses isn't a HIPAA-grade BAA — it's a NDA in fancy dress. We've seen plenty of those in the wild.

The simpler way to think about it: HIPAA puts duties on covered entities. The BAA passes a defined chunk of those duties down to the vendor. Both parties end up legally responsible to the Department of Health and Human Services (HHS) — that's the post-HITECH bit, and it reshaped the relationship permanently in 2013. Before HITECH, only the covered entity faced direct HHS enforcement; now the business associate does too. That's why a vendor with a current BAA programme and a defensible security posture has become a procurement requirement rather than a nice-to-have.

If you're brand new to the HIPAA framework, the wider HIPAA-compliant credit card processing guide walks through how PHI, PCI, and the BAA all sit together. This piece zooms in on the BAA itself.

Who counts as a business associate?#

The category is wider than most teams assume. A business associate is any person or organisation that performs functions or activities on behalf of a covered entity involving the use or disclosure of PHI. That covers obvious vendors — billing companies, claims processors, transcription services, IT consultants who can see PHI during support — and less obvious ones, like cloud storage providers, email-hosting vendors, document-shredding companies, and yes, payment processors that handle data alongside PHI on a phone call.

Specific examples HHS calls out include third-party administrators that help a health plan handle claims, lawyers whose work for the covered entity involves access to PHI, accountants who get PHI during an audit, independent medical transcriptionists, and pharmacy benefit managers running a formulary. The pattern in all of those is the same: outside party, performs a function for the covered entity, sees PHI to do it. Three boxes ticked, BAA required.

The cases that surprise teams the most are the modern ones. A SaaS analytics platform that touches encrypted PHI but never decrypts it is still a business associate — HHS's position is that conduit-only is a narrower exemption than vendors typically claim. A managed cloud provider hosting an EHR is a business associate even if it can't read the data because it has the keys to the door. A telephony vendor recording calls that contain PHI is a business associate. The conduit exemption was deliberately written narrow to stop everyone wriggling out of it.

There's a second tier: subcontractors. If a business associate hires a vendor of its own to help perform the function — say, a billing company hires a cloud database — that subcontractor is also a business associate and needs its own BAA with the upstream business associate. HIPAA flows downhill. Every link in the chain that handles PHI needs to be covered, and the covered entity at the top is allowed to ask each link to prove it.

What is PHI and why does it matter for the BAA?#

The BAA exists because PHI exists. Protected Health Information is any individually identifiable health information held or transmitted by a covered entity or its business associate, in any form — electronic, paper, or oral. "Individually identifiable" is the test the HHS Office for Civil Rights applies, and it's broader than "contains the patient's name." Eighteen identifiers are listed in the Privacy Rule and the presence of any of them turns health information into PHI: names, geographic data smaller than a state, dates more specific than the year, phone numbers, email addresses, Social Security numbers, medical record numbers, account numbers, biometric identifiers, full-face photos, and so on.

Payment data sits right next to PHI on a phone-payment call. If a patient calls to pay their bill and the agent says "Mrs Garcia, I've got the $240 outstanding on your account ending 1442 for the colonoscopy on April 14th" — every word of that is PHI plus PCI in one breath. The recording, if it isn't masked, captures both. That's exactly the boundary case where the BAA does its work: it forces the vendor (the payment processor, the recording platform, the contact-centre vendor) to apply Security Rule controls to anything that gets caught up in the audio path.

This is why phone-payment infrastructure is one of the most BAA-heavy parts of a healthcare stack. The payment moment is the moment PHI and PCI collide, and the BAA + DTMF masking combination is what keeps that collision from turning into a breach. The detail on the technical side lives in our DTMF masking solution page; the BAA is the legal complement to it.

The required clauses: what a real BAA contains#

HIPAA's BAA requirements aren't optional and they aren't subjective. The list is in the regulation — 45 CFR 164.504(e)(2) for the privacy components, 45 CFR 164.314(a)(2) for the security components. Any BAA missing one of these isn't compliant, even if it's been signed by both sides. Here's what has to be in the document.

The first set of clauses defines the permitted uses and disclosures. The BAA has to specify, in concrete terms, what the business associate is allowed to do with the PHI. That's not a generic "for business purposes" clause; it's a description tied to the actual service. A payment processor's BAA will permit using PHI to process the transaction, manage the recording, support reconciliation, and respond to disputes. It won't permit using PHI for marketing, for selling to third parties, or for purposes outside the documented service.

The second set covers safeguards. The business associate must agree to use appropriate administrative, physical, and technical safeguards to prevent use or disclosure outside the BAA terms, and to implement the Security Rule requirements for any electronic PHI. The phrase "appropriate" matters — it's interpreted against the Security Rule's risk-analysis approach, not a one-size-fits-all checklist. A vendor handling PHI at scale needs more elaborate safeguards than a transcriptionist working with a single client's recordings.

The third set covers breach notification. The business associate must report to the covered entity any use or disclosure not permitted by the BAA, any security incident, and any breach of unsecured PHI. The reporting clock is tight and HIPAA's definition of "breach" is statutory — anything except a narrow set of exceptions counts. The notification clause needs to specify the timeline, the channel, and the content of the notification.

The fourth set covers subcontractors. The business associate has to ensure any subcontractor that creates, receives, maintains, or transmits PHI on its behalf agrees in writing to the same restrictions and conditions. That's the downstream flow we mentioned earlier — the covered entity's BAA with the business associate doesn't bind the subcontractor directly, so the business associate has to put its own BAA in place with each one.

The fifth set covers individual rights. The business associate has to make PHI available to satisfy a covered entity's obligations under the right of access (45 CFR 164.524), the right of amendment (45 CFR 164.526), and the accounting of disclosures requirement (45 CFR 164.528). In practice this means the business associate has to be able to find a specific patient's PHI in its systems and hand it back when asked.

The sixth set covers return or destruction. At termination of the BAA, the business associate must return or destroy all PHI received from or created on behalf of the covered entity. If return or destruction isn't feasible — usually because the PHI is in long-term backups or commingled records — the BAA must extend the protections to the retained PHI for as long as it's held. Vendors that can credibly destroy data at termination have a competitive advantage; vendors with sticky backups have to write longer BAAs.

Finally, the BAA has to give the covered entity the right to terminate the agreement if it determines the business associate has materially breached the contract. That's the contractual hammer the covered entity holds, and the practical reason vendors take BAA breaches seriously even before HHS gets involved.

What a BAA is not#

A BAA isn't a confidentiality agreement. We've seen vendors hand over a one-page NDA labelled "BAA" because somebody internally believed the two were interchangeable. They aren't. An NDA is a private contract between two parties that protects information without invoking any regulatory framework. A BAA invokes HIPAA explicitly, allocates statutory duties under HIPAA, and creates a regulatory hook for HHS to come after both parties. Different document, different purpose, different liability.

A BAA isn't a substitute for the security controls themselves. Signing the document doesn't make a vendor HIPAA-compliant. The vendor still has to do the work — risk analysis, access controls, encryption at rest and in transit, audit logging, incident response, workforce training, all of it. The BAA is the legal wrapper; the controls are what the wrapper protects.

A BAA isn't a one-and-done annual ritual. Procurement teams sometimes treat it as a contract milestone that gets signed once at vendor onboarding and forgotten. The reality is that any material change to the service — a new data type processed, a new sub-processor added, a change to the data residency arrangement, an acquisition of the vendor by another company — should trigger a BAA review. Most BAAs include a clause requiring written notice of material changes; that clause exists because the people who drafted it knew the static-document model breaks under real-world vendor change.

A BAA isn't always required. The conduit exception, narrow as it is, applies to vendors that transmit PHI on behalf of a covered entity but don't access the content in any meaningful way — think a telecoms carrier that routes calls without recording them, or a postal service delivering paper records. In our world, a payment processor that records calls is not a conduit; one that strictly transmits and never recordings isn't either. Most modern vendors fall outside the conduit exception, so the safer assumption is that you need a BAA.

The HITECH Act and direct liability#

If you talk to a HIPAA lawyer about BAAs, they'll bring up HITECH within five minutes. The Health Information Technology for Economic and Clinical Health Act of 2009 changed the BAA landscape by making business associates directly liable to HHS for certain HIPAA violations. Before HITECH, the covered entity was the only directly regulated party — a business associate could only be sued for breach of contract by the covered entity. After HITECH (specifically, after the HHS Omnibus Final Rule in 2013 that implemented the relevant HITECH provisions), HHS can investigate and fine a business associate directly.

The practical effect is that vendors take BAAs much more seriously now than they did pre-2013. A vendor with a current BAA programme, a defensible Security Rule implementation, and an incident-response playbook is one that's accepted the post-HITECH risk model. A vendor that's still treating BAAs as procurement-driven paperwork — and there are still some — is one that's underinvested in its own compliance posture.

The fines themselves are scaled by HHS's tier system. Tier 1 is for violations the business associate didn't know about and couldn't reasonably have known about, with per-violation penalties starting at $137 and capped at $34,464 per identical violation per year. Tier 4 is for wilful neglect not corrected within thirty days, with per-violation penalties starting at $68,928 and capped at $2,067,813 per identical violation per year. Those numbers come from the 2024 HHS adjustments and reset annually. Our piece on HIPAA fines for payment processing breaches walks through how the tiers play out in real settlements.

When a BAA is required (and when it isn't)#

The rule of thumb is simple: if a vendor will create, receive, maintain, or transmit PHI on behalf of a covered entity, a BAA is required. The harder question is when that test is met in edge cases.

A vendor whose product touches PHI only because a customer chose to put it there — say, a generic cloud storage bucket where a clinic dropped some unencrypted records — is still a business associate. The vendor's intent doesn't matter; the data flow does. This is why HHS has been consistent in its enforcement against cloud providers that argued they weren't business associates because they didn't "design" their product for PHI.

A vendor that processes only de-identified data isn't a business associate, because de-identified data isn't PHI. The de-identification has to meet either the Safe Harbor standard (removing all eighteen identifiers and having no actual knowledge that the residual data could identify a person) or the Expert Determination standard (a statistically defensible methodology applied by a qualified expert). Hand-waving "we've removed the names" doesn't meet either bar.

A vendor that's a workforce member rather than an outside contractor isn't a business associate. Workforce includes employees, volunteers, trainees, and other people whose conduct is under the direct control of the covered entity, whether or not they're paid. The dividing line is control: if the covered entity manages the work day-to-day, the person is workforce; if the work is performed at arms-length by another organisation, that organisation is a business associate.

A vendor whose involvement is purely as a conduit for PHI — the postal service, a courier, a phone carrier that doesn't record — isn't a business associate. The exception is real but narrower than vendors often claim. The HHS guidance specifically calls out that the conduit exception applies only to transmission services that have transient access, and the agency has rejected attempts to extend it to cloud storage, email hosting, and similar services that maintain PHI even temporarily.

For everything in between, the safer default is to assume a BAA is required and let the vendor's legal team push back if they genuinely qualify for an exception. That's how procurement teams should approach it; that's how vendors should expect to be approached.

The covered entity's responsibilities under a BAA#

The BAA isn't all about the vendor. The covered entity has obligations too. The most important one is the obligation to terminate the BAA — and the relationship — if the business associate materially breaches the contract and doesn't cure the breach. HHS treats failure to act on a known material breach as itself a violation by the covered entity.

The covered entity is also expected to do reasonable due diligence at the front end. That doesn't mean a full vendor audit before signing every BAA, but it does mean asking the basic questions: does the vendor have a current Security Rule implementation, has it had any reportable breaches in the past three years, does it carry cyber liability insurance at a level that reflects the data exposure, can it produce a SOC 2 Type II or equivalent third-party attestation. Procurement teams that ask none of these and then face a breach often find HHS asking them why.

The covered entity also has the right — but not, by default, the obligation — to audit the business associate's BAA compliance. Many BAAs include an audit-rights clause that allows the covered entity to inspect the vendor's relevant policies, procedures, and controls. The frequency varies. Annual is common for high-value relationships; once-in-the-contract-life is more common for routine ones. The clause is there to support investigation when something goes wrong, and that's usually when it gets exercised.

BAAs and the payment moment#

Phone payments are one of the densest BAA scenarios in healthcare. A single inbound call can produce PHI (the agent confirming the procedure or balance with the patient), PCI data (the card details the patient reads or keys), and a recording of both that lives on the contact-centre platform. Every vendor in that chain — the telephony provider, the recording platform, the contact-centre software, the masking or payment provider, the gateway — touches data that's regulated under HIPAA, PCI DSS, or both.

Our position, having sat on the vendor side of dozens of these stacks, is that the payment moment should be architected so the PHI and the PCI data are separated structurally, not just contractually. DTMF masking does that for the PCI side — the digits never reach the merchant's environment, so the recording never contains PAN. For the PHI side, the right pattern is to keep the agent's voice path narrow: the agent confirms the patient and the amount, but the medical detail stays inside the EHR rather than getting verbalised mid-call. Combine those two and the call recording becomes much less sensitive — still PHI, still BAA-protected, but a much smaller exposure if something goes wrong.

If you're working through this for your own clinic or contact centre, our HIPAA payment processor checklist walks through the vendor questions to ask. The companion piece on HIPAA + PCI combined compliance for healthcare contact centres goes deeper on the two regulations together.

Common mistakes we see when reviewing BAAs#

The first mistake is signing without reading. A BAA is a contract; like any contract, the version a vendor sends first is the version most advantageous to the vendor. Permitted-use clauses can be written narrowly or broadly, breach-notification timelines can be tight or generous, subcontractor controls can be strong or weak. The covered entity that signs whatever lands in the inbox loses the negotiation by default.

The second mistake is treating the BAA as the whole compliance story. A signed BAA with a vendor that has no SOC 2, no Security Rule risk analysis, no incident-response plan, and no breach history reporting is a vendor that's likely to fail you when something goes wrong. The document is necessary; it's not sufficient.

The third mistake is failing to inventory active BAAs. Covered entities that can't produce a current list of every business associate they have on contract have a HIPAA gap before HHS even asks a question. The 2024 HHS guidance reiterates that maintaining a current BAA inventory is part of the covered entity's overall HIPAA programme.

The fourth mistake is not updating BAAs when the vendor changes its service. If a payment processor adds a new analytics feature that ingests transcription data, that's a material change to the data flow. The original BAA may not cover it. A vendor that pushes the change live without updating the BAA — or alerting the covered entity to the change — is creating exposure for both parties.

The fifth mistake is letting BAAs expire silently. Most BAAs are evergreen or auto-renewing, but some have hard end dates tied to the underlying service contract. When the service contract renews, the BAA needs to renew alongside it. A live vendor relationship without a current BAA is a HIPAA gap on the wrong side of the audit clock.

BAA negotiation: where the give and take happens#

Covered entities and business associates negotiate BAAs all the time. The clauses HIPAA requires are non-negotiable, but plenty of language around them is. Here are the points where negotiations usually centre.

Breach notification timelines are the most contested. Covered entities want immediate notice; vendors want time to investigate before alerting. A common middle ground is notification "without unreasonable delay" plus a hard outer bound — five business days, say, or ten calendar days. Whichever you pick, both sides need to know they can hit it in practice; an aspirational two-hour notification clause that gets missed on the first incident is worse than a realistic five-day clause that gets hit every time.

Indemnification is another flashpoint. Vendors often want to cap their liability at the fees paid under the service contract; covered entities want uncapped indemnification for HIPAA breaches caused by the vendor's negligence. The settlement point is usually a carve-out: standard liability cap for general contract claims, uncapped or super-capped indemnity for HIPAA breaches and breach-notification costs. Cyber liability insurance, with the covered entity named as additional insured, is the practical mechanism that makes the indemnity collectable.

Subcontractor approval clauses vary widely. Some covered entities want consent rights over every subcontractor; vendors with established stacks argue that's operationally impractical and offer a list of approved sub-processors plus advance notice of additions. The HIPAA requirement is that the business associate ensures the subcontractor agrees in writing to the same restrictions — the consent layer above that is a contractual matter, not a regulatory one.

Data return or destruction language at termination needs realism. "Destroy all PHI within five business days" sounds tidy but ignores backup retention schedules, archival systems, and the practical impossibility of finding every reference in commingled records. The honest version is "return or destroy what's reasonably feasible, extend BAA protections to anything retained, and document why retention is necessary." That's the language HHS expects in real-world BAAs.

Audit rights are negotiated against the vendor's existing attestation programme. A vendor with a current SOC 2 Type II report covering the relevant controls will often offer the report in lieu of an on-site audit. Covered entities that accept SOC 2 plus a short remote review of policy documentation usually find it gives them comfort without the cost of bespoke audits.

The OCR enforcement landscape in 2026#

HHS's Office for Civil Rights has been steadily increasing BAA-related enforcement over the past five years. Settlements against covered entities for inadequate BAA programmes — failing to have BAAs in place at all, having BAAs missing required clauses, failing to act when a business associate breached the contract — have moved from rare to common. Settlements against business associates for breach of their own HIPAA duties have similarly grown.

The headline cases tend to involve breach notification failures or unsecured PHI exposed in cyber incidents. Two patterns have emerged: regulators expect the covered entity to be able to produce a current list of all business associates, with executed BAAs for each, on demand; and regulators expect the business associate to be able to produce a current risk analysis, evidence of Security Rule implementation, and a breach notification process that has been tested. Either side that can't produce those records when asked tends to face larger fines.

The 2024 HIPAA Privacy Rule update around reproductive healthcare added a new dimension. Business associates handling reproductive-health PHI now have specific attestation requirements before disclosing that PHI for non-treatment purposes. BAAs signed before December 2024 that don't reflect those requirements are likely candidates for amendment as the rule beds in.

OCR's audit pilot, which paused in 2017, is widely expected to restart in some form during 2026. Covered entities and business associates with mature BAA programmes will navigate that smoothly; those with thin documentation will not.

BAAs in the international context#

HIPAA is a US federal statute and BAAs are a US construct, but the data flows it governs frequently cross borders. A US covered entity using a UK-based contact centre, a Canadian transcription service, or an EU-based cloud provider needs a BAA with each, regardless of where the vendor sits. HIPAA applies to the data, not the vendor's geography.

The wrinkle is that vendors outside the US sometimes resist signing BAAs because the document references US federal law and US-style indemnification. The pragmatic answer is that any vendor wanting US healthcare business has to sign US-style BAAs, and most established international vendors have a BAA template ready. Vendors that don't are usually new to the US healthcare market and need a procurement-side conversation rather than a regulatory one.

For European vendors, GDPR sits alongside HIPAA. The two regimes have overlapping but not identical requirements — GDPR's Article 28 processor agreements cover similar ground but with different specifics. A vendor handling PHI for a US covered entity from an EU base typically needs both a BAA (for HIPAA) and a data processing agreement (for GDPR). The two documents reference each other.

How to read a vendor's BAA in twenty minutes#

If you're on the buying side and a vendor has just sent you a BAA, here's a fast review pattern. It's not legal advice — it's a triage process to decide whether the document needs deeper legal review.

Start with the permitted-use clause. Is it tied specifically to the service the vendor will provide? If it says anything like "for purposes consistent with the business associate's services to similar clients" or "for product improvement", that's a flag. The clause should describe your service, not the vendor's whole product line.

Read the breach notification clause. Does it commit to a specific timeline? Is the timeline operationally realistic for the vendor's incident response capability? Does it cover security incidents as well as breaches? "Security incident" is broader than "breach" and should be reported separately — the BAA should reflect that.

Read the subcontractor clause. Does the vendor undertake to ensure subcontractors agree in writing to the same restrictions? Is there a list of current sub-processors, and a commitment to notify you of new ones? A BAA that's silent on subcontractors is signing you up to risk you can't see.

Read the termination clause. What triggers termination? What happens to PHI at termination? Is the return/destruction language realistic given the vendor's architecture? Does the BAA extend protections to retained PHI?

Read the indemnification clause and the limitation of liability. Are HIPAA-related claims carved out from the general liability cap? Is there cyber liability insurance backing the indemnity? At what level?

If any of those five reads turn up concerning language, that's where the legal review focuses. If all five look clean, the BAA is probably ready to sign — but never skip the read.

Next steps#

If you take phone-based card payments in a healthcare setting and you're working through your BAA programme, the document is part of the solution but not the whole solution. The architecture matters too — what data each vendor sees, where PHI and PCI collide, and how the recording is protected. We've helped clinics and healthcare contact centres put that architecture in place around our DTMF masking platform, signed BAAs as the payment processor in those stacks, and walked through the procurement questions with their HIPAA officers.

If you'd like to talk through your specific setup, get in touch. If you'd rather see the masked-payment flow live first, book a 15-minute demo and we'll show you a real call with PHI and PCI handled side by side. The wider pillar on HIPAA-compliant credit card processing covers the full picture if you're earlier in the research.