These questions surfaced in multiple discussions after the MCBS breach hit the news. A medical billing firm, 1.3 million patient records, and an extortion gang that doesn't even bother encrypting files anymore. These aren't theoretical questions. They're from compliance leads trying to figure out what to do differently tomorrow.
Do I Need to Audit Every Vendor That Touches Patient Data?
Yes, but the depth of the audit depends on their access level.
Under the Health Insurance Portability and Accountability Act (HIPAA), you must have business associate agreements with any vendor handling protected health information. That's the contract part. The operational part is due diligence.
For vendors with direct database access or administrative privileges, like medical billing firms, you need evidence of their security controls. Request their SOC 2 Type II report if available. If not, that's a red flag for a vendor handling 1.3 million patient records. At minimum, review their incident response plan, access control policies, and network segmentation documentation.
For lower-risk vendors, like a marketing platform handling only de-identified data, annual attestations and contract terms might suffice. Document why you chose each approach. When the Office for Civil Rights (OCR) investigates a breach, they'll ask about your due diligence before signing the contract.
How Can I Detect Attacks Using Legitimate Admin Tools?
You can't rely on signature-based detection; you need behavioral baselines.
PEAR's approach, using tools like AteraAgent, Splashtop, PsExec, and RClone, is called "living off the land." It works because these tools have valid administrative uses. Your security team probably uses some of them. The difference is context.
Start with privileged access monitoring. If someone installs Splashtop on a server that's never had remote access software, that's anomalous. If RClone starts transferring terabytes of data at 2 AM from a database server, that's anomalous. If credentials authenticated from your office in Atlanta suddenly appear on a VPN login from Romania, that's anomalous.
You need a security information and event management system or endpoint detection tool that can correlate these signals. Configure alerts for:
- New remote access software installations on production systems
- Bulk file transfers exceeding normal patterns
- Credential use from unexpected geolocations
- PsExec execution outside of approved change windows
None of these signals alone proves an attack, but together, they create an investigation trigger.
What's the Timeline for Notifying Patients After a Breach?
You have 60 days from when you discover the breach, but discovery timing matters.
The Health Information Technology for Economic and Clinical Health Act requires notification "without unreasonable delay and in no case later than 60 calendar days" after discovery. MCBS detected unauthorized access on September 25, 2025, and filed their breach report in 2026, which appears to fall within that window.
The clock starts when you discover the breach, not when the attack occurred. MCBS's investigation determined the threat actor accessed files between September 22 and September 26. They discovered it on September 25. The 60-day countdown started September 25.
If your investigation takes three weeks to determine what data was accessed, you've got 39 days left to notify patients. This is why you need a documented incident response plan with defined investigation procedures. You can't pause the regulatory clock while you figure out what happened.
For breaches affecting 500 or more individuals, you also notify the Department of Health and Human Services (HHS) and prominent media outlets. For smaller breaches, you report to HHS annually.
Should I Be Worried About Extortion Gangs That Don't Encrypt Files?
Yes, because you might not notice them as quickly.
Traditional ransomware announces itself. Systems lock up, users can't access files, and you know there's a problem. Extortion-only attacks like PEAR's can run for days while the threat actor exfiltrates data. MCBS's breach window was September 22-26, meaning the attacker potentially had four days of access before detection.
The risk model shifts from availability (can we restore from backups?) to confidentiality (what did they take?). You can't restore stolen data. Once PEAR posted 3.3 terabytes on their dark web site, that information is compromised permanently.
Your detection strategy needs to focus on data exfiltration, not just system encryption. Monitor outbound traffic volumes, especially from database servers and file shares. Implement data loss prevention rules for sensitive data patterns. Review firewall logs for unusual external connections.
And here's the practical piece: test your backup restoration process, but also test your ability to identify what data exists where. If you can't quickly answer "what patient data does this server contain," you can't scope a breach investigation in the 60-day notification window.
What Should I Ask in Vendor Security Questionnaires?
Ask for evidence, not attestations.
Most vendor questionnaires are checkbox exercises. "Do you encrypt data at rest?" Everyone says yes. What you need to know: "What encryption standard do you use, and can you provide evidence of implementation?"
For vendors with administrative access to your environment:
- How do you manage privileged credentials? (Look for Privileged Access Management tools, not shared admin passwords)
- What remote access tools are approved for your staff, and how are they monitored?
- Do you segment your network so client data isn't accessible from general corporate systems?
- What's your process for detecting compromised VPN credentials?
For vendors handling patient data:
- Where is data stored geographically?
- Who has access to production databases, and how is that access logged?
- What's your incident response plan, and when was it last tested?
- Have you had any security incidents in the past 24 months?
That last question matters. PEAR had targeted at least 51 victims across various industries with an average ransom demand of $550,000 as of February. If your vendor was on that list, you want to know what they learned and what they fixed.
How Do I Know If My Current Vendor Contracts Are Enforceable?
Read them, then have your legal team review the indemnification and liability clauses.
Many business associate agreements include liability caps that limit the vendor's financial exposure to a fraction of the contract value. If you're paying a billing vendor $200,000 annually and their liability cap is one year's fees, you're looking at $200,000 in coverage for a breach that could cost millions in notification, credit monitoring, and legal fees.
The MCBS breach already has at least one proposed federal class action lawsuit. Those costs don't fall on MCBS alone; depending on contract terms, their healthcare clients may face liability too.
Review these specific provisions:
- Liability caps and whether they apply to security incidents
- Indemnification (who pays for what if there's a breach)
- Insurance requirements (does the vendor carry cyber liability coverage, and what are the limits)
- Audit rights (can you review their security controls, or just ask for attestations)
- Breach notification obligations (how quickly must they tell you if they're compromised)
If your contracts don't address these points, you're operating on hope. Renegotiate before the next renewal, or at minimum, document the gap in your risk register.
Where Do I Go From Here?
Start with your business associate inventory. List every vendor that touches protected health information, categorize them by risk level, and document what due diligence you've performed. If you can't answer "what data does this vendor access" for each entry, that's your first project.
Then review your detection capabilities for the "living off the land" techniques: remote access tools, credential dumping, bulk data transfers. If you're relying entirely on antivirus signatures, you're not detecting modern extortion attacks.
The MCBS breach is the seventh largest health data breach reported in 2026 and the fifth largest involving a business associate. Third-party risk isn't a compliance checkbox anymore. It's the primary attack vector.
