When Is a HIPAA Business Associate Agreement Required, and When Is It Not?
A Business Associate Agreement (BAA) is not a “nice to have” contract, and it is not something you sign just because a vendor asks for it. Under HIPAA, a BAA is required in specific situations: when a person or company is acting as your business associate because they create, receive, maintain, or transmit protected health information (PHI) on your behalf while performing certain functions or services for you.
Clinics get this wrong in both directions. Some sign BAAs with vendors that are not business associates, which creates busywork and false confidence. Others fail to sign BAAs where HIPAA expects one, most commonly with IT support, cloud services, and communications tooling. The correct approach is to classify the relationship first, then apply the BAA requirement based on that classification.
Informational note: This article is for informational purposes only and does not constitute legal advice.
The definitions that determine whether you need a BAA
HIPAA’s definition of a “business associate” is functional, not marketing-driven. A business associate is generally a person or entity, other than your workforce, that performs certain functions or activities on behalf of a covered entity (or provides certain services to it) where the service involves the use or disclosure of PHI. The definition explicitly includes entities that “maintain” PHI, not just entities that view it.
HIPAA also draws a clean boundary between a business associate and your workforce. Workforce includes employees, volunteers, trainees, and other persons whose conduct, in the performance of work for you, is under your direct control, whether or not they are paid. Workforce members are not business associates.
Finally, HIPAA recognizes that a covered entity can be a business associate of another covered entity in certain arrangements. The label on the organization (clinic, plan, hospital) does not decide the relationship. The function and the PHI handling do.
The core test: “on behalf of you” versus “for their own purposes”
The fastest way to decide whether a BAA is required is to ask a single question and answer it honestly:
Is the vendor handling PHI in order to perform a service for your clinic, on your behalf?
If yes, you are usually in business associate territory.
If no, a BAA may not be required, even if the vendor is in healthcare, even if the vendor sometimes sees PHI incidentally, or even if PHI passes through the vendor in a transient way.
This “on your behalf” idea is why BAAs show up in routine clinic vendor stacks. When you hire a billing service, IT managed service provider, cloud storage provider that hosts your PHI, or a patient communications vendor that routes PHI-laden messages, those vendors are performing a function for you that involves PHI. That is the classic HIPAA business associate pattern.
When a BAA is required
The baseline HIPAA rule
HIPAA generally requires covered entities to obtain “satisfactory assurances” in writing that a business associate will appropriately safeguard PHI. In practice, this is the BAA. The Privacy Rule ties this to business associate arrangements, and the regulation spells out the contract requirements.
A simple operational translation is: if a vendor is your business associate, you should not allow PHI to flow to that vendor until the BAA is executed.
Common clinic scenarios that usually require a BAA
Rather than memorizing a long vendor list, focus on the patterns that make a vendor a business associate:
A vendor is very likely a business associate when they host, store, process, or back up PHI for you. This includes many cloud service providers. HHS has been explicit that cloud providers are business associates when they create, receive, maintain, or transmit ePHI on behalf of a covered entity or another business associate, even if they cannot actually view the ePHI because it is encrypted and they do not have the decryption key. “No-view” does not equal “not a business associate.”
A vendor is very likely a business associate when they provide operational services to you where PHI is part of the work product, such as claims processing, billing, utilization review, quality assurance, practice management support, data aggregation, accounting, legal services involving PHI, or administrative services that require PHI. This is baked into the regulatory definition.
A vendor is very likely a business associate when they provide IT services that require access to systems containing PHI, even if their stated purpose is “technical support.” HHS gives a concrete example: a software company that hosts software containing patient information on its own server, or accesses patient information when troubleshooting, is a business associate and the covered entity must enter into a BAA before allowing access.
Subcontractors, the part clinics forget
Business associate obligations do not stop at your direct vendor. If your business associate uses a subcontractor that creates, receives, maintains, or transmits PHI on the business associate’s behalf, that subcontractor is also in scope. HIPAA expects the business associate to ensure subcontractors agree to the same restrictions and conditions that apply to the business associate. The HHS sample BAA provisions call this out explicitly, and the regulatory definition includes subcontractors in the business associate definition.
This matters for small clinics because you often do not see the downstream chain. A clinic signs a contract with Vendor A, Vendor A uses Vendor B for hosting or support, and suddenly PHI is present in places the clinic never mapped. You do not need to micromanage every subcontractor, but you do need a vendor governance posture that acknowledges subcontractors exist and that contractual flow-down is part of HIPAA’s structure.
When a BAA is not required
The most useful way to understand “not required” is to look at the specific exceptions and clarifications HHS has published.
1) Workforce members under your direct control
If a person’s conduct in performing work for you is under your direct control, you may be able to treat them as workforce rather than as a business associate, even if they are not a traditional employee. HHS explicitly notes that when an employee of a contractor, such as a software or IT vendor, has their primary duty station on-site at a covered entity, the covered entity may choose to treat that individual as a member of the covered entity’s workforce rather than as a business associate, referencing the workforce definition.
This option is frequently misunderstood. Treating someone as workforce is not just a label. It implies you have direct control over how they perform the work, and you have integrated them into your policies, training, and supervision.
2) Disclosures to another healthcare provider for treatment
The Privacy Rule does not require a business associate contract for disclosures by a covered entity to a healthcare provider for treatment of the individual. This is one of the most important “do not over-lawyer this” rules in clinic operations. If you disclose PHI to another provider for treatment, that provider is not your business associate just because they received PHI.
This is why referrals and care coordination typically do not require BAAs between providers. The disclosure is occurring for treatment, not because the receiving provider is performing a service on your behalf.
3) Mere conduits, limited and narrow
HHS has an explicit conduit concept. The Privacy Rule does not require BAAs with organizations such as the U.S. Postal Service, certain private couriers, and their electronic equivalents that act merely as conduits for PHI. A conduit transports information but does not access it other than on a random or infrequent basis as necessary to perform the transportation service or as required by law.
Clinics often misapply this by trying to treat storage vendors as conduits. HHS’s cloud computing guidance is explicit that cloud service providers that maintain ePHI for storage are business associates, not conduits, because their access is more persistent.
4) Incidental contact with PHI
A business associate contract is not required when a person or organization’s functions, activities, or services do not involve the use or disclosure of PHI, and any access to PHI would be incidental, if at all. HHS uses the example of services where inadvertent contact may occur, such as janitorial services.
The practical idea here is that HIPAA is not trying to force BAAs with every entity that could theoretically see a stray page. It is focused on entities that are involved in PHI handling as part of the service they are providing.
5) Software vendors that do not access PHI
HHS is direct on this point: merely selling or providing software does not create a business associate relationship if the vendor does not have access to the PHI of the covered entity. If the vendor does need access to PHI to provide its service, for example hosting the data or troubleshooting in a way that touches patient information, then the vendor is a business associate.
This is a high-signal clarification for small clinics. “We bought a software product” does not automatically mean “we need a BAA.” “The vendor hosts our patient data” often does.
What a BAA must actually contain
A BAA is not just an NDA with the word HIPAA in it. HIPAA specifies what the contract must do. At a high level, a compliant BAA must:
Define permitted and required uses and disclosures of PHI by the business associate, and prohibit uses and disclosures not authorized by the contract or required by law.
Require appropriate safeguards, including Security Rule safeguards for ePHI.
Require reporting of impermissible uses or disclosures, including breach reporting obligations.
Require the business associate to support the covered entity in meeting certain individual rights obligations (access, amendment, accounting) as applicable to the services.
Require flow-down restrictions to subcontractors.
Address return or destruction of PHI at termination where feasible, and allow termination for material breach.
HHS publishes sample business associate agreement provisions that track these required elements and are aligned to the regulation.
A key compliance point that clinics sometimes miss is that a BAA does not magically make an unsafe vendor safe. It is a necessary contractual control. It is not a substitute for vendor due diligence, access controls, and a documented security risk analysis.
A practical classification method clinics can actually run
You do not need to classify vendors with legal jargon. You need a repeatable method that produces consistent results. Here is a defensible approach that works well for small clinics:
First, map where PHI flows. This is the foundation. If you cannot name the systems and workflows where PHI is created, stored, or transmitted, you will miss BAAs you need.
Second, classify each vendor relationship by function. Ask whether the vendor is performing a function for you that involves PHI, or whether PHI only passes through transiently or incidentally.
Third, use the narrow exceptions intentionally. Treatment disclosures to another provider generally do not require BAAs. Conduits are limited to transmission-only services with only transient access. Incidental contact vendors are not business associates.
Fourth, require the BAA before PHI is shared, and ensure the contract includes the required HIPAA elements. If the vendor refuses to sign a BAA when their service involves PHI handling, the compliance answer is not “sign up anyway and hope for the best.” The answer is to choose a different vendor or redesign the workflow so PHI does not flow through that service.
This is one place where tooling helps. Clinics commonly lose track of BAAs because the documents live in someone’s email thread or a folder no one owns. A platform like Timber can keep your vendor inventory, BAA status, and renewal review tasks in one place, which reduces the odds of vendor sprawl turning into unmanaged PHI exposure.
Sources
HHS OCR: Business Associates guidance (overview, examples, and BAA requirement)
https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html
HHS OCR: Sample Business Associate Agreement Provisions (what a BAA must include)
https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html
45 CFR § 160.103 (definitions, including business associate and workforce)
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103
45 CFR § 164.502 (business associate standard, permitted uses and disclosures, BAA reference)
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502
45 CFR § 164.504(e) (business associate contract requirements)
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.504
HHS OCR FAQ: Conduit exception (USPS, couriers, and “mere conduit” definition)
https://www.hhs.gov/hipaa/for-professionals/faq/245/are-entities-business-associates/index.html
HHS OCR FAQ: Incidental contact does not require a BAA (janitorial-type example)
https://www.hhs.gov/hipaa/for-professionals/faq/243/is-a-business-associate-contract-required-for-inadvertent-contact-with-phi/index.html
HHS OCR FAQ: Software vendor is not a BA unless it accesses PHI; hosting or troubleshooting access makes it a BA; on-site contractor may be treated as workforce
https://www.hhs.gov/hipaa/for-professionals/faq/256/is-software-vendor-business-associate/index.html
HHS OCR: Guidance on HIPAA and Cloud Computing (CSPs are BAs even for “no-view” encrypted storage; CSPs generally not conduits)
https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html
HHS OCR FAQ: Using a cloud service to store or process ePHI requires a HIPAA-compliant BAA with the CSP
https://www.hhs.gov/hipaa/for-professionals/faq/2075/may-a-hipaa-covered-entity-or-business-associate-use-cloud-service-to-store-or-process-ephi/index.html