If your company touches patient data in any way, whether you're building a healthcare app, providing cloud infrastructure, or managing EHR integrations, you've probably been asked to sign a BAA. But understanding who needs a business associate agreement isn't always straightforward, and getting it wrong can cost you millions in HIPAA penalties.

The answer goes beyond just hospitals and insurance companies. HIPAA's BAA requirements extend to a wide chain of organizations: covered entities, business associates, and even subcontractors who handle protected health information (PHI) on their behalf. Every link in that chain carries legal obligations, and a missing or incomplete BAA creates exposure for everyone involved. If you're a healthcare innovator connecting to EHRs or processing patient records, this applies directly to you, and to every vendor in your integration stack.

At SoFaaS, we operate squarely in this space. Our platform enables healthcare applications to connect with EHR systems like Epic, Cerner, and Allscripts through SMART on FHIR, which means we handle PHI as part of the integration process. We maintain HIPAA-compliant infrastructure and SOC 2 Type II certification because BAA obligations aren't optional for platforms like ours, they're foundational. That firsthand experience is exactly why we built this guide.

This article breaks down which parties are required to enter into a BAA, what triggers that requirement, how subcontractors fit into the picture, and what happens when organizations skip this critical step.

What a business associate agreement is and does

A business associate agreement (BAA) is a legally binding contract required by HIPAA between a covered entity and any outside party that accesses, uses, or discloses protected health information (PHI) on that entity's behalf. It is the formal mechanism that assigns data protection responsibilities to every organization that touches patient records as part of delivering a service. Without this contract in place, both parties operate outside federal law, regardless of how careful they are with the data in practice.

The legal definition of a BAA

Under 45 CFR §164.504(e), the HIPAA Privacy Rule requires covered entities to obtain satisfactory assurances from business associates that PHI will be appropriately protected. The regulation defines exactly what that assurance must look like in contract form. A BAA is not a general privacy policy or a terms-of-service addendum. It is a specific, federally mandated instrument with defined provisions that both parties must honor.

The term "business associate" carries a specific legal meaning under HIPAA. Any vendor, contractor, or service provider that creates, receives, maintains, or transmits PHI while performing functions for a covered entity meets the definition. This is precisely where understanding who needs a business associate agreement becomes critical, because the category is far broader than most organizations initially assume.

What a BAA requires each party to do

A BAA places concrete obligations on the business associate. That party must use PHI only for the purposes specified in the agreement, implement appropriate administrative, physical, and technical safeguards, report any breaches or security incidents to the covered entity, and ensure that any subcontractors it engages are bound by the same standards. These are not aspirational commitments. They carry direct legal weight and enforcement consequences under HIPAA.

A BAA does not transfer liability away from the covered entity. It distributes responsibility across every party that handles PHI, making each one independently accountable under HIPAA.

Your organization also takes on obligations as the covered entity. You must monitor whether your business associates comply with the agreement terms, and if a violation occurs, you are required to take reasonable steps to correct it or terminate the relationship. Signing a BAA is not the final step in your compliance work. It is the beginning of an ongoing oversight responsibility that continues for the life of the vendor relationship.

How a BAA differs from a standard NDA or privacy policy

Many organizations confuse a BAA with a non-disclosure agreement (NDA) or a general data privacy policy. An NDA protects confidential business information broadly, while a privacy policy describes how an organization handles data for its users or customers. A BAA is narrower and more specific. It governs PHI exclusively, under federal law, with mandatory provisions defined by the Department of Health and Human Services that cannot be negotiated away or substituted with a different document type.

If a vendor sends you a generic NDA and describes it as sufficient for HIPAA compliance, treat that as a serious warning sign. HIPAA requires specific language covering permitted uses of PHI, breach notification timelines, the patient's right to access their records, and the return or destruction of PHI at contract termination. A standard NDA addresses none of those requirements, which means your organization would be exposed even if both parties signed in good faith.

