Third-party risk management in most organizations is a ritual that everyone knows doesn't work and no one has replaced. A vendor is onboarded, someone sends a security questionnaire, the vendor returns a hundred pages of mostly-accurate answers, a risk analyst reads them, a spreadsheet cell turns green, and the relationship is considered assessed — for a year, regardless of what changes in the meantime. This model was designed for a world where a company had a manageable set of significant vendors. That world is gone. A modern organization runs on hundreds of SaaS applications, each one holding some slice of its data, and the questionnaire-once-a-year model has quietly become theater: a compliance artifact that produces a paper trail without producing safety.

The problem is not that the tools of third-party risk management are wrong. Questionnaires, contracts, and assessments all have a place. The problem is that the operating model was built for a scale and a cadence that no longer match reality, and stretching it across hundreds of SaaS vendors turns it from a control into a formality. Fixing it means starting from the actual risk surface rather than the process everyone inherited.

Why the inherited model fails

The annual questionnaire fails for three structural reasons, and understanding them is the whole argument for a different approach.

It's point-in-time in a continuous world. A questionnaire captures a vendor's posture on the day it's answered. But breaches don't wait for the renewal cycle, vendors change their architecture and sub-processors constantly, and a green cell from ten months ago tells you nothing about today. The assessment is stale almost immediately, and the organization mistakes the paperwork's freshness for the risk's.

It doesn't scale to SaaS sprawl. A risk team that could thoughtfully assess forty vendors cannot meaningfully assess four hundred with the same process. What happens instead is triage by exhaustion: the questionnaire gets sent, the answers get filed largely unread, and the assessment becomes a checkbox that proves the process ran, not a judgment that the vendor is safe. Effort spread that thin stops being effort.

It assumes procurement is the entry point, and increasingly it isn't. The single biggest change in the vendor risk surface is that individual teams now adopt SaaS tools directly, with a corporate card and an OAuth grant, entirely outside any procurement or security review. The formal TPRM process governs the vendors it knows about. The vendors it doesn't know about — the ones a marketing team wired into the CRM last quarter — are exactly the ones no one assessed.

The risk surface is data and access, not the vendor

The instinct in vendor risk is to assess vendors. The more useful framing is to assess what a vendor can reach. A SaaS tool is risky to precisely the degree that it holds sensitive data or has access to systems that do — and two vendors of identical security maturity can carry wildly different risk depending on what they touch.

This reframing matters because it exposes the parts of the surface the vendor-centric model misses. OAuth and API grants are the clearest example: a tool granted broad read access to a company's email or cloud drive holds real risk regardless of how it scored on a questionnaire, and these grants accumulate silently, often outliving the reason they were created. Sub-processors — the vendors your vendors use — extend the surface another layer out; your data doesn't stop at the vendor you contracted with, and the fourth-party you've never heard of can be the one that leaks it. And data flowing outward through integrations means a breach at a minor vendor can expose data that originated in your most sensitive systems, if the integration piped it there.

The practical consequence is that a risk program organized around "which vendors are risky" asks the wrong question. The right question is "which vendors can reach our sensitive data or systems, directly or through a grant or integration, and what happens if any one of them is compromised." That question leads to a different and more defensible program.

Inventory is the foundation, and most organizations don't have one

You cannot manage a risk surface you cannot see, and the uncomfortable truth for most organizations is that no single person can produce an accurate list of the SaaS tools in use and the data each one holds. The formal vendor list captures the procured relationships. It misses the team-adopted tools, the free-tier accounts, the trials that became load-bearing, and the OAuth grants nobody tracks.

Building that inventory is the unglamorous foundation of any TPRM program that works, and it comes from combining several imperfect sources: expense and card data reveals what's being paid for, single-sign-on logs reveal what's being logged into, OAuth grant reviews in the major cloud platforms reveal what's been given access, and network or CASB telemetry reveals what's being talked to. None is complete alone; together they produce a picture close enough to reality to act on. The organizations that skip this step are managing the risk of the vendors they happen to know about while the unmanaged remainder sits unassessed — and the unassessed remainder is, almost by definition, where the surprises live.

