A practical guide to the Digital Operational Resilience Act — covering what DORA is, which technology services it covers, how financial entities classify their suppliers, and what the mandatory contract terms under Article 30 require of ICT service providers.

DORA is live. Regulation (EU) 2022/2554 and the accompanying Implementing Technical Standards (ITS) on registers of information (Commission Implementing Regulation 2024/2956) both became applicable on 17 January 2025. In November 2025, the European Supervisory Authorities published the first list of 19 Critical Third-Party Providers subject to direct regulatory oversight. Compliance obligations are being actively enforced.

Contents

1. Why DORA Matters Beyond the Banks
2. What Is DORA? An Overview
3. What Is an ICT Service Under DORA?
4. Critical or Important? How the Designation Works
5. Contracting Implications Under Article 30
6. The Critical Third-Party Provider List
7. What SMBs and Software Vendors Should Do Now
8. Key Legal References

I. Why DORA Matters Beyond the Banks

The EU’s Digital Operational Resilience Act is widely understood as a financial services regulation — and it is. But its practical reach extends far beyond the banks, insurers, and investment firms that are its primary regulated subjects. DORA creates a set of mandatory, non-negotiable contract obligations that every EU financial entity must impose on its technology suppliers. If you develop and sell software, provide cloud services, run managed infrastructure, deliver IT consulting, or license on-premises applications to EU financial institutions, DORA shapes the commercial relationship you will be asked to enter — regardless of where your company is headquartered and regardless of whether you are yourself a regulated entity.

This is DORA’s key supply-chain mechanism: the regulation does not directly supervise most technology companies. Instead, it legally requires their customers — the regulated financial entities — to include specific terms in their supplier contracts. Those terms flow downstream as a matter of commercial necessity. A software vendor that refuses to accept them effectively prevents its financial entity customer from complying with EU law. The result is that DORA compliance is not just the bank’s problem; it is a commercial and operational reality for every technology vendor with a client base that includes EU-regulated financial institutions.

This page is written for two audiences. The first is small and medium-sized financial entities — community banks, payment institutions, investment advisers, insurance intermediaries, and others — that need to understand what DORA requires of them as they manage their technology supplier relationships. The second is the growing population of software vendors, SaaS companies, cloud providers, managed service providers, and technology consultancies that supply services to those institutions and need to understand how DORA will affect the terms they are asked to accept, the audits they may be required to support, and the operational changes they may need to make.

II. What Is DORA? An Overview

The Regulation and Its Purpose

DORA — Regulation (EU) 2022/2554 on digital operational resilience for the financial sector — was adopted on 14 December 2022 and became applicable across all EU Member States on 17 January 2025. As a directly applicable EU Regulation, it does not need to be transposed into national law: it takes effect uniformly in every Member State simultaneously. The accompanying Commission Implementing Regulation 2024/2956, which establishes standard templates for the register of information (commonly referred to as the ITS), was published on 2 December 2024 and applies from the same date.

The regulation was designed to address a structural vulnerability in the EU financial system: the deep and growing dependence of financial institutions on third-party technology providers. Large-scale ICT outages — whether at a hyperscale cloud provider, a payment processing platform, or a specialist financial technology vendor — have repeatedly demonstrated their capacity to simultaneously disrupt dozens or hundreds of financial institutions, creating systemic risk that existing regulatory frameworks were not designed to manage. DORA’s objective is to ensure that EU financial entities can withstand, adapt to, respond to, and recover from all ICT-related disruptions, whether those disruptions originate within the institution or at a third-party supplier.

The Five Pillars

DORA organises its requirements around five pillars. The first is ICT risk management: financial entities must establish a comprehensive internal framework for identifying, classifying, and managing ICT risks. The second is ICT incident reporting: major ICT-related incidents must be classified, reported to supervisory authorities, and communicated to affected customers according to prescribed timelines and templates. The third pillar is digital operational resilience testing, which includes regular testing of ICT systems and, for significant financial entities, Threat-Led Penetration Testing (TLPT) — structured red-team exercises that simulate realistic cyberattacks. The fourth pillar — and the one most directly relevant to technology vendors — governs ICT third-party risk management, covering how financial entities identify, assess, contract with, monitor, and exit their technology supplier relationships. The fifth pillar provides a framework for voluntary information sharing of cyber threat intelligence between financial entities.

