DORA — the Digital Operational Resilience Act — entered into force on 17 January 2025. Unlike NIS2, DORA is not a directive but a regulation: it is directly binding in all EU member states without national implementation. And it targets the financial sector specifically.
The core question DORA asks is not whether your systems are secure. It is whether you can continue to function — for your clients, for the market, for the regulator — even when your systems are attacked or fail. Including the systems of everyone you depend on.
Who Does DORA Apply To?
DORA applies to everything connected to financial services: banks, payment institutions, investment firms, insurance companies, pension funds, credit rating agencies, crowdfunding platforms. And — critically — also to ICT third-party service providers: cloud providers, SaaS companies, and software firms delivering services to financial institutions.
A software company providing invoice management to a bank falls directly under DORA. An accounting firm serving an insurance broker may not fall under DORA directly — but the broker is required to assess the accountant’s ICT suppliers if those suppliers deliver services touching the financial operation. The line is not always sharp. The direction is: DORA flows through the entire chain.
The Five Pillars of DORA
DORA is structured around five core areas. Together they form a framework for digital operational resilience.
Pillar 1 — ICT Risk Management
You must have a documented framework for managing ICT risks. Not a document sitting in a drawer — a working system you can demonstrate to a regulator. The framework covers identification of all ICT assets, protection, detection of anomalies, incident response, recovery, and learning from incidents. A cloud AI service is an ICT asset. It goes in your register. You must assess its risk and maintain an exit strategy.
Pillar 2 — ICT-Related Incident Management
Major ICT incidents must be reported to the competent authority. The timelines are stricter than NIS2: 4 hours for an initial notification after classifying the incident as major, 72 hours for an interim report, and 1 month for a final report. If a cloud AI provider only informs you six hours after an incident that affected your service delivery, you already have a regulatory problem. Your clock starts the moment you become aware.
Pillar 3 — Digital Operational Resilience Testing
You cannot simply claim your systems are resilient — you must test them. Annual testing of all ICT systems is the baseline. Large financial institutions are required to conduct Threat-Led Penetration Testing (TLPT): simulated attacks on production systems by certified external testers, at least every three years. Testing a cloud AI service for resilience is complex: the provider largely determines what you are permitted to test. Local systems are fully accessible for penetration testing without requiring external authorisation.
Pillar 4 — Third-Party ICT Risk Management
This is the pillar with the most day-to-day impact. Every cloud provider, every SaaS supplier, every external ICT service must be entered in a register, have a DORA-compliant contract, be assessed on cybersecurity practices, and have an exit strategy. The contract must include as a minimum: a description of services, the location where those services are delivered, availability and continuity guarantees, and the exit procedure when the relationship ends.
Pillar 5 — Information Sharing
Financial institutions are encouraged to share intelligence on cyber threats and vulnerabilities with other institutions and authorities. DORA recognises that cybersecurity is a collective problem: an attack on one institution is a signal for the entire sector.
The Register: The Administrative Backbone
Article 28 of DORA requires financial entities to maintain a register of all contractual arrangements with ICT service providers. That sounds bureaucratic. But the register is the foundation of everything: it determines which suppliers you must assess, which contracts you must update, and which exit strategies you must document.
If you do not yet have a register, not knowing about DORA is not an excuse. It is precisely the situation DORA was designed to address.
Three Steps You Can Take Now
1. Determine whether you are in scope
Are you a financial institution, an insurance intermediary, or an ICT service provider to the financial sector? Then you fall directly under DORA. Do you provide other services to financial institutions? Then you are part of their DORA chain.
2. Build an ICT register
Which external software tools, cloud providers and services do you use? For each supplier, note: what they deliver, how critical that is to your service delivery, and what contract terms exist around incidents and continuity.
3. Review your contracts
DORA sets requirements for the content of contracts with ICT suppliers. Service descriptions, data location, SLAs, exit procedures — are those in your contracts in concrete terms? If not, revision is needed before a regulator makes that determination for you.
DORA carries fines that can reach 1% of average daily global turnover for each day of non-compliance. For ICT third-party providers designated as critical, additional obligations apply — including direct supervision by the European supervisory authorities themselves.