Your supplier list looks diversified. Your fourth parties are not. In November 2025 EU regulators published the first list of the shared providers most of finance depends on, and the same concentration is now forming under AI.
The 60-second version
Diversification is mostly on paper. Roughly two-thirds of the cloud infrastructure market sits with three companies, AWS, Microsoft Azure, and Google Cloud (Synergy Research, Q4 2025). When twenty of your vendors run on the same cloud, you do not have twenty independent suppliers. You have one dependency wearing twenty names.
Regulators have started treating it that way. Under the EU's Digital Operational Resilience Act (DORA), financial firms reported 3,383 major ICT incidents in 2025, and nearly 29% of them originated at a third-party provider. In November 2025 the European Supervisory Authorities named the first 19 Critical ICT Third-Party Providers, with AWS, Microsoft, Google Cloud, Oracle, and SAP among them, and put those firms under direct EU oversight.
Six vendors, three providers. A single provider outage takes down every vendor sitting on it.
Your program scores each vendor alone.
Third-party risk management rates one vendor at a time. Vendor A gets a SOC 2 review, a questionnaire, and a risk tier. So does Vendor B, and Vendor C. Each score stands on its own, and each looks fine.
The dependency underneath them does not stand on its own. When A, B, and C all run on the same cloud region, or all call the same foundation-model API, their risk is correlated. A per-vendor score cannot see that, because correlation lives between vendors, not inside any one of them.
Concentration risk is the diligence question almost no program answers: who does your vendor depend on, and how many of your other vendors depend on the same thing.
The failure is not hypotheticalOn October 20, 2025, a single AWS region (us-east-1) failed for more than 15 hours and took over 70 AWS services with it. Slack, Snapchat, Atlassian, and hundreds of other services that looked unrelated went dark together.
None of it is exotic. It is what happens when you assess suppliers one at a time.
Map the dependency, then manage the concentration.
DORA turned this from good practice into a filing. Every regulated financial entity now keeps a Register of Information: every ICT arrangement mapped, classified, and submitted annually in xBRL-CSV.
The penalties are real. Financial entities face fines up to 2% of total annual worldwide turnover, senior managers can be fined personally up to 1 million euros, and a designated provider can be charged up to 1% of its average daily worldwide turnover for each day of breach. You do not need to be a European bank for the logic to apply. Your model is a vendor and MCP is third-party risk; concentration is the layer above both.
Your diligence stops at the direct vendor. The provider that several of your vendors share never gets assessed.
You close it from two directions: build the picture, then act on it.
AMap the dependency
Build the picture your vendor scores cannot
1Require subservice disclosure
Every critical vendor names its cloud, its primary region, and its critical subprocessors. You cannot count what a vendor will not tell you.
Closes blind fourth party
2Build a fourth-party register
One list of the providers sitting behind your vendors. DORA's Register of Information is the working template, every arrangement classified and kept current.
Closes register gaps
3Tag the shared providers
Count how many vendors land on each one. The provider with the highest count is your real single point of failure, whatever your vendor scores say.
Closes correlated failure
4Add model-provider disclosure
Ask which foundation-model APIs power each AI feature, and record the answer like any other subprocessor.
Closes model-provider concentration
BManage the concentration
Act on the overlap once you can see it
1Set exposure thresholds
Decide how much of your critical stack is allowed to sit behind any one provider, and flag it when the count crosses the line.
Closes correlated failure
2Require exit and multi-region plans
For the providers you cannot realistically replace, hold the vendor to a documented failover and exit path.
Closes single-region outage
3Test a provider-outage scenario
Table-top the loss of your most-shared provider for a day. What breaks, and how many “separate” vendors break with it.
Closes unseen exposure
4Monitor designations and outages
Watch the CTPP list and provider status pages. A new designation or a repeat outage changes your exposure before your next review cycle does.
Closes blind fourth party
A long supplier list is not a resilient one. The question your scores skip is how many vendors fall together.
TPRM tools measure vendors in isolation, and isolation is the assumption concentration breaks. Regulators named the shared providers because the market would not, and the AI stack is concentrating along the same lines the cloud already did. Count the layer beneath your vendors before an outage counts it for you.
See how Zania runs third-party risk autonomously →
Sources
01ESAs designate the first Critical ICT Third-Party Providers under DORA, EIOPA (18 Nov 2025)
02ESAs publish first list of critical ICT third-party providers under DORA, PwC Legal
03Third parties cause a third of ICT failures, DORA report shows, Risk.net
04European banks report 3,383 major ICT incidents under DORA, FinanceFeeds
05DORA penalties and fines 2026, regulation-dora.eu
06AWS us-east-1 outage analysis, October 20, 2025, ThousandEyes
07AWS hit by US-East-1 outage after data center event, Network World
08Cloud infrastructure market share, Q4 2025 (Synergy Research)
Share
