Third-party risk management is a blind spot for most executives

Most organizations I’ve sat down with in the past few years already have some kind of vendor risk process, but, in most cases, the process usually runs on a security questionnaire that gets rubber-stamped and a deadline that beats a security review nearly every time.

Third-party risk management (TPRM) becomes nothing more than a compliance task when nobody above the security team decides how much diligence is enough diligence. When that happens, critical business decisions defaults to whomever is closest to the vendor relationship at the time, which is usually the person under the most pressure to move fast.

Ponemon Institute’s 2025 State of Third-Party Access in Cybersecurity study, commissioned by Imprivata and covering nearly 2,000 IT and security practitioners across the US, UK, Germany, and Australia, found that 47% of organizations had a breach or cyberattack in the past year that involved a third party getting into their network. Fifty-eight percent believe their strategy to address privileged access risks as inconsistent or non-existent, and 41% point to insufficient resources or budget as the reason.

Buying the tool doesn’t fix the root problem

A lot of executives see numbers like the ones above, decide the fix is a platform, and greenlight a TPRM tool. A year later, they’re frustrated it hasn’t changed anything.

KPMG’s 2026 Global Third-Party Risk Management Survey, based on responses from 851 organizations, found that most companies use only one to five systems to support their TPRM program, and integration between those systems is the single biggest pain point. The result is a patchwork of disparate and disconnected tools. Whatever doesn’t fit into those ends up in a spreadsheet that nobody officially owns and few know it exists. 

Why these programs stall

Sadly, even the best-intentioned TPRM initiatives often stall despite having the tools in place and the real desire to improve. While there are a number of contributing factors, the primary driver I’ve seen is the adoption of monolithic, cumbersome procurement processes. When the processes that underpin bidding, procurement, vendor vetting, and contract negotiations become so cumbersome and ungainly, anyone with a purchasing card will do everything in their power to work around them. That leads directly to shadow IT, and shadow IT quickly opens the door to unquantified and invisible cybersecurity risks that fall outside the bounds of corporate security visibility, policies, and programs.

The trouble starts the first time a business unit needs a vendor onboarded before that vendor’s review has ground its way through the monolithic TPRM program. Whoever makes that call to cut a corner or expedite before the process is complete sets the precedent, and after that, the exception becomes the process. That’s the same informal vendor management system the initiative was supposed to replace initially. The tiering model I’ve written about before can tell you which vendors deserve the closest scrutiny, but it can’t give the TPRM and security teams the standing to hold up onboarding until the review is done.

What executives actually need to own

More security headcount and a bigger TPRM budget would probably help, but the real fixes are twofold. First, your TPRM program must seek to strike a balance between diligence and business agility.  TPRM and cybersecurity should be framed in the same way: as a business enabler that supports organizational strategy, not a roadblock or barrier to business progress. Build a base TPRM process that is fast, approachable, and usable, then communicate its corporate benefits so that staff want to adopt it.  Then, build a safety valve into it, such that when exceptions are needed, there is a documented process that allows for rapid procurement and lightweight evaluations, but doesn’t just automatically greenlight a purchase. Back all of that with policies and well-communicated expectations around behaviors and outcomes, then be sure to enforce those policies when the time comes.

The second fix is to name an actual owner for the vendor risk program; someone who isn’t buried three layers under the CISO. That also means putting vendor exceptions on the same governance calendar as other material risk decisions instead of letting them disappear into a ticket queue, and asking, at that review, the simple questions: which vendors could hurt us most, do we actually know that, and how are we certain? 

Security culture problems don’t stay inside the security team. I’ve made the case before about executive sponsorship inside the security program itself, and vendor risk is that same problem showing up in a different part of the business. Architect an attractive process, fix the ownership, and the tools you already bought are far more likely to earn their keep.

Nothing here should be taken as legal, financial, or security advice for your specific situation — see the full disclaimer at cyberresilience.com/disclaimer.