When MCBS LLC disclosed a breach affecting 1.3 million patients, the resulting class action lawsuit highlighted the medical billing firm's "inadequately protected computer systems." This phrase is common in third-party breach lawsuits, yet healthcare organizations continue to make the same vendor risk management mistakes.
Here's why these errors persist and how to fix them before your next audit or breach notification.
Why These Mistakes Keep Happening
Healthcare entities face a structural problem: you're accountable under HIPAA for your business associates' security, but you don't control their infrastructure. The Health Insurance Portability and Accountability Act and HITECH Act emphasize this through breach notification requirements and enforcement actions. Yet, many organizations treat vendor risk as a checkbox exercise rather than continuous oversight.
The extortion group PEAR exploited this gap at MCBS by using legitimate remote management tools like AteraAgent and Splashtop Remote Service. Your vendor assessments probably wouldn't have caught this because these are authorized administrative tools. The group accessed the network through compromised VPN credentials and exfiltrated 3.3 terabytes of data without triggering traditional malware detection.
That's the disconnect: your vendor questionnaires ask about antivirus and firewalls while attackers use your vendors' own tools against them.
Mistake 1: Treating BAAs as Risk Management
Why it happens: Your legal team executes a Business Associate Agreement (BAA), files it, and your compliance team marks third-party risk as "complete." The BAA becomes a substitute for technical validation.
The consequence: A BAA is a contract, not a control. It establishes liability and notification obligations, but it doesn't prevent unauthorized access. When MCBS faced its federal class action lawsuit, the BAA didn't matter to the plaintiffs or the 1.3 million affected patients. The contract creates legal recourse after a breach, not protection before one.
The fix: Separate your contract review from your technical assessment. After executing the BAA, require evidence of specific HIPAA Security Rule controls:
- Access control implementation (§164.312(a)(1))
- Audit controls for system activity (§164.312(b))
- Transmission security for ePHI (§164.312(e)(1))
- Workstation security controls (§164.310(c))
Request SOC 2 Type II reports covering security and availability. If the vendor can't provide attestation reports, require third-party penetration test results from the past 12 months. Map their controls to HITRUST CSF requirements if you're pursuing that certification.
Mistake 2: Annual Assessments for Continuous Access
Why it happens: You inherited a vendor risk program built around annual questionnaire cycles. Your team sends the same security assessment once a year, receives it back, scores it, and moves to the next vendor. The billing company you assessed in January could be compromised by March.
The consequence: PEAR gained initial access to MCBS through compromised VPN credentials. This is a credential management failure that develops over time as employees leave, contractors lose devices, or phishing campaigns succeed. Your annual questionnaire from nine months ago is irrelevant to today's access patterns.
The fix: Implement continuous monitoring for vendors with direct access to ePHI or your network:
- Require quarterly attestations for privileged account reviews
- Monitor vendor-owned IP addresses against threat intelligence feeds
- Establish automated alerts for dark web mentions of vendor domains
- Review vendor security incidents through your shared information sharing and analysis organization
For critical vendors like billing companies, medical device manufacturers, or EHR platforms, negotiate the right to conduct unannounced security assessments. Include this provision in your BAA during initial contracting.
Mistake 3: Ignoring "Living Off the Land" Detection Gaps
Why it happens: Your security team focuses on malware signatures and known bad indicators. You assume your endpoint detection and response tools will catch malicious activity because they caught the last ransomware attempt.
The consequence: PEAR uses legitimate tools that your security operations center sees every day: PsExec for remote execution, RClone for file transfers, credential dumping utilities that administrators use for password resets. At-Bay's research notes this creates a "detection dilemma for defenders" because every tool has legitimate administrative purposes. Your vendor's security team sees these tools running and assumes they're authorized.
The fix: Require vendors to implement behavior-based detection, not just signature-based tools. Specifically, demand evidence of:
- User and Entity Behavior Analytics that flag unusual data access patterns
- Data Loss Prevention rules for large file transfers to external destinations
- Privileged Access Management that requires approval workflows for administrative tools
- Network segmentation that limits lateral movement even with compromised credentials
During your technical assessment, ask: "If an attacker used your own remote management tools, how long would it take you to detect 3.3 terabytes leaving your network?" If the vendor can't answer with a specific time frame and detection method, escalate this as a critical finding.
Mistake 4: No Incident Response Integration
Why it happens: Your incident response plan covers internal breaches. Your vendor's incident response plan covers their environment. Nobody has documented how these plans connect when a vendor breach exposes your patients' data.
The consequence: MCBS detected unauthorized access on Sept. 25, 2025, but the breach window ran from Sept. 22 to Sept. 26. Somewhere in that timeline, MCBS had to determine which clients were affected, what data was compromised, and how to coordinate notifications. If you were one of those seven medical practices, you were probably learning about the breach at the same time as your patients.
The fix: Build vendor incident response integration into your Computer Security Incident Response Team procedures:
- Require vendors to notify you within four hours of detecting potential ePHI access
- Establish a joint communication protocol with primary and backup contacts
- Conduct annual tabletop exercises that include your critical vendors
- Pre-negotiate forensic investigation access and evidence preservation procedures
Document these requirements in your BAA under the breach notification section. The HITECH Act's 60-day notification timeline to affected individuals starts when you discover the breach, not when the vendor tells you about it. Delayed vendor notification becomes your compliance failure.
Mistake 5: Treating All Vendors Equally
Why it happens: Your vendor risk program applies the same assessment framework to your medical billing company that processes 1.3 million patient records and your coffee supplier. You're being "consistent" across vendors.
The consequence: You waste resources assessing low-risk vendors while under-investing in critical business associates. Your billing company has the same assessment frequency as your office supplies vendor, even though the billing company maintains Social Security numbers, dates of birth, health insurance policy numbers, medical history, mental or physical condition, medical treatment information, and diagnosis information.
The fix: Implement a tiered vendor classification system:
Tier 1 - Critical Business Associates: Direct ePHI access, processes large patient volumes, or provides essential clinical services. Examples: billing companies, EHR vendors, lab systems. Assessment frequency: Quarterly technical reviews, annual SOC 2 Type II validation, continuous monitoring.
Tier 2 - Standard Business Associates: Limited ePHI access or specific use cases. Examples: medical transcription, cloud backup providers, patient portal vendors. Assessment frequency: Semi-annual questionnaires, biennial penetration testing.
Tier 3 - Low-Risk Vendors: No ePHI access, no network connectivity. Examples: office suppliers, facilities management. Assessment frequency: Annual contractual review only.
Allocate your budget accordingly. If you're spending equal time on all vendors, you're under-protecting your critical business associates.
Prevention Checklist
Use this checklist before onboarding new business associates or during your next vendor review cycle:
- BAA executed with specific HIPAA Security Rule control requirements
- SOC 2 Type II report received and reviewed within past 12 months
- Vendor classified by tier with appropriate assessment frequency documented
- Continuous monitoring established for Tier 1 vendors (threat intelligence, dark web monitoring)
- Behavior-based detection requirements validated, not just signature-based tools
- Network segmentation confirmed for vendor access to ePHI
- Privileged Access Management controls verified for administrative tools
- Incident response integration tested through tabletop exercise
- Four-hour breach notification requirement documented in BAA
- Quarterly privileged account review process confirmed
- Right to audit clause included in contract with defined scope
- Data Loss Prevention rules validated for large file transfers
- Vendor security incident history reviewed for past 24 months
- Joint communication protocol established with backup contacts
- Forensic investigation access pre-negotiated in contract
The MCBS breach affected seven healthcare practices because those organizations relied on a business associate's security. Your vendor risk program needs to assume that reliance comes with continuous verification, not annual questionnaires. The 1.3 million affected patients and the federal class action lawsuit are the cost of treating vendor risk as a compliance checkbox instead of an operational discipline.