Who Is a “Financial Entity” Under DORA?

The population of financial entities subject to DORA is broad. It includes credit institutions (banks), investment firms, payment institutions, electronic money institutions, crypto-asset service providers, insurance and reinsurance undertakings and their intermediaries, central counterparties, trading repositories, fund managers, crowdfunding service providers, data reporting service providers, central securities depositories, and a range of other regulated financial market participants. For technology vendors, the practical implication is significant: DORA’s footprint covers almost every type of regulated financial institution in the EU, which means that the market for financial services technology is, in its entirety, a DORA-covered market.

DORA does provide for proportionality: the obligations apply differently depending on the size, scale, and risk profile of the financial entity. Microenterprises — defined under EU law as entities with fewer than 10 employees and annual turnover or balance sheet total not exceeding €2 million — benefit from certain simplified obligations, including a specific derogation in the audit rights provisions of Article 30 that is discussed in detail below. Smaller and non-complex entities are also subject to a simplified ICT risk management framework. However, the core contracting obligations under Article 30 apply to financial entities of all sizes.

How DORA Reaches Technology Vendors

The mechanism by which DORA binds technology suppliers is indirect but powerful. DORA does not make most ICT vendors directly supervised entities. Instead, it requires financial entities to include specific, mandatory contractual terms in every ICT service agreement. The financial entity has no discretion about whether to include them — they are legally required. This means that when a financial institution approaches a software vendor, cloud provider, or IT consultancy to negotiate or renegotiate a contract, the DORA-required terms are non-negotiable from the financial entity’s side. Vendors that decline to accept them prevent their customers from complying with EU law. Understanding what those terms require — and preparing commercially and operationally to accept them — is therefore a business-critical exercise for any vendor serving the EU financial sector.

III. What Is an ICT Service Under DORA?

The Statutory Definition — Broader Than It Looks

DORA defines ICT services in Article 3(21) as “digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis, including hardware as a service and hardware services which includes the provision of technical support via software or firmware updates by the hardware provider, excluding traditional analogue telephone services.” Recital 35 adds an important interpretive instruction: the definition “should be understood broadly.” The intent is clear — the regulation is meant to capture the full range of technology services on which financial institutions depend, not merely a narrow subset of cloud or software services.

The key elements of the definition are worth unpacking. The service must be digital or data-based; it must be delivered through ICT systems; it must be provided on an ongoing basis (not a one-off transaction); and it must be provided to internal or external users. The “ongoing basis” element is sometimes overlooked: a single software implementation project that concludes upon delivery might arguably fall outside the definition, while a continuing maintenance, support, or licensing arrangement for the same software would fall squarely within it.

The ITS Extends the Scope Further

Whatever uncertainty existed about the scope of DORA’s statutory definition, the December 2024 Implementing Technical Standards on registers of information resolved it decisively — in the direction of breadth. The ITS Annex III establishes a taxonomy of ICT service categories that financial entities must use when populating their registers of information, and that taxonomy includes a number of services that would not intuitively be considered “digital services” under the statutory definition alone. The final wording of the ITS essentially adopts the expansive interpretation previously advocated by the European Banking Authority, going further than many practitioners anticipated when DORA was first published.

The recognised ICT service categories under ITS Annex III span the full technology stack. At the infrastructure layer, they include Infrastructure-as-a-Service (IaaS), data center hosting facilities, network infrastructure, digital processing capabilities, data storage platforms, and telecommunications systems. At the platform and application layer, they include Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS), as well as the licensing of software run on premises. For services that support software delivery, the ITS includes ICT development — encompassing business analysis, software design and development, and testing — and ICT project management. For operational and advisory services, the list extends to ICT operation management (infrastructure configuration, maintenance, capacity management, and business continuity management), data provider and data analysis services, and — perhaps most notably — ICT consulting, which expressly includes intellectual property and ICT expertise services.

