When threat actors exfiltrate a terabyte of data over four days from your third-party applications, you're not facing a technical failure. You're facing a governance breakdown that happened months earlier.
The recent cyberattack against McKesson, disclosed in a Form 8-K filing with the SEC, involved unauthorized access through third-party applications and the exfiltration of data between August 21 and August 25, 2026. The ShinyHunters group claims to have stolen 284 million records from the healthcare giant's Salesforce environment and Snowflake instance. Whether or not every detail is confirmed, the pattern is familiar: third-party systems become the entry point because teams treat vendor access as a procurement problem instead of a continuous control obligation.
Why These Mistakes Keep Happening
Third-party risk management fails for a structural reason. Your team builds controls around what you own and operate directly. You map ISO/IEC 27001 Annex A controls to your internal systems. You configure Role-Based Access Control for employees. You monitor your own network perimeter.
Then you grant a vendor privileged access to a Salesforce org or a data warehouse, and those same controls don't extend automatically. The vendor's authentication lives outside your identity provider. Their access doesn't appear in your quarterly access reviews. Your SIEM doesn't see their API calls unless you explicitly configure collection. The control gap isn't theoretical; it's architectural.
Healthcare organizations face this problem at scale because clinical workflows depend on specialized applications. Each oncology system, pharmacy platform, or patient portal introduces another authentication boundary and another dataset that sits partially outside your direct visibility.
Mistake 1: Treating Vendor Security Questionnaires as Risk Assessment
Your procurement team sends a 200-question security assessment to every new vendor. The vendor's sales engineer fills it out, checking boxes that confirm they encrypt data in transit and conduct annual penetration tests. You file the PDF and move on.
This isn't risk assessment. It's compliance theater.
The real risk surfaces when you ask: what specific data will this vendor access, through which authentication method, and what prevents them from exfiltrating it in bulk? A questionnaire can't answer that question because it doesn't examine your implementation. The vendor might have strong perimeter controls, but if you grant their service account read access to your entire Snowflake warehouse with no query logging, the questionnaire's answers become irrelevant.
The fix: Map data flows before you grant access. Document which datasets the vendor needs, what level of access their application requires, and how you'll detect anomalous activity. This becomes your vendor-specific control baseline. ISO/IEC 27001 Annex A.15.1.2 requires you to define and agree upon security controls with suppliers, not just collect their self-attestations. If the vendor needs read access to patient records, specify the query patterns you expect and configure alerts for bulk exports or after-hours access.
Mistake 2: Granting Persistent Privileged Access Instead of Just-in-Time Access
A vendor's support team needs administrative access to troubleshoot integration issues. You create a service account with elevated privileges and share the credentials through your ticketing system. The vendor uses it once during implementation, then the account sits dormant for months with full access still enabled.
This happens because Just-in-Time Access feels like operational overhead. Provisioning temporary credentials requires workflow changes. It's easier to grant standing access and assume the vendor won't abuse it.
The consequence: when a threat actor compromises the vendor through social engineering, they inherit that standing access. ShinyHunters reportedly uses vishing and social engineering to gain initial access. If your vendor's employee falls for a pretext call and provides credentials, the attacker doesn't need to exploit a vulnerability. They log in with legitimate credentials that your systems are configured to trust.
The fix: Require time-bound access for all vendor administrative functions. If your identity provider supports it, configure vendor accounts to expire after a defined period (24 hours, 72 hours, whatever matches your operational needs). For vendors who need recurring access, implement an approval workflow where their request triggers a temporary elevation. NIST SP 800-53 AC-6(2) and AC-2(5) support this approach. The friction is intentional. It forces both parties to justify access every time it's granted.
Mistake 3: Failing to Extend Logging to Third-Party Environments
Your SIEM collects authentication logs, network flow data, and endpoint telemetry from your internal infrastructure. You've tuned detection rules for lateral movement and data exfiltration. Then a vendor accesses your Salesforce org through their API integration, and none of that logging captures their activity.
This gap exists because third-party platforms often require separate logging configuration. Salesforce Event Monitoring, Snowflake query history, and AWS CloudTrail all generate logs, but they don't automatically feed into your central monitoring unless you build that integration.
The real-world consequence: when McKesson detected the incident on August 25, 2026, the exfiltration had been occurring since August 21. That's a four-day window where a terabyte of data left the environment. Effective logging doesn't prevent the initial access, but it compresses the time between compromise and detection.
The fix: Treat third-party application logs as mandatory data sources, not optional add-ons. When you onboard a new SaaS platform or grant vendor access to a cloud environment, configure log export on day one. Define baseline activity (typical query volume, authentication patterns, data export frequency) and set thresholds that trigger investigation. NIST Cybersecurity Framework (CSF) 2.0 function DE.CM-1 applies equally to third-party environments. If you can't monitor it, you can't detect compromise.
Mistake 4: Assuming Breach Notification Obligations Don't Apply to Vendor Incidents
When a vendor's employee clicks a vishing link and provides credentials that grant access to your patient data, who's responsible for breach notification? Your team might assume the vendor owns that obligation because their employee was compromised.
That assumption is wrong. Under the Health Insurance Portability and Accountability Act and the Health Information Technology for Economic and Clinical Health Act, covered entities remain responsible for protected health information even when a business associate (vendor) causes the breach. The 72-Hour Notification Requirement doesn't pause while you negotiate with the vendor about whose fault it was.
The consequence: delayed notification triggers regulatory penalties and extends the window where affected individuals remain unaware of the exposure. McKesson disclosed the incident in a Form 8-K filing with the SEC and warned customers of potential service degradation, but determining the full scope of affected individuals takes time when the data spans multiple business units.
The fix: Build vendor breach scenarios into your incident response plan. Define the notification trigger (when do you start the clock: when the vendor detects the incident, or when they notify you?), the escalation path (who at the vendor has authority to make decisions during the response), and the evidence-sharing protocol (how will the vendor provide logs and forensic data). HIPAA Security Rule § 164.308(a)(1)(ii)(D) and § 164.308(a)(6) require you to maintain these procedures. Your business associate agreement should specify the vendor's obligation to notify you within a defined timeframe, not "promptly" or "as soon as practicable."
Mistake 5: Relying on Contractual Indemnification Instead of Technical Controls
Your contract with the vendor includes an indemnification clause. If their security failure causes a breach, they'll cover the costs of notification, credit monitoring, and regulatory fines. Your legal team considers this adequate risk transfer.
It's not. Indemnification doesn't prevent the breach. It doesn't restore patient trust. It doesn't eliminate the operational disruption when you have to take systems offline for forensic investigation. McKesson warned customers of potential impacts on system availability and intermittent service degradation, which affects clinical operations regardless of who pays for the incident response.
The fix: Use contractual terms to enforce technical requirements, not replace them. Your vendor agreement should mandate specific controls: multi-factor authentication for all administrative access, encryption of data at rest and in transit (specify the algorithm), quarterly access reviews with documented results, and annual third-party penetration testing with findings shared within 30 days. ISO/IEC 27001 Annex A.15.1.3 requires you to address security risks in the supply chain. The contract becomes the enforcement mechanism for controls you can't implement directly.
Prevention Checklist
Before granting any vendor access to systems containing sensitive data:
- Document the specific datasets the vendor needs and the minimum access level required (read-only, write, administrative)
- Configure time-bound access with automatic expiration, or implement an approval workflow for recurring access requests
- Enable detailed logging for the third-party platform and integrate those logs into your SIEM or central monitoring system
- Define baseline activity metrics (query volume, authentication frequency, data export patterns) and set alert thresholds
- Update your incident response plan with vendor-specific notification triggers, escalation contacts, and evidence-sharing protocols
- Review your business associate agreement to confirm it specifies notification timeframes, control requirements, and audit rights
- Conduct a tabletop exercise that simulates a vendor compromise, including notification decisions and communication with affected individuals
The ShinyHunters group continues to target healthcare organizations using social engineering and vishing. Your questionnaire won't stop them. Your indemnification clause won't prevent the operational impact. The controls you implement before you grant access will determine whether a compromised vendor credential becomes a four-day exfiltration event or a detected anomaly that your team contains within hours.
