DORA and software suppliers: what the contract must say

Article 30 of the Digital Operational Resilience Act (DORA) lists what a financial entity's written contract with an ICT supplier has to contain, and it asks for more when the service supports a critical or important function. The regulation has applied since 17 January 2025 and the duty sits with the financial entity, so a software supplier meets it through the clauses its customer asks for.

Who has to put these clauses in the contract?

The obligation is on the financial entity. Article 28(1)(a) of Regulation (EU) 2022/2554 says an entity with contracts for ICT services stays fully responsible for meeting the regulation. Article 64 of the same regulation says it applies from 17 January 2025, and BaFin's DORA FAQ says the same.

Article 30 sets out what the entity's contract contains. In our reading, a supplier takes on these duties only through the contract, which is why a bank or insurer sends clauses to its software suppliers.

The regulation defines ICT services as "digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis". The register templates in Implementing Regulation (EU) 2024/2956 list "ICT Development" (business analysis, software design and development, testing) as one type of ICT service. So software development is named. Whether a fixed-scope build that ends on delivery counts as "ongoing" is not answered in the sources we read.

What must every ICT contract contain?

Article 30(1) requires the rights and obligations of both sides to be set out in writing. The full contract includes the service level agreements and sits in one written document, available on paper or in another downloadable, durable and accessible format.

Article 30(2) lists the minimum for every contract on ICT services, in the regulation's order. The first group describes the service itself. The contract needs a clear and complete description of all functions and ICT services, stating whether subcontracting of a service that supports a critical or important function is permitted and on what conditions. It must name the regions or countries where services are provided and data is processed, storage included, with advance notice if the supplier plans to change them. It must also contain service level descriptions, including updates and revisions.

The second group concerns the data and the supplier's help when something goes wrong. The contract needs provisions on the availability, authenticity, integrity and confidentiality of data, personal data included. It must also provide for access, recovery and return of personal and non-personal data in an easily accessible format if the supplier becomes insolvent, is resolved or stops trading, or if the contract ends. The supplier takes on an obligation to help when an ICT incident related to the service occurs, at no additional cost or at a cost fixed in advance.

The third group covers oversight and the end of the relationship. The supplier must cooperate fully with the entity's competent authorities and resolution authorities, including people they appoint. The contract sets termination rights and minimum notice periods, in line with what those authorities expect, and it states the conditions under which the supplier takes part in the entity's security awareness programmes and resilience training. On that last element, BaFin's FAQ says the entity decides on a risk basis and proportionately which conditions to agree and whether to run a training at all.

What else applies for a critical or important function?

The regulation defines a critical or important function as one whose disruption would materially impair the entity's financial performance, or the soundness or continuity of its services, or its compliance with its authorisation. The entity assesses this before it signs (Article 28(4)(a)).

For such services Article 30(3) adds at least six terms. Two of them concern how performance is measured and reported. The contract needs full service level descriptions with precise quantitative and qualitative targets, so the entity can monitor and act without undue delay when targets are missed. It also needs notice periods and reporting duties, including notice of any development that could materially affect the supplier's ability to deliver at the agreed service levels.

Two more concern resilience and testing. The supplier must implement and test business contingency plans and keep ICT security measures at an appropriate level, and it must take part in and cooperate fully with the entity's threat-led penetration testing (TLPT) under Articles 26 and 27. The last two concern control and exit. The entity gets the right to monitor performance on an ongoing basis: unrestricted access, inspection and audit rights for the entity, an appointed third party and the authority, alternative assurance levels if other clients' rights are affected, cooperation in on-site audits, and details of scope, procedure and frequency. The contract also needs exit strategies, with a mandatory adequate transition period in which the supplier keeps providing the service and the entity can move to another supplier or in-house.

A microenterprise may agree that its audit rights go to an independent third party that the supplier appoints (Article 30(3), last subparagraph). Article 30(4) asks both sides to consider standard contractual clauses developed by public authorities. BaFin's implementation notice says none were available when it was written and that firms should not wait for them.

How do termination and exit reach the contract?

Article 28(7) says the entity must be able to end a contract in four situations: a significant breach by the supplier, circumstances found in monitoring that could change how the service performs, evidenced weaknesses in the supplier's ICT risk management, and cases where the authority can no longer supervise the entity effectively because of the contract.

