2026-11-10 - NIS e GDPR davanti all'incidente: le decisioni da prendere prima della crisi

---

Il 6 novembre ero tra i relatori della sessione «

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

» al

di Lecce.

La domanda del titolo si affronta di solito sul terreno dei testi normativi. In quei giorni i fatti l’hanno posta in termini molto più concreti:

il giorno prima, email minatorie avevano coinvolto voli e aeroporti italiani ed europei;
nella settimana precedente, centinaia di scuole avevano ricevuto falsi allarmi bomba e una nuova ondata di attacchi aveva colpito i sistemi di refrigerazione in diversi Stati membri;
il giorno dopo, si è saputo che dati personali del ministro degli Esteri, del procuratore di Roma e del capo della Polizia postale circolavano nel dark web.

Letta alla luce di quei fatti, la domanda trova una risposta meno astratta di quanto sembri. Durante un incidente, NIS e GDPR possono richiedere decisioni diverse: su presupposti diversi, verso destinatari diversi, con termini che decorrono in parallelo. Non per questo si contrappongono. Chiedono però all’organizzazione di prepararsi a prendere quelle decisioni insieme, e prima che servano. È questa preparazione, a mio avviso, il punto in cui oggi molte organizzazioni sono più esposte, più ancora che sul piano tecnico.

I fatti, distinti dalle ipotesi

Tengo separato ciò che risulta da comunicazioni ufficiali o dei diretti interessati da ciò che resta oggetto di accertamento. Le fonti non stabiliscono se gli episodi siano collegati, né chi ne sia l’autore.

EventoChe cosa risultaChe cosa resta aperto

Impianti di refrigerazioneIncidenti in più Stati membri dall'11 ottobre, nuova ondata l'1 e il 2 novembre (

dichiarazione congiunta UE, 4 novembre

); richiamo del CSIRT Italia esteso a tutti gli impianti gestiti a distanzaAutori; siti italiani coinvolti

Falsi allarmi bombaScuole il 2 novembre, dopo una prima ondata il 19 ottobre; voli e aeroporti il 5 novembre. A Milano si contestano procurato allarme e pubblica intimidazione (

ANSA, 9 novembre

)Origine degli invii; uso di caselle compromesse; collegamento tra le ondate

Dati personali nel dark webSchede su 18 persone, con offerte di denaro per ulteriori informazioni (

ANSA, 7 novembre

); fascicolo della Procura di Roma per accesso abusivo e minacce (

ANSA, 9 novembre

)Provenienza dei dati; attribuzione a NoName057(16)

Server di scambio documentiBBT SE, società della Galleria di Base del Brennero: accessi non autorizzati, il 17 ottobre, a dati su un server condiviso con gli affidatari italiani, senza ripercussioni sui lavori (

nota della società

)Vettore di ingresso; dati esfiltrati; responsabilità

Presunto archivio della DIAMesso in vendita l'8 novembre; dalle verifiche risulta solo un'acquisizione del sito, con dati pubblici (

ANSA, 9 novembre

)Accertamenti in corso

Il contesto quantitativo è coerente. Secondo i dati ACN riportati dall’

ANSA

, nei primi nove mesi del 2026 gli eventi cyber rilevati sono stati 3.271, contro i 2.729 dell’intero 2025. Nello stesso periodo il CSIRT Italia ha individuato quasi 45 mila asset e servizi a rischio, oltre 3.200 dei quali potenzialmente compromessi.

Perché il bersaglio sono le decisioni

Nel dibattito pubblico questi episodi sono stati ricondotti alla guerra ibrida: il ministro degli Esteri ha usato l’espressione

commentando gli attacchi

. Uso la nozione come chiave di lettura, non come qualificazione dei fatti.

Il riferimento europeo è il

Quadro congiunto per contrastare le minacce ibride

del 2016 (JOIN(2016) 18 final). Vi si descrive una combinazione di attività coercitive e sovversive, impiegate in modo coordinato da attori statali o non statali al di sotto della soglia della guerra dichiarata. Tra i tratti tipici il documento indica la produzione deliberata di ambiguità, allo scopo di ostacolare i processi decisionali.

