If you sell software, hosting or managed services to banks, insurers, investment firms or payment companies in the EU, a DORA request has probably reached you already. It arrives as a questionnaire, a contract addendum, or a request for data you have never been asked to supply in that shape.
The confusing part is that the regulation was not written with you as its main audience. DORA places its obligations on financial entities. It reaches most ICT providers indirectly, through what those entities must demand of their suppliers, and directly only for a narrow group of providers designated as critical.
This article explains what DORA is, who it binds, the four routes by which its requirements travel to a provider, and what you can prepare once instead of answering from scratch for every customer.
What DORA is and when it started applying
The Digital Operational Resilience Act is Regulation (EU) 2022/2554. It entered into force in January 2023 and has applied since 17 January 2025. Because it is a regulation rather than a directive, it applies directly in every member state. There is no national transposition step, so the text is the same wherever your customer is supervised.
Its purpose is to make sure financial entities can withstand, respond to and recover from ICT-related disruption. Before DORA, ICT risk rules for finance were spread across sector guidelines and national supervisory practice. DORA brings them into one text. Regulatory and implementing technical standards, adopted by the European Commission on drafts from the European Supervisory Authorities, fill in the detail.
The regulation is organized around five areas:
ICT risk management. A documented framework covering identification, protection, detection, response, recovery and learning, with the management body accountable for it.
ICT-related incident management and reporting. A process to detect, classify and report major ICT-related incidents to the competent authority.
Digital operational resilience testing. A risk-based testing program and, for entities selected by their supervisors, threat-led penetration testing.
ICT third-party risk. Rules on how financial entities assess, contract with, monitor and exit ICT providers, plus an EU oversight framework for critical providers.
Information sharing. Voluntary arrangements for exchanging cyber threat intelligence among financial entities.
Who DORA binds directly
Article 2 lists the entities in scope. The list is long: credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, insurance and reinsurance undertakings, fund managers, credit rating agencies, crowdfunding service providers and others. Some categories, such as smaller insurance intermediaries, are carved out.
Article 2 also names ICT third-party service providers. That does not mean every provider carries the financial entities' obligations. The provisions aimed at providers themselves sit mainly in the oversight framework for critical providers, covered below.
DORA applies proportionately. Article 4 requires financial entities to implement it in line with their size, overall risk profile, and the nature, scale and complexity of their services. Some smaller entities follow a simplified ICT risk management framework. The practical effect for you is that a large bank and a small payment institution may ask for different depth, even under the same law.
The term that decides how much you will be asked
DORA defines ICT services broadly: digital and data services provided through ICT systems to internal or external users on an ongoing basis. Most hosting, SaaS, managed service, data and security products sold to financial entities fall within it. Whether a particular service does is your customer's call to make.
The term that drives the depth of scrutiny is critical or important function. A function is critical or important when its disruption would materially impair the entity's financial performance, the soundness or continuity of its services, or its continued compliance with its authorization and other financial services obligations.
If your service supports such a function, expect the longer contract clause list, closer monitoring, exit planning, and possible inclusion in testing. If it does not, the baseline requirements still apply, but the conversation is shorter. Ask your customer which category they have placed you in. It saves both sides from negotiating terms that do not apply.
Four routes by which DORA reaches you
The contract
Article 30 sets terms that every contract for ICT services must contain, and a longer list for services supporting critical or important functions. The baseline covers service descriptions, data processing locations, data protection, access to and return of data, service levels, incident assistance, cooperation with authorities, termination rights and participation in security awareness training. The longer list adds precise performance targets, notice obligations, continuity testing, participation in threat-led testing, audit and access rights, and an exit transition period.
The register of information
Every in-scope financial entity keeps a register of all its contractual arrangements for ICT services and reports it to its competent authority. Your customer needs accurate data about you to complete it: your legal entity details, the services you provide, the functions they support, where you process data, and, for critical or important functions, the subcontractors that support the service.
Incident management
Financial entities must classify major ICT-related incidents and report them to their competent authority on deadlines set in the technical standards, with the first notification due within hours. If an incident at your company affects their service, they need facts from you fast enough to meet their own clock. Article 30 requires the contract to commit you to assistance when an incident related to your service occurs, at no additional cost or at a cost determined in advance.
Testing
Financial entities must test the ICT systems and applications that support critical or important functions at least yearly. Entities selected by their supervisors must also run threat-led penetration tests on live production systems, and those tests can include a provider's systems in scope. DORA expects you to participate when that happens.
The direct regime for critical providers
DORA creates a direct oversight regime for a narrow group of providers. The European Supervisory Authorities (the EBA, EIOPA and ESMA) designate ICT third-party service providers as critical, using criteria such as the systemic impact of a provider's failure, the importance of the financial entities that rely on it, and how hard it would be to substitute.
Each designated provider is assigned a Lead Overseer, one of the three authorities. The Lead Overseer can request information, conduct investigations and inspections, and issue recommendations. Financial entities may only use a designated provider established outside the EU if it sets up a subsidiary in the Union within 12 months of designation.
Most providers will never be designated. The criteria point at providers whose failure would affect the financial system, not at a typical vendor serving a handful of banks. Plan around the indirect routes unless you have a specific reason to think otherwise.
What to prepare before the next request
The requests are predictable, so the answers can be prepared once and kept current. A provider selling to EU financial entities should be able to hand over the following without a scramble:
- Not done:
Entity data. Legal name, registered address and a legal entity identifier, which register templates ask providers to supply.
- Not done:
Service catalog. A plain description of each service, so customers can map it to their functions.
- Not done:
Locations. Where you provide each service and where you store and process data, plus how you notify customers before a change.
- Not done:
Subcontractor chain. Which subcontractors support each service, what they do, and where they do it.
- Not done:
Incident commitments. How quickly you notify customers, what the notice contains, and who their contact is.
- Not done:
Continuity and exit. Tested continuity plans, data return formats, and the transition support you can offer a departing customer.
- Not done:
Assurance. Current audit reports or certificates, penetration test summaries, and a position on customer audit rights.
- Not done:
A standard DORA addendum. Your own version of the Article 30 terms, reviewed in advance, so negotiations start from your text.
Existing assurance helps but does not close the question. A SOC 2 report or an ISO 27001 certificate answers many control questions, and if you run an information security management system much of the underlying discipline is already in place. Your customers will still need DORA-specific contract terms and register data, which no audit report supplies.
Some providers face a second regime. Cloud, data center and managed service providers may fall directly under NIS2 in their own right, separate from anything their financial customers require. Our DORA framework page summarizes the regulation's structure. How DORA applies to your specific contracts and services is a question to confirm with counsel.
How TrustLynce helps
TrustLynce keeps your own vendor and subcontractor inventory, risk tiers and reviews in one place through third-party risk management, so register data is ready when a customer asks. Control mapping lets you reuse SOC 2 and ISO 27001 evidence against DORA questions, and the Trust Center shares assurance documents behind gated access with an access log.