You've secured your network, trained your staff on phishing, and passed your last Security Rule risk analysis. Then your vendor gets compromised, and you're notifying 28,000 patients anyway.
That's what happened to LHC Group in April 2026, when a voice phishing attack on one employee gave a threat actor eight days of access to a vendor platform holding patient referrals, care plans, and Social Security numbers. The vendor managed clinical workflows for a multi-state home health provider, which meant it touched exactly the kind of data the Breach Notification Rule was written to protect.
This wasn't an outlier. Provident Behavioral Health, Central Arkansas Pediatrics, and Elixir Medical Corporation all reported breaches within the same period, each involving unauthorized access to systems holding Protected Health Information (PHI) or employee records. The pattern is consistent: third-party access creates exposure, and most organizations don't find out until the damage is done.
Why These Mistakes Keep Happening
You inherit your vendor's security posture the moment you grant them access to ePHI. But most Business Associate Agreements (BAAs) treat vendor risk as a paperwork exercise, not an operational control. You sign the BAA, check the box, and move on.
The Security Rule requires you to implement policies and procedures for evaluating Business Associates (§ 164.308(b)(1)), but it doesn't prescribe how to evaluate them. So teams default to questionnaires, attestations, and annual reviews that measure compliance theater instead of actual security capability. By the time you learn your vendor's multi-factor authentication (MFA) was optional or their logging was inadequate, you're already drafting breach notices.
Mistake 1: Treating the BAA as the Security Control
Why it happens: The BAA is a legal document. It creates liability and defines responsibilities, but it doesn't prevent unauthorized access. Teams assume that signing a BAA means the vendor is secure, when all it really means is that the vendor has agreed to be secure.
Real consequence: LHC Group's vendor had access to referral management and clinical workflow data for patients across 28 states. When an LHC employee fell victim to voice phishing, the attacker used stolen credentials to access the vendor platform from April 7 through April 15, 2026. The BAA didn't stop the breach; it just determined who had to send the notifications.
The fix: Separate your legal review from your technical assessment. Before you grant a vendor access to ePHI, require evidence of specific controls: MFA enforcement logs, vulnerability scan results, incident response runbooks, and access review procedures. If the vendor can't produce evidence, don't grant access. If they're already integrated, conduct a gap assessment and set a remediation deadline. Document everything in your vendor risk register, not just in the contract file.
Mistake 2: Assuming Your Training Protects Their Employees
Why it happens: You've invested in phishing simulations, security awareness modules, and incident response drills for your workforce. It's easy to assume your vendors have done the same. They haven't.
Real consequence: The LHC breach started with a voice phishing attack against an LHC employee, but the compromise happened on the vendor's platform. Your employee's credentials became the entry point because the vendor's system accepted them without sufficient authentication controls. You can train your staff perfectly and still inherit risk from a vendor whose employees click every link.
The fix: Require vendors to provide annual training completion rates, phishing simulation results, and evidence of role-based security training for anyone with access to your ePHI. During onboarding, ask how they handle social engineering attempts and what their escalation process looks like. If they can't answer, that's your signal to either impose stricter access controls or find a different vendor. At minimum, enforce MFA on every vendor account that touches your environment, and monitor vendor logins for anomalies in real time.
Mistake 3: Granting Persistent Access Instead of Time-Boxed Privileges
Why it happens: It's operationally easier to give a vendor standing access than to provision and deprovision accounts based on project phases. So you grant access once and leave it open indefinitely.
Real consequence: The threat actor in the LHC breach had access to the vendor platform for eight days. That's eight days to enumerate files, identify high-value data, and exfiltrate clinical summaries, treatment plans, diagnosis codes, Medicare numbers, and Social Security numbers. Persistent access turns a credential compromise into a data breach.
The fix: Implement time-bound access for vendor accounts. If a vendor needs access for a three-month implementation, provision the account with a hard expiration date. Use privileged access management (PAM) tools to enforce just-in-time access for sensitive systems. Require vendors to request access renewal with a business justification, and review all vendor accounts quarterly. Disable accounts immediately when the contract ends or the project closes. This isn't about trust; it's about reducing the window of exposure when credentials inevitably get compromised.
Mistake 4: Relying on Annual Reviews to Detect Active Threats
Why it happens: The Security Rule requires periodic evaluation of Business Associates, and most organizations interpret "periodic" as annual. You send a questionnaire in Q4, the vendor returns it in Q1, and you file it until next year.
Real consequence: LHC Group became aware of suspicious activity on April 7, 2026, the same day the vishing attack occurred. But the investigation and data review took until July 9 to confirm affected individuals. If your vendor review cycle runs annually, you won't detect a compromise until your next scheduled assessment, which could be months after the breach.
The fix: Shift from annual reviews to continuous monitoring. Require vendors to report security incidents within 24 hours, not when it's convenient. Integrate vendor systems into your SIEM or log aggregation platform so you can detect anomalies in real time. Conduct quarterly access reviews to identify dormant accounts or privilege creep. If a vendor experiences a breach, trigger an immediate re-assessment and consider suspending access until you've validated their remediation. Annual reviews measure compliance; continuous monitoring detects threats.
Mistake 5: Failing to Scope Vendor Access to Minimum Necessary Data
Why it happens: Vendors ask for broad access to make integration easier, and you grant it because limiting access requires custom configuration, data segmentation, and ongoing maintenance.
Real consequence: The LHC vendor platform held clinical summaries, treatment plans, diagnosis codes, physician information, insurance details, and Social Security numbers. When the platform was compromised, all of that data was exposed. If the vendor had been limited to referral coordination data only, the breach would have been smaller and the notification obligations reduced.
The fix: Apply the minimum necessary standard to vendor access, not just to internal disclosures. Before you grant access, map exactly what data the vendor needs to perform their function. If they're managing referrals, they don't need treatment plans. If they're processing claims, they don't need clinical notes. Use data segmentation, role-based access controls, and API-level restrictions to enforce those limits. Document your minimum necessary determination in the BAA and audit vendor data access quarterly to ensure they're staying within scope.
Prevention Checklist
- Require vendors to provide evidence of MFA enforcement, vulnerability management, and incident response procedures before granting ePHI access
- Separate BAA execution from technical security assessment; do not treat the contract as proof of security
- Implement time-bound access with hard expiration dates for vendor accounts; disable access immediately when projects close
- Require vendors to report security incidents within 24 hours and trigger immediate re-assessment when breaches occur
- Integrate vendor systems into your SIEM or log aggregation platform for real-time anomaly detection
- Conduct quarterly access reviews to identify dormant vendor accounts and privilege creep
- Apply minimum necessary standard to vendor data access; document scope in BAA and audit compliance quarterly
- Require annual training completion rates and phishing simulation results from vendors with ePHI access
- Use privileged access management (PAM) tools to enforce just-in-time access for sensitive vendor operations
- Maintain a vendor risk register with technical findings, remediation deadlines, and access scope documentation
By addressing these common mistakes, you and your team can significantly reduce the risk of third-party breaches and protect your patients' sensitive information.
