What DORA Requires of Banks and Their Critical ICT Providers

A customer disputes a transaction they never authorized. The bank says it sent the security alert. The supervisor asks for the one thing that counts: prove it.

Here is where it breaks down. The bank’s audit trail stops the moment the message left its systems. After that, an aggregator, a carrier and a network it does not own took over. The bank knows it sent the alert. It cannot show that it landed.

Before January 2025, that was a complaints problem. Now that DORA in banking applies in full, across the European Union it is a supervisory one.

Regulation (EU) 2022/2554 on digital operational resilience rests on a premise that redraws the line between a bank and its technology suppliers: the bank is accountable to its supervisor for the resilience of its whole provider chain, even though it runs none of the links. The point is not better procurement. It is knowing, documenting and proving how that chain behaves when something breaks.

The first annual incident report, published by the European authorities on June 3, 2026 using 2025 data, shows where the risk actually sits. Of the 3,383 major incidents reported across the EU financial sector, only 10% were cyber-related. System failures and external events drove the rest, and roughly a third had cross-border impact. The authorities draw a blunt conclusion: banks need solid third-party risk management and tight coordination with providers while an incident is running.

This article covers what DORA asks of banks on ICT providers, what the critical provider designation of November 2025 actually changes, and why the layer that delivers OTP codes, fraud alerts and regulatory notices sits squarely inside that perimeter.

Why DORA in banking exists and what it requires

For years, financial regulation treated technology risk as a flavor of operational risk: something a bank held capital against. That approach was built to absorb losses, not to keep the lights on.

The sector, meanwhile, changed shape. Banks moved their systems to the cloud, outsourced processing and concentrated large parts of their operations in a handful of technology suppliers. One failure could now take out dozens of banks in several countries at once.

DORA in banking began as a Commission proposal on September 24, 2020, part of the EU’s digital finance package. It set out to do two things: apply one set of digital resilience requirements across the whole EU financial sector, and push supervision beyond the bank’s own walls, out to the providers it leans on. Resilience stops being about what a bank controls, and becomes about what it can sustain and prove when something outside its control gives way.

It has applied in full since January 17, 2025, with no phase-in, and rests on five pillars: ICT risk governance and management, incident management, digital resilience testing, ICT third-party risk, and threat information sharing.

What DORA requires of banks on their ICT providers

The fourth pillar — Articles 28 to 44 — is the one that lands on a technology team’s desk. It adds no technical requirement for the provider. It puts the burden on the bank to know its own chain and be able to evidence it.

Three questions, answerable at any time and in writing, for every service the bank buys: who supplies it, on what terms, and what happens if they stop.

Concretely, the bank has to:

• Keep a register of information covering every ICT contract, flagged for which ones support critical or important functions. National authorities collect it and pass it up to the European authorities. It repeats every year.
• Write the Article 30 minimum clauses into contracts: service description, measurable service levels, access and audit rights, incident notification, subcontracting terms, data location, notice periods and termination.
• Document an exit strategy for every provider behind a critical or important function.
• Assess concentration risk — what happens when everything runs through one provider, or one technical route.
• Keep monitoring after signature, not just during procurement.

A bank can outsource the work. It cannot outsource the answer it owes its supervisor.

What a critical ICT provider is, and what designation changes

An ICT provider is any outside company supplying the bank with technology: whoever hosts its systems, supplies its fraud software, runs its alerting engine or provides its connectivity. This is not a footnote in the operating model. Estimates drawn from the EBA’s outsourcing registers suggest more than 60% of critical functions at large European banks run on external ICT providers.

DORA calls them “ICT third-party service providers” and splits them into two groups with very different consequences.

Who counts as a critical provider

Critical providers — CTPPs, or Critical Third-Party Providers — are designated under Article 31 by the European Supervisory Authorities: the EBA for banking, EIOPA for insurance and pensions, ESMA for securities markets.

Three criteria decide it:

• Systemic importance of the provider
• Support of essential functions — the ones a bank cannot operate without
• Substitutability — how easily another provider could step in

On November 18, 2025, the three authorities published the first list: 19 companies. None of them sells to banks alone. They are the infrastructure the sector runs on — cloud platforms, data centers, market data providers and large technology services firms.

The list was not assembled from scratch. It came out of the registers of information banks had already filed with their supervisors. Banks named who they depend on, and that exercise drew the map of where the sector is concentrated.

Designation puts the provider under direct European oversight, with a Lead Overseer assigned to it.

What about providers not on the list

This is where banks most often get it wrong. Missing from the critical list does not mean outside DORA. It means the bank answers for that provider, not Brussels. If the service supports a critical or important function, the provider still goes into the register of information, still needs the Article 30 clauses, still needs an exit strategy.

The reverse holds too. A designated provider does not take weight off the bank. European oversight is added to the bank’s obligations, not substituted for them.

That is where most specialist providers in the sector sit. Critical communications providers among them.

Which banking alerts fall inside DORA’s perimeter

Every bank decides for itself which functions count as critical or important, based on its business impact analysis. You do not settle that by message type. You settle it by asking what breaks when the message never lands. An OTP code decides whether a transaction closes. A fraud alert decides how much time the customer has to react. A regulatory notice decides where the bank stands in a dispute.

