DORA for a software vendor: the Article 30 contract clauses your bank customer will send, the register of information you will appear in, and what ISO 27001 already answers

If your customers include a bank, an insurer, an investment firm, a payment or e-money institution, a crypto-asset service provider or a fund manager in the Union, you have probably received a contract addendum you did not draft, with clauses about audit rights, exit strategies and the countries your servers are in. That is Regulation (EU) 2022/2554, the Digital Operational Resilience Act, which has applied since 17 January 2025. It does not regulate you; it regulates your customer, and Article 28(1)(a) makes the customer fully responsible for everything it outsources to you, so the customer passes the obligations down in the contract. This article reads the clauses Article 30 requires, the register of information your contract lands in, the delegated acts that fill in the detail, and which clauses an ISO 27001 management system already answers, from the texts on CELLAR on 12 September 2026. It is not legal advice.

Who you are, in DORA's words

Article 3(19) defines an ICT third-party service provider as an undertaking providing ICT services, and Article 3(21) defines ICT services as digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis. A SaaS product is that; so is a managed service, a hosted API, a data feed. Whether the contract is short or long, listed or negotiated, does not matter. What matters is one question the customer answers under Article 28(4)(a) before signing: does the service support a critical or important function, defined in Article 3(22) as a function whose disruption would materially impair the customer's financial performance, the soundness or continuity of its services, or its continued compliance with its authorisation. The answer decides whether you get nine clauses or fifteen.

The nine clauses of every ICT contract, Article 30(2)

Article 30(1) starts with form: rights and obligations clearly allocated and set out in writing, the full contract including the service level agreements in one written document, available on paper or in a downloadable, durable and accessible format. Then Article 30(2) lists what every contract on the use of ICT services includes at least:

(a) a clear and complete description of all functions and ICT services provided, indicating whether subcontracting of a service supporting a critical or important function is permitted and on what conditions; (b) the locations, regions or countries, where the functions and services are provided and where data is processed, storage included, and an obligation to notify the customer in advance of a change of location; (c) provisions on availability, authenticity, integrity and confidentiality of data, personal data included; (d) provisions ensuring access, recovery and return, in an easily accessible format, of the customer's personal and non-personal data in the event of your insolvency, resolution or discontinuation, or of termination; (e) service level descriptions, including their updates and revisions; (f) your obligation to assist the customer at no additional cost, or at a cost determined ex ante, when an ICT incident related to the service occurs; (g) your obligation to fully cooperate with the customer's competent authorities and resolution authorities, including persons they appoint; (h) termination rights and minimum notice periods for termination, in line with the expectations of those authorities; (i) the conditions of your participation in the customer's ICT security awareness programmes and digital operational resilience training under Article 13(6).

Two of these change a vendor's operations rather than its paperwork. Point (b) means a region change on your cloud account is a contractual notice event. Point (f) means incident assistance is priced before the incident or not priced at all.

The six more for critical or important functions, Article 30(3)

Where the service supports a critical or important function, the contract includes in addition:

(a) full service level descriptions with precise quantitative and qualitative performance targets, so the customer can monitor and take corrective action without undue delay when levels are not met; (b) notice periods and reporting obligations to the customer, including notification of any development that might materially affect your ability to provide the service at the agreed levels; (c) requirements to implement and test business contingency plans and to have ICT security measures, tools and policies giving an appropriate level of security for the customer's regulatory framework; (d) your obligation to participate and fully cooperate in the customer's threat-led penetration testing under Articles 26 and 27; (e) the customer's right to monitor your performance on an ongoing basis: unrestricted rights of access, inspection and audit by the customer, a third party it appoints, and the competent authority, with the right to take copies of relevant documentation on site where you are critical to their operations, not impeded by other contracts; the right to agree alternative assurance levels where other clients' rights are affected; your obligation to cooperate fully in on-site inspections and audits by the competent authorities, the Lead Overseer, the customer or its appointee; and the obligation to provide details of the scope, procedures and frequency of such inspections and audits; (f) exit strategies, with a mandatory adequate transition period during which you continue providing the service so the customer can migrate to another provider or in-house without disruption.

One derogation: where the customer is a microenterprise, Article 30(3) lets the parties agree that its access, inspection and audit rights are delegated to an independent third party you appoint, from which the customer can request information and assurance at any time. And Article 30(4) asks both sides to consider standard contractual clauses developed by public authorities for specific services.

The register of information, and the acts behind the detail

Article 28(3) makes every customer maintain a register of information on all its contractual arrangements for ICT services, distinguishing those supporting critical or important functions, report yearly to its competent authority on the new arrangements, the categories of providers, the types of contract and the services and functions, hand over the full register on request, and inform the authority before contracting for a critical or important function. Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024 lays down the standard templates of that register, so your name, your legal identifier, the service, the function it supports and the countries it is delivered from are fields in a form your customer files.

Three delegated regulations fill in the rest. Delegated Regulation (EU) 2024/1773 of 13 March 2024 specifies the content of the customer's policy on contractual arrangements for critical or important functions: the due diligence it runs on you before signing (Article 28(4)(d)), including whether you comply with appropriate information security standards, which Article 28(5) makes a condition of contracting at all and, for critical or important functions, a matter of the most up-to-date and highest quality standards. Delegated Regulation (EU) 2024/1774 of the same date specifies the customer's own ICT risk management tools, methods, processes and policies, the framework Article 28(1) makes your service a component of. Delegated Regulation (EU) 2025/532 of 24 March 2025 specifies what the customer determines and assesses when you subcontract a service supporting a critical or important function, which is why point (a) of the nine clauses asks you to say whether you subcontract and on what conditions.

The layer above the contract

Article 29 makes the customer assess, before signing, whether you are not easily substitutable and whether it is concentrating several critical services on you or on providers closely connected to you; a vendor that is hard to replace is a vendor whose exit strategy under Article 30(3)(f) gets negotiated hard. Article 31 lets the European Supervisory Authorities designate ICT third-party service providers that are critical for the financial sector as a whole, on criteria of systemic impact, the number and importance of the financial entities served, and substitutability; a designated provider gets a Lead Overseer with powers of its own. That layer reaches the hyperscalers and the core banking vendors, not a company with three bank customers, but the register of information is how the authorities count.

What ISO 27001 already answers

Article 28(5) is the clause that asks what standard you comply with, and the audit right of Article 30(3)(e) is the clause that asks to see it. An ISO/IEC 27001 information security management system does not satisfy a contract clause; it produces the evidence a customer's due diligence and audit ask for under several of them. The table is StandardOS's reading of the fit; DORA names no standard and grants no presumption.

Two clauses have no ISO 27001 answer and are pure contract: 30(2)(g) cooperation with the customer's authorities, and 30(2)(h) termination rights aligned with what those authorities expect. Write them once and reuse them.

What to do before the next addendum arrives

Decide, per product, whether you can be a critical or important function for a customer, and prepare the fifteen-clause version rather than negotiating from the nine. Write the locations sentence exactly: regions, countries, subprocessors, storage. Price incident assistance ex ante. Write the exit and transition procedure with a period in months and a data return format. Publish the audit terms you can live with, including the alternative assurance route for shared infrastructure. The clause checklist lists the nine or fifteen in your language with a status for each. Then bring the ISO 27001 records the table names to the due diligence, so the customer's Article 28(5) question has an answer before it is asked.