DORA for a technology supplier to financial entities
DORA applies to banks and insurers, but its contractual and oversight provisions reach their ICT providers directly. What changes in your contracts, your exit plans and your incident reporting if your customers are regulated.
The Digital Operational Resilience Act has applied across the EU since 17 January 2025. It is aimed at financial entities — banks, insurers, investment firms, payment institutions, crypto-asset service providers and about fifteen other categories — but a large part of its text is about their suppliers.
If you sell software or infrastructure to a financial entity, DORA arrives at your door in two forms: contract clauses your customers are now required to impose, and, for a small number of providers, direct oversight by the European Supervisory Authorities.
The five pillars, briefly
DORA organises requirements into ICT risk management, incident reporting, digital operational resilience testing, third-party risk management, and information sharing. For a supplier, the second and fourth are where the pressure lands.
Incident reporting follows a defined timeline for major ICT-related incidents: an initial notification, an intermediate report, and a final report, with the regulatory technical standards setting the specific windows. The financial entity reports to its regulator, but it cannot do so without you — which means your contract will specify how fast you must notify them. Expect to be asked for notification within hours, because their own clock starts when they become aware.
Third-party risk management requires the financial entity to maintain a register of information about every ICT contract, assess concentration risk, and ensure specific clauses are in every contract. This is the part that shows up in your renewals.
What your contracts will now contain
Article 30 sets out mandatory contractual provisions. Expect your next renewal with a financial customer to require:
- A full description of the services, including whether subcontracting of critical functions is permitted and under what conditions.
- The locations where services are provided and data is processed and stored, with notice before changing them. Moving a workload to a different region becomes a contractual event.
- Data protection, availability, integrity and confidentiality provisions, with specified service levels including quantitative targets.
- Assistance at no additional cost, or at a pre-agreed cost, when an incident occurs.
- Full cooperation with the customer's competent authorities, including access, inspection and audit rights over you.
- Exit strategies: a mandatory transition period during which you continue providing the service, and obligations around returning data.
- Participation in the customer's threat-led penetration testing (TLPT) where the entity is required to perform it.
Three of these regularly cause difficulty for suppliers who have not seen them before.
Audit rights. Financial entities need contractual rights for themselves and their regulators to inspect. You can manage this with pooled audits and by offering existing certifications and reports — an ISO 27001 certificate and a SOC 2 Type II satisfy much of the routine assurance — but you cannot contractually exclude regulator access.
Exit and transition. You must be able to hand the customer their data in a usable form and keep the service running while they move. Write the exit plan and test the export before a customer asks, because "we would export the database" is not an answer when the question is about a two-year transition period for a critical function.
Subcontractor transparency. Your own cloud provider and any critical sub-processors must be disclosed, with notice of changes. Keep the list current; you will be asked for it repeatedly.
Critical ICT third-party providers
A small number of providers will be designated as critical (CTPPs) by the European Supervisory Authorities, based on systemic importance and substitutability. Designated providers come under direct EU oversight, with a Lead Overseer, inspection powers and the ability to issue recommendations.
Realistically this designation lands on the hyperscalers and a handful of large financial-sector software vendors. If you are a mid-sized SaaS company, you will not be designated — but your financial customers must assess concentration risk across their providers, which means you may be asked questions about your own dependence on a single cloud provider or region.
What to build, in order
If financial entities are a meaningful part of your customer base:
- A service description and locations document, per service, kept current. This feeds their register of information and you will be asked for it by every customer.
- An incident notification procedure with committed timeframes, wired into your on-call runbook with the customer contact route in it. The 24-hour NIS2 clock and DORA's customer-notification expectations are similar enough to build once.
- A tested exit plan: data export in a documented format, a transition timeline, and evidence you have run the export.
- A subcontractor register, with a notification process for changes.
- Resilience testing evidence. DORA expects entities to test; suppliers who can show their own testing — including failover exercises with recorded recovery times — shorten every due diligence conversation.
None of this requires a certification, and there is no "DORA certificate" to obtain. What there is, is a set of documents and capabilities your customers are now obliged to ask for. Having them ready turns a six-week procurement review into a one-week one, which for a supplier is the entire practical benefit.