Important for vendors who thought they were outside DORA’s scope: The ITS’s inclusion of ICT project management, on-premises software licensing, and intellectual property consulting as recognised ICT service categories is significant. These are not “digital services” in the conventional sense, yet they are classified as ICT services under the final ITS. A consultancy providing ICT architecture advice, a company licensing on-premises enterprise software on an annual basis, or a project management firm managing a technology implementation for a financial institution — all are providing “ICT services” under this framework and their financial entity customers are required to treat those arrangements accordingly.

What Is Excluded

Traditional analogue telephone services are expressly excluded from the definition of ICT services and fall entirely outside DORA’s scope. Beyond that, the exclusions are narrow. ICT services provided by intra-group providers — where both the provider and the recipient belong to the same corporate group — are subject to a lighter DORA regime and are excluded from the Critical Third-Party Provider designation process discussed below, though they remain within the broader ICT third-party risk management framework. Financial entities providing ICT services to other financial entities are also excluded from the CTPP designation process.

The Register of Information Obligation

Every financial entity subject to DORA must maintain an ongoing, updated register of all contractual arrangements with ICT third-party service providers. (DORA Article 28) This register must be structured in accordance with the templates set out in the ITS and must be made available to the financial entity’s supervisory authority on request. For vendors, the register obligation has a practical consequence: financial entity customers will need specific information about each ICT service arrangement to populate the register correctly — descriptions of services, data processing locations, subcontracting arrangements, and more. Vendors should expect to be asked to provide this information and should be prepared to do so accurately and promptly.

IV. Critical or Important? How the Designation Works

Two Distinct Concepts That Must Be Kept Separate

DORA uses the phrase “critical or important” in two entirely different contexts, and confusing them is one of the most common errors in DORA compliance work. The first is the financial entity’s own internal assessment of whether a particular ICT service it uses supports a “critical or important function.” This is a routine internal risk classification exercise that every regulated financial entity must carry out for its entire ICT supplier portfolio. It is what triggers the enhanced Article 30(3) contract requirements described in the next section. The second is the designation by the European Supervisory Authorities of a small number of very large, systemically important technology providers as “Critical Third-Party Providers” — a formal, EU-level regulatory designation that carries its own oversight framework and that, so far, applies to only 19 providers globally.

For the overwhelming majority of SMBs and software vendors, the first concept — the financial entity’s internal classification — is what governs day-to-day commercial relationships. The ESA-level CTPP designation is relevant primarily to hyperscale cloud providers, major data centre operators, and a small number of financial services-specific technology firms of genuine systemic scale. Understanding which concept applies to your situation is the essential starting point for any DORA compliance analysis.

What Is a “Critical or Important Function”?

DORA Article 3(22) defines a critical or important function as one “whose disrupted, defective or failed performance would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or its other obligations under applicable financial services law, or the financial soundness, or the continuity or quality of its services and activities, or the continued provision of financial activities and services.” In practical terms, the question a financial entity must ask is: if this service were to fail or be significantly disrupted, would that failure cause us to breach our regulatory obligations, suffer material financial harm, or be unable to serve our customers?

Functions that will almost invariably be classified as critical or important include core banking systems, payment processing platforms, trading and order management systems, portfolio management software, insurance underwriting and claims management platforms, customer-facing digital banking channels, regulatory reporting systems, and business continuity infrastructure. Functions that are less likely to qualify are purely ancillary administrative tools with readily available substitutes, generic office productivity software that does not touch regulated processes, and services whose failure would have no direct bearing on the financial entity’s regulated activity or its ability to meet its supervisory obligations.

How a Financial Entity Makes the Assessment