Why business associate agreements matter under HIPAA

HIPAA does not treat BAAs as optional paperwork. The Department of Health and Human Services (HHS) Office for Civil Rights (OCR) has the authority to impose civil monetary penalties ranging from $100 to $50,000 per violation, with annual caps reaching $1.9 million per violation category. Organizations that allow a vendor to access PHI without a signed BAA are in violation from the moment that access begins, not just after a breach occurs. This means the risk exists even when no data incident takes place.

The financial and legal consequences of non-compliance

OCR enforcement actions against organizations without proper BAAs are well-documented in the agency's public breach portal and resolution agreement records. Regulators look specifically at whether covered entities identified their business associates and executed proper agreements before granting PHI access. If they didn't, that failure becomes its own violation, independent of whether any patient data was misused. Beyond federal penalties, states can layer their own fines on top, and affected individuals can pursue civil claims in some circumstances.

Signing a BAA before your vendor accesses any PHI is not a formality; it is the legal line that separates compliant operations from active violations.

How BAAs create accountability across your vendor relationships

Understanding who needs a business associate agreement becomes especially relevant when you start mapping your vendor stack. Every time you bring in a third-party service that will interact with patient records, a BAA establishes exactly what that vendor is permitted to do with the data, how quickly they must notify you if something goes wrong, and what happens to the PHI when the contract ends. Without that structure, you have no enforceable claim against a vendor who mishandles patient data, because you never legally defined their obligations in the first place.

A BAA also protects your patients. When every party in your data ecosystem operates under a signed agreement, patients retain their HIPAA-guaranteed rights: the right to access their records, the right to have corrections made, and the right to know when their data was involved in a breach. Without proper BAAs in place, those rights become difficult or impossible to enforce downstream, and your organization bears the responsibility for that gap regardless of which vendor caused the problem.

Who counts as a HIPAA covered entity

HIPAA defines three specific categories of organizations as covered entities: health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically. If your organization falls into any of these categories, you carry direct obligations under HIPAA, including the requirement to execute BAAs with every vendor who accesses PHI on your behalf.

Health plans

Health plans are the most recognizable covered entities. This category includes individual and group health insurance plans, employer-sponsored health plans with 50 or more participants, Medicare, Medicaid, and other government-funded programs. Health Maintenance Organizations (HMOs) also fall under this definition. If your organization administers or funds medical, dental, or vision benefits for a population, it almost certainly qualifies as a health plan and must operate under HIPAA's full framework.

Healthcare providers

Any provider that transmits health information electronically in connection with a HIPAA-covered transaction is a covered entity, regardless of size. This includes hospitals, physician offices, dentists, pharmacies, and nursing facilities. The electronic transmission threshold matters: a small independent physician who submits claims to an insurance company through electronic systems is covered, while one who operates entirely on paper technically is not, though that scenario is increasingly rare. If your company builds software for any of these providers, you are very likely operating as their business associate rather than as a covered entity yourself, which shifts your compliance obligations in a specific direction.

Healthcare clearinghouses

Healthcare clearinghouses are organizations that process nonstandard health information into standardized formats, or vice versa. They sit between health plans and providers, translating claim data, eligibility information, and remittance data. Billing services and repricing companies that perform these functions typically qualify under this category.

If your organization receives PHI from a covered entity and processes it to generate any output, you should evaluate whether you meet the clearinghouse definition before assuming you fall outside HIPAA's scope.

Knowing who counts as a covered entity is the starting point for determining who needs a business associate agreement at all. Once you confirm your organization's status, every vendor relationship that involves PHI access requires scrutiny. Healthcare app developers and EHR integration platforms are rarely the covered entity themselves, but their customers almost always are, and that single fact shapes every compliance obligation that flows downstream.

Who counts as a HIPAA business associate

