DORA Named The 19 Critical Providers. Now Every Bank Has To Explain Its Concentration Risk

By Micky Irons

For years, "we run it in the cloud" was an answer that ended the conversation. As of 18 November 2025, it starts one.

On that date the three European Supervisory Authorities, the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA) and the European Securities and Markets Authority (ESMA), published the first official list of Critical ICT Third-Party Providers under the Digital Operational Resilience Act (DORA). Nineteen firms were designated. Amazon Web Services, Microsoft Azure and Google Cloud sit near the top of it, alongside names such as Oracle, SAP, IBM and Deutsche Telekom.

This is not a think-tank ranking. It is a supervisory instrument. The moment those 19 names went onto a public register, the dependency that every European bank and insurer already carried became a documented fact that supervisors can now interrogate. I want to walk through what actually changed, because the practical consequence lands squarely on the desk of the Chief Risk Officer and the ICT third-party risk team.

What the list actually does

DORA has applied across all 27 EU member states since 17 January 2025. The critical-provider designation is a specific mechanism inside it. The ESAs assessed providers on systemic impact, degree of substitutability, cross-border footprint and how deeply interconnected they are with EU financial entities, then named the ones whose failure would ripple across the system. Those 19 firms now fall under direct oversight by a Lead Overseer: the EBA, ESMA or EIOPA depending on the sector they serve.

For the provider, that means annual risk assessments, reporting obligations, on-site inspections and the power to demand remediation. If a designated provider ignores the Lead Overseer, DORA allows periodic penalty payments of up to 1% of the provider's average daily worldwide turnover, charged every day for up to six months. For a hyperscaler, that is a genuinely large number per day.

But the fine on the provider is not the part that should keep a CRO awake. The part that matters is what the list does to the financial entity's own obligations.

Your register just became evidence

DORA already required financial entities to keep a Register of Information under Article 28(3): a structured record of every contractual arrangement with an ICT third-party provider, available to your competent authority on request. Through 2025 that register was, for many firms, a compliance artefact. In 2026 it has become an enforcement tool.

Here is the mechanism. Your national competent authority now holds the official list of 19 critical providers. It can cross-reference that list against the registers submitted by every bank and insurer in its jurisdiction. When it does, it can see, at a portfolio level, exactly how many regulated entities route their critical and important functions through the same handful of cloud platforms. That is concentration risk, and it is now visible from the supervisor's side of the desk, not just yours.

The follow-through is uncomfortable. If your register shows that a critical or important function depends on a designated provider with no genuine exit path, that is no longer a private risk you manage on your own timeline. It is a documented liability a supervisor can ask you to explain. DORA leaves the size of the fine to national law under Article 50, so the ceilings vary by member state: some cap penalties as a percentage of total annual worldwide turnover, others set absolute ceilings that run as high as EUR 20 million in states like Italy. Several national authorities have said plainly that in 2026 they will move past supervisory dialogue and use the full enforcement toolkit, with third-party risk under Article 28 named as a priority. The posture has visibly hardened.

The honest version of the concentration problem

I want to be precise here, because the market is full of overstatement. DORA does not bar you from the cloud. Almost no European regime does. The EU AI Act, DORA, the FCA and PRA rulebooks and GDPR all permit cloud use with the right controls. The genuine no-cloud line is drawn at the workload level: classified material, isolated operational technology, data protection assessments that come back negative. For most functions, cloud remains lawful.

So the pressure is not a legal wall. It is a documented, supervised preference problem. You are allowed to concentrate your critical functions on two or three hyperscalers. You now simply have to prove, on the record, that you have understood that concentration, stress-tested the failure of that provider, and hold a credible exit strategy. For a lot of AI and data workloads, "we would migrate to another hyperscaler" is not a credible exit, because the alternative is also on the list of 19. That is the trap the designation exposes.

Where sovereign infrastructure changes the math

This is the reason I built Mickai the way I did.

Mickai is a Sovereign Intelligence Operating System, a SIOS. It is not a service you rent from a hyperscaler. It is intelligence infrastructure that a regulated organisation owns and runs inside its own walls: on-premises, air-gapped where required, with a cryptographically-signed audit record on every action the system takes. It is built and live today, not a roadmap.

The point, in DORA terms, is what that does to your register. When a critical or important function runs on infrastructure you own and operate, the dependency on a designated critical provider for that function drops out of the concentration calculation. You are not registering yet another line that points at AWS or Azure. You are registering a function that stays inside your perimeter, with a signed audit trail that answers the resilience and traceability questions a Lead Overseer will ask, before they ask them.

That does not mean rip out the cloud. It means you get to choose which functions genuinely need to leave your walls and which never should. For the crown-jewel workloads, the models that touch customer data, the analytics that drive credit or claims decisions, the intelligence layer you cannot afford to have offline or opaque, keeping them sovereign turns a documented liability back into a controlled asset. Our work on sovereign AI for regulated financial institutions and on the audit trail regulators actually want both come straight out of this shift.

Mickai's approach here rests on a substantial patent position: 104 UK patent applications across 13 families, roughly 2,340 claims, filed by named inventor Mickarle Wagstaff-Irons and building toward examination. Those cover the sovereign runtime, the signed audit architecture and the model-governance layer that make this defensible rather than a slide.

The takeaway for a CRO

The 19-name list did not create your concentration risk. It made it legible, to your supervisor, on a public register, at exactly the moment enforcement turned serious. The question in your next DORA review will not be whether you use a critical provider. It will be whether you can explain the concentration, and whether your most important functions have anywhere else to go.

For the functions that can stay inside your perimeter, sovereign infrastructure is the cleanest answer to that question, because it removes the dependency instead of documenting it. That is the calculation I would be running this quarter.

Frequently asked questions

Does DORA ban banks from using AWS, Azure or Google Cloud?

No. DORA permits cloud use with appropriate controls. What changed on 18 November 2025 is that those providers are now formally designated critical, which means your dependency on them is documented and directly supervised. You have to show you understand the concentration and hold a credible exit strategy, not that you have stopped using them.

What are the fines involved?

Two separate regimes. A designated critical provider that ignores its Lead Overseer can face periodic penalty payments of up to 1% of its average daily worldwide turnover, for up to six months. For financial entities, DORA hands the penalty regime to national law under Article 50, so the amounts differ by member state, combining turnover-based percentages with absolute ceilings that reach as high as EUR 20 million in some countries.

How does the supervisor see my concentration risk?

Through your Register of Information under Article 28(3). Your national competent authority holds the official list of critical providers and can cross-reference it against the registers every regulated entity submits, making system-wide reliance on a few hyperscalers visible from their side.

How does running Mickai on-premises change my DORA position?

When a critical or important function runs on infrastructure you own and operate inside your own perimeter, that function no longer registers as a dependency on a designated critical provider. Mickai adds a cryptographically-signed audit record on every action, which directly answers the resilience and traceability questions a Lead Overseer asks. See our work on running critical AI inside your own perimeter.