Third-party risk doubled this year — what to actually do
DBIR 2025 found third-party involvement in breaches doubled from 15% to 30%. Vendor questionnaires aren't going to fix this. Here's what works.
The headline statistic from the 2025 Verizon DBIR that should have gotten more coverage: third-party involvement in breaches doubled, from 15% to 30%, year over year. That's a structural shift, not a blip — and it reflects what most security teams have been feeling for years. Your attack surface increasingly includes everyone you depend on.
Standard vendor risk management (questionnaires, SOC 2 attestations, contract clauses) is necessary but no longer sufficient. Here's a frame for what actually moves the needle.
What "third-party involvement" actually means
The DBIR's third-party category covers several distinct patterns:
- Software supply chain compromises — a tool you use is itself compromised, and the attacker pivots into your environment
- Vendor environment breaches — a vendor with access to your data is breached, and your data is exfiltrated as part of theirs
- MSP / MSSP compromises — a service provider with broad access is compromised, and the attacker uses that access to reach all of their clients
- Authorized third-party user incidents — contractors, consultants, or partner-organization users with access to your systems are the entry point
- Reused-credential incidents — credentials issued for a third-party service get leaked elsewhere, and attackers use them to access systems they shouldn't
The "doubled" number rolls all of these together. Not all of them have the same defense playbook.
Why questionnaires aren't enough
The traditional vendor risk approach: send a questionnaire (SIG, CAIQ, custom), get back a SOC 2 report, do a risk score, sign a contract with security clauses. This addresses some of the third-party problem, specifically the "is this vendor competent at security" question.
It does not address:
- What happens when a competent vendor still gets breached
- What the blast radius is if a specific vendor's data is exfiltrated
- Whether the access this vendor has is actually appropriate to what they do
- How fast we'd know if something went wrong
Questionnaires are a point-in-time check. Real third-party risk management requires continuous attention.
Five things that actually reduce third-party risk
1. Reduce blast radius before you reduce probability.
Most third-party risk programs spend disproportionate effort trying to pick "safe" vendors. A more durable strategy: assume your vendors will get breached at some rate, and engineer your systems so any single vendor breach doesn't take you down.
That looks like: scoped data-sharing (vendor only sees what they need), encryption and tokenization for sensitive fields, network segmentation so vendor access doesn't pivot, separation of vendor identity from your core directory.
2. Treat third-party access as a first-class security problem.
Most organizations have hundreds of third-party identities (contractors, MSP technicians, partner users, vendor service accounts) in their environment. These often have:
- Stale or excessive access
- Shared accounts
- No or weak MFA
- Less behavioral monitoring than employee accounts
Tightening this is high-leverage work. Specific actions:
- Phishing-resistant MFA on third-party accounts (often the gap)
- Just-in-time access for high-privilege third-party roles
- Quarterly access review of all non-employee identities
- Behavioral monitoring rules tuned for third-party patterns
3. Tier your vendors and treat them differently.
A few-hundred-vendor portfolio doesn't all need the same scrutiny. A simple tiering:
- Tier 1 (critical): vendors with broad access to data, identity, or operations. MSP, identity provider, hosting provider, payroll, primary database. <10 vendors typically.
- Tier 2 (significant): vendors with scoped access to sensitive data. CRM, marketing automation with PII, analytics tools. ~20-50 vendors.
- Tier 3 (limited): vendors with little or no access to sensitive data. Most SaaS productivity tools.
Real continuous monitoring on Tier 1, deep due diligence + annual review on Tier 2, lightweight checks on Tier 3. This concentrates effort where it matters.
4. Continuously monitor, don't just questionnaire.
For Tier 1 and significant Tier 2 vendors, continuous monitoring catches issues that point-in-time assessments miss. Useful inputs:
- Breach notification monitoring (if your vendor gets breached, you want to know within hours, not weeks)
- External attack surface monitoring (most "rating" services watch for vendor cert expiry, exposed services, leaked credentials)
- Security questionnaire updates (annual or on material change)
- Direct security relationships with critical vendors (named contacts, rapid-incident-comms agreements)
5. Train your people on third-party-flavored social engineering.
The DBIR shows that many third-party-involved breaches start with social engineering: a fake message from "your vendor" requesting payment changes, credential resets, or data shares. Vendor-themed pretexts are extremely effective because they exploit existing trusted relationships.
Awareness training that includes vendor-impersonation scenarios — fake invoice emails, fake support requests, fake "your account was suspended, click here" messages branded as legitimate vendors — is one of the higher-leverage program additions you can make.
Concrete program changes that landed in 2025
A few patterns we saw mature this year across organizations that did this well:
- Vendor incident response playbooks. A short, predefined process for "what we do when a critical vendor reports a breach to us." Saves days during an actual event.
- Contractual breach notification windows. Many 2025 contracts require vendors to notify within 24-48 hours of confirmed breach, not the older 7-30 day windows.
- Annual penetration testing of vendor-facing surfaces. Specifically: the boundary between you and your critical vendors.
- Tabletop exercises that include third-party scenarios. Not just "ransomware on us" but "MSP compromise that affects us."
The bigger picture
The DBIR data on third-party involvement isn't going to reverse. The structural reasons are real: SaaS continues to grow as a fraction of every organization's stack, software supply chains continue to lengthen, and attackers continue to shift toward whichever path has the lowest defender attention.
That makes third-party risk less of a "vendor management" problem and more of a "security architecture" problem. The organizations that handle the next phase well will be the ones that engineered for it — minimal blast radius, tight third-party identity hygiene, fast vendor incident response, awareness programs that include vendor-themed pretexts, and continuous monitoring of the relationships that actually matter.
Sources: Verizon 2025 Data Breach Investigations Report — Executive Summary, IBM Cost of a Data Breach Report 2025.