2026-11-10 - NIS and GDPR in the face of an incident: the decisions to take before the crisis

Read on website

---

On 6 November I was one of the speakers at the session «

NIS e GDPR: normative che si intrecciano o si contrappongono?

» (NIS and GDPR: intertwined or opposed?) at the

DIGEAT Festival

in Lecce.

The question in the title is usually addressed on the ground of legislative texts. In those days, events posed it in far more concrete terms:

Read in the light of those events, the question finds a less abstract answer than it might seem. During an incident, NIS and GDPR may require different decisions: on different grounds, towards different recipients, with deadlines running in parallel. That does not make them opposed. They do, however, require the organisation to prepare to take those decisions together, and before they are needed. In my view, this preparation is where many organisations are most exposed today, even more than on the technical side.

The facts, separated from the hypotheses

I keep what results from official communications, or from those directly concerned, separate from what is still under investigation. The sources do not establish whether the episodes are connected, nor who is behind them.

EventWhat is establishedWhat remains open

Refrigeration systemsIncidents in several Member States since 11 October, a new wave on 1 and 2 November (

EU joint statement, 4 November

); CSIRT Italia warning extended to all remotely managed plantsPerpetrators; Italian sites involved

Bomb hoaxesSchools on 2 November, after a first wave on 19 October; flights and airports on 5 November. In Milan, prosecutors are pursuing false alarm and public intimidation (

ANSA, 9 November

)Origin of the messages; use of compromised mailboxes; link between the waves

Personal data on the dark webPersonal data disseminated on the dark web (

Italian Ministry of Foreign Affairs statement, 7 November

); profiles of 18 people, with offers of money for further information (

ANSA, 7 November

); investigation opened by the Rome Public Prosecutor's Office for unauthorised access and threats (

ANSA, 9 November

)Origin of the data; attribution to NoName057(16)

Document exchange serverBBT SE, the company building the Brenner Base Tunnel: unauthorised access, on 17 October, to data on a server shared with the Italian contractors, with no impact on the works (

company statement

)Entry vector; data exfiltrated; responsibility

Alleged archive of the DIA (Italian Anti-Mafia Investigation Directorate)Put up for sale on 8 November; checks show only a takeover of the website, with public data (

ANSA, 9 November

)Checks ongoing

The quantitative context is consistent. According to ACN data reported by

ANSA

, 3,271 cyber events were detected in the first nine months of 2026, against 2,729 in the whole of 2025. In the same period, CSIRT Italia identified almost 45,000 assets and services at risk, more than 3,200 of which were potentially compromised.

Deciding with incomplete information

In public debate these episodes have been traced back to hybrid warfare: the Minister of Foreign Affairs used the expression

commenting on the attacks

. I use the notion as an interpretive key, not as a qualification of the facts.

The European reference point is the

Joint Framework on countering hybrid threats

of 2016 (JOIN(2016) 18 final). It describes a mixture of coercive and subversive activities, used in a coordinated manner by state or non-state actors below the threshold of formally declared warfare. Among the typical features, the document mentions the deliberate creation of ambiguity in order to hinder decision-making.

Whether or not the episodes of recent weeks are coordinated, that feature describes well their effect on the organisations involved. The technical impacts were often limited. Each episode, however, raised questions to be answered within hours and with incomplete information: evacuate or not, notify or not and whom, communicate or wait, give credit to a claim or verify it. This is the ground on which NIS and GDPR come into play together.

Where NIS and GDPR meet

The two regimes look at the same event from different perspectives.

Legislative Decree 138/2024

, which transposes NIS2 in Italy (hereinafter, the NIS Decree), protects the security and continuity of the services of essential and important entities. The

GDPR

protects the rights and freedoms of the people whose data are processed. Two autonomous qualifications follow, each with its own recipients and deadlines.

RegimeTriggerRecipientDeadlines

NIS (Legislative Decree 138/2024, Art. 25)Significant incident; at first application, the basic incident types identified by ACNCSIRT ItaliaEarly warning within 24 hours and incident notification within 72 hours of becoming aware of the significant incident; final report within one month of submitting the notification

GDPR (Arts. 33 and 34)Personal data breach, unless it is unlikely to result in a risk to the rights and freedoms of natural personsSupervisory authority (in Italy, the Garante); data subjects, if the risk is highTo the authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach; to data subjects without undue delay

CRA (Regulation (EU) 2024/2847, Art. 14), manufacturers onlyActively exploited vulnerability or severe incident having an impact on the security of the productCSIRT designated as coordinator and ENISA, simultaneously, through the single reporting platform (

ENISA FAQ

)As set out in Art. 14 of the Regulation

The NIS deadlines and the GDPR deadline do not necessarily start together. The organisation may become aware of the significant incident and of the personal data breach at different times: this happens, for example, when only a later analysis reveals that the data involved include personal data.

