Your critical vendor passed every assessment. Strong financials. Clean audit. Solid SLA.

What you didn’t know — couldn’t know, with a standard assessment — is that they rely on a single cloud provider for their core infrastructure. The same cloud provider that just experienced a 14-hour regional outage.

That’s fourth-party risk. And it’s the blind spot that standard vendor risk programs weren’t built to see.

The Limit of Standard Vendor Assessment

Third-party risk management has matured significantly over the past decade. Most enterprise programs now assess vendor financial stability, security posture, contractual SLAs, and concentration exposure.

What they rarely assess is the supply chain behind the vendor — the sub-processors, infrastructure dependencies, and critical service providers that your vendor relies on to deliver what they deliver to you.

This is the fourth-party problem: your vendor’s resilience is bounded by the resilience of their critical dependencies. And in many cases, those dependencies are invisible to your risk program.

Why Fourth-Party Risk Is Accelerating

The consolidation of critical digital infrastructure has created a concentration risk at the ecosystem level that is largely invisible to individual vendor assessments:

A small number of cloud providers (AWS, Azure, GCP) underpin a massive portion of the commercial application stack. Your vendor, their backup vendor, and your backup-to-your-backup may all be running on the same infrastructure.
Content Delivery Network (CDN) and Domain Name System (DNS) dependencies are similarly concentrated. A disruption to a major CDN provider cascades through hundreds of dependent services simultaneously.
Payment processing, identity management, and Application Programming Interface (API) infrastructure are similarly centralized, creating correlated failure risk across seemingly unrelated vendors.
Many Software-as-a-Service (SaaS) vendors rely on the same underlying infrastructure providers — meaning that what appears to be supply chain diversity may mask significant concentration at the sub-vendor level.

Build Fourth-Party Visibility Into Your Program

Full fourth-party visibility is operationally challenging — but targeted visibility into your most critical vendor dependencies is achievable:

For your top-tier critical vendors, add a question to your assessment: ‘What are your three most critical infrastructure or service dependencies, and do any of them represent a single point of failure for your ability to serve us?’
Map the infrastructure stack behind your most critical SaaS applications. Which cloud provider are they running on? Do multiple critical vendors share that provider?
Run a ‘fourth-party failure’ scenario in your next tabletop exercise: your primary vendor is operational, but their critical infrastructure provider is unavailable. What’s your response?
Revisit your vendor concentration analysis. The goal isn’t just avoiding reliance on a single vendor — it’s avoiding correlated failure risk across vendors who share sub-dependencies.

Perfect fourth-party visibility is unrealistic. Targeted visibility into your highest-risk dependencies is not.

The Question Your Next Vendor Review Should Include

Here’s a simple addition to your next critical vendor review:

“Can you describe the top three sub-processors or infrastructure dependencies that would materially affect your ability to perform under our contract?”

Most vendors will answer honestly. Some will reveal concentration risks neither of you had mapped. All of it is intelligence your program needs.

Most vendor risk programs clearly see the first-order relationship. The fourth-party layer is where the surprises live. How deep does your vendor risk visibility actually go — and what would a fourth-party failure look like in your critical service stack?