Che gli episodi delle ultime settimane siano o no coordinati, quel tratto descrive bene il loro effetto sulle organizzazioni coinvolte. Gli impatti tecnici sono stati spesso contenuti. Ciascun episodio, però, ha prodotto domande cui rispondere in poche ore e con informazioni incomplete: evacuare o no, notificare o no e a chi, comunicare o attendere, dare credito a una rivendicazione o verificarla. È su questo terreno che NIS e GDPR entrano in gioco insieme.

I due regimi guardano allo stesso evento da prospettive diverse. Il

decreto legislativo 138/2024

(di seguito, decreto NIS) tutela la sicurezza e la continuità dei servizi del soggetto essenziale o importante. Il

GDPR

tutela i diritti e le libertà delle persone i cui dati sono trattati. Ne derivano due qualificazioni autonome, con destinatari e termini propri.

RegimePresuppostoDestinatarioTermini

NIS (d.lgs. 138/2024, art. 25)Incidente significativo; in prima applicazione, le tipologie di base individuate dall'ACNCSIRT ItaliaPre-notifica entro 24 ore da quando si viene a conoscenza dell'incidente; notifica entro 72 ore; relazione finale entro un mese

GDPR (artt. 33 e 34)Violazione di dati personali, salvo che sia improbabile un rischio per i diritti e le libertà delle personeGarante; interessati, se il rischio è elevatoSenza ingiustificato ritardo e, ove possibile, entro 72 ore; agli interessati senza ingiustificato ritardo

CRA (Reg. (UE) 2024/2847, art. 14), solo per i fabbricantiVulnerabilità attivamente sfruttata o incidente grave che incide sulla sicurezza del prodottoPiattaforma unica di segnalazione gestita da ENISASecondo l'art. 14 del regolamento

Uno stesso evento può far scattare entrambi i regimi, uno solo o nessuno. Ciò che decide è la qualificazione, e la qualificazione dipende spesso da un dettaglio tecnico che l’organizzazione deve essere in grado di accertare in fretta. I casi delle ultime settimane lo mostrano bene.

Un servizio irraggiungibile. Un attacco DDoS satura un servizio con un volume di richieste generato da migliaia di dispositivi compromessi. Su un sito istituzionale, di regola, non tocca dati personali: il terreno è quello NIS. Le specifiche di base dell’ACN includono tra gli incidenti significativi la violazione dei livelli di servizio attesi (tipologia IS-3), livelli che il soggetto stesso definisce in base alla misura DE.CM-01 (si veda la

guida alla lettura delle specifiche di base

). Se un DDoS sia da notificare dipende quindi da una scelta compiuta, o mancata, prima dell’attacco.

Un mittente imitato o una casella violata. Un messaggio può apparire inviato da un dominio senza che nessuno vi abbia avuto accesso. È sufficiente che il dominio non dichiari, con i protocolli SPF, DKIM e DMARC indicati nelle

linee guida ACN sulla posta elettronica

, quali server possono spedire a suo nome e che cosa fare dei messaggi che non superano i controlli. In questo caso il titolare del dominio non subisce, a mio avviso, una violazione dei propri dati. Ha però un problema di configurazione che qualcuno ha sfruttato. Se invece la casella è stata violata, l’accesso abusivo integra nella gran parte dei casi una violazione di dati personali ai sensi dell’art. 4, punto 12, GDPR. Per un soggetto NIS può integrare anche la perdita di riservatezza verso l’esterno (IS-1) e, per i soggetti essenziali, l’accesso non autorizzato o con abuso dei privilegi (IS-4). Dalla stessa email minatoria discendono quindi conseguenze opposte, a seconda di un accertamento tecnico che va fatto nelle prime ore. Per gli autori, le fattispecie contestate a Milano sono il procurato allarme presso l’Autorità (art. 658 c.p.) e la pubblica intimidazione (art. 421 c.p.).

Dati cifrati o dati sottratti. Quando un attaccante cifra i dati, il problema principale è di disponibilità, e il backup è la risposta. Quando li sottrae, il problema è di riservatezza, e il backup non serve a nulla: protegge dalla perdita, non dalla pubblicazione. La distinzione cambia la qualificazione. La sottrazione orienta verso la perdita di riservatezza (IS-1) e verso la valutazione del rischio per gli interessati ai fini degli artt. 33 e 34 GDPR. Il caso del Brennero, che riguarda l’accesso a dati su un server di scambio con gli affidatari, si colloca su questo versante. Vi si aggiunge la dimensione della catena di approvvigionamento:

l’art. 24, comma 2, lettera d), e comma 3, del d.lgs. 138/2024 (decreto NIS) chiede di governare il rischio legato ai fornitori diretti, tenendo conto delle loro vulnerabilità specifiche e della qualità delle loro pratiche;
l’art. 28 GDPR disciplina i responsabili del trattamento quando i dati scambiati sono personali.

Impianti che diventano trattamenti. Gli attacchi ai sistemi di refrigerazione hanno mostrato che un accesso abusivo può alterare i parametri, ma anche gli allarmi e i valori visualizzati, ritardando la scoperta del problema. Per i soggetti NIS le misure di sicurezza devono proteggere i sistemi informativi e di rete «nonché il loro ambiente fisico» (art. 24, comma 2, del decreto). Il CSIRT Italia ha esteso le sue

raccomandazioni

a tutti gli impianti gestiti a distanza, citando anche la videosorveglianza. Ed è qui che i due regimi si toccano: un impianto di videosorveglianza compromesso è anche, potenzialmente, una violazione di dati personali. Per i fabbricanti dei dispositivi si aggiunge, dall'11 settembre 2026, l’obbligo di segnalazione previsto dal

Cyber Resilience Act

Persone esposte. La pubblicazione di schede personali sposta l’attacco dai sistemi alle persone. Per l’organizzazione di cui la persona fa parte, le domande sono due:

Provenienza dei dati. I dati provengono da un suo sistema? Se sì, si aprono le valutazioni ex artt. 33 e 34 GDPR e, per i soggetti NIS, quella dell’incidente significativo.
Rischio indotto. L’esposizione modifica il rischio dell’organizzazione? A mio avviso sì: la persona esposta diventa il vettore più probabile di ingegneria sociale. Questo rischio entra nell’analisi richiesta dall’art. 32 GDPR e, per i soggetti NIS, dall’art. 24, comma 2, lettera a), del decreto.

Il principio di minimizzazione (art. 5, paragrafo 1, lettera c, GDPR) acquista qui una funzione difensiva: recapiti diretti e organigrammi pubblicati senza necessità sono la materia prima di questi attacchi.

L’intelligenza artificiale: negli attacchi, nella prevenzione, nella gestione

Nessuno degli episodi in tabella è stato attribuito, allo stato, all’uso dell’intelligenza artificiale. Ragionare oggi di decisioni da prendere sotto pressione senza considerarla sarebbe però un errore di prospettiva. L’IA incide su tre piani: su come si attacca, su come si previene, su come un soggetto NIS gestisce i propri adempimenti.

Negli attacchi

Il 3 novembre il National Cyber Security Centre britannico ha pubblicato la sua

rassegna annuale

. Vi si valuta che l’IA difficilmente cambierà gli obiettivi di chi attacca, ma con alta probabilità ne aumenterà velocità, scala ed efficienza, accelerando tecniche già note più che creandone di nuove. Lo stesso documento segnala che i modelli sono in grado di individuare vulnerabilità rimaste a lungo inosservate. Per chi difende, la conseguenza è una corsa a ridurre il tempo tra la scoperta di una falla e l’applicazione della correzione.

Lo stesso giorno Bitdefender ha documentato

un’intrusione ransomware in un gruppo di scuole britanniche

. Alcune fasi mostrano un operatore umano; altre il comportamento di un ciclo automatizzato, che sottopone a un modello linguistico l’esito di ogni comando e ne esegue la correzione. L’azienda presenta questa lettura come ipotesi di lavoro, non come fatto accertato, e sottolinea che nessuna delle tecniche impiegate era nuova.

Il caso è istruttivo anche per un’altra ragione. L’attaccante ha preso di mira i backup e, prima di cifrare i sistemi, ha sottratto file da un archivio dell’area finanziaria. Disponibilità e riservatezza sono state compromesse nello stesso incidente, e le due qualificazioni vanno gestite insieme. Se l’IA accorcia il tempo tra l’ingresso dell’attaccante e il danno, accorcia anche il tempo per accorgersene e decidere.

