What a Business Associate Agreement Must Cover Under HIPAA

August 21, 2026

A Business Associate Agreement is a required, written HIPAA contract whenever a vendor creates, receives, maintains, or transmits protected health information on a covered entity’s behalf. The controlling rule is 45 CFR §164.504(e), and it’s not optional paperwork. If your billing company, cloud host, or IT contractor touches PHI and you don’t have a signed BAA in place, you’re already out of compliance, whether or not a breach has ever happened.

Every compliant BAA needs to nail down the same core terms:

Permitted uses and disclosures of PHI, narrowly defined to what the vendor actually needs to do its job
Required safeguards, including the administrative, physical, and technical protections spelled out in the Security Rule
Breach reporting obligations, with a defined timeline for notifying the covered entity
Subcontractor flow-down, meaning any vendor the business associate hires must sign the same protections
Return or destruction of PHI when the contract ends, unless it isn’t feasible to do so

HHS publishes sample BAA provisions that map directly to these requirements. Building your agreement off that government template is the safest starting point, and it’s what most compliance attorneys recommend before adding organization-specific language.

Table of Contents

Key Takeaways

A compliant Business Associate Agreement requires specific written provisions under 45 CFR §164.504(e), and missing any one of them creates direct liability exposure for both the covered entity and the business associate.

Point	Details
BAA is legally mandatory	Any vendor that creates, receives, maintains, or transmits PHI needs a signed agreement before access begins.
Six required elements	Permitted uses, safeguards, breach reporting, subcontractor flow-down, return/destruction, and HHS access must all appear.
Subcontractors need their own BAAs	Flow-down obligations mean liability can reach the covered entity if a subcontractor never signed.
Cloud vendors are usually business associates	Persistent storage of ePHI generally defeats the conduit exception, even with strong encryption claims.
BAAs are not NDAs	An NDA protects business confidentiality; only a BAA satisfies HIPAA’s mandatory contract elements.
Verification matters as much as signing	tekrescue reviews vendor BAAs and tests actual safeguards against contract language for healthcare clients in Central Texas.

Primary Sources and Official Templates

For internal compliance records or audit preparation, cite these directly rather than secondhand summaries:

Reference the specific section number, not just “HIPAA,” when documenting compliance decisions. Auditors and legal counsel move faster when your records point to the exact regulatory text you relied on.

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.

What Is a Business Associate Agreement and Who Needs One?
What Legal Authority Requires a Business Associate Agreement?
What Provisions Must a BAA Include?
How Do Subcontractors Fit Into a Business Associate Agreement?
What Should a BAA Require From Cloud Providers?
How Do You Get a BAA Signed and Managed?
What Mistakes Trigger OCR Enforcement Around BAAs?
Is a BAA the Same as an NDA or a Data Use Agreement?
Why Most BAA Reviews Miss the Real Risk
Get Help Reviewing Your Vendor Agreements
Sources
FAQ

What Is a Business Associate Agreement and Who Needs One?

A HIPAA Business Associate Agreement is a written contract that binds a vendor to the same privacy and security obligations that apply to the covered entity it works for. The regulatory test is simple to state and often messy to apply: does the vendor create, receive, maintain, or transmit PHI on behalf of a covered entity? If the answer is yes, a BAA isn’t a nice-to-have. It’s required before that vendor touches a single patient record.

Covered entities include doctors, hospitals, dentists, pharmacies, health plans, and healthcare clearinghouses. But the business associate side of that relationship is much broader than most administrators expect, and that’s where compliance gaps usually open up.

Common vendors that need a signed BAA include:

Medical billing and coding companies
Cloud storage and backup providers
Medical transcription services
Payment processors handling healthcare claims
Managed IT support providers with access to systems containing PHI
Document shredding and destruction companies
Answering services and appointment scheduling platforms

There’s a narrow exception for “conduits,” entities like the U.S. Postal Service or an internet service provider that merely transports data without accessing its content in any meaningful way. But that exception gets misapplied constantly. Cloud storage and email hosting are routinely mistaken for conduits when they’re actually business associates, because they store PHI persistently rather than just passing it through, according to Washington University’s HIPAA compliance resources. If a vendor could technically open a file and read PHI, or if PHI sits on their servers for any length of time, the conduit exception almost certainly doesn’t apply.

One wrinkle that trips up a lot of practices: a covered entity can also act as a business associate to another covered entity. A hospital that provides billing services to an independent physician group, for example, needs a BAA covering that specific relationship, separate from its own compliance obligations as a covered entity.

Pro Tip: When a vendor relationship feels ambiguous, ask one question: could this vendor function without ever accessing PHI? If the honest answer is no, sign a BAA before granting access, not after you’ve already handed over a patient database “just to get started.”

