When attackers breach third-party applications through social engineering, your incident response begins with a crucial question: what access did that vendor have, and who controls it now?
The McKesson incident, disclosed on August 25, 2026, highlights how vishing attacks against employees led to an Okta single sign-on compromise, cascading into Salesforce and Snowflake environments. ShinyHunters claimed responsibility for stealing 284 million data records. This pattern is instructive: attackers didn't exploit a software vulnerability. They exploited the trust between your workforce and your application stack.
This checklist covers controls to prevent and contain third-party application breaches driven by social engineering. It's designed for procurement security teams managing SaaS vendor relationships in healthcare supply chains, where patient data amplifies every failure.
Prerequisites
Before using this checklist, ensure you have:
A current inventory of all third-party applications with patient data access. If you can't list every SaaS tool with PHI access, you can't secure them. This should look like a CMDB or asset register with data classification tags, updated within the last 30 days.
Documented data flows for each vendor relationship. You need to know what data moves where. This should include data flow diagrams showing ingress/egress points, data types, and processing locations for each vendor.
Defined roles for vendor breach response. When a vendor calls at 3 a.m. to report unauthorized access, who owns the response? This should include a RACI matrix naming the vendor relationship owner, legal, privacy officer, and technical leads.
Security Controls Checklist
Access Management
1. Single sign-on accounts require phishing-resistant MFA for all vendor applications handling patient data.
Vishing attacks compromise passwords and push-notification MFA. Your SSO provider must enforce FIDO2 security keys or passkeys for any application processing PHI or PII.
This should look like Okta or similar configured to require hardware-based authentication for applications tagged "PHI access" in your vendor inventory, with no SMS or voice call fallback enabled.
2. Vendor application access follows least-privilege principles with role-based controls.
Attackers who compromise one employee account shouldn't inherit enterprise-admin privileges in your Salesforce or Snowflake environments.
This should include role definitions documented in your vendor contract, technical implementation validated during onboarding, and quarterly access reviews showing no standing admin access for standard users.
3. Access Revocation procedures execute within four hours of termination or role change.
The window between an employee's last day and credential deactivation is an attacker's opportunity.
This should include automated deprovisioning workflows triggered by your HRIS system, with manual verification logs showing completion timestamps under the four-hour threshold.
Vendor Security Requirements
4. Vendor contracts include Sub-Processor Disclosure requirements with 30-day advance notice.
Your SaaS vendor's decision to add a new sub-processor changes your risk surface. You need visibility before it happens.
This should include contract language requiring written notice and a right to object, with a sub-processor register maintained by the vendor and reviewed quarterly by your team.
5. Right to Audit clauses permit security assessments with 10 business days' notice.
When you suspect compromise or need to validate controls after an incident elsewhere in your supply chain, you can't wait 90 days for a vendor's audit window.
This should include contract terms allowing your third-party auditor to conduct on-site or virtual security reviews, with vendor cooperation requirements and defined scope (technical controls, access logs, incident response records).
6. Notification Timeline requirements mandate breach disclosure within 24 hours of vendor detection.
McKesson disclosed its incident the same day it was discovered. Your vendors should be contractually bound to the same standard.
This should include contract language specifying "within 24 hours of discovery" for any unauthorized access to your data, with defined communication channels (security team email, not account manager) and required incident details (affected systems, data types, timeline).
Monitoring and Detection
7. Continuous Monitoring of Active Arrangements includes monthly review of vendor authentication logs.
You're looking for anomalies: logins from unexpected geographies, unusual access volumes, or credential sharing patterns.
This should include automated log ingestion from vendor SSO systems into your SIEM, with alerting rules for failed authentication spikes and access from non-corporate IP ranges.
8. Cyber Risk Ratings are reviewed quarterly for all vendors with patient data access.
External ratings from SecurityScorecard or BitSight can surface DNS hijacking attempts, exposed credentials, or patching delays before they become breach vectors.
This should include ratings integrated into your vendor risk register, with score thresholds triggering reassessment workflows (e.g., any vendor dropping below 700 gets a security questionnaire within 15 days).
9. Employee security awareness training includes vendor-specific vishing scenarios.
Generic phishing training doesn't prepare your help desk for a caller who knows your vendor relationship details and current projects.
This should include quarterly tabletop exercises simulating vendor impersonation calls, with success measured by employees' ability to verify caller identity through out-of-band channels before resetting credentials.
Incident Response
10. Vendor Breach Management playbooks define containment steps for each critical vendor.
When your Snowflake vendor reports unauthorized access, you need pre-approved actions: isolate the connection, pull access logs, notify affected Business Associates.
This should include vendor-specific runbooks stored in your incident response platform, tested annually, with decision trees for data exposure scenarios and pre-drafted notification templates.
11. Wind-Down Plans exist for all vendors classified as critical or important functions.
If you need to terminate a vendor relationship mid-incident, can you restore service within your recovery time objective?
This should include documented migration procedures, identified alternative vendors, and tested data export processes. For critical vendors, this means an annual failover test with success criteria (full service restoration within your RTO).
12. Post-incident vendor reviews are mandatory within 30 days of any security event.
Every vendor incident is a test of your controls. Document what worked, what failed, and what changes.
This should include structured after-action reports covering root cause, your detection timeline, vendor communication quality, and contractual compliance. Feed findings into your next contract negotiation cycle.
Common Mistakes
Treating SSO as sufficient access control. SSO consolidates authentication but doesn't prevent lateral movement once attackers have valid credentials. You still need application-level permissions and monitoring.
Skipping vendor-specific training. Your employees know not to click suspicious links, but do they know how to verify a caller claiming to be from your Salesforce support team? Attackers study your vendor relationships.
Relying on vendor SOC 2 reports without reading them. A clean SOC 2 Type II doesn't tell you whether the vendor can detect social engineering attacks or how fast they'll notify you of a breach. Read the control descriptions and test results, not just the opinion.
Next Steps
Schedule a 90-day sprint to implement controls 1, 6, and 10. Phishing-resistant MFA, contractual notification timelines, and vendor-specific incident playbooks address the attack pattern demonstrated in the McKesson case.
Then build out your monitoring layer (controls 7 and 8) before the next contract renewal cycle, when you can negotiate stronger audit rights and sub-processor disclosure requirements.
Your third-party applications are infrastructure. Secure them like it.
