- DORA sets digital resilience rules for banks, insurers and other financial entities, and it has applied since 17 January 2025 (Article 64).
- It tells those entities what their contracts with ICT service providers must contain (Article 30). That is where it reaches your product.
- Exit plans, audit access and help during incidents are in the text, which is why they turn up in procurement.
DORA is Regulation (EU) 2022/2554 of 14 December 2022, on digital operational resilience for the financial sector.
This is not legal advice, and nothing here tells you whether you or your customers meet the regulation. That judgement belongs to you, your customers and your advisers. What follows is what the text says, in plain terms, with the article beside each point so you can read it yourself.
A regulation, with one date
A regulation applies directly in every Member State, without a national law to carry it. Article 64 sets the date: DORA applies from 17 January 2025. So on the date of this guide, its rules on contracts with suppliers already apply to the entities in scope.
If your customers also sit under NIS2, DORA takes the lead for them. Article 1 makes it the sector-specific act for financial entities that NIS2 treats as essential or important. Our guide to NIS2, for product leaders who sell to regulated customers, covers that directive; this one stays with DORA.
Who is in scope, and where you appear
The duties fall on financial entities. Your role is defined, but the obligations in this guide are theirs.
Article 2 lists the financial entities it covers, among them credit institutions, payment institutions, investment firms, insurance and reinsurance undertakings, and insurance intermediaries. Article 3 defines an ICT third-party service provider as an undertaking providing ICT services, and ICT services as digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis.
Article 4 asks financial entities to apply the rules in proportion to their size, their overall risk profile and the nature, scale and complexity of what they do.
Whether your own product counts as an ICT service under these definitions, and what follows if it does, is a question for your advisers.
Why procurement asks for what it asks
Your customer stays responsible for its suppliers. Article 28 says financial entities manage ICT third-party risk as part of their own ICT risk management, and remain fully responsible for meeting their obligations when they use ICT services from someone else. Before signing, they assess the risks and carry out due diligence on the provider. They also keep a register of information on all their contracts for ICT services, and report on it to their competent authority.
Article 5 places this with the management body, which is responsible for the ICT risk management framework and approves and reviews the policy on using ICT third-party services. So the questions that arrive on your desk are backed by obligations that reach the top of your customer’s organisation.
What the contract has to say
Article 30 asks for the rights and obligations of both sides to be set out in writing, and lists what every contract for ICT services must include at least. Among them:
A description of the services, and whether subcontracting of a service supporting a critical or important function is permitted, and on what conditions.
Where the work happens. The regions or countries where the services are provided and the data is processed, and advance notice if the provider plans to change them.
Your customer’s data back. Access, recovery and return of the data in an easily accessible format if the provider becomes insolvent, stops its business, or the contract ends.
Help when something goes wrong. The provider assists when an ICT incident related to its service occurs, at no extra cost or at a cost agreed in advance.
Termination rights, with minimum notice periods.
For services that support critical or important functions, Article 30 adds more: full service level descriptions with precise performance targets, notice of developments that could affect the service, business contingency plans the provider implements and tests, and cooperation in your customer’s threat-led penetration testing.
Exit plans, audit access and incident reporting
Exit plans. For ICT services supporting critical or important functions, Article 28(8) asks financial entities to have exit strategies, so they can leave without disrupting their business or the service their clients receive. The plans are documented and tested, and identify alternative solutions. Article 28(7) asks that contracts can be terminated in set circumstances, among them a significant breach by the provider. The contract itself carries the exit too: Article 30(3)(f) asks for a mandatory adequate transition period, during which the provider keeps delivering the service while the customer moves to another provider or brings it in-house.
Audit access. For the same services, Article 30(3)(e) gives the financial entity the right to monitor the provider’s performance on an ongoing basis. That includes unrestricted rights of access, inspection and audit, by the entity, by a third party it appoints and by the competent authority, and the provider’s full cooperation during inspections and audits.
Incident reporting. The duty to report sits with your customer. Article 19 asks financial entities to report major ICT-related incidents to their competent authority, in an initial notification, an intermediate report and a final report. What it asks of you runs through the contract: the assistance in Article 30(2)(f), and, for critical or important functions, the reporting obligations in Article 30(3)(b).
A separate track, starting at Article 31, designates some ICT providers as critical and puts them under direct oversight. If you think that could concern you, take it to your advisers.
What this means for the roadmap
Most of this lands on contracts and on how your company is run. Some of it lands on the product.
Know which of your services support critical or important functions. Your customer decides that, and the answer sets how much of Article 30 applies to your contract.
Make leaving possible. An exit plan is easier to sign when your customer’s data comes out in a format they can use and your product doesn’t hold it hostage.
Know who answers when an incident hits a customer. Settle inside your company who decides that a customer must be told, and who helps them.
Bring your advisers in before you sign. What you agree with a financial entity is a legal question.
Settle these once, keep them current, and you can lift your eyes back to the product your customers depend on.
Where we come in
We don’t give legal advice, we make no compliance promise, and we don’t tell you whether you, your customers or anyone else falls under DORA. That judgement stays with you and your advisers.
What we can do is the work on your product that you choose, such as the security work in Harden security before the questionnaire arrives. We work within the access you grant, and nothing more. The work lands in your own code repository. The code we build for you is yours. You decide what ships. Nothing reaches your users without your approval.
It starts with a conversation, with no obligation.