What Legal Authority Requires a Business Associate Agreement?

The BAA requirement isn’t a best practice invented by compliance consultants. It’s federal law, built on a specific stack of regulations and enforcement actions that have gotten sharper over the past decade.

The foundational citation is 45 CFR §164.504(e), which requires the written contract and lists its mandatory elements. That section works alongside several related provisions:

§164.502, which governs uses and disclosures of PHI generally and establishes the baseline that business associates must follow
§164.308, the Security Rule’s administrative safeguards section, which shapes what a BAA must require of a vendor’s internal security program
§164.410, which sets breach notification timing and content requirements that BAAs need to mirror
§164.314, the Security Rule’s organizational requirements, which mandate that business associate contracts include specific implementation language for safeguards and incident reporting

The HITECH Act changed the stakes significantly. Before 2009, business associates were mostly insulated from direct federal enforcement. HITECH and OCR’s 2013 final rule made business associates directly liable to the Office for Civil Rights for certain violations, including failure to enter into required subcontractor BAAs and failure to report breaches. That’s a meaningful shift: a vendor can no longer treat HIPAA as “the covered entity’s problem.” OCR can now come after the vendor directly.

More recently, CMS guidance letter GL-2022-03 clarified something covered entities often overlook: they must require business associates to comply with Administrative Simplification requirements, including transaction and operating rule standards, and a covered entity can be held responsible when a business associate fails to meet those obligations. In other words, signing the BAA and forgetting about it doesn’t protect you. The guidance ties the covered entity’s own compliance standing to how well its vendors actually perform.

For anyone drafting internal compliance policy or preparing for an audit, citing these sections directly (rather than paraphrasing them from a blog post) carries real weight with auditors and legal counsel alike.

What Provisions Must a BAA Include?

Every BAA needs to translate the regulatory language of §164.504(e) into contract clauses a vendor can actually follow. Here’s how the required elements map to real contract language, with short annotated snippets you can adapt.

Diagram of required BAA provisions

Permitted uses and disclosures. This clause defines exactly what the business associate can do with PHI, and it should be narrow.

That single sentence does a lot of work. It closes off any use the contract doesn’t explicitly authorize, which protects the covered entity if the vendor later tries to repurpose data for something like marketing analytics or product development.

Safeguards. The BAA must require the business associate to implement administrative, physical, and technical safeguards consistent with the Security Rule.

Breach reporting. This is where vague language causes the most damage later. Don’t just require “prompt” notification. Define an actual number of days.

Access and amendment support. The vendor must help the covered entity respond to patient requests for access or amendment of their records, since the covered entity remains responsible for those obligations under the Privacy Rule.

HHS access. The contract must let federal regulators inspect the business associate’s records related to PHI handling.

Return or destruction. At termination, PHI must be returned or destroyed if feasible, per the HHS sample provisions. If destruction isn’t feasible, the agreement must explain how protections continue to apply to any PHI retained.

Subcontractor flow-down. Any subcontractor the business associate engages must agree, in writing, to the same restrictions and conditions.

Termination for material breach. The covered entity needs the right to terminate the agreement if the business associate violates a material term and fails to cure it within a reasonable period.

The drafting judgment call that trips people up most is how narrowly to define “permitted uses.” Too broad, and you’ve handed the vendor a blank check. Too narrow, and you accidentally prohibit routine functions the vendor needs to perform its actual job, like using aggregate data for its own management and administrative functions, which HIPAA does allow under specific conditions.

Pro Tip: Set breach notification timelines in business days, not calendar days, and specify what counts as “discovery.” Vague timing language is one of the most common reasons covered entities miss the 60-day breach notification deadline that applies to affected individuals, because the clock started running at the vendor long before anyone told the covered entity.

How Do Subcontractors Fit Into a Business Associate Agreement?

A business associate can’t quietly hand PHI to a subcontractor and skip the paperwork. The flow-down requirement means every 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 original business associate.

Hands wiring network cables representing subcontractor compliance

Picture the chain this way: covered entity signs a BAA with a billing company (the business associate). That billing company outsources data entry to an overseas processing firm (the subcontractor). The subcontractor now needs its own BAA with the billing company, carrying forward the exact same protections. If that link is missing, the whole chain is exposed, and CMS guidance makes clear the covered entity can still be held responsible for that gap, even though it never directly contracted with the subcontractor.

Before signing off on a vendor, run through a short vetting checklist:

Does the vendor’s own contract require subcontractor BAAs, in writing, before data access begins?
Has the vendor provided a list of subcontractors who touch PHI, and are those relationships current?
Does the vendor’s security assessment cover its subcontractors, or only its own systems?
Is there a contractual right to audit subcontractor compliance, not just the primary vendor’s?