The same event may trigger both regimes, only one, or neither. What decides is the qualification, and the qualification often depends on a technical detail that the organisation must be able to establish quickly. The cases of recent weeks show this well.

An unreachable service. A DDoS attack saturates a service with a volume of requests generated by thousands of compromised devices. The ground is primarily that of NIS. ACN’s basic specifications include among significant incidents the breach of expected service levels (type IS-3), levels that the entity itself defines under measure DE.CM-01 (see the

reading guide to the basic specifications

). Whether a DDoS must be notified therefore depends on a choice made, or not made, before the attack. The GDPR is not excluded by definition, however: a loss of availability of personal data, even a temporary one, may also constitute a breach under Article 4(12). If the attack makes a purely informational website unreachable, the problem as a rule remains one of service. If it makes inaccessible personal data that the organisation or the data subjects need, the assessment must also be carried out under the GDPR. What counts is what has become unavailable, not the type of attack.

A spoofed sender or a compromised mailbox. A message may appear to have been sent from a domain without anyone having accessed it. It is enough that the domain does not declare, through the SPF, DKIM and DMARC protocols described in the

ACN guidelines on email

, which servers may send on its behalf and what to do with messages that fail the checks. In this case the domain holder does not, in my view, suffer a breach of its own data. It does, however, have a configuration problem that someone has exploited. If instead the mailbox has been compromised, the unauthorised access in most cases amounts to a personal data breach under Article 4(12) GDPR. For a NIS entity it may also amount to a loss of confidentiality towards the outside (IS-1) and, for essential entities, to unauthorised access or abuse of privileges (IS-4). The same threatening email can thus lead to opposite consequences, depending on a technical finding that must be made in the first hours. For the perpetrators, the offences charged in Milan are causing a false alarm to the authorities (Article 658 of the Italian Criminal Code) and public intimidation (Article 421).

Encrypted data or stolen data. When an attacker encrypts data, the main problem is availability, and backup is the answer. When the attacker steals them, the problem is confidentiality, and backup is of no use: it protects against loss, not against publication. The distinction changes the qualification. Theft points towards a loss of confidentiality (IS-1) and towards the assessment of the risk to data subjects for the purposes of Articles 33 and 34 GDPR. The Brenner case shows why the distinction must be established rather than presumed. The company reports unauthorised access to data on a server used for exchanges with its contractors; whether data were stolen does not, at present, emerge. Unauthorised access to personal data already falls, in any case, within the definition of a breach in Article 4(12) GDPR. The supply chain dimension adds to this:

Plants that become processing operations. The attacks on refrigeration systems showed that unauthorised access can alter parameters, but also alarms and displayed values, delaying the discovery of the problem. For NIS entities, security measures must protect network and information systems «and their physical environment» (Article 24(2) of the Decree). CSIRT Italia has extended its

recommendations

to all remotely managed plants, also mentioning video surveillance. This is where the two regimes touch: a compromised video surveillance system is also, potentially, a personal data breach. For manufacturers of the devices, the reporting obligation under the

Cyber Resilience Act

has applied since 11 September 2026.

Exposed people. The publication of personal profiles moves the attack from systems to people. For the organisation to which the person belongs, there are two questions:

The principle of data minimisation (Article 5(1)(c) GDPR) takes on a defensive function here: direct contact details and organisation charts published without need are the raw material of these attacks.

Artificial intelligence: in attacks, in prevention, in compliance management

None of the episodes in the table has, at present, been attributed to the use of artificial intelligence. Ignoring it, however, would distort the perspective, because it affects three levels.

In attacks. According to the

annual review

published on 3 November by the UK National Cyber Security Centre, AI will highly likely increase the speed, scale and efficiency of attacks, accelerating known techniques rather than creating new ones. Models, moreover, find vulnerabilities that have long gone unnoticed. On the same day Bitdefender documented

a ransomware intrusion into a group of British schools

, in which some phases appear to have been run by an automated loop based on a language model; the company presents this as a working hypothesis and notes that none of the techniques was new. The case matters for another reason: the attacker targeted the backups and, before encrypting the systems, stole files from the finance area. Availability and confidentiality were compromised in the same incident, with two qualifications to handle together and less time to establish the facts. Finally, fake voices and faces make requests and claims credible when they are not: it is the ambiguity described in the 2016 Joint Framework, at a much lower cost.

In prevention. The NCSC expects mature organisations to use AI to detect threats better, prioritise the vulnerabilities to fix and automate part of their defence, and warns that the benefits will not be evenly distributed. The most useful applications are those that shorten the findings described above: correlating logs from different systems, detecting anomalous volumes of outgoing data, deciding which flaws to close first. Analysing logs that contain personal data with AI is, however, itself a processing operation. And AI tools with access to internal systems fall, in my view, among the systems to which the measures of Article 24 of the NIS Decree apply. For providers of high-risk systems, the AI Act also requires an appropriate level of accuracy, robustness and cybersecurity (Article 15,

text on the Commission’s service desk

).