The designation is an internal risk assessment that the financial entity must carry out deliberately and document. The key factors to consider are the extent to which a disruption or failure of the function would impair the entity’s compliance with regulatory requirements or the quality of its services to customers; the degree to which the function is substitutable — is there a readily available alternative provider that could be engaged without significant delay, cost, or operational risk; the financial materiality of the function to the institution; and the interdependency between the function and other critical systems. Where a financial entity is in doubt about whether a function meets the threshold, the conservative approach — treating it as critical or important — is appropriate, given that the consequence of under-classification is failure to comply with the enhanced Article 30(3) contract requirements.

The ESA-Level Critical Third-Party Provider Designation (Article 31)

The ESA-level CTPP designation is a separate regulatory process conducted by the European Supervisory Authorities — the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA), and the European Securities and Markets Authority (ESMA) — acting through their Joint Committee. The designation is based on four criteria set out in Article 31(2), each of which must be considered in the assessment. The first criterion is systemic impact: what would happen to the stability, continuity, or quality of financial services across the EU if the provider were to suffer a large-scale operational failure, having regard to the number and total value of assets of the financial entities it serves? The second is the systemic importance of the financial entities that rely on the provider, assessed by reference to the number of globally or other systemically important institutions (G-SIIs and O-SIIs) that depend on the provider and the interdependencies between those institutions and others. The third is the concentration of reliance — how many financial entities depend on this provider for critical or important functions, including through subcontracting chains where the provider’s services are consumed indirectly? The fourth is substitutability: are there real alternatives in the market, or does the provider’s market position, proprietary technology, or the practical difficulty of migration mean that financial entities have no genuine alternative?

The ESAs published the first list of 19 CTPPs on 18 November 2025. The list includes hyperscale cloud providers, data centre operators, infrastructure and network providers, and financial services-specific technology companies. The designations were based on data collected from the registers of information submitted by financial entities to their national supervisors, which identified which third-party ICT providers support critical or important functions. Providers assessed as potentially meeting the criteria were formally notified and had a right to respond by submitting a reasoned statement before the final designation decision was taken. The list will be updated and published by the ESAs on an annual basis.

Several important carve-outs from CTPP designation exist under Article 31(8). The designation does not apply to financial entities providing ICT services to other financial entities; to ICT third-party service providers already subject to oversight frameworks established under Article 127(2) of the Treaty on the Functioning of the European Union (covering central bank-related oversight); to ICT intra-group service providers; or to providers that supply ICT services solely in one Member State to financial entities that are active only in that same Member State. Where a provider belongs to a corporate group, the designation criteria are assessed across the group as a whole. A provider designated as critical that is established in a third country — outside the EU — must establish an EU subsidiary as its coordination point within 12 months of designation.

Concept 1 — Routine Compliance

Financial Entity’s Internal Classification

The financial entity assesses whether each ICT service supports a “critical or important function.” Applies to every regulated entity. Triggers enhanced Article 30(3) contract requirements for any positively classified service.

Concept 2 — Direct ESA Oversight

ESA-Level CTPP Designation

The ESAs designate a small number of systemically important ICT providers as CTPPs. Currently 19 providers globally (November 2025). CTPPs face direct regulatory oversight, must designate an EU subsidiary, and pay annual oversight fees.

What CTPP Designation Means in Practice

For financial entities, the designation of one of their ICT suppliers as a CTPP is a double-edged development. On one hand, it means that the provider’s risk management and governance frameworks are subject to direct regulatory scrutiny by the relevant Lead Overseer ESA — which provides a degree of regulatory assurance that the provider’s operational standards are being independently assessed. On the other hand, it creates contractual and commercial complexity: the financial entity’s obligations under DORA continue to apply regardless of the CTPP designation, and contract renegotiation may be required to ensure compliance. For CTPPs themselves, the designation triggers a direct supervisory relationship: the relevant ESA will assess the provider’s risk management procedures, incident reporting, subcontracting arrangements, and ICT security practices. Where the ESA identifies deficiencies, it may issue recommendations for remediation. If a CTPP does not comply, the ESA may make the non-compliance public and, as a last resort, require financial entities to suspend or terminate use of the provider’s services.

