Skip to main content
HIPAA Path
Category: Governance and Workforce

Third-Party Governance

Also known as: Third-Party Governance and Risk Management, Third-Party Risk Governance
Simply put

Third-party governance is the set of policies, procedures, and processes an organization uses to oversee and manage the risks that come from working with outside parties such as vendors and service providers. Its aim is to assess, monitor, and reduce those risks while making sure the relationships still deliver value. In healthcare compliance, this discipline typically supports (but does not by itself satisfy) the oversight obligations a covered entity or business associate has toward the vendors that handle protected health information.

Formal definition

Third-party governance refers to the frameworks, policies, procedures, and processes an organization establishes to manage relationships with external entities and to oversee the risks those relationships introduce. It is the governance layer of third-party risk management (TPRM), encompassing the people, processes, and technologies used to identify, assess, monitor, manage, and mitigate third-party risk, and is distinct from the assurance activities (such as testing and validation) that verify controls are operating effectively. In the HIPAA context, third-party governance is an organizational practice rather than a defined regulatory term; specific HIPAA obligations toward vendors attach through defined relationships and instruments (for example, business associate agreements between covered entities, business associates, and subcontractors) rather than through governance programs alone. A governance program can help operationalize these obligations but does not on its own establish HIPAA compliance, and readers should confirm applicable requirements against current regulatory text and any additional state-law or contractual obligations. The evidence packet does not address HIPAA-specific requirements, so those aspects should be verified independently.

Why it matters

Healthcare organizations rarely handle protected health information in isolation. Covered entities and business associates routinely rely on outside vendors and service providers for functions ranging from claims processing to cloud hosting, and each of those relationships introduces risk that the organization cannot simply hand off. Third-party governance provides the structured way to assess, monitor, and reduce those risks while confirming the relationships continue to deliver value. Without a deliberate governance layer, an organization may lack the processes, people, and technologies needed to manage third-party risk effectively.

In the HIPAA context, this discipline matters because it helps operationalize the oversight an organization is expected to exercise over the vendors that touch PHI. It is important to be precise here: third-party governance is an organizational practice, not a defined HIPAA regulatory term. Specific HIPAA obligations toward vendors attach through defined relationships and instruments, such as business associate agreements between covered entities, business associates, and subcontractors, rather than through a governance program alone. A strong governance program can support those obligations but does not by itself establish HIPAA compliance.

Because of this gap between good practice and legal obligation, compliance leaders should treat third-party governance as a foundation to build on rather than a finish line. The evidence available here does not address HIPAA-specific requirements, and additional state-law or contractual obligations may apply. Organizations should confirm applicable requirements against current regulatory text and layer their governance activities on top of the specific instruments HIPAA requires.

Who it's relevant to

Compliance and Privacy Officers
Those responsible for HIPAA compliance use third-party governance to structure oversight of vendors that handle PHI. They should understand that governance programs support but do not by themselves satisfy HIPAA obligations, which attach through defined relationships and instruments such as business associate agreements. Applicable requirements should be confirmed against current regulatory text and any additional state-law obligations.
Security Officers and Risk Managers
Security and risk professionals operate the identify, assess, monitor, manage, and mitigate cycle at the core of TPRM. They coordinate the people, processes, and technologies needed to manage third-party risk and often own both the governance framework and the assurance activities that verify vendor controls are operating effectively.
Vendor Management and Procurement Teams
Teams that source and manage external service providers apply governance policies and procedures throughout the vendor relationship lifecycle. Their aim is to reduce third-party risk while ensuring the relationships continue to deliver value, and to ensure that required contractual instruments are in place before PHI is shared.
Auditors and Assurance Professionals
Auditors focus on the assurance side, testing and validating that third-party controls function as intended, which is distinct from the governance frameworks that define how risk is managed. They help confirm that a governance program is more than documented policy and is producing verifiable results.

Inside Third-Party Governance

Business Associate Agreements (BAAs)
Contracts through which a covered entity extends applicable HIPAA obligations to business associates, and through which business associates extend obligations to their subcontractors. HIPAA obligations generally attach through these defined relationships rather than to every vendor that touches data. BAAs typically address permitted uses and disclosures of PHI, safeguarding requirements, breach reporting duties, and terms for termination and return or destruction of PHI.
Third-Party Risk Assessment
The process of evaluating the privacy and security risks a vendor may introduce, particularly where the vendor creates, receives, maintains, or transmits PHI or ePHI on behalf of a covered entity or business associate. Assessments generally consider the nature of data access, the vendor's safeguards, and the flow-down of obligations to any subcontractors.
Ongoing Monitoring and Oversight
Continued review of third-party performance and compliance after contracting, rather than a one-time check at onboarding. This may include periodic reassessment, review of the vendor's safeguards, and confirmation that obligations under the BAA continue to be met.
Vendor Classification and Scoping
Distinguishing which third parties are business associates (and therefore subject to HIPAA obligations through a BAA), which are subcontractors, and which have no access to PHI. Precise classification matters because HIPAA does not directly regulate every vendor in a supply chain; obligations attach through defined relationships.
Independent Assurance Frameworks
Third-party certifications or attestations, such as HITRUST CSF certification, that some organizations request from vendors to gain assurance about control maturity. These are provided by private organizations and can support a governance program but do not, by themselves, establish HIPAA compliance.

Common questions

Answers to the questions practitioners most commonly ask about Third-Party Governance.

