These myths persist because third-party risk management sits between your security team's control and your vendors' promises. When ShinyHunters claimed the theft of 284 million records from McKesson through third-party applications, it confirmed what many privacy officers suspected: conventional wisdom about vendor risk is dangerously outdated.
You're managing an expanding attack surface that includes SaaS platforms, cloud storage, and specialty applications, yet your risk assessments still treat third-party access as a yes/no question. Let's dismantle the myths that create this gap.
Myth 1: "Our Business Associate Agreement transfers the liability"
Reality: A BAA documents obligations; it doesn't eliminate your responsibility under the HIPAA Security Rule.
When unauthorized access occurs through a third-party application, you remain the Covered Entity responsible for safeguarding ePHI. The Security Rule's administrative safeguards at 45 CFR § 164.308(b) require you to obtain satisfactory assurances that the Business Associate will appropriately safeguard ePHI, but that requirement doesn't end with a signed contract.
McKesson disclosed in its SEC filing that the breach "involved third-party applications and unauthorized access and exfiltration of data." The BAA with those application providers didn't prevent the incident, and it won't shield McKesson from OCR scrutiny of whether the company conducted adequate due diligence before granting access to ePHI.
Your BAA creates a legal framework for breach notification and cooperation. It does not absolve you of the duty to assess whether the vendor's security controls meet the standards you're required to implement. If you can't demonstrate that you evaluated the vendor's safeguards before sharing ePHI, the BAA becomes evidence of negligence, not protection from it.
Myth 2: "We've assessed the vendor once; we're covered"
Reality: Point-in-time assessments miss configuration drift, new integrations, and evolving threat tactics.
The group behind the McKesson incident, ShinyHunters, gained access between August 21 and August 25, 2026. Your vendor assessment from eighteen months ago didn't account for the Salesforce environment configuration that existed on August 21, the Snowflake access controls in place that week, or the social engineering tactics ShinyHunters refined in recent campaigns against healthcare targets including Medtronic, Abbott Laboratories, and DentaQuest.
Third-party risk isn't static. Vendors add integrations, migrate to new infrastructure, and rotate personnel with administrative access. Each change creates new exposure that your initial assessment didn't contemplate.
Effective ongoing monitoring includes quarterly reviews of access logs, annual re-validation of security controls, and immediate notification requirements when the vendor experiences a security incident or makes material changes to its environment. The Security Rule's evaluation standard at 45 CFR § 164.308(a)(8) requires periodic technical and nontechnical evaluation, not a one-time checkbox.
Myth 3: "The vendor's SOC 2 report means they're secure"
Reality: SOC 2 reports describe controls; they don't validate security outcomes or detect active compromise.
A SOC 2 Type II report tells you whether specified controls operated effectively during the audit period. It doesn't tell you whether those controls address the risks specific to your ePHI, whether the vendor's incident response can contain a sophisticated threat group, or whether configuration errors have introduced new vulnerabilities since the audit.
ShinyHunters reportedly exfiltrated around 1 terabyte of data over four days. That volume of data movement should trigger anomaly detection, but detection depends on configuration, not certification. If the vendor's monitoring thresholds weren't tuned for healthcare data sensitivity or if alerting rules didn't account for bulk export patterns, the SOC 2 report's description of "continuous monitoring controls" becomes meaningless.
Use SOC 2 reports as a starting point, not an endpoint. Your vendor risk assessment should include questions the SOC 2 doesn't answer: What's your mean time to detect unauthorized data access? How do you prevent credential compromise through social engineering? What data loss prevention controls apply to bulk exports? Where is ePHI stored at rest, and what encryption standard protects it?
Myth 4: "We'll know immediately if there's a breach"
Reality: Detection timelines depend on the vendor's monitoring capabilities and your contractual notification requirements.
McKesson detected the incident on August 25, 2026, and disclosed it to the SEC on August 28. That three-day window represents relatively fast disclosure for a complex investigation involving third-party applications. But consider the gap between when ShinyHunters first gained access (August 21) and when McKesson detected the activity (August 25). Four days of unauthorized access allowed exfiltration of substantial data volumes.
Your Business Associate Agreement should specify notification timelines, but "immediate" or "without unreasonable delay" leaves room for interpretation. Define it: notification within 24 hours of discovery, with preliminary details within 48 hours and a full incident report within 10 business days.
More importantly, require your vendors to implement detection controls that surface anomalous activity in hours, not days. That means behavioral analytics on administrative access, real-time alerting on bulk data exports, and automated correlation of failed authentication attempts across accounts. If your vendor can't describe these controls in specific technical terms, you're relying on hope, not security.
Myth 5: "Incident response is the vendor's problem"
Reality: You need a coordinated response plan that includes your team, the vendor, and potentially affected downstream partners.
When McKesson activated incident response protocols and engaged cybersecurity experts, the company also had to manage customer communication, assess impact on system availability, and coordinate across multiple business units. The breach affected "a subset of customers of its Oncology & Multispecialty and Medical-Surgical business units," requiring targeted notification and operational continuity planning.
Your incident response plan should include vendor-breach scenarios with predefined escalation paths, communication templates, and decision trees for determining Breach Notification Rule obligations. If the vendor experiences unauthorized access to your ePHI, who makes the determination about whether the breach meets the threshold for individual notification? What evidence do you need from the vendor to complete your risk assessment under 45 CFR § 164.402?
Test this coordination annually. Run a tabletop exercise where a Business Associate reports unauthorized access to ePHI, and walk through each decision point: How do you assess the scope? Who contacts affected individuals? What interim security measures do you require from the vendor before restoring access?
What to do instead
Replace point-in-time vendor assessments with continuous risk monitoring. Establish quarterly touchpoints where you review access logs, validate security control changes, and confirm that the vendor's threat detection remains effective against current tactics.
Build vendor security requirements into your procurement process before you sign the BAA. Require specific controls, not general assurances: multi-factor authentication on all administrative access, encryption of ePHI at rest using AES-256 or equivalent, network segmentation that isolates your ePHI from other customers' data, and real-time monitoring with defined detection thresholds.
Document your vendor risk assessment methodology and retain evidence of each evaluation. When OCR investigates a breach involving a Business Associate, they'll ask what due diligence you conducted. Your answer needs to be more detailed than "we reviewed their SOC 2 report."
Finally, treat vendor incidents as opportunities to validate your response coordination. When a vendor reports a security event, even if it doesn't affect your ePHI, use it to test your escalation procedures and refine your communication protocols. The time to discover gaps in your incident response plan is during a drill, not during a breach notification to OCR.
ShinyHunters' ransom demand exceeded $55 million. Your third-party risk program should cost a fraction of that figure, but only if you're investing in ongoing oversight, not one-time assessments.
