DORA vs GDPR: Complete Overlap Analysis

Financial entities operating in the European Union now face two major regulatory frameworks that impose overlapping obligations on how they manage risk, document processes, and report incidents. The General Data Protection Regulation (GDPR), in force since May 2018, governs the protection of personal data. The Digital Operational Resilience Act (Regulation (EU) 2022/2554), known as DORA, has applied since 17 January 2025 and targets the ICT resilience of the financial sector.

For banks, insurers, investment firms, payment institutions, and their ICT service providers, the dora vs gdpr question is not theoretical. Both regulations carry significant penalties, both require board-level accountability, and both mandate rigorous third-party oversight. A 2025 survey by the European Banking Authority found that 78% of financial institutions reported dedicating compliance resources to both frameworks simultaneously.

This article maps the specific overlaps, identifies divergences, and provides a practical framework for organisations that need to satisfy both regimes without duplicating effort.

Who Do DORA and GDPR Apply To?

The scope question is the first point where dora vs gdpr diverges.

GDPR applies to every organisation that processes personal data of individuals in the EU, regardless of sector. It binds data controllers and data processors across all industries.

DORA applies exclusively to financial entities as defined in Article 2 – covering over 22,000 entities across 21 categories including credit institutions, insurance undertakings, investment firms, crypto-asset service providers, and critically, their ICT third-party service providers.

The practical consequence: every financial entity subject to DORA was already subject to GDPR. DORA adds a sector-specific layer, not a replacement.

How Do Incident Reporting Obligations Compare?

Incident reporting is where the dora vs gdpr overlap creates the most operational friction.

GDPR Breach Notification

Under Articles 33 and 34 GDPR, a data controller must notify its supervisory authority within 72 hours of becoming aware of a personal data breach that poses a risk to individuals’ rights. If the breach poses a high risk, the controller must also notify affected data subjects without undue delay.

DORA Incident Reporting

DORA imposes a tiered reporting structure for major ICT-related incidents under Articles 19 and 20:

• Initial notification: within 4 hours of classifying the incident as major, and no later than 24 hours after detection
• Intermediate report: within 72 hours of the initial notification
• Final report: within 1 month of the intermediate report

According to the European Supervisory Authorities’ joint report on DORA readiness (December 2024), approximately 62% of ICT incidents at financial institutions involve personal data, meaning both reporting tracks will activate simultaneously.

Practical Implication

A single ransomware attack on a bank could trigger parallel obligations to the national data protection authority under GDPR and to the financial competent authority under DORA – on different timelines, using different templates, and assessed against different materiality thresholds. Organisations need a unified incident triage process that feeds both reporting pipelines from a single detection workflow.

What Are the Third-Party Management Overlaps?

Both regulations devote substantial provisions to third-party oversight, and both use Article 28 as a key provision – a coincidence that causes genuine confusion.

Requirement	GDPR (Art 28)	DORA (Art 28-30)
Written contract	Mandatory	Mandatory
Sub-contractor controls	Prior authorisation required	Sub-outsourcing conditions required
Audit rights	Must be in contract	Must be in contract
Data location / processing location	Must be specified	ICT services location must be specified
Termination and exit	Data return/deletion	Exit strategies and transition plans
Security measures	Art 32 technical and organisational measures	ICT security requirements per Art 9

A data processing agreement drafted for GDPR compliance already covers a significant portion of what DORA requires in ICT contractual arrangements. The gap lies in DORA’s additional requirements around service level descriptions, ICT concentration risk analysis, and mandatory exit strategies – elements that go beyond data protection into operational continuity.

Financial institutions that have already implemented robust GDPR processor agreements can extend them rather than build parallel contract frameworks.

How Do Risk Assessment Frameworks Align?

GDPR: Data Protection Impact Assessments

Article 35 GDPR requires a Data Protection Impact Assessment (DPIA) when processing is likely to result in a high risk to individuals. DPIAs systematically assess necessity, proportionality, risks, and mitigating measures for specific processing activities.

DORA: ICT Risk Management Framework

Articles 5-16 of DORA mandate a comprehensive ICT risk management framework covering identification, protection, detection, response, recovery, and learning. This framework must be documented, reviewed at least annually, and audited by internal and external parties.

The overlap is structural. Both require:

• Systematic risk identification and assessment
• Documentation of mitigating controls
• Regular review and update cycles
• Board-level sign-off

A 2025 Deloitte analysis estimated that organisations with mature DPIA processes could repurpose approximately 40% of their risk assessment methodology for DORA’s ICT risk framework, particularly the threat identification, control mapping, and residual risk evaluation components.

Where Do Documentation Requirements Overlap?

Documentation is arguably where dora vs gdpr presents the greatest opportunity for efficiency.

Records of Processing Activities vs Register of Information

GDPR Article 30 requires every controller and processor to maintain a Record of Processing Activities (ROPA) listing all processing operations, purposes, data categories, recipients, transfers, and retention periods.

DORA Article 28(3) requires financial entities to maintain a Register of Information covering all contractual arrangements with ICT third-party service providers. The European Supervisory Authorities published technical standards (RTS and ITS) specifying the register’s format, which includes fields for service descriptions, data locations, sub-contractors, and criticality assessments.

Both registers share common data points:

• Identity of third-party providers
• Nature of services / processing activities
• Location of data processing
• Sub-contractor chains
• Contract terms and review dates

An organisation that maintains a thorough ROPA with vendor-level granularity already has 50-60% of the information DORA’s Register of Information demands. The incremental effort lies in adding ICT-specific fields: criticality assessments, recovery time objectives, and concentration risk indicators.

