Art. 23 NIS 2

Phishing incident under NIS 2

How phishing crosses the significant-incident threshold, what the reporting cascade asks for, and what a typical playbook handles in parallel.

Simon OrzelSimon Orzel·

What this page covers

Phishing is not a separate regulatory category under NIS 2. The directive treats a successful phishing attempt as one possible significant incident among others. The qualitative test in Article 23(3) NIS 2 is the same one every other incident type has to pass. Commission Implementing Regulation (EU) 2024/2690 (CIR) names categories in Annex Section 11.6 that, for digital infrastructure entities, count as significant by default.

The trigger most operators miss is credential compromise. A phishing email that captures a working set of credentials for a critical account is not a near miss. It is a successful unauthorised access event. Whether it then meets the Article 23(3) threshold depends on what the account can reach, what was extracted, and what services were affected.

This page sets out the mechanics, not the legal advice. It describes the early warning, incident notification and final report clocks under Article 23(4) NIS 2, how a typical SOC playbook handles containment and evidence preservation, and where GDPR Article 33 runs in parallel when personal data is involved.

Legal anchor
Three layers sit on top of every phishing case: the directive defines significance, the CIR adds quantitative and category-based detail for digital infrastructure, and national law transposes the cascade.

NIS 2 Directive (EU) 2022/2555, Art. 23(3)

An incident shall be considered to be significant if: (a) it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned; (b) it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

This is the only general definition of a significant incident in EU law. Both points use 'capable of causing', so potential damage counts as well as actual damage. A phishing event that compromised credentials for a privileged account can meet point (a) even before any service has actually stopped.

CIR (EU) 2024/2690, Annex Section 11.6

An incident shall be considered significant where it causes or is capable of causing severe operational disruption of the services or financial losses for the entity concerned, or where it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

Section 11.6 lists categories that always qualify as significant for the digital infrastructure entities covered by the CIR: ransomware, exfiltration of personal or sensitive data, denial-of-service against essential services, and loss of confidentiality or integrity of critical assets. A phishing case that ends in any one of these has crossed the threshold by definition. For sectors outside the CIR, the qualitative test in Article 23(3) governs alone.

§32 BSIG (Germany)

Essential and important entities notify the Bundesamt of significant incidents without undue delay, at the latest within the deadlines named in Article 23(4) of Directive (EU) 2022/2555.

Germany takes the directive cascade as is and routes reporting through the BSI portal at meldung.bsi.bund.de. §32 BSIG is the German anchor. The substantive deadlines remain the ones in Article 23(4) NIS 2: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month.

Three things happen in parallel
A phishing incident that crosses the threshold sets three workstreams running at the same time. None of them waits for the others.
Step 1

Triage and threshold call

The clock starts when the entity becomes aware of the incident. Awareness is when a competent person inside the organisation knows enough to suspect a significant incident, not when the investigation completes. Triage answers three questions: which accounts were compromised, what those accounts can reach, and whether any CIR Annex Section 11.6 category fits. If yes, the threshold question is closed and the early warning is prepared.

Step 2

Containment and evidence

A typical SOC playbook resets the compromised credentials, revokes active sessions, blocks the sender domain, isolates affected endpoints from the network and preserves the mailbox, endpoint disk image and authentication logs before any reimage. Wiping a phished machine before imaging it destroys the forensic record that later answers what the attacker actually reached.

Step 3

The 24h / 72h / 1-month cascade

Article 23(4) NIS 2 sets three deadlines from the point of awareness. Within 24 hours the entity submits an early warning indicating whether the incident is suspected to be caused by unlawful or malicious acts or has cross-border impact. Within 72 hours an incident notification updates the early warning with an initial assessment, indicators of compromise and severity. Within one month a final report describes the root cause, mitigation and any cross-border impact.

Two principles that drive the early calls
These are the two operating rules that decide how the first 24 hours run.

Scope of harm is what makes phishing significant

Article 23(3) does not care about the technique. It cares about effect. A phishing email opened by one finance clerk is not significant. The same email, if it captured working credentials that allow access to the billing system, payroll or a customer database, can meet point (a) on potential operational disruption or point (b) on damage to natural or legal persons. The scope question is: what could the compromised credential reach before it was revoked, and what was reached during the window of access.

Speed beats completeness

The BSI position is 'Schnelligkeit vor Vollständigkeit'. The 24-hour early warning is built for the moment when the picture is incomplete. The form asks for an initial classification and known facts, not a final root-cause analysis. Holding the early warning back until everything is known misses the deadline; the deadline cannot be made up later, even if the incident later turns out not to have been significant.

