Short answer. ICT third-party risk under DORA is the risk that a financial firm’s reliance on outside technology suppliers, cloud platforms, software vendors, and external AI model providers weakens its ability to keep running. DORA devotes 17 articles, numbers 28 to 44, to controlling it. Since 17 January 2025 every EU bank, insurer, and investment firm must map these dependencies, secure specific contract terms, and record each arrangement in a register. In November 2025 regulators named the first 19 providers judged critical enough for direct EU-level oversight.
Most financial firms no longer run their own technology end to end. They rent it. Core banking sits on a vendor platform, payments route through a processor, data lives in a public cloud, and customer service now leans on an external AI model. DORA treats each of those suppliers as an ICT third party, and it makes the financial entity, not the vendor, accountable for the resilience of the whole chain.
Pillar four of DORA, ICT third-party risk management, carries the heaviest operational load of the regulation. Over 60% of critical financial-sector functions already depend on outside ICT providers, so the surface area is large. In practice, compliance means four concrete activities:
The point is not paperwork. A cloud outage or a compromised software update at one supplier can freeze payments for millions of customers, and the regulator now holds the bank answerable for that dependency.
DORA became applicable on 17 January 2025 and applies directly across all 27 member states, so a bank in Bratislava, Prague, or Vienna works to the same text as one in Frankfurt. There is no national transposition to soften it. For CEE financial firms that have spent a decade moving core systems to AWS, Microsoft Azure, and Google Cloud, this reframes an ordinary vendor relationship as a supervised risk.
The regulator’s concern is concentration. When most of a market runs on the same handful of platforms, a single failure becomes systemic. Regulators have flagged that more than 65% of EU financial entities use at least two of AWS, Azure, and Google Cloud for critical functions. DORA answers that with a direct oversight layer, and firms that fall short face supervisory penalties on top of the resilience gap itself. As of early 2026, only around half of in-scope institutions were assessed as fully compliant.
ICT third-party risk is DORA pillar four, Articles 28 to 44, and it makes the financial firm accountable for its whole supplier chain.
DORA scales its demands by importance, so the first task is classification. A function is critical or important when a disruption to it would materially impair the firm’s financial performance, the soundness or continuity of its services, or its ability to meet the conditions of its authorization. Core banking, payment processing, trading, and claims handling almost always qualify. A marketing analytics tool usually does not.
This matters because the strictest contractual and exit requirements apply only to third parties supporting critical or important functions. Misclassifying a supplier as non-critical to avoid the obligations is one of the first things a supervisor checks, and national authorities are now cross-referencing registers against incident histories to find gaps.
Article 28(3) requires every in-scope firm to keep a complete, current register of all contractual arrangements with ICT service providers. It is not a spreadsheet of logos. It records the function each provider supports, whether that function is critical, the location of data and processing, and the chain of subcontractors behind the headline vendor. Article 28(9) requires firms to submit the register to their competent authority once a year and on request at any time.
The register does double duty. Internally it is the map a firm uses to see its own concentration. Externally it is the dataset the European Supervisory Authorities used to decide which providers were critical enough to oversee directly, which is why accuracy is not optional.
DORA created an EU-level oversight framework for the providers that carry systemic weight. The European Supervisory Authorities, the EBA, EIOPA, and ESMA, designate Critical ICT Third-Party Providers and appoint a Lead Overseer for each. On 18 November 2025 the Authorities published the first list: 19 providers, including AWS EMEA, Microsoft Ireland, Google Cloud EMEA, IBM, Oracle, SAP, and several data and connectivity firms.
Designation follows an assessment of systemic impact, substitutability, cross-border footprint, and interconnectedness. A Lead Overseer can examine a critical provider, issue recommendations, and impose a periodic penalty payment of up to 1% of the provider’s average daily worldwide turnover until it complies. The oversight sits on the provider, but the financial entity keeps its own duty to manage the relationship.
Yes. When a bank calls an external large language model to summarize documents or triage service requests, that model provider is an ICT third party under DORA, and if the function it supports is critical or important, the full weight of pillar four applies. This is where DORA and AI governance meet. A firm that adopts a general-purpose AI model inherits a dependency it does not control: the provider’s uptime, its data location, its own subcontractors, and its model changes.
The practical consequence is that an AI pilot cannot graduate to a production decision path without a register entry, DORA-grade contract terms, and an exit plan for the day the model is withdrawn or repriced. Treating an AI vendor as an ordinary software licence, rather than a supervised ICT dependency, is a compliance gap waiting to surface in an audit.
Start with the map, not the contracts. A firm cannot manage what it has not listed, so the first move is a complete inventory of ICT providers and the functions each one supports, including the AI services that entered quietly through individual teams. From there, classify which functions are critical or important, then concentrate contract remediation and exit planning on that subset. Firms that sequence it this way close the highest-risk gaps first and avoid rewriting hundreds of low-stakes contracts at once.
Ableneo builds AI into regulated organizations where the technology has to be observable, accountable, and shipped to production, not parked in a pilot. In 2025 the team delivered 34 production AI projects across Slovakia, Czechia, Austria, and the US, 94% of them using large language models, in the same banking and insurance environments DORA governs. That work makes one thing clear: an external AI model is a supervised dependency, and it belongs in the register and the resilience plan from day one, not after go-live. Our approach to AI transformation for regulated industries treats governance as part of the build, so the system that reaches production is the same system a supervisor can inspect.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.