A fourth party is your vendor's vendor: the sub-processors your SaaS providers rely on to run their service, such as their cloud host, email delivery, or AI provider. You never contract with them and usually cannot see them, yet a breach or outage at that layer still reaches your data. We read the public sub-processor disclosures of 163 business-software vendors one by one. The result: 92% run on Amazon Web Services, close to 100% depend on at least one of just three companies, and the disclosures that prove it are quietly disappearing.
Why this is original
Every SaaS vendor is required to publish the list of companies it depends on. Each list is public and unremarkable on its own, and nobody aggregates them. So the layer underneath the software economy has never been mapped at scale. We mapped it: this is the first published measurement of how concentrated that layer is, built by reading and canonicalising 163 vendors' own disclosures. It is not a survey or an estimate. It is a count.
One company sits under almost everything
We use one repeatable measure, the Fourth-Party Concentration Index (FPCI): the share of sampled vendors that name a given provider as a sub-processor. Amazon Web Services has an FPCI of 92%. Google Cloud, 86%. Combine the three hyperscalers and almost no vendor escapes: in our deep-itemised sample, 100% depended on at least one of AWS, Azure, or Google Cloud.
The practical meaning is blunt. A single serious incident at AWS would reach more than nine in ten of these tools at once. There is almost no such thing, in this sample, as a vendor failure that stays contained to one vendor.
How many fourth parties are you actually exposed to?
Concentration is only half the exposure. The other half is volume. The vendors we itemised disclosed anywhere from a handful of sub-processors to more than 50 each, with several naming between 27 and 43. A single recruiting or support tool can carry 30 or more downstream dependencies on its own. So your true fourth-party count is not the number of vendors you signed with, it is a large multiple of it, and almost none of it appears on a contract you ever reviewed.
Inside each function, concentration is even worse
A stack does not fail by cloud in the abstract. It fails by function, and inside most functions the market has collapsed onto one or two names. Edge delivery defaults to Cloudflare. Transactional email runs mostly through the Twilio family (including SendGrid and Segment, an FPCI of about 68%) and Mailgun, now owned by Sweden's Sinch. And the newest layer, AI, arrived already concentrated: OpenAI has an FPCI of about 52% and Anthropic about 40%. Two years ago that layer barely appeared in disclosures. It is now mainstream, and it formed narrow.
Beyond the big three, the same supporting cast recurs across almost every stack. Payments run through Stripe. Transactional email runs through the Twilio family, SendGrid, and Mailgun. Monitoring and error tracking cluster on Datadog and Sentry. Customer support sits with Zendesk and Intercom. Identity leans on Okta and Auth0. Product analytics concentrate on Segment, Amplitude, and Mixpanel. If you want to guess what is underneath your own tools before you check, this is the shortlist you will almost certainly find.
There is a US transfer question inside almost every tool
The overwhelming majority of the distinct sub-processors we catalogued are US-headquartered, and in our deep-itemised sample every single vendor relied on at least one US-based sub-processor. This is the point most procurement checks miss: a vendor can offer EU data residency and still sit on a fourth-party layer that is overwhelmingly US-controlled, because residency governs where data is stored, not the headquarters or lawful-access exposure of the companies underneath. For anyone assessing a vendor under GDPR Chapter V or the Swiss FADP, the transfer question does not stop at the vendor. It runs one layer deeper, into companies the customer never contracted with and usually cannot see.
Europe's alternatives exist, but they are rare
European-headquartered providers did appear in the data, including Hetzner in Germany, OVH in France, Aiven in Finland, Sinch in Sweden (which now owns Mailgun), and Exoscale in Switzerland. But they were the clear exception, not the rule. For an organisation with data-sovereignty or FADP concerns, the map shows European options are real and usable, yet the default gravity of the SaaS supply chain still pulls almost everything back to a small group of US providers.
The disclosures are disappearing
This is the finding we did not go looking for, and the one that matters most. Genuine non-disclosure is rare, because the law effectively requires a list. But a large and growing share of vendors no longer publish it in a form anyone can actually read at scale. Across the vendors we checked, roughly four in ten served their list only through a JavaScript trust portal, a PDF released on request, or a page behind a login. The list renders for a human clicking through a browser. It does not render to anyone trying to read many of them, compare them, or hold the market accountable.
The direction of travel is toward less openness, not more. One vendor in the sample, Render, replaced its open trust centre with an NDA-gated document centre, meaning a customer must sign away rights simply to see who Render depends on. The effect, whether intended or not, is that the fourth-party layer is becoming harder to audit at exactly the moment DORA, NIS2, and GDPR are demanding that organisations map it.
This is the accountability heart of the report: the more regulators ask organisations to understand their supply chain, the harder the market is making it to see.
How to map your own fourth-party exposure
You can run a version of this analysis on your own stack. Start with the vendors you actually use, pull each one's sub-processor list, canonicalise the names to the real underlying providers (AWS, Amazon Web Services, and Amazon.com are one company), and then flag two things: which providers are shared across many of your vendors, and which vendors no longer publish a readable list at all.
Doing this by hand across a large estate is slow, and the gated layer makes it harder every quarter. Continuous, outside-in monitoring of the kind this research argues for is built into the Supplier Shield module in Acuna GRC, and for a first structured pass across a regulated estate, a specialist advisor such as Abilene Advisors can run the mapping with you.
What this means
Three conclusions for anyone running a third-party programme. First, treat AWS, Google Cloud, and Azure as systemic fourth parties, not ordinary vendors: if more than nine in ten of your tools share one provider, continuity and exit planning has to start there. Second, extend due diligence one layer deeper, into the fourth-party layer where both the concentration and the US-transfer exposure actually live. Third, capture the disclosure while you can, because sub-processor lists are being gated and may not stay readable.
Related reading
The discipline this sits inside: what is third-party risk management. The practical layer: our vendor due diligence checklist, including fourth-party checks. The regulatory obligation: concentration risk is explicit in DORA (Article 29) and supply-chain security in NIS2.
Frequently asked questions
What is a fourth party in risk management?
A fourth party is a sub-processor your direct vendor depends on, such as its cloud host, email provider, or AI provider. It is one layer below the vendor you contracted with. Because a breach or outage there still reaches your data, fourth-party risk is now a core part of third-party risk management.
Which cloud providers do most SaaS companies use?
In this research, 92% of sampled SaaS vendors named Amazon Web Services as a sub-processor and 86% named Google Cloud, and close to 100% depended on at least one of AWS, Microsoft Azure, or Google Cloud.
What is a sub-processor?
A sub-processor is a third party a vendor engages to process data on its behalf. Under GDPR Article 28, vendors must disclose their sub-processors, which is why these lists are public and can be mapped.
Why is SaaS supply-chain concentration a risk?
When most of your tools quietly depend on the same few providers, a single outage or compromise at one of them can affect a large share of your software at once. Concentration turns many separate vendors into one shared point of failure.
How can an organisation reduce fourth-party and vendor concentration risk?
Tier vendors by criticality, extend due diligence to the sub-processor layer, treat the dominant cloud providers as systemic dependencies in continuity and exit planning, and monitor sub-processor disclosures continuously, because they change and are increasingly gated.
Methodology
We itemised the public GDPR Article 28 sub-processor disclosures of 163 widely used B2B SaaS vendors, using only each vendor's own published disclosure. Access date for every record: 8 July 2026. Corporate variants were canonicalised to one entity before counting (AWS to Amazon, Azure to Microsoft, SendGrid and Segment to Twilio). Concentration percentages are pooled across the 142 vendors in our primary itemisation batches; a further 21 vendors recovered via rendered trust-portal pages are part of the collection but held out of the pooled percentages to avoid double counting. Nothing was inferred or estimated; where a vendor published no readable list, that was recorded as data.
Limitations
We almost certainly understate concentration: the vendors we could not extract sit behind trust portals and are disproportionately large, mainstream vendors most likely to run on AWS and Google, so excluding them pulls the measured figure down, not up. We count disclosed dependencies only, and a listing shows that a dependency exists, not how critical it is. Jurisdiction is by headquarters, not data-storage region. Vendors that publish readable lists skew toward more transparency-minded companies, which is itself relevant to the disappearing-disclosure finding.
About the author
This report was researched and written by the Supplier Shield team, the editorial desk covering third-party and supply-chain risk. Our research is built only from public, verifiable sources, and is free to cite with attribution.
Cite this report
Supplier Shield, The Fourth-Party Map 2026, July 2026. Free to cite and reference with attribution and a link to this page. The full anonymised dataset and all charts are available for reuse with a link back.