TPRM16 April 202613 min read

Your Vendors All Depend on AWS: The Fourth-Party Concentration Risk Nobody Is Measuring

By ArvexLab Team — Compliance Research

We Scraped 10 Vendor Subprocessor Pages. Here Is What We Found.

Every company regulated under GDPR must publish a list of subprocessors. It is a legal requirement under Article 28. These lists are public, updated regularly, and freely available on vendor trust centre pages.

We scraped the subprocessor disclosure pages of 10 widely-used SaaS vendors: Atlassian, Datadog, GitHub, Stripe, Okta, Zendesk, Box, GitLab, Zoom, and Dropbox. We extracted every third-party subprocessor, their purpose, and their processing locations.

The results are sobering.

The Concentration Numbers

Subprocessor	Vendors Using It	Portfolio %	Role
Amazon Web Services	10 of 10	100%	Infrastructure
Google / GCP	9 of 10	90%	Infrastructure
Microsoft / Azure	8 of 10	80%	Infrastructure
Twilio / SendGrid	8 of 10	80%	Notifications
Cloudflare	6 of 10	60%	CDN / Security
OpenAI	5 of 10	50%	AI features
Anthropic	5 of 10	50%	AI features
Snowflake	4 of 10	40%	Analytics
Zendesk	4 of 10	40%	Support
Salesforce	5 of 10	50%	CRM

Every vendor in our sample depends on AWS. Nine out of ten depend on Google Cloud. Eight out of ten depend on Microsoft Azure and Twilio.

This is not a vendor risk problem. This is a systemic concentration risk that most organisations have never measured.

What Fourth-Party Risk Actually Means

When you assess Atlassian, you are assessing a company that depends on AWS for hosting, Cloudflare for content delivery, Twilio for notifications, MongoDB for database services, Snowflake for analytics, and Databricks for data processing. Each of these is a fourth party to your organisation. You have no contract with them. You have no SLA with them. You have no visibility into their operations.

But if AWS eu-west-1 goes down, Atlassian goes down. And so does Datadog. And GitHub. And Stripe. And Okta. And Zendesk. And every other vendor in your portfolio that runs on AWS.

That is not a theoretical scenario. It happened.

When Concentration Risk Becomes a Cascade

CrowdStrike, 19 July 2024. A single faulty content update crashed 8.5 million Windows systems worldwide. Delta Air Lines lost $500 million. Healthcare systems lost $1.94 billion. The total damage to Fortune 500 companies: $5.4 billion, with cyber insurance covering only 10-20% of losses.

CrowdStrike was not a vendor to most affected organisations. It was a vendor's vendor's vendor. A fourth party. Most companies had no idea CrowdStrike was in their supply chain until it brought down their operations.

AWS, 20 October 2025. A half-day outage in multiple regions resulted in an estimated $581 million in insurance losses. But the insured losses were a fraction of the total impact. Every SaaS vendor running on AWS was affected. Every customer of those vendors was affected. The cascade was systemic.

Axios npm package, 31 March 2026. North Korea's Lazarus Group compromised the most popular HTTP client in the JavaScript ecosystem. Axios is present in 80% of cloud environments. The malicious version was live for less than three hours. In that window, OpenAI's macOS code-signing certificates were exposed through a GitHub Actions workflow that pulled the compromised package. The attack chain: npm registry (first party) → Axios maintainer account (compromised) → OpenAI CI/CD pipeline (fourth party). Nobody in this chain had a direct relationship with the attacker's target.

Why Your Risk Assessment Misses This

Traditional TPRM programmes assess vendors one at a time. You evaluate Atlassian. You evaluate Datadog. You evaluate GitHub. Each gets a score. Each looks acceptable.

What you miss is that all three depend on the same infrastructure. A single AWS incident does not trigger one vendor risk event. It triggers ten simultaneously. Your carefully diversified vendor portfolio is not diversified at all.

The maths is straightforward. If you have 15 vendors and all 15 depend on AWS:

Your apparent single-vendor concentration: 6.7% (1/15)
Your actual infrastructure concentration: 100%
Your regulatory risk: a single incident can trigger 15 simultaneous vendor incidents, each requiring an Art. 23 notification

The Regulatory Framework Already Exists

NIS2 and DORA both address this problem explicitly.

NIS2 Article 21(2)(d) requires organisations to address "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." Your vendors' subprocessors are part of your supply chain. ENISA's implementation guidance makes clear that this includes downstream ICT dependencies.

DORA Articles 28-29 go further. Financial entities must maintain a Register of Information documenting all ICT third-party arrangements, including "the identification of subcontractors." Article 29(2) requires entities to assess "whether the provision of ICT services by the ICT third-party service provider is concentrated with a limited number of ICT third-party service providers."

