Module 3: DORA in the EU Regulatory Landscape

1. Orienting DORA in the EU Rulebook (2022–2025)

DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025, with most obligations becoming enforceable from 17 January 2025 + 24 months = 17 January 2025? (Note: the actual application date is 17 January 2025; the Regulation entered into force in January 2023, two years earlier). Today, in late 2025, DORA is fully part of the EU financial regulatory core, alongside:

• Capital & prudential frameworks (CRR/CRD, Solvency II, IFD/IFR, etc.)
• Market and conduct rules (MiFID II/MiFIR, UCITS, AIFMD, PRIIPs)
• Payments & banking rules (PSD2, EMD2, and the upcoming PSD3/PSR package)
• Cyber and data frameworks (NIS2, GDPR, Data Governance Act, Data Act)

Key idea:

• Pre‑DORA, ICT and cyber risk were treated as sub‑topics inside prudential or conduct rules.
• DORA elevates digital operational resilience into a standalone, horizontal pillar for the entire financial sector, with a unified set of rules.

In this module, you will:

• Map DORA’s obligations to other EU frameworks (GDPR, NIS2, PSD2, Data Governance Act, etc.).
• Understand the supervisory architecture (ESAs + national authorities + DORA Oversight Framework for critical ICT providers).
• See how Regulatory Technical Standards (RTS) and Guidelines convert DORA’s high‑level principles into detailed, enforceable expectations.

> Study tip: As you go, sketch a simple table with columns: DORA requirement → Closest GDPR/NIS2/PSD2/Data Act link → Potential tension or overlap.

2. From Capital Adequacy to Operational Resilience

Historically, EU financial regulation focused on capital adequacy and liquidity:

• CRR/CRD, Solvency II, IFD/IFR: ensure that banks, insurers, and investment firms can absorb losses and remain solvent.
• Operational risk was mainly treated via Pillar 2 requirements (internal governance, risk management) and capital add‑ons.

DORA’s shift:

• DORA does not set capital requirements.
• Instead, it imposes a comprehensive operational resilience framework that is:
• Technology‑centric (ICT risk throughout the lifecycle).
• Scenario‑driven (threat‑led penetration testing, severe disruption scenarios).
• Third‑party focused (ICT outsourcing, concentration risk, oversight of critical providers).

Think of it as moving from:

• "How much capital do you hold if your systems fail?" → to →
• "How do you prevent, withstand, respond to, and recover from ICT incidents so they do not disrupt financial stability?"

Key DORA pillars (reminder from Modules 1–2):

1. ICT risk management framework
2. ICT‑related incident reporting
3. Digital operational resilience testing
4. ICT third‑party risk management and register of ICT contracts
5. Oversight framework for critical ICT third‑party service providers (CTPPs)

These pillars sit alongside capital rules. A bank can meet all CRR/CRD ratios and still breach DORA if, for example, it lacks robust incident response or uses unmanaged critical cloud providers.

3. DORA vs. GDPR: Security, Data Breaches, and Role Conflicts

DORA and GDPR intersect heavily around security and incident response, but they have different primary objectives:

• GDPR (Regulation (EU) 2016/679): protects personal data and fundamental rights of individuals.
• DORA: protects the functioning and stability of the financial system via digital operational resilience.

3.1 Overlapping security obligations

• GDPR – Art. 32: requires "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk (encryption, pseudonymisation, resilience, backup, regular testing).
• DORA – Chapters II & III: require an ICT risk management framework and incident management (governance, mapping of assets, backup, logging, testing, business continuity, disaster recovery).

Mapping:

• DORA’s ICT risk management and testing support compliance with GDPR Art. 32 for personal data processed in financial services.
• However, DORA covers all ICT assets and data relevant to operations, not only personal data.

3.2 Incident notification: dual regimes

• GDPR: data controllers must notify the data protection authority within 72 hours of becoming aware of a personal data breach (Art. 33), and in some cases notify affected individuals (Art. 34).
• DORA: imposes standardised reporting of major ICT‑related incidents to financial supervisors (e.g. via the ESAs’ harmonised templates adopted in 2024–2025).

Edge case:

• A ransomware attack encrypts a bank’s core systems and likely compromises customer personal data.
• Under GDPR: this is a personal data breach → notify the Data Protection Authority (DPA) and possibly customers.
• Under DORA: this is a major ICT incident → notify the relevant financial supervisor using DORA templates.

Result: dual notification channels with different criteria and timelines, but for the same underlying event.

3.3 Role conflicts and tensions

• Data minimisation vs. log retention:
• DORA encourages extensive logging and monitoring (for forensics and resilience).
• GDPR requires data minimisation and storage limitation.
• Solution: design logging strategies with pseudonymisation, role‑based access, and retention limits that still satisfy DORA’s forensic needs.

• Data sharing in incident response:
• DORA encourages information sharing on cyber threats (e.g. via trusted communities).
• GDPR restricts sharing of personal data without a valid legal basis.
• Solution: share technical indicators (hashes, IPs, TTPs) that are not personal data, or ensure a lawful basis and safeguards when personal data is involved.

> Mental model: DORA asks, "Are your systems and services resilient?"; GDPR asks, "Are individuals’ data and rights protected?" You must satisfy both in parallel.

4. Quick Check: DORA vs. GDPR

Test your understanding of how DORA and GDPR interact.

5. DORA vs. NIS2: Sector‑Specific vs. Horizontal Cyber Rules

NIS2 Directive (EU) 2022/2555 modernised the EU cybersecurity framework and had to be transposed by Member States by October 2024. It covers essential and important entities in many sectors (energy, transport, health, digital infrastructure, etc.), including some financial entities.

But DORA is lex specialis for financial entities:

• NIS2 – Art. 4(3): where sector‑specific EU acts (like DORA) impose equivalent or more specific requirements, those acts prevail for the entities they cover.
• DORA explicitly positions itself as the sector‑specific regime for financial services’ digital operational resilience.

5.1 Overlaps

Both DORA and NIS2 require:

• Risk‑based cybersecurity measures
• Business continuity and disaster recovery planning
• Incident reporting to competent authorities
• Supply‑chain/third‑party risk management

5.2 Key differences

• Scope:
• NIS2: broad range of sectors; some financial entities may be included as essential or important entities.
• DORA: all EU‑regulated financial entities (banks, insurers, investment firms, payment institutions, crypto‑asset service providers under MiCA, etc.) + their ICT third‑party providers (via contractual obligations and CTPP oversight).

• Supervision:
• NIS2: national cybersecurity authorities / CSIRTs.
• DORA: financial supervisors (national competent authorities, ESAs) + joint oversight for critical ICT providers.

• Level of detail:
• DORA is more granular for financial entities (e.g. specific ICT testing, classification of incidents, central register of ICT contracts).

5.3 Edge cases

• A cloud provider that serves both financial and non‑financial sectors:
• For financial clients, DORA obligations are channelled via contracts and, if designated as a CTPP, via direct oversight by an ESA‑led Oversight Forum.
• For non‑financial critical sectors, NIS2 obligations apply via national authorities.
• Result: the provider faces two regulatory logics and must reconcile them in its controls and reporting processes.

> Key takeaway: For financial entities, DORA generally displaces NIS2 as the primary cyber/ICT regime, but NIS2 can still apply to certain shared service providers or non‑financial parts of a group.

6. DORA and PSD2: Payments, Strong Customer Authentication, and Incident Reporting

PSD2 (Directive (EU) 2015/2366) governs payment services, including Strong Customer Authentication (SCA), secure communication, and incident reporting for payment service providers (PSPs). While PSD2 is being updated by PSD3 and the Payment Services Regulation (PSR) (legislative work advanced in 2023–2025), PSD2‑based rules still apply in late 2025.

6.1 Complementarity

• PSD2 focuses on:
• Payment security (SCA, secure communication for APIs)
• Consumer protection and liability for unauthorised transactions
• Operational and security risk management specific to payment services

• DORA focuses on:
• Enterprise‑wide ICT risk management across all services (not only payments)
• Unified incident classification and reporting for the whole financial entity
• Testing and third‑party risk management (including cloud for payment systems)

6.2 Incident reporting overlaps

