GDPR, NIS2 and DORA: How the Three EU Regimes Intersect

Most European organisations did not choose to comply with three overlapping digital regulations at once. They simply arrived, one at a time, each drafted by a different part of the EU machine, each with its own authorities, its own deadlines, and its own vocabulary for what is often the same underlying obligation.

The GDPR has governed personal data since 2018. NIS2 has governed cybersecurity risk management for essential and important entities since national transposition deadlines in 2024. DORA has governed digital operational resilience for the financial sector since January 2025. Three regimes, drafted separately, now operating on the same organisations, the same systems, and frequently the same incidents.

This guide maps where they intersect — and where treating them as three unrelated compliance projects wastes effort or, worse, creates gaps. For the NIS2 and DORA detail, start with the complete NIS2 and DORA compliance guide; this page adds the third regime and the connective tissue.

This is not legal advice. National transpositions of NIS2 vary, and all three regimes continue to be refined — including by the proposed Digital Omnibus.

The three regimes in one paragraph each

GDPR — Regulation (EU) 2016/679. Protects the personal data of individuals. Applies to any organisation processing personal data of people in the EU, regardless of the organisation's size or sector. Enforced by national data protection authorities. The protected interest is the individual's fundamental rights.

NIS2 — Directive (EU) 2022/2555. Requires cybersecurity risk management and incident reporting from essential and important entities across 18 sectors above a size threshold. Transposed into national law in each member state, enforced by national competent authorities and CSIRTs. The protected interest is the security and continuity of network and information systems supporting critical services.

DORA — Regulation (EU) 2022/2554. Requires digital operational resilience from financial entities. Directly applicable across the EU, enforced by financial supervisors. The protected interest is the operational resilience of the financial system.

Three different protected interests. But the mechanisms — risk management, incident reporting, supplier oversight, governance — are strikingly similar, because there are only so many ways to regulate digital risk. That similarity is both the opportunity and the trap.

Where they apply — the overlap is real

The three regimes have different scope tests, and an organisation can easily fall under one, two, or all three.

Organisation	GDPR	NIS2	DORA
200-person SaaS provider handling customer data	✅	✅ (digital infrastructure / digital provider)	—
Regional bank	✅	Displaced by DORA	✅
80-person manufacturer of medical devices	✅	✅ (Annex II manufacturing)	—
Payment institution	✅	Displaced by DORA	✅
30-person marketing agency	✅	— (below threshold)	—
Hospital	✅	✅ (health, Annex I)	—

Two observations. First, GDPR is nearly universal — almost every organisation processes personal data, so GDPR is the regime with the widest reach. Second, NIS2 and DORA do not stack for financial entities: DORA is lex specialis, displacing NIS2's equivalent provisions for the entities it covers. The detail of that displacement is in NIS2 vs DORA: Key Differences.

GDPR, by contrast, is not displaced by either. A financial entity complying with DORA still complies with GDPR in full for its processing of personal data. A NIS2 essential entity still complies with GDPR. The three regimes are not a hierarchy with one winner — GDPR runs in parallel to whichever cybersecurity regime applies.

Intersection one: incident reporting — one event, multiple clocks

This is the intersection that causes the most operational pain, and the one the proposed Digital Omnibus is specifically trying to fix.

A single security incident involving personal data at a NIS2 essential entity can trigger:

• A GDPR personal data breach notification to the data protection authority — currently within 72 hours of becoming aware, where the breach poses a risk to individuals' rights
• A NIS2 significant incident report to the CSIRT — the 24-hour early warning, 72-hour notification, 30-day final report cadence
• For a financial entity, a DORA major ICT-related incident report to the financial supervisor — the initial / intermediate / final cadence

Same incident. Up to three authorities. Three templates. Three clocks, none of them aligned. The GDPR clock and the NIS2 clock both reference "becoming aware" but measure different things — GDPR measures awareness of a personal data breach, NIS2 measures awareness of a significant incident, and an event can be one without being the other.

The practical defence is a single incident record with parallel reporting workflows. One internal source of truth about the incident; separate, pre-built reporting templates that draw from it for each regime. Maintaining one record avoids the contradiction risk — the situation where the GDPR notification and the NIS2 report describe the same incident inconsistently, which competent authorities notice and which undermines both.

The full reporting mechanics are in the reference layer: NIS2 Incident Reporting: The 24-72-30 Day Timeline. The dedicated cross-regime treatment — including how to operate the three clocks together — is in GDPR Breach Notification vs NIS2 and DORA.