V. Contracting Implications Under Article 30

A Two-Tier Mandatory Framework

Article 30 creates the backbone of DORA’s third-party risk management regime. It establishes a two-tier contractual framework: a baseline set of requirements that must appear in every ICT service contract, and an enhanced set of requirements that must be added on top of the baseline whenever the service supports a critical or important function. Both tiers are mandatory. The financial entity has no discretion to omit them, and the ICT service provider’s agreement to them is a precondition of the contract’s compliance with DORA.

Tier 1: The Baseline — What Every ICT Service Contract Must Contain (Article 30(1) and (2))

Article 30(1) establishes the foundational requirement: the rights and obligations of the financial entity and the ICT service provider must be clearly allocated and set out in writing. The full contract — including any service level agreements — must be documented in a single written document that is available to both parties on paper or in a downloadable, durable, accessible format. This requirement alone will require many existing vendor contracts to be restructured, since it is common for technology service arrangements to be spread across multiple documents, order forms, clickwrap terms, and evolving SLA schedules.

Article 30(2) then sets out the minimum content that every ICT service contract must include, regardless of the nature of the function it supports. The contract must contain a clear and complete description of all functions and ICT services to be provided, indicating whether subcontracting of the service — or material parts of it — is permitted, and if so, on what conditions. It must specify the locations — regions or countries — where the service will be provided and where data will be processed and stored, along with a requirement that the provider give advance notice to the financial entity if it intends to change those locations. The contract must include provisions addressing the availability, authenticity, integrity, and confidentiality of data, including personal data, in connection with the service.

Beyond these data-related provisions, the baseline contract must address business continuity: specifically, it must include provisions ensuring that the financial entity can access, recover, and obtain the return of its personal and non-personal data in an easily accessible format in the event of the provider’s insolvency, business discontinuation, or the termination of the contractual arrangement. Service level descriptions must be included, along with updates and revisions to those descriptions over time. The provider must accept an obligation to assist the financial entity at no additional cost — or at a cost determined in advance — when an ICT incident related to the service occurs. The provider must also agree to cooperate fully with the competent authorities and resolution authorities of the financial entity, including any persons they may appoint. The contract must specify termination rights and minimum notice periods, and must require the provider to participate in the financial entity’s ICT security awareness programmes and digital operational resilience training.

Tier 2: Enhanced Requirements for Critical or Important Functions (Article 30(3))

Where the ICT service has been designated by the financial entity as supporting a critical or important function, six additional categories of requirement must be added to the Tier 1 baseline. These requirements are more operationally demanding — particularly for smaller technology vendors — and understanding them in advance is essential for any vendor seeking to serve the EU financial sector competitively.

First: Precise, measurable service level descriptions. Generic SLA language is insufficient for critical or important function contracts. Article 30(3)(a) requires full service level descriptions that include precise quantitative and qualitative performance targets, enabling the financial entity to effectively monitor ICT service delivery and to take corrective action without undue delay when agreed targets are not met. Vendors should expect to be asked to commit to specific uptime percentages, response times, resolution timescales, and other measurable metrics — and to accept contractual consequences if those targets are not achieved.

Second: Enhanced notice and reporting obligations. The provider must give notice of any development that might materially affect its ability to deliver the service in line with the agreed service levels. (Article 30(3)(b)) This is a forward-looking obligation — it requires notification of circumstances that create a material risk to future service delivery, not merely reporting on incidents that have already occurred. For vendors, this means establishing internal monitoring and escalation processes to identify and disclose capability risks before they materialise as service failures.

Third: Business contingency planning and ICT security. The provider must implement and test business contingency plans and must maintain in place ICT security measures, tools, and policies that provide an appropriate level of security for the financial entity’s services, in line with the financial entity’s regulatory framework. (Article 30(3)(c)) Vendors who have not previously been required to maintain or evidence formal business continuity plans will need to develop them, and should expect their financial entity customers to request evidence of testing.

