Module 1: What Is DORA and Why It Matters Now

1. Setting the Scene: Why DORA Matters in 2025

In January 2025, the Digital Operational Resilience Act (DORA) stopped being a future concern and became binding law across the EU financial sector.

• Legal reference: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector
• Part of: the EU Digital Finance Package (adopted 2020)
• Key date: DORA entered into force in 2022, and started applying on 17 January 2025 (relative to today: earlier this year).

DORA is not just another cybersecurity guideline. It is a directly applicable EU regulation that:

1. Harmonizes ICT risk and cyber resilience rules across almost the entire EU financial sector.
2. Integrates ICT risk into prudential and conduct supervision, instead of treating it as a side issue.
3. Brings critical ICT third‑party providers (CTPPs) (e.g. major cloud providers) into the EU financial regulatory perimeter for the first time.

> Core idea: Financial entities must be able to resist, respond to, and recover from all types of ICT‑related disruptions and cyber‑attacks, while continuing to provide critical services to the real economy.

You should approach DORA as a structural shift comparable to:

• Basel III for capital adequacy, but for digital resilience;
• GDPR for data protection, but focused on operational continuity and ICT risks.

In this module, you will:

• Understand what DORA is and why it was created.
• Grasp its five core thematic areas.
• Be able to reconstruct the key milestones in its legislative and implementation timeline, including 17 January 2025.

Keep in mind: as of today (December 2025), supervisory expectations, RTS/ITS, and guidance are already shaping exams, audits, and enforcement. This is no longer a theoretical framework.

2. What Exactly Is DORA? Legal Nature and Position in EU Law

Let’s be precise and rigorous.

2.1 Legal identity

• Full name: Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector.
• Common name: DORA (Digital Operational Resilience Act).
• Type of act: Regulation, not a Directive.

Why this matters:

• A Directive requires transposition into national law and can lead to fragmentation.
• A Regulation is directly applicable in all Member States, ensuring uniform rules.

DORA therefore replaces the previous patchwork of:

• EBA, ESMA, EIOPA guidelines on ICT and security risk management;
• National supervisory expectations and circulars;
• Sector‑specific provisions scattered across different EU financial services acts.

While some earlier rules still exist, DORA is now the primary reference for digital operational resilience in the EU financial sector.

2.2 Place within the EU Digital Finance Package

DORA is part of a broader EU Digital Finance Package (adopted 2020), alongside:

• Regulation (EU) 2023/1114 on markets in crypto‑assets (MiCA),
• Regulation (EU) 2022/858 on a pilot regime for market infrastructures based on DLT,
• A Digital Finance Strategy and Retail Payments Strategy.

Together, these instruments aim to:

1. Foster innovation and competitiveness in EU digital finance.
2. Ensure consumer protection and financial stability.
3. Maintain technological neutrality while addressing new digital risks.

DORA is the operational resilience pillar of this package.

3. Policy Objectives: What Problem Is DORA Solving?

DORA was designed in response to several systemic weaknesses observed over the last decade.

3.1 Fragmented ICT risk frameworks

Before DORA:

• Different financial sub‑sectors (banks, insurers, asset managers, payment institutions) faced different ICT rules.
• National supervisors had heterogeneous expectations.
• Cross‑border groups struggled with duplicative, inconsistent requirements.

DORA’s first objective is harmonization: a single, coherent framework for digital operational resilience across the EU financial sector.

3.2 Growing dependency on ICT and third‑party providers

Financial entities increasingly rely on:

• Cloud computing (often from a small number of large global providers),
• Software‑as‑a‑Service (SaaS) for core functions,
• Complex ICT outsourcing chains (sub‑outsourcing, offshoring).

This creates concentration risk and single points of failure. DORA’s second objective is to control and supervise ICT third‑party risk, especially where providers are systemically important (CTPPs).

3.3 Escalating cyber threats and systemic events

Recent years have seen:

• Large‑scale ransomware campaigns,
• Supply‑chain attacks (e.g. via compromised software updates),
• Disruptions of payment systems and online banking channels.

These events showed that:

• Even a single ICT incident can have EU‑wide systemic impact.
• Many firms lacked structured incident reporting, testing, and crisis communication.

DORA’s third objective is to make sure financial entities can withstand, respond to, and recover from such events, protecting:

• Financial stability,
• Market integrity,
• Consumer and investor confidence.

> Key takeaway: DORA’s core policy goal is digital operational resilience: ensuring that critical financial services remain available and reliable even under severe ICT disruption.

4. Who Is In Scope? Financial Entities and ICT Providers

DORA’s scope is broad by design.

4.1 Financial entities

DORA applies to a wide range of regulated financial entities, including (non‑exhaustive):

• Credit institutions (banks),
• Investment firms and trading venues,
• Central counterparties (CCPs) and central securities depositories (CSDs),
• Payment institutions and electronic money institutions,
• Insurance and reinsurance undertakings,
• Insurance intermediaries (above certain thresholds),
• Asset management companies, AIFMs, UCITS management companies,
• Crypto‑asset service providers (CASPs) under MiCA, once fully operational,
• Credit rating agencies, trade repositories, and others.

DORA uses proportionality: smaller/less complex firms have lighter obligations, but no entity is entirely exempt from ICT risk management duties.

4.2 ICT third‑party service providers

DORA does not regulate all ICT providers in general. It focuses on those providing ICT services to in‑scope financial entities, such as:

• Cloud service providers (IaaS, PaaS, SaaS),
• Providers of data centers and hosting,
• Providers of network and communication services,
• Providers of software crucial for operations (core banking, trading, risk systems),
• Providers of security services (e.g. SOC, threat monitoring).

Within this group, some will be designated as Critical ICT Third‑Party Providers (CTPPs), subject to direct oversight by the Lead Overseer (one of the ESAs).

> Edge case to think about: A large global cloud provider that serves many EU banks and CCPs, but is headquartered outside the EU. DORA still captures its EU‑facing activities, because the risk materializes in the EU financial system, not where the provider is incorporated.

The high‑level scope is therefore:

• Financial entities (broad list, with proportionality), and
• ICT third‑party providers (especially those designated as critical).

5. The Five Pillars of DORA: High‑Level Structure

DORA is structured around five core thematic areas. Understanding these is essential before diving into details.

1. ICT Risk Management (IRM)

Financial entities must establish comprehensive ICT risk management frameworks, integrating:

• Governance and board accountability,
• ICT asset and risk identification,
• Protection, detection, response, and recovery capabilities,
• Business continuity and disaster recovery planning.

1. ICT‑Related Incident Management, Classification and Reporting

Entities must:

• Detect and log incidents,
• Classify them (e.g. major incidents),
• Report significant incidents to competent authorities using standardized templates and timelines.

1. Digital Operational Resilience Testing (DORT)

Entities must conduct regular testing of their ICT systems and controls, including:

• Vulnerability assessments and penetration testing,
• Advanced Threat‑Led Penetration Testing (TLPT) for significant entities.

1. ICT Third‑Party Risk Management (TPRM)

Entities must manage risks arising from outsourcing and other ICT third‑party arrangements, including:

• Contractual requirements,
• Concentration risk assessment,
• Exit strategies and substitution plans.

1. Information Sharing Arrangements

DORA encourages voluntary information sharing among financial entities on:

• Cyber threats,
• Indicators of compromise,
• Tactics, techniques, and procedures (TTPs).

These pillars are interconnected:

• Effective ICT risk management requires testing, incident management, and robust third‑party oversight.
• Information sharing improves detection, testing scenarios, and incident response.

> When reading any DORA article, try to map it to one of these five pillars. This helps you quickly understand its purpose and interactions.

6. Real‑World Scenario: Outage at a Cloud‑Dependent Bank

Consider this realistic scenario, and mentally map it to DORA’s pillars.

Scenario

A mid‑size EU bank has migrated most of its core banking system to a major cloud provider. On a Monday morning, a configuration error at the provider’s data center triggers a cascading failure:

• Mobile and online banking are unavailable for 6 hours.
• Card payments are intermittently failing.
• The bank’s call center is overwhelmed.

How DORA views this scenario

1. ICT Risk Management

• Did the bank’s board approve and understand the risk of heavy cloud dependence?
• Were there redundant systems or fail‑over capabilities?
• Did the bank’s business continuity plan cover this kind of outage?

1. Incident Management & Reporting

• How quickly did the bank detect and classify the incident?
• Was it classified as a major ICT‑related incident?
• Did the bank notify its competent authority within the DORA deadlines and using the prescribed format?

