NIS2 vs DORA vs GDPR: Untangling EU Cybersecurity Regulation

Three regulations, three different questions

Most teams treat GDPR, NIS2 and DORA as one big compliance blob. They are not. Each answers a different question, and once you see the question, the scope falls into place.

• GDPR asks: are you handling personal data?
• NIS2 asks: do you run services that society depends on?
• DORA asks: are you a financial entity or an ICT provider serving one?

You can be in scope for all three, two, one, or none. A hospital processes patient data (GDPR), runs an essential service (NIS2), and is not a bank (no DORA). A payment institution hits all three. A small marketing agency usually only touches GDPR.

Let us take each one in turn, then map the overlaps.

GDPR: personal data, everyone

Regulation (EU) 2016/679, the General Data Protection Regulation, has applied since May 2018. It is the widest net of the three. If you process personal data of people in the EU, you are in scope, wherever you are hosted.

For security teams the relevant parts are:

• Article 32: security of processing. You must implement appropriate technical and organisational measures.
• Article 33: breach notification to the supervisory authority within 72 hours of becoming aware of a personal data breach.
• Article 34: notification to affected individuals when the breach is high risk.

The trap is that security telemetry itself contains personal data. IP addresses, email addresses, usernames and device identifiers are all personal data under GDPR. So the tooling you use to investigate incidents is also a processing activity you have to account for. We cover that angle in Why EU Data Hosting Matters for Security Tooling.

NIS2: essential and important entities

Directive (EU) 2022/2555, the second Network and Information Security directive, replaced the original NIS directive. Because it is a directive, not a regulation, it does not apply directly. Each member state transposes it into national law, and the details differ by country. The transposition deadline was 17 October 2024, though several states ran late.

NIS2 splits covered organisations into two tiers:

• Essential entities: energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, public administration, space.
• Important entities: postal services, waste management, chemicals, food, manufacturing of certain products, digital providers, research.

Both tiers face the same core obligations. The difference is mainly in supervision: essential entities get proactive oversight, important entities get reactive oversight (authorities act after an incident or complaint).

Core NIS2 duties:

• Risk management measures (Article 21): policies, incident handling, business continuity, supply chain security, encryption, access control.
• Incident reporting (Article 23): an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month.
• Management bodies are accountable and can be held personally liable.

Size matters here. NIS2 generally applies to medium and large entities in the listed sectors (the size-cap rule), though some entity types are covered regardless of size.

DORA: the financial sector, in detail

Regulation (EU) 2022/2554, the Digital Operational Resilience Act, applies from 17 January 2025. Unlike NIS2 it is a regulation, so it applies directly and uniformly across the EU with no national variation.

DORA covers financial entities: banks, payment institutions, investment firms, insurers, crypto-asset service providers, and more. It also reaches into their ICT third-party providers, and lets regulators designate some cloud and software providers as critical, subjecting them to direct oversight.

DORA has five pillars:

1. ICT risk management.
2. ICT-related incident management, classification and reporting.
3. Digital operational resilience testing, including threat-led penetration testing (TLPT) for the largest entities.
4. ICT third-party risk management.
5. Information sharing arrangements.

We break the engineering impact down in DORA Explained for Security Teams, and the vendor side in Third-Party Risk Management Without the Spreadsheet Nightmare.

The key relationship: DORA is lex specialis

Here is the part that trips people up. A bank is both a financial entity (DORA) and, under NIS2, an essential entity in the banking sector. Which rules on ICT risk and incident reporting apply?

DORA is lex specialis relative to NIS2. That legal principle means the more specific law wins over the general one. For the ICT risk management and incident reporting matters that DORA covers, financial entities follow DORA, not NIS2. NIS2 explicitly defers here to avoid double regulation. It does not mean a bank ignores NIS2 entirely, but for the overlapping ICT provisions, DORA governs.

GDPR sits on a different axis. It is not displaced by either NIS2 or DORA, because it protects a different interest (personal data rights, not service continuity). A single incident can trigger reporting under all applicable frameworks at once.

Where they collide: incident reporting

The overlap that causes the most operational pain is incident reporting, because the clocks differ and can run in parallel.

Imagine a payment institution suffers a breach where attackers exfiltrate customer records. That single event may require a GDPR Article 33 notification (personal data), a DORA major-incident report (financial ICT incident), and, depending on national transposition and the lex specialis carve-out, possibly a NIS2 touchpoint. The 24-hour DORA and NIS2 clocks start ticking before you have finished scoping. Build your incident response so the first hour produces the facts all three notifications need. Our First 60 Minutes checklist is written with that in mind.

Where they collide: risk management

All three expect a risk-based security programme, and the requirements rhyme:

• Governance and accountability at management level.
• Documented risk assessment.
• Access control, encryption, logging.
• Supply chain and third-party risk.
• Testing and continuous improvement.

If you build one solid ICT risk management programme, you cover most of the common ground. The frameworks diverge in the specifics (DORA's TLPT, NIS2's sector measures, GDPR's data-subject rights), not in the foundations.

A compliance priority order for mid-size companies

If you are a mid-size company staring at all three, here is a sane order.

1. GDPR first. It is almost certainly already in scope, it has been enforced since 2018, and the fines are real. If your data mapping, breach process and vendor agreements are shaky, fix them before anything else.

2. Work out your NIS2 status. Check whether your sector and size put you in the essential or important tier under your national transposition. If yes, map Article 21 measures against what you already run for GDPR. The gap is usually smaller than feared.

3. DORA only if you are a financial entity or serve one. If you are an ICT provider to banks, expect DORA obligations to arrive through your contracts even though the regulation does not name you directly. Read those clauses carefully.

4. Consolidate, do not duplicate. One risk register, one incident process with multiple notification branches, one third-party inventory. Three parallel compliance silos will bury your team and still leave gaps.

The regulations look tangled from the outside. From the inside they are three lenses on the same security programme: protect personal data, keep essential services running, and make the financial system resilient. Build the programme once, then report through whichever lenses apply.

Different laws, same discipline. Get the fundamentals right and compliance becomes a reporting exercise, not a rebuild.