In compliance management. An inventory of systems and services, measures to be mapped against ACN’s specifications, suppliers, deadlines, documentation for the management bodies: a NIS entity must hold many elements together, and AI can help to connect them, flag gaps and prepare the first draft of an early warning. Two limits apply, however, in my view. The tool does not transfer responsibility, which the Decree places on the management bodies (Article 23). And compliance data are a map of the entity’s vulnerabilities: where they are stored, who can read them and whether they are encrypted is a security matter in its own right. This is why the shadow AI flagged by the NCSC, meaning company data moved to unauthorised tools, is a double risk: of lawfulness of processing, if the data are personal; of security, if they are compliance documents.

On all three levels, the qualification of the incident and the decision to notify are not delegated to a model. The NCSC itself observes that even attackers need effective human oversight of their own agents.

Deciding beforehand

The decisions that follow presuppose an organisation that already exists: a crisis unit is not set up during the crisis, and an event log is not configured after the incident. Two prerequisites come before everything else.

The first concerns the top. The NIS Decree requires the management bodies to approve how the cybersecurity risk-management measures are implemented, to oversee compliance with the obligations, and makes them responsible for infringements; it also requires them to follow cybersecurity training (Article 23). Security cannot be delegated entirely to the technical function: those who govern the entity must be able to understand the decisions they approve.

The second concerns people. Basic cyber hygiene and training are minimum elements of the risk-management measures (Article 24(2) of the Decree). In the events of recent weeks, the first point of contact with the attack was often a person: whoever received the threatening email, whoever was contacted on the basis of exposed data, whoever could have noticed that a value on the control panel did not add up. An organisation in which reporting an anomaly is simple, and does not expose anyone to blame, shortens qualification times more than any tool.

On this basis rest six decisions which, in my view, must be taken and documented before they are needed. For each, the facts show what happens when the decision is missing.

Thresholds

An organisation hit by a DDoS that has never defined its expected service levels must establish, during the attack, whether the unavailability is significant. It does so with the website down, customers on the phone and the 24-hour deadline running. If instead the service level has been framed in measurable terms, the qualification takes a few minutes. For example: a minimum availability percentage during service hours and a maximum duration of continuous interruption.

The same applies on the GDPR side. Article 33 exempts from notification only where a risk to individuals is unlikely. Without risk assessment criteria decided in advance and applied consistently, that assessment risks being made case by case, under pressure, and not withstanding later scrutiny.

Roles

Within the same organisation, figures answering to different rules coexist:

In my view, the risk lies not in the absence of these figures but in their separation. When the same event touches both regimes, the deadlines run in parallel, but not necessarily from the same moment: the 24 hours of the early warning to CSIRT Italia from awareness of the significant incident, the 72 hours of the notification to the Garante from awareness of the personal data breach. If the two qualifications are entrusted to functions that do not talk to each other, the risk is twofold. The two notifications may describe the same event inconsistently, or one of them may be overlooked because each side assumes the other is dealing with it. This is how the data protection officer learns of an incident when the early warning has already gone out, or how whoever qualifies the event for NIS purposes is unaware that the video surveillance logs contain personal data.

In my view, the solution is a single incident management unit, in which sit:

Alongside the unit, a single incident register, serving both the documentation required by Article 33(5) GDPR and NIS incident management. Every role needs a designated deputy: incidents do not pick working days.

Traces

The distinctions that change the qualification are findings of fact, not opinions:

Without event logs collected in a single place, with synchronised timestamps and kept long enough, those findings cannot be made within the required times. In its recommendations on plants, CSIRT Italia advises extending the analysis up to ninety days back, where logs allow. Stolen data also require the ability to notice anomalous outgoing volumes, because exfiltration is precisely what backup does not see.

An organisation without reliable traces faces two paths, both wrong. Notifying everything out of caution, overloading itself and the authorities. Or notifying nothing out of uncertainty, exposing itself to the charge of failing to notify what it should have.

Channels

The first channel is the one for communicating during the crisis. If email is compromised or the website is unreachable, those managing the incident must be able to rely on an alternative channel already in place. The NIS Decree expressly requires it among the minimum elements of risk-management measures: secured emergency communication systems (Article 24(2)(l)). It is also the channel on which to keep and circulate, unaltered, the threatening messages that law enforcement will ask for.

The second channel is the one for verifying. Personal profiles on the dark web and videos faked with artificial intelligence, whose use the Italian

Postal Police

