Regulation (EU) 2022/2554 — the Digital Operational Resilience Act. A binding EU regulation that requires financial entities to ensure they can withstand, respond to, and recover from ICT-related disruptions and threats.
DORA is structured around five interconnected pillars. Think of them as the security domains you already work with, but with explicit regulatory teeth.
Your risk management framework, policies, asset inventory, detection, response, recovery, and lessons learned. Essentially your ISMS on steroids.
Articles 5–16Classify, manage, and report ICT incidents to regulators. Strict timelines. Think SOC + compliance reporting baked into law.
Articles 17–23Vulnerability assessments, pen tests, and Threat-Led Penetration Testing (TLPT). Red teaming mandated by law for significant entities.
Articles 24–27Manage your supply chain. Contractual requirements for ICT providers, concentration risk, and an EU oversight framework for critical providers.
Articles 28–44Voluntary threat intelligence sharing between financial entities. ISACs and CTI exchanges built into the regulatory framework.
Article 45Unlike frameworks (ISO 27001, NIST CSF), DORA is a regulation. Non-compliance means fines and regulatory action, not just a failed audit.
SIEM, SOAR, vulnerability management, pen testing, BCP/DR, vendor risk — all explicitly required. Your security program IS the compliance program.
The management body is directly responsible. This gives security teams real leverage to push for resources and get executive buy-in.
Cloud providers, SaaS vendors, managed services — all under the microscope. You'll need to assess, contract, and monitor every critical ICT provider.
| Aspect | DORA | ISO 27001 | NIST CSF | NIS2 |
|---|---|---|---|---|
| Type | EU Regulation (binding) | Voluntary standard | Voluntary framework | EU Directive (transposed) |
| Sector | Financial services | Any | Any | Essential & important entities |
| Pen Testing | Mandatory TLPT for significant entities | Recommended | Recommended | Encouraged |
| Incident Reporting | Mandatory, strict timelines | Internal process | Internal process | 24h early warning, 72h report |
| Third-Party | Detailed contractual & oversight rules | Annex A controls | Supply chain category | Supply chain security |
| Board Accountability | Explicit personal liability | Management commitment | Governance function | Management liability |
Select a pillar from the sidebar or filter below to focus on a specific domain.
This is the backbone of DORA. It requires financial entities to have a comprehensive, documented ICT risk management framework that covers identification, protection, detection, response, and recovery. If you've built a security program based on NIST CSF or ISO 27001, this maps closely — but DORA adds prescriptive detail and makes it legally binding.
Click any row for detailed context, obligations, and external references.
| DORA Requirement | What It Means for You | Tools / Controls |
|---|---|---|
| ICT risk management framework (Art. 6) | Documented framework, reviewed annually, approved by management body | GRC platform, policy management |
| ICT systems inventory (Art. 8) | Complete asset inventory of all ICT systems and information assets | CMDB, asset discovery tools |
| Identification of risks (Art. 8) | Regular risk assessments, threat modeling, vulnerability identification | Risk register, threat modeling tools |
| Protection & prevention (Art. 9) | IAM, encryption, network security, secure SDLC, patch management | IAM, WAF, SAST/DAST, patching tools |
| Detection (Art. 10) | Anomaly detection, continuous monitoring, multiple layers of control | SIEM, EDR, NDR, UEBA |
| Response & recovery (Art. 11) | IR plans, BCP, DR plans, communication procedures | SOAR, BCP/DR tools, runbooks |
| Backup & restoration (Art. 12) | Backup policies, regular testing of restoration, separate from production | Backup solutions, DR drills |
| Learning & evolving (Art. 13) | Post-incident reviews, lessons learned fed back into framework | PIR process, knowledge base |
| Communication (Art. 14) | Crisis communication plans, designated spokesperson, internal notification procedures | Comms templates, contact lists |
| Simplified framework (Art. 16) | Proportionate requirements for smaller entities (microenterprises etc.) | Reduced documentation burden |
Formalises your incident response process and adds mandatory reporting to regulators. This isn't just "have an IR plan" — DORA prescribes classification criteria, reporting timelines, and post-incident reporting.
DORA defines major incidents based on these factors:
| Criterion | Description |
|---|---|
| Clients affected | Number of clients / financial counterparts impacted |
| Reputational impact | Severity of potential reputational damage |
| Duration | How long the incident persisted including service downtime |
| Geographic spread | Number of Member States affected |
| Data losses | Volume and sensitivity of data compromised |
| Criticality of services | Whether critical or important functions were affected |
| Economic impact | Direct and indirect financial costs |
This is where DORA gets very hands-on for security engineers. It mandates a testing programme with specific requirements that scale with the entity's significance.
Click any row for detailed context, obligations, and external references.
| Test Type | Who | Frequency | Details |
|---|---|---|---|
| Vulnerability assessments | All financial entities | At least annually | Scans of all ICT systems and applications supporting critical functions |
| Open-source software analysis | All financial entities | Ongoing | Review of OSS components, known vulnerabilities, license compliance |
| Network security assessments | All financial entities | At least annually | Network architecture review, segmentation testing, firewall rule review |
| Scenario-based testing | All financial entities | At least annually | Table-top exercises, business continuity simulations |
| Penetration testing | All (except microenterprises) | At least annually | Application and infrastructure pen testing |
| Source code review | Where feasible | As appropriate | Static analysis, code review of critical systems |
| TLPT (Threat-Led Pen Testing) | Significant entities only | Every 3 years | Red team exercises based on real threat intelligence, following TIBER-EU framework |
The crown jewel for red teamers. DORA mandates TLPT for entities identified by competent authorities as significant. Key rules:
The largest chapter in DORA. This regulates how financial entities manage risk from ICT service providers (cloud, SaaS, outsourced infra, managed services). It also establishes an EU-level oversight framework for "critical" ICT third-party providers (think AWS, Azure, Google Cloud, Bloomberg, etc.).
The ESAs (EBA, ESMA, EIOPA) can designate ICT providers as "critical" based on systemic importance. Once designated:
The shortest pillar, but strategically important. DORA explicitly encourages (but does not mandate) financial entities to share cyber threat intelligence with each other.
All 64 articles of DORA, grouped by chapter. Click to expand details, obligations, and practical security notes.
Defines what DORA covers: ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing for financial entities.
57 definitions that DORA uses. Key ones you'll need:
Lists all 21 types of financial entities in scope. See the "Entities" section for the full breakdown.
Requirements are proportionate to the entity's size, risk profile, nature, scale, and complexity of services. This is your friend — smaller or less complex entities can implement simpler controls.
The management body (board of directors, executive board) bears ultimate responsibility for ICT risk management. This is personal, not delegable.
The core requirement: maintain a comprehensive, documented, and regularly updated ICT risk management framework.
Know what you have, know what can go wrong, and document it all.
Empowers the ESAs to develop Regulatory Technical Standards (RTS) further specifying the ICT risk management requirements. These RTS provide the granular technical detail beneath the principles in Articles 5–14.
Provides a lighter-touch framework for smaller entities (small and non-interconnected investment firms, payment institutions exempted under PSD2, etc.).
ESAs develop RTS specifying the content, timelines, and templates for incident reports. Standardised templates mean consistent reporting across the EU.
ESAs and ECB to explore the feasibility of establishing a single EU Hub for major ICT-related incident reporting.
Competent authorities must provide feedback and guidance to the reporting entity following their report. They may also share anonymised information about the incident with other entities to improve sector-wide resilience.
Special provisions for credit institutions, payment institutions, and e-money institutions regarding payment-related incidents. DORA's incident reporting replaces the PSD2 incident reporting for these entities.
ESAs designate ICT third-party providers as "critical" based on criteria including:
Articles 32–44 establish the EU-level oversight framework for critical ICT third-party providers. Key elements:
Establishes the supervisory framework: which national competent authorities enforce DORA, how they cooperate across borders, and their powers for administrative penalties and remedial measures.
Final provisions covering delegated acts (empowering the Commission to specify technical details), amendments to existing regulations, the review clause (3-year review), and the entry into force / application date.
Key obligations grouped by who is responsible and what they need to do. Mapped to specific articles.
| What | To Whom | When | Article |
|---|---|---|---|
| Major incident — initial notification | Competent authority | Within 4 hours (max 24h) of classification | Art. 19 |
| Major incident — intermediate report | Competent authority | Within 72 hours | Art. 19 |
| Major incident — final report | Competent authority | Within 1 month | Art. 19 |
| Register of ICT providers | Competent authority | At least annually | Art. 28(3) |
| New critical provider arrangements | Competent authority | Timely (before contracting) | Art. 28(3) |
| Information sharing participation | Competent authority | Upon entering arrangement | Art. 45 |
| TLPT results | Competent authority | After TLPT completion | Art. 26 |
| Client notification (major incidents) | Affected clients | Without undue delay | Art. 19(3) |
Important milestones for DORA implementation.
Practical checklist to assess your organisation's DORA readiness. Click items to mark them as done.
DORA applies to 21 types of financial entities (Art. 2) and ICT third-party service providers under the oversight framework.
| # | Entity Type | Examples | Simplified Framework? |
|---|---|---|---|
| 1 | Credit institutions | Banks, building societies | No |
| 2 | Payment institutions | Payment processors, PSPs | Some (PSD2-exempted) |
| 3 | Account information service providers | Open banking aggregators | Yes |
| 4 | Electronic money institutions | E-money issuers | Some |
| 5 | Investment firms | Brokers, dealers, advisors | Small & non-interconnected |
| 6 | Crypto-asset service providers | Exchanges, wallet providers | No |
| 7 | Central securities depositories | CSDs | No |
| 8 | Central counterparties | CCPs, clearing houses | No |
| 9 | Trading venues | Stock exchanges, MTFs, OTFs | No |
| 10 | Trade repositories | EMIR trade repositories | No |
| 11 | Management companies (UCITS) | Fund managers | No |
| 12 | Alternative investment fund managers | Hedge fund managers, PE managers | No |
| 13 | Data reporting service providers | ARMs, APAs, CTPs | No |
| 14 | Insurance undertakings | Insurance companies | No |
| 15 | Reinsurance undertakings | Reinsurers | No |
| 16 | Insurance intermediaries | Insurance brokers (certain) | Some |
| 17 | Institutions for occupational retirement | Pension funds (IORPs) | No |
| 18 | Credit rating agencies | S&P, Moody's, Fitch | No |
| 19 | Administrators of critical benchmarks | LIBOR/EURIBOR administrators | No |
| 20 | Crowdfunding service providers | EU crowdfunding platforms | No |
| 21 | Securitisation repositories | Securitisation data repositories | No |
The ESAs (EBA, ESMA, EIOPA) developed detailed technical standards that specify the requirements of DORA. These are the granular "how-to" beneath the regulation's principles.
DORA does not specify a single EU-wide penalty amount (unlike GDPR). Instead, it empowers Member States and competent authorities to impose administrative penalties and remedial measures.
Curated links to official documents, technical standards, guidance, and tools. All links open in a new tab.
The complete DORA regulation text on EUR-Lex. The authoritative legal source. Available in all EU languages.
The accompanying directive that amends existing financial services directives to align them with DORA (CRD, MiFID II, Solvency II, PSD2, etc.).
Commission page listing all delegated and implementing acts under DORA, including adopted Commission Delegated Regulations.
Official Q&A document from the Commission clarifying scope, definitions, and application of DORA requirements.
EBA's central page for all DORA regulatory products including RTS, ITS, and guidelines. Start here for the banking-sector perspective.
ESMA's dedicated DORA page with technical standards, Q&As, and resources relevant to investment firms, trading venues, and market infrastructure.
The detailed technical standard specifying ICT risk management framework requirements and the simplified framework. Covers policies, procedures, governance.
Materiality thresholds and criteria for classifying ICT-related incidents as "major." Essential for configuring your SIEM classification rules.
Standard forms and templates for initial notifications, intermediate reports, and final reports. Download these and integrate them into your IR process.
Template and data model for the register of ICT contractual arrangements. Defines exactly what fields you need to capture for each provider.
TLPT methodology, tester qualifications, scope requirements, and reporting. Maps closely to TIBER-EU. Essential reading if your entity is TLPT-designated.
Conditions for sub-outsourcing ICT services supporting critical or important functions and monitoring requirements for subcontracting chains.
Quantitative and qualitative criteria the ESAs use to designate providers as "critical" under the oversight framework.
The Threat Intelligence-Based Ethical Red Teaming framework that DORA's TLPT is modeled after. Understand TIBER-EU and you understand TLPT.
ENISA's guidance on incident classification and reporting across EU frameworks. Useful for aligning DORA reporting with NIS2 and other regimes.
Annual EU threat landscape analysis. Useful for informing risk assessments (Art. 8) and understanding threat context for TLPT scenarios.
If you're ISO 27001 certified, use it as a foundation. Many DORA Pillar 1 requirements map to Annex A controls. Gap analysis recommended.
NIST CSF maps well to DORA's Identify-Protect-Detect-Respond-Recover structure. Useful for building a crosswalk between your existing controls and DORA.
Pre-DORA EBA guidelines that formed the basis for many DORA requirements. Useful to understand the evolution and for institutions already compliant with these.
Pre-DORA outsourcing guidelines. Many organisations built their third-party risk programmes on these — DORA builds on and supersedes them for ICT services.
The broader EU cybersecurity directive. Financial entities are generally exempt from NIS2 because DORA is lex specialis, but understanding the overlap helps with group-level compliance.
Map DORA requirements to other standards (ISO 27001, NIST, CIS Controls) using OpenCRE. Excellent for building crosswalk / gap analysis matrices.
The standard protocols for sharing threat intelligence. You'll need STIX/TAXII capability to participate in information sharing arrangements under Art. 45.
Open-source threat intelligence platform widely used in the financial sector. Supports STIX/TAXII, IoC sharing, and community integration.
Map your detection capabilities (Art. 10) and TLPT scenarios (Art. 26) to the ATT&CK matrix. Essential for structured red/blue teaming.
Methodology for structuring your ICT risk assessments (Art. 8). Complements DORA's requirements with a process-oriented approach.
Standard marking system for information sharing. Use TLP when participating in threat intel sharing communities under DORA Art. 45.
The global financial sector ISAC. Membership gives you access to threat intel feeds, sharing communities, and exercises — directly supports Art. 45 compliance.
High-level forum for cyber resilience in the Euro area financial infrastructure. Publishes recommendations and best practices.
EU cybersecurity agency. Publishes threat landscapes, best practices, and coordinates incident response across the EU. Key resource for risk assessments.
If you use SWIFT, their CSP controls overlap significantly with DORA Pillar 1. A joint assessment can reduce duplication.
Start typing in the search bar to find articles, obligations, and keywords.