Fourth-Party Risk: Your Vendors' Vendors
The vendor register you've built only covers your direct relationships — here's how to get a handle on the layer beneath it without drowning in subcontractor audits you can't enforce anyway.
In mid-2023, a vulnerability in Progress Software's MOVEit Transfer product was exploited by the Cl0p ransomware group. The notifications that followed landed at organizations all over the world. Most of them didn't run MOVEit. Their payroll provider did, or their managed file transfer vendor did, or their law firm did. They had never heard of Progress Software, never reviewed it, never signed a contract with it. The breach showed up in their incident log anyway.
That's fourth-party risk in its clearest form. You vet your vendors, collect their SOC 2 reports, fill out the risk register — and then a company you've never dealt with gets compromised, and your customers' data goes with it.
What fourth-party risk actually is
Third-party risk is the risk from your direct vendors — companies you've contracted with, whose names appear in your DPA and your risk register. Fourth-party risk is one step further: it's the risk from your vendors' vendors. The cloud provider they've built on. The payroll processor they've outsourced HR to. The open-source library baked into their product that neither you nor they are actively maintaining.
The term is sometimes extended to "Nth-party risk" to acknowledge that the chain doesn't stop at four. Your SaaS vendor runs on AWS. AWS uses hardware from manufacturers with their own supply chains. In practice, nobody traces all the way down — the real question is where to draw the line and what to do at the boundary you pick.
Most mature programs draw it at fourth-party. You're not trying to achieve perfect visibility into every node in a global supply chain. You're trying to ensure that the vendors you've trusted are doing the same diligence downstream that you're doing with them.
Why it's harder than third-party risk
With a direct vendor, you have a relationship. You can request their SOC 2, send a questionnaire, and put requirements in the signed agreement. With a fourth party, you have none of that. No contract, no audit rights, no direct leverage. Your vendor has those things — you don't.
This creates a visibility problem that no amount of internal process can fully solve. Some security teams try to identify and assess every subprocessor their critical vendors rely on. That approach collapses quickly: a mid-sized SaaS company might depend on dozens of subprocessors across infrastructure, payments, email delivery, and analytics — and that list rotates as they ship features. Trying to independently evaluate each one for each vendor is a job for a large team, and it still won't catch the integration they added last quarter without telling anyone.
The practical answer isn't comprehensive enumeration. It's a combination of contractual flow-down requirements, smart DPA drafting, reading the subprocessor disclosures vendors already publish, and keeping your eyes on concentration risk. None of these fully solves the problem. Together they give you defensible coverage.
Where your contracts actually help
The most direct influence you have over fourth-party risk is in the contract you sign with your direct vendor. Specifically the Data Processing Agreement. A well-drafted DPA should give you four things:
- A current subprocessor list. The vendor maintains a public or customer-accessible page listing who they share your data with, what role each party plays, and where they're based. Most enterprise SaaS companies publish this now — Stripe, Twilio, Salesforce, and their peers all have publicly searchable subprocessor registries.
- Advance notice of new subprocessors. Actual notice before a new party receives your data, not a retroactive log. Thirty days is the market standard and gives you a real window to assess and respond.
- A right to object. If a new subprocessor introduces risk you can't accept, you need a mechanism to say so. The vendor may be able to terminate if you object, but the right still gives you standing — and signals to the vendor that this clause gets read.
- Flow-down obligations. This is the clause that does the most work. It requires your vendor to impose equivalent data protection requirements on their subprocessors. You can't directly audit Progress Software, but you can contractually require that your file transfer vendor does — and that those obligations survive any subprocessor change.
The full mechanics of DPA drafting, including how flow-down interacts with GDPR's controller-processor chain, are in DPA vs BAA explained. The subprocessor notice and flow-down sections are often the most negotiated parts of a data processing agreement, and there's a reason buyers have started pushing harder on them.
What your vendor's SOC 2 tells you about their vendors
Your auditor won't directly test your fourth-party controls, but they will expect you to have reviewed your vendors' programs — and those programs should include their own vendor management.
The AICPA's common criteria include CC9.2, which covers how an organization manages risk from third parties including subservice providers. When you read a vendor's SOC 2 Type 2 report, one of the things you're looking at is whether their vendor management controls were tested and held up. Check the relevant control descriptions and test results: Did the auditor actually test vendor due diligence, subprocessor monitoring, and third-party agreement requirements? Were there exceptions?
A vendor with a clean SOC 2 Type 2 that includes meaningful CC9.2 testing is telling you something useful: an independent CPA watched how they manage their vendors and found it working. That's imperfect — the test period is a snapshot, not a guarantee — but it's meaningfully better than a vendor with no attestation and no vendor management process they can describe. The SOC 2 guide covers how to read these reports, including where exceptions appear and what they signal.
From your side, when your own auditor asks about vendor risk management, the most sophisticated buyers also expect you to have thought about concentration risk in your vendor stack, not just documented each vendor in isolation. I cover what a tier-based vendor review looks like in the vendor risk assessment checklist.
The concentration risk you're probably underestimating
There's a specific version of fourth-party risk worth isolating: the shared infrastructure that underpins many of your vendors at once. A large fraction of B2B SaaS products run on AWS or Azure. Twilio handles SMS and transactional email for a wide swath of the software stack. A handful of identity providers sit inside authentication flows at thousands of vendors.
This isn't necessarily a flaw — the security practices at major cloud hyperscalers are almost certainly better than what most mid-market SaaS vendors could build independently. But it does mean a significant event at one of those providers creates simultaneous exposure across many of your vendor relationships at once, in ways that won't show up in any individual vendor's SOC 2.
For your most critical vendors, it's worth knowing which shared infrastructure they depend on — not to avoid it, but to understand the blast radius and make sure your business continuity planning accounts for it. If your primary vendor and your backup both run exclusively on the same cloud region, your failover plan may not hold when you actually need it.
The practical posture
Nobody manages fourth-party risk to zero. The goal is defensible coverage and a program that's proportionate to what's actually at stake.
- Use your DPAs to push flow-down obligations and subprocessor disclosure requirements into every contract with a critical vendor. Silence on this point is a negotiating choice that favors them.
- Review published subprocessor lists before you sign. Subscribe to change notifications if the vendor offers them — many do via email list or RSS.
- When reviewing a vendor's SOC 2, look at the vendor management controls. They tell you something concrete about how that vendor manages its own downstream relationships.
- Map the shared infrastructure underneath your most critical relationships. Identify meaningful concentrations and factor them into your continuity planning.
- Don't try to directly audit every fourth party yourself. That's your vendor's obligation, and your contract should say so explicitly.
The underlying third-party risk program that fourth-party risk sits inside — inventory, tiering, assessment, monitoring — is covered in the vendor risk guide. Fourth-party is the layer you add once those fundamentals are running. Get the basics right first; then build the next tier of coverage on top of them.