DORA and GDPR: Navigating the Data Protection Intersection
Two Regulations, One Data Incident
At 3:47 AM on a Tuesday, a financial institution's security operations center detects unauthorized access to a database containing customer personal data and payment information. The breach is confirmed by 5:15 AM. The attacker exfiltrated records affecting approximately 40,000 customers.
Two regulatory clocks start simultaneously.
Under DORA Article 19, the institution must submit an initial notification to its national competent authority (NCA) — the financial supervisor — within four hours of classifying the incident as major. Under GDPR Article 33, the institution must notify the data protection authority (DPA) within 72 hours of becoming aware of a personal data breach.
Different regulators. Different timelines. Different notification formats. Different severity criteria. Overlapping but not identical scopes. And a single incident response team managing both under extreme time pressure.
This is not a theoretical scenario. Financial institutions experience an average of 2.3 reportable cybersecurity incidents annually. Of these, an estimated 40-60% involve personal data and therefore trigger obligations under both DORA and GDPR simultaneously. In 2025, 739 data compromises were recorded in the financial services sector — the highest of any industry for the second consecutive year.
Mapping the Intersections
DORA and GDPR were designed for different purposes: DORA governs operational resilience of ICT systems, while GDPR protects personal data. But in practice, the obligations overlap in six critical areas.
1. Incident Reporting: Two Clocks, Two Authorities
The most operationally complex intersection is incident reporting. The timelines, authorities, and severity criteria differ:
| Dimension | DORA (Art. 17-23) | GDPR (Art. 33-34) |
|---|---|---|
| Trigger | Major ICT-related incident | Personal data breach |
| Authority | Financial supervisor (NCA) | Data protection authority (DPA) |
| Initial notification | 4 hours from classification | 72 hours from awareness |
| Intermediate report | 72 hours | Not required |
| Final report | 1 month | Not specified (but documentation required) |
| Customer notification | Art. 23(2) for payment services | Art. 34 if high risk to individuals |
| Classification criteria | Business impact, duration, geographic spread | Risk to individuals' rights and freedoms |
| Format | Standardized template (ITS) | Variable by DPA jurisdiction |
The key operational challenge: a single data breach incident typically requires notification to the financial supervisor (within 4 hours), the DPA (within 72 hours), and potentially affected individuals (under GDPR Art. 34 if high risk, and under DORA Art. 23(2) for payment-related services). Three notification streams from one incident response team.
The DORA timeline is significantly tighter than GDPR's. An institution that designs its incident response process around GDPR's 72-hour window will miss DORA's 4-hour deadline by a wide margin. The practical implication: incident response processes must be calibrated to the most aggressive timeline — DORA's — with GDPR notifications incorporated as a subsequent workstream.
2. Evidence Retention vs Data Minimization
DORA's operational resilience framework generates enormous volumes of evidence: incident reports, test results, audit trails, third-party assessments, recovery documentation. Under DORA and broader supervisory expectations, this evidence must be retained for extended periods — typically 5-10 years — to demonstrate ongoing compliance and support supervisory examinations.
GDPR Article 5(1)(c) requires data minimization — personal data must be "adequate, relevant and limited to what is necessary." Article 5(1)(e) requires storage limitation — personal data kept for no longer than necessary.
The tension arises when DORA evidence contains personal data. An incident report documenting a data breach necessarily contains information about affected individuals. An audit trail of user actions in a banking system captures personal data about both employees and customers. Test results for business continuity may include sample production data.
| Evidence type | DORA retention need | Personal data content | GDPR tension |
|---|---|---|---|
| Incident reports | 5-10 years | Affected individual details | Retention vs minimization |
| Audit trails | 10 years | User actions, access logs | Retention vs storage limitation |
| Test results | 5 years | Sample customer data (if used) | Purpose limitation |
| Third-party assessments | Duration of relationship + 5 years | Contact persons, performance data | Proportionality |
| Evidence vault artifacts | 10 years | Variable | Case-by-case assessment |
The resolution is not to choose one regulation over the other but to implement data governance controls that satisfy both: pseudonymize personal data in evidence where possible, restrict access to evidence containing personal data, document the legal basis for retention (DORA compliance as legitimate interest under GDPR Art. 6(1)(f) or legal obligation under Art. 6(1)(c)), and implement automated purging of personal data from evidence when the retention period expires.
3. Information Sharing Under Pillar V
DORA Article 45 encourages financial entities to exchange cyber threat intelligence and information about tactics, techniques, and procedures. This information sharing arrangement — Pillar V — is designed to strengthen the collective resilience of the financial sector.
But threat intelligence shared between financial institutions may contain personal data: IP addresses of attack sources, email addresses used in phishing campaigns, identifiers of compromised accounts. GDPR restricts the processing and sharing of personal data, even when the purpose is legitimate.
Article 45(2) explicitly addresses this tension, stating that information sharing "shall take place within trusted communities of financial entities" and "shall be implemented in compliance with applicable rules on data protection." The regulation acknowledges the tension but does not resolve it — it instructs institutions to navigate both frameworks simultaneously.
Practical approaches to GDPR-compliant threat intelligence sharing include: sharing indicators of compromise (IOCs) without personal identifiers where possible, using TLP (Traffic Light Protocol) classification to control redistribution, implementing data sharing agreements that define GDPR roles (controller/processor) for shared data, and conducting Data Protection Impact Assessments (DPIAs) for information sharing arrangements.
4. Third-Party Data Processing
DORA Article 28-30 governs ICT third-party risk management, including contractual requirements for critical outsourcing. GDPR Article 28 governs data processor agreements. When an ICT third party processes personal data on behalf of a financial entity, both sets of contractual requirements apply.
The contractual obligations are complementary but not identical:
| Contractual requirement | DORA Art. 30 | GDPR Art. 28 |
|---|---|---|
| Data processing locations | Art. 30(2)(c) — specified locations | Art. 28(3)(a) — only on documented instructions |
| Sub-processing | Art. 30(2)(a) — prior approval | Art. 28(2) — prior written authorization |
| Audit rights | Art. 30(3)(e) — unrestricted access | Art. 28(3)(h) — audits and inspections |
| Termination/exit | Art. 28(8) — exit strategy required | Art. 28(3)(g) — deletion/return on termination |
| Security measures | Art. 30(2)(b) — in line with ICT risk | Art. 32 — appropriate technical/organizational measures |
| Breach notification | Art. 30(2)(e) — incident notification | Art. 33(2) — notify controller without undue delay |
Institutions should develop a unified contract template that satisfies both DORA and GDPR requirements, rather than maintaining separate addenda that may conflict.
5. Right to Erasure vs Audit Trail Integrity
GDPR Article 17 establishes the right to erasure ("right to be forgotten"). An individual can request deletion of their personal data when it is no longer necessary for the purpose for which it was collected.
DORA's audit trail requirements — and the broader supervisory expectation of maintaining immutable records of security events, access logs, and incident histories — create a direct tension. Deleting audit records that contain personal data to comply with an erasure request could compromise the integrity of the audit trail that DORA and supervisory examination depend on.
Article 17(3)(b) provides the resolution: the right to erasure does not apply where processing is necessary "for compliance with a legal obligation which requires processing by Union or Member State law." DORA constitutes such a legal obligation. An institution can lawfully decline an erasure request for personal data that is retained to comply with DORA requirements — provided it can demonstrate that the specific data is necessary for DORA compliance and not merely retained by inertia.
The key is specificity: "we need this data for DORA compliance" is not a blanket exemption. The institution must identify which specific DORA obligation requires the retention of which specific personal data records, and must delete the data when the DORA retention requirement expires.
6. Data Protection Impact Assessments for DORA Programmes
GDPR Article 35 requires a Data Protection Impact Assessment (DPIA) for processing operations that are "likely to result in a high risk to the rights and freedoms of natural persons." DORA compliance programmes that involve large-scale monitoring, testing with production data, or threat intelligence processing may trigger this requirement.
Specific DORA activities that may require DPIAs:
- Implementing user behavior analytics for insider threat detection (Art. 9)
- Processing production customer data in resilience testing environments (Art. 24-27)
- Establishing information sharing arrangements that include personal data (Art. 45)
- Deploying continuous monitoring systems that capture employee activity data
The Unified Notification Workflow
Institutions need a single incident response workflow that triggers the correct notifications under both DORA and GDPR based on the incident characteristics.
Hour 0-1: Detection and initial assessment. Security operations confirms the incident. Initial assessment determines: (a) Is this an ICT-related incident under DORA? (b) Does it involve personal data under GDPR? (c) What is the scope and severity?
Hour 1-4: DORA initial notification. If classified as a major ICT incident under DORA criteria, submit initial notification to the NCA. This notification focuses on operational impact, affected systems, and initial containment measures. Personal data aspects may be noted but are not the primary focus.
Hour 4-24: Parallel investigation. Investigate both the operational and data protection dimensions. Determine the number of affected individuals, the categories of personal data involved, and the likely consequences for data subjects. Begin preparing the GDPR notification to the DPA.
Hour 24-72: GDPR notification and DORA intermediate report. Submit GDPR Article 33 notification to the DPA within 72 hours. Submit DORA intermediate report to the NCA (also within 72 hours). These are separate submissions to separate authorities, but the underlying investigation supports both.
Hour 72+: Customer notification assessment. Assess whether customer notification is required under GDPR Art. 34 (high risk to individuals) and/or DORA Art. 23(2) (payment service-related incidents). If required, coordinate messaging to avoid contradictory communications.
Month 1: DORA final report. Submit the final incident report to the NCA, incorporating root cause analysis, remediation actions, and lessons learned. GDPR does not have an equivalent final report requirement, but the DPA may request additional information.
Regulatory Cooperation: The Emerging Framework
The European Systemic Risk Board (ESRB) facilitates dialogue between financial supervisors and data protection authorities to address the DORA-GDPR intersection. While formal cooperation frameworks are still developing, the direction is clear: regulators recognize that financial entities operate under both regimes and should not face contradictory obligations.
In practice, this means: NCAs and DPAs are developing shared understanding of incident classification to avoid conflicting severity assessments; ESAs and the EDPB (European Data Protection Board) are working toward consistent guidance on evidence retention periods; and the Lead Overseer framework for CTPPs will need to coordinate with DPA oversight of the same providers' data processing activities.
Actionable Takeaways
- Calibrate incident response to the 4-hour clock. Design your incident notification workflow around DORA's 4-hour timeline, not GDPR's 72 hours. An institution prepared for 4-hour notification will always meet the 72-hour deadline; the reverse is not true.
- Build a unified contract template. Merge DORA Art. 30 and GDPR Art. 28 requirements into a single third-party contract framework. Separate addenda create inconsistencies that become audit findings.
- Implement evidence pseudonymization. Where DORA evidence contains personal data, pseudonymize it at the point of collection where possible. This reduces GDPR friction throughout the evidence lifecycle without compromising DORA audit trail integrity.
- Document your legal basis for retention. For every category of evidence that contains personal data, document the specific DORA obligation that requires its retention and the planned deletion date. Generic claims of "regulatory compliance" are insufficient.
- Conduct DPIAs for monitoring and testing. Before deploying continuous monitoring, threat intelligence sharing, or testing with production data, complete a GDPR Article 35 assessment. The DPIA documents your compliance rationale and identifies mitigation measures.
For institutions navigating the 4-hour incident reporting clock, the dual DORA-GDPR notification challenge is particularly acute. Use our self-assessment tool to evaluate your preparedness across both frameworks.
This guide reflects DORA Regulation (EU) 2022/2554 and GDPR Regulation (EU) 2016/679 as applicable in Q1 2026. National implementations of both DORA penalty frameworks and GDPR enforcement practice vary by member state.