DORA for Suppliers: What ICT Providers to EU Financial Firms Must Do

Most writing about the Digital Operational Resilience Act is aimed at banks and insurers. But DORA’s sharpest practical effect lands somewhere else entirely: on the software companies that sell to them. If a European bank, insurer, payment institution or investment firm uses your product, DORA is already reshaping your contracts — whether or not you have read it.

This is the supplier’s view. What actually reaches you, what your customers are contractually obliged to extract, and what to have ready before the questionnaire arrives.

You are probably not regulated. You are still affected.

DORA applies directly to around twenty categories of EU financial entity. Unless you are one of them, it does not bind you as a matter of law. There is one exception: providers the European Supervisory Authorities formally designate as critical ICT third-party providers come under a direct EU oversight regime. That designation is aimed at hyperscalers and major market infrastructure. It is almost certainly not you.

What reaches you instead is contractual, and it is not optional for your customer. Chapter V of DORA tells financial entities exactly what their ICT contracts must contain. Your customer cannot waive those terms to win your goodwill — their supervisor will ask to see them.

The contract terms your customer must obtain

Article 30 sets out the minimum contents of an ICT services contract. Where the service supports a critical or important function, the list grows considerably. Expect these to appear in redlines, and expect little flexibility:

The register of information

This is the requirement most suppliers meet first, usually without warning. Every financial entity must maintain a register of information covering all contractual arrangements for ICT services, and report it to their competent authority. The technical standards specify the fields, and the granularity surprises people.

Your customer will come to you for data they cannot generate themselves. Have it ready:

• Your legal entity identifier (LEI). If you do not have one, get one — expect to be asked, and expect confusion if you cannot supply it.
• The country of your headquarters and the countries where the service is actually provided from.
• Every country in which Customer Data is stored and processed, including by your own sub-processors.
• Your sub-processors supporting the service, their function and their locations.
• Whether the service supports a function your customer has classified as critical or important — they decide this, but they will ask you to confirm what the service does.
• Contract start and end dates, notice periods and governing law.

A supplier who can return this in a day rather than a fortnight becomes noticeably easier to buy from. It is a low bar and most vendors do not clear it.

Concentration risk, and why you may be asked about your own suppliers

DORA requires financial entities to assess ICT concentration risk — including whether they depend on a provider who is themselves concentrated on a single sub-provider. That question flows down. If your entire platform sits in one cloud region with one provider and no tested alternative, expect that to appear in an assessment, and occasionally in a redline about your exit plan.

You do not need to re-architect for multi-cloud to answer it. You need to be able to describe your dependencies honestly, say what your recovery position is, and show that you have tested it.

Incident reporting: their clock becomes your clock

Financial entities face hard deadlines for reporting major ICT-related incidents to their competent authority — an initial notification, an intermediate report and a final report, on a defined timetable. They cannot meet those deadlines without you.

In practice this means your incident process needs three things it may not have today: a named contact your customer can reach outside business hours, an agreed notification window measured in hours, and enough detail in your early updates for them to classify the incident against DORA’s criteria. “We are investigating” four hours in does not let anyone file anything.

What to build before the questionnaire arrives

• A current sub-processor list with service, entity, country and transfer mechanism — published, not emailed on request.
• A register-of-information data sheet: the fields above, maintained as a document you can send, not assembled each time.
• An exit and transition plan: what data comes back, in what format, over what period, and who helps.
• Incident notification commitments in your contract template, with hours rather than "promptly", and an out-of-hours route.
• Evidence that you test recovery — a date, a scope and an outcome. Not a policy saying you intend to.
• A resilience testing position: what you run, how often, and what you will share with a customer under NDA.

Which of your customers are actually in scope

Worth knowing, because it tells you which accounts will raise this and which will not. DORA applies to a defined list of EU financial entities, and it is broader than “banks”:

• Credit institutions, payment institutions and electronic money institutions.
• Investment firms, crypto-asset service providers and account information service providers.
• Insurance and reinsurance undertakings, and insurance intermediaries.
• Institutions for occupational retirement provision, above size thresholds.
• Central securities depositories, central counterparties, trading venues and trade repositories.
• Credit rating agencies, administrators of critical benchmarks and crowdfunding service providers.
• Managers of alternative investment funds and UCITS management companies.

There is a proportionality principle: microenterprises and certain small entities face a simplified regime. But the register of information and the contractual requirements apply widely, so a small EU fintech will still come to you with the same questions a large bank does — usually with less patience for a slow answer, because they have fewer people to chase it.

“Critical or important function” — the phrase that changes everything

Nearly every heavier obligation in Chapter V hinges on whether your service supports a critical or important function. Understand two things about that determination.

First, your customer makes it, not you. It is their assessment of their own operations: a function whose disruption would materially impair their financial performance, the soundness or continuity of their services, or their ability to meet regulatory obligations.

Second, the classification can surprise you. Teams assume it means core banking. In practice a fraud-screening tool, an identity-verification service, a customer-communications platform or a regulatory-reporting integration can all land in scope, because their failure stops the entity meeting an obligation. If you sell any of those, assume you are in the heavier tier and prepare accordingly.

What changes when you are: exit strategies become mandatory rather than advisable, audit and access rights must be unrestricted, your sub-contracting of that service is constrained, and the entity must be able to demonstrate it can transition away from you without operational damage.

Sub-contracting: the rules that flow to your suppliers

Where you support a critical or important function, your own sub-contracting comes under conditions. Financial entities must be able to see the chain and must retain the right to object to changes in it.

Practically, this means three things you should sort before a redline forces you to:

• Maintain a genuine sub-processor register — legal entity, service provided, country of processing, and where they sit in the chain. Not a marketing page listing four logos.
• Give meaningful advance notice of changes, with a stated period. Thirty days is common; some contracts push for more where the function is critical.
• Flow the relevant obligations down. If your customer needs audit rights that reach your sub-processor, your contract with that sub-processor has to permit it — retrofitting that is slow and occasionally impossible.
• Know which sub-processors are load-bearing. A customer assessing concentration risk will want to know whether your whole platform rests on one provider in one region.

Put it in your standard terms

The slowest path is negotiating each DORA clause fresh with every financial customer. The fastest is having a DORA-aware addendum ready that you offer before they ask.

It costs a few thousand pounds of legal time once. It removes weeks from every subsequent financial-services deal, and it signals competence at exactly the moment a procurement team is deciding whether a company your size is a safe bet. Cover, at minimum: audit and access rights, sub-contracting notice and objection, incident notification windows, exit and transition assistance, data location and portability, service levels, and termination triggers including supervisory instruction.

Where you cannot accept something — genuinely unrestricted on-site audit rights are hard for a small SaaS company to grant to every customer — offer the alternative rather than refusing. Pooled audits, a third-party assurance report, or an annual audit window are all recognised approaches, and DORA anticipates them.

The commercial read

DORA is usually framed as a burden on suppliers. For a small vendor it is closer to the opposite. The requirements are documentation-heavy and mostly static — a sub-processor list, an exit plan, defined notification windows, tested recovery. Large incumbents move slowly on contract terms. A 40-person company that can return a complete register-of-information sheet the same week, with audit rights already in its standard terms, removes the single biggest reason a bank’s procurement team defaults to the incumbent.

The work is real but it is finite, and most of it is writing down things you already do.