A forward note: the Digital Omnibus proposes a single EU incident-reporting entry point — "report once, share many" — routing notifications across NIS2, GDPR, DORA, eIDAS and CER. If adopted and built, it would collapse much of this friction. It is a proposal, not law; see the analysis in Report Once, Share Many: What the Digital Omnibus Actually Changes.

Same controls, three regulators. Photo: Markus Spiske / Unsplash.

Intersection two: security measures — the same controls, three times

All three regimes require security measures, and the measures substantially overlap.

GDPR Article 32 requires "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk — explicitly mentioning encryption, confidentiality, integrity, availability, resilience, and the ability to restore data after an incident. NIS2 Article 21 sets out its 10 risk management measures. DORA's Pillar 1 sets out its ICT risk management framework across Articles 5 to 14.

Read side by side, the three lists are not three different security programmes. They are three regulatory descriptions of one security programme. Encryption appears in all three. Backup and restoration appears in all three. Access control appears in all three. Incident handling appears in all three.

The implication for compliance design is significant: an organisation should build one security control set and map it to all three regimes, rather than running three parallel security projects. The mapping exercise — one control, three regulatory citations — is itself the artefact that demonstrates coherent compliance. The reference layer breaks down the NIS2 controls in NIS2 Article 21: All 10 Risk Management Measures Explained and the DORA framework in DORA ICT Risk Management Framework Explained.

The differences are at the edges, and they matter. GDPR's security obligation is specifically about protecting personal data and is risk-assessed against harm to individuals. NIS2's is about protecting services. DORA's is about operational resilience. The same encryption control serves all three, but the risk assessment that justifies its depth differs by regime — GDPR asks "what is the risk to the data subject," NIS2 and DORA ask "what is the risk to the service or the system." A coherent programme runs one control set and three risk lenses.

Intersection three: supply chain and processors

All three regimes regulate the organisations you depend on — and again, the obligations overlap.

GDPR Article 28 governs data processors — any third party processing personal data on your behalf. It requires a written contract with prescribed terms, processor due diligence, and controller accountability for processor compliance. NIS2 Article 21(2)(d) governs supply chain security for direct suppliers and service providers. DORA Articles 28 to 30 govern ICT third-party risk with a prescribed contractual regime and the mandatory Register of Information.

A single cloud provider hosting personal data for a financial entity is simultaneously a GDPR processor, a NIS2 supplier (if NIS2 applies), and a DORA ICT third-party provider. Three regimes, three sets of contractual requirements, one vendor relationship.

The efficient approach is a unified third-party programme: one supplier register, tiered by criticality and by data sensitivity, with contracts that satisfy the strictest applicable regime. For a financial entity, that strictest regime is usually DORA — a contract meeting DORA Article 30 will generally also satisfy GDPR Article 28 and NIS2 Article 21(2)(d), provided the GDPR-specific processor terms are included. The reverse is not true: a GDPR-compliant processor contract does not automatically meet DORA's prescribed provisions.

The reference layer covers each: NIS2 Supply Chain Security, DORA Third-Party Oversight, and DORA Register of Information. The GDPR-specific processor due diligence, and how to fold it into one programme, is in Data Processor Due Diligence: GDPR Article 28 Meets NIS2 Supply Chain.

Intersection four: governance and accountability

The three regimes all push responsibility upward, toward management — though they do it differently.

GDPR builds in accountability as a core principle (Article 5(2)) — the controller must not only comply but be able to demonstrate compliance — and requires a Data Protection Officer for certain organisations (Article 37). NIS2 Article 20 makes the management body approve and oversee risk management measures and undergo training. DORA Articles 5 and 6 make the management body own the ICT risk management framework with prescribed, article-level responsibilities.

The three governance regimes can be operated as one board-level function. A management body that has a standing cybersecurity-and-data agenda — covering GDPR accountability, NIS2 oversight, and DORA framework approval in one quarterly rhythm — satisfies all three more coherently than three separate governance tracks. The detail of the NIS2 and DORA management obligations, including the country-by-country variation in personal liability, is in NIS2 Board-Level Accountability: Personal Liability Explained.

One structural note: the GDPR's Data Protection Officer and a cybersecurity lead are different roles with different independence requirements. The DPO has a statutory independence — they advise and monitor, and cannot be instructed on how to perform their tasks or penalised for performing them. Folding the DPO into a general compliance or security role can compromise that independence. Unify the governance rhythm; do not unify the DPO role out of existence.

Where the regimes genuinely conflict

Overlap is mostly an efficiency opportunity. But there are a few genuine tension points worth naming.