A business associate is any outside party that performs functions or activities for a covered entity that involve the use or disclosure of PHI. The HIPAA definition is deliberately broad. It covers vendors who actually view patient records and those who simply store or transmit data without ever reading it. If PHI passes through a system your vendor controls, that vendor is your business associate regardless of how they describe their own role.

Technology and software vendors

This category covers a wide range of companies that healthcare organizations rely on every day. Cloud storage providers, EHR integration platforms, patient portal vendors, and billing software companies all fall here if their services involve PHI. A company hosting your EHR data on its servers is a business associate. An API platform that routes patient data between your application and an EHR system is a business associate. Knowing who needs a business associate agreement in your technology stack requires you to trace every path where PHI flows and identify which vendor controls each segment.

If a vendor touches PHI at any point in your workflow, even briefly or in transit, the business associate classification applies and a BAA is required before access begins.

Professional service providers

Many organizations overlook professional service firms in their BAA reviews because these vendors do not look like typical technology providers. Attorneys who review patient records as part of litigation support, accountants who audit claims data, and consultants who analyze patient outcomes are all business associates if PHI is part of what they access. The test is not whether the vendor is technical. The test is whether they access, receive, maintain, or transmit PHI while carrying out their work for you.

What the business associate definition excludes

Not every third party who works with your organization qualifies as a business associate. Workforce members of the covered entity itself are not business associates; they fall under the organization's own internal HIPAA policies. Covered entities sharing PHI with each other for treatment purposes operate under a different HIPAA provision and do not need a BAA for that specific exchange. A courier service that physically transports sealed medical records without accessing their content also falls outside the definition. These exclusions are specific, and you should not assume any vendor qualifies for one without confirming it against the regulatory text at HHS.gov.

When you need a business associate agreement

The requirement to execute a BAA activates the moment a vendor receives access to PHI as part of the service they provide to your organization. You do not need to wait for a data incident or an audit inquiry. The legal obligation begins before access is granted, and the agreement must be signed before any PHI changes hands. Understanding who needs a business associate agreement in your specific situation comes down to applying two tests: does the vendor access PHI, and does that access happen as part of a function or service performed on your behalf?

PHI access triggers the requirement

Any time a vendor's system processes, stores, or transmits patient data for your organization, you need a BAA in place. The trigger is the nature of the data, not the intent behind the access. A vendor does not need to read patient records actively to qualify. Storing encrypted PHI on a server is sufficient, as is routing it through an API layer or indexing it for search functionality.

The following scenarios all require a BAA before work begins:

• A cloud infrastructure provider hosts your patient database or backup files
• An analytics platform ingests clinical or claims data to generate reports
• A communication tool transmits patient information between providers and staff
• An EHR integration platform connects your application to hospital systems and exchanges patient records
• A billing vendor accesses diagnosis or procedure codes tied to individual patients

You cannot rely on a vendor's own description of their role to determine whether a BAA is required. Apply the PHI access test yourself against the actual data flow.

Third-party access through integrations and APIs

Healthcare applications that connect to EHR systems sit at the center of this requirement. If your product pulls patient demographics, clinical notes, lab results, or medication records through an API integration, every platform in that chain that touches the data is your business associate. That includes the integration middleware, the API gateway, and any authentication service that processes identifiable patient tokens as part of the OAuth flow.

Your compliance obligation does not shrink because the access is automated or the PHI passes through in milliseconds. Automated data pipelines carry the same BAA requirement as manual data access. Confirm that every vendor in your integration stack has signed a BAA before your application goes live.

When you do not need a business associate agreement

Not every third-party relationship involving patient data requires a BAA, and misapplying the requirement creates unnecessary friction in your vendor negotiations. Understanding when the BAA obligation does not apply is just as important as knowing when it does. The key is identifying situations where the law either uses a different mechanism to protect PHI or where the third party does not meet the legal definition of a business associate in the first place.

Treatment, payment, and operations exchanges between covered entities

