Covered Entity Vs Business Associate: Key Differences & BAAs

If your organization touches protected health information (PHI) in any way, understanding the distinction between covered entity vs business associate is non-negotiable. These two HIPAA classifications carry different obligations, different risks, and different legal exposure, and misidentifying your role can result in significant fines and regulatory action.

A covered entity is typically a healthcare provider, health plan, or clearinghouse that creates or receives PHI directly. A business associate, on the other hand, is any third party that handles PHI on behalf of a covered entity, think software vendors, cloud hosting providers, or integration platforms. The relationship between the two must be formalized through a Business Associate Agreement (BAA), which spells out exactly how PHI will be protected. Without one, both parties are exposed.

This matters especially when you're integrating with EHR systems. At SoFaaS, we operate as a HIPAA-compliant, SOC 2 Type II certified platform that connects healthcare applications to EHRs like Epic, Cerner, and Allscripts using the SMART on FHIR standard. That means we function as a business associate for the organizations we serve, and we take that responsibility seriously with built-in encryption, audit logging, and proper BAA execution.

This article breaks down the exact definitions of each role, walks through real examples, explains your compliance obligations, and clarifies when a BAA is required. Whether you're a health tech startup or a healthcare supplier building your first EHR integration, knowing where you stand under HIPAA is step one.

Why the difference matters for HIPAA compliance

Understanding the covered entity vs business associate distinction is not just a legal formality. It determines which HIPAA rules apply to your organization, what contracts you must sign, and what penalties you face if something goes wrong. The HIPAA Privacy Rule and Security Rule assign specific, non-overlapping responsibilities based on how your organization interacts with PHI, and regulators at the Office for Civil Rights (OCR) enforce those responsibilities independently for each party.

The compliance obligations differ by role

Your classification under HIPAA shapes your entire compliance program. Covered entities must implement both the Privacy Rule and the Security Rule in full, which includes publishing a Notice of Privacy Practices, appointing a privacy officer, and managing patient rights like access and amendment requests. Business associates carry a narrower but still substantial compliance burden: they must implement the Security Rule's administrative, physical, and technical safeguards for any PHI they handle, and they must report breaches directly to the covered entity within the timeframes set by the Breach Notification Rule.

If you misclassify your organization as a covered entity when you are actually a business associate, you may skip safeguards that are legally required for your actual role, and vice versa.

The practical difference shows up in day-to-day operations. A business associate cannot use PHI for its own purposes beyond what the BAA permits, even if the data passes through its systems constantly. A covered entity, by contrast, can use PHI for treatment, payment, and healthcare operations without additional authorization in most cases. These distinctions directly affect how you build your data pipelines, what you log, and how long you retain records.

What happens when classification gets it wrong

OCR enforcement actions consistently show that misclassification is one of the most common root causes of HIPAA violations. When a company incorrectly assumes it is not a business associate, it often skips executing a BAA with its downstream vendors and fails to implement required security controls. That creates liability for both parties: the covered entity for failing to obtain a BAA, and the vendor for handling PHI without the protections the law requires.

Penalties are tiered based on culpability, but even unknowing violations carry fines starting at $100 per violation and reaching into the millions per calendar year for repeated failures. In cases where willful neglect is found and not corrected, OCR has levied penalties exceeding $1.9 million in a single case. Beyond the financial hit, enforcement actions become public record, which damages trust with patients, partners, and health systems you are trying to integrate with.

Why both roles are accountable under the HITECH Act

The HITECH Act extended direct HIPAA liability to business associates, which was a significant shift from the original HIPAA framework. Before HITECH, covered entities were largely responsible for enforcing compliance through their contracts with vendors. After HITECH, OCR gained the authority to audit and fine business associates directly, without going through the covered entity first.

This means your compliance responsibility does not disappear just because you are a third-party vendor rather than a healthcare provider. If you build or operate a platform that processes PHI for covered entities, you are independently accountable to OCR. You need your own policies, your own risk assessments, and your own incident response procedures. Relying on a covered entity's compliance program to cover you is a mistake that regulators have penalized repeatedly.

What counts as a covered entity

