The recent McKesson breach through third-party applications didn't just expose data; it highlighted how vendor integrations have become a vulnerable entry point into your organization. If unauthorized access can compromise a healthcare supply chain giant, every organization using peripheral software with core data faces a similar threat.
Here's your playbook for auditing and securing third-party application access before it becomes your next incident report.
The Problem: Your Vendor Apps Are Production Systems Now
Third-party applications often have privileged access, yet many organizations treat them as optional rather than essential infrastructure. McKesson quickly notified the Securities and Exchange Commission and engaged external incident response specialists after detecting unauthorized access to third-party applications affecting some customers. While attackers claimed they exfiltrated 284 million records (a figure that remains unverified), the core issue is that a peripheral application had enough access to make such a claim plausible.
You're facing two converging problems: AI-driven SaaS development is flooding your environment with new integrations faster than security teams can assess them, and each integration expands your attack surface. Every API connection, vendor SSO integration, and data sync creates another path that bypasses your mature internal controls.
What You Need Before Starting
Inventory your third-party applications. You can't secure what you don't know exists. Gather:
- All SaaS subscriptions from procurement and finance
- Shadow IT discovered through network traffic analysis or CASB logs
- API connections listed in your identity provider
- Data sharing agreements from legal and compliance
Identify your audit team. You'll need:
- IT security engineer for technical audits
- Privacy officer for data classification and regulatory obligations
- Procurement or vendor management for contracts and SLAs
- Application owners to confirm business criticality
Set your baseline access policy. Define least-privilege standards:
- What data categories can third parties access? (Sensitive Personal Data, PHI, financial records)
- What actions can they perform? (read-only, write, delete, export)
- What network segments can they reach?
- What authentication methods are required? (MFA, SSO, certificate-based)
Step-by-Step Implementation
Day 1: Inventory and Classify (4-6 hours)
Map every third-party application to data categories.
Create a spreadsheet with columns:
- Application name and vendor
- Data accessed (specific fields, not just "customer data")
- Access method (API, SFTP, direct database, screen scraping)
- Authentication mechanism
- Business owner
- Last security review date
For each application, determine if it accesses Sensitive Personal Data, protected health information, or financial records. If yes, it's critical infrastructure.
Prioritize by risk. Flag applications that:
- Access regulated data (HIPAA, GDPR, PCI)
- Have write or delete permissions
- Lack MFA or use shared credentials
- Haven't been reviewed in the past year
- Are developed by unverifiable vendors (no SOC 2, no security documentation)
Day 2: Technical Audit of High-Risk Apps (6-8 hours)
Audit access controls for each flagged application:
Check your identity provider (Okta, Azure AD, etc.):
- Review assigned users and groups
- Confirm MFA enforcement on the app
- Check for service accounts or API keys
- Verify session timeout settings
Review API permissions:
- Pull OAuth scopes or API permission grants
- Compare granted permissions to minimum required
- Look for overly broad scopes like "read all" or "admin"
Examine network access:
- Confirm the app uses encrypted connections (TLS 1.2+)
- Check if the vendor IP ranges are allowlisted
- Verify the app can't reach internal networks unless required
Document findings immediately. Note:
- Excessive permissions
- Data exposed
- Who approved the current configuration
Day 2-3: Vendor Security Assessment (4 hours)
Request security documentation from high-risk vendors:
- SOC 2 Type II report (within the past 12 months)
- Penetration test results or vulnerability scan summaries
- Incident response contact and SLA
- Data handling and retention policies
- Subprocessor list
If a vendor can't provide SOC 2 or equivalent attestation, send a security questionnaire covering:
- Encryption at rest and in transit
- Access logging and monitoring capabilities
- Backup and disaster recovery procedures
- Employee background check policies
Set a 10-business-day response deadline. Vendors who can't answer basic security questions shouldn't have production access.
Day 3: Implement Immediate Controls (2-4 hours)
Revoke excessive permissions now. Don't wait for vendor responses:
Reduce OAuth scopes to minimum required:
- Example: Change "contacts.read_write" to "contacts.read" if the app only needs to pull contact data
Disable unused service accounts:
- Identify accounts with no activity in 90 days
- Disable rather than delete (in case of dependencies)
- Document the change and monitor for break/fix requests
Enforce MFA on all third-party app access:
- Enable conditional access policies requiring MFA
- Block legacy authentication protocols
- Set session timeouts to 8 hours maximum
Segment network access:
- Move third-party app connections to a DMZ or isolated VLAN
- Restrict outbound connections to vendor-documented IP ranges
- Enable egress filtering to block unexpected data exfiltration paths
Validation: How to Verify It Works
Test reduced permissions (30 minutes per app):
- Log in as a standard user
- Attempt to perform the app's core functions
- Confirm the app still works with reduced scope
- Document any functionality breaks and assess if they're acceptable
Monitor for unauthorized access attempts (ongoing): Configure alerts in your SIEM or identity provider for:
- Failed authentication attempts to third-party apps (threshold: 5 in 10 minutes)
- New user provisioning to high-risk apps
- Permission scope changes
- API calls from unexpected IP ranges
Verify data egress monitoring (1 hour):
- Confirm your DLP or CASB solution logs third-party app data transfers
- Set up alerts for large data exports (threshold varies by app; start with 1,000 records in a single session)
- Test an export to confirm the alert fires
Maintenance: Ongoing Tasks
Quarterly vendor reviews (2 hours per quarter):
- Re-pull the application inventory
- Identify new SaaS subscriptions added since last review
- Verify SOC 2 reports are current
- Review access logs for anomalies
Monthly access audits (1 hour):
- Export user lists from high-risk apps
- Compare to your authoritative employee directory
- Disable accounts for terminated employees or role changes
- Flag shared accounts or service accounts with recent activity
Continuous monitoring dashboards: Set up a view showing:
- Third-party apps accessed in the past 24 hours
- Data volume transferred per app
- Failed authentication attempts
- Apps missing current security attestations
Incident Response Structure updates (annually): Add third-party compromise scenarios to your tabletop exercises. Practice:
- Revoking vendor access within 15 minutes
- Identifying what data the vendor could access
- Notifying affected customers and regulators
- Engaging forensic specialists
Third-party applications aren't optional software anymore. When managing a complex supply chain or handling regulated data, every vendor integration is critical infrastructure. The 72-hour sprint above won't eliminate third-party risk, but it will close the most obvious doors before an attacker walks through them. Start with your highest-risk apps, implement least-privilege access, and build continuous monitoring into your security operations. The next breach notification you read shouldn't be your own.