When two covered entities share PHI directly with each other for treatment, payment, or healthcare operations purposes, HIPAA does not require a BAA between them. A hospital sending patient records to a referring physician for treatment purposes operates under a different HIPAA provision and does not need a formal agreement to govern that exchange. Similarly, a health plan sharing claims data with another covered entity for coordinated care or payment processing falls outside the BAA requirement.

This exception applies to the exchange itself, not to any vendor a covered entity brings in to facilitate that exchange, which still requires a BAA.

Workforce members and internal operations

Your own employees, volunteers, and contracted workforce members who operate under your organization's direct control are not business associates. HIPAA treats them as part of your covered entity, governed by your internal policies, training programs, and sanctions procedures rather than by a separate contract. If your IT staff administers your EHR system or your billing team processes claims in-house, those activities do not trigger the question of who needs a business associate agreement because no outside party is involved.

This distinction matters when you evaluate staffing arrangements. A temporary employee placed by a staffing agency who works under your supervision and follows your policies is generally treated as part of your workforce. The staffing agency itself, however, may require a BAA if it has its own access to your PHI as part of managing the placement.

Incidental contact without PHI access

Vendors who provide services to your organization but never access PHI as part of those services are not business associates. A janitorial company cleaning your office, a food service vendor supplying your break room, or a shipping courier delivering sealed packages without any ability to access their contents all fall outside the definition. The operative test is whether PHI is accessible to the vendor in the course of their work, not whether they physically enter a space where records are stored.

Subcontractors and the downstream BAA chain

When a business associate brings in another vendor to help carry out its work with PHI, that additional vendor becomes a subcontractor under HIPAA. The obligation to execute a BAA does not stop at the first layer of the vendor relationship. It extends through every downstream party that touches PHI, regardless of how far removed that party is from the original covered entity. Understanding who needs a business associate agreement in complex vendor chains requires you to trace the data through every handoff, not just the first one.

How the subcontractor chain works

A business associate is responsible for ensuring that any subcontractor it engages to carry out PHI-related functions signs a BAA before receiving access to that data. The covered entity does not need to execute a direct agreement with the subcontractor in most cases. The business associate takes on that responsibility independently. However, the obligations imposed on the subcontractor must be at least as protective as those the business associate accepted in its own agreement with the covered entity. You cannot contract your way to weaker protections as data moves down the chain.

Consider a practical example from healthcare integrations: your application uses an EHR integration platform to connect with hospital systems. That platform stores patient data using a third-party cloud provider. The integration platform is your business associate, and the cloud provider is that platform's subcontractor. The cloud provider must have a signed BAA with the integration platform covering the same PHI protection requirements you negotiated upstream. If that agreement is missing, a compliance gap exists in your stack even though you never had direct contact with the cloud provider.

A business associate that cannot confirm its subcontractors have signed BAAs is a compliance risk to your organization, because HIPAA holds the entire chain accountable for PHI protection.

Your visibility into the subcontractor chain

You should ask any business associate you work with whether they engage subcontractors who access PHI, and whether those subcontractors have executed proper agreements. This is not overreach. HIPAA's framework explicitly anticipates these questions, and a credible vendor will maintain documentation of its downstream agreements and provide assurances on request. If a vendor resists this inquiry or cannot confirm its subcontractor BAA status, treat that as a material compliance concern before you allow PHI to flow through their systems.

What a HIPAA-compliant BAA must include

Knowing who needs a business associate agreement only gets you halfway. The agreement itself must contain specific provisions that HHS defines in 45 CFR §164.504(e). A BAA missing any of these required elements is legally deficient, which means it offers your organization no real protection even if both parties signed it willingly.

Required provisions under 45 CFR §164.504(e)

Every valid BAA must spell out what the business associate is permitted to do with PHI and what activities are explicitly prohibited. Vague language about "protecting data" does not satisfy the regulatory requirement. HHS mandates that the agreement address each of the following in clear, specific terms:

