NIS2 Data Breach Notification: Why a GDPR Breach Doesn’t Always Trigger the 24-Hour CSIRT Clock

Attackers halt a water utility’s treatment line for nine hours by compromising its SCADA network. The affected systems hold valve states and flow telemetry — no personal data. The same week, an HR administrator emails a payroll spreadsheet with 340 employees’ bank details to the wrong distribution list. No service is interrupted.

The first incident starts a 24-hour clock to the national CSIRT and no GDPR clock. The second starts a 72-hour clock to the data protection authority and, on its own facts, no NIS2 clock. Same organisation, same week, two different filings — because NIS2 and GDPR are not two deadlines on one obligation. They are separate tests measuring different things.

ENISA’s Threat Landscape 2025 found that 53.7% of the incidents it analysed concerned entities NIS2 defines as essential [8], so a large share of European organisations now run both tests on every incident. This guide covers which regime actually fires, what each filing must contain, and the two duties to notify affected people — one under each regime — that almost no comparison article mentions.

The short answer: two tests that measure different things

NIS2 asks whether your service broke or whether others were harmed. GDPR asks whether personal data was compromised. Neither test mentions the other’s subject matter. Article 23(3) of NIS2 never uses the words "personal data", and the GDPR definition of a personal data breach never mentions service availability.

	NIS2 Article 23	GDPR Article 33
What must have happened	A "significant incident"	A "personal data breach"
Defined where	Article 23(3), two limbs [1]	Article 4(12) [5]
What it measures	Severe operational disruption or financial loss to you; or considerable damage to others	Destruction, loss, alteration, unauthorised disclosure of, or access to, personal data
Who you notify	Your CSIRT or competent authority	Your data protection supervisory authority
Deadlines	24h early warning, 72h notification, final report one month after the 72h notification [1]	72h notification; no final report [3]
Who it applies to	Essential and important entities only	Any controller processing personal data
Built-in escape hatch	None — the test is met or it isn’t	No notification if the breach is "unlikely to result in a risk to the rights and freedoms of natural persons" [3]

An incident can therefore satisfy one test, both, or neither. Treating the pair as one workflow with two deadlines is the most common structural error in incident response plans, and it produces both over-reporting and under-reporting.

Does this even apply to you?

GDPR applies to essentially every organisation processing personal data. NIS2 applies only to essential and important entities inside its scope. The two populations overlap but are not the same set, and your obligations depend on which you are in.

Your situation	What you run on each incident
Not in NIS2 scope, processes personal data	The GDPR test only. NIS2 Article 23 does not apply to you at all.
In NIS2 scope, processes personal data (most in-scope entities)	Both tests, independently, on every incident. Either can fire without the other.
In NIS2 scope, genuinely no personal data in the affected systems	The NIS2 test only for that incident — but verify the "no personal data" claim before relying on it.

If you are unsure whether a given incident clears the NIS2 bar, our walkthrough of the Article 23(3) two-limb significance test covers the threshold question in detail.

The four cases: which regime actually fires

Run both tests and you land in one of four quadrants. Most published guidance only ever describes the first.

Case	Example	Why
Both fire	Ransomware encrypts customer-facing systems holding personal data; service down for hours, records exfiltrated	Severe disruption meets NIS2 limb (a); loss of access and unauthorised disclosure meet Article 4(12)
NIS2 only	SCADA or OT compromise halts production, affected systems carrying telemetry rather than personal data; or exfiltration of trade secrets and R&D files holding no personal data	Disruption and financial loss meet limb (a). No personal data was destroyed, lost, altered, disclosed or accessed, so Article 4(12) is not met
GDPR only	Misdirected payroll email; an employee snooping in records they may not access; a lost unencrypted USB stick	A clear personal data breach, but no severe disruption or financial loss, so limb (a) fails. Limb (b) is a separate judgement (see below)
Neither notifies	A blocked phishing attempt; contained malware with no data touched and no service impact	Below both thresholds. GDPR still requires an internal record where a breach occurred; NIS2 requires no filing

