Sponsored content

The third-party risk blind spot: Why vendor oversight fails under pressure 

By Richard Chambers

Ask a chief audit executive whether the organisation manages third-party risk, and the answer is almost always yes. There are contracts in place, onboarding reviews on file, and a vendor register that appears fully assigned. On paper, everything looks accounted for. 

Set that against what actually happens: roughly three-quarters of organisations (76%) experienced at least one vendor-related disruption in the past two years, and more than half of those disruptions resulted in $1 million or more, according to Optro research from When Business Continuity Fails.  

I have seen this pattern repeatedly over five decades in and around internal audit. The vendor relationship was documented, and the risk was rated. Once the vendor went down, what nobody could produce was evidence that it could recover on the timeline the business had assumed it would. 

Having a document is not the same as proving recovery under real conditions. Most organisations have documented their vendor relationships without ever testing them. That is where they discover, too late, that a critical vendor cannot recover as expected.

Third-party resilience is an operational risk 

Once you map the outside dependencies behind critical operations, vendor exposure stops behaving like a procurement matter. It should be governed like any other operational risk, with one complication: the control environment sits inside somebody else's organisation.

What I learned when our delivery network closed 

When I led The Institute of Internal Auditors (IIA) through COVID-19, our business model depended on candidates sitting certification exams at testing centers around the world. Those centers closed within days of each other. No continuity plan we had on file contemplated a scenario in which every one of them shut at once, and we rebuilt around remote proctoring in about five weeks. 

We recovered because we understood our mission-critical processes and had people willing to adapt, not because of anything in the documentation. What strikes me looking back is the nature of the failure. Our exposure sat in a delivery network we did not own, which our planning had treated as stable and permanent rather than a dependency that could fail.

The lesson was not simply that we needed a better plan. It was that we had mistaken dependency for stability.

Vendor oversight is documented far more than it is tested

The same Optro research bears that pattern out at scale. Most organisations use familiar vendor oversight practices: 

• Vendor BCM documentation reviews: 39%
• Periodic BCM reassessments for critical vendors: 38%
• BCM assessments at vendor onboarding: 36%
• Resilience requirements written into vendor contracts: 36%

Joint continuity testing with critical third parties sits at 31%

That gap explains most of what goes wrong during a live event, because each of those common mechanisms proves something narrower than it appears to:

• A documentation review tells you a plan exists.
• An onboarding assessment reflects what a vendor said at the start of the relationship.
• A completed questionnaire can be useful, but they are still self-reported evidence.
• A contractual resilience clause may define accountability without proving recovery capability. 

Internal auditors apply a different standard everywhere else. We do not accept management's assertion that a control operates effectively. We test it, and we ask for evidence. That same insistence has not been applied to external providers. And our own function is not exempt from the finding: 35% of internal auditors in the survey say they have never formally stress-tested a cloud or IT outage scenario, in a research population that ranks cloud infrastructure as its top third-party continuity risk.

You cannot govern a dependency you have not mapped

Testing a vendor relationship assumes you know which processes rest on it, and that assumption does not hold in most organisations. When asked how thoroughly they map critical business processes to their dependencies, only 42% report that all critical services are fully mapped with defined impact tolerances. Another 56% describe their mapping as partial or minimal. The majority are managing recovery objectives without an accurate picture of the upstream and downstream assets required to meet them.

The problem becomes clear during incident reviews. When organisations examined why their continuity plans fell short during real events, 31% pointed to impacted processes that were not documented or mapped accurately, and 27% pointed to third-party failures that process mapping had never anticipated.

Senior leaders often believe dependency mapping is further along than it really is. Executives report dependency mapping adoption at 41%, against 27% across all functions. In my experience, senior leaders rarely overstate deliberately. They trust documentation that nobody has pressure-tested, which is precisely the condition internal audit exists to detect.

A vendor’s word is not evidence 

Independent review remains uncommon. Only 35% of organisations have had their business continuity programs externally validated or audited in the past 12 months, nearly 60% have gone more than a year without independent review, and 5% have never had a formal assessment. Programs assessed only by the people who run them will look stronger than they are.

The same logic applies one level out. When a vendor tells you its continuity program is sound, you are accepting a self-assessment from an organisation with every incentive to describe itself favourably, and you are accepting it without the independent review you would demand of an internal control. For a provider your critical processes cannot operate without, that is not sufficient.

Responsibility for third-party resilience is fragmented 

Part of why these gaps persist is that no single function is positioned to close them. Vendor risk sits with procurement. Continuity sits with the resilience team. Technology dependencies sit with IT. Internal audit reviews all of it periodically and owns none of it. Each function operates responsibly within its remit, and the biggest risk often sits in the handoff points between those functions.

The structure shows up in the research. Roughly one in seven organisations runs business continuity as a completely standalone function, with no formal connection to operational risk management, third-party risk, or disaster recovery. When responsibility is spread across every function, accountability often disappears. 

This is exactly where internal audit should be at its best: identifying the exposure that everyone touches and no one truly owns. Reporting that no function can produce end-to-end evidence for a critical dependency is a finding, and it is one the board can act on in a way it cannot act on four partial assurances from four functions.

AI is widening third-party exposure faster than testing can keep up

For audit leaders, the issue is not simply that AI introduces new risk. It is that these risks often arrive through external providers faster than governance, testing, and accountability models can adapt. The three least stress-tested scenarios globally are agentic AI failure at 30%, never tested, shadow AI exposure at 29%, and AI-enabled cyberattacks at 28%.

Each one typically arrives through a third party. An agent acting on the organisation's behalf runs on a provider's model. Shadow AI is, by definition, a tool somebody adopted without review. An AI-enabled attack on a provider becomes an attack on everyone connected to it.

Meanwhile, 26% of organisations report a formal AI governance program covering business continuity. The technology is moving faster than the testing, accountability, and governance structures around it.

Closing the third-party resilience gap

Fully integrated continuity programs recover within defined targets at twice the rate of minimally integrated ones, 31% against 15%, and are more than twice as likely to activate response protocols within four hours, 50% against 20%. The problem is less lack of effort than lack of coordination. 

Third-party resilience requires coordination across audit, risk, IT, and continuity. Treating it as a contracting activity is what leaves the gap open, and it is the gap the data keeps pointing to: oversight that is thoroughly documented and rarely tested, sitting on dependency maps that were never completed. Internal audit is well-positioned to close it, because asking for evidence instead of accepting assurance is already what we do.

Five questions to ask about your critical vendors

1. Which critical processes stop if this provider stops, and when was that mapping last refreshed?
2. Has this provider's recovery time objective ever been demonstrated, and did we see the results?
3. Which of our critical third parties have participated in a joint continuity exercise in the past 12 months?
4. Where a provider is concentrated or irreplaceable, what alternative is documented, and has it been tested?
5. Which AI tools, agents, and models now sit inside our critical processes, and whose infrastructure are they running on?

Most of these questions are answerable; the harder part is asking them of every critical vendor, often enough to stay current, across a population large enough that periodic manual review cannot keep pace. That is where manual review begins to fall behind. 

For teams trying to scale this work beyond periodic manual review, Optro’s playbook, Effective third-party risk management: Harnessing AI-powered technology for success, outlines how AI-driven approaches can improve vendor categorisation and support more continuous monitoring.