Everyone's AI runs on the same few vendors. Regulators just named them.

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 hypothetical

On 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.

• Map the dependency - Build the picture your vendor scores cannot

  • Require 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

  • Build 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

  • Tag 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

  • Add model-provider disclosure: Ask which foundation-model APIs power each AI feature, and record the answer like any other subprocessor. Closes - Model Provider Concentration.

    
    

• Manage the concentration - Act on the overlap once you can see it

  • Set 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

  • Require exit and multi-region plans: Track the vendor’s posture between reports rather than waiting for next year’s refresh. The annual cadence is the floor, not the coverage. Closes - Single Region Outage

  • Test 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

  • Monitor 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:

• ESAs designate the first Critical ICT Third-Party Providers under DORA, EIOPA (18 Nov 2025)

• ESAs publish first list of critical ICT third-party providers under DORA, PwC Legal

• Third parties cause a third of ICT failures, DORA report shows, Risk.net

• European banks report 3,383 major ICT incidents under DORA, FinanceFeeds

• DORA penalties and fines 2026, regulation-dora.eu

• AWS us-east-1 outage analysis, October 20, 2025, ThousandEyes

• AWS hit by US-East-1 outage after data center event, Network World

• Cloud infrastructure market share, Q4 2025 (Synergy Research)