1. Digital Operational Resilience Testing

• Had the bank previously tested its ability to operate under a cloud outage scenario?
• Were there TLPT exercises simulating attacks on the cloud environment or configuration errors?

1. ICT Third‑Party Risk Management

• Did the contract with the provider include sufficient service level agreements (SLAs) and incident support obligations?
• Had the bank assessed its concentration risk (e.g. reliance on a single provider)?
• Was there an exit strategy or multi‑cloud/on‑premise fallback option?

1. Information Sharing

• After the incident, did the bank share anonymized threat and incident information with peers or ISAC‑like communities?
• Did other entities benefit from learning about the root cause and mitigations?

> Use this scenario as a mental template: any significant ICT disruption can be analyzed through DORA’s five pillars. This is also how supervisors will think about it.

7. Thought Exercise: Borderline Scope and Proportionality

Reflect on the following borderline cases and write down (mentally or on paper) how DORA would likely apply. Aim for precise reasoning, not just yes/no answers.

Case A: Small FinTech Payment Institution

A small FinTech, licensed as a payment institution in one EU Member State, offers a mobile app for peer‑to‑peer payments. It has:

• 25 employees,
• No physical branches,
• Infrastructure fully hosted in the public cloud.

Questions to consider:

1. Is the entity in scope of DORA? On what legal basis?
2. How would proportionality apply to its ICT risk management and testing obligations?
3. Which of the five pillars are most critical for this firm’s risk profile?

---

Case B: EU Asset Manager Using a US SaaS Provider

An EU asset management company uses a US‑based SaaS provider for its portfolio management system. The SaaS is critical for day‑to‑day trading and risk monitoring.

Questions to consider:

1. Does DORA apply directly to the US SaaS provider? Why or why not?
2. How does DORA expect the asset manager to manage the risks associated with this provider?
3. Under what conditions might such a provider be considered for CTPP designation?

---

Case C: Large Bank vs. Small Credit Union

Compare a G‑SIB‑level bank and a small local credit union within the EU.

Questions to consider:

1. Which obligations will be qualitatively similar for both (e.g. existence of an ICT risk framework)?
2. Where will proportionality lead to very different expectations (e.g. TLPT, complexity of governance, volume of incident reporting)?

> Challenge yourself: For each case, explicitly link your reasoning back to the policy objectives and five pillars discussed earlier. This is exactly the type of reasoning expected in advanced exams or interviews.

8. Timeline and Key Milestones: From Proposal to Enforcement

Understanding when DORA developed is essential to understanding how mature the framework now is (as of late 2025).

8.1 Legislative timeline (high level)

• September 2020 – European Commission presents the Digital Finance Package, including the proposal for DORA.
• Late 2022 – DORA is formally adopted as Regulation (EU) 2022/2554.
• 16 January 2023 – DORA enters into force (20 days after publication in the Official Journal).
• 17 January 2025 – DORA starts applying: this is the critical enforcement date. From this day, financial entities and in‑scope ICT providers are legally bound by DORA obligations.

8.2 Regulatory technical standards (RTS/ITS) and guidance

Between 2023 and 2025, the European Supervisory Authorities (EBA, ESMA, EIOPA) developed regulatory technical standards (RTS) and implementing technical standards (ITS) on:

• ICT risk management requirements,
• Incident classification and reporting formats,
• TLPT frameworks,
• Criteria for designating critical ICT third‑party providers.

Many of these standards entered into force around the same time DORA began to apply (January 2025), and have since been refined and clarified through Q&As and supervisory communications.

8.3 Where we are now (December 2025)

• DORA is fully applicable.
• Supervisory reviews and on‑site inspections are already testing compliance.
• Some Member States have adjusted national laws to align sanctions and supervisory powers with DORA.
• The first CTPP designations and oversight activities are either in place or well advanced.

> When you see a reference to DORA as “upcoming” or “future”, treat it as outdated material. For your studies and professional practice, assume DORA is operational and enforceable now.

9. Quick Check: Core Understanding of DORA

Answer the following question to test your grasp of DORA’s nature and scope.

10. Flashcard Review: Key Terms from Module 1

Use these flashcards to consolidate the core vocabulary for DORA. Try to recall the definition before flipping each card.