How to Build a Vendor Risk Programme That Actually Reduces Healthcare Breaches

Image Source: Pexels | How to Build a Vendor Risk Programme That Actually Reduces Healthcare Breaches

88% of healthcare data breaches involve a third-party vendor.

Not a rogue employee. Not a misconfigured internal system. A vendor with legitimate access to the network who either got compromised themselves or whose credentials were used in ways nobody was monitoring.

This figure has been consistent across multiple years of breach reporting. It is well-known enough that most healthcare security teams can recite it. And yet the way most health systems manage vendor security has not fundamentally changed in response to it.

Understanding why this gap persists and what closing it actually requires is one of the most important conversations happening in healthcare security right now.

Why Vendor Risk Is Different

Internal security is a problem of governing what your own systems and people can do. Vendor risk is a problem of governing what someone else's systems and people can do inside your environment.

The distinction matters because the tools and governance frameworks designed for internal security do not translate directly to vendor risk management. You can enforce multi-factor authentication on your own staff. You cannot directly control whether a third-party developer with access to your EHR integration has the same controls in place on their end.

What makes this particularly complex in healthcare is the volume and diversity of vendor relationships. The average health system has over 1,400 third-party vendor connections.

These range from large enterprise software providers with sophisticated security programmes to small clinical workflow tools managed by two-person companies. The access these vendors have varies from read-only data queries to full administrative control over critical clinical systems.

Managing this landscape through contracts and attestations, which is how most health systems currently approach it, is the equivalent of asking every vendor to tell you how secure they are and taking their word for it.

What Most Vendor Contracts Actually Say

The standard approach to vendor security in healthcare is the Business Associate Agreement. Under HIPAA, any vendor who accesses protected health information must sign a BAA, in which they commit to protecting that information in compliance with the relevant regulations.

A BAA is a legal commitment. It is not a security control. It does not verify that the vendor's systems are actually configured securely. It does not require an independent audit. It does not create a mechanism for the health system to detect a vendor compromise before it affects its own environment.

Beyond the BAA, most vendor contracts contain some version of a security questionnaire requirement. The vendor completes a self-assessment, submits it to the health system's compliance team, and the assessment is filed. If the vendor's answers indicate strong security practices, the contract proceeds. If the vendor's answers are inaccurate, nobody finds out until something goes wrong.

This process satisfies a compliance requirement. It does not meaningfully reduce the risk that a vendor's compromised credentials will be used to access a health system's environment six months after the questionnaire was completed and filed.

The Three Tiers of Vendor Risk

Not all vendor relationships carry the same risk, and a practical vendor security programme starts by understanding where the exposure actually is.

The highest-risk tier consists of vendors with persistent, direct access to clinical systems or patient data. These include EHR integration partners, clinical decision support tools with live data feeds, and managed service providers who operate within the health system's network. A compromise of any vendor in this tier could give an attacker direct access to patient records, clinical systems, or administrative infrastructure. These relationships require the most rigorous ongoing scrutiny.

The medium-risk tier includes vendors with periodic or limited access to sensitive data. These might be billing partners who receive data exports, analytics providers who access de-identified datasets, or software vendors who require occasional remote access for maintenance. The access is real, and the risk is meaningful, but the exposure surface is narrower, and the access is more controllable.

The lowest-risk tier covers vendors with no direct access to clinical systems or patient data. These relationships still require standard contractual security commitments, but they do not carry the same potential for catastrophic breach.

Most health systems apply roughly the same level of scrutiny to all three tiers. A formal vendor risk programme applies scrutiny proportional to actual exposure.

What a Genuine Vendor Risk Programme Requires

Building a vendor security programme that actually reduces breach risk rather than just satisfying compliance requirements involves four interconnected elements.

The first is a complete and current vendor inventory. Most health systems do not have one. Shadow IT, legacy integrations that were never formally documented, and vendor relationships established by individual departments without central oversight are all common. The inventory must capture not just who the vendor is, but what access they have, to which systems, under whose authority, and when that access was last reviewed.

The second is a risk classification system. Using the tier structure described above as a starting point, each vendor should be assigned a risk level that determines the intensity of security review required. High-risk vendors should be subject to independent security assessments, not self-attestation. Medium-risk vendors should receive periodic re-assessments rather than one-time questionnaires. Low-risk vendors require standard contractual commitments and basic ongoing monitoring.

The third is continuous monitoring rather than periodic review. Annual vendor questionnaires capture a point-in-time snapshot of a security environment that changes constantly. The vendors with the highest access to a health system's environment should be subject to ongoing monitoring that surfaces unusual access patterns, credential anomalies, and potential indicators of compromise in real time rather than waiting for an annual review cycle to reveal a problem that has been developing for months.

The fourth is incident response integration. When a vendor is compromised, the health system needs a pre-planned response that addresses how vendor access is suspended, how the extent of any data exposure is assessed, and how affected parties are notified. Most health system incident response plans are written around internal breaches. Vendor breach response requires a separate set of protocols that most organisations have not developed.

The Practical Steps

For health systems that want to close this gap without building an entirely new security programme from scratch, the starting point is an honest assessment of the current vendor landscape.

Map every vendor relationship that involves access to patient data or clinical systems.

Identify which of those relationships has received a meaningful security assessment in the last 12 months, as opposed to a completed self-attestation form. The gap between those two numbers is the starting point for prioritisation.

For the highest-risk vendors, commission independent security assessments from a qualified third party rather than relying on vendor-completed questionnaires. These assessments are an operational requirement, not a regulatory nicety.

For the medium and lower-risk tiers, build a structured re-assessment cycle that surfaces changes in the vendor's security posture before they create exposure. A vendor who was well-managed two years ago may have changed their infrastructure, their staff, or their own vendor relationships in ways that have introduced new risk.

Finally, ensure that vendor access management is integrated into the health system's identity and access management infrastructure. Every vendor with network access should have credentials that are actively monitored and that can be suspended immediately in the event of a suspected compromise. This is a technical control that most health systems have not fully implemented for their entire vendor population.

The Gap Is a Choice

The 88% breach figure is not going to improve on its own. The vendor ecosystem that healthcare organisations operate within is growing in size and complexity with every new clinical tool, every new analytics platform, and every new integration that connects disparate parts of the system.

Managing that ecosystem with BAAs and annual self-assessments was never going to be sufficient. The only question is whether healthcare organisations decide to address the gap before a breach makes the decision for them.

The organisations that have built genuine vendor risk management programmes are not doing anything exotic. They are applying the same rigour to their external attack surface that they already apply to their internal one.

That is a decision every health system can make today.