• Under PSD2, PSPs must notify major operational or security incidents to their national competent authority (NCA), typically using the EBA Guidelines on incident reporting.
• Under DORA, PSPs (as financial entities) must report major ICT‑related incidents under harmonised DORA templates.

In practice, the ESAs have worked to align PSD2 and DORA incident reporting, but full harmonisation is complex. A single incident may:

• Trigger PSD2 reporting (payment disruption, fraud impacts), and
• Trigger DORA reporting (material ICT disruption at entity level).

6.3 Strong Customer Authentication (SCA)

• SCA requirements (under PSD2 RTS on SCA & secure communication) remain the primary source for authentication in payments.
• DORA does not redefine SCA; instead, it:
• Requires governance, testing, and resilience of the systems implementing SCA.
• Demands that third‑party providers involved in SCA (e.g. authentication service providers, biometric solution vendors) are properly managed under the DORA ICT third‑party risk framework.

> Analytical point: For a payment institution, PSD2 and DORA are mutually reinforcing: PSD2 defines what security features payments must have; DORA defines how robustly the underlying ICT environment must be managed and tested.

7. Mapping Exercise: DORA vs. GDPR, NIS2, PSD2, and Data Governance Act

Use this thought exercise to actively map DORA to other EU frameworks.

Task A – Classify the primary regime

For each scenario below, decide which regime is primary and which are supporting/parallel. Write down your reasoning.

1. Scenario 1 – Payments outage with data breach

A payment institution in the EU suffers a DDoS attack on its payment API, causing 12 hours of outage. Logs show possible exfiltration of personal data from the payments database.

• Which regimes are triggered? (DORA, GDPR, PSD2, NIS2?)
• Which is sector‑specific?
• How would you sequence notifications?

1. Scenario 2 – Cloud provider failure

A large cloud provider hosting core banking systems for several EU banks experiences a prolonged regional outage due to a configuration error. No personal data is exfiltrated.

• Which entities are directly under DORA? Which under NIS2?
• How does the DORA CTPP oversight change the picture if this provider has been designated as critical?

1. Scenario 3 – Data altruism platform

A data intermediary registered under the Data Governance Act (DGA) facilitates sharing of anonymised financial transaction data for research. Some data comes from EU banks.

• How does DORA affect the banks’ decision to provide data?
• How do GDPR and DGA requirements interact on anonymisation and consent?

Task B – Create a mini‑matrix

Draw a 4×4 table (on paper or digitally) with rows = DORA pillars and columns = GDPR, NIS2, PSD2, DGA/Data Act. Fill one cell per intersection with a short phrase (e.g. "Incident reporting templates align", "Tension: log retention vs. minimisation").

Reflect: Which pillar has the densest overlaps? (Hint: often ICT incident reporting and third‑party risk.)

8. DORA and the New EU Data Laws: Data Governance Act & Data Act

Two major horizontal data laws entered the EU landscape around DORA:

• Data Governance Act (DGA) – Regulation (EU) 2022/868: applied from September 2023.
• Data Act – Regulation (EU) 2023/2854: entered into force in January 2024 and has been phasing in since 2025.

8.1 Data Governance Act (DGA)

The DGA aims to:

• Facilitate data sharing (including public sector data reuse, data altruism, and data intermediaries).
• Create trusted mechanisms and a framework for data intermediaries.

For financial entities:

• DORA requires robust ICT governance, security, and third‑party risk management for any data sharing infrastructure (APIs, platforms, intermediaries) used.
• If a financial entity uses a data intermediary under the DGA, DORA’s ICT third‑party requirements (due diligence, contractual clauses, monitoring) still apply.

8.2 Data Act

The Data Act introduces:

• Access and portability rights for users to data generated by connected products and related services.
• Rules on business‑to‑business (B2B) and business‑to‑government (B2G) data sharing.
• Provisions on cloud switching and interoperability.

For DORA:

• Cloud switching and interoperability obligations under the Data Act intersect with DORA’s focus on concentration risk and exit strategies for ICT providers.
• A DORA‑compliant exit strategy for a critical cloud provider must be consistent with Data Act obligations (e.g. switching assistance, limits on egress fees).

Edge case:

• A bank uses IoT‑based telematics data (from connected vehicles) to underwrite insurance. Under the Data Act, users may have rights to share this data with third parties. Under DORA, the bank must ensure that any new data flows and third‑party interfaces are covered by its ICT risk management and testing regime.

> Synthesis: DORA ensures that whatever data sharing or cloud usage is allowed or encouraged by the DGA and Data Act is done in a secure, resilient, and well‑governed manner within financial institutions.

9. Supervisory Architecture: ESAs, NCAs, and Critical ICT Providers

DORA’s enforcement relies on a multi‑layered supervisory structure.

9.1 European Supervisory Authorities (ESAs)

• EBA – European Banking Authority
• ESMA – European Securities and Markets Authority
• EIOPA – European Insurance and Occupational Pensions Authority

Under DORA, the ESAs:

• Develop Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) (e.g. on incident reporting, testing, third‑party registers).
• Issue Guidelines and Q&As clarifying expectations.
• Coordinate with national competent authorities (NCAs) and among themselves.
• Lead the Oversight Framework for critical ICT third‑party providers (CTPPs) via a joint Oversight Forum.

9.2 National Competent Authorities (NCAs)

• NCAs are the primary supervisors of individual financial entities under DORA (e.g. national central banks, financial supervisory authorities).
• They:
• Receive DORA incident reports.
• Review entities’ ICT risk management frameworks and testing programmes.
• Enforce sanctions and remedial measures.

The Single Supervisory Mechanism (SSM) for significant euro‑area banks integrates DORA into its supervisory review processes.

9.3 Oversight of Critical ICT Third‑Party Providers (CTPPs)

A key innovation of DORA is direct EU‑level oversight of certain ICT providers (e.g. large cloud or core banking platform providers) designated as critical.

• The ESAs, through a Joint Oversight Forum, conduct:
• Risk assessments of CTPPs.
• On‑site inspections and off‑site reviews.
• Recommendations to CTPPs and to the financial entities using them.

• Financial entities remain responsible for their own compliance, but:
• Must integrate CTPP oversight findings into their own risk management.
• May be instructed by supervisors to limit or terminate relationships with non‑compliant CTPPs.

> Comparison: This is more centralised and intrusive than typical GDPR or NIS2 supervision of processors and providers, reflecting the systemic importance of certain ICT providers for financial stability.

10. RTS, ITS, and Guidelines: How DORA’s High‑Level Rules Become Operational

DORA is a framework regulation. Its detailed application depends heavily on Level 2 and Level 3 instruments:

• Regulatory Technical Standards (RTS) – legally binding, specify technical requirements.
• Implementing Technical Standards (ITS) – legally binding, specify formats, templates, procedures.
• Guidelines & Recommendations – soft law, but create a strong expectation of compliance.

Between 2023 and 2025, the ESAs have adopted and updated a series of RTS/ITS under DORA, including (non‑exhaustive):

• RTS on ICT risk management framework.
• ITS on incident reporting templates and timelines.
• RTS on threat‑led penetration testing (TLPT).
• RTS on criteria for designating CTPPs and oversight procedures.
• ITS on registers of ICT third‑party contracts.

Why this matters for you as a practitioner or analyst:

• The Regulation text gives high‑level obligations (e.g. "ensure appropriate ICT security").
• The RTS/ITS tell you concretely what that means (e.g. specific categories of incidents to report, granularity of asset mapping, frequency of tests).

> Advanced point: In conflicts or overlaps, RTS/ITS under DORA may effectively shape how entities implement GDPR, NIS2, or PSD2 security provisions in the financial context, even if those other acts are not formally amended.

In complex groups, compliance teams increasingly build integrated control frameworks that:

• Start from DORA RTS/ITS for ICT risk and incident management.
• Map controls to GDPR Art. 32, NIS2 requirements, PSD2 security guidelines, and relevant data‑law obligations.

This is why reading only the DORA Regulation is insufficient; you must track ESA outputs continuously.

11. Review Key Terms and Relationships

Flip the cards (mentally) and test whether you can explain each concept in your own words.

12. Final Check: Applying the Landscape View

One more scenario to consolidate your understanding of DORA’s place in the EU regulatory ecosystem.