Fourth: Threat-Led Penetration Testing cooperation. The provider must participate fully and cooperate in the financial entity’s TLPT exercises as referred to in Articles 26 and 27 of DORA. (Article 30(3)(d)) TLPT is a rigorous, structured red-team exercise in which realistic cyber threats are simulated against live production systems. For vendors whose systems are in scope for a financial entity’s TLPT, this obligation requires active operational cooperation — providing access to systems, engaging with the testing team, and participating in remediation of any findings. This is one of the more demanding obligations for smaller technology providers that have not previously been subject to this level of security testing.

Fifth: Comprehensive audit and inspection rights. Article 30(3)(e) is typically the provision that generates the most commercial negotiation. The contract must provide unrestricted rights of access, inspection, and audit to the financial entity, any third party the financial entity appoints, and the competent authority — including the right to take copies of relevant documentation on-site if it is critical to operations. Critically, these rights must not be impeded or limited by other contractual arrangements the provider may have with third parties or by its implementation policies. The contract must also provide the right to agree on alternative assurance levels where the direct exercise of audit rights would affect the confidentiality rights of other clients. The provider must cooperate fully during onsite inspections and audits carried out by the competent authority, the Lead Overseer (in the case of a CTPP), the financial entity, or any appointed third party, and must provide details on the scope, procedures, and frequency of such inspections and audits.

The microenterprise derogation: Where the financial entity qualifies as a microenterprise under EU law (fewer than 10 employees; annual turnover not exceeding €2 million), the parties may agree that the financial entity’s direct rights of access, inspection, and audit can be delegated to an independent third party appointed by the ICT service provider — provided the financial entity retains the ability to request information and assurance from that third party at any time. (Article 30(3)(e), derogation paragraph) This is a genuine and useful practical accommodation for smaller financial entities that may lack the internal capacity to conduct direct vendor audits and for smaller vendors that may find it operationally difficult to accommodate individual customer audit teams.

Sixth: Exit strategies and mandatory transition periods. The contract must include provisions for an exit strategy — specifically, the establishment of a mandatory, adequate transition period during which the provider will continue to provide the service with a view to reducing the risk of disruption to the financial entity, and during which the financial entity can migrate to an alternative provider or bring the function in-house, consistent with the complexity of the service. (Article 30(3)(f)) For vendors, this means accepting a contractual obligation to continue servicing a customer that has decided to leave — potentially for an extended period — while that customer arranges an alternative. Vendors should factor this into their commercial planning and ensure that their standard terms can accommodate this requirement.

Subcontracting of Critical or Important Functions

Where a vendor itself relies on subcontractors to deliver services that support a financial entity’s critical or important functions, the contract must address that subcontracting explicitly. The financial entity must be informed whether subcontracting is permitted, for which elements, and on what conditions. (Article 30(2)(a)) The ESAs are developing Regulatory Technical Standards to specify further the elements that financial entities must assess when evaluating subcontracting of critical or important functions, taking into account the financial entity’s size and risk profile. For technology vendors whose services are built on third-party infrastructure — for example, a SaaS platform deployed on a hyperscale cloud provider — this creates a disclosure obligation and may require contractual protections that flow through to the subcontractor level.

Standard Contractual Clauses

Article 30(4) states that when negotiating contractual arrangements, financial entities and ICT service providers should consider using standard contractual clauses developed by public authorities for specific services. This is framed as a recommendation rather than a hard obligation, but it reflects a regulatory preference for standardised terms that can reduce negotiation friction and provide a degree of legal certainty. As the market matures and standard DORA-compliant contractual clauses become more widely available, vendors should monitor their development and consider incorporating them into their standard terms to reduce the commercial friction of DORA-related negotiations with financial entity customers.

VI. The Critical Third-Party Provider List