The ESAs designated 19 Critical ICT Third-Party Providers (CTPPs) in November 2025. All 19 are in our vendor catalog. The oversight framework exists precisely because regulators recognise the systemic risk of cloud concentration.

EIOPA has flagged cloud provider concentration as a systemic risk to the insurance sector. Munich Re's 2026 Cyber Insurance report identifies "hyperconnectivity, systemic dependencies and mono-structures" as the primary concern for accumulation modelling. A single cloud provider outage can trigger thousands of cyber insurance policies simultaneously.

What We Found in the Subprocessor Data

Beyond the headline concentration numbers, we found structural patterns that most organisations do not track.

The notification dependency. Twilio and SendGrid handle notifications for 80% of vendors in our sample. If Twilio goes down, you will not receive alerts from 8 out of 10 of your vendors. The irony: the system designed to warn you about incidents is itself a concentration point.

The AI duopoly. OpenAI and Anthropic each appear as subprocessors for 50% of vendors. Both Datadog and GitHub list both. As AI features become integral to SaaS products, your vendor portfolio's AI capabilities are concentrated in two companies, both of which are themselves dependent on cloud infrastructure from the Big Three.

The support chain. Zendesk handles support for 4 of 10 vendors (GitLab, Dropbox, Datadog, Okta use it as a subprocessor). Salesforce handles CRM for 5 of 10. A breach at Zendesk could expose support ticket data from half your vendor portfolio simultaneously.

The monitoring paradox. Datadog is used by Okta to monitor its infrastructure. But Datadog itself uses AWS, Google, and Microsoft as subprocessors. Your vendor's monitoring system shares dependencies with the system it is monitoring. This creates blind spots in incident detection.

How to Actually Measure Concentration Risk

Step 1: Map your fourth parties. Every vendor in your portfolio has a GDPR subprocessor page. They are legally required to publish it. Collect them. Extract the subprocessor names. Cross-reference against your vendor list.

Step 2: Build the dependency graph. For each fourth party, count how many of your vendors depend on it. The result is your concentration score. AWS at 100% means a single AWS incident is a portfolio-wide event.

Step 3: Identify single points of failure. Look for subprocessors that appear in every critical vendor. These are your systemic risks. They need to be in your risk register, not as "vendor risk" but as "infrastructure concentration risk."

Step 4: Model the cascade. For each concentrated fourth party, ask: if this entity experiences a 4-hour outage, which of my vendors are affected? Which business functions depend on those vendors? What is the aggregate business impact? This is the scenario your board report should include.

Step 5: Monitor subprocessor changes. Vendors add and remove subprocessors regularly. Under GDPR Art. 28, they must give you 30 days notice. Subscribe to notifications for your critical vendors.

The Business Case for Fourth-Party Visibility

Compliance aside, concentration risk has direct financial consequences:

Cyber insurance. Underwriters increasingly model concentration scenarios. A portfolio with 100% AWS dependency will face higher premiums than one with diversified infrastructure. Munich Re explicitly models "mono-structure" risk in their 2026 pricing framework.

Business continuity. If your top 5 vendors all run on the same cloud, your BCP for "vendor outage" is actually a BCP for "cloud outage." That is a fundamentally different scenario.

M&A due diligence. Acquirers and PE firms are starting to assess fourth-party concentration as part of technology due diligence. A target company whose entire stack runs on a single cloud provider carries concentration risk that affects valuation.

Board reporting. When the board asks "what happens if AWS goes down?", the answer is not "our website goes offline." The answer is "every vendor in our portfolio is affected simultaneously." That is a very different conversation.

What You Can Do Today

Download your vendors' subprocessor lists. Start with your critical and high-tier vendors. Most have a page at `/legal/sub-processors` or `/trust/subprocessors`.

Build a simple concentration matrix. Rows = your vendors. Columns = common fourth parties (AWS, GCP, Azure, Cloudflare, Twilio). Fill in the grid. Count the columns where every row has a check mark.

Add concentration risk to your risk register. Not "AWS might go down" (that is an external event). Instead: "15 of our 15 vendors depend on AWS, creating a portfolio-wide single point of failure."

Include fourth-party scenarios in your BCP testing. Test the scenario where your top 3 vendors all go down simultaneously. Because if they share infrastructure, they will.

Discuss with your cyber insurer. Ask if they model concentration risk in your premium. If they do not, they will soon. Getting ahead of this conversation demonstrates maturity.

---

*This article is part of our supply chain risk series. Previous articles: Why Every Company Needs Vendor Risk Management, The Trivy Compromise, The Axios Attack.*

Sources and References

Ready to assess your NIS2 readiness?

Use our free self-assessment tool or speak with our compliance team.

Start NIS2 Assessment Contact Us