Your vendor risk assessment expired the day you signed it

Third-party risk management has a time problem. The entire process is built to produce a snapshot: assess the vendor, assess the software, assess the planned use, file the report, move on. It's the same model we used for procured software twenty years ago, when you bought a version of a product, deployed it on your own infrastructure, and it sat there unchanged until you decided to upgrade.

‍

That model made sense when both sides of the equation were static. Neither side is static anymore.

‍

The process we all run

If you've been through a vendor review, you know the drill. Profile the vendor: who are they, how mature is their security program, do they have a SOC 2, who are their subprocessors. Assess the software: what does it do, what data will it touch, what access does it need. Assess the use case: which team is bringing it in, for what purpose, with what scope.

‍

It's a reasonable process. It's also expensive, slow, and famously hard to scale, which is why most organizations reserve the full treatment for a fraction of their vendors and let the long tail through with a questionnaire or nothing at all.

‍

But scale isn't actually the biggest problem. The biggest problem is that every one of those assessments answers a question about a moment in time, and the moment passes almost immediately.

‍

Both sides of the equation are moving

Start with the vendor. SaaS products don't have versions you opt into. They ship continuously, sometimes weekly, sometimes daily. New features appear in your employees' browsers without anyone in your organization approving anything. New subprocessors get added with a quiet update to a legal page. And right now, nearly every vendor in your stack is racing to bolt on AI-powered features, which frequently means new data flows to new model providers that didn't exist when you did your review.

‍

The product you assessed in January is not the product your employees are using in July. Same name, same contract, different risk profile.

‍

Now look at your side. Software doesn't stay where you put it. A tool brought in for one narrow use case by one team gets discovered by another team, then another. New datasets get connected through the integration patterns that make modern SaaS so useful, OAuth grants chief among them. Each grant is a small, reasonable decision made by an individual employee. Nobody runs a risk review for clicking "Allow." Yet the average employee creates 88 OAuth grants, and 31 of them carry data-level permissions.

‍

Multiply that by every employee and every app, and you get what we call the Workforce Edge: the sum of all the small, decentralized decisions that shape how software and data actually move through your organization.

‍

Play that forward eighteen months and you get a familiar picture: a product holding delegated, programmatic access to your most critical data, in broad use across your employee base, backed by a risk assessment that was scoped to a single team evaluating a single use case. The paperwork says low risk. The paperwork is wrong.

‍

Consider Notion. It entered most organizations as a superpowered corporate wiki. Low stakes, easy approval, one team writing docs. Today it's an agentic runtime platform and a corporate data repository, with AI agents acting on its contents and connections spanning your critical systems. The Notion in your environment right now bears almost no resemblance to the Notion your review approved. And nothing in your TPRM process was ever going to tell you that.

‍

To be clear, none of this is a knock on Notion. Their product evolution has been a strong one, and it placed them at the center of how a lot of companies work. This is what good software does: it solves more problems for the customer, and each problem it solves earns it more data, more integrations, and more trust. The risk inherent in a product grows with its success. Your vendors will keep evolving. The question is whether your security program can keep up.

‍

Why annual reviews don't fix this

The standard answer is periodic reassessment. Put the vendor on an annual review cycle, refresh the questionnaire, update the file.

‍

An annual snapshot of a system that changes weekly is not risk management. It's an audit artifact. It exists to demonstrate that a process ran, not to tell you what's true. And it does nothing about the usage side of the equation, because the review process was never instrumented to see how adoption and access actually evolve inside your environment. You can ask the vendor what changed. You can't ask a questionnaire what your own employees did.

‍

This is where most of the industry's energy is going wrong. Faster questionnaires, AI-assisted questionnaires, questionnaire exchanges. We're breeding faster horses when the problem calls for a car.

‍

Assess continuously or assess fiction

If both the vendor and the usage are dynamic, the assessment has to be dynamic too. That means treating third-party risk as a stream of observations rather than a document:

• Watch what the vendor ships. New AI features, new subprocessors, new data handling terms. These are the events that should trigger a look, not the calendar.
• Watch how the software is actually used. Which teams have adopted it, what OAuth scopes it holds, which datasets it can reach programmatically. The delta between assessed use and actual use is where the risk lives.
• Re-score when the delta matters. A tool that gained read access to your file storage and tripled its user base since the last review isn't the same tool. Your risk register should know that before your incident response team does.

None of this is achievable with more questionnaires or a bigger GRC team. The average organization has twice as many SaaS apps as employees, and 60% of them are unsanctioned. No reviewer can keep that on an annual cycle, let alone a continuous one.

‍

How Nudge Security approaches this

This is the problem Nudge Security was built for. Nudge continuously discovers every SaaS and AI tool in use across your organization, then watches how that use evolves: new OAuth grants and the scopes they carry, API keys created and where they hold access, employees adopting a tool or walking away from it, integrations connecting one system's data to another.

‍

That stream of signal is what lets you assess risk against reality instead of against the use case someone described in a review two years ago. When a tool's footprint changes in a way that matters, whether that's a new grant into your file storage, a spike in adoption, or an AI feature reaching into a dataset it never touched before, you see it and can act on it, including nudging the employees involved to fix it themselves.

‍

The point-in-time review still has a job. It's where the assessment starts. The old model assumed the world held still after you signed. It never really did, and now it doesn't even pretend to.

‍

See how your SaaS footprint has changed since your last review. Start a free trial.