DORA brought the software supplier into the resilience review

DORA changed the evidence financial institutions needed from their technology providers, from incident support and service continuity to a workable exit.

Cybersecurity4 min read

Liquid cooling hardware in a data center. Illustration.

The Digital Operational Resilience Act began applying on 17 January 2025. It brought a common framework to the technology risks facing the financial entities within its scope. The rules covered the ability to continue and recover services, alongside incident reporting, testing and the management of external technology providers. For a software company selling to banks, insurers or investment firms, that last element reached directly into the customer relationship.

Before application, the European Supervisory Authorities had warned that DORA provided no additional transitional period. Many institutions already faced requirements on technology risk and outsourcing; DORA brought them into a common framework with a firm deadline. Suppliers needed to help customers meet those requirements without every sale becoming an extended exercise in bespoke documentation.

Start with the service the customer depends on

Article 28 required financial entities to manage technology supplier risk within their wider risk framework. It called for a register of contractual arrangements and a distinction between services supporting critical or important functions and other services. An institution needed to understand what it bought, how it used it and what interruption would mean. A single supplier name on a purchasing ledger was insufficient for that analysis.

For the supplier, useful preparation began with a clear description of the delivered service and its dependencies. That included where data was processed, the relevant subcontractors and the customer's options if part of the service failed. These details could also expose a mismatch between the product being sold and the reliability commitments a sales team had accepted.

The contract had to describe operational reality

Article 30 listed provisions for technology service contracts, including service descriptions, data locations, the protection and return of data, incident assistance and termination rights. For services supporting critical or important functions, it added more demanding provisions on performance targets, notification, business continuity, testing, access and audit. The exact requirements depended on the arrangement. A generic assertion of DORA compliance could not explain how a vendor would meet the terms of a particular contract.

These obligations had engineering consequences. Returning data in a usable format required an export capability. Promising assistance during an incident required available staff and an agreed way to communicate. An exit period had to be supported by continued service while the customer moved. Negotiating language without checking those capabilities could leave a young supplier carrying commitments its product and staffing model could not sustain.

Reporting depended on information moving quickly

The ESAs said financial entities needed to be equipped to classify and report major technology incidents from the application date. Their earlier policy package had addressed reporting and testing, although draft technical standards still had to pass through the adoption process. Institutions therefore had to prepare for the regulation's deadline while tracking the adoption of its supporting standards.

Three DE-CIX equipment cabinets with Brocade networking hardware and yellow cables visible through their mesh doors. — DE-CIX network equipment, 2011.Stefan Funke (opens in a new tab) · CC BY-SA 2.0 (opens in a new tab)

A customer's reporting duties made timely supplier information valuable. The supplier needed to distinguish observed facts from estimates, identify affected services and provide updates as the investigation developed. A reassuring status page alone could leave a customer unable to judge the significance of an outage. Maintaining an incident record and a reliable contact route became part of delivering the financial institution's service.

Critical provider oversight was a separate mechanism

DORA also established direct European oversight for technology providers designated as critical, addressing concentrations of dependency across the financial system. Supplying a bank did not automatically place a startup under that oversight. The ESAs expected the first designations in the second half of 2025, after the regulation began applying.

Supplier scrutiny and critical-provider oversight

Scroll to view all columns

Comparison	Supplier arrangement	Critical-provider oversight
Trigger	A financial entity uses third-party ICT services.	The ESAs designate a provider as critical.
Mechanism	Supplier due diligence, written contract terms and ongoing risk management.	Direct oversight by an appointed Lead Overseer.

These are separate mechanisms. Financial entities remain responsible for their DORA obligations when they use a technology provider.

Source1

An ordinary supplier could nevertheless face detailed questions because its customer remained responsible for managing the arrangement. That distinction mattered when estimating market entry costs. Some work arose through customer contracts and diligence; a separate set of duties would arise if the provider itself received a critical designation. Treating the two as interchangeable exaggerated some obligations and obscured others.

The investment case was in delivery, as well as compliance

DORA created demand for accurate dependency records, incident coordination, resilience testing and supplier information. The quality of these businesses depended on whether their products fitted the institution's existing systems and reduced repeated manual work. A dashboard that could not connect a contract, a service and the function it supported would leave much of the underlying problem unresolved.

For software suppliers more broadly, preparation could improve the credibility of an enterprise sale. It also carried real costs in engineering, support and contract management. Investors could examine whether those costs became reusable across customers or expanded with every negotiation. A convincing sale had to be backed by a service the customer could examine, operate through disruption and eventually leave.