One Ransomware Attack, Three Notification Deadlines, Two Regulators: The NIS2/GDPR Dual Compliance Playbook

At 3:47 AM, your security operations centre detects ransomware spreading across your file servers. Within twenty minutes, your incident commander confirms that customer records — names, email addresses, order histories — have been exfiltrated before encryption. Your on-call CISO and DPO are both woken up.

What happens next is not a single regulatory problem. It is three simultaneous notification deadlines, two separate regulatory tracks, and two different authorities waiting for two different documents — on different forms, through different portals, with different content requirements.

This is the NIS2/GDPR dual compliance problem. The NIS2 Directive gives your organisation 24 hours to file an early warning and 72 hours to submit a full incident notification to your national CSIRT or competent authority. The GDPR runs an entirely separate 72-hour clock for notification to your Data Protection Authority — plus an additional, open-ended obligation to notify affected individuals. Different recipients. Different content requirements. Different severity thresholds.

Most compliance guides treat these frameworks in isolation. This article maps the combined operational workflow that no current guidance covers fully: the dual-notification timeline matrix, the Article 35 coordination mechanism that connects both regulators, and the real penalty exposure when both frameworks are triggered by the same incident.

Two Frameworks, One Attack — Who Is Subject to Both?

Not every organisation carries dual notification obligations. The applicability matrix below clarifies which entities face parallel duties under NIS2 and GDPR simultaneously.

Organisation type	NIS2 applies?	GDPR applies?	Dual obligation risk
Essential entity (energy, health, digital infrastructure, water)	Yes — Article 3(1)	Yes — processes personal data	High
Important entity (postal, food, manufacturing, digital providers)	Yes — Article 3(2)	Yes — processes personal data	High
In-scope NIS2 entity processing no personal data	Yes	Unlikely	NIS2 only
SME below NIS2 thresholds (<50 staff, <€10M turnover)	Generally no	Yes, if processing personal data	GDPR only

The practical reality: the vast majority of essential and important entities under NIS2 also process personal data — customer records, employee credentials, authentication logs, patient data. A cyberattack on any of these organisations triggers both frameworks simultaneously the moment personal data is compromised or at risk. For CISOs and DPOs operating in the same organisation, that means shared accountability from the moment of detection.

NIS2 Article 23 — The Three-Stage Notification Obligation

The NIS2 incident reporting regime under Article 23 operates in three mandatory stages. Missing any stage is a separate compliance failure — not a single breach of one obligation.

Stage 1 — Early warning (within 24 hours of awareness): The entity must submit an early warning to its national CSIRT or NIS2 competent authority within 24 hours of becoming aware of a significant incident. This document must indicate whether the entity suspects the incident involves unlawful or malicious acts, and whether it has cross-border impact. No comprehensive analysis is required at this stage. The sole purpose is to put the authority on immediate notice.

There is no GDPR equivalent to this early warning. The 24-hour NIS2 obligation is unique and runs ahead of every GDPR deadline — making it the first compliance action your organisation must take regardless of what the GDPR clock is doing.

Stage 2 — Incident notification (within 72 hours of awareness): Within 72 hours, the entity provides a substantive initial notification that updates the early warning with an initial severity assessment, impact analysis, and indicators of compromise (IoCs). This is the document the CSIRT uses to evaluate response options and provide operational guidance. The authority must respond within 24 hours of receiving this notification with feedback and mitigation recommendations.

Stage 3 — Final report (within one month): A comprehensive final report, due within one month of the initial notification, must cover the full incident description, threat type and root cause, applied mitigation measures, and cross-border implications. For ongoing incidents, an interim progress report may substitute, followed by a final report within one month of resolution.

What qualifies as a significant incident?

Article 23 sets significance by two conditions, either of which is sufficient: (a) the incident has caused or is capable of causing severe operational disruption or financial loss; or (b) it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Potential impact qualifies — confirmed harm is not required. A contained ransomware attack with active exfiltration risk can trigger Article 23 obligations even before any data has verifiably left your environment.

GDPR Articles 33 and 34 — The Parallel Data Protection Track

The GDPR creates two overlapping notification obligations triggered by a personal data breach. Both are mandatory once the applicable threshold is met — there is no sequencing or choice between them.

Notification to the supervisory authority (Article 33): Where a personal data breach is likely to result in a risk to the rights and freedoms of individuals, the data controller must notify its competent Data Protection Authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it.” Where notification is delayed beyond 72 hours, the controller must explain the reason for the delay.

