Why it reaches you
The Digital Operational Resilience Act, known as DORA, is an EU regulation that has applied to financial entities since 17 January 2025. Banks, insurers, payment and e-money firms, investment firms and asset managers are in scope. Their suppliers are not.
What the regulation does is make those firms answerable for the resilience of the information and communication technology (ICT) services they depend on. "Our vendor handles that" is no longer an answer their supervisor accepts. Since they cannot regulate you, they push the obligation down the only channel they have, which is your agreement with them.
This is why the tone of the relationship changed without anything about your product changing. And it is worth being clear about what you are exposed to. The fines in DORA land on the regulated firm, not on you. Your exposure is a deal that sits in procurement for two months because you cannot sign what they need signed.
The contract clauses
Article 30 of DORA lists what has to be in every agreement for ICT services. When the redline arrives, your customer's lawyers are not being difficult. They are copying that list.
For any ICT service, the agreement has to cover:
- a full description of the service, including where it is provided and where data is processed
- service levels
- availability, integrity, security and protection of personal data
- access to and return of their data if you become insolvent or stop the service
- your help during an incident, at no extra cost or at a price agreed in advance
- cooperation with their supervisor
- termination rights and notice periods
If your service supports what they call a critical or important function, four more are added: performance targets with agreed corrective action, notice of anything that could materially affect your service, tested contingency plans, and rights of access, inspection and audit for them, for an auditor they appoint, and for their regulator.
That last one is usually the shock. Most software companies have never given a customer the right to inspect them, let alone a supervisor they have never met. Holding ISO 27001 does not remove it, because the right has to exist in the contract whether or not anyone ever uses it.
What you can shape is how it works:
- Notice periods. How much warning before an audit.
- Frequency. How often, and what triggers an extra one.
- Pooled audits. Several customers sending one auditor instead of each sending their own.
- Existing reports. Accepting your certificate or test results where they answer the question.
Raise those early. Asking after legal has escalated is a much slower conversation.
The register
Every financial entity has to keep a register of information. That is a structured inventory of every contract it has for ICT services, filed with its supervisor once a year. The format is fixed by Implementing Regulation (EU) 2024/2956, which is why the questions feel like a form. They are a form.
You are one row in it. Your customer has to record, among other things:
- your legal name, your LEI, your head office country and your ultimate parent company
- the type of ICT service you provide, chosen from a fixed list
- which of their functions your service supports, and whether that function is critical or important
- the countries where data is stored and where it is processed
- what they spend with you each year, and your contract dates
- how easily you could be replaced, whether an exit plan exists, and when you were last audited
If your service supports a critical or important function, your own subcontractors go in too, each one recorded by where it sits in the chain.
Two things follow from that. The first is to get an LEI if you do not have one, because providers outside the European Union can only be identified in the register that way, and a customer who cannot complete your row has a deadline problem with your name on it. Applying takes a few days and a small fee.
Second, this comes round every year at about the same time. The current cycle uses a reference date of 31 December 2025, and filing windows run in the first quarter. They differ by country, so ask your customer when theirs falls and put it in your calendar.
The incident clock
When a financial entity has a major ICT incident, it has very little time. Under Delegated Regulation (EU) 2025/301, the first notification is due within four hours of classifying the incident as major, and in any case no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours, and a final report within a month of the last intermediate one.
Read that first deadline again, because the consequence for you sits inside it. They cannot classify an incident they do not know about. If the problem is in your system and you take a working day to say so, you have used their entire window before they could start.
So the notification commitment in your contract will be written in hours. Vague wording in your favour tends to cost you more in procurement time than it ever saves you at three in the morning. The more useful negotiation is about what a first notification has to contain. Agree that it can be two lines, that it can say you are investigating and do not yet know the scope, and that detail follows as you learn it. That is a promise an on-call engineer can actually keep.
Exit and concentration
Your customer has to hold an exit strategy for you. Not because they expect you to fail, but because they have to be able to leave without their own service falling over. In practice that means a transition period where you keep the service running, and a realistic route to another provider or to doing it in-house.
So they will ask how data comes out, in what format, how long an extraction takes, and what help you give during a migration. They will also ask what you run on underneath, because they have to look at concentration: whether too much of their estate, through too many suppliers, rests on the same provider.
Saying you run on a major cloud provider is a perfectly good answer. Declining to say is not, and it reads worse than the answer you were protecting.
Subcontractors
Can you change one quietly? No.
Delegated Regulation (EU) 2025/532 covers subcontracting where the service supports a critical or important function. The contract has to state which parts may be subcontracted at all. You stay responsible for what your subcontractors do. You have to tell your customer about intended material changes in good time, with enough notice for them to assess the change and object. If you make a material change they have not approved, or subcontract something the contract never allowed, they can terminate.
For a team used to swapping an infrastructure component over a weekend, this is the requirement that changes how you work rather than what you file. Put the notification step into your vendor change process now, while it is a process question. It is a much worse conversation once it is a breach.
One note on the other end of the chain. Some very large providers are designated as critical ICT third-party providers and supervised directly, with the first designations announced by the European Supervisory Authorities on 18 November 2025. That list changes over time and, unless you operate at that scale, it does not apply to you. It does explain why questions about who you depend on have become sharper.
Do's and don'ts
| Do | Don't |
|---|---|
| Ask which of their functions your service supports, because that decides how heavy the contract gets | Promise a notification time your on-call rota cannot meet |
| Get an LEI before anyone asks for it | Change a subcontractor without telling regulated customers first |
| Negotiate how audit rights are exercised, not whether they exist | Assume a certificate answers the whole questionnaire |
| Write down your exit and data extraction process before you are asked under time pressure | Refuse to name what you run on, because it reads as a bigger problem than it is |
Where to start
If you already hold ISO 27001, you are most of the way there on substance. Risk management, incident handling, access control, continuity and the supplier controls all map across, and your certificate with a Statement of Applicability will answer a fair share of any questionnaire. What it does not give you is the LEI, the register fields, contractual audit rights for a supervisor, notification measured in hours, the exit detail or the subcontractor notice. Those are contract and process work, and they are the parts that hold up signature.
Start with the asset side, because everything else reads off it. You need a current list of what you run and where, including which third parties hold customer data and in which countries, with a named person owning each entry rather than a team.
Then make sure your incident process can produce a first notification within hours, with an out-of-hours route somebody has actually tested. The rest is three short documents. A description of exit and data extraction, covering format, timescale and the support you provide. A subcontractor list with locations, plus a change process that tells regulated customers before a change happens. And an LEI.
The companies that close these deals quickly are not the ones with the most certificates. They are the ones who can answer the questionnaire in a week.
What's next?
DORA is not the only regulation that lands on you through somebody else's obligations. NIS-2 works the same way, and if you supply anyone in energy, transport, health, water, manufacturing or IT services, the same style of questionnaire is already on its way: see how to tell in 20 minutes whether NIS-2 applies to you. And if you are starting from nothing rather than tightening what you have, the first steps in setting up your ISMS is the cheaper order to do the work in.