DORA for subcontractors: when your bank and insurance clients pass their obligations on to you

Regulation (EU) 2022/2554, known as DORA (Digital Operational Resilience Act), has applied since 17 January 2025 to financial entities in the Union: banks, insurers, investment firms and payment institutions, among others. An SME that sells them software, a SaaS service, hosting or managed IT is not itself in scope. It receives the effects of the regulation through contracts: DORA requires financial entities to record their ICT (information and communication technology) service providers in a register, to include mandatory clauses in contracts and to control subcontracting chains. This article describes the three transfer mechanisms (Articles 28 to 30), then the answer file an SME provider should build once and reuse with each financial client, rather than treating every request as a new exercise.

Why your client asks for an LEI code and the list of your subcontractors

Article 28(3) of the regulation requires every financial entity to maintain a register of information covering all its contractual arrangements with ICT service providers. The content of the register is standardised by Implementing Regulation (EU) 2024/2956: identification of the provider, nature of the services, functions supported, whether the function is critical or important, data processing locations, and subcontractors further down the chain. In France, the Autorité de contrôle prudentiel et de résolution (ACPR), the French banking and insurance supervisor, collected the first registers by 15 April 2025; the European supervisory authorities repeat the collection each year.

This register explains the requests providers receive: a Legal Entity Identifier (LEI, the 20-character code identifying a legal entity in financial transactions), a precise service description, hosting and processing countries, and the list of subcontractors involved in the service. The client is not being overzealous. It is filling in a regulatory template that its supervisor checks.

The annual cycle and the first critical provider designations

The register collection is now an annual exercise. For the 2026 cycle, financial entities reported their register with a reference date of 31 December 2025, for transmission to the European supervisory authorities by 31 March 2026; an entity whose arrangements had not changed could confirm its previous submission instead of refiling in full. For a provider, this means the requests return every year, at minimum as a confirmation that the recorded information still holds.

On the basis of the first registers, the three European supervisory authorities designated the first critical ICT third-party providers (CTPPs) on 18 November 2025: 19 providers, mostly large cloud and IT infrastructure groups, now under direct oversight by the authorities. An SME provider is not in that population. The effect it may feel is indirect: a designated provider in its own chain (a hyperscaler hosting the service, for instance) passes parts of its oversight obligations down through contracts.

One caveat on the horizon: the Commission's digital omnibus proposals, under negotiation in 2026, include measures to streamline incident reporting across NIS2, DORA and the GDPR. Nothing has been adopted at the date of this article; the obligations described here are the ones in force.

The clauses your client must obtain in the contract

Article 30 sets the minimum content of contracts between a financial entity and an ICT service provider. For all contracts, paragraph 2 requires among other things a clear and complete description of the services, the locations where data is processed, provisions on the availability, authenticity, integrity and confidentiality of data, assistance when an ICT incident relates to the service (at no additional cost or at a cost determined up front), cooperation with the competent authorities, and termination rights with notice periods.

Where the service supports a critical or important function within the meaning of Article 3, point (22), paragraph 3 raises the bar: full service level descriptions with precise performance targets, an obligation to implement contingency plans and ICT security measures, participation in the client's threat-led penetration testing (TLPT), unrestricted rights of access, inspection and audit for the financial entity and its supervisors, and an exit strategy with a mandatory transition period.

The principle of these clauses is not negotiable: the financial client is not allowed to sign without them. Negotiation concerns their practical terms, for instance the scope of an on-site audit, the exit notice period or the cost of incident assistance.

Subcontracting down the chain

Delegated Regulation (EU) 2025/532, in force since 22 July 2025, specifies what the financial entity must assess when an ICT service supporting a critical or important function is subcontracted. In practice, your client must know and assess your own subcontracting chain: which tiers of subcontracting are allowed, under which conditions, and it must be informed of material changes to those arrangements. A provider unable to describe its chain (hosting provider, managed components, third-line support) blocks its client's analysis, which in practice means repeated document requests and longer contracting timelines.

One answer file, reused for every client

DORA requests from several financial clients cover the same items: every bank or insurer fills in the same register template and must obtain the same clauses. Rather than rebuilding the answers for each request, the provider maintains a single file and draws each client's answers from it: identifying data (LEI code, legal entities), a standardised description of each service with hosting and processing locations, a documented subcontracting chain, an incident management process with notification commitments to the client, proposed audit arrangements (third-party report, pooled audit, on-site audit) and an exit plan. The same information feeds client security questionnaires outside the financial sector, at a higher level of formalisation.

In NIST CSF 2.0, this preparation falls under the GOVERN function (identified as GV in the framework), and more precisely its GV.SC category, dedicated to cybersecurity supply chain risk management: it describes how an organisation identifies its suppliers, puts its security requirements into contracts and monitors compliance with them. The SME provider is itself a supplier in its client's chain, and the Article 30 requirements (security, notification, exit) match the outcomes described by GV.SC and by the PROTECT function (PR), which covers data and access protection measures. Losing a financial client over contractual non-compliance also belongs in the risk register.

The Komplyo assessment measures the maturity of the GOVERN and PROTECT functions, and the generated documents (security policy, incident management process) cover part of what DORA files ask for. The free diagnostic (23 questions, around 5 minutes) gives a first view of these functions.