Why Third-Party Risk Management Programs Don’t Actually Reduce Risk

Enterprises have spent years building third-party risk programs around evidence collection: security questionnaires, audit reports, and penetration tests. Yet when a vendor gets breached, security teams still struggle to answer the question that matters: what exposure did that vendor actually create inside the environment?

The gap between compliance activity and measurable risk reduction is getting harder to ignore.

Verizon’s 2025 Data Breach Investigations Report found that breaches involving third parties doubled in a single year, rising from 15% to 30%. McKinsey separately noted that nearly one-third of cyber breaches are now associated with technology supply chains and third-party dependencies.

During the same period, organizations expanded TPRM teams, increased assessment volume, and added more vendors into formal review processes. The amount of oversight grew. So did the number of compromises coming through vendors.

TPRM Was Built For Compliance, Not Exposure Management

Most TPRM programs were not designed for the environment they now operate in. They were built inside procurement and GRC functions to support due diligence, regulatory obligations, and audit defensibility.

That is no longer enough.

Vendors now sit inside identity infrastructure, customer data flows, production environments, support systems, and CI/CD pipelines. Many have privileged access into environments security teams monitor more lightly than their own endpoints.

Vendors are now a predominant part of the attack surface. Most TPRM programs are still optimized to collect evidence, not understand exposure.

The underlying issue is structural. The teams responsible for gathering vendor evidence are often not the teams responsible for defending the organization when a vendor gets compromised. In many enterprises, the CISO has limited operational ownership over TPRM.

Vendor Trust Became Self-Reported

The compliance market normalized the idea that vendors can reliably attest to their own security posture.

Most TPRM inputs ultimately originate from the vendor. Security questionnaires are completed by the vendor. Audit reports are commissioned by the vendor. Customers are expected to evaluate risk using evidence controlled largely by the vendor itself.

That creates predictable incentives.

The recent Delve case exposed how fragile the model became. The YC-backed compliance startup was accused of issuing hundreds of SOC 2 reports with nearly identical language and no documented exceptions across large numbers of engagements. What’s remarkable about Delve isn’t just that the reports were allegedly fabricated. It’s that hundreds of companies accepted them without question and called it risk management.

When the audit itself is compromised and the TPRM process is reduced to collecting documents, nobody is left whose job is to actually find the risk.

Even outside extreme cases, audit quality varies significantly between firms. Two vendors can both present valid SOC 2 reports while representing very different levels of operational risk.

Third Parties Needs To Be Treated Like Any Other Attack Surface

Anyone running security at scale already knows the environment changes faster than governance processes do. Permissions expand, integrations drift, and sensitive data starts flowing into systems that were never part of the original review. Yet most TPRM programs still rely on point-in-time assessment.

The first shift is to stop treating vendor evidence as a file review. The point is not to collect artifacts. It is to interrogate them.

A SOC 2 report, security questionnaire, trust page, privacy policy, DPA, subprocessors list, and breach disclosure should not be reviewed in isolation. They should be cross-referenced against one another and against operational reality. What changed between the trust page and the contract? Were new subprocessors added after onboarding? Is data sharing enabled by default inside the product? Does the privacy policy allow uses of customer data the questionnaire denies? Has the vendor had layoffs, breaches, or material operational changes that never appear in the clean report?

That is where buried risk usually shows up.

Most importantly, organizations need to assess their exposure to the vendor rather than treating the vendor as the unit of analysis.

What systems does the vendor connect to? What permissions were granted? What customer or internal data moves through the integration? Is the vendor training AI models on enterprise data? If the vendor is compromised, what can an attacker realistically reach from there? And when a breach does happen, how to react with speed and precision.

Exposure is also not static.

Vendors accumulate new permissions. Integrations expand. Business units onboard tools outside approved procurement channels. Data starts flowing into systems security teams never assessed in the first place.

Most TPRM programs have almost no visibility into that drift.

The Perimeter Already Moved

The perimeter doesn’t end with your organization. It extends into vendors, SaaS platforms, APIs, and every external integration connected to your environment. Most TPRM programs still operate as if those systems sit outside the attack surface.

The next generation of TPRM will look much less like compliance administration and much more like exposure management. Continuous prioritization and remediation will matter more than annual reviews. Independent telemetry will matter more than vendor-supplied evidence. Vendor security will move closer to the SOC and further away from filing cabinets.