The Article 33 notification must include: the nature of the breach — categories and approximate number of personal data records and data subjects affected; DPO contact details; the likely consequences of the breach; and measures taken or proposed to address the breach and mitigate its effects. Where all information cannot be provided immediately, phased disclosure is permitted “without undue further delay.”

Communication to affected individuals (Article 34): Where the breach “is likely to result in a high risk” to individuals’ rights and freedoms — a higher threshold than Article 33 — the controller must also notify affected data subjects “without undue delay.” No fixed hour deadline applies here; the obligation runs concurrently with the supervisory authority notification, not after it.

Article 34 contains three exceptions that waive the individual notification requirement: the personal data was encrypted before the breach (rendering it unintelligible to unauthorised parties); subsequent action by the controller eliminated the high risk entirely; or individual notification would require disproportionate effort — in which case a public communication reaching affected parties equally effectively is required instead. The Data Protection Authority retains the power to override any claimed exception.

The threshold asymmetry — why this matters operationally:

NIS2 and GDPR use different notification thresholds, and conflating them is one of the most common dual-compliance errors. NIS2’s significant incident test focuses on operational disruption and potential damage to third parties. GDPR’s test focuses on risk to individual rights and freedoms. These are not the same assessment. An incident can be significant under NIS2 — causing severe service downtime with no personal data involved — without triggering any GDPR notification. Equally, a contained data breach affecting a limited number of records may trigger GDPR Article 33 notification while falling below the NIS2 significant incident threshold. Your incident triage must run both tests independently, in parallel, at detection.

The Dual-Notification Timeline Matrix

The table below maps the complete parallel obligation timeline for an incident that triggers both frameworks simultaneously — the highest-pressure operational scenario and the one most compliance teams are least prepared for.

Time from detection	NIS2 obligation	GDPR obligation	Recommended action
T=0 (Detection)	Incident response activation	Incident response activation	Activate unified incident log; trigger simultaneous NIS2 and GDPR triage; loop in CISO and DPO within one hour
T+2h	Preliminary significance assessment (Art. 23 threshold)	Preliminary personal data breach impact assessment (Art. 33 threshold)	CISO assesses operational disruption scope; DPO assesses personal data involvement and risk to individuals
T+24h	Early warning to CSIRT or competent authority — unlawful act flag, cross-border indicator (Art. 23(1)(a))	— No GDPR equivalent —	Security team files early warning; DPO reviews draft for factual consistency with anticipated GDPR content before submission
T+72h	Incident notification to CSIRT — severity assessment, operational impact, indicators of compromise (Art. 23(1)(b))	Notification to Data Protection Authority — breach nature, affected records, consequences, measures taken or planned (Art. 33)	Both filings dispatched simultaneously, drawn from the same unified incident log; cross-check both drafts for factual consistency before submission
T+days (as warranted)	— No NIS2 equivalent —	Individual notification to affected data subjects where high risk likely (Art. 34)	DPO assesses high-risk threshold; drafts plain-language communication; dispatches without undue delay; verify content does not contradict regulatory filings
T+30 days	Final report to CSIRT — root cause, full mitigation record, cross-border implications (Art. 23(1)(c))	Ongoing DPA correspondence and supplementary updates as requested	CISO compiles root cause analysis and remediation evidence; DPO confirms personal data resolution status; both outputs coordinated from unified incident log

The T+72h window is the highest-risk coordination point. Both the NIS2 initial notification and the GDPR supervisory authority notification are due simultaneously — to different regulatory bodies, on different forms, with different content requirements. Organisations without a unified incident log pull data from multiple disconnected sources under severe time pressure at this moment, producing the inconsistent narratives between NIS2 and GDPR filings that draw sustained regulatory follow-up. The NIS2 notification emphasises technical indicators and operational impact; the GDPR notification emphasises data subject impact and remedial measures. The factual substrate — what happened, when, what data was involved, what actions were taken — must be identical in both documents.

NIS2 Article 35 — How the Two Regulators Coordinate

Article 35 of the NIS2 Directive — “Infringements entailing a personal data breach” — is the most consistently overlooked provision in NIS2 GDPR overlap guidance. It defines the compulsory coordination mechanism between NIS2 competent authorities and GDPR supervisory authorities when the same incident crosses both frameworks, with direct implications for your organisation’s penalty exposure and notification strategy.