When the answer is that operations stop or compliance slips, the function is critical — and DORA in banking puts three requirements on whoever supports it.

• Continuity you can demonstrate. An availability commitment is not enough. The bank needs to know what happens when a channel provider goes down: whether alternative routes, load balancing and failover exist, how fast they kick in, and how they are tested. Latinia’s guide on operational resilience and service continuity covers the three mechanisms behind that.
• Traceability that survives an audit. Article 30 requires access, inspection and audit rights. For communications, that means reconstructing what was sent, when, through which channel, and what came back.
• Transparency down the subcontracting chain. A banking communications provider sits on top of SMS aggregators, push providers, carriers and messaging platforms. That chain has to be known and contractually governed, not a black box starting where the main contract ends — as set out in Latinia and Channel Providers: A Guide to Governance and Resilience in Critical Notifications.

Then there is incident coordination, where the clock is unforgiving. Initial notification within four hours of classifying the incident as major, and no later than twenty-four hours from detection. Intermediate report within seventy-two hours of that notification. Final report no later than a month after the intermediate one. No bank hits those deadlines if its provider needs days to confirm what happened at its end.

That gap between sending and governing is what separates messaging infrastructure from a governance layer over banking communications: deciding what goes out and at what priority through a real-time decision engine, holding delivery together when a provider drops, watching the process, and keeping evidence of every notification. DORA did not invent that requirement. It made it supervisable.

What this means in Spain and Latin America

In Spain, supervision falls to the Banco de España, the securities regulator CNMV and the insurance and pensions regulator DGSFP, depending on the institution. The obligation that eats the most time is also the quietest one: once a year, the bank hands its supervisor a full inventory of its technology providers.

Nobody files that inventory away. National authorities consolidate it and send it to the European authorities every March 31 — and that cross-check is exactly what produced the critical provider list. A badly declared field is not a reporting slip. It is a statement about who the bank depends on.

DORA binds financial institutions in the European Union, but the effect does not stop at the border. In Latin America it arrives three ways:

• European groups push their ICT contracting standards down to regional subsidiaries
• Latin American institutions with EU operations are in scope through that activity
• The framework hardens into a market reference in provider selection well before it becomes law

Same dynamic we looked at in the evolving regulation of financial communications: the standard shows up in the RFP long before it shows up in the statute book.

Three decisions worth making now

On that basis, the useful question for a CIO, a CTO or a head of compliance is not whether the bank complies with DORA. It is whether the bank can prove it, across the chain.

1. Check how the communications layer is declared in the register of information. Does it show up as supporting a critical or important function? Are the underlying channel providers declared?
2. Hold current contracts up against Article 30. Audit rights above all, plus notification deadlines that work with a four-hour window, and an exit strategy on paper.
3. Test the evidence, not the send. Pull one specific communication as if an auditor had asked for it. If that means stitching together records from three systems, the problem is architectural.

Digital operational resilience is not a cybersecurity project. It is a decision about how the infrastructure is built, and about what the bank can put in front of a supervisor when something fails. Within that architecture, critical communications are not the last piece to get wired in.

Latinia has spent more than 25 years working with banks across Europe and Latin America on their critical communications. You can see how that works in practice in our use case on how to comply with banking regulations and in our security and regulatory compliance solution.

Want to see how your communications layer holds up against DORA?

Let’s talk.

FAQs

What is the DORA Regulation and when did it start to apply?

DORA is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. It has applied in full since January 17, 2025, with no phase-in period, and takes direct effect in all twenty-seven Member States. It rests on five pillars: ICT risk management, incident management, resilience testing, third-party risk and information sharing.

What is a critical ICT provider, or CTPP, under DORA?

A CTPP is an ICT third-party service provider designated as critical by the European Supervisory Authorities under Article 31 of DORA. Designation turns on the provider’s systemic importance, its role in supporting critical functions, and how easily it could be replaced. The first list, published on November 18, 2025, names 19 providers.

Does designating a provider as critical reduce the bank’s obligations?

No. It opens European oversight over the provider, but moves none of the bank’s obligations. The bank still answers to its supervisor for its entire ICT provider chain, designated or not.

What must an ICT provider contract include under Article 30 of DORA?

A full service description, measurable service levels, data location, availability and integrity obligations, subcontracting terms, access and inspection rights, assistance during ICT incidents, notice periods and grounds for termination. Where the service supports a critical or important function, a documented exit strategy is required as well.

What are the reporting deadlines for a major ICT incident under DORA?

Three windows. Initial notification within four hours of classifying the incident as major, and no later than twenty-four hours from detection. Intermediate report within seventy-two hours of that initial notification. Final report no later than one month after the intermediate report.

What does DORA require of a banking alerts and notifications provider?

If the bank treats critical communications as supporting a critical or important function, the provider goes into its register of information and falls under the Article 30 clauses. In practice: continuity when a channel fails, auditable traceability for every send, transparency over subcontracting, and response times that fit the bank’s own deadlines.

Does DORA affect banks in Latin America?

Not directly — it binds financial institutions in the European Union. The effect reaches the region three ways: European groups push their standards down to local subsidiaries, Latin American institutions with EU operations are in scope, and the framework is settling in as a reference point in provider selection.