The DORA regulation has applied to EU banks, insurers and other financial entities since 17 January 2025, and it makes one thing very clear: responsibility cannot be outsourced. If an external IT provider fails, the financial entity is responsible for keeping its operations running. Most of the work comes from supplier relationships: a register of every IT contract, a risk assessment before signing, mandatory contract clauses and, for critical functions, a tested exit plan. In this article I show what this means in practice, what to ask of your suppliers, and where it most often goes wrong.
In brief
- DORA (the Digital Operational Resilience Act) is Regulation (EU) 2022/2554. It entered into force on 16 January 2023 and, after a two-year preparation period, has applied since 17 January 2025.
- External IT providers are covered by Articles 28–30: a register of information, a risk assessment before contracting, mandatory contract clauses and an exit strategy.
- For services supporting critical or important functions, exit plans must be documented, tested and reviewed periodically.
- The rules apply regardless of supplier size: to the large cloud provider and to the small development firm alike.
- The most common mistake is treating DORA preparation as a legal exercise. An exit plan is really a matter of knowledge transfer and capacity.
As a former CIO, I see the same pattern in many places: the compliance team reviews the contracts, adds the mandatory clauses and considers the job done. But the regulation does not ask for paperwork. It asks that you can keep operating after a supplier fails, and only the IT organisation can guarantee that, not the contract.
What does the DORA regulation expect regarding external IT providers?
DORA covers five areas: ICT risk management, the handling and reporting of ICT-related incidents, digital operational resilience testing, the management of ICT third-party risk, and information sharing. The third-party part brings the most practical change, because it affects every IT supplier contract, from the large cloud provider to the two-person development firm.
The principle is simple: the financial entity remains fully responsible for complying with the regulation even when an external company does the work. A supplier can take over the work, but not the responsibility.
Four obligations that affect every supplier relationship
1. A register of every IT contract. Under Article 28(3), the financial entity must maintain and keep up to date a register of information on all contractual arrangements for ICT services. It must report to the supervisor at least yearly on the number and nature of new arrangements, and inform it in a timely manner about planned arrangements supporting critical or important functions. For many firms this is the first real inventory: it is when they discover how many smaller contracts, licences and “temporary” solutions are running in the background.
2. A risk assessment before signing. Under Article 28(4), before entering into a contract the entity must assess whether the service supports a critical or important function and what risks it carries (including concentration risk), carry out due diligence on the prospective provider, and identify any conflicts of interest. This cannot be done after the fact; it has to be part of the procurement process.
3. Mandatory contract clauses. Article 30 sets a baseline for every ICT contract: a clear description of the service and whether subcontracting is allowed, the locations where services are provided and data is processed, data protection and the return of data when the contract ends, assistance with ICT incidents, cooperation with the authorities, termination rights, and participation in security awareness training. Critical or important functions need more: quantitative service levels (SLAs), notice periods and reporting obligations, a tested business contingency plan, participation in threat-led penetration testing (TLPT), unrestricted rights of access and audit, and an exit strategy with a mandatory transition period.
4. A tested exit plan. Under Article 28(8), services supporting critical or important functions require an exit strategy, and exit plans must be comprehensive, documented, sufficiently tested and reviewed periodically. I touched on this briefly in IT contractors or in-house developers. Here we look at why it is the hardest part.
The typical mistake – an exit plan that exists only on paper
Most exit plans read something like this: “on termination, the provider will support the transition for six months and hand over the documentation”. That is a contract clause, not an exit plan.
A real exit plan answers three questions:
- Who takes over the work? Another provider, your own team, or retiring the system? Do you have the capacity and knowledge in-house today?
- What needs to be handed over? Source code, operating procedures, access rights, data and, most often missing, the knowledge in people's heads about why the system works the way it does.
- How long will it take? Realistically, not the number in the contract. If only one supplier knows an application close to your core system, a six-month transition is often not enough.
The word “tested” is the key. Testing does not mean someone rereads the plan. At the very least you need a tabletop exercise where you walk through who would do what tomorrow morning if the supplier disappeared. That is usually when it turns out that some access rights are registered to the supplier, or that the documentation is two versions behind.
As a CIO, I saw the greatest risk not in the large, well-known providers, but in old, custom-built systems that the same small team has kept alive for years. There, the exit plan is really a knowledge-transfer project, and it should not start when the contract is terminated. I wrote more about the dilemmas of legacy systems here: when NOT to modernise your legacy system.
Concentration risk: when everyone relies on the same provider
DORA also looks at whether a financial entity relies too heavily on a single supplier, or whether the whole sector depends on the same providers. That is why it introduced EU-level oversight of critical ICT third-party service providers (CTPPs). The list of providers designated by the European Supervisory Authorities contains 19 companies, including the European entities of AWS, Google Cloud, Microsoft, Oracle, SAP and IBM (EBA: DORA oversight).
This does not take the burden off the financial entity. Your cloud provider may be supervised at EU level, but your own exit plan and your own concentration risk are still yours to manage.
What should you ask of your suppliers?
DORA places the obligations on the financial entity, but meeting them requires the supplier too. A well-prepared IT supplier accepts and can provide the following:
- a precise list of the locations where the service is provided and data is processed, with advance notice of any change;
- a list of subcontractors involved in services supporting critical functions;
- immediate notification and assistance in the event of an incident, on terms agreed in advance;
- access and audit rights for you, for an auditor you appoint and for the supervisor;
- up-to-date documentation that can be handed over: architecture, operating procedures, a list of access rights;
- participation in business continuity and exit tests, and in security training;
- a committed, adequate transition period during which the service continues unchanged.
If a supplier is reluctant to accept several of these, that in itself is important input for your risk assessment.
Decision framework: how much work does a supplier need?
| Question | If yes | If no |
|---|---|---|
| Does it support a critical or important function? | The full Article 30(3) package: SLAs, audit rights, a tested exit plan | The baseline clauses of Article 30(2) |
| Does only one supplier know the system? | A knowledge-transfer plan now, not at termination | A documented handover process is enough |
| Does it use subcontractors for a critical function? | The subcontracting chain must also be assessed and recorded | – |
| Are several critical services with the same provider? | Analyse concentration risk and assess alternatives | – |
Where to start, and when not to start with the contracts
If you do not yet have an up-to-date list of which business functions are critical or important, rewriting contracts is premature. In the reverse order, a firm either treats every contract as critical and drowns in administration, or misses exactly the relationships that matter. The order that works:
- Classify your business functions: which are critical or important.
- Map the systems and the suppliers behind them.
- Populate the register and look for concentration.
- Add the missing contract clauses for critical relationships.
- Write and test the exit plans, starting where in-house knowledge is weakest.
What we do differently at FrontX
- We know both sides. Our team members have worked at financial institutions on the client side, and today we work as a supplier to financial institutions. We know what a supplier must provide so that the client's DORA compliance is more than paperwork.
- Documentation and knowledge transfer are part of the work. They are not an extra task at the end of the contract; they are delivered together with the work.
- We provide a transparent team. With our IT team augmentation and contracting service, you know by name who works on your system, and your in-house team learns from them.
- With old systems, we start by uncovering the knowledge. The first step of our legacy modernisation and support service is to assess and document the system, so that how it works is not held in one or two people's heads.
If you would like to check how realistic the exit plan for a critical supplier really is, we are happy to help you map where the biggest risk lies: request a free consultation.
Frequently asked questions
Who does the DORA regulation apply to?
EU financial entities, including banks, insurers, investment firms, payment institutions and electronic money institutions. Microenterprises and some smaller players are subject to simplified rules. External IT providers are affected through their contracts, and designated critical providers are also subject to direct EU-level oversight.
Since when has DORA applied?
It entered into force on 16 January 2023 and has applied since 17 January 2025. Since then, registers, contracts and exit plans must comply with the regulation.
What counts as a critical or important function?
A function whose disruption or defective performance would materially impair the financial entity's financial performance, the soundness or continuity of its services, or its continued regulatory compliance. The financial entity makes the classification, and it determines which supplier contracts are subject to the stricter requirements.
Do small suppliers need an exit plan too?
Yes, if the supplier provides a service supporting a critical or important function. The exit plan must be prepared by the financial entity, regardless of the supplier's size. With small suppliers it is often even more important, because fewer people hold the knowledge.
What is the difference between DORA and NIS2?
NIS2 is a general, cross-sector cybersecurity directive that member states transpose into their own laws. DORA is a regulation tailored to the financial sector and applies directly. For financial entities DORA is the specific rule, so it takes precedence in the areas it covers.
László Behán is Managing Director and Co-Founder of FrontX Kft. He was previously CIO of Signal Insurance, Head of Development and Data Warehouse at Groupama Insurance, and Operations Director and board member at LeasePlan Hungaria. He has 20 years of IT and business leadership experience in financial services. LinkedIn profile
