Who is accountable for HIPAA compliance when third parties handle PHI on behalf of a covered entity?

Why This Matters for Security Teams

HIPAA accountability does not stop at the covered entity’s perimeter. Once a business associate or subcontractor touches protected health information, the risk profile shifts to shared responsibility, shared evidence, and shared failure modes. That means access paths, logging, retention, incident response, and offboarding must be governed with the same discipline across the chain. Current guidance suggests that compliance breaks most often where contracts say one thing and operations do another.

For identity-heavy environments, this is not just a policy issue. Third parties often handle secrets, service accounts, API keys, and delegated access that outlive the original purpose of the engagement. NHIMG research shows that 92% of organisations expose NHIs to third parties, which is why supplier oversight has become a practical compliance concern, not a theoretical one. See Ultimate Guide to NHIs — Regulatory and Audit Perspectives and the OWASP Non-Human Identity Top 10 for how exposed identities and delegated access create audit gaps. In practice, many security teams discover weak third-party controls only after a vendor incident or audit request has already forced the issue.

How It Works in Practice

HIPAA accountability is layered. The covered entity remains responsible for selecting and overseeing vendors appropriately, but business associates are directly bound by their own HIPAA obligations within scope, and subcontractors inherit those duties when they receive PHI on behalf of a business associate. The practical test is whether each party can show that it protects PHI, limits use to permitted purposes, and can prove what happened to the data.

That starts with governance, not tooling. Covered entities should maintain a complete inventory of who stores, processes, transmits, backs up, or administers PHI, then map each relationship to a Business Associate Agreement, data flow, and control owner. Evidence should include access reviews, incident reporting timelines, encryption status, disposal procedures, and termination workflows. NIST’s Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls are useful references for structuring those expectations into repeatable supplier controls.

• Define scope clearly: which systems, users, service accounts, and integrations touch PHI.
• Require written contractual obligations for safeguard, breach notification, audit rights, and subcontractor flow-down.
• Verify least privilege, MFA, logging, retention, and offboarding for both human and non-human access.
• Demand current evidence, not annual attestations alone, especially for privileged access and secret rotation.

NHIMG guidance on Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is especially relevant where vendors use long-lived tokens or shared service identities to reach PHI. These controls tend to break down when subcontractors are added late in the delivery chain because the original oversight model no longer matches the real data path.

Common Variations and Edge Cases

Tighter vendor oversight often increases procurement friction and operational overhead, requiring organisations to balance faster onboarding against stronger assurance. That tradeoff becomes sharper when a third party only touches de-identified data, aggregated analytics, or infrastructure components that can still indirectly expose PHI.

There is no universal standard for every edge case, but current guidance suggests the safest approach is to classify the relationship based on actual access, not job title. A company may be a business associate even if it never opens a patient chart, while a subcontractor may inherit HIPAA obligations because it supports a business associate’s service stack. If a vendor uses other vendors, the covered entity should require flow-down obligations and visibility into those downstream parties.

Other recurring exceptions include emergency support access, managed services, and temporary integrations where credentials are created quickly and then forgotten. That is where the accountability model usually fails. Security teams should insist on short-lived access, explicit revocation, and logs that can be tied back to a named organization and purpose. For a broader view of third-party exposure patterns, compare NHIMG’s 52 NHI Breaches Analysis with the Top 10 NHI Issues. In practice, the hardest failures are not obvious policy violations but vendor relationships where nobody can prove who had PHI access, for how long, or under whose authority.

Related resources from NHI Mgmt Group

• Why do business associate agreements matter when third parties handle PHI?
• Who is accountable for HIPAA compliance when business associates and subcontractors handle PHI?
• Who is accountable for PCI SAQ compliance when organisations rely on third-party payment providers?
• Who is accountable when PHI is entered into a collaboration app that is not HIPAA compliant?