Pro Tip: Ask every vendor for a current subcontractor list during procurement, not after a breach. Vendors change subprocessors more often than covered entities realize, and a BAA signed two years ago may no longer reflect who’s actually touching your patients’ data today.

What Should a BAA Require From Cloud Providers?

Cloud hosting is where the conduit exception gets misapplied most often, and it’s also where technical safeguards matter more than legal language. A cloud service provider storing or processing ePHI is a business associate, full stop, unless it truly never accesses content and never retains data beyond momentary transit. Persistent storage, even encrypted storage the provider claims it “can’t read,” generally puts a CSP squarely in business associate territory.

Once you’ve established that a BAA is required, the real work is making sure the contract reflects how the technology actually behaves. Push for specific language on:

Encryption at rest and in transit, not just a general reference to “industry standard” protections
Key management, including who controls encryption keys and whether the provider can access unencrypted data
Access control and logging, so you can verify who touched PHI and when
Backup and retention policies, including how long backups persist after a deletion request
Destruction feasibility, since cloud environments often replicate data across multiple regions in ways that make true destruction harder than it sounds

A SOC 2 report or similar security attestation is useful evidence of a vendor’s controls, but it doesn’t replace a BAA and it doesn’t guarantee HIPAA compliance. Those reports typically cover a defined scope and time period chosen by the vendor. They tell you the vendor passed an audit against criteria it selected, not that every clause required by §164.314 is actually in your contract. A well-run cloud computing setup still needs the BAA doing the legal work that a security certificate can’t.

Pro Tip: Request explicit backup retention language before signing. “We delete data upon request” means very little if the provider’s automated backups retain a copy for 90 days regardless of that request, and most vendor sales teams won’t volunteer that detail unless you ask directly.

How Do You Get a BAA Signed and Managed?

Getting a compliant BAA in place is a process, not a form you fill out once. Here’s the order that actually works for most practices and vendors:

Map every PHI flow. List every vendor, system, and contractor that touches patient data, even indirectly.
Identify which relationships require a BAA. Apply the creates/receives/maintains/transmits test to each vendor on that list.
Select a starting template. Begin with the HHS sample provisions rather than a generic contract template pulled from a search engine.
Negotiate permitted uses and safeguards. This is where covered entity and vendor priorities often collide, and where legal review earns its cost.
Confirm safeguards match actual practice. Don’t take a vendor’s word that encryption and access controls are in place. Ask for documentation.
Sign and date the agreement, keeping an executed copy accessible for audit purposes.
Document the relationship in a central vendor registry that tracks contract dates, renewal terms, and subcontractor lists.

Realistically, expect the process to take a few weeks for a straightforward vendor with a cooperative legal team, and several weeks for a larger vendor with its own standard contract language it wants to negotiate from.

Watch for red flags in vendor-proposed language: broad “may use PHI for any lawful business purpose” clauses, breach notification windows longer than a few days, or missing subcontractor flow-down language entirely. During procurement, ask vendors directly:

Who are your current subcontractors with PHI access?
What’s your breach notification timeline, in writing?
Can you provide evidence of encryption at rest and in transit?
Will you sign the covered entity’s BAA language, or only your own?

What Mistakes Trigger OCR Enforcement Around BAAs?

Most BAA-related enforcement doesn’t come from some dramatic hack. It comes from paperwork gaps that existed long before any breach occurred. The recurring failures OCR and CMS guidance point to include:

Missing or expired BAAs with active vendors
No subcontractor BAAs, even when the primary business associate has one
Breach reporting language so vague it doesn’t specify a real timeline
Permitted-use clauses broad enough to allow uses HIPAA never intended
Failure to terminate the relationship after a documented material breach

The HITECH direct liability rule means OCR can act against the business associate directly for several of these, not just the covered entity. That changes the incentive structure for vendors, and it should change how covered entities vet them.

Pro Tip: Keep a compliance file for every vendor relationship containing the signed BAA, the most recent security assessment, and a subcontractor list, updated at least annually. When an audit or investigation happens, the organizations that produce this file in an afternoon fare very differently than the ones scrambling to reconstruct it from memory.

Where to Find Official Sample BAA Language

The safest source for BAA language is the HHS sample provisions themselves, because that language was written specifically to satisfy §164.504(e). Using it as your starting point, rather than a generic contract template, means you’re not guessing at what regulators expect.

That’s the flow-down principle stated in HHS’s own language, and it’s worth quoting directly rather than paraphrasing when you’re briefing legal counsel or a vendor’s procurement team.

Vendors commonly redline a few specific clauses:

