What Is a Business Associate Agreement (BAA)? HIPAA, Explained

A Business Associate Agreement is the written contract HIPAA requires before you let a vendor create, receive, maintain, or transmit protected health information on your behalf. Here is who needs one, when the law requires it, what it must contain, and where a signed agreement ends and your daily oversight begins.

What a BAA is — and the obligation behind it

A Business Associate Agreement (BAA) is a written contract between a HIPAA covered entity and a business associate — or between a business associate and its subcontractor — that governs how protected health information (PHI) may be used and protected. It is not a courtesy form or a box to tick. It is the mechanism HIPAA uses to extend its privacy and security obligations down a chain of vendors, so that everyone who handles a patient's information is contractually bound to safeguard it.

The legal hook is the requirement for "satisfactory assurances." Under the Privacy Rule at 45 CFR 164.502(e), a covered entity may disclose PHI to a business associate, and may let that business associate create, receive, maintain, or transmit PHI on its behalf, only if it first obtains satisfactory assurances that the vendor will appropriately safeguard the information. Critically, those assurances are not a handshake — the regulation requires them to be documented through a written contract or other written arrangement. The BAA is that document. Without it, the disclosure itself can be a violation, independent of whether any data is ever breached.

The Security Rule mirrors this for electronic PHI (ePHI). At 45 CFR 164.308(b), the business-associate-contracts standard says a covered entity may permit a business associate to create, receive, maintain, or transmit ePHI on its behalf only if it obtains the written assurances required by 45 CFR 164.314(a), which spells out the specific contract terms. Read together, these provisions mean the same thing in plain English: if an outside party is going to touch PHI on your behalf, you need a signed BAA in place before they start.

This article is general information, not legal, compliance, or audit advice, and it does not create any professional relationship. HIPAA's requirements are detailed and fact-specific, so confirm the current rules for your situation at hhs.gov and, where it matters, with a qualified professional.

Business associate vs. covered entity: who is who

HIPAA binds two kinds of organizations, and knowing which role you and your vendors play is the whole game. A covered entity is a health plan, a healthcare clearinghouse, or a health care provider who transmits health information electronically in connection with certain standard transactions — which, in practice, sweeps in almost every billing medical, dental, and behavioral-health practice, regardless of size. If you run the practice and hold the patient relationship, you are almost certainly the covered entity.

A business associate is a person or organization, other than a member of your workforce, that creates, receives, maintains, or transmits PHI to perform a function or service on your behalf. The defining phrase is "on behalf of." Your cloud-based EHR or practice-management vendor, your medical billing company, an IT provider with access to systems that store PHI, an outside coding or transcription service, a cloud backup or file-storage provider that holds PHI, a shredding company, an answering service that takes patient messages, and a third-party administrator are all classic business associates. So is a consultant, a lawyer, or an accountant if their work requires access to PHI.

The "on behalf of" test matters because not every vendor is a business associate. A janitorial service that empties bins but has no routine access to PHI is not one. Another health care provider you refer a patient to for treatment is acting for the patient, not on your behalf, so that disclosure is treatment — not a business-associate relationship. The question is always whether the outside party is performing a service for you that requires it to handle PHI. If yes, it is a business associate and you need a BAA. If it merely happens to be near PHI without a function that uses it, you generally do not.

One more wrinkle: business associates can themselves hire help. When a business associate passes PHI to a subcontractor to do part of the work, that subcontractor becomes a business associate too — and the chain of BAAs has to follow the data down.

When a BAA is legally required (164.502(e), 164.308(b), 164.314(a))

The trigger is simple to state: a BAA is required whenever a business associate will create, receive, maintain, or transmit PHI to perform a service or function on behalf of a covered entity (or on behalf of another business associate). Three regulatory provisions establish and shape that obligation.

45 CFR 164.502(e) is the Privacy Rule's foundation. It permits the disclosure of PHI to a business associate only on satisfactory written assurances, and it makes the same requirement flow to subcontractors. 45 CFR 164.308(b) is the Security Rule's parallel standard for electronic PHI, requiring a covered entity to obtain those written assurances before letting a business associate handle ePHI on its behalf. 45 CFR 164.314(a) is the organizational-requirements section that says what the written contract must actually contain — most notably that the business associate will comply with the applicable Security Rule requirements, will ensure that any subcontractors it uses agree to the same protections, and will report security incidents and breaches to the covered entity.

A practical point that trips up small practices: the obligation attaches to access and handling, not to whether the vendor ever actually looks at a record. If a service maintains or transmits PHI on your behalf — even encrypted PHI it cannot read — it is generally a business associate and needs a BAA. The Department of Health and Human Services has been explicit that cloud service providers storing or processing PHI are business associates even when they hold only encrypted data and lack the key, because they maintain persistent access to it.