On 18 November 2025, the ESAs published the first list of 19 Critical Third-Party Providers designated under Article 31. The list was developed using data collected from the registers of information submitted by financial entities to their national supervisors across the EU banking, insurance and pensions, and securities and markets sectors — registers that identify which third-party ICT providers support the critical or important functions of each financial entity. That data, aggregated across the sector, allowed the ESAs to apply the four designation criteria systematically across the full population of ICT third-party service providers operating in the EU financial services market.

The 19 providers on the initial list span four broad categories: hyperscale cloud providers, data centre operators, infrastructure and network providers, and financial services-specific technology companies. For CTPPs, the practical consequences are significant and immediate. Each CTPP must designate a legal entity — ideally an EU subsidiary with sufficient resources and authority — as its coordination point with the relevant Lead Overseer ESA. CTPPs must pay annual oversight fees to the relevant ESA. Their risk management and governance frameworks are subject to direct supervisory assessment, and they may be required to remediate any deficiencies identified by the Lead Overseer. In the most serious cases of non-compliance, the ESA has the power to require financial entities to suspend or terminate their use of the CTPP’s services.

Providers that are not on the initial list but believe they may meet the designation criteria have the right under Article 31(11) to submit a reasoned application to the relevant ESA requesting voluntary designation as critical. The ESAs must decide on such applications within six months of receipt. The list will be updated and republished annually, meaning that providers that do not currently appear on it may find themselves on a future edition as the market evolves and the ESAs’ data collection matures. Technology providers with a significant concentration of EU financial sector clients should monitor the annual publication process closely.

VII. What SMBs and Software Vendors Should Do Now

For Small and Medium Financial Entities

The starting point for any financial entity is a complete and accurate mapping of its ICT supplier portfolio. Every contractual arrangement with an ICT service provider must be registered in the format required by the ITS — a task that requires both legal and technical input to complete correctly. Once the register is populated, the financial entity must carry out a critical or important function assessment for each ICT service relationship, documenting its methodology and conclusions. This assessment should be reviewed and updated at least annually, and whenever there is a material change to the service or the financial entity’s business.

With the assessment complete, the financial entity must audit its existing contracts against the Article 30(2) baseline requirements and, for any service designated as supporting a critical or important function, against the Article 30(3) enhanced requirements. Gaps should be identified and prioritised: critical or important function contracts with material deficiencies represent the highest compliance risk and should be remediated first. Financial entities should be prepared for contractual negotiations with ICT vendors to be commercially complex, particularly around audit rights and exit strategies, and should consider engaging specialist privacy and technology counsel to assist.

For Software Vendors and Technology Providers

The most important step for any technology vendor serving the EU financial sector is a thorough review of its standard terms and conditions for compatibility with DORA Article 30. The provisions most likely to create friction are the audit and inspection rights under Article 30(3)(e), the exit strategy and transition period obligations under Article 30(3)(f), the TLPT cooperation obligation under Article 30(3)(d), and the business continuity requirements under Article 30(3)(c). Vendors that have not previously been asked to accept these obligations should begin internal discussions now about what operational changes would be required to honour them, and should develop a clear commercial position on how they will approach these negotiations.

Proactively developing a DORA addendum — a short, standardised form of contract amendment that incorporates the Article 30 requirements — can significantly reduce the time and cost of individual negotiations with financial entity customers. Vendors that come to the table with a prepared, legally reviewed DORA addendum signal both commercial sophistication and regulatory awareness, which can be a genuine competitive differentiator in a market where financial entities are under pressure to complete their DORA remediation programmes.

Vendors should also assess, honestly, whether their services are likely to be classified as supporting critical or important functions by their financial entity customers. The more central the service is to the customer’s regulated activity — the more directly a failure would impair regulatory compliance or service continuity — the more likely it is to attract the enhanced Article 30(3) requirements. Vendors serving multiple financial entities across the EU should also consider whether, over time, they may approach the threshold for CTPP designation, and what the operational and commercial implications of that designation would be.

VIII. Key Legal References