National view (Germany)
Three German authorities show up in a phishing case that involves personal data and a criminal element. Each has its own channel and clock.
DE

BSI: NIS 2 reporting at meldung.bsi.bund.de

The BSI runs the §32 BSIG single channel for NIS 2 incident reporting. The portal pre-structures the 24h, 72h and one-month submissions and stores the audit trail. BSI public guidance repeats the Article 23(3) wording and confirms 'Schnelligkeit vor Vollständigkeit'. Phishing-driven incidents that meet the qualitative test go through this channel, regardless of whether they also touch personal data.

DE

BfDI / state DPA: GDPR Article 33 parallel

If the phishing event exposed personal data, GDPR Article 33 runs alongside NIS 2. The data protection notification goes to the competent supervisory authority within 72 hours of awareness, unless the breach is unlikely to result in a risk to natural persons. The NIS 2 report and the GDPR notification are separate documents to separate authorities; the underlying facts overlap, the formal channels do not.

DE

ZAC LKA: criminal complaint as a separate decision

A successful phishing attack is usually a criminal act under §202a, §202b or §263a StGB. The Zentrale Ansprechstelle Cybercrime (ZAC) of the responsible Landeskriminalamt is the entry point for the criminal complaint. Filing it is a separate management decision from the regulatory reporting and does not pause either clock.

Three things that go wrong in the first 24 hours
Each of these falls apart against the text of Article 23(3) and the CIR.
  • 'It was only one user, not significant'

    The Article 23(3) test asks whether the incident is capable of causing severe operational disruption or considerable damage to third parties. A working credential set for a privileged account in the hands of an attacker is capable of doing both, regardless of how many users were phished. Significance is decided by what the credential can reach, not by the size of the click-through population.

  • 'Reimage the laptop straight away to be safe'

    Wiping the endpoint before a forensic image is taken destroys the only record of what the attacker actually did during the access window. The 72-hour incident notification and the one-month final report both ask for indicators of compromise and root cause. Without the image, those answers are guesses. A typical playbook isolates first, images the endpoint and the affected mailbox, and only then reimages.

  • 'Quiet is safer, do not tell anyone internally'

    Article 23(1)(h) NIS 2 obliges the entity, where appropriate, to communicate to recipients of its services that are potentially affected. Silence on the internal side delays the second wave of detection: other staff who received the same email, other accounts that may already be compromised. A short, factual internal note in the first hours is part of the response, not a press release.

Practitioner note

The most useful thing a small team can rehearse before the real event is the threshold call. Write down, in advance, which accounts are 'critical' for the entity (admin consoles, payment systems, identity provider, customer database, OT control). A phishing event that captures any of those is, by your own definition, a Section 11.6 candidate and the 24-hour clock starts.

The second most useful thing is the report template. The BSI portal asks for a structured set of facts. Drafting the early warning the first time during a real incident wastes the first two hours. A pre-filled template with company identifiers, sector, contact channels and a blank narrative section can be filed inside thirty minutes once the facts are in.

How we handle this on the platform

The incident module opens a case from a single 'awareness' timestamp and anchors three clocks: 24 hours, 72 hours, one month. Each clock has its own template, pre-filled with the fields Article 23(4) and CIR Annex Section 11.6 ask for. You enter what is known, the platform shows what is still missing. A separate GDPR Article 33 timer activates if personal data is flagged on the case.

The case log preserves the chain of awareness time, containment actions, communications and submissions. That log is the audit evidence the BSI portal cannot generate for you and the document an auditor will ask for in a §61 BSIG review.

Sources
  • Directive (EU) 2022/2555 (NIS 2), Article 23 (incident reporting), Article 21(2)(g) (security awareness training), Recital 101 (significance factors). EUR-Lex.
  • Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, Annex Section 11.6 (categories of incidents always considered significant for digital infrastructure entities). EUR-Lex.
  • BSIG (Gesetz über das Bundesamt für Sicherheit in der Informationstechnik), §32 (incident reporting to BSI). gesetze-im-internet.de.
  • Regulation (EU) 2016/679 (GDPR), Article 33 (notification of personal data breach to the supervisory authority within 72 hours). EUR-Lex.
  • BSI, public guidance on the NIS 2 reporting cascade and the 'Schnelligkeit vor Vollständigkeit' principle. bsi.bund.de.
  • Strafgesetzbuch (StGB) §202a Ausspähen von Daten, §202b Abfangen von Daten, §263a Computerbetrug. gesetze-im-internet.de.
Check whether your phishing case is significant
The applicability and incident classification check walks through Article 23(3) and CIR Annex Section 11.6 with your facts and returns a written rationale for the management file.