DORA and ICT supplier contracts: what financial firms now ask of software and service providers

What DORA is

Regulation (EU) 2022/2554, the Digital Operational Resilience Act, sets uniform requirements for the security of network and information systems in the EU financial sector. Because it is a regulation rather than a directive, it applies directly in every member state, supplemented by regulatory and implementing technical standards drafted by the European Supervisory Authorities.

It covers a wide range of financial entities, including credit institutions, payment and electronic money institutions, investment firms, crypto-asset service providers, trading venues, insurers and reinsurers, and managers of investment funds, with some exemptions and proportionality for smaller firms. For those entities, DORA is the sector-specific law on digital operational resilience.

The regulation rests on five areas: ICT risk management, reporting of major ICT-related incidents, digital operational resilience testing, management of ICT third-party risk, and information sharing. The third-party area is the one that reaches software vendors, cloud providers, hosting companies, data providers and agencies building or running systems for financial firms.

The register of information

Financial entities must maintain a register of information on all contractual arrangements for the use of ICT services provided by third parties, at entity level and, for groups, at sub-consolidated and consolidated levels. The register distinguishes arrangements that support critical or important functions from others, and competent authorities can request it. Supervisors collected the first registers during 2025.

For suppliers, the register explains a wave of data requests: legal entity identifiers, the services provided, the functions they support, where data is processed and stored, and which subcontractors are involved in delivering the service. Accurate answers help the customer and reduce later back-and-forth, while vague answers tend to trigger more questions.

Contract terms required by Article 30

Article 30 of DORA lists key contractual provisions that agreements for ICT services must contain. The rights and obligations of both parties must be clearly allocated and set out in writing, and the full contract, including service level agreements, has to be documented in one written document available to both parties.

Service description

A clear and complete description of all functions and ICT services, including whether subcontracting of services supporting critical or important functions is permitted and under what conditions.

Locations

The regions or countries where services are provided and data is processed, with an obligation to notify the financial entity in advance of changes.

Data protection

Provisions on availability, authenticity, integrity and confidentiality of data, including personal data.

Access and return of data

Access, recovery and return of data in an easily accessible format if the provider becomes insolvent, is resolved or stops operating, or the contract ends.

Service levels

Descriptions of service levels, including updates and revisions.

Incident assistance

An obligation to assist when an ICT incident related to the service occurs, at no additional cost or at a cost determined in advance.

Cooperation and termination

Full cooperation with competent and resolution authorities, and termination rights with minimum notice periods.

Training

Conditions for the provider’s participation in the financial entity’s ICT security awareness programmes and digital operational resilience training.

Extra terms for critical or important functions

Where a service supports a critical or important function, the contract must go further. It needs full service level descriptions with precise quantitative and qualitative performance targets, notice periods and reporting obligations towards the financial entity, and requirements for the provider to implement and test business contingency plans and appropriate security measures.

The provider must also participate and fully cooperate in the financial entity’s threat-led penetration testing where relevant, grant unrestricted rights of access, inspection and audit to the financial entity and competent authorities, and support exit strategies, including a mandatory adequate transition period during which the provider continues to deliver the service so the customer can move to another provider or bring it in-house.

These terms often surprise smaller suppliers used to standard online terms of service. Negotiation is possible on how audit rights are exercised, for example through pooled audits or certifications, but the rights themselves are required.

Incidents: why suppliers are asked to report fast

Financial entities must classify ICT-related incidents and report major ones to their competent authority. The technical standards set short deadlines: an initial notification within four hours of classifying an incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report within one month.

A financial firm cannot meet those timelines if a supplier takes days to disclose an outage or breach. As a result, contracts ask suppliers to notify incidents promptly, share technical details and support root cause analysis. Suppliers should agree commitments they can actually meet, with named contacts and a defined process outside office hours.

Critical ICT third-party providers

DORA also creates an oversight framework for ICT third-party service providers designated as critical for the EU financial sector, typically large cloud and technology providers whose failure could affect many institutions. The European Supervisory Authorities designate these providers, and a lead overseer can request information, conduct inspections and issue recommendations.

Most software houses and agencies will never be designated. The framework still matters to them indirectly, because customers build their concentration risk assessments and exit plans around the large platforms that smaller suppliers often run on.

How suppliers can prepare

Prepare a standard information pack: legal entity details, a description of services, data and hosting locations, subprocessors and subcontractors, security measures, certifications, backup and recovery arrangements, incident notification process and business continuity testing. Keep it current, because customers must keep their registers current.

Review your own contract templates against Article 30 so that negotiations start from terms that already contain the required elements. Plan how you would support an exit, including data export formats and a realistic transition period, rather than treating exit as unlikely.

Finally, look at your own dependencies. If your service runs on a cloud platform or relies on other providers, your customer will ask about them, and a clear map of that chain is increasingly part of winning and keeping financial sector work. This article is a general overview and not legal advice.

Where this sits in what we do

This article covers one decision inside a wider engagement. The solution page sets out how that engagement runs, what it includes and what it costs to find out.

• Custom Business Platform — A platform built around how your business actually runs — customer portal, internal tooling, database and the automation between them.
• The EU AI Act: what actually applies from 2 August 2026
• Belgium's B2B e-invoicing mandate: the January 2026 big bang
• Free zone or mainland in the UAE: what the licence changes for your website, sales and systems
• E-invoicing across Europe: four models, and how to run one invoicing process
• All insight articles