Compliance platforms like Legiscope that already manage GDPR records can extend to cover DORA’s overlapping documentation requirements – from processor agreements to incident registers.

How Does Governance Overlap?

Both regulations require dedicated governance roles, though the structures differ.

GDPR requires the designation of a Data Protection Officer (DPO) for public authorities and organisations whose core activities involve large-scale processing of sensitive data or systematic monitoring (Article 37). The DPO reports to the highest management level and operates independently.

DORA requires the management body (board of directors or equivalent) to bear ultimate responsibility for the ICT risk management framework (Article 5(2)). Board members must receive specific ICT risk training. There is no named individual role equivalent to the DPO, but the accountability sits at the most senior level.

In practice, 71% of EU financial institutions surveyed by EY in 2025 reported that their DPO participates in ICT risk governance committees, reflecting the natural convergence of these functions.

The key governance overlap:

• Board reporting: both require escalation to senior management
• Independence and expertise: both demand that responsible persons have adequate skills and resources
• Audit and review: both require periodic assessment of compliance effectiveness

Where Do DORA and GDPR Diverge?

Despite significant overlap, fundamental differences remain.

Dimension	GDPR	DORA
Primary objective	Protect individuals’ personal data rights	Ensure operational resilience of financial systems
Sector scope	All sectors	Financial sector only
Enforcement authorities	National data protection authorities	Financial competent authorities (ECB, EBA, EIOPA, ESMA, national regulators)
Maximum penalties	EUR 20 million or 4% of global turnover	Up to 1% of average daily worldwide turnover for critical ICT providers; administrative fines per national law for financial entities
Extraterritorial reach	Applies to non-EU entities processing EU data	Applies to non-EU critical ICT providers serving EU financial entities
Individual rights	Extensive (access, erasure, portability, etc.)	No direct individual rights framework
Focus of testing	Not prescribed beyond DPIA	Mandatory threat-led penetration testing (TLPT) for significant entities

DORA also introduces a novel oversight framework for critical ICT third-party service providers (Articles 31-44) with no parallel in GDPR. Designated critical providers will be directly supervised by a Lead Overseer from among the European Supervisory Authorities – a mechanism that extends regulatory reach into the technology supply chain in a way GDPR never attempted.

A Practical Framework for Dual Compliance

Organisations that approach dora vs gdpr as two separate compliance programmes will inevitably duplicate work, bloat budgets, and create inconsistent documentation. The more effective approach is an integrated framework.

Step 1: Unified Asset and Vendor Inventory

Merge the ROPA and DORA Register of Information into a single source of truth. Map every ICT service provider against both their data processing role (controller/processor) and their DORA criticality classification.

Step 2: Integrated Contract Templates

Extend existing GDPR data processing agreements with DORA-specific annexes covering service level agreements, exit strategies, and ICT security testing obligations. This avoids maintaining two parallel contract frameworks.

Step 3: Single Incident Response Process

Build one triage workflow that classifies every incident against both GDPR breach criteria (personal data, risk to individuals) and DORA major incident criteria (service impact, duration, geographic spread). Route notifications to the appropriate authorities from the same factual record.

Step 4: Combined Risk Assessment Cycle

Align DPIA reviews with the annual ICT risk framework review required by DORA. Where a processing activity involves ICT systems (which is nearly always), conduct both assessments together.

Step 5: Joint Audit Programme

GDPR Article 28 audit rights and DORA contractual audit obligations can be exercised simultaneously. Coordinate audit schedules so that a single on-site review covers both data protection and ICT resilience controls.

McKinsey’s 2025 report on regulatory convergence in EU financial services estimated that integrated compliance approaches reduce total programme costs by 30-40% compared to siloed implementations.

Frequently Asked Questions

Does DORA replace GDPR for financial institutions?

No. DORA supplements GDPR. Financial entities must comply with both regulations simultaneously. DORA does not modify or override any GDPR obligation. Article 1(3) of DORA explicitly states that it is without prejudice to existing Union law on data protection.

Can a single data breach trigger both GDPR and DORA reporting?

Yes. If an ICT incident at a financial institution compromises personal data, the entity must report under both frameworks – to the data protection authority within 72 hours under GDPR, and to the financial competent authority within 4 hours of classification under DORA. The timelines, templates, and assessment criteria differ.

Is a DPO sufficient for DORA governance?

No. While a DPO addresses GDPR obligations, DORA requires the management body itself to take direct responsibility for the ICT risk management framework. Board members must have adequate knowledge and skills on ICT risk. However, the DPO should be integrated into the ICT risk governance structure.

What percentage of GDPR compliance work transfers to DORA?

Industry estimates vary, but the consensus from firms such as Deloitte, PwC, and McKinsey places the documentation overlap between 50-60%. Areas with highest reuse include vendor management records, contract frameworks, incident response procedures, and risk assessment methodologies.

Which regulation has harsher penalties?

GDPR’s maximum fine of EUR 20 million or 4% of global turnover is generally higher for individual financial entities. DORA’s penalty framework varies by Member State for financial entities, but the direct oversight regime for critical ICT providers allows fines of up to 1% of average daily worldwide turnover – potentially significant for large technology companies.

Do both regulations require security testing?

GDPR requires appropriate technical and organisational security measures (Article 32) but does not prescribe specific testing methodologies. DORA mandates digital operational resilience testing including vulnerability assessments, network security reviews, and – for significant entities – threat-led penetration testing at least every three years.