DORA for ICT suppliers: what your banking clients will ask you for

This article explains how the rules work in practice. It is not legal advice. For contract wording, talk to a lawyer.

What DORA is, and why a supplier should care

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It covers banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and other financial entities in the EU.

Most ICT suppliers are not regulated by DORA themselves. A small group of providers that the European Supervisory Authorities designate as critical get direct oversight. Everyone else is affected indirectly, through contracts.

Under DORA, the financial entity stays fully responsible for the services it outsources. So it has to know who you are, what you do for it, and whether you can be trusted with it. That is why a software vendor, a hosting company or a DevOps contractor that has never heard of DORA may suddenly receive a 40-page questionnaire and a contract addendum.

The register of information

Article 28(3) requires each financial entity to keep a register of information on all its contractual arrangements for ICT services from third-party providers. The format is fixed by implementing technical standards (Commission Implementing Regulation (EU) 2024/2956).

The entity reports the register to its competent authority every year, and must make it available on request. For you, as a supplier, that means your client needs accurate data about you:

• your legal entity and identifiers, such as an LEI;
• which ICT services you provide, and which of the client’s business functions they support;
• where the services are provided and where data is stored and processed;
• for services that support critical or important functions, the chain of subcontractors that actually underpin them.

The last point matters. If your service runs on a cloud provider, uses an outsourced support desk or relies on another vendor’s platform, your client may need to see that chain. Keep an up-to-date list of the subcontractors involved in delivering each service.

Contract clauses that flow down to you

Articles 28 to 30 set out what the contract between the financial entity and its ICT provider must contain. Your client cannot simply drop these clauses. Expect them in new contracts and in addenda to existing ones.

For every ICT service (Article 30(2))

• A clear and complete description of the functions and services you provide.
• The locations (regions or countries) where you deliver the services and where data is processed and stored, and a duty to tell the client in advance before you change them.
• Provisions on availability, authenticity, integrity and confidentiality of data, including personal data.
• Ensuring access, recovery and return of data in an easily accessible format if you go insolvent, the service ends or the contract is terminated.
• Service level descriptions, including how they are updated.
• A duty to assist the client when an ICT incident related to your service occurs, at no extra cost or at a cost agreed in advance.
• A duty to cooperate fully with the competent authorities and resolution authorities, including people they appoint.
• Termination rights and minimum notice periods. Article 28(7) lists situations in which the client must be able to end the contract, for example a significant breach of law or contract, or weaknesses in how you manage ICT risk.
• Conditions for your participation in the client’s ICT security awareness programmes and operational resilience training.

For critical or important functions (Article 30(3))

If your service supports a function whose disruption would materially harm the client’s business or its regulatory compliance, the contract must also include:

• full service level descriptions with precise quantitative and qualitative performance targets;
• notice periods and reporting duties, including notifying the client of any development that could materially affect your ability to deliver;
• a duty to implement and test business contingency plans, and to have appropriate ICT security measures, tools and policies;
• a duty to participate and cooperate in the client’s threat-led penetration testing (TLPT) when it is in scope;
• the client’s right to monitor your performance, with unrestricted rights of access, inspection and audit for the client, an appointed third party and the competent authority;
• exit strategies, including a mandatory, adequate transition period.

Article 29 also asks the client to assess concentration risk and to weigh how much your service depends on long or complex subcontracting chains. Further technical standards describe the client’s policy for these contracts and the conditions for subcontracting critical services.

What the questionnaire really asks for

Contract clauses are promises. Questionnaires and audits ask you to show that you can keep them. Because they follow the same articles, the questions tend to cluster around the same few topics. A supplier that prepares an evidence pack in advance answers faster and more consistently.

1. Access control. Who has access to production and to client data, how access is granted and removed, whether MFA is enforced, and how privileged and service accounts are managed. Evidence: an access list, a joiner/leaver procedure, the last access review.
2. Logging and monitoring. What is logged, where logs are kept, for how long, and who looks at alerts. Evidence: a short description of the logging setup and an example of an alert being handled.
3. Backups and disaster recovery. Backup frequency, where backups are stored, whether they are encrypted, and above all when you last restored one. Evidence: a backup policy and a dated restore test with its result.
4. Incident handling. How you detect, classify and escalate incidents, and how quickly you would inform the client. DORA gives financial entities tight incident reporting deadlines, so they need your input fast. Evidence: an incident procedure, contact points and a past incident report or exercise.
5. Change management. How changes reach production, who reviews them, and whether you can roll back. Evidence: a description of the pipeline, review rules and an example change record.
6. Vulnerability and patch management. How you find and fix vulnerabilities in your code, dependencies and servers. Evidence: scan reports and patch timelines.
7. Exit plan. How the client gets its data back and moves to another provider, how long it takes, and what help you give during the transition. Evidence: a written exit plan per service.
8. Subcontractors and locations. Who else is involved in delivering the service and where data lives. Evidence: a subcontractor list with services, locations and the data each one handles.

None of this needs to be a thick binder. A dozen short, accurate documents with dates on them beat a generic policy set. What supervisors and auditors look for is proof that the control runs: a restore log, an access review record, a merged pull request with a review.

Common mistakes

• Promising what you do not do. Signing an addendum with audit rights or a four-hour incident notice you cannot meet creates a contractual problem later. Read the clauses with your engineers, not only with sales.
• Forgetting your own suppliers. Your hosting, monitoring and support providers are part of the chain. Your client may ask about them.
• One answer per client. Ten banks will send ten questionnaires. Keep one maintained evidence pack and adapt it, so your answers stay consistent.
• No restore test. “We have backups” is the most common answer and the weakest one. A dated, successful restore is what convinces.

Where to start

Pick one service you deliver to a financial client. Write down its description, locations, subcontractors and the data it touches. Then check each item of the evidence list above and mark what you can show today. The gaps become your plan.

If you want help, our DORA readiness for ICT suppliers engagement does exactly this and closes the technical gaps with you. If you first need an honest view of your servers and access, start with an infrastructure security audit.