Vi è poi l’ambiguità. Voci e volti falsificati, di cui la Polizia postale ha documentato l’uso, rendono credibili richieste e rivendicazioni che non lo sono. È la stessa ambiguità descritta dal Quadro congiunto del 2016, ottenuta a costi molto più bassi. La risposta non è tecnica: è il canale di verifica deciso in anticipo, di cui si dirà più avanti.

Nella prevenzione

L’IA serve anche a chi difende. Secondo il NCSC, le organizzazioni con programmi di sicurezza maturi e una governance dell’IA già impostata potranno rilevare meglio le minacce, stabilire con più precisione quali vulnerabilità correggere per prime e automatizzare parte dei processi difensivi. Lo stesso NCSC avverte che questi benefici non saranno distribuiti in modo uniforme: le organizzazioni meno strutturate rischiano di non tenere il passo con attacchi sempre più rapidi.

In concreto, l’IA può accorciare i tempi proprio dove si giocano le distinzioni descritte sopra:

nella correlazione di registri provenienti da sistemi diversi, che consente di capire in fretta se una casella è stata violata o soltanto imitata;
nel rilevamento di volumi anomali di dati in uscita, cioè dell’esfiltrazione che il backup non vede;
nella scelta delle vulnerabilità da correggere per prime, in base all’esposizione effettiva dei sistemi.

Le realtà piccole e medie difficilmente costruiranno da sé queste capacità, e per lo più vi accederanno attraverso fornitori di servizi gestiti, con i limiti di responsabilità di cui si dirà a proposito dell’esternalizzazione.