Under HIPAA, covered entities fall into three distinct categories defined by the Department of Health and Human Services. These categories are based on what your organization does, not how large it is or what technology it uses. When working through the covered entity vs business associate distinction, starting with these three categories gives you a clear and practical baseline.

The three categories of covered entities

Healthcare providers make up the largest group. This includes any person or organization that furnishes, bills for, or is paid for healthcare services, such as physicians, hospitals, dentists, chiropractors, nursing homes, and pharmacies. The key requirement is that the provider must transmit health information electronically in connection with certain standard transactions, like claims submission or eligibility inquiries. A solo practitioner who submits claims electronically qualifies just as much as a large hospital network.

Health plans form the second category. These include health insurance companies, HMOs, employer-sponsored group health plans, Medicare, Medicaid, and the Children's Health Insurance Program (CHIP). Small self-funded employer health plans with fewer than 50 participants are the one notable exception under the rules, so size can matter here in a limited way.

Healthcare clearinghouses make up the third and most specialized category. A clearinghouse processes nonstandard health information received from one entity and converts it into standard formats, or the reverse. Billing services and repricing companies that perform this function are the most common real-world examples.

If your organization pays for or processes healthcare services for a defined group of members, you almost certainly fall under one of these three categories.

Why your operational role determines your classification

Your classification depends on what your organization actually does with PHI, not what your marketing materials say or what you assume your role to be. A software company that hosts patient records for a hospital is not a covered entity simply because it holds PHI; it is a business associate. A pharmacy that fills prescriptions and submits electronic claims, however, clearly qualifies as a healthcare provider regardless of its size or technical setup.

This distinction carries direct compliance consequences. Covered entities must follow the full scope of HIPAA's Privacy Rule, which governs patient rights, required disclosures, and permissible uses of PHI. If you are unsure of your classification, reviewing the official HHS covered entity decision tool is a practical and authoritative starting point.

What counts as a business associate

A business associate is any person or entity that performs a function or activity on behalf of a covered entity that involves creating, receiving, maintaining, or transmitting PHI. The definition is intentionally broad. If your product, service, or platform touches PHI while supporting the operations of a covered entity, you almost certainly qualify as a business associate under HIPAA, regardless of whether you consider yourself a "healthcare company."

How the definition applies in practice

The covered entity vs business associate distinction becomes clearest when you examine the nature of the work being performed. A business associate does not need to own the PHI or make clinical decisions with it. Simply storing, processing, or transmitting PHI on behalf of a covered entity is enough to trigger business associate status. This applies to software vendors, managed service providers, billing companies, and any platform that handles patient data as part of its core service delivery.

The word "on behalf of" is critical here. If a cloud storage provider hosts a hospital's patient records, it is a business associate. If an analytics firm processes claims data to identify care gaps for a health plan, it is a business associate. The test is whether the PHI access is in service of the covered entity's functions.

If your platform, application, or service accesses PHI to deliver value to a covered entity, you are operating as a business associate whether or not you have signed a BAA yet.

Common categories of business associates

Many technology and service companies fall into business associate territory without realizing it. The categories below represent the most common real-world examples:

• EHR integration platforms that connect third-party applications to health systems
• Medical billing and coding vendors that process claims containing patient diagnoses and treatment data
• Cloud hosting and infrastructure providers that store PHI on behalf of healthcare organizations
• Healthcare analytics and reporting tools that receive and process patient-level data
• Telehealth platforms that transmit clinical information between providers and patients
• Legal, accounting, or consulting firms that access PHI while advising a covered entity

Your subcontractors also matter. If you are a business associate and you engage a subcontractor who will access PHI to perform work for you, that subcontractor becomes a business associate of yours. The chain of accountability extends downstream, and you are responsible for ensuring those relationships are covered by proper agreements.

When you need a business associate agreement

A Business Associate Agreement (BAA) is required any time a covered entity shares PHI with a third party that qualifies as a business associate. This is not optional, and it is not something you can delay until after a vendor is already handling your data. The BAA must be in place before PHI is accessed, processed, or transmitted by the outside party. Failing to execute one before data sharing begins puts both organizations in direct violation of HIPAA, regardless of whether a breach ever occurs.

