Third-Party vs. Fourth-Party Risk: What's the Difference?

The short version

Third-party risk is the risk introduced by the vendors you contract with directly — the SaaS tools, processors, and providers whose names appear on your invoices. Fourth-party risk is the risk introduced by their vendors: the sub-processors, infrastructure providers, and contractors your vendors rely on to deliver their service to you.

Put plainly, your third parties are the companies you chose. Your fourth parties are the companies they chose. You signed a contract with the first group and can hold them to it; the second group you may never have heard of — yet their failures still reach you through the vendor in between.

A worked example

Say you use a payroll platform. The payroll platform is your third party. To run, it depends on a cloud host for compute, an email provider for payslip delivery, and an identity provider for login. Those three are your fourth parties.

If the cloud host has a regional outage, your payroll platform goes down — and so does your ability to pay people on time. You never signed anything with that cloud host, but the dependency is real, and the impact lands on you. Fourth-party risk is simply the recognition that your exposure does not stop at the edge of your direct contracts.

Why the fourth party is the one you can't see

Third-party risk is hard but tractable: you have a contract, a point of contact, and the leverage to ask for evidence. Fourth-party risk is harder for one structural reason — you have no direct relationship with it. The sub-processor owes you nothing, answers none of your questionnaires, and changes without telling you.

That invisibility is where surprises live. A vendor can pass every assessment you run and still inherit a critical weakness from a sub-processor you never assessed. Most real-world supply-chain incidents travel this path: the breach happens several links down the chain and surfaces at the company whose name is on the headline.

Concentration is the hidden multiplier

The reason fourth-party risk deserves its own attention is concentration. Map the sub-processors behind your vendors and a pattern almost always appears: a handful of cloud providers, identity platforms, and CDNs sit underneath dozens of the tools you use.

That means a single fourth party can be a shared point of failure across vendors that look completely independent on your inventory. Ten green, well-assessed third parties can all go dark at once if they quietly share the same underlying provider — a risk no per-vendor review will catch, because each vendor in isolation looks fine.

How to bring fourth parties into view

You cannot assess what you cannot see, so the first job is discovery. The practical sources:

• Sub-processor lists — most serious vendors publish one, often linked from their security or legal pages, and commit to notifying you of changes.
• Data processing agreements — the DPA typically names approved sub-processors and the terms under which new ones can be added.
• Security questionnaires — ask the vendor directly which providers underpin the service and where data physically resides.
• Architecture and audit reports — a SOC 2 or pen-test summary often reveals the infrastructure and key dependencies behind the product.

How to manage what you find

Once the fourth parties are visible, you manage them indirectly — through the third party you do control. The levers:

• Flow-down requirements — contractually require your vendor to hold its sub-processors to the same security, privacy, and breach-notification standards you require of the vendor.
• Change notification and objection rights — the right to be told before a new sub-processor is added, and to object when one is unacceptable.
• Concentration mapping — record the major sub-processors behind each vendor so you can see, at a glance, which fourth parties are shared across your stack.
• Proportionate depth — chase the fourth parties behind your critical, high-data vendors hard; for low-impact vendors, knowing the sub-processor exists is usually enough.

Common mistakes

Fourth-party programs tend to fail in predictable ways:

• Stopping at the third party — assessing the vendor thoroughly and never asking what sits behind it.
• Treating the sub-processor list as a formality — collecting it once at onboarding and never checking it again, so additions go unnoticed.
• Scoring vendors in isolation — missing that several of them rest on the same fourth party, and therefore share its fate.
• Chasing every fourth party equally — burning effort mapping the dependencies behind a low-risk tool while a critical vendor's chain stays unexamined.

Where to draw the line

Taken literally, the chain never ends — your fourth parties have their own vendors, and so on. The goal is not infinite recursion; it is proportionate visibility. For most programs that means: know your third parties well, know the significant fourth parties behind your critical vendors, and watch for concentration across the whole set.

Done that way, the distinction stops being academic. Third-party risk tells you about the vendors you chose; fourth-party risk tells you about the dependencies you inherited — and keeping both in one register is what lets you answer, honestly, how far your real exposure reaches.