DORA Digital Operational Resilience Act.

Why DORA exists and who it binds

Before DORA, digital operational resilience for financial entities in the EU was a patchwork. Banks answered to one set of supervisory expectations, insurers to another, and the rules on ICT incidents, outsourcing, and testing varied by sector and by member state. DORA replaces that fragmentation with a single regulation that applies directly across the Union, no national transposition required. Its scope is deliberately wide: banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, trading venues, and many more, plus the critical ICT third-party providers those entities depend on.

That last point is what makes DORA different from a normal financial rule. It does not only regulate the supervised firms; it reaches into their supply chain. Cloud providers, data centre operators, and software vendors that are deemed critical to the financial system can be placed under direct oversight at EU level. For a practitioner, the practical consequence is that resilience is no longer something you can fully outsource and forget. You remain accountable for the ICT risk your providers carry, and you have to prove it.

The five pillars in practice

DORA is built on five pillars, and each one translates into concrete programme work rather than paperwork:

• ICT risk management. A governance framework owned by the management body, covering identification, protection, detection, response, and recovery for ICT assets. This is the backbone the other four pillars hang from.
• Incident management and reporting. Classify ICT-related incidents by severity, and report the major ones to the competent authority on a defined timeline. The emphasis is on a harmonised taxonomy so supervisors across the EU see comparable data.
• Digital operational resilience testing. A regular testing programme that ranges from vulnerability assessments up to threat-led penetration testing (TLPT) for the most significant entities, modelled on real adversary behaviour.
• ICT third-party risk management. Contractual safeguards, registers of information on all ICT arrangements, exit strategies, and the oversight regime for critical third-party providers.
• Information sharing. Voluntary exchange of cyber threat intelligence between financial entities, encouraged rather than mandated, to raise collective defence.

DORA next to NIS 2

The question practitioners ask most is how DORA relates to NIS 2, since both are EU instruments touching cybersecurity and both reach roughly the same maturity bar. The short answer is lex specialis: where DORA and NIS 2 would both apply to a financial entity on the ICT angle, DORA prevails because it is the more specific rule. NIS 2 sets a broad cybersecurity baseline across many sectors; DORA goes deeper on the financial sector's ICT resilience and adds the third-party oversight regime NIS 2 does not have.

In day-to-day terms, a bank does not get to pick one. It maps its obligations and finds that for ICT risk, incident reporting, and resilience testing, DORA is the controlling text, while NIS 2 may still matter for parts of the group that fall outside DORA's financial scope. The clean way to run this is a single control framework, often anchored on ISO 27001 and ISO 22301, that satisfies both regimes and lets you evidence compliance once.