Article 28(8) requires exit strategies for services that support critical or important functions. The entity must be able to leave without disrupting its business, without limiting regulatory compliance and without harming service to clients. Exit plans are documented, tested and reviewed, and cover moving services and data to another provider or in-house.

The supplier's part is in the contract: return of data, a transition period and termination rights. Article 10 of Delegated Regulation (EU) 2024/1773 (published 25 June 2024) adds that the policy on contracts for services supporting critical or important functions must require a documented exit plan for each contractual arrangement, with a schedule that fits the exit and termination terms.

What do the rules say about subcontractors?

Article 30(2)(a) already asks whether subcontracting is allowed and on what conditions. Delegated Regulation (EU) 2025/532 (published 2 July 2025) adds detail for services that support critical or important functions. Under its Article 4 the contract identifies which services may be subcontracted and on what conditions, and it specifies several further points.

The first concerns responsibility and monitoring. The supplier is responsible for services its subcontractors provide and monitors them, and it has monitoring and reporting duties towards the entity about subcontractors. The supplier also assesses the risks tied to the locations of subcontractors and their parent companies, and the contract states where a subcontractor stores or processes data. The second concerns what flows down. Business contingency and ICT security requirements reach the subcontractor, and the subcontractor gives the entity and the authorities the same access, inspection and audit rights. The supplier must also notify the entity of any material change to subcontracting.

Article 5 adds that the contract sets a reasonable notice period in which the entity can approve or object to such a change, and that the supplier implements it only after approval or no objection. Article 6 lets the entity provide for termination if the supplier goes ahead after an objection or before the period ends, or subcontracts something the contract does not explicitly allow.

Our addition: a checklist for a software supplier

This checklist is our addition, built from the articles above. It turns the clauses into questions a supplier can answer early.

A supplier can start with the description of the work. Can you describe every service and deliverable in one written document, with the service levels in it? Which subcontractors would touch the service, in which countries, and how would you tell the customer before that changes? Where are data stored and processed, backups and test environments included, and what notice do you give before moving them? How does the customer get its data back, and in what format, if you become insolvent or the contract ends?

The next questions concern the relationship. What help do you give during an incident, and is it free or priced in advance? Will you cooperate with the customer's supervisor and resolution authority? What notice periods apply to termination, and how long would you keep the service running during a transition? Do you take part in the customer's security training?

Four more questions apply only where the service supports a critical or important function. Will you accept audits and inspections on site, including by an appointed third party? Will you cooperate in the customer's threat-led penetration test? Can the customer see service level results against precise targets? Which contingency plans do you test, and how often?

The list covers only what Article 30 names. BaFin's list of minimum clauses likewise holds only terms the legal texts name, and BaFin says other terms it would be prudent to agree are not in it. Article 30 does not mention source code, code escrow or intellectual property. In our reading, those stay a matter for the parties.

For this kind of work, our financial services page says we go through the contract terms DORA lists with a customer before signing, and our security page describes how we handle data. Our custom software development page covers the build work itself.

What about the register of information?

Article 28(3) requires financial entities to keep a register of all contractual arrangements on ICT services, distinguishing those that support critical or important functions, and to report at least yearly to the competent authorities on new arrangements, supplier categories, contract types and the services provided. The templates are in Implementing Regulation 2024/2956, published on 2 December 2024. In our reading, a supplier should expect its customer to ask for details to fill in the register. We did not go through the templates line by line.

What we could not confirm

The main open question is whether a fixed-scope software project that ends on delivery is an ICT service "on an ongoing basis". The definition says so, the register templates list ICT development, and we found no official answer on fixed-scope projects. A lawyer should decide this for a specific contract. We also cannot say what a customer will insist on, since its own policy and its supervisor decide the final wording and we read only BaFin's guidance.

We could not confirm whether anyone has published standard contractual clauses under Article 30(4) since BaFin wrote its notice. We found none in a limited search, which does not prove there are none. Nor could we confirm whether Articles 28 to 30 have been amended: we read the text as published in the Official Journal, a query of the Publications Office database for amending acts returned none, and we could not open a consolidated version.

BaFin's notice text is dated June 2024, its web page 9 October 2024 (changed 2 May 2025), and it refers to a draft of the subcontracting rules. We used the final 2025/532 text directly. BaFin calls the notice non-binding help.