LX20 Law Firm

Does DORA apply to every ICT provider? Distinguishing roles and client requests

· Redazione LX20 Law Firm

Date: 8 November 2026. Author: Redazione LX20 Law Firm. Publisher: LX20 Law Firm.

Working as a bank's ICT provider does not automatically give the supplier the bank's regulatory role. Understanding DORA's effect requires distinguishing the financial entity, the service supplied and the possible critical-provider oversight regime. Client contractual requests may affect a supplier even when it is not a financial entity subject to the same obligations.

This distinction helps interpret questionnaires and proposed clauses correctly. It does not justify ignoring a request merely because it arrives through a contract. This guide provides a general information approach without determining a particular company's scope or suggesting answers to an authority in a specific case.

Identify the entity and its activity

Regulation (EU) 2022/2554 of 14 December 2022, known as DORA, defines its scope in Article 2. Operating generally in technology or finance is insufficient: compare the entity with relevant categories and exclusions. Source: DORA, Article 2. The commercial name “fintech” does not replace assessment.

Collect information about actual activities, authorisations and group entities involved. A company may offer different services while the examined contract concerns only some of them. Do not assign the parent company's role to every subsidiary or automatically extend the client's classification to a supplier. This reconstruction should precede questionnaire completion.

Understand the service supplied to the client

Describe what the client buys and how it uses it. DORA defines ICT services in Article 3(21). Comparison with that definition requires attention to actual service characteristics. An occasional sale and an ongoing service may present different elements; the contract heading does not resolve the question alone.

Ask which client function the service supports and how it was assessed. Classification as critical or important affects the request framework but should not be inferred from supplier size. Record client information and distinguish what the provider can independently verify from matters belonging to the financial entity's operating model.

Read contractual requests in context

Articles 28 and 30 of DORA concern ICT third-party risk management and key contractual provisions. Source: DORA, Articles 28 and 30. Clients may therefore request information and commitments to manage supplier relationships. This does not turn every questionnaire item into an identical obligation for every participant.

For each request, identify the service concerned and its stated source. If a clause uses broad wording, ask which activity it should cover. If a questionnaire demands a binary answer to a complex situation, prepare a factual explanation rather than an unsupportable yes. An accurate response distinguishes current capabilities, proposed commitments and activities still to be organised.

Do not confuse an important function with a critical provider

A service may support a client's critical or important function without its provider being designated critical under the European oversight regime. DORA Article 31 governs designation. Similar terminology describes different assessments. An internal procurement-register label is not equivalent to European designation.

This distinction prevents opposite errors: claiming oversight status without evidence, or considering contractual requests irrelevant because no designation exists. For each statement, identify its supporting document and the authority or person making it. If the client's meaning is ambiguous, clarify it in the documentary discussion.

Verify what can be declared

Before responding about security, continuity or access, involve people familiar with the service. Certification concerning a different scope should not be treated as universal evidence. An existing plan does not establish that every activity described has already been tested. Record relevant conditions and limits, avoiding commercial wording promising more than has been verified.

Retain questionnaire and answer versions alongside referenced attachments. If a capability changes, assess which earlier declarations need updating. The process should reconstruct who checked facts and which commitments were approved. The purpose is to avoid reusing a response prepared for one relationship outside its context.

A fictional example

A software company receives an intermediary's questionnaire calling it a “critical provider”. Its manager asks whether this means the service's internal importance or European designation. The client clarifies that it concerns its own service classification. The software company retains that explanation and examines clauses within the correct scope.

A later question asks it to confirm a continuity test never performed for that configuration. The provider describes available evidence and the remaining verification point without claiming a nonexistent test. This example is invented and describes no clients or engagements of the Firm. It does not determine whether a particular answer meets obligations in a real relationship.

Keep classification and implementation distinct

Defining the role begins the work. Contracts and procedures consistent with that role must then be assessed. The Bank of Italy DORA communication of 30 December 2024 demonstrates the relevance of organisational issues beyond contractual documents. It is neither general supplier certification nor a substitute for scope analysis.

Carry these boundaries into any internal summary. A confirmed role does not establish that every operational requirement has been met, just as an incomplete document does not determine the entity's classification by itself. Recording which question each conclusion answers makes subsequent review clearer and limits inappropriate reuse of earlier statements.

For the Firm's relevant regulated-sector practice overview, see Fintech, Digital Assets & Web3.