Why Your EHR Vendor’s Security Is Your Compliance Problem

On February 21, 2024, Change Healthcare — a subsidiary of UnitedHealth Group and one of the largest health IT clearinghouses in the United States — was hit by a ransomware attack that effectively froze claims processing for thousands of hospitals, physician practices, and pharmacies across the country. The attackers entered through a Citrix portal that lacked multi-factor authentication. The breach affected an estimated one in three Americans. Months later, providers were still absorbing the financial fallout, with the American Hospital Association estimating the average impact on individual hospitals at nearly $10.9 million.

Change Healthcare did not operate inside your network. But if your organization processed claims through their platform, the breach was your problem — operationally, financially, and under HIPAA, potentially your compliance problem too.

This is the defining reality of third-party health IT risk: the vendors you trust with PHI carry your liability with them. Their security posture is not separate from yours. It is an extension of it.

The Numbers Behind the Risk

The Change Healthcare incident was extreme in scale but not unusual in kind. According to the Ponemon Institute’s 2023 Third-Party Risk in Healthcare report, 55% of healthcare data breaches now originate from a third-party vendor — a figure that has grown steadily as healthcare organizations have expanded their digital ecosystems. The same report found that 60% of organizations do not conduct a security assessment of a vendor before signing a contract granting PHI access, relying instead on attestations, questionnaires, and the assumption that a signed BAA is sufficient protection.

It is not.

A Business Associate Agreement is a legal instrument. It establishes liability and notification obligations. It does not create security controls, patch vulnerabilities, enforce MFA policies, or prevent a ransomware actor from exploiting an unprotected Citrix gateway. The gap between what a BAA requires on paper and what a vendor’s security program delivers in practice is where breaches happen — and where OCR investigations begin.

What HIPAA Actually Requires of You

The HIPAA Security Rule does not permit covered entities to outsource their compliance obligations to their vendors. Under 45 CFR §164.308(b), covered entities are required to obtain satisfactory assurances that business associates will appropriately safeguard PHI — and the word “satisfactory” carries weight. HHS has made clear through enforcement actions that a signed BAA alone does not constitute satisfactory assurance. Organizations are expected to conduct due diligence, monitor vendor compliance, and take action when risks are identified.

This creates a direct accountability chain. If a vendor experiences a breach and OCR investigates, one of the first questions will be: what did you know about this vendor’s security posture, and when did you know it? If the answer is “we had a BAA and an annual questionnaire,” that is unlikely to satisfy an investigator who finds that the vendor had known, unpatched vulnerabilities and no meaningful security testing program.

“Covered entities cannot contract away their HIPAA obligations. A business associate agreement is a floor, not a ceiling — and organizations that treat it as the entirety of their vendor risk program are exposed.”

— HHS Office for Civil Rights, Guidance on Business Associates, 2023

The Vendor Attack Surface You’re Not Seeing

Health IT vendor relationships are not simple bilateral arrangements. Your EHR vendor has subcontractors. Your revenue cycle management platform integrates with clearinghouses. Your telehealth solution connects to third-party credentialing and scheduling systems. Each of those relationships is a potential PHI exposure point — and most of them are invisible to your security team.

Wiz’s 2023 Cloud Security Report found that the average enterprise has PHI flowing through more than 1,500 third-party vendor relationships when the full supply chain is mapped. In healthcare specifically, the connectivity between systems is deep and often undocumented. An EHR vendor may have a dozen integration partners who each have their own cloud infrastructure, their own access control policies, and their own security track record — or lack thereof.

The attack path is straightforward. A threat actor identifies a smaller, less security-mature vendor in your health IT supply chain — a scheduling integration, a billing platform, a referral management tool. They compromise that vendor’s environment, which has legitimate, credentialed access to your EHR or claims system. From there, they access PHI without ever touching your perimeter, your firewall, or your endpoint detection tools. The access is authorized. The session looks normal. The breach may not be discovered for weeks.

This is not a hypothetical scenario. It is the documented attack pattern behind a significant and growing share of healthcare breaches.

The Vendor Assessment Gap

Most healthcare organizations rely on one of three mechanisms to assess vendor security: the signed BAA, an annual security questionnaire returned by the vendor, or a SOC 2 report. Each of these has meaningful limitations.

The BAA, as discussed, is a legal document — not a security control. Annual questionnaires are self-reported, rarely verified, and typically lag actual security posture by months. SOC 2 reports assess controls against a framework at a point in time; they do not tell you whether the vendor has unpatched critical CVEs in their external infrastructure, whether their cloud storage is misconfigured, or whether their staff are using MFA on the systems that access your data.

What most organizations are not doing — and what their vendors are almost never asked to demonstrate — is independent, adversarial validation of their security posture. That means penetration testing of the systems that handle your PHI, verification that the controls described in questionnaires are actually implemented, and ongoing monitoring of the vendor’s external attack surface for changes that might introduce new risk.

8 Questions to Ask Every Health IT Vendor

These eight questions should be part of every vendor onboarding process, and revisited annually for vendors with access to PHI. The answers should be documented, verified where possible, and treated as a living part of your vendor risk management program — not a checkbox completed at contract signature and filed away.

Pay particular attention to questions two and four. A vendor who cannot tell you when they last underwent independent penetration testing — or who cannot produce even a high-level summary of findings and remediation — is a vendor whose security program exists primarily on paper. A vendor who cannot articulate a specific contractual breach notification timeline is a vendor whose incident response process is not mature enough to meet HIPAA’s requirements.

What a Mature Third-Party Risk Program Looks Like

Closing the vendor security gap in healthcare requires moving beyond documentation-based assurance toward evidence-based assurance. That distinction matters more than any other in this space.

Documentation-based assurance is a vendor completing your security questionnaire and attesting that MFA is enabled. Evidence-based assurance is independently verifying that MFA is actually enforced on the systems that access your PHI — and understanding what happens if it is not.

A mature program operates at three levels. At the contracting stage, security requirements are specific and measurable: penetration testing frequency, patch SLAs for critical CVEs, encryption standards, breach notification timelines. At the onboarding stage, those requirements are verified — not just attested to — through documentation review, examination of recent test results, and where the vendor is high-risk, direct assessment of their external attack surface. And on an ongoing basis, the vendor’s external presence is monitored for changes: new subdomains, new services, configuration changes that might introduce risk.

For your highest-risk vendors — those with direct, real-time access to large volumes of PHI — consider requiring evidence of continuous penetration testing rather than annual point-in-time assessments. A vendor operating a continuous security program generates a living record of their security posture over time, not a snapshot that may be six or twelve months stale by the time you need to rely on it.

Key Takeaways for Security Leadership

The Change Healthcare breach did not happen because of a failure inside a hospital’s network. It happened because of a failure inside a vendor’s network — and it cascaded into a crisis that affected the entire healthcare system. That is the nature of third-party risk in health IT: the failure point is not yours, but the consequences are.

HIPAA holds covered entities accountable for the security practices of their business associates. OCR has signaled, through enforcement action and published guidance, that this accountability extends beyond the signed BAA. Organizations that can demonstrate genuine, ongoing oversight of their vendor relationships — verified security assessments, contractual security requirements, continuous monitoring, and documented remediation follow-through — are in a materially stronger position both to prevent breaches and to defend against regulatory scrutiny when incidents occur.

Your EHR vendor’s security is not their problem to manage in isolation. Under HIPAA, it is yours to oversee. The question is whether your vendor risk program reflects that reality.

Ready to assess the security posture of your most critical health IT vendors?Learn more at sprocketsecurity.com or reach out at contact@sprocketsecurity.com.