When ShinyHunters demanded approximately $55 million from McKesson Corporation in late August, they exposed more than just stolen data. They highlighted a widespread misunderstanding of third-party risk in the healthcare sector.
You've heard the warnings about vendor risk and likely completed security questionnaires. Yet, myths about third-party applications create vulnerabilities that threat actors exploit. McKesson discovered its breach on August 25, affecting third-party applications that accessed customer data across its Oncology & Multispecialty and Medical-Surgical units. This pattern repeats because these myths persist.
Myth 1: "We can outsource accountability for third-party security"
Reality: You're the data controller, regardless of where processing occurs.
Under GDPR Article 28, you must use processors that provide sufficient guarantees to implement appropriate measures. "Sufficient" means you must assess these guarantees before processing begins, not after a breach notification.
The UK General Data Protection Regulation and California Privacy Rights Act impose similar accountability. When McKesson's third-party applications were compromised, the company had to file with the US Securities and Exchange Commission and issue public notices because the legal obligation sits with the organization that determines the purposes and means of processing.
Map every third-party application that handles personal data. Document the Article 30 processing activities. Ensure your contracts include the mandatory processor clauses from Article 28(3). If you can't produce that documentation quickly, you're assuming compliance rather than ensuring it.
Myth 2: "Annual security questionnaires are sufficient due diligence"
Reality: Point-in-time assessments don't detect continuous risk.
A vendor's SOC 2 report from nine months ago doesn't reflect their patch management last week. The ShinyHunters group has compromised multiple organizations because static assessments create false confidence.
Implement continuous monitoring for critical vendors. Require real-time security posture reporting for any processor handling protected health or personally identifiable information. Set contractual rights to audit on demand, not annually.
For high-risk processing under GDPR Article 35, your Data Protection Impact Assessment must evaluate processor controls as part of the necessity and proportionality analysis. That evaluation is meaningless if you're reviewing outdated security documentation.
Myth 3: "If we don't pay the ransom, we avoid legal exposure"
Reality: Your notification obligations trigger regardless of ransom payment.
The 72-hour notification requirement under GDPR Article 33 starts when you're aware of the breach, not when you decide whether to negotiate. McKesson confirmed the incident publicly because notification to supervisory authorities and affected individuals is mandatory when personal data breaches are likely to risk rights and freedoms.
The compromised information allegedly included protected health information, medical and treatment records, prescription and billing data, and employee information. This scope triggers notification under multiple frameworks: GDPR, UK General Data Protection Regulation, the Health Insurance Portability and Accountability Act breach notification rule, and state-level requirements across the US.
Whether you pay doesn't change your notification timeline. The breach register you maintain under Article 33(5) must document the facts, effects, and remediation regardless of extortion negotiations. Build your incident response plan around regulatory timelines, not ransom deadlines.
Myth 4: "Vendor contracts transfer liability for breaches"
Reality: Contracts allocate costs but don't eliminate your regulatory obligations.
You can negotiate indemnification clauses and require vendors to maintain cyber insurance, but you can't contract away your duty to implement appropriate security measures or your accountability to supervisory authorities.
When a processor breach affects your data subjects, you're the entity that must notify the supervisory authority within 72 hours. You're the organization that faces potential administrative fines up to €20 million or 4% of annual global turnover under GDPR Article 83. Your vendor's insurance policy doesn't satisfy your compliance obligations.
Review your processor agreements for the Article 28(3)(f) requirement that processors assist you in ensuring compliance with breach notification. That assistance should include specific response timelines, forensic cooperation, and evidence preservation. If your contract says the vendor will "reasonably cooperate," you don't have enforceable incident response terms.
Myth 5: "Disconnecting systems after detection limits damage"
Reality: Preservation of evidence often requires keeping compromised systems online under controlled monitoring.
McKesson noted it wasn't disconnecting systems in response to the breach. That's not negligence; it's forensic discipline.
When you detect unauthorized access, your priority is containment, but containment doesn't always mean shutdown. You need to preserve logs, capture network traffic, and document the attack path for your notification to supervisory authorities. GDPR Article 33(3) requires you to describe the nature of the breach, including the categories and approximate number of data subjects and records concerned.
If you power down systems before capturing that evidence, you're filing an incomplete breach notification. Worse, you've eliminated your ability to assess whether the attacker maintained persistence through additional access points.
Your incident response plan should define decision criteria for isolation versus monitoring. Document who has authority to make that call and what evidence threshold triggers each response. The plan should reference your Article 32 security measures and explain how incident response aligns with your ongoing obligation to ensure appropriate security.
What to Do Instead
Stop treating vendor risk as a procurement checkbox. Build a third-party risk program that recognizes processors as extensions of your own processing activities.
Maintain an Article 30 record of processing activities that identifies every processor and sub-processor. Verify that your processor agreements include all nine mandatory clauses from Article 28(3). Require processors to notify you of breaches affecting your data within 24 hours, not 72.
Conduct Data Protection Impact Assessments for any processing that involves systematic monitoring, large-scale processing of special categories of data, or automated decision-making. That assessment must evaluate processor controls, not just your own.
When ShinyHunters set a September 1 deadline for McKesson, they were counting on the same myths that compromise organizations daily. Your vendor security program should address continuous risk with enforceable contracts and real-time monitoring, or it merely documents your assumptions until the breach notification proves them wrong.