The mandatory authority coordination mechanism:

When a NIS2 competent authority discovers during supervision or enforcement that an entity’s infringement of Article 21 (security requirements) or Article 23 (reporting obligations) has caused or could cause a personal data breach as defined in GDPR Article 4(12), it must inform the GDPR supervisory authority “without undue delay.” Where the competent GDPR supervisory authority operates in a different Member State than the NIS2 competent authority, the competent authority must additionally notify the supervisory authority in its own Member State of the potential breach.

The practical implication for organisations under NIS2 investigation: your Data Protection Authority may receive information about your incident directly from the NIS2 competent authority — potentially before, or in parallel with, your own GDPR notification. Organisations that have not yet filed their Article 33 notification when the Article 35 coordination occurs face an unenviable position with the DPA. Proactive, timely notification under both frameworks, with a consistent incident narrative, eliminates this risk.

The double fine prohibition:

Article 35(2) creates a critical protection that most dual-compliance guides do not address. Where a GDPR supervisory authority has imposed an administrative fine under Article 58(2)(i) of the GDPR for the same conduct, the NIS2 competent authority “shall not impose an administrative fine pursuant to Article 34” for the same infringement. The prohibition on double fining for identical conduct is explicit in the directive text.

However, Article 35(2) explicitly preserves the NIS2 competent authority’s right to impose non-monetary enforcement measures set out in Articles 32(4), 32(5), and 33(4). These include: binding instructions to implement specific security measures; compliance audit requirements imposed at the entity’s expense; temporary suspension of relevant certifications; and — in the most serious cases — temporary bans on named individuals from exercising management functions within the entity. A GDPR fine eliminates the NIS2 administrative fine for overlapping conduct; it does not eliminate NIS2 enforcement.

The directional asymmetry:

The Article 35 double fine prohibition runs in one direction only. A GDPR fine imposed for the same conduct prevents the NIS2 administrative fine. The reverse is not true — a NIS2 fine does not prevent a subsequent GDPR fine. Additionally, where regulators characterise the security management failure (NIS2 Article 21 liability) and the notification failure (GDPR Article 33 liability) as separate, distinct violations rather than a single continuous infringement, both fines may apply simultaneously. This characterisation depends on the specific facts of the incident, making timely and consistent dual notification the most reliable way to manage this risk.

Penalty Exposure — The Real Risk Picture

Understanding the combined NIS2 penalties and GDPR fine landscape requires precision about both maximum figures and the Article 35 moderating mechanism. The numbers are significant; the interaction between them is equally important.

NIS2 administrative fines (Article 34):

• Essential entities: maximum EUR 10,000,000 or 2% of total worldwide annual turnover in the preceding financial year, whichever is higher
• Important entities: maximum EUR 7,000,000 or 1.4% of worldwide annual turnover, whichever is higher

GDPR administrative fines (Article 83):

• Article 83(5) — violations of core processing principles, data subject rights, or international transfer rules: maximum EUR 20,000,000 or 4% of global annual turnover, whichever is higher
• Article 83(4) — violations of controller/processor obligations, including failure to notify under Article 33: maximum EUR 10,000,000 or 2% of global annual turnover, whichever is higher

The EUR 30M theoretical ceiling and what it actually means:

The theoretical combined maximum — EUR 10M under NIS2 Article 34 plus EUR 20M under GDPR Article 83(5) — totals EUR 30M for a large essential entity that fails catastrophically under both frameworks simultaneously. In practice, Article 35’s double fine prohibition means the NIS2 administrative fine is waived where a GDPR fine covers the same underlying conduct. The realistic worst-case scenario for overlapping conduct is the higher of the two applicable fines — most likely the GDPR Article 83(5) maximum — plus NIS2 non-monetary enforcement measures that remain fully available regardless.

The EUR 30M combined exposure becomes more realistic where regulators treat the security failure and the notification failure as separate, distinct violations: a security management infringement under NIS2 Article 21 resulting in a EUR 10M fine, combined with a separate GDPR Article 33 notification failure resulting in a EUR 10M fine under Article 83(4). Neither violation is the same conduct as the other, so Article 35’s protection does not apply. This distinction underscores why timely notification under both frameworks is not merely a procedural requirement — it is a substantive penalty mitigation measure.

Management personal liability under NIS2 Article 20:

NIS2 uniquely holds management bodies personally accountable for approving and actively overseeing cybersecurity risk management measures. Article 20 requires management to participate in relevant cybersecurity training and to take direct responsibility for the entity’s compliance. Where enforcement finds that management ignored reported security risks or failed to implement required measures, individual managers can face temporary bans from exercising management functions within the entity. The GDPR imposes no equivalent personal sanction on named individuals.

Building an Integrated Dual-Notification Workflow

The dominant failure mode in NIS2 GDPR incident reporting is the bifurcated response: the security team manages the NIS2 track in isolation; the privacy or legal team manages the GDPR track separately; neither knows what the other has submitted until after both authorities have been notified — sometimes with inconsistent accounts of the same incident. Inconsistent narratives between NIS2 and GDPR filings are the single most reliable predictor of sustained regulatory follow-up.

Step 1 — Unified detection triage (T=0 to T+2h)

Incident detection triggers a single unified intake process running both NIS2 and GDPR severity assessments in parallel. The triage checklist answers three questions simultaneously: Does this qualify as a significant incident under NIS2 — service disruption, financial loss, or damage to others? Does it involve personal data? If yes, is it likely to create risk to the rights and freedoms of individuals? These three assessments, completed within the first two hours, determine the notification path for both frameworks. Both CISO and DPO must be engaged at this stage — not sequentially.

Step 2 — Unified incident log creation (T+2h)

Both regulatory tracks draw from a single incident log created at triage. This document records: timestamp of detection and the moment of awareness; technical details of the attack vector and indicators of compromise; categories and approximate numbers of affected personal data records and data subjects; containment and remediation actions taken with timestamps; and escalation decisions. This log is the single source of truth for both the NIS2 and GDPR submissions. The fifteen minutes spent creating a shared log at T+2h eliminates the inconsistency risk that produces months of regulatory correspondence.

Step 3 — NIS2 early warning filing (T+24h)

The security team files the early warning to the national CSIRT or competent authority. Content is deliberately minimal: confirmation of the incident, suspected unlawful act flag, cross-border impact indicator. The DPO reviews the early warning draft before submission to verify that the incident description is consistent with anticipated GDPR content. Contradictions at the early warning stage — before the GDPR clock is anywhere near expiry — are entirely preventable with a fifteen-minute review.

Step 4 — Parallel 72-hour submissions (T+72h)

The CISO team submits the NIS2 initial notification to the national CSIRT portal; the DPO submits the GDPR personal data breach notification to the DPA portal — simultaneously. Both documents draw from the unified incident log. A brief cross-check of both final drafts before submission — comparing the incident description, scope, affected data, and remediation narrative — takes under thirty minutes and eliminates the inconsistency risk that triggers follow-up queries. The NIS2 document leads with technical indicators and operational impact; the GDPR document leads with data subject impact and remedial measures. The underlying facts — what happened, when, what was compromised, what actions were taken — must be identical.

Step 5 — Individual notification assessment (GDPR Article 34, as warranted)

After the DPA filing, the DPO determines whether the breach meets the Article 34 “high risk” threshold for individual notification. Where it does, a plain-language communication is drafted and dispatched without undue delay. This communication must be reviewed against both regulatory filings — a public-facing statement that contradicts what was reported to the DPA creates a secondary compliance problem that is entirely avoidable.

Step 6 — NIS2 final report and GDPR resolution (T+30 days)

The CISO compiles the comprehensive NIS2 final report covering root cause analysis, full technical narrative, applied mitigation measures, and cross-border implications. The DPO confirms the personal data resolution status: whether affected individuals have been notified, whether residual risks have been eliminated, and whether supplementary DPA correspondence is required. Both deliverables are coordinated from the same unified incident log and reviewed for consistency before submission.

Role-Specific Action Plan

Different roles carry distinct obligations under the dual framework. Building this role map into your NIS2 compliance checklist and your GDPR incident response procedure — before an incident occurs — is the most efficient single investment in dual-compliance readiness.

