Your third-party vendor passed the assessment. Their security questionnaire was thorough, their SOC 2 report was current, and their contractual security clauses were solid. Six months later, they were breached — through a vulnerability in one of their own suppliers.

That’s fourth-party risk. And it’s the reason why “we assessed all our vendors” is no longer a complete answer to the question of third-party risk management.

Third Party, Fourth Party — What’s the Difference?

The terminology is straightforward once you map it out:

• First party: Your organisation.
• Third party: Your direct vendors and suppliers — the companies you have contracts with.
• Fourth party: Your vendors’ vendors — the companies your direct suppliers depend on to deliver their services to you.

When you use a SaaS platform that runs on AWS, processes payments through Stripe, monitors its systems with Datadog, and stores backups with a specialist provider — each of those companies is a fourth party from your perspective. You have no contract with them, often no visibility into them, and no direct ability to assess them. But their security failures become your problem.

Why Fourth-Party Risk Has Grown Dramatically

Modern software is deeply interconnected. The average enterprise SaaS product relies on dozens of third-party services, APIs, and infrastructure providers. A security failure anywhere in that chain can cascade upstream to your organisation — even when your direct vendor did everything right.

The most significant supply chain incidents of the last five years have been fourth-party or deeper attacks. The SolarWinds breach, Log4j, the MOVEit vulnerability — these were exploits in software components used by vendors who were used by thousands of organisations. None of the affected companies had a direct relationship with the compromised software.

Regulators have noticed. DORA specifically requires financial entities to manage concentration risk across their entire ICT supply chain — including the sub-processors and infrastructure providers their direct vendors rely on. The EU AI Act, NIS2, and upcoming SEC disclosure requirements are moving in the same direction.

The Problem With Traditional VRM Approaches

Standard vendor assessment questionnaires don’t reach fourth parties. You can ask a vendor “do you have a vendor risk management program?” and they can say yes. But whether that program actually covers their critical sub-processors, and whether those sub-processors have adequate controls, is essentially invisible to you.

The traditional response — asking vendors to fill in a section about their sub-processors — creates a documentation exercise, not actual risk visibility. A vendor who lists AWS and Stripe as sub-processors hasn’t told you anything meaningful about how those relationships are managed or what controls are in place.

How to Manage Fourth-Party Risk Practically

You can’t assess every fourth party directly — that would mean assessing thousands of companies, most of which have no obligation to respond. The practical approach is a combination of four things:

1. Map your critical fourth parties

For your Tier 1 vendors, ask them to identify their critical sub-processors and infrastructure dependencies. Focus on the providers whose failure would prevent your vendor from delivering their service to you. Concentration risk is a particular concern — if three of your critical vendors all depend on the same cloud provider or payment processor, that’s a systemic exposure.

2. Make fourth-party requirements contractual

Your vendor contracts should require them to maintain a register of critical sub-processors, notify you of material changes to those relationships, flow down your security requirements to their critical suppliers, and maintain their own vendor risk program. This doesn’t give you direct visibility, but it creates accountability.

3. Monitor for fourth-party incidents in real time

When a significant security incident hits a major infrastructure provider (a cloud platform, a widely-used API, an authentication provider), you need to know whether any of your vendors depend on them — and you need to know quickly. Real-time monitoring that maps vendor dependencies and surfaces relevant threat intelligence is the only way to get ahead of incidents rather than reacting after the fact.

4. Use certification verification as a proxy

Requiring vendors to only use sub-processors who hold recognised certifications (SOC 2 Type II, ISO 27001) doesn’t eliminate fourth-party risk, but it creates a meaningful baseline. A sub-processor with a current, in-scope SOC 2 Type II report has had their controls independently audited. That’s a significantly better assurance than no verification at all.

What Good Fourth-Party Risk Management Looks Like

A mature approach to fourth-party risk doesn’t require you to directly assess every company in your vendors’ supply chains. It requires you to have clear contractual requirements, real-time visibility into your direct vendors’ posture, and the ability to quickly understand your exposure when a supply chain incident surfaces.

The goal is not zero fourth-party risk — that’s not achievable in a connected software ecosystem. The goal is knowing where your critical exposures are and having a plan to respond when something in your supply chain is compromised.