Summary · cheatsheet · DORA / ICT provider
ICT provider · Regulation (EU) 2022/2554 · the obligations usually arise not from the regulation but from the contract under Article 30 · print as PDF
Obligations of an ICT provider
An overview for a provider that has received a DORA contract addendum from a bank, an insurer or a payment institution: what has to be in it, what happens in an audit and in the register of information, and what can be negotiated.
An ICT third-party service provider is, under Article 3(19), any undertaking providing ICT services; the service itself is defined just as broadly in Article 3(21) — digital and data services provided through ICT systems on an ongoing basis, including hardware as a service and its support through updates. The only express carve-out is traditional analogue telephone services. There is no size threshold: a three-person software house is an ICT provider just as much as a hyperscaler. Direct obligations under the regulation usually do not arise for you — they arise from the contract, because without them the financial entity is not allowed to sign.
A full description of the functions and services, stating whether subcontracting is permitted. The specific regions or countries where the service is provided and where data is processed and stored, plus an obligation to give advance notice of any planned change of those locations. Provisions on data protection. Ensuring access, recovery and return of data in an easily accessible format on insolvency, discontinuation of business or termination of the contract. Service level descriptions. Assistance with an ICT incident at no additional cost, or at a cost determined ex ante. Cooperation with the authorities. Termination rights and minimum notice periods. Participation in digital operational resilience training.
Whether your service supports a critical or important function (Article 3(22)) is decided by the financial entity — you can tell from how hard the addendum bites. What is added then: full service level descriptions with quantitative performance targets, an obligation to report any development that could affect your ability to provide the service, an obligation to implement and test business contingency plans, an obligation to take part in the customer's TLPT (Articles 26 and 27) and an exit strategy with an adequate transition period during which you keep providing the service.
Unrestricted rights of access, inspection and audit belong to the financial entity, to a third party it appoints and to the competent authority, including taking copies of documentation on site. Under Article 30(3)(e)(i) their exercise must not be impeded by other contractual arrangements or by your own internal policies — an "audits only under our audit policy" clause will not pass. Two things can be negotiated: Article 30(4) provides for standard contractual clauses developed by public authorities, and where the customer is a microenterprise the audit may be carried out by an independent third party appointed by you.
Under Article 28(3) the financial entity keeps a register of all contractual arrangements on the use of ICT services; the format comes from Implementing Regulation 2024/2956 — fifteen interlinked templates. It will ask you for an LEI code (without it the return will not go through; the alternative is an EUID), the classification of the service under the S01 to S19 typology, the countries of provision and of data storage, and a list of subcontractors. A direct provider has rank 1, a subcontractor a higher one; the standard sets no fixed number of layers. The ones reported are those that actually provide services supporting critical or important functions (Article 3(2)).
The European Supervisory Authorities (EBA, EIOPA, ESMA) designate, through their Joint Committee, the providers that are critical for financial entities and appoint a Lead Overseer for each of them. The criteria are in Article 31(2) and are specified further by Regulation 2024/1502: the systemic impact of a large-scale outage, the systemic character of the entities that depend on the provider, the degree of reliance for critical functions and substitutability. The inputs come from the registers of information. The list is published and updated yearly; the first one came out on 18 Nov 2025. For a Czech software house this is out of reach; anyone who wants to be on the list can apply for it (Article 31(11)).
The financial entity uses them to meet Article 28(4) and (5): before contracting it has to assess the risks of the arrangement including the aggravation of ICT concentration risk, carry out due diligence and verify that you meet the appropriate information security standards. There is one defence — build one set of your own documentation (scope of the service, architecture, controls, incident response plan, test results, subcontractors with countries) and answer the questionnaires from it. Otherwise you answer everyone separately and after a few dozen rounds you contradict yourself.
Direct penalties are narrow: under Section 19 of Act No. 31/2025 Coll. it is an offence not to cooperate with the Czech National Bank in its supervision under Article 50(2) — a fine of up to CZK 10,000,000. For a critical provider, failing to cooperate with the Lead Overseer is an offence as well and the fine goes up to CZK 20,000,000; on top of that a critical provider faces periodic penalty payments of up to 1 % of its average daily worldwide turnover, imposed daily for up to six months (Article 35(6) to (8)). The commercial risk matters more: without the provisions of Article 30 a financial entity is not allowed to sign with you and, under Article 28(7), it has to be able to terminate.
We can help with the implementation
We will assess your situation against DORA, prepare the inputs for the register of information, rehearse an incident report with you or go through the contract addendum from your bank. The consultation is non-binding.