Liability caps. Vendors often want to limit damages; covered entities should push back when a cap would undercut the vendor’s incentive to maintain safeguards.
Broadened permitted uses. Watch for language letting the vendor use “de-identified data” without defining de-identification to HIPAA’s actual standard.
Shortened record retention for audits. Some vendors propose short document retention windows that would make an OCR audit difficult to support.

Is a BAA the Same as an NDA or a Data Use Agreement?

No, and treating them as interchangeable is one of the more expensive mistakes covered entities make. A Non-Disclosure Agreement protects general confidential business information, like trade secrets or financial terms, but it doesn’t include any of the specific HIPAA-mandated provisions, breach reporting duties, or subcontractor flow-down language a BAA requires. Signing an NDA with a vendor who handles PHI, and stopping there, leaves you without a compliant contract.

A Data Use Agreement serves a narrower purpose: it governs the use of a limited data set for research, public health, or healthcare operations, under separate provisions from the standard BAA framework. A DUA doesn’t replace a BAA when the vendor relationship involves full PHI access, only when a specifically defined limited data set is being shared.

In practice, many vendor relationships call for both an NDA and a BAA. An NDA might cover confidential pricing or proprietary business terms in the contract, while the BAA separately governs PHI handling. If you combine documents into a single master agreement, make sure every HIPAA-required clause from §164.504(e) survives the merge. It’s easy to draft a hybrid agreement that reads well but quietly drops a required element, like the subcontractor flow-down clause, because it got absorbed into general “confidentiality” language that doesn’t meet the regulatory bar.

Why Most BAA Reviews Miss the Real Risk

The conventional advice on BAAs treats them like a signature exercise: get the document signed, file it away, move on. That’s backwards. The contract language matters, but the bigger risk almost always lives in the gap between what the BAA says and what the vendor actually does day to day.

I’ve seen the pattern play out the same way across different practices. A covered entity signs a technically compliant BAA, checks the box, and never asks the follow-up questions: Does this vendor actually encrypt data at rest the way the contract claims? Does its subcontractor list match what was disclosed at signing? Has anyone reviewed the vendor’s security posture since the agreement was executed eighteen months ago? A signed BAA with no ongoing verification is a legal document, not a security program.

The organizations that handle this well treat the BAA as the starting point of an ongoing relationship, not the finish line. That means periodic check-ins on vendor safeguards, a real subcontractor registry, and someone internally responsible for tracking renewal dates and material changes to how a vendor operates. Managed IT providers who work in regulated environments tend to build this verification into their standard engagement, because they’ve seen what happens when it’s skipped: the breach investigation reveals a BAA that was technically compliant on paper and completely divorced from what was happening on the vendor’s servers.

Get Help Reviewing Your Vendor Agreements

Drafting a compliant BAA is only half the job. The harder half is confirming the vendor’s actual practices, encryption, access controls, subcontractor management, match what the contract promises. tekrescue works with healthcare providers and business associates across the Austin, San Marcos, New Braunfels, and Kyle area to review vendor agreements, assess whether current safeguards hold up against Security Rule requirements, and flag gaps before an auditor or a breach finds them first.

That review typically starts with mapping your PHI flows and existing vendor contracts, then testing the technical controls those contracts claim to require, encryption status, access logging, backup retention, against what’s actually configured. If your practice hasn’t had its vendor BAAs reviewed in the last year, or you’re bringing on a new billing or cloud provider, that’s the moment to get a second set of eyes on the paperwork and the systems behind it. Reach out to tekrescue’s managed IT services team to schedule a vendor compliance review and get a clear picture of where your BAAs stand.

Sources

FAQ

Who requires a business associate agreement?

Any covered entity, a healthcare provider, health plan, or clearinghouse, must have a signed BAA with any vendor that creates, receives, maintains, or transmits PHI on its behalf, as required by 45 CFR §164.504(e).

Can you provide an example of a business associate agreement?

Yes. HHS publishes official sample BAA provisions covering permitted uses, safeguards, breach reporting, subcontractor obligations, and termination language that organizations can adapt directly.

What is the difference between a business associate agreement and an NDA?

An NDA protects general confidential business information but contains none of HIPAA’s mandatory provisions. A BAA is legally required whenever PHI is involved and must include specific clauses like breach reporting and subcontractor flow-down that an NDA never covers.

How do I get a business associate agreement in place?

Start by mapping which vendors touch PHI, then use the HHS sample provisions as your contract template, negotiate permitted uses and safeguards with the vendor, and get it signed before any data access begins. A managed IT partner familiar with HIPAA-focused vendor reviews can help confirm the vendor’s actual safeguards match what the contract requires.