A covered entity is a health plan, health care clearinghouse, or a provider that handles PHI in the normal course of care. A business associate is a vendor or subcontractor that creates, receives, maintains, or transmits PHI on behalf of a covered entity. The distinction matters because both parties have compliance duties, but their responsibilities arise from different roles in the data flow.
How HIPAA separates roles in the data flow
The difference comes down to who is operating in the health care ecosystem versus who is performing work on someone else’s behalf. A covered entity is the regulated health organization itself, while a business associate is an outside party that touches protected health information because the covered entity hired it to do so. The role, not just the data, determines the obligation.
That distinction matters because HIPAA does not treat every organization with PHI the same way. Covered entities are accountable for how PHI is used in treatment, payment, and health care operations. Business associates are accountable for the PHI they handle under contract, including safeguards, permitted uses, and subcontractor oversight. The legal relationship shapes the compliance boundary.
- A health plan, provider, or clearinghouse is a covered entity when it is carrying out its own HIPAA-regulated functions.
- A vendor becomes a business associate when it creates, receives, maintains, or transmits PHI for a covered entity.
- A subcontractor can also be a business associate if it performs part of that delegated work and has access to PHI.
Why the distinction changes responsibility
Covered entities sit at the center of HIPAA compliance because they choose the service model, set the permissible uses, and must ensure downstream parties are constrained. Business associates do not inherit the covered entity’s full operational role, but they do inherit specific privacy and security duties tied to the PHI they handle. In practice, the question is which party controls the activity and which party merely supports it.
That is why agreements matter. A business associate agreement is not just paperwork, it is the mechanism that defines allowed processing, required safeguards, breach handling, and subcontractor flow-down expectations. Where the vendor relationship is loosely defined, organizations often blur operational convenience with legal authority, and that is where HIPAA failures start.
For background on identity and access risk in delegated relationships, NHI Mgmt Group’s Ultimate Guide to NHIs is useful when vendors, integrations, and service credentials are part of the control picture. The same principle shows up in externally visible breach patterns such as Salesloft OAuth token breach and Klue OAuth Supply Chain Breach, where third-party access paths became the practical exposure point.
What practitioners should verify in real HIPAA programs
Start by verifying whether the organization is acting as a covered entity, a business associate, or both. Large health systems often occupy both roles in different services, and vendors may also be business associates for one client while functioning as ordinary service providers for another. The legal status is relationship-specific, not company-wide by default.
What to verify:
- Whether the party actually creates, receives, maintains, or transmits PHI on behalf of another entity.
- Whether a business associate agreement exists before PHI is shared.
- Whether subcontractors are contractually bound to the same PHI handling limits.
- Whether access, retention, and breach response duties are documented for each role.
Common mistake: treating “vendor” and “business associate” as interchangeable. Many vendors are not business associates, and some covered entities also perform business associate functions for other organizations. The compliance test is the activity and relationship, not the job title.
Practitioner takeaway: Build the role map before you build the control map. If you cannot show who is a covered entity, who is a business associate, and which PHI flows justify that status, the rest of the HIPAA program will be directionally right but operationally weak.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV — Oversight | HIPAA role separation is a governance oversight issue for PHI handling relationships. |
| PR.AC — Identity Management, Authentication and Access Control | The distinction affects who may access PHI and under what authority. | |
| Recommendation — Map covered entity and business associate oversight to PHI-bearing relationships and review responsibilities. Restrict PHI access to the role-defined minimum and validate delegated access paths. | ||
| CIS Controls v8 | 6 — Access Control Management | Business associate handling of PHI depends on controlled, role-based access. |
| 3 — Data Protection | HIPAA role boundaries govern how PHI is handled, protected, and shared. | |
| Recommendation — Enforce least privilege for PHI systems and review third-party access regularly. Classify PHI flows and apply data protection controls to every delegated transfer. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Delegated access to PHI depends on trustworthy identity proofing and account control. |
| AAL — Authenticator Assurance Level | PHI access through business associates needs strong authentication assurance. | |
| Recommendation — Use strong identity proofing and authentication for any user or service that can reach PHI. Require phishing-resistant authentication for accounts that can access PHI. | ||
| PCI DSS v4.0 | 7 — Restrict Access by Business Need to Know | The same least-privilege principle applies to role-based PHI access decisions. |
| Recommendation — Limit PHI access to only the users and services with a documented business need. | ||
Related resources from NHI Mgmt Group
- What is the difference between Dropbox personal accounts and Dropbox Business for HIPAA use?
- What is the difference between patient access requests and disclosures to third parties under the updated HIPAA framework?
- What is the difference between operational priorities and business goals in IAM?
- What is the difference between HITRUST and HIPAA for security teams?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
