When AdaptHealth disclosed to the SEC that a social engineering attack against a third-party contractor exposed patient data across their network of 600 locations serving 4.3 million patients annually, many healthcare risk teams responded predictably: "We have vendor assessments in place."
That confidence is the problem. Third-party risk management in healthcare has become a checkbox exercise, where teams believe they're protected because they completed a questionnaire or reviewed a SOC 2 Type II report. The myths below persist because they feel administratively sufficient, even when they leave gaping security holes.
Myth 1: Annual Vendor Assessments Provide Adequate Oversight
Reality: The AdaptHealth breach shows why point-in-time assessments fail. A compromised user session can happen any day of the year. Your annual vendor risk review, completed in January, tells you nothing about the contractor's security posture in September when an attacker successfully executes a social engineering campaign.
Continuous monitoring requirements exist in NIST SP 800-53 (control CA-7) and ISO/IEC 27001 (clause 8.1) for this reason. You need real-time visibility into vendor security events, not annual snapshots. Implement automated security posture monitoring that tracks your vendors' external attack surface, certificate expirations, domain reputation changes, and publicly disclosed incidents. When a vendor experiences a credential compromise or phishing campaign, you should know within hours, not when your next assessment cycle begins.
Myth 2: SOC 2 Reports Cover Third-Party Access Risks
Reality: A SOC 2 Type II report validates that a vendor has controls in place for their own environment. It doesn't address how that vendor's employees or contractors access your systems. The AdaptHealth incident involved external EHR portal access, a common integration point that falls outside standard SOC 2 scope.
Review your vendor contracts for access provisions. Does the SOC 2 report you received cover the specific systems your vendor accesses? Does it include controls for session management, multi-factor authentication on privileged accounts, and monitoring of third-party contractor activity? Most don't. You need supplemental security requirements that specifically address access to your environment, documented in your Business Associate Agreement under the Health Insurance Portability and Accountability Act or equivalent contract terms. Require vendors to implement Just-in-Time Access for administrative functions and log all privileged sessions with your data.
Myth 3: Social Engineering Is Primarily an End-User Problem
Reality: Healthcare organizations invest heavily in phishing simulations and security awareness training for their own staff, then assume vendors do the same. They don't, at least not consistently. The contractor whose session was compromised at AdaptHealth represents a common weak point: individuals with legitimate access credentials who receive minimal security training.
Your third-party risk assessment must include specific questions about the vendor's security awareness program for contractors and temporary staff. How frequently do they conduct phishing simulations? What is their click rate on simulated attacks? Do they require security training completion before granting access to client systems? These aren't optional; they're material risk factors. Under HIPAA Security Rule § 164.308(a)(5), you must have written contracts ensuring that business associates implement appropriate safeguards, which includes training personnel who handle electronic protected health information.
Myth 4: Cyber Insurance Transfers Third-Party Risk
Reality: AdaptHealth's SEC filing noted that the full financial impact of the breach remains unknown. Cyber insurance policies typically exclude losses from inadequate vendor management practices, and even when coverage applies, premiums increase substantially after a claim. More importantly, insurance doesn't prevent the breach or protect patient trust.
Your risk transfer strategy should focus on contractual liability provisions, not insurance as a primary control. Require vendors to carry appropriate cyber liability coverage, but also establish clear liability terms for breaches originating from their environment. Define notification timelines (the 72-Hour Notification Requirement provides a reasonable baseline even for U.S. organizations), forensic investigation responsibilities, and indemnification provisions. Document these requirements in your vendor risk tier definitions so high-risk vendors, those with access to protected health information or electronic health records, face appropriately stringent terms.
Myth 5: IT Security Handles Vendor Risk Management
Reality: When a breach occurs through a third-party contractor, the impact spans compliance, legal, operations, and finance. AdaptHealth's $3.2 billion in net revenue for fiscal 2025 faces potential regulatory penalties, litigation costs, patient notification expenses, and reputational damage. Yet many organizations still treat vendor risk as an IT security function.
Effective third-party risk management requires cross-functional governance. Your vendor risk committee should include procurement, legal, compliance, information security, and business unit leaders. Each brings necessary perspective: procurement understands contract leverage, legal manages liability exposure, compliance tracks regulatory requirements like HIPAA Privacy Rule § 164.524 for patient access rights, and business units understand operational dependencies. The NIST Cybersecurity Framework (CSF) 2.0 function "Govern" explicitly addresses third-party risk oversight as an enterprise responsibility, not a technical one.
What to Do Instead
Build a risk-tiered vendor management program that matches oversight intensity to actual risk exposure. Vendors with access to protected health information, financial systems, or critical infrastructure require quarterly security reviews, continuous monitoring, and annual penetration testing of integration points.
Implement technical controls at the integration layer. Even if a vendor's environment is compromised, Zero Trust Architecture principles limit lateral movement. Require vendors to authenticate through your identity provider, restrict access to specific data sets through Role-Based Access Control, and monitor all vendor sessions for anomalous behavior.
Document your third-party risk management program in your Statement of Applicability if you maintain ISO/IEC 27001 certification, mapping vendor controls to Annex A requirements 5.19 through 5.23. For HITRUST CSF assessments, address the entire third-party management control category with evidence of your tiered approach, continuous monitoring capabilities, and incident response coordination procedures.
The AdaptHealth breach should prompt one question: if a contractor's compromised session exposed your patients' data tomorrow, what would your investigation reveal about your vendor oversight program?
