Table of Contents
- 1.The Invisible Half of DORA
- 2.Am I Even an ICT Third-Party Provider?
- 3.Article 30: The Mandatory Clauses That Must Be in Your Contract
- 4.Audit and Access Rights: What You Are Really Granting
- 5.The Register of Information: How You End Up on Your Customer's List
- 6.Negotiation Guardrails: What You Accept, What You Push Back On
- 7.How to Become a Preferred DORA Supplier
- 8.Sources and Further Reading
The Invisible Half of DORA
A great deal has been written about DORA — almost all of it for the regulated financial entities. Banks, insurers, payment service providers, and investment firms find countless guides explaining how to build their resilience, manage third-party risk, and maintain their Register of Information. What almost nobody explains: the contracts DORA requires are signed by two parties. On the other side sits the ICT third-party service provider — and for that party the available sources online are surprisingly thin.
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied directly across all EU member states since 17 January 2025. Unlike a directive, it needs no national transposition — the regulation takes effect directly. For financial entities this is a hard obligation. For their IT providers it is a contractual phenomenon: the regulatory requirements reach you not through a statute, but through the contracts your customers now put in front of you.
We therefore deliberately look at DORA here from the vendor perspective. If you sell cloud hosting, software-as-a-service, managed services, data center services, or specialized IT consulting to financial entities, you are an ICT third-party service provider within the meaning of the regulation. The legal assessment of your specific contract belongs with a law firm — but the logic of the clauses, the room to negotiate, and the operational consequences are things you can understand before you sign. That is what this guide delivers.
The most important sentence up front: you are no longer asked whether you accept DORA clauses. You are asked whether you want the contract. Anyone who cannot or will not meet the mandatory clauses of Article 30 drops off the supplier list — because without them the financial entity is not even permitted to enter into the contract. Anyone who understands them can negotiate in the right places and save time in the wrong ones.
Am I Even an ICT Third-Party Provider?
The scope of DORA for providers is broader than many assume. The regulation defines ICT services comprehensively: digital and data services provided on an ongoing basis through ICT systems to one or more internal or external users. That covers far more than classic hosting.
In practice: if you provide any of the following to a financial entity, you are very likely an ICT third-party provider and should expect DORA contracts. The following list is orientation, not a conclusive legal classification — that follows from your specific service profile.
A special category are the "critical ICT third-party providers" (CTPPs), designated and supervised directly by the European Supervisory Authorities. This affects only very large, systemically relevant providers. The vast majority of providers are not critical in the sense of this special oversight, but they are very much covered by the contractual obligations of Article 30 — via their financial customers' contracts.
- Cloud computing services (IaaS, PaaS, SaaS) — from infrastructure to a finished business application
- Software development and maintenance, where the software runs in production financial operations
- Managed services, data center and hosting services, network and connectivity services
- Data analytics, data hosting, and data processing services
- Specialized IT consulting and implementation services with ongoing system access
- Security services such as SOC operations, monitoring, or identity management
Article 30: The Mandatory Clauses That Must Be in Your Contract
The heart of the matter for providers is Article 30 of Regulation (EU) 2022/2554. It lists the elements every contractual arrangement on the use of ICT services must mandatorily contain. This is not a recommendation and not bargaining material: without these elements the financial entity may not conclude the contract. Article 30 distinguishes between requirements that apply to all ICT contracts and additional, stricter requirements for services that support critical or important functions of the financial entity.
This distinction is central for you as a provider: if your service delivers a critical or important function, the stricter clauses apply — full service-level descriptions with precise quantitative and qualitative targets, far-reaching audit and access rights, and detailed exit strategies. If your service delivers a supporting, non-critical function, the base catalogue applies. The classification is made by the financial entity, not by you — but it determines how strict your contract becomes.
The following overview translates the central mandatory elements of Article 30 into what they concretely mean for you as a provider. It does not replace reading the regulation text on EUR-Lex, but it turns the statutory text into a negotiation map.
| Mandatory element (Art. 30) | What it means for you as a provider | Stricter for critical/important function |
|---|---|---|
| Clear service description | Complete, unambiguous description of all ICT services and functions provided — vague scope is no longer permissible | Yes — incl. whether sub-services are allowed and under what conditions |
| Data location & processing | Specification of the locations (countries/regions) where data is processed and stored; duty to inform in advance of relocation | Yes — location changes may become subject to consent |
| Availability, integrity, confidentiality, data protection | Contractual assurance of protection levels for the financial entity's data, including personal data | Yes — usually underpinned with measurable targets |
| Service Level Agreements (SLAs) | For non-critical services: description of the service levels. For critical services: precise quantitative and qualitative performance targets with response times | Yes — full, measurable SLAs with defined response and recovery targets |
| Incident assistance & notification | Duty to assist the financial entity in ICT incidents and to inform it of incidents affecting its services — at no additional cost or at pre-agreed cost | Yes — defined reporting paths and support for regulatory incident reporting |
| Audit, access & inspection rights | The financial entity, its appointed auditors, and the competent authority obtain comprehensive rights of access, inspection, and audit of your relevant systems and premises | Yes — unrestricted rights, incl. on-site audits and full cooperation |
| Participation in resilience testing | Duty to participate in or support the financial entity's security awareness and resilience testing programs | Yes — inclusion in the threat-led penetration testing (TLPT) program may be required |
| Sub-outsourcing transparency | Disclosure of whether and which subcontractors support critical/important functions; conditions for sub-outsourcing | Yes — prior information and possibly objection/consent rights when subcontractors change |
| Termination & exit rights | Defined termination grounds and notice periods in favor of the financial entity, including for breaches, supervisory orders, or weaknesses in risk management | Yes — plus a full exit strategy and transition support |
| Exit strategy & data return | For critical/important functions: an adequate transition period during which you continue the service, plus orderly return/migration of all data in a usable format | Yes — the exit plan is a mandatory element, not optional |
Audit and Access Rights: What You Are Really Granting
Audit and access rights are, for many providers, the most uncomfortable part of Article 30 — and the most frequently misunderstood. The regulation requires that the financial entity, a third party it appoints, and the competent supervisory authority obtain the unrestricted right of access, inspection, and audit of the systems, processes, and premises relevant to the service provided. For critical or important functions, these rights are particularly far-reaching and include on-site audits.
What unsettles many providers at first: does this mean any bank customer may walk into my data center unannounced at any time? No. The regulation allows the modalities to be shaped contractually — notice periods, confidentiality rules, proportionality, and limitation to the areas relevant to the service are negotiable. What is not negotiable is the existence of the right itself and the fact that the supervisory authority may not, in the end, be locked out.
A decisive lever in practice for providers with many financial customers are recognized third-party certifications and pooled audits. Instead of granting every customer its own on-site audit, you can negotiate that standardized assurance reports (such as recognized security and control audits by independent assessors) cover the bulk of the audit requirement and that on-site audits remain limited to justified exceptional cases. Supervisors explicitly accept such poolable evidence as a means to reduce the burden on both sides — but it does not replace the supervisory access right.
You must accept: the audit right itself, full supervisory access, and the duty to cooperate. You can negotiate: notice periods, the recognition of pool audits and certifications, limitation to relevant systems, and fair cost-sharing for additional on-site audits.
The Register of Information: How You End Up on Your Customer's List
Under DORA, every financial entity must maintain a Register of Information on all contractual arrangements for the use of ICT services. Every provider appears in this register — including you. For you as a provider this matters because your customer needs precisely the data from you that it enters into this register and reports to its supervisor.
The European Supervisory Authorities — the EBA for banks, EIOPA for insurers, and ESMA for investment firms — have harmonized the format of the Register of Information through joint technical standards. In Germany, BaFin coordinated the national collection. The first regular reporting window for the Register of Information ran from 9 to 30 March 2026 — financial entities had to submit their registers to BaFin in this period. This means: if you have financial customers, you very likely received data requests in spring 2026, and this reporting window will recur regularly.
Concretely, your customer typically needs a set of structured master data from you in order to enter you correctly into the register. A provider who keeps these details clean, current, and in the expected form is noticeably easier for its financial customers to manage — and that is precisely a competitive advantage when the customer consolidates its supplier list.
- 1Unique identifiers: your company identifiers such as the Legal Entity Identifier (LEI), where available, plus full legal name and registered seat.
- 2Service description and ICT service type: a clear classification of the service you provide, matching the agreed taxonomy.
- 3Function critical or not: the information whether your service supports a critical or important function of the financial entity — this drives the strictness of the contract clauses.
- 4Data locations: the countries/regions where data is processed and stored, plus the location of service provision.
- 5Sub-outsourcing chain: details of the subcontractors supporting critical/important functions — the chain must be traceable to a relevant depth.
- 6Contract key data: start, term, notice periods, and the classification of whether it is a contract for a critical or important function.
Negotiation Guardrails: What You Accept, What You Push Back On
The most valuable skill for an IT provider in the DORA era is to cleanly separate what is non-negotiable because the regulation mandates it from what is genuinely bargaining material because the regulation only sets the objective, not the exact mechanism. Anyone who nods through everything gives up room unnecessarily. Anyone who blocks across the board loses the contract, because their customer is not allowed to conclude it without the mandatory clauses.
The following guardrail is a rule of thumb from practice, not legal advice. It helps you focus the conversation with your financial customer's procurement and legal departments on the points where there is genuinely something to gain.
What you must accept (non-negotiable)
The existence of audit, access, and inspection rights for the customer, appointed auditors, and the supervisor. You can shape the modalities, but you cannot delete the right.
The duty to cooperate with the competent supervisory authority — the supervisor may not be contractually locked out.
The duty to assist the financial entity in ICT incidents and to inform it of relevant incidents.
A complete service description and the specification of data locations. Vague scope definitions are no longer tenable under DORA.
For critical/important functions: an exit strategy with an adequate transition period and orderly data return in a usable format.
Termination rights for the financial entity for the grounds named in the regulation, such as serious breaches or regulatory orders.
What you can negotiate (room to shape)
Notice periods and the practical design of on-site audits — including the recognition of pool audits and independent third-party certifications instead of individual audits.
The concrete SLA targets, response and recovery times — they must be measurable, but the level is a matter of negotiation and should fit your real capability.
The allocation of costs for audit, support, and testing services beyond the standard scope.
The length of the exit transition period and the extent of migration support — adequate, but not unlimited.
Liability caps and proportionality clauses, as far as they do not hollow out the mandatory elements.
The depth of sub-outsourcing disclosure and the design of information or consent rights when subcontractors in the chain change.
Where to be careful (red flags)
Blanket, unlimited audit rights "at any time without notice" with no modalities at all — that goes beyond the mandatory level and you may demand a sensible design.
Unlimited exit transition obligations with no cost provision — an adequate period is mandatory, but indefinite continued service at the old price is not.
Pass-through clauses that load full liability for every subcontractor onto you without proportionality — transparency yes, unlimited strict liability no.
Penalties tied to SLA targets you cannot reliably meet operationally — better to agree realistic values than to make promises you will break.
How to Become a Preferred DORA Supplier
The obligation can be turned into an advantage. Financial entities are noticeably consolidating their supplier base under DORA — every provider generates register, audit, and oversight effort. A provider who keeps that effort small for the customer becomes a preferred vendor while others drop off the list. The following steps make you DORA-fit from the vendor side, before the next contract or the next data request arrives.
- 1Document your service profile: produce a precise, unambiguous description of your ICT services, data locations, and supported functions — exactly the details that must go into your customer's Register of Information.
- 2Disclose the sub-outsourcing chain: keep a current list of your relevant subcontractors ready, including which of them touch critical/important functions. This transparency is contractually required — offer it proactively.
- 3Pool your audit evidence: invest in recognized, independent security and control audits you can offer to all financial customers as pooled evidence. This reduces individual on-site audits and is a genuine selling point.
- 4Prepare an exit plan: define in advance how an orderly migration and data return in a usable format would run, including a transition period. A ready exit plan signals maturity and speeds up negotiations.
- 5Define incident reporting paths: set out through which channel, within what deadline, and with what level of detail you inform financial customers of relevant incidents — and rehearse this path before the first real case.
- 6Check SLA realism: reconcile your committed service levels with your actual, measured capability. Realistic, achievable SLAs are worth more under DORA than ambitious ones you breach when it counts.
Sources and Further Reading
This article is based on the original text of the regulation and official supervisory sources. The legal assessment of your specific contract belongs in the hands of a law firm.
- DORA — Regulation (EU) 2022/2554, incl. Article 30 (EUR-Lex, consolidated text): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554
- Regulatory technical standards on the subcontracting of ICT services supporting critical or important functions — Delegated Regulation (EU) 2024/1773 (EUR-Lex): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1773
- BSI — supervision of regulated companies and digital resilience (related NIS-2/critical-infrastructure context): https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/nis-2-regulierte-unternehmen_node.html
- heise online — ongoing coverage of DORA and digital operational resilience: https://www.heise.de/thema/DORA
Key Takeaways
- DORA (Regulation (EU) 2022/2554) has applied directly since 17 January 2025. IT providers are not directly regulated but are bound to the same obligations through their financial customers' contracts.
- Article 30 lists the mandatory elements of every ICT contract — without them the financial entity may not conclude it. For critical/important functions, stricter clauses apply (full SLAs, exit strategy, far-reaching audit rights).
- Audit, access, and inspection rights for the customer and supervisor are non-negotiable — but the modalities (notice, pool audits, recognized certifications) very much are.
- Every provider ends up in its financial customer's Register of Information; the first regular reporting window to BaFin ran from 9 to 30 March 2026. Keeping clean master data ready makes you easier to manage.
- The skill lies in separation: accept the mandatory clauses, negotiate modalities, SLA values, cost-sharing, and exit periods, and treat unlimited audit/liability clauses as red flags.
Related Assessment Templates
Continue Reading
COBIT vs. ITIL — Which Framework for IT Governance?
Read articleDORA Enforcement 2026: From Compliance Paperwork to Real-Time Proof
Read articleNIST CSF 2.0 Assessment Guide: Evaluate Your Cybersecurity Systematically
Read articleNIS2 Compliance for IT Teams — Practical Governance Guide 2026
Read articleFrequently Asked Questions
DORA directly regulates the financial entities, not you. But through Article 30 you are contractually bound to the same requirements: your financial customer may only conclude the contract if it contains the mandatory clauses, and thereby passes them on to you. In practice you therefore satisfy DORA not as a statute but as a contract. An exception are the few providers designated as critical, who fall directly under European supervision — that affects only very large, systemically relevant providers. The legal classification of your specific case belongs with a law firm.
Non-negotiable are: the audit, access, and inspection right for the customer, appointed auditors, and supervisory authority; the duty to cooperate with the supervisor; the duty to assist and inform in ICT incidents; a complete service and data-location description; the financial entity's termination rights for the grounds named in the regulation; and, for critical or important functions, an exit strategy with data return. Negotiable, by contrast, is how these duties are shaped — deadlines, modalities, SLA targets, cost-sharing, and the recognition of pool audits.
No. The regulation requires that audit, access, and inspection rights exist and that the supervisor is not locked out. But it allows the modalities to be shaped contractually: notice periods, confidentiality, proportionality, and limitation to relevant systems are negotiable. In practice you can also offer recognized independent assurance reports and pool audits so that individual on-site audits remain limited to justified exceptions. The right itself and supervisory access, however, remain in place.
Under DORA, every financial entity maintains a Register of Information on all ICT contractual relationships and reports it to its supervisor. In Germany, BaFin coordinates the collection; the first regular reporting window ran from 9 to 30 March 2026. Your customer enters you into this register and needs structured master data from you for that: unique identifiers (such as the LEI), a service description including ICT service type, the information whether your service supports a critical or important function, the data locations, the sub-outsourcing chain for critical functions, and the contract key data.
Article 30 contains a base catalogue for all ICT contracts and a stricter catalogue for services that support a critical or important function of the financial entity. For critical/important functions, additions include: full, measurable service levels with precise performance and recovery targets, more far-reaching audit and on-site rights, an explicit exit strategy with an adequate transition period and orderly data return, and stricter requirements for the disclosure and management of subcontractors. The classification of whether your function is critical is made by the financial entity — but it largely determines how strict your contract becomes.
Financial entities are consolidating their supplier base under DORA because every provider generates register, audit, and oversight effort. A provider who keeps that effort small becomes a preferred vendor: a cleanly documented service profile, a disclosed sub-outsourcing chain, recognized poolable security and control audits, a prepared exit plan, defined incident reporting paths, and realistic, achievable SLAs. These six points make you noticeably easier to manage for your financial customers — and that is exactly what decides who stays on the supplier list.