Indice
Il contesto di partenza: l’attuale ‘mix‘ normativo tra GDPR e NIS2
A quasi un anno dall’emanazione del D.Lgs. n.138/2024, di recepimento della NIS2, e con l’adozione delle determine dell’ACN per tradurre e concretizzare le misure di sicurezza di base per soggetti importanti ed essenziali, la scadenza del 01.01.2026, per l’implementazione del piano di gestione degli incidenti, si avvicina inesorabile.
È ormai evidente che parlando di protezione dei dati non si possa più parlare solo di GDPR, il quale si focalizza sul diritto personale alla riservatezza e sulla legittimità dei trattamenti dei dati personali da parte dei titolari. Bisogna invece estendere il discorso anche alla NIS2, che tutela la continuità dei servizi più importanti e critici per l’intero tessuto socio-economico.
GDPR e NIS2 appaiono subito come due discipline complementari, inestricabilmente legate ed interconnesse. Infatti, operano in simbiosi e vanno affrontate con un approccio olistico e multidisciplinare, integrando e facendo convergere diverse professionalità.
Ma qual è il rapporto, anche gerarchico, tra GDPR e NIS2?
Il GDPR, essendo un regolamento europeo direttamente applicabile in tutti gli Stati membri, e proteggendo un diritto fondamentale dell’UE, sembrerebbe di rango gerarchicamente superiore rispetto alla NIS2.
Infatti la direttiva NIS2 necessita di attuazione e recepimento a livello nazionale, e sappiamo che il diritto degli Stati membri cede il passo ai diritti fondamentali dell’UE direttamente applicabili.
Quindi nel percorso di compliance alla NIS2, tutte le misure adottate per migliorare la sicurezza informatica, in primis, dovranno inevitabilmente essere conformi anche al GDPR.
Ciò è particolarmente rilevante se si pensa che l’estensione del perimetro applicativo della NIS2 comporterà un notevole aumento dei trattamenti di dati personali a fini di sicurezza informatica (indirizzi IP, identificatori dei dispositivi, file di log, ecc…).
Si pensi, ad es., ai controlli sui dipendenti finalizzati alla sicurezza informatica interna i quali, seppur aumenteranno inevitabilmente, non potranno mai violare la privacy e riservatezza dei lavoratori né andare oltre i limiti consentiti dall’art.4 Stat. Lav.
Per questo i dipendenti dovranno essere preventivamente informati (ex artt.12-13 GDPR) delle nuove misure di cybersecurity che comportano il trattamento dei loro dati personali, aggiornando – se del caso – l’informativa privacy loro rivolta.
Inoltre tali misure dovranno essere sottoposte a valutazioni al fine di assicurare la raccolta solo dei dati personali e dei log necessari allo scopo, la conservazione solo per il periodo necessario al perseguimento delle finalità della norma.
Laddove possibile, andrà prevista la pseudonimizzazione o comunque ulteriori meccanismi per ridurre l’impatto sulla dignità dei lavoratori e sugli eventuali dati anche sensibili trattati a tale scopo.
Quali sono invece le differenze più significative tra GDPR e NIS2?
Una delle differenze più evidenti è che il GDPR si applica a qualsiasi titolare del trattamento a prescindere dalle sue dimensioni (anche ad es. ad microimprese o ad singoli professionisti).
Invece la NIS2 si rivolge direttamente ai soggetti cd. “essenziali” o “importanti” che operano in ambiti critici o altamente critici (ad es. trasporti pubblici, gestione acque e rifiuti, servizi sanitari, ecc..) e che superano al contempo determinati requisiti dimensionali (più di 50 dipendenti e fatturato o bilancio annui maggiori di 10 mln €).
Un’altra differenza rilevante è che la NIS2 non si concentra solo sui dati personali, come il GDPR, ma è finalizzata alla protezione dei dati aziendali di servizio, cioè di quelli fondamentali per la continuità operativa dei servizi più critici come ad es. progetti, brevetti, piani strategici, informazioni su transazioni o interconnessioni digitali.
È però innegabile che uno degli aspetti più importanti su cui le due normative si sovrappongono (c.d. “overlapping”) è la gestione degli incidenti di sicurezza.
Le differenze tra gli incidenti significativi della NIS2 e le violazioni di dati personali del GDPR
Chiariamo subito che per la NIS2 un incidente è un evento di sicurezza che compromette la disponibilità, l’autenticità, l’integrità o la riservatezza non solo dei dati ma, anche e soprattutto, dei servizi erogati attraverso i sistemi informativi e le reti del soggetto NIS, che vengono quindi interrotti, resi inaccessibili o non fruibili.
Al contempo, però, non tutti gli incidenti sono rilevanti ai sensi della NIS2, ma solo quelli significativi in grado di causare:
- grave perturbazione operativa dei servizi, o
- perdite finanziarie per il soggetto interessato, oppure ancora
- ripercussioni e perdite considerevoli su altri soggetti.
Non sono invece incidenti significativi, tali da far scattare gli obblighi NIS2, i c.d. quasi-incidenti o ‘near-miss‘ che avrebbero potuto configurare un incidente, ma che sono stati evitati prima che si concretizzassero o, comunque, efficacemente prevenuti.
Già da queste prime definizioni possiamo comprendere come non tutti gli incidenti significativi per la NIS2 siano automaticamente anche violazioni di dati personali per il GDPR.
Vediamo insieme due casi concreti.
Per il caso (A) pensiamo ad es. ad un attacco DDoS che rende indisponibile e irraggiungibile, per i soli pazienti, il sistema di prenotazione di un ospedale. Tale incidente comporta ‘solo‘ l’interruzione dei servizi di prenotazione online, creando appunto disservizi significativi per la NIS2. Ai fini del GDPR, invece, non comporta la perdita d’integrità, riservatezza o disponibilità dei dati personali trattati e archiviati tramite il gestionale di backend dell’ospedale. Perciò non rappresenta una violazione di dati personali.
Per il caso (B) pensiamo ora ad un’errata pubblicazione di dati personali sul sito istituzionale di una pubblica amministrazione, dovuto ad un errore umano. Tale evento potrebbe rappresentare un data breach per il GDPR, ma verosimilmente non sarebbe significativo in ambito NIS2. Ciò in quanto la continuità operativa e l’erogazione dei servizi istituzionali dell’ente non parrebbero esserne intaccati.
I nuovi obblighi di notifica e comunicazione della NIS2 rispetto al GDPR
Laddove un soggetto NIS2 rilevi di aver subito un evento di sicurezza, sarà dunque chiamato (art. 25 D.Lgs. 138/2024) a valutare se esso sia significativo o se invece sia configurabile come un semplice near-miss, in considerazione delle misure positive poste in essere per sventarne la portata lesiva.
Tale valutazione sarà basata su parametri
- sia quantitativi (numero di sistemi interessati, numero dei dati potenzialmente compromessi, durata dell’interruzione dei servizi, impatto economico stimato)
- sia qualitativi (tipologia di dati interessati, potenziale esposizione mediatica, impatto dell’interruzione del servizio critico, conseguenze per i terzi, coinvolgimento di portatori di minacce a livello statale).
Tempistiche
Se il soggetto NIS2 valuta che l’incidente occorso sia significativo, allora scatteranno gli obblighi di notifica al CSIRT dell’ACN (Computer Security Incident Response Team) secondo le seguenti tempistiche:
- Entro 24 h dalla rilevazione dell’incidente: pre-allerta al CSIRT (indicando se è causato da attività illecite o ha implicazioni transfrontaliere)
- Entro 72 h: notifica con valutazione iniziale su gravità, impatti e indicatori di compromissione (IoC)
- Senza ritardi: notifica ai destinatari dei servizi (“sentito il CSIRT, se ritenuto opportuno e qualora possibile“: art.25 co.9 D.Lgs. 138/24)
- Entro 1 mese: relazione finale al CSIRT
Seppur entrambe le normative, per far scattare i rispettivi obblighi di notifica, non richiedano la concreta materializzazione del danno, ma solo la rilevazione dell’incidente potenzialmente dannoso, è molto più evidente la differenza nelle scadenze temporali.
Occorre dunque evitare di confondere le due differenti scadenze e usare invece (se del caso) interamente il termine di 72 ore, ex art.33 GDPR, dalla conoscenza dell’evento prima di fare scelte avventate e notifiche immeditate: come visto sopra (caso A), seguendo le apposite procedure, si potrebbe valutare che lo stesso incidente che ha obbligato il soggetto NIS a pre-allarmare il CSIRT, non rientri fra i casi di obbligo di notifica al Garante.
Cosa fare con la procedura Data Breach del GDPR ora che entra in vigore la NIS2?
In caso d’incidenti significativi che coinvolgano anche dati personali, i soggetti NIS2, a partire dal 01.01.2026, si troveranno quindi a gestire doppi obblighi di notifica, con diverse tempistiche e, soprattutto, diverse finalità e soglie.
Per i soggetti in perimetro NIS2
è dunque un obbligo dotarsi di un IRP che permetta di rispettare le nuove tempistiche viste sopra.
Per affrontare tale sfida di compliance l’iter che sembra il più logico ed efficiente, anche dal punto di vista dei costi/benefici, è partire dalla procedura di data breach esistente ai sensi del GDPR per estenderla ed integrarla anche alle finalità della NIS2 così come declinate dal D.Lgs. 138/2024 e dalle determine dell’ACN.
Questa sembra dunque essere la posizione maggiormente condivisa dai commentatori, ma ciò non significa che sia l’unica chiave di lettura possibile, in quanto anche la NIS2 ribadisce il principio di lasciare all’accountability delle imprese l’implementazione delle misure di cyber-resilience. Anche in questo caso, quindi, occorrerà effettuare una valutazione caso per caso, prima di decidere.
Unificare le policy, comunque, sembrerebbe permettere di evitare il rischio che la gestione delle due norme come compartimenti stagni, separati, possa causare problemi dovuti a duplicazioni, incoerenze o all’assenza o errata comunicazione fra funzioni e procedure aziendali.
Per i soggetti NON in perimetro NIS2
invece, seppur non risultino direttamente sottoposti dall’obbligo di aggiornamento, riteniamo utile un assessment dei propri clienti e investitori:
- se la maggior parte degli introiti deriva da soggetti NIS2 (clienti e investitori medio-grandi che operano nei settori critici e altamente critici della Direttiva) allora risulterà quasi inevitabile l’aggiornamento organico della Data Breach Policy in un IRP coordinato che contempli sia gli incidenti significativi NIS2 sia i data breach GDPR e soprattutto permetta di rispondere alle aspettative dei clienti NIS2;
- se invece solo una minima parte del fatturato deriva da soggetti NIS2, e la maggior parte dei clienti sono piccole o micro imprese che non operano nei settori NIS2, allora potremmo forse trovarci in un caso in cui l’adozione di una procedura separata (c.d. ‘stand-alone‘) permetterebbe di non assumere oneri eccessivi e sproporzionati rispetto alla dimensione aziendale e alle effettive esigenze della clientela.
- Una policy separata, applicabile solo ai clienti che la richiedano e sulla base delle loro indicazioni e aspettative, potrebbe essere opportuna almeno finché il soggetto fuori perimetro NIS2 non avrà raggiunto un livello di awareness tale da estendere tali politiche e impegni volontari anche a vantaggio degli altri stakeholders.
A quali standard, modelli e linee guida ispirarsi per redigere un piano conforme?
Davanti a una sfida di compliance così impegnativa, è spontaneo rivolgersi a standard internazionali e linee guida delle autorità per fare tesoro delle esperienze ivi condensate e indirizzare fin da subito al meglio gli sforzi e gli investimenti.
Senza pretesa d’esaustività, riteniamo che durante il percorso d’adozione delle misure richieste dalla NIS2 possano essere seguiti i seguenti standard e linee guida:
Il Cybersecurity Framework (CSF) del National Institute of Standards and Technology (NIST) americano
Anche le misure di sicurezza di base dell’ACN di aprile 2025 si ispirano all’aggiornamento 2024 del CSF del NIST, così come tradotto, recepito e interpretato dal Framework nazionale per la Cybersecurity e la Data Protection.
Il Framework nazionale è a sua volta frutto della collaborazione tra il Centro Ricerca CIS dell’Università di Roma La Sapienza, il Laboratorio Nazionale Cybersecurity del CINI, e l’ACN stessa, nonché Poste e banche.
Il CSF NIST è stato già rivisto ad aprile 2025 prevedendo un framework olistico, comunque coerente con le misure di sicurezza di base dell’ACN, secondo cui un piano di risposta agli incidenti dovrebbe comporsi delle fasi preparatoria (Govern, Identify, Protect), di contenimento e di mitigazione (Detect, Respond e Recover).
La norma ISO/IEC 27001
La ISO 27001 presuppone un solido Information Security Management System (ISMS) che protegge la riservatezza, l’integrità e la disponibilità delle risorse informative aziendali. Inoltre mappa e raccoglie in un’architettura centralizzata tutti gli aspetti relativi alla sicurezza delle informazioni.
Seppur condivida con la ISO-27001 l’obiettivo generale di migliorare la sicurezza informatica, la NIS2 richiede misure concrete, mentre la ISO-27001 funge ‘soltanto‘ da metodologia, comunque utilissima, in quanto copre la maggioranza dei controlli necessari per conformarsi alla NIS2.
Infatti, la certificazione ISO 27001 non implica in automatico la compliance alla NIS2, principalmente perché non prevede le tempistiche di notifica e comunicazione degli incidenti così come recepite dal D.Lgs. 138/24.
Le Linee Guida d’Implementazione Tecnica dell’ENISA
Molto utili in quanto forniscono un soddisfacente elenco delle policy da implementare e chiarisce i punti in comune, nonché le differenze, tra NIS2 e i framework internazionali (ISO 27001 e NIST).
[Data la loro ampiezza e rilevanza, ne abbiamo parlato più diffusamente in un apposito articolo]
Cosa deve contenere un piano di gestione incidenti per la NIS2?
Di seguito riportiamo quelli che secondo noi sono i tratti comuni più importanti (ma ovviamente non gli unici) di un IRP strutturato sulla base dei modelli, standard e linee guida appena visti.
1) Preparation: organizzazione e strumenti.
Vanno innanzitutto definiti ruoli e responsabilità da distribuire tra CISO, DPO, Security Operation Center (SOC), team IT e responsabili di settori e funzioni. Per prepararsi alla NIS2 si può partire dotando l’organizzazione di software per il monitoraggio integrato tra cui, su tutti, soluzioni di Security Information and Event Management (SIEM) e di Intrusion Detection and Prevention System (IDS/IPS). Ovviamente, inoltre, il personale, soprattutto quello non tecnico, deve essere formato sull’igiene informatica di base e su come usare le relative piattaforme e tool, anche pianificando esercitazioni e simulazioni pratiche affinché gli incaricati reagiscano rapidamente e conformemente anche sotto stress.
2) Identification: detection e conferma.
Il monitoraggio dovrà essere per quanto più possibile continuo e capillare. Il SIEM aggrega log e dati provenienti da molteplici fonti, gli IDS/IPS evidenziano le anomalie e le sottopongono all’attenzione del SOC che conferma se l’evento è incidente significativo, near-miss o falso positivo, per procedere poi all’escalation per le notifiche alle autorità. Il modello del report di escalation, per essere allineato a quello da inviare al CSIRT, dovrebbe richiedere data e ora dell’evento, una sua descrizione, compresi (se disponibili) gli asset coinvolti e gli IoC, nonché eventuali screenshot, log o altre prove rilevanti e le informazioni di contatto del segnalante per eventuali follow-up.
3) Contenimento dell’incidente e limitazione dei danni.
Gli asset compromessi vanno isolati e vanno protette le copie di backup. Se possibile, raccogliere e conservare prove per l’analisi forense. Prioritizzate interventi sugli aspetti più gravi dell’incidente e sui maggiori pericoli concreti: è infatti qui che l’IRP comunica con il BCP in quanto vanno azionati gli strumenti di business continuity (ad es. l’interruzione dei backup automatizzati per prevenire la contaminazione del ransomware alle copie di backup).
4) Eradication: rimozione della minaccia.
Eliminare le root causes e gli IoC integrando intelligence esterna per migliorare le euristiche di rilevazione e accedere alle pratiche di mitigazione più diffuse da applicare.
5) Recovery: ripristino controllato.
Recupero e verifica dei backup, verifica dell’integrità dei sistemi e riattivazione dei servizi e delle funzionalità critiche con test di validazione.
6) Follow-up: lesson learned e miglioramento.
Le analisi post-incidente mirano a comprendere le cause dell’attacco, valutare l’efficacia delle misure di risposta, trovare spunti di miglioramento e correzione del piano di risposta degli incidenti, il tutto da documentarsi opportunamente ai fini di accountability.
Ulteriori caratteristiche più avanzate per una migliore efficacia
È utile ed opportuno dotarsi anche di diversi canali di segnalazione (ad es. email dedicata, hotline, app) per poter ricevere segnalazioni di anomalie anche dall’esterno.
Inoltre, è considerato un nice-to-have aggiuntivo l’adozione da parte dei soggetti NIS2 di manuali o vademecum operativi di risposta agli incidenti statisticamente più diffusi e ricorrenti, contenenti flussi di lavoro dettagliati per gestirli.
I piani e gli strumenti summenzionati devono poi rispondere a criteri di facilità d’uso, di completa integrazione e comunicazione con l’infrastruttura ICT esistente, di rigoroso controllo degli accessi e di legittimità delle licenze.
Come affrontare queste nuove sfide di compliance?
Innanzitutto non partendo da zero, ma dai punti di contatto e sovrapposizione tra le due norme, per innestare la compliance alla NIS2 sulla già esistente compliance al GDPR affinché i cambiamenti più profondi richiesti dalla NIS2 si radichino sulla consolidata architettura del GDPR.
Così si favorisce, come già rilevato in precedenza, un approccio che permette di vedere agli obblighi di compliance come opportunità.
In questo senso, ad es., se il soggetto NIS2 notifica un incidente significativo ma dispone di un piano di gestione incidenti serio e calato sulla propria realtà organizzativa come visto sopra, allora potrà addirittura usufruire (ex art.25 co.7 D.Lgs. 138/24) di orientamenti, consulenza o ulteriore assistenza tecnica da parte del CSIRT.
Infatti, i compiti di vigilanza e sanzionatori dell’ACN (artt. 34 ss. D.Lgs. 138/24), non sembrano il core della normativa – o almeno non nei primi tempi di sua attuazione e applicazione.
Concludendo
Dunque, un buon IRP permette di:
- ridurre l’incertezza, migliorare i processi decisionali ed evitare il caos in situazioni di crisi;
- tramite la fase di post-incident review, imparare dall’evento e prevenire recidive;
- tutelare la reputazione e i rapporti con partner e investitori, generare fiducia nei clienti nonché ridurre i rischi operativi e finanziari.
Tuttavia la sua implementazione richiede tempo, risorse e soprattutto impegno e coinvolgimento del top management. Perché sia un percorso sostenibile servono gap analysis serie, budget calibrati e progressiva semplificazione dei processi una volta a regime.
Se desiderate supporto in questo percorso, siamo a disposizione per valutare insieme priorità, criticità e un percorso di adeguamento e consapevolizzazione in tema di cyber-resilience organizzativa che sia sostenibile e al contempo efficace e coerente con gli obiettivi di business.