In the fourth case, "no filing" is not "no obligation". Article 33(5) requires the controller to document any personal data breach — facts, effects and remedial action — precisely so the supervisory authority can verify that the decision not to notify was sound [3]. The record evidences that you applied the test rather than ignored it.

The ransomware trap. That "NIS2 only" example holds only because the affected systems carry no personal data. Where ransomware encrypts systems that do, it is usually both cases at once: the EDPB treats loss of access to personal data as an "availability breach", one of the three recognised types alongside confidentiality and integrity breaches [6], and attacker-side encryption is exactly that. Treating ransomware as NIS2-only because nothing was published or sold is a common and expensive misreading — see NIS2 ransomware reporting obligations.

The overlap limb most guides miss: Article 23(3)(b)

Limb (a) of the significance test is about you — severe operational disruption or financial loss. Limb (b) is about everyone else: an incident is also significant where it "has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage" [1]. Either limb alone is enough.

Note the vocabulary. "Material or non-material damage" to "natural persons" is the same language the data protection world uses for financial loss and distress. Read plainly, the text means a large personal data breach at an in-scope entity can be a NIS2 significant incident through limb (b) even with zero downtime and no cost to the entity. That is the honest answer to the question this article’s title raises: a GDPR breach does not automatically trigger NIS2, but it is not insulated from it either.

What limb (b) is not is a switch that flips on its own. It turns on "considerable" damage — a threshold judgement that national competent authorities are settling member state by member state, with little published enforcement practice to calibrate against yet. As a working approach, treat limb (b) as live whenever a personal data breach is large, involves sensitive categories, or exposes people to fraud or identity theft — and write down the reasoning either way. A documented judgement is what an authority can review; a silent decision is not.

Two filings, two forms, two content sets

Where both tests fire, you file twice. There is no single-window mechanism between the two regimes, and national authorities say so directly. The Centre for Cybersecurity Belgium, Belgium’s national cybersecurity authority, states in its own NIS2 Notification Guide that "incident notifications under the NIS2 law do not replace any notifications in the event of a personal data breach, for example to the Data Protection Authority (DPA). Two separate notifications will still be required" [7]. The guide notes that closer collaboration between the two authorities "could lead to the development of common tools" — future convergence, not a present shortcut.

The two filings ask for genuinely different information:

Required content	NIS2 Article 23(4)	GDPR Article 33(3)
Categories and approximate numbers of people and records affected	Not asked	Required, point (a)
Contact point for further information	Not specified	DPO or other contact point, point (b)
Likely consequences	Severity and impact assessment at 72h	Required, point (c)
Mitigation measures	Applied and ongoing measures, in the final report	Taken or proposed, point (d)
Suspected unlawful or malicious cause	Flagged in the 24h early warning	Not asked
Indicators of compromise	Where available, at 72h	Not asked
Cross-border impact	Required where applicable	Not asked
Root cause	Required in the one-month final report	Not asked

Two structural differences matter. NIS2 has a closing obligation GDPR lacks: a final report no later than one month after the 72-hour notification, covering severity, root cause, mitigation and cross-border impact [1]. GDPR instead allows information in phases under Article 33(4), with no terminal report [3]. The clocks also start at different evidential thresholds — NIS2 runs from becoming aware of a significant incident, while the EDPB treats a controller as "aware" only once it has "a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised" [6], so the shorter NIS2 deadline often begins while the GDPR assessment is still open. Our decision tree for running both clocks on one incident and the full dual-notification timeline playbook cover that sequencing; where to actually file the NIS2 notification lists the national portals.

One asymmetry matters if you are hesitating: NIS2 states expressly that "the mere act of notification shall not subject the notifying entity to increased liability" [1], and GDPR has no equivalent clause. Filing the NIS2 early warning on thin information carries a protection the GDPR filing does not.

The duty nobody mentions: telling the people affected

Both regimes contain an obligation to tell affected people directly, not just the regulator — and the two obligations are triggered by completely different things. This is the part almost every NIS2-versus-GDPR comparison omits.

	NIS2 Article 23(1) and 23(2)	GDPR Article 34
Who you tell	Recipients of your services	Data subjects
Trigger	Incidents "likely to adversely affect the provision of those services"; separately, remedies recipients can take against a significant cyber threat [1]	Breach "likely to result in a high risk to the rights and freedoms of natural persons" [4]
Qualifier	"Where appropriate" / "where applicable"	None on the duty itself
Exemptions	None stated	Three, at Article 34(3) [4]
Regulator can force disclosure	Yes — Article 23(7) lets the CSIRT or competent authority inform the public itself, or require you to, after consulting you [1]	Yes — Article 34(4) [4]

The encryption asymmetry. GDPR Article 34(3)(a) excuses you from telling data subjects where you had applied protection measures that render the data "unintelligible to any person who is not authorised to access it, such as encryption" [4]. Encrypting your data can therefore remove the duty to notify individuals under GDPR. It does nothing at all for the NIS2 recipient duty, because that duty turns on whether your service was adversely affected, not on whether data stayed readable. Ransomware makes the point sharply: your own encryption of data at rest may spare you the Article 34 communication, while the attacker’s encryption is exactly what takes the service down and engages Article 23(1). Any communications plan assuming the organisation controls the timing of disclosure is also mistaken — Article 23(7) lets the authority go public itself, after consulting you but not subject to your agreement [1].

What this changes, by role

Role	What to do differently
Compliance officer	Split the incident record into two independent assessments with their own evidence trails, not one form with two deadline fields. Record the limb (b) reasoning on every personal data breach.
CISO / IT security manager	Tag systems by whether they hold personal data before an incident, not during one. That single attribute decides which tests fire, and it cannot be established reliably at 2am.
SME owner without a DPO	You still owe both filings if in scope. Identify the two recipient bodies in your member state now — different organisations, different portals, and one may not accept filings in English.
Board / senior management	A regulator can disclose your incident publicly under Article 23(7). Approve a communications plan that assumes you may not control the announcement.

On penalties, the regimes coordinate at exactly one point: Article 35(2) stops a NIS2 competent authority fining conduct already fined by a data protection authority under GDPR, though other NIS2 enforcement measures such as binding instructions and audits remain available [2]. Article 35(1) runs the other way — the NIS2 authority must alert the data protection authority where an infringement it finds could entail a notifiable personal data breach [2], so a NIS2 inspection can originate a GDPR case.

Frequently Asked Questions

Does notifying the CSIRT satisfy my GDPR obligation?
No. They are separate filings to separate authorities. Belgium’s national cybersecurity authority states plainly that NIS2 notifications "do not replace" a personal data breach notification and that two separate notifications are still required [7].

Can a personal data breach ever be a NIS2 significant incident with no downtime?
Yes, through Article 23(3) limb (b), where the incident is capable of causing considerable material or non-material damage to other persons [1]. It is a threshold judgement rather than an automatic consequence, so document your reasoning.

Which clock starts first if both apply?
Usually NIS2. Its 24-hour early warning runs from becoming aware of a significant incident, while the EDPB sets the GDPR trigger at "a reasonable degree of certainty" that personal data was compromised [6] — a higher evidential bar that is often reached later.

We encrypt everything. Does that remove both notification duties?
No. Encryption can exempt you from communicating with data subjects under GDPR Article 34(3)(a) [4]. It has no equivalent effect on NIS2, whose recipient notification turns on adverse effect to your service [1].

Sources

1. Directive (EU) 2022/2555 (NIS 2 Directive), Article 23 — Reporting obligations
2. Directive (EU) 2022/2555 (NIS 2 Directive), Article 35 — Infringements entailing a personal data breach
3. Regulation (EU) 2016/679 (GDPR), Article 33 — Notification of a personal data breach to the supervisory authority
4. Regulation (EU) 2016/679 (GDPR), Article 34 — Communication of a personal data breach to the data subject
5. Regulation (EU) 2016/679 (GDPR), Article 4 — Definitions
6. European Data Protection Board, Guidelines 9/2022 on personal data breach notification under GDPR, Version 2.0
7. "NIS2 Notification Guide" — Centre for Cybersecurity Belgium (ccb.belgium.be)
8. ENISA, "ETL 2025: EU consistently targeted by diverse yet convergent threat groups"

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.