Due avvertenze. Usare l’IA su registri che contengono dati personali è a sua volta un trattamento, soggetto ai principi del GDPR a partire dalla minimizzazione. E gli strumenti e gli agenti di IA con accesso a sistemi e dati interni sono asset da censire e proteggere come gli altri: a mio avviso rientrano tra i sistemi informativi e di rete cui si applicano le misure dell’art. 24 del decreto NIS. Per i fornitori di sistemi di IA ad alto rischio, l’AI Act richiede inoltre livelli adeguati di accuratezza, robustezza e cibersicurezza (art. 15,

testo sul servizio di assistenza della Commissione

Nella gestione degli adempimenti NIS

Il terzo piano è il meno discusso. Un soggetto NIS deve tenere insieme molti elementi:

l’inventario dei sistemi e dei servizi;
le misure di sicurezza da attuare e documentare secondo le specifiche dell’ACN;
l’elenco dei fornitori e dei rischi che portano con sé (art. 24, comma 2, lettera d, del decreto);
gli adempimenti verso la piattaforma dell’Agenzia;
i termini di notifica, che decorrono dal momento in cui si viene a conoscenza dell’incidente;
la documentazione da sottoporre agli organi di amministrazione e direttivi.

È un lavoro di raccordo continuo, in cui l’IA può aiutare a ricondurre le misure adottate ai requisiti, a segnalare lacune e scadenze, a predisporre una prima bozza di pre-notifica quando le 24 ore hanno già cominciato a decorrere. In questa direzione va

NIS2DESK

, lo strumento che ho sviluppato per la gestione degli adempimenti dei soggetti NIS2.

Anche qui valgono, a mio avviso, due limiti. Il primo: lo strumento organizza e suggerisce, ma non trasferisce la responsabilità, che il decreto colloca in capo agli organi di amministrazione e direttivi (art. 23). Il secondo: i dati di conformità di un soggetto NIS sono, di fatto, una mappa delle sue vulnerabilità. Inventari, lacune, misure non ancora attuate descrivono con precisione dove l’organizzazione è più esposta. Dove lo strumento conserva quei dati, chi può leggerli e se sono protetti con la cifratura diventa una questione di sicurezza in sé.

Qui si colloca anche il rischio che il NCSC chiama shadow AI: dati aziendali trasferiti su strumenti non autorizzati, di cui l’organizzazione perde visibilità e controllo. Quando quei dati sono personali, la questione diventa anche, a mio avviso, una questione di liceità del trattamento. Quando si tratta dei documenti di conformità NIS, l’organizzazione consegna a terzi proprio la mappa che dovrebbe proteggere.

Su tutti e tre i piani resta ferma una regola. La qualificazione dell’incidente e la decisione di notificare, a mio avviso, non si delegano a un modello: restano in capo a chi ne risponde. Lo stesso NCSC osserva che perfino gli attaccanti hanno bisogno di una supervisione umana efficace dei propri agenti per raggiungere i loro obiettivi. A maggior ragione ne ha bisogno chi deve rispondere davanti alle autorità.

L’organizzazione prima delle decisioni

Le decisioni di cui si dirà presuppongono un’organizzazione che esista già. Una cellula di crisi non si costituisce durante la crisi, e un registro degli eventi non si configura dopo l’incidente.

Il primo livello è quello dei vertici. Il decreto NIS attribuisce agli organi di amministrazione e direttivi l’approvazione delle modalità di implementazione delle misure di gestione dei rischi, la supervisione degli obblighi e la responsabilità per le violazioni. Li obbliga inoltre a seguire una formazione in materia di sicurezza informatica (art. 23). La sicurezza, in altre parole, non è delegabile per intero alla funzione tecnica: chi governa l’ente deve essere in grado di comprendere le decisioni che approva.

Il secondo livello è la mappa dei ruoli. In una stessa organizzazione convivono figure che rispondono a norme diverse:

sul versante NIS, il punto di contatto e il referente CSIRT, che tiene i rapporti con il CSIRT Italia;
sul versante GDPR, il titolare, il responsabile della protezione dei dati (artt. 37-39) e i responsabili del trattamento (art. 28);
sul versante tecnico, il responsabile della sicurezza delle informazioni e gli amministratori di sistema.

A mio avviso il rischio non sta nella mancanza di queste figure, ma nella loro separazione. Funzioni che riferiscono a organi diversi, tengono registri diversi e usano linguaggi diversi finiscono per non condividere informazioni, priorità e tempi. È così che il responsabile della protezione dei dati apprende di un incidente quando la pre-notifica al CSIRT Italia è già partita. Oppure che chi qualifica l’evento ai fini NIS ignora che i registri dell’impianto di videosorveglianza contengono dati personali.

Il terzo livello riguarda ciò che si affida all’esterno. Esternalizzare la gestione dei sistemi o della sicurezza non trasferisce la responsabilità: per il GDPR resta in capo al titolare, per il decreto NIS agli organi dell’ente. Vale soprattutto per le realtà piccole e medie che si affidano a un unico fornitore informatico. Quel fornitore diventa insieme il presidio e, come mostra il caso del Brennero, un possibile punto di ingresso.

Il quarto livello sono le persone. L’igiene informatica di base e la formazione sono elementi minimi delle misure di gestione dei rischi (art. 24, comma 2, del decreto). In molte delle vicende delle ultime settimane, il primo punto di contatto con l’attacco è stato una persona:

chi ha ricevuto l’email minatoria;
chi è stato contattato sulla base di dati esposti;
chi avrebbe potuto notare che un valore sul pannello di controllo non tornava.

Un’organizzazione in cui segnalare un’anomalia è semplice, e non espone a rimproveri, accorcia i tempi di qualificazione più di qualsiasi strumento.

Decidere prima

Su questa organizzazione si innestano sei decisioni che, a mio avviso, vanno prese e documentate prima che servano. Per ciascuna, i fatti mostrano che cosa accade quando la decisione manca.

Le soglie

Un’organizzazione colpita da un DDoS che non ha mai definito i propri livelli di servizio attesi deve stabilire, durante l’attacco, se l’indisponibilità è significativa. Lo fa con il sito irraggiungibile, i clienti al telefono e il termine delle 24 ore che decorre. Se invece il livello di servizio è stato formulato in termini misurabili, la qualificazione richiede pochi minuti. Per esempio: una percentuale minima di disponibilità in orario di servizio e una durata massima di interruzione continuativa.

Lo stesso vale sul versante GDPR. L’art. 33 esonera dalla notifica solo se è improbabile un rischio per le persone. Senza criteri di valutazione del rischio decisi in anticipo e applicati in modo coerente, quella valutazione rischia di essere fatta caso per caso, sotto pressione, e di non reggere a un controllo successivo.

I ruoli

Quando lo stesso evento tocca entrambi i regimi, due termini decorrono in parallelo: le 24 ore della pre-notifica al CSIRT Italia e le 72 ore della notifica al Garante. Se la qualificazione NIS e quella GDPR sono affidate a funzioni che non si parlano, il rischio è doppio. Le due notifiche possono descrivere lo stesso evento in modo incoerente, oppure una delle due può essere trascurata perché ciascuno presume che se ne occupi l’altro.

A mio avviso la soluzione è un’unica cellula di gestione dell’incidente, in cui siedano:

chi qualifica l’evento ai fini NIS;
il titolare o chi ne esercita le funzioni;
il responsabile della protezione dei dati, che l’art. 38 GDPR vuole coinvolto tempestivamente in tutte le questioni relative alla protezione dei dati.

Accanto alla cellula, un registro unico degli incidenti, che serva insieme alla documentazione richiesta dall’art. 33, paragrafo 5, GDPR e alla gestione NIS. Ogni ruolo ha bisogno di un sostituto designato: gli incidenti non scelgono i giorni lavorativi.

Le tracce

Le distinzioni che cambiano la qualificazione sono accertamenti sui fatti, non opinioni:

mittente imitato o casella violata;
dati cifrati o dati sottratti;
parametro modificato dal manutentore o da un intruso.

Senza registri degli eventi raccolti in un unico punto, con orari sincronizzati e conservati abbastanza a lungo, quegli accertamenti non si fanno nei tempi richiesti. Nelle sue raccomandazioni sugli impianti, il CSIRT Italia indica di estendere l’analisi fino a novanta giorni indietro, dove i registri lo consentono. Per i dati sottratti serve anche la capacità di accorgersi di volumi anomali in uscita, perché l’esfiltrazione è proprio ciò che il backup non vede.

Un’organizzazione priva di tracce affidabili ha davanti due strade, entrambe sbagliate. Notificare tutto per prudenza, sovraccaricando sé stessa e le autorità. Oppure non notificare nulla per incertezza, esponendosi alla contestazione di non aver notificato ciò che avrebbe dovuto.

I canali

Il primo canale è quello per comunicare durante la crisi. Se la posta è compromessa o il sito è irraggiungibile, chi gestisce l’incidente deve poter contare su un canale alternativo già predisposto. Il decreto NIS lo richiede espressamente, tra gli elementi minimi delle misure di gestione dei rischi: sistemi di comunicazione di emergenza protetti (art. 24, comma 2, lettera l). È anche il canale su cui conservare e far circolare, senza alterarli, i messaggi di minaccia che le forze dell’ordine chiederanno.

Il secondo canale è quello per verificare. Le schede personali nel dark web e i video falsificati con l’intelligenza artificiale, di cui la

Polizia postale

ha documentato l’uso, rendono credibili richieste che non lo sono. La regola va decisa prima: ogni richiesta insolita di pagamenti, credenziali o dati riservati si verifica su un canale indipendente e già noto, anche e soprattutto quando sembra provenire dal vertice.

Il terzo canale è quello verso l’esterno. Il caso DIA mostra quanto in fretta una rivendicazione non verificata produca allarme. Chi comunica, dopo quali verifiche e in quali tempi è una decisione da prendere a freddo, non nel momento in cui i giornalisti chiamano.

I fornitori

Il caso del Brennero è un promemoria: il punto di scambio con i fornitori è per definizione un’apertura del perimetro. La decisione da prendere prima riguarda soprattutto i tempi. Un fornitore che contrattualmente deve segnalare un incidente “tempestivamente”, senza termini precisi, può farlo quando la pre-notifica al CSIRT Italia è già scaduta. I contratti dovrebbero prevedere termini di segnalazione compatibili con i propri, con un contenuto minimo che consenta di qualificare l’evento. A questo si aggiungono:

accessi e collegamenti di condivisione con scadenza predefinita;
una politica di conservazione per gli spazi di scambio, così che non vi restino documenti che non servono più.

I bollettini

Il 4 novembre il CSIRT Italia ha esteso le raccomandazioni sugli impianti di refrigerazione a chiunque utilizzi strumenti di telecontrollo industriale, con rinvio al bollettino sui

dispositivi IoT e i servizi di accesso remoto

. Un’organizzazione che gestisce impianti connessi si trova davanti a una scelta: applicare le misure, applicarne una parte, ritenerle non pertinenti.

I bollettini non sono atti normativi. A mio avviso, però, possono concorrere alla valutazione dell’adeguatezza delle misure ai sensi dell’art. 24 del decreto NIS e dell’art. 32 GDPR. Davanti a un incidente, sarà difficile sostenere che un rischio descritto pubblicamente, con le relative contromisure, non fosse conoscibile. Ciò che conta, allora, è documentare la decisione presa davanti al bollettino:

chi lo ha valutato;
se riguarda i propri sistemi;
quali misure sono state adottate e quali no, e per quale ragione;
entro quando si completeranno le altre.

Una scelta motivata di non applicare una misura è cosa diversa da un bollettino ignorato.

Intrecciate o contrapposte?

Torno alla domanda della sessione di Lecce. A mio avviso NIS e GDPR, di per sé, non si intrecciano né si contrappongono: hanno oggetti diversi e convivono senza conflitto. Coincidono o si scontrano nelle organizzazioni, a seconda di come queste si sono preparate.

Dove l’organizzazione è stata costruita prima, e soglie, ruoli, tracce, canali e rapporti con i fornitori sono stati decisi a freddo, un incidente che tocca entrambi i regimi si traduce in due valutazioni coerenti e in due notifiche tempestive. Dove quelle decisioni mancano, lo stesso incidente produce incertezza, ritardi e versioni contraddittorie. È esattamente l’effetto che chi produce ambiguità cerca di ottenere.

L’intelligenza artificiale non cambia questa conclusione. Riduce il tempo disponibile per decidere e, usata con le cautele dette, aiuta a prepararsi. In nessun caso sposta la responsabilità di chi decide.

Il rapporto tra i due regimi è approfondito anche nel contributo della serie NIS2 in Italia, oltre le scadenze dedicato a

NIS2, GDPR e DORA

Fonti

Atti e documenti istituzionali

Commissione europea e Alto rappresentante,

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

, 6 aprile 2016

Commissione europea, ENISA, Europol EC3, CSIRTs Network, EU-CyCLONe,

Joint statement on cyber incidents in refrigeration systems across the EU

, 4 novembre 2026

Decreto legislativo 4 settembre 2024, n. 138

Regolamento (UE) 2016/679 (GDPR)

Regolamento (UE) 2024/2847 (Cyber Resilience Act)

ACN,

Guida alla lettura delle Linee guida NIS, specifiche di base

ACN, CSIRT Italia,

Misure urgenti di verifica e mitigazione per operatori della distribuzione alimentare e della filiera del freddo (BL01/261013/CSIRT-ITA)

ACN, CSIRT Italia,

Dispositivi IoT e servizi di accesso remoto connessi ad Internet: rischi e mitigazioni

ACN,

Linee guida per la configurazione del servizio di posta elettronica per l’autenticazione del mittente

Polizia di Stato, Commissariato di P.S. online,

Attenzione alle false proposte di investimenti online

Commissione europea, AI Act Service Desk,

Article 15: Accuracy, robustness and cybersecurity

National Cyber Security Centre,

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

, 3 novembre 2026

Notizie e altre fonti citate

Bitdefender,

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

, 3 novembre 2026

DIGEAT Festival,

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

, Lecce, 6 novembre 2026

ANSA, 7, 8 e 9 novembre 2026, ai link indicati nel testo
LaPresse,

dichiarazioni del ministro degli Esteri

, 8 novembre 2026

BBT SE, nota del 9 novembre 2026, riportata da

Prima Pagina News

---

Questo contributo ha finalità divulgative e non costituisce consulenza legale. Il quadro è aggiornato al [DATA]; i fatti riportati sono oggetto di indagini in corso e gli atti citati vanno verificati sui testi ufficiali.

---

Nuovo su Gemini? Questa capsula si legge al meglio con un client Gemini, come Lagrange.

Lagrange - client Gemini per desktop, iOS e Android

Torna all'elenco articoli

Sezione italiana

Home