DORA: what the regulation requires of financial institutions

DORA, the Digital Operational Resilience Act, has applied since 17 January 2025. The fact that it is a regulation rather than a directive is more than a legal detail. Regulation (EU) 2022/2554 applies directly in every member state, in identical wording, without the national legislator in between. For institutions used to open norms and supervisory good practice, that is a shift: the regulation and its technical standards spell out on many points exactly what has to happen and by when.

Who DORA applies to

The regulation lists the entities it covers, and that list is longer than most organisations assume on first reading. Banks, insurers and reinsurers, investment firms, payment institutions, electronic money institutions, pension funds, fund managers, trading venues, crypto asset service providers, credit rating agencies and crowdfunding service providers are all named. A small payment institution or a pension fund with an outsourced management office is in scope too.

Not everyone gets the same package. DORA provides a simplified ICT risk management framework for, among others, small and non-interconnected investment firms and small pension funds. Proportionality is built into the regulation itself, but the institution has to substantiate which regime applies to it. That is one of the first things a supervisor wants to see.

ICT service providers are not directly subject to most of the obligations, but they feel DORA all the same. Their financial clients are required to include specific arrangements in the contract, and a designated group of large providers falls under direct oversight by the European Supervisory Authorities. What that means in practice is covered in DORA for ICT providers to financial institutions.

Pillar 1: ICT risk management

The first pillar asks for an ICT risk management framework that covers the full cycle: identify, protect, detect, respond and recover. In concrete terms that means an up to date inventory of information assets and the business functions they support, policy and controls that follow from it, detection capability, and continuity and recovery plans that have actually been tested.

The framework is reviewed at least annually, and additionally after a major incident or following supervisory findings. Two requirements are routinely underestimated. The first is the separation between execution and control: responsibility for managing and overseeing ICT risk must sit with a control function with sufficient independence. The second is the role of the management body, which defines, approves and oversees the framework and has to keep its own knowledge of ICT risk current.

Pillar 2: classifying and reporting incidents

Major ICT related incidents must be reported to the supervisor in three steps. An initial notification follows no later than four hours after classification as major, and in any case within 24 hours of the institution becoming aware of the incident. Then an intermediate report within 72 hours and a final report within one month.

So the clock starts at classification, and that is where the work sits. The criteria for what counts as major are set out in the technical standards: clients and transactions affected, duration and downtime, geographical spread, data loss, criticality of the service affected and economic impact. Organisations that have not translated these criteria to their own services in advance lose the first hours arguing about whether this is a major incident. It pays to include classification in the incident response plan as a decision tree, including who may apply it outside office hours.

Alongside mandatory incident reporting there is the option to report significant cyber threats voluntarily. That is not an obligation, but it deserves a place in the escalation process.

Pillar 3: digital operational resilience testing

The third pillar asks for a testing programme that covers, every year, all ICT systems supporting critical or important functions. That goes beyond a penetration test: vulnerability scanning, source code review, scenario based testing, performance testing and tests of continuity and recovery plans all belong to it.

Institutions designated by the supervisor additionally carry out threat led penetration testing based on the TIBER-EU framework, at least every three years. Such a test uses threat intelligence about the organisation itself and attacks the live production environment without the defending team knowing it is an exercise. That takes considerable preparation and the involvement of suppliers where critical functions run on their platforms.

Pillar 4: managing ICT third party risk

The fourth pillar is the heaviest for most institutions. DORA requires a register of information covering all contractual arrangements for ICT services, recording per arrangement the provider, the function supported, how critical it is, the data location and the chain of subcontractors. That register is submitted to the supervisor periodically.

DORA also prescribes which clauses the contract must contain where a service supports a critical or important function: access and audit rights, incident notification deadlines, conditions for subcontracting, service descriptions with measurable targets, and an exit strategy that can actually be executed. Concentration risk has to be assessed as well, meaning the question of what happens if one cloud platform or one core banking supplier fails. The practical side of this, from supplier register to reading assurance reports, is covered in third party risk management.

Pillar 5: information sharing

The fifth pillar is the lightest. Financial entities may share information on cyber threats and vulnerabilities among themselves within trusted communities, provided this happens under arrangements that protect confidentiality and personal data. It is not mandatory.

How DORA relates to NIS2, ISO 27001 and supervisory frameworks

For financial entities DORA takes precedence over the NIS2 directive on the subjects DORA covers. A bank does not set up ICT risk management and incident reporting twice.

An existing ISMS helps but does not cover DORA. ISO 27001 delivers governance, risk assessment and a large share of the controls, and organisations working with it have a real head start. What ISO 27001 does not deliver are the reporting deadlines, the register of information, the mandatory contract clauses and the testing programme scoped on critical functions. The same applies to institutions following the DNB Good Practice for information security: the base is there, the DORA specific articles still have to go on top.

Where implementations stall in practice

Four patterns keep recurring. The register of information is unfinished, usually because nobody held all the contracts centrally. Contracts with existing suppliers have not been renegotiated, so audit and exit clauses are missing at precisely the parties running critical functions. A testing programme exists but cannot be traced back to the list of critical and important functions. And incident classification is described in policy without anyone ever having applied it to a real incident.

All four surface in a focused gap analysis that establishes, article by article, what evidence exists, who owns it and what is missing. Start with the register and with the list of critical and important functions, because those two set the scope of nearly everything that follows.

Secure Audit carries out DORA gap analyses and readiness assessments for financial institutions and tests whether the ICT risk framework demonstrably works rather than merely being written down. More on that on our compliance page. Get in touch to discuss where you stand.