Tier by consequence, not uniformly

Once the inventory exists, the second decision is how much scrutiny each vendor gets — and the failure mode is treating them uniformly. Sending the same hundred-question assessment to the payroll system and the team's meeting-notes app wastes effort on the trivial and under-weights the critical.

A workable tiering runs on two axes: the sensitivity of the data the vendor holds, and the criticality of the vendor to operations. A tool holding regulated personal data or with broad access to core systems is a top tier that warrants real assessment, contractual controls, and ongoing monitoring. A tool holding no sensitive data and easily replaced is a bottom tier that warrants little more than being known and inventoried. Most vendors fall in between and warrant a proportionate middle. The point of tiering is not to assess less — it's to concentrate the finite assessment capacity where the consequences actually are, which is the same discipline that makes any risk program work: match the effort to the stakes.

What actually reduces third-party risk

Assessment identifies risk; it doesn't reduce it. The reduction comes from a smaller set of moves that the questionnaire ritual often crowds out.

Contractual controls that mean something — breach notification within a defined and short window, the right to audit or to receive current independent assessment reports, clear data-handling and deletion obligations, and limits on sub-processors. Contracts are the one point of real leverage over a vendor, and they're strongest at onboarding and renewal, which is exactly when the risk team is often least involved.

Technical constraint of what a vendor can reach — scoping OAuth grants to the minimum necessary rather than the maximum offered, segmenting integrations, and preferring vendors that support granular permissions over those that demand broad access. A vendor that can only reach a little is a smaller problem when it's breached, and least-privilege applies to third parties as much as to internal systems.

Monitoring that's continuous where it matters — for the top tier, that means tracking the vendor's posture over time rather than trusting a point-in-time snapshot, watching for breach disclosures, and re-evaluating when the vendor materially changes. Security-rating services can help here, with an important caveat: they measure a vendor's external posture, which correlates with but does not equal the security of your specific data inside that vendor. Treat the rating as one signal, not a verdict.

The offboarding gap nobody owns

The least-discussed and most common third-party risk failure is not onboarding — it's the absence of offboarding. Vendors get adopted; they rarely get formally dropped. The contract lapses or the team stops using the tool, but the account stays live, the data stays resident, and the OAuth grant stays active. The result is a long tail of dead relationships that still hold data and still have access, accumulating silently as a risk nobody is watching because the relationship is, on paper, over.

A TPRM program that only manages active vendors is missing half the surface. Real offboarding means confirming data deletion, revoking access and OAuth grants, and removing the integration — and it needs an owner, because it is exactly the kind of unglamorous cleanup that never happens unless someone is accountable for it. The dead vendor holding a copy of last year's customer data is a breach waiting to be attributed to a company that forgot the vendor existed.

What good looks like

A third-party risk program that works in the SaaS era shares a shape. It starts from a real inventory built from multiple telemetry sources, not a procurement list. It tiers vendors by the sensitivity of the data they hold and the access they have, and concentrates assessment effort on the top tier. It reduces risk through contracts and least-privilege access, not just through paperwork that documents it. It monitors the vendors that matter continuously rather than annually. And it closes the loop with real offboarding, so the vendor list reflects reality rather than accumulating dead weight. None of this is exotic — it's the same risk discipline applied honestly to a surface that outgrew the old process.

The bottom line

The annual security questionnaire didn't fail because questionnaires are useless; it failed because the world it was built for — a handful of significant vendors, adopted through procurement, changing slowly — stopped existing. The organizations getting third-party risk right in 2026 have stopped trying to scale a point-in-time, vendor-centric ritual across hundreds of SaaS tools and started managing the actual surface: what data flows where, what has access to what, and what happens when any one of those relationships is compromised. That reframing turns third-party risk from a compliance formality back into a control. It also mirrors the internal exercise exactly — mapping trust boundaries and blast radius — which is why the same threat-modeling discipline applies to the vendor edge as to your own systems. For a threat model on a specific system and its integrations, mapped to NIST CSF 2.0 and CIS Controls v8, Attack Path produces a working first draft.

---

Part of a series on enterprise cybersecurity architecture.