Ask a patient who has access to their health records and they’ll name their dentist, maybe their insurer. They won’t say DentaQuest. They won’t say MCBS. Most people have never heard of either company, and yet this year both just confirmed breaches that together touched roughly 24 million people’s dental and medical information. That’s the uncomfortable truth sitting underneath a lot of cybersecurity coverage right now: the biggest data exposure risk in healthcare isn’t the provider you see. It’s the vendor behind the vendor, the one processing your claims, managing your billing, running the systems nobody outside the industry has ever noticed.

DentaQuest disclosed that hackers pulled personal and dental health information from its network in an intrusion that started back in May. Separately, MCBS, a medical business management company, says roughly 1.2 million individuals had their data exposed after the PEAR ransomware group claimed to have stolen 3 terabytes of records. Neither company is a household name. Both sit deep inside the plumbing of the healthcare system, which is exactly why they’re such attractive targets.

The Front Door Was Never the Problem

For years, healthcare security conversations centered on hospitals and insurers: their firewalls, their patch cycles, their phishing training. That focus made sense when those organizations held the data directly. It makes a lot less sense now that so much of the actual data lives one or two contractual layers removed, with dental benefit administrators, billing processors, claims clearinghouses, and practice management vendors that most patients can’t name and didn’t choose.

These companies are what HIPAA calls business associates rather than covered entities, and that label matters more than it should. A business associate can hold identical data to the provider it serves, sometimes aggregated across dozens of client organizations, while operating under security programs that were never independently vetted by the patients whose information they’re storing. Nobody signed a consent form that said “and also this billing vendor you’ve never met.”

Cybersecurity Programs Don’t Extend Past the Contract

Here’s the part that should bother security leaders more than it seems to: a covered entity’s threat detection, incident response, and security hardening efforts almost always stop at the edge of its own network. Once data crosses into a vendor relationship, oversight becomes a compliance exercise. A questionnaire gets filled out once a year. A SOC 2 report gets filed away. Nobody’s actually watching whether that vendor patches on schedule, segments its network, or has brute-force protections on the systems holding your records.

What “Business Associate” Actually Means in Practice

In plain terms, a business associate is any vendor that touches protected health information on behalf of a covered entity, think claims processors, billing companies, benefit administrators, even some cloud hosting providers. HIPAA requires a business associate agreement, but that agreement is a legal document, not a security control. It obligates the vendor to “implement appropriate safeguards.” It does not mandate specific firewall configurations, specific detection tooling, or specific incident response timelines beyond notification. Two companies can both sign an identical BAA and land at wildly different levels of actual defense in depth.

That gap is where PEAR and groups like it live. Ransomware crews don’t care whether their target is a hospital system or a back-office biller. They care about the size of the data pool and the strength of the defenses standing between them and it. Increasingly, the back-office vendor is the softer target holding the bigger pool.

Software Supply Chains Get a Cooldown. Data Supply Chains Don’t.

It’s worth noticing what GitHub just did with Dependabot. The platform now waits at least three days after a package release before opening an automated pull request to adopt it, specifically to reduce the chance that a newly published, still-unvetted package gets pulled into production before anyone’s had a chance to notice it’s malicious. It’s a small feature, but it reflects a real principle: new trust relationships in a software supply chain deserve a pause, a window for scrutiny before you extend access.

Healthcare’s vendor supply chain has no equivalent pause. A new billing processor, benefits administrator, or practice management platform can get plugged into a provider’s systems, granted API access, and start moving patient data within days of a signed contract. There’s no cooldown period. There’s no default requirement to demonstrate active threat detection or incident response maturity before the data starts flowing. The industry built elaborate rules around who’s allowed to see the data and almost none around how well the companies holding it can actually defend it.

Mary Rose Martinez, CISO at Marathon Petroleum, made a related point in a recent interview about operational technology: vendors and their vendors increasingly hold the keys, and supply chain risk doesn’t stop at your direct contractor, it runs through everyone they depend on too. Healthcare has the same nested dependency problem, just with medical records instead of pipeline controls.

Hardening a Vendor Relationship You Don’t Fully Control

You can’t force a business associate to run your security program. You can build enough structure around the relationship that a breach on their end doesn’t become an open-ended disaster on yours.

1. Tier vendors by data sensitivity and access scope, not by contract size, and apply your strictest scrutiny to anyone holding aggregated records across multiple clients.
2. Put specific security requirements in the contract: encryption at rest and in transit, logging retention, threat detection capability, and a hard breach notification SLA measured in days, not “as soon as reasonably possible.”
3. Negotiate a right to audit, and actually use it. An unused audit clause is just decoration.
4. Segment vendor access so a compromised billing system can’t reach your clinical systems or vice versa. Least privilege applies to vendor API keys just as much as employee accounts.
5. Require evidence of basic security hardening: patch cadence, brute-force protections on exposed logins, MFA on administrative access.
6. Build the vendor into your incident response plan before there’s an incident. Know who you call, what data they hold, and what your notification obligations look like the moment they call you instead.

None of this is exotic. It’s the same threat-protection discipline you’d apply to your own network, extended outward to the places your data actually lives.

Frequently Asked Questions

Why do business associates like DentaQuest or MCBS hold so much data in the first place?

They perform functions covered entities outsource, like dental benefits administration or medical billing, which requires access to claims and patient records across potentially dozens of client organizations. That aggregation is exactly what makes them attractive breach targets.

Does HIPAA require these vendors to meet the same security standard as hospitals?

HIPAA requires “appropriate safeguards” under a business associate agreement, but it doesn’t mandate specific technical controls like particular firewall rules or detection tooling, so actual security posture varies significantly between vendors.

What can a healthcare organization do if it can’t control a vendor’s internal security?

Focus on what you can control: contractual security requirements, audit rights, network segmentation that limits blast radius, and an incident response plan that already accounts for that vendor before anything goes wrong.

Sources

• DentaQuest Data Breach Potentially Impacts Over 23 Million People
• MCBS Data Breach Affects 1.2 Million Individuals
• GitHub Adds 3-Day Dependabot Cooldown to Limit Poisoned Package Adoption
• Marathon Petroleum’s CISO on OT security automation, supply chain risk