There is no headcount or revenue floor here, just as there is none for HIPAA generally. A solo dentist using a cloud EHR, a two-person therapy practice using an online scheduling tool that stores patient details, and a small clinic outsourcing its billing all need BAAs with those vendors. The relationship — not your size — creates the requirement.

The conduit exception (and why "the cloud" usually isn't one)

The most misunderstood corner of BAA law is the conduit exception. HHS has long recognized a narrow carve-out for entities that merely transport information without accessing it other than on a random or infrequent basis — the way a postal or courier service moves a sealed envelope, or an internet service provider routes packets, without any role in storing or using the contents. The classic examples are the U.S. Postal Service, private couriers like UPS, and telecommunications and internet providers acting purely as data pipes. These conduits are not business associates, so no BAA is required with them.

The exception is genuinely narrow, and it is widely misread as covering far more than it does. The distinguishing line HHS draws is transient versus persistent access. A true conduit transports data and has only transient, incidental access to it. A vendor that stores PHI — even briefly, even encrypted, even without ever reading it — has persistent access and is a business associate, not a conduit. That is why cloud storage providers, backup services, and most SaaS tools that hold patient data do not qualify for the conduit exception, despite the intuitive appeal of calling them "just the pipes." If the data sits on the vendor's systems, the conduit exception almost never applies.

The practical mistake this causes is assuming a popular consumer service is exempt. A general-purpose email provider, a personal file-sharing account, or a free messaging app that stores PHI is not a conduit, and many such services will not sign a BAA at all — which is itself a signal that they are not an appropriate place for PHI. The safe operating rule is to treat any vendor that stores, processes, or has more-than-incidental access to PHI as a business associate and to get a BAA, rather than leaning on a conduit theory that rarely holds. When in doubt, confirm the current HHS guidance at hhs.gov and document your reasoning.

What must be in a BAA — plus the subcontractor chain

A compliant BAA is not boilerplate you can lift blindly; it has required substance. Drawing on 45 CFR 164.504(e) and 164.314(a), a BAA must, among other things, establish the permitted and required uses and disclosures of PHI by the business associate; prohibit uses or disclosures beyond what the contract and the law allow; require the business associate to use appropriate safeguards (and, for ePHI, to comply with the Security Rule); require it to report to the covered entity any use or disclosure not permitted by the contract, including security incidents and breaches of unsecured PHI; require it to make PHI available to satisfy individuals' access and amendment rights and to provide an accounting of disclosures; ensure that any subcontractors it engages agree to the same restrictions and conditions; and require it, at termination, to return or destroy the PHI where feasible. The Breach Notification Rule reinforces this at 45 CFR 164.410, which obligates a business associate to notify the covered entity following discovery of a breach of unsecured PHI.

The subcontractor chain is where many programs leak. Since the 2013 Omnibus Rule implemented the HITECH Act, a subcontractor that creates, receives, maintains, or transmits PHI on behalf of a business associate is itself a business associate, directly liable under HIPAA, and must have a BAA in place with the business associate above it. The duties flow downstream: your EHR vendor's data-center provider, its email subprocessor, or its offshore support contractor each needs a BAA with your vendor, even though you may never deal with them directly. Your BAA with your direct vendor should require it to bind its subcontractors to equivalent terms, and your vendor — not you — is responsible for papering those downstream agreements.

This is exactly where a documentation toolkit earns its keep. The ComplianceDocs HIPAA Compliance Toolkits (for medical, dental, and mental-health practices) include a Business Associate Management Policy alongside the rest of the Security and Privacy Rule policy set, giving you an editable starting point for how you identify business associates, get BAAs signed before sharing PHI, track them, and handle termination — so you are tailoring a structured framework rather than drafting from a blank page. To be clear about what that does and does not do: a template gives you the documentation layer HIPAA expects and removes the slowest part, drafting; it does not make your practice compliant on its own and confers no certification. You still have to actually execute the BAAs, maintain the inventory, and operate the controls.

Consequences of going without — and the practical steps

Operating without a required BAA is a HIPAA violation in its own right, separate from any breach. Disclosing PHI to a business associate without first obtaining the documented satisfactory assurances breaches 45 CFR 164.502(e) and 164.308(b), and HHS Office for Civil Rights (OCR) has repeatedly resolved enforcement matters where a missing or never-executed BAA was the central failing — sometimes after a breach exposed the gap, sometimes on its own. Civil monetary penalties under HIPAA are tiered by culpability and can be substantial, and many enforcement actions also impose multi-year corrective action plans. The exact penalty amounts and tiers are set by regulation and adjusted over time, so treat any specific figure you see as something to confirm at hhs.gov rather than rely on from memory; the dependable takeaway is that a missing BAA is a discrete, enforceable, and avoidable violation.

The practical program is straightforward to describe and worth doing deliberately. First, inventory every outside party that creates, receives, maintains, or transmits PHI on your behalf — EHR, billing, IT, cloud storage and backup, email, scheduling, transcription, shredding, answering service, and any consultant or professional with PHI access. Second, for each one, get a signed BAA in place before sharing PHI; if a vendor will not sign a BAA, treat that as a reason not to put PHI there. Third, keep a living register of your BAAs with renewal and termination tracking, and revisit it when you add tools or switch vendors. Fourth, confirm your BAA obligates the vendor to bind its own subcontractors. Fifth, define how breaches get reported up to you and what happens to PHI when an engagement ends.

The honest division of labor is the same here as everywhere in HIPAA. Documentation — a Business Associate Management Policy, a BAA template, and a vendor register — is the fastest part to get right and the part that stalls practices longest when they start from scratch. But the BAA only protects you once it is actually executed, the inventory is actually maintained, and the relationship is actually overseen. There is no certificate at the end of this, and OCR enforces on whether the agreements and oversight genuinely exist. Get the paperwork done quickly so your limited time goes to the operating work that actually protects patient information, and confirm the current rules at hhs.gov and with a qualified professional for your specific situation.

Frequently asked questions

What is a Business Associate Agreement (BAA) in simple terms?

A BAA is a written contract that HIPAA requires before a covered entity (like a medical, dental, or therapy practice) lets an outside vendor create, receive, maintain, or transmit protected health information on its behalf. In the contract, the vendor — the "business associate" — agrees to safeguard the information, use it only as permitted, report breaches, and bind its own subcontractors to the same protections. The legal basis is the requirement for documented "satisfactory assurances" under 45 CFR 164.502(e) and the Security Rule at 164.308(b) and 164.314(a). Without a signed BAA, sharing PHI with that vendor can itself be a violation, even if no data is ever breached.

When is a BAA legally required under HIPAA?

A BAA is required whenever a business associate will create, receive, maintain, or transmit PHI to perform a service or function on behalf of a covered entity — or on behalf of another business associate. The requirement comes from 45 CFR 164.502(e) (Privacy Rule), 164.308(b) (Security Rule), and 164.314(a), which set out the written contract terms. It is triggered by access and handling, not by whether the vendor ever reads the data, so even a cloud service holding only encrypted PHI generally needs a BAA. There is no practice-size exemption: a solo provider using a cloud EHR needs one just as a large clinic does.

What is the conduit exception, and does my cloud storage qualify?

The conduit exception is a narrow HHS carve-out for entities that merely transport PHI without accessing it other than on a random or infrequent basis — think the U.S. Postal Service, couriers, and internet service providers acting purely as data pipes. These conduits are not business associates and need no BAA. The dividing line is transient versus persistent access: a vendor that stores PHI — even briefly, even encrypted — has persistent access and is a business associate, not a conduit. That is why cloud storage, backup, and most SaaS tools that hold patient data do not qualify, despite the intuitive appeal of calling them "just the pipes," so you should get a BAA with them.

Do subcontractors need their own BAAs?

Yes. Since the 2013 Omnibus Rule implemented the HITECH Act, a subcontractor that creates, receives, maintains, or transmits PHI on behalf of a business associate is itself a business associate, directly liable under HIPAA. It must have a BAA in place with the business associate above it, and the obligations flow all the way down the chain. As the covered entity, you generally contract only with your direct vendor, but your BAA should require that vendor to bind its subcontractors to equivalent terms — papering those downstream agreements is the vendor's responsibility, not yours.

What happens if I don't have a BAA in place?

Operating without a required BAA is a HIPAA violation on its own, separate from any data breach — disclosing PHI to a business associate without documented satisfactory assurances breaches 45 CFR 164.502(e) and 164.308(b). HHS Office for Civil Rights has repeatedly resolved enforcement matters where a missing or never-executed BAA was the central failing, sometimes on its own and sometimes after a breach exposed the gap, often with civil monetary penalties and multi-year corrective action plans. The specific penalty amounts are set by regulation and adjusted over time, so confirm current figures at hhs.gov; the reliable point is that a missing BAA is a discrete, enforceable, and entirely avoidable violation. The fix is to inventory every vendor that touches PHI and get a signed BAA in place before sharing any.

Related guides: HIPAA

Toolkits that help

← All articles