DORA (the Digital Operational Resilience Act, EU Regulation 2022/2554) is an EU regulation requiring financial sector entities to manage ICT risk in a way that’s harmonised across the whole European Union. Instead of scattered, national-level requirements, DORA introduces one shared operational resilience standard for banks, investment firms, insurers, and their critical technology providers.
Quick Overview
What you’ll learn from this article:
- Exactly who DORA covers, and why the regulation also reaches IT providers serving the financial sector
- What DORA’s five pillars are and what they mean in practice
- How DORA differs from NIS2 and how the two regulations complement each other
- Where to start preparing an organisation for compliance
Who this article is for: compliance officers and risk managers at financial institutions, CTOs/CISOs at technology providers serving the financial sector, and executives responsible for regulatory compliance.
Reading time: 6 minutes
DORA: digital operational resilience for the financial sector
Per the text of Regulation (EU) 2022/2554 published on EUR-Lex, DORA covers a broad catalogue of financial entities — banks, payment institutions, investment firms, insurers — and, importantly, also key third-party ICT service providers (cloud computing, data centres) where they serve the financial sector. This extension of accountability beyond the financial sector itself is one of the most significant changes compared to earlier national-level regulations.
DORA’s five pillars
| Pillar | What it covers |
|---|---|
| ICT risk management | Internal risk management frameworks, with clear accountability at board level |
| Incident reporting | A harmonised process for classifying and reporting major ICT incidents to supervisory authorities |
| Digital operational resilience testing | Regular testing, including advanced Threat-Led Penetration Testing (TLPT) for the largest entities |
| Third-party risk management | Oversight of ICT providers, including audit rights and contractual clauses required by DORA |
| Information sharing | Voluntary sharing of cyber threat intelligence among sector entities |
The third-party risk management pillar is particularly relevant for technology companies that previously never had to comply with financial regulation directly — DORA requires financial institutions to contractually enforce specific security standards on their IT providers. In practice, this means a cloud provider serving a bank may be asked to adapt its contract to DORA’s requirements, even though it isn’t itself a financial institution — because the financial institution carries responsibility for the entire ICT supply chain it relies on.
The regulation also introduces the concept of “critical third-party providers” — providers so systemically important to the financial sector that they fall under direct oversight by European supervisory authorities, rather than only indirect oversight through their financial-sector clients.
DORA versus NIS2 — how they differ
DORA is a sector-specific regulation (financial services only) and takes precedence over NIS2 wherever the two could overlap — the lex specialis principle. NIS2 covers a broader range of sectors (energy, transport, healthcare, digital infrastructure) and sets more general cybersecurity requirements. In practice, a financial institution is primarily subject to DORA, not to both regulations in parallel for the same scope.
Where to start preparing for compliance
- Map every ICT provider contract — DORA requires a register of all technology dependencies, including both critical and non-critical providers.
- Review contractual clauses with providers against DORA’s requirements (audit rights, exit plans, data access).
- Build or update your incident reporting process to meet the required classification and reporting timeframes.
- Plan operational resilience testing proportionate to your organisation’s scale — not every entity has to undergo full TLPT.
- Train the board and senior management — DORA explicitly requires accountability for ICT risk management to sit at board level, not solely within the IT department, which for many organisations means a real change in how technology risk gets reported upward.
Read Also
- Phishing and Social Engineering: How to Spot an Attack
- MLOps: Taking Machine Learning Models to Production
Develop Your Skills
Want to deepen your regulatory and technology risk management skills? Check out our training led by experienced EITT instructors.
➡️ Cyber Security for Employees in the Context of NIS2 and KSC — EITT training ➡️ Introduction to ISO 27001: The Basics of the Standard — EITT training
Frequently Asked Questions (FAQ)
Exactly who does DORA cover?
DORA covers a broad catalogue of financial entities — banks, investment firms, payment institutions, insurers — as well as key third-party ICT service providers, such as cloud providers, where they serve the financial sector. This extension to technology providers is one of the key differences from earlier, purely national financial-sector regulations.
How does DORA differ from NIS2, if both address cybersecurity?
DORA is a sector-specific regulation dedicated solely to the financial sector and takes precedence over NIS2 wherever the two could overlap (the lex specialis principle). NIS2 covers a broader range of economic sectors and sets more general requirements, while DORA specifies them precisely for operational and ICT risk in finance.
Does every financial institution have to undergo advanced penetration testing (TLPT)?
No — full Threat-Led Penetration Testing is required primarily from the largest and systemically important financial entities, under the proportionality principle built into the regulation. Smaller institutions are subject to regular but less advanced forms of operational resilience testing.
What’s the best place to start rolling out DORA compliance in an organisation?
The most practical first step is mapping every contract and dependency with ICT service providers — without a full register of technology dependencies, it’s difficult to assess which DORA requirements (such as third-party risk management) even apply. Only on that basis can you plan updates to contractual clauses and the incident reporting process.