• Permitted uses and disclosures of PHI by the business associate
• A prohibition on the business associate using PHI for any purpose not authorized in the agreement
• Breach and security incident notification requirements, including timelines for reporting to the covered entity
• The business associate's obligation to implement administrative, physical, and technical safeguards consistent with the HIPAA Security Rule
• A requirement that the business associate subcontract only to parties who agree to the same PHI protection standards
• Patient rights provisions, including supporting the covered entity in responding to individual access and amendment requests
• A requirement to make PHI available to HHS for compliance investigations if requested

A BAA that omits the breach notification timeline or fails to address subcontractor obligations is deficient under federal law, regardless of how detailed the rest of the agreement appears.

Language that protects PHI at contract end

One provision that organizations frequently overlook is what happens to PHI when the vendor relationship terminates. A HIPAA-compliant BAA must require the business associate to either return or destroy all PHI at the end of the contract, retaining no copies. If returning or destroying the data is not feasible, the business associate must extend PHI protections indefinitely for whatever data it cannot eliminate.

Review this clause carefully before signing. Many vendor agreements include generic termination language that covers business data broadly but does not address PHI specifically. If your BAA does not name PHI destruction or return as a distinct post-termination obligation, revise it before any patient data enters that vendor's systems.

How to decide fast using a vendor checklist

Working through who needs a business associate agreement on a vendor-by-vendor basis takes time, but a structured checklist eliminates most of the guesswork. Rather than analyzing every vendor relationship from scratch, you can apply a consistent set of five questions to each new vendor before granting any PHI access. If any question produces a "yes," a BAA is required before that vendor touches your data.

The five questions to ask before granting PHI access

Run every incoming vendor through this list the moment you begin evaluating their service. The goal is to make the PHI access determination before contract negotiations conclude, not after a vendor is already embedded in your workflow.

Question	Yes	No
Will this vendor receive, store, process, or transmit PHI?	BAA required	Continue checklist
Does the vendor provide a service or function on behalf of your covered entity?	BAA required	Continue checklist
Will this vendor build a product or system that handles PHI for you?	BAA required	Continue checklist
Is this vendor a subcontractor of an existing business associate with PHI access?	BAA required	Continue checklist
Does this vendor access any system where PHI is present, even incidentally?	Evaluate further	No BAA needed

A vendor that answers "no" to every question in this table almost certainly does not meet the HIPAA business associate definition, but you should document that determination in writing in case OCR ever asks.

Work through the table before any pilot, proof of concept, or sandbox environment that includes real patient data. Development environments using de-identified or synthetic data do not trigger the BAA requirement, so confirm the data type your vendor will access as a preliminary step before running the checklist at all.

What to do when a vendor pushes back

Some vendors resist signing BAAs, either claiming they are not a business associate or offering a generic privacy agreement as a substitute. When this happens, send them the HHS business associate definition directly from HHS.gov and ask them to explain in writing how their service falls outside that definition. Their response tells you everything you need to know about their compliance posture and reliability as a long-term partner. A vendor that cannot explain its own HIPAA status or refuses to execute a proper BAA is not a vendor you should trust with patient data, regardless of how strong their product offering is.

Next steps

By now, you have a clear picture of who needs a business associate agreement and what that requirement looks like in practice across covered entities, business associates, and subcontractors. The rules are specific, the penalties are real, and every vendor in your PHI data chain carries weight. Use the checklist in the previous section as your default filter for every new vendor evaluation, and never let PHI flow to a third party before a valid, signed BAA is in place.

If you build healthcare applications that connect to EHRs, your integration platform is one of the most critical links in your compliance chain. SoFaaS by VectorCare is built specifically for this environment, with HIPAA-compliant infrastructure, SOC 2 Type II certification, and BAA support included as part of the platform. You can launch your SMART on FHIR app without building compliance infrastructure from scratch, and get your integration running in days rather than months.