Does HIPAA directly regulate every third-party vendor that touches our data?
No. HIPAA does not attach obligations to every vendor simply because it handles data. Obligations flow through defined relationships: a covered entity engages a business associate that creates, receives, maintains, or transmits PHI on its behalf, and that relationship is generally governed by a business associate agreement (BAA). Business associates in turn flow obligations down to subcontractors through their own agreements. Vendors that do not access PHI, or that only handle it in ways falling outside the business associate definition, are generally not brought under HIPAA by that relationship alone. Third-party governance programs should map which vendors actually meet the business associate definition rather than assuming all vendors are equally regulated.
If a vendor is HITRUST CSF certified, does that mean our third-party governance obligations are satisfied and the vendor is HIPAA compliant?
No. HITRUST is a private organization and the HITRUST CSF is a certifiable control framework, not a legal requirement. A vendor's HITRUST certification does not by itself establish HIPAA compliance, and it does not discharge a covered entity's or business associate's own third-party governance responsibilities. Certification can be useful evidence when evaluating a vendor's control environment, but it typically covers a defined scope and point in time and should be reviewed for what it actually assesses. You generally still need an executed BAA, your own due diligence, and ongoing oversight. Confirm any certification scope and current HITRUST CSF version rather than treating certification as a substitute for these obligations.
How do we decide which vendors need a business associate agreement?
The general starting point is to determine whether the vendor meets the business associate definition, typically because it creates, receives, maintains, or transmits PHI on your behalf, or provides services that involve such access. Maintaining an inventory of vendors and the data each one touches supports this analysis. Where a vendor meets the definition, a BAA is generally required before PHI is shared. Where it does not, a BAA may not be legally required, though other contractual protections may still be prudent. Because edge cases arise, and because state law or the HITECH Act may add requirements, verify classifications against current regulatory guidance.
What kinds of due diligence should we perform before onboarding a business associate?
Due diligence typically includes reviewing the vendor's security and privacy practices relative to the safeguard expectations relevant to the services, confirming the scope of any certifications or assessments they provide, and evaluating how they handle PHI across administrative, physical, and technical safeguards. It generally also involves executing a BAA that addresses the vendor's obligations, including flow-down requirements to subcontractors and breach notification responsibilities. The depth of diligence usually scales with the sensitivity and volume of PHI involved. No single measure guarantees compliance, so onboarding is generally treated as the beginning of an ongoing oversight relationship rather than a one-time check.
How should we handle subcontractors that a business associate uses?
Obligations generally flow down from the business associate to its subcontractors through agreements comparable to a BAA. As the engaging covered entity or business associate, you typically address this in your own BAA by requiring the vendor to ensure equivalent protections and appropriate agreements with subcontractors that handle PHI. While the direct contractual relationship may sit between the business associate and its subcontractor, third-party governance programs commonly seek visibility into material subcontractors, particularly where they access significant PHI. Verify current requirements, since specifics can be affected by regulatory guidance and state law.
What does ongoing monitoring of third parties generally involve after onboarding?
Ongoing monitoring typically includes periodic reassessment of the vendor's control environment, tracking the status and scope of certifications or assessments they provide, confirming that BAAs remain current and accurate as services change, and defining how breach or incident notifications are received and acted upon. It often also involves reviewing changes in the PHI a vendor handles and any new subcontractors introduced. The cadence and rigor generally scale with risk. Because no monitoring approach prevents all breaches, programs usually pair oversight with incident response planning and confirm that notification timelines and responsibilities align with current Breach Notification Rule requirements and any applicable state law.

Common misconceptions

Signing a BAA makes a covered entity responsible for a vendor, and once signed the covered entity's job is done.
A BAA is a mechanism to extend applicable HIPAA obligations to a business associate, but it does not eliminate the need for ongoing oversight. Business associates carry their own direct obligations, and covered entities generally still need to assess and monitor third parties rather than relying on the contract alone.
A vendor's HITRUST certification means the vendor is HIPAA compliant.
HITRUST is a private organization and the HITRUST CSF is a certifiable control framework. Certification is not a legal requirement and does not by itself establish HIPAA compliance. It may provide useful assurance about a vendor's controls but should not be treated as a substitute for confirming that HIPAA obligations are met.
HIPAA directly regulates every vendor that touches an organization's data.
HIPAA obligations attach through defined relationships. A vendor becomes a business associate when it creates, receives, maintains, or transmits PHI on behalf of a covered entity or another business associate; obligations flow through BAAs to business associates and subcontractors, not automatically to every vendor in the supply chain.

Best practices

Classify each third party accurately to determine whether it is a business associate, a subcontractor, or a vendor with no PHI access, and put appropriate BAAs in place where obligations must flow through.
Ensure BAAs address permitted uses and disclosures, safeguarding expectations, breach reporting, and the return or destruction of PHI, and confirm that obligations flow down to subcontractors.
Conduct a risk assessment before granting a vendor access to PHI or ePHI, focusing on the vendor's safeguards and the sensitivity of the data involved.
Treat third-party oversight as ongoing rather than a one-time onboarding step, with periodic reassessment and review of continued compliance with the BAA.
Where a vendor provides a HITRUST CSF certification or similar attestation, use it as supporting assurance rather than as proof of HIPAA compliance, and verify certifications against the current HITRUST CSF version.
Account for additional requirements that may apply beyond HIPAA, such as state law or HITECH Act provisions, and confirm specific obligations against current regulatory text and guidance.