The trigger for requiring a BAA

The trigger is straightforward: if a vendor or service provider creates, receives, maintains, or transmits PHI on your behalf, you need a BAA in place. When working through the covered entity vs business associate relationship, this is the single most actionable question to ask. It applies whether the vendor is a large cloud infrastructure provider, a small analytics firm, or an EHR integration platform like SoFaaS. The size or sophistication of the vendor is irrelevant to the legal requirement.

If PHI moves to a third party for any operational purpose, a BAA is required before that transfer happens.

What a BAA must include

A valid BAA must cover specific terms to satisfy HIPAA's requirements. The agreement needs to define the permitted uses and disclosures of PHI that the business associate is allowed to perform. It must require the business associate to use appropriate safeguards, report breaches to the covered entity, and restrict subcontractors from accessing PHI without their own agreements in place. The BAA must also address what happens to PHI when the contract ends, whether that means returning the data, destroying it, or retaining it under specific conditions.

Your BAA should not be a generic contract with a line or two about data protection added in. It needs to be a substantive, HIPAA-specific agreement that both parties review carefully. Relying on boilerplate language without confirming it meets current regulatory standards is a compliance gap that OCR audits regularly surface.

When a BAA is not required

Not every vendor relationship involving health data requires a BAA. Disclosures to treatment providers who are themselves covered entities, for example, fall under different HIPAA rules. Conduit services that transport data without accessing its content, such as a postal service or a basic telecommunications carrier, also fall outside the business associate definition. The distinction hinges on whether the vendor can access and use the PHI content, not simply whether the data passes through its infrastructure.

How to classify your org and vendors

Getting your classification right starts with looking at what your organization actually does with PHI, not what you assume your role to be. Many organizations in the health tech space sit in a gray area, and the covered entity vs business associate distinction only becomes clear when you examine your operational functions systematically. The questions below give you a structured way to work through both your own classification and that of every vendor you use.

Start with your own organization

Ask yourself one direct question: does your organization furnish, bill for, or get paid for healthcare services, or does it administer a health plan? If yes, you are almost certainly a covered entity. If your organization instead builds software, processes data, or provides services that support a covered entity's functions, you are operating as a business associate. The two roles are mutually exclusive for any given function, though some organizations can hold both statuses depending on the specific activity.

If your platform accesses PHI to deliver a service to a healthcare provider or plan, you are a business associate by definition, regardless of whether you think of yourself as a technology company.

Use this checklist to confirm your classification before assuming:

• Do you submit electronic claims or eligibility transactions directly? (Covered entity signal)
• Do you process or store PHI on behalf of another organization? (Business associate signal)
• Are you the primary decision-maker about how PHI is used, or are you following a covered entity's instructions?
• Do you have direct relationships with patients for treatment or billing purposes?

Assess each vendor you work with

Once your own classification is clear, apply the same logic to every vendor in your technology stack. For each tool, platform, or service provider your organization uses, ask whether that vendor creates, receives, maintains, or transmits PHI in the course of delivering its service to you. If the answer is yes, that vendor is a business associate and you need a signed BAA before PHI flows to them.

Build a simple vendor inventory that documents each vendor name, the type of PHI they access, their business associate status, and the BAA execution date. Review this inventory at least annually, because vendor capabilities and data access patterns change over time. A provider that only handled anonymized data during an initial engagement may expand to full PHI access later, which immediately triggers the BAA requirement regardless of how long you have worked together.

Key takeaways and next steps

The covered entity vs business associate distinction shapes your entire HIPAA compliance program. Your classification determines which rules apply to you, which contracts you must sign, and what liability you carry when something goes wrong. Getting it right is not optional.

Once you know where your organization stands, your next move is practical: audit every vendor in your stack, confirm which ones access PHI, and execute BAAs before any data changes hands. If you build applications that connect to health systems, you are almost certainly a business associate, and your compliance infrastructure needs to reflect that directly.

SoFaaS handles HIPAA-compliant EHR integration so you can build healthcare applications without building a compliance program from scratch. Connect your app to Epic, Cerner, and more in days, not months, with a platform that comes ready with built-in security controls and a signed BAA included.