Role	NIS2 obligation	GDPR obligation	Pre-incident action
CISO / IT Security	File 24h early warning; lead 72h initial notification; compile 30-day final report	Provide technical incident log to DPO; support personal data breach impact assessment	Build early warning template; establish unified incident log format; confirm CSIRT portal access and credentials
Data Protection Officer	Review NIS2 submissions for factual consistency with GDPR position	File 72h DPA notification; assess high-risk individual notification threshold; maintain Article 30(5) breach register	Build GDPR Article 33 notification template; confirm DPA portal access; agree incident triage triggers with CISO
Compliance Officer / Legal	Monitor NIS2 competent authority correspondence; document enforcement timeline for audit trail	Monitor DPA correspondence; recognise and respond to Article 35 coordination signals from NIS2 competent authority	Establish single audit trail covering both regulatory tracks; prepare Article 35 response protocol
Board / Management	Approve cybersecurity risk management framework (Art. 20); receive incident briefings; complete NIS2 cybersecurity training	Overall accountability for data protection governance; approve escalation thresholds	Review and formally approve dual-notification policy; set incident escalation thresholds that trigger both regulatory tracks simultaneously

Frequently Asked Questions

Does every NIS2 significant incident require a GDPR notification?

No. GDPR Article 33 notification applies only where the incident involves a personal data breach and is likely to result in a risk to the rights and freedoms of natural persons. A NIS2 significant incident affecting only operational systems — without any access to or exfiltration of personal data — does not trigger GDPR notification. Run both triage assessments independently at detection.

Does every GDPR personal data breach require a NIS2 notification?

Not automatically. Two conditions must both be met: the organisation must be an essential or important entity under NIS2; and the incident must qualify as a significant incident under Article 23 — severe operational disruption, financial loss, or considerable damage to others. A contained data breach involving a small number of records, with no service disruption and no cross-border impact, may trigger GDPR Article 33 notification while falling below the NIS2 significant incident threshold.

Can we file a single notification to satisfy both obligations?

No. NIS2 notifications go to the national CSIRT or designated competent authority for cybersecurity. GDPR notifications go to the national Data Protection Authority. These are separate regulatory bodies with separate notification portals and separate content requirements. A unified “report once, share many” system via an ENISA portal has been discussed at Commission level, but no such mechanism is operational as of 2026. Two separate filings are required.

What if the 72-hour GDPR and NIS2 deadlines land on a weekend or public holiday?

Neither the NIS2 Directive nor the GDPR provides a working-day extension. Member-state implementing legislation may include guidance, but the default position under both frameworks is that the 72-hour clock runs from the moment of awareness regardless of the calendar. Incident response procedures should treat both 72-hour deadlines as absolute, with internal escalation triggers set no later than T+48h to allow adequate preparation time.

If our organisation receives a GDPR fine, does that eliminate our NIS2 fine exposure?

For the same conduct, Article 35(2) prohibits the NIS2 competent authority from imposing an additional administrative fine under Article 34. However, non-monetary NIS2 enforcement measures — binding security instructions, audit requirements at the entity’s expense, temporary activity suspension, and management function bans — remain fully available regardless of whether a GDPR fine has been imposed. The GDPR fine eliminates only the financial penalty for overlapping conduct; it does not provide full NIS2 enforcement immunity.

Does our DPO need to be involved in NIS2 notifications?

The DPO has no formal role in the NIS2 notification chain — that obligation falls to the entity’s management and designated security leadership. However, from an operational standpoint, DPO involvement in reviewing NIS2 notifications before submission is essential to ensure factual consistency with anticipated GDPR filings. Contradictions between NIS2 and GDPR submissions that arise because the DPO was not in the NIS2 review loop are among the most common causes of dual-authority follow-up inquiries.

This article provides general information only and does not constitute legal or regulatory advice. NIS2 transposition varies by member state jurisdiction, and GDPR requirements are subject to interpretation by each national Data Protection Authority. Consult a qualified legal professional or compliance specialist for advice specific to your organisation’s situation and sector.

Sources

1. NIS2 Article 23: Reporting Obligations — streamlex.eu
2. NIS2 Article 34: Administrative Fines — nis-2-directive.com
3. NIS2 Article 35: Infringements Entailing a Personal Data Breach — nis2resources.eu
4. GDPR Article 33: Notification of a Personal Data Breach to the Supervisory Authority — gdpr-info.eu
5. GDPR Article 34: Communication of a Personal Data Breach to the Data Subject — gdpr-info.eu
6. GDPR Article 83: General Conditions for Imposing Administrative Fines — gdpr-info.eu
7. EDPB Guidelines 9/2022 on Personal Data Breach Notification under GDPR (Version 2.0) — European Data Protection Board