Data minimisation versus security logging. GDPR's data minimisation principle pushes toward collecting and retaining less personal data. NIS2 and DORA's detection and incident-handling obligations push toward extensive logging, which often contains personal data (IP addresses, user identifiers, access records). The resolution is lawful-basis discipline — security logging has a legitimate-interest or legal-obligation basis under GDPR — but the retention period for security logs must be deliberately set, not left indefinite, and documented as a balancing decision.

Breach transparency versus investigation integrity. GDPR may require notifying affected individuals of a breach. An active NIS2 or DORA incident investigation, or a law-enforcement request, may create pressure to delay public disclosure. The regimes can be reconciled, but the timing requires legal judgement, not a default.

Encryption as a get-out versus encryption as a baseline. Under GDPR, strong encryption of breached data can remove the obligation to notify individuals (though not necessarily the authority). Under NIS2 and DORA, encryption is simply a baseline expected control. The same control has different legal consequences in each regime — useful to know when assessing a breach.

One programme, one governance forum. Photo: Nastuh Abootalebi / Unsplash.

Building one programme for three regimes

The practical synthesis for an organisation in scope of two or three regimes:

1. One control set, three mappings. Build the security programme once; map each control to GDPR Article 32, NIS2 Article 21, and DORA Pillar 1 as applicable.
2. One incident record, parallel reporting. Maintain a single internal incident record; pre-build separate reporting templates for each regime's authority and clock.
3. One third-party programme, strictest-regime contracts. One supplier register; contracts meeting the strictest applicable regime, with regime-specific clauses (GDPR processor terms, DORA Article 30 provisions) layered in.
4. One governance rhythm, distinct DPO independence. A unified board-level cybersecurity-and-data agenda; but preserve the DPO's statutory independence as a separate role.
5. Three risk lenses, deliberately applied. The same control, assessed for risk to data subjects (GDPR), to services (NIS2), and to operational resilience (DORA).

This is more efficient than three parallel programmes, and — crucially — it is also more coherent. Regulators across all three regimes respond well to evidence of an integrated approach, because fragmentation is itself a risk indicator.

Frequently asked questions

If DORA displaces NIS2 for my financial entity, does it also displace GDPR? No. DORA is lex specialis relative to NIS2 only. GDPR applies in full to a financial entity's processing of personal data, alongside DORA.

Do I report a personal data breach under GDPR or NIS2? Potentially both. A security incident involving personal data at a NIS2 entity can be both a GDPR personal data breach and a NIS2 significant incident, triggering separate notifications to different authorities.

Can one contract satisfy GDPR, NIS2 and DORA for a supplier? Yes, if drafted to the strictest applicable regime. For a financial entity, a DORA Article 30-compliant contract with GDPR Article 28 processor terms included generally satisfies all three.

Is the DPO the same as the CISO or the NIS2 compliance lead? They can be related but should not be merged. The DPO has statutory independence under GDPR that a CISO or compliance lead does not — merging the roles can compromise that independence.

Does GDPR have a size threshold like NIS2? No. GDPR applies to any organisation processing personal data of individuals in the EU, regardless of size. NIS2 has a medium-enterprise threshold; DORA has no size floor for financial entities.

Will the Digital Omnibus merge these three regimes? No — it proposes to align and reduce overlap, notably via a single incident-reporting entry point, not to merge the regimes. And it is a proposal, not law. See Report Once, Share Many.

The bottom line

Three takeaways:

1. The three regimes overlap by design of circumstance, not intent. They were drafted separately but regulate the same digital risk, so the mechanisms converge.
2. Build once, map three times. One control set, one incident record, one third-party programme, one governance rhythm — each mapped to all applicable regimes.
3. Mind the genuine conflicts and the DPO independence. Most overlap is efficiency; a few tension points need deliberate legal judgement.

For the NIS2 and DORA detail this pillar builds on, see the complete NIS2 and DORA compliance guide. For the cross-regime incident-reporting mechanics, GDPR Breach Notification vs NIS2 and DORA.

---

Sources & further reading

• Regulation (EU) 2016/679 — GDPR — Articles 5, 28, 32, 33, 37
• Directive (EU) 2022/2555 — NIS2 — Articles 20, 21, 23
• Regulation (EU) 2022/2554 — DORA — Articles 5–14, 17–23, 28–30
• European Data Protection Board (EDPB) — guidance on personal data breach notification and on the controller/processor relationship
• European Commission — Digital Strategy: NIS2 directive — Digital Omnibus Package incident-reporting harmonisation