has documented, make requests credible when they are not. The rule must be decided beforehand: any unusual request for payments, credentials or confidential data is verified on an independent and already known channel, even and above all when it appears to come from the top.

The third channel is the one towards the outside. The DIA case shows how quickly an unverified claim produces alarm. Who communicates, after which checks and on what timeline is a decision to take in cold blood, not when journalists call.

Suppliers

Outsourcing the management of systems or security does not transfer responsibility: under the GDPR it remains with the controller, under the NIS Decree with the entity’s management bodies. This applies above all to small and medium-sized organisations that rely on a single IT provider, which becomes both their safeguard and a possible entry point.

The Brenner case is a reminder: the exchange point with suppliers is by definition an opening in the perimeter. The decision to take beforehand concerns above all timing. A supplier contractually required to report an incident “promptly”, without precise deadlines, may do so when the early warning to CSIRT Italia is already overdue. Contracts should provide for reporting deadlines compatible with one’s own, with a minimum content that allows the event to be qualified. In addition:

Bulletins

On 4 November CSIRT Italia extended its recommendations on refrigeration systems to anyone using industrial remote control tools, referring to the bulletin on

IoT devices and remote access services

. An organisation that manages connected plants faces a choice: apply the measures, apply some of them, or consider them not relevant.

Bulletins are not legislative acts. In my view, however, they may contribute to the assessment of the adequacy of measures under Article 24 of the NIS Decree and Article 32 GDPR. In the face of an incident, it will be hard to argue that a publicly described risk, with its countermeasures, was not knowable. What matters, then, is documenting the decision taken in response to the bulletin:

A reasoned choice not to apply a measure is something quite different from an ignored bulletin.

Intertwined or opposed?

I return to the question of the Lecce session. In my view, NIS and GDPR, in themselves, are neither intertwined nor opposed: they have different objects and coexist without conflict. They converge or clash within organisations, depending on how these have prepared.

Where the organisation has been built beforehand, and thresholds, roles, traces, channels and supplier relations have been decided in cold blood, an incident touching both regimes translates into two consistent assessments and two timely notifications. Where those decisions are missing, the same incident produces uncertainty, delays and contradictory versions. That is exactly the effect sought by those who produce ambiguity.

The relationship between the two regimes is also examined in the article of the NIS2 in Italy, beyond the deadlines series devoted to

NIS2, GDPR and DORA

.

Sources

Legislative acts and institutional documents

Joint Framework on countering hybrid threats: a European Union response, JOIN(2016) 18 final

, 6 April 2016

Joint statement on cyber incidents in refrigeration systems across the EU

, 4 November 2026

Legislative Decree No. 138 of 4 September 2024

(in Italian)

Regulation (EU) 2016/679 (GDPR)

Regulation (EU) 2024/2847 (Cyber Resilience Act)

Reading guide to the NIS Guidelines, basic specifications

(in Italian)

Urgent verification and mitigation measures for food distribution and cold chain operators (BL01/261013/CSIRT-ITA)

(in Italian)

IoT devices and remote access services connected to the Internet: risks and mitigations

(in Italian)

Guidelines for configuring email services for sender authentication

(in Italian)

Beware of fake online investment offers

(in Italian)

Single Reporting Platform, Frequently Asked Questions

statement of 7 November 2026 on personal data disseminated on the dark web

(in Italian)

Article 15: Accuracy, robustness and cybersecurity

NCSC Annual Review 2026, The impact of AI on cyber threat

, 3 November 2026

News and other sources cited

3AM Hits European Schools: A Hybrid AI Ransomware Attack, Part Human, Part Agentic Loop

, 3 November 2026

session «NIS e GDPR: normative che si intrecciano o si contrappongono?»

, Lecce, 6 November 2026

statements by the Minister of Foreign Affairs

, 8 November 2026 (in Italian)

Prima Pagina News

(in Italian)

---

Author’s note. I have developed

NIS2DESK

for managing the compliance obligations of NIS2 entities. I mention it for transparency: the analysis above does not presuppose the use of this or any other tool.

This article is for information purposes and does not constitute legal advice. It is up to date as of [DATA]; the facts reported are the subject of ongoing investigations and the acts cited should be checked against the official texts.

---

New to Gemini? This capsule is best read with a Gemini client, such as Lagrange.

Lagrange - a Gemini client for desktop, iOS and Android

Back to articles list

English section

Home

Proxied content from gemini://nicfab.eu/en/gemlogen/2026/2026-11-10-nis-gdpr-incident-decisions_en.gmi

Gemini request details:

Original URL
gemini://nicfab.eu/en/gemlogen/2026/2026-11-10-nis-gdpr-incident-decisions_en.gmi
Status code
Success
Meta
text/gemini;lang=en-US
Proxied by
kineto

Be advised that no attempt was made to verify the remote SSL certificate.