What DORA Requires of ICT Third-Party Providers, Article by Article

Regulation (EU) 2022/2554 — the Digital Operational Resilience Act (DORA) — applied from 17 January 2025. Unlike most cybersecurity frameworks, DORA is not a directive requiring national transposition: it is a regulation with direct effect across all EU Member States. For covered financial entities and their ICT third-party service providers, the regulation text is the operative rule, without any intermediation by national legislators.

This article analyses the obligations DORA imposes specifically on the management of ICT third-party service providers: the Register of Information, the contractual minimums, the exit strategy requirements and the critical provider oversight framework. It is not a summary of the full regulation — which also covers internal risk management, incident reporting and resilience testing — but a focused analysis of the articles that directly govern how financial entities must structure their relationships with technology vendors.

Article 28: the Register of Information as a structural obligation

Article 28 of DORA requires financial entities — banks, insurers, asset managers, investment firms, crowdfunding platforms, and a substantial list of others — to maintain an up-to-date Register of Information covering all contractual arrangements with ICT third-party service providers. This is not a contact list or a licence inventory: it is a structured register that must document precise, verifiable information about each relationship.

Implementing Regulation (EU) 2024/2956, published on 29 November 2024 and in force from 19 December of that year, establishes the standardised templates entities must use. There are twelve templates — labelled B_01.01 through B_07.01 — covering everything from the identification of the entity responsible for maintaining the register to the ICT risk assessment for each individual contract. The templates most directly relevant to third-party management are:

B_02.01 and B_02.02, which capture general and specific contractual arrangements. B_03.01 and B_03.02, which identify the contracting parties on both the entity and the provider side. B_05.01 and B_05.02, which map provider identities and their supply chains. B_07.01, which documents the ICT risk assessment associated with each contract.

Legal entity identifiers are a critical element. For providers established within the EU, use of the Legal Entity Identifier (LEI) or EUID as a unique identifier is mandatory. For providers in third countries, only the LEI applies. Each contract must carry a unique and permanent reference number, and providers occupying different positions in the supply chain must be identified accordingly: position 1 for a direct provider, position 2 or higher for sub-contractors.

Article 28(3) requires entities to report the Register of Information periodically to their competent authorities. The deadline for the first submission was set for April 2025. In Spain, the relevant competent authorities are the Bank of Spain (Banco de España), Spain's securities markets regulator (Comisión Nacional del Mercado de Valores, CNMV), and the Directorate-General of Insurance and Pension Funds (DGSFP), depending on the type of entity. The three European Supervisory Authorities — EBA, EIOPA and ESMA — coordinated the submission processes with their respective national counterparts.

Article 30: the contractual minimums that are non-negotiable

Article 30 of DORA sets out the content requirements for contracts with ICT third-party service providers. The structure is clear: there is a baseline set of requirements that applies to all contracts, and a reinforced set that applies where the service underpins essential or important functions of the entity.

For all contracts, Article 30(2) requires at minimum: a clear and comprehensive description of all services provided; an indication of the locations from which services are delivered, including where data is stored and processed; security provisions that the provider and its sub-contractors must meet; obligations on the provider to assist the entity in the event of an ICT incident; full cooperation with competent authorities in their inspections; and clearly defined termination rights.

Where the service underpins essential or important functions, Article 30(3) adds a second, considerably more detailed tier of requirements:

Service levels must be defined with both quantitative and qualitative objectives — response times, availability targets, error rates. Audit rights cannot be restricted: the contract must recognise the entity's right to conduct audits directly or through designated third parties, including access to physical premises and to the provider's technical documentation. Participation in threat-led penetration testing (TLPT) must be contractually guaranteed when required by supervisory authorities. The exit strategy must be documented within the contract itself, with explicit commitments from the provider to cooperate during the transition period.

Delegated Regulation (EU) 2024/1773, published in April 2024, supplements Article 30 by specifying the detailed content of the internal policy that entities must maintain regarding their contractual arrangements for ICT services underpinning essential or important functions. That policy must define, among other things, the criteria for determining which functions are essential or important, the internal approval processes for new contracts, and the change management procedures when a provider modifies its sub-contracting arrangements.

The exit strategy: planning the separation before signing

One of the elements most consistently underestimated by legal and procurement teams is the exit strategy that DORA requires for services supporting essential or important functions. Article 28(8) is explicit: entities must have documented exit strategies that ensure service continuity during the transition and minimise the risk of losing critical functionality.

This is not a contractual penalty clause for non-performance. It is an operational plan that must cover how a service will be transferred to another provider or brought back in-house; what realistic timeframes that transition requires; what cooperation obligations apply to the exiting provider, including data portability, technical documentation handover and support during the transition period; and what internal capabilities the entity needs to execute the transition.

The practical rationale for this requirement is to prevent lock-in situations that compromise operational resilience. An ICT provider from which it is impossible to disengage within a reasonable timeframe is, by definition, a concentration risk — and limiting that risk is one of DORA's explicit objectives. Supervisory authorities use the Register of Information to identify systemic concentrations: if a significant proportion of financial entities depend on a single ICT provider for critical functions, that represents a risk to the stability of the financial system as a whole, not merely to each individual entity.

Article 31: the oversight of critical ICT third-party providers

Article 31 establishes a differentiated regime for Critical ICT Third-Party Providers (CTPPs). These providers are designated by the European Supervisory Authorities through a process defined in the regulation itself, and once designated they are subject to direct oversight by EU-level authorities — not merely to the contractual obligations that individual entities choose to impose on them.

The ESAs published the first list of CTPPs on 18 November 2025: 19 providers, including the major cloud computing providers and other ICT service providers with systemic presence in the European financial sector. Designation carries immediate consequences for the designated provider: if it is not established in the EU, it must set up a subsidiary in the Union within twelve months (Art. 31(12)); it must cooperate with the Joint Oversight Network (JON) — composed of the ESAs and the relevant national competent authorities — and it is subject to direct inspections.

For financial entities, contracting with a CTPP does not remove their own risk management obligations. The regulation is unambiguous: public oversight of a critical provider does not substitute for the assessment and monitoring the entity must conduct on its own account. What changes is that entities may benefit from the information the ESAs gather through their inspections of CTPPs, which in practice facilitates the internal assessment process.

The sub-contracting dimension: obligations in cascade

DORA does not ignore the fact that ICT providers sub-contract. Article 30(2)(a) requires the contract to state whether sub-contracting of services underpinning essential or important functions is permitted and under which conditions. Delegated Regulation (EU) 2025/532 develops this: the provider must give advance notice of any material change to its sub-contracting, and the entity can object before it takes effect. Furthermore, the same security standards and audit rights that apply to the primary contract must be passed down contractually to the sub-contractor.

This creates what is commonly described as a cascade of obligations: the entity requires the direct provider to meet certain standards; the direct provider must impose equivalent standards on its sub-contractors; and the entity must have visibility across that chain. The Register of Information under Article 28 must reflect the sub-contractors supporting essential or important functions, identifying their position in the supply chain.

For contract management teams, this means that due diligence on an ICT provider cannot be confined to analysing that provider in isolation. It is necessary to understand which sub-contractors the provider uses, which functions it delegates to them, and what controls it has over that chain. A provider with strong internal security practices that itself depends on a sub-contractor without adequate controls represents a risk that the DORA Register is precisely designed to surface.

What DORA changed in the vendor relationship

DORA's entry into force shifted the balance of power in negotiations between financial entities and ICT vendors. Before January 2025, large cloud providers and enterprise software vendors could offer standard contractual terms that excluded audit rights, limited information about sub-contractors, and imposed generic service terms. Under DORA, those clauses are incompatible with the regulatory obligations of in-scope financial entities.

In practice, ICT providers that want to work with the European financial sector must adapt their contracts to Article 30's requirements. Those that have done so — delivering the information needed for the Register in an orderly way, acknowledging audit rights, and maintaining documented incident management processes — have a genuine competitive advantage over those still offering standard terms designed for a different context.

For financial entities, the most immediate implication is the need to review the existing ICT contract portfolio. Contracts signed before January 2025 that do not cover Article 30's requirements must be renegotiated. The window for that renegotiation is not open-ended: national supervisory authorities — including the Bank of Spain and the CNMV — are active, and the first round of DORA supervisory activity is already under way. A register that reveals systemic contractual gaps is not a theoretical problem; it is the starting point for a supervisory conversation that no compliance team wants to initiate from a position of admitted non-compliance.