NOTE · 13 OCTOBER 2026

DORA for a company that is not a bank

Who the Digital Operational Resilience Act reaches beyond banks, and what its third-party articles mean for a technology supplier to financial firms.

The Digital Operational Resilience Act is easy to file under banking. The text reaches further than that, in two directions: many kinds of financial firm that are not banks, and the technology companies that supply them. This note reads the regulation from the second chair, the supplier's. The legal analysis of whether and how DORA applies belongs to the firm's own lawyers; what follows is what the text asks engineers to be able to show.

The text and its date

DORA is Regulation (EU) 2022/2554. Unlike a directive it applies directly in every member state, and Article 64 sets 17 January 2025 as the date from which it applies.

Who is in scope

Article 2 lists the financial entities covered. Besides credit institutions, the list includes payment institutions, electronic money institutions, investment firms, crypto-asset service providers, insurance and reinsurance undertakings, crowdfunding service providers and others. A payments start-up or an insurer is as much a DORA firm as a bank, with Article 4 requiring the rules to be applied in proportion to size, risk and complexity.

Where a supplier comes in

A technology company that is none of those things meets DORA through its customers. Article 28 requires financial entities to manage the risk that comes from their ICT third-party service providers and to keep a register of information on every contractual arrangement for ICT services. Article 30 then lists what those contracts must contain, including:

  • a clear description of the services and the locations where data is processed
  • provisions on availability, authenticity, integrity and confidentiality of data
  • assistance when an ICT incident related to the service occurs
  • cooperation with the financial entity's competent authorities
  • termination rights and, for critical or important functions, exit strategies

None of that is a legal obligation on the supplier directly. It arrives as contract clauses, questionnaires and audit requests, and a supplier that cannot answer them quickly becomes harder to buy from.

A small group of providers is treated differently. Article 31 lets the European Supervisory Authorities designate ICT third-party service providers as critical, which brings them under direct oversight. That is a question for large cloud and data providers, not for most software suppliers.

What a supplier can prepare

Most of what a financial customer will ask for already exists in a well run system: where data lives, who can reach it, how incidents are handled, how a restore is proven, how the service would be handed over at exit. The work is to write it down once, keep it current and point to records rather than describe intentions.

We usually start with the service description and the data locations, because every later answer depends on them. Then comes the incident path, written so that a customer's own reporting duties under Article 19 can be met with facts from the supplier's side. The exit plan comes last and is the one most often missing: how the customer would get its data and keep operating if the contract ended tomorrow.

None of this makes a supplier compliant with anything. It makes the supplier easy to assess, which is what a financial firm under DORA needs from it.

SOURCES

Where the facts come from

Talk it through with us

Send a short description of your system and the question this note raised. We reply with how we would approach it in your setup.

Start a conversation