Da domani, 20 novembre 2025, sul portale dell’Agenzia per la Cybersicurezza Nazionale (ACN) si accende un tassello chiave del decreto NIS2: la procedura telematica per la designazione del referente CSIRT.
La finestra è già scritta nero su bianco: dal 20 novembre al 31 dicembre 2025 il Punto di Contatto di ciascun soggetto essenziale o importante dovrà indicare il proprio referente e gli eventuali sostituti.
Non è un adempimento di fine anno da sbrigare tra panettone e bilanci: è il momento in cui ogni organizzazione deve decidere chi, nei giorni peggiori, avrà il compito di parlare con il CSIRT Italia e di firmare le notifiche di incidente previste dagli articoli 25 e 26 del decreto legislativo NIS2.
In pratica, chi si prenderà la responsabilità operativa e formale di gestire il rapporto con l’autorità quando i sistemi sono in crisi.
Indice degli argomenti
Chi è davvero il referente CSIRT
L’articolo 7 della determinazione del Direttore ACN è molto chiaro: il referente CSIRT è una persona fisica, designata dal Punto di Contatto attraverso la procedura che sarà disponibile sul portale. Non è una “struttura”, non è una “funzione aziendale” generica, non è una società esterna in quanto tale. È un nome e un cognome, associato a responsabilità ben precise.
Questa persona diventa l’interlocutore stabile dello CSIRT Italia: è lei che, per conto del soggetto NIS, effettua le notifiche degli incidenti significativi e delle informazioni rilevanti previste dagli articoli 25 e 26. Per evitare che tutto si blocchi se il referente è in ferie, malato o semplicemente irraggiungibile, la determinazione prevede la possibilità di indicare uno o più sostituti, che lo supportano e possono operare al suo posto.
Nella sostanza, la normativa sta dicendo alle aziende: “Quando succede qualcosa di serio, non vogliamo dover capire chi chiamare. Vogliamo sapere subito chi è il vostro volto operativo verso il CSIRT Italia”.
Competenze minime e competenze reali
L’articolo 7 richiede che referente CSIRT e sostituti abbiano almeno competenze di base in tre aree: sicurezza informatica, gestione degli incidenti, conoscenza dei sistemi e delle reti dell’organizzazione per cui operano.
È un minimo legale, non un traguardo.
Se il referente deve capire quando un evento rientra nella definizione di “incidente significativo”, raccogliere le informazioni giuste in tempi stretti, coordinarsi con CISO, IT, legale, comunicazione e direzione, e infine parlare con il CSIRT Italia in modo chiaro e strutturato, è evidente che una semplice infarinatura non basta.
Serve qualcuno che conosca l’architettura dei servizi critici, non solo per schema ma per esperienza; che abbia già masticato gestione incidenti e crisi digitali, non solo in teoria; che comprenda le implicazioni legali e reputazionali delle informazioni che sta trasmettendo e sappia tenere insieme livello tecnico e livello di governance.
Ridurre il referente CSIRT a un “cliccatore di moduli” sul portale significherebbe svuotare di senso uno dei nodi centrali dell’intero impianto NIS2.
Interno o esterno? L’unico criterio serio è la competenza
La norma non impone che il referente sia interno o esterno all’organizzazione. Chiarisce solo che deve essere una persona fisica, designata dal Punto di Contatto e posta nelle condizioni di operare.
Questo apre tre scenari:
- figura interna, tipicamente il CISO, il responsabile sicurezza informatica, il responsabile incident response o continuità operativa, nelle aziende che hanno già una struttura di sicurezza matura;
- professionista esterno, pienamente legittimo, purché si tratti di una persona (non della società in quanto tale) con un mandato formale, contrattualizzato, integrato nel processo di gestione incidenti dell’organizzazione;
- modello misto, con referente interno affiancato da consulenti esterni specializzati che lo supportano nel raccogliere le informazioni e nel predisporre le comunicazioni verso il CSIRT Italia.
Il messaggio implicito è semplice: prima la competenza, poi l’organigramma. Se in azienda non esiste una figura che abbia già gestito incidenti complessi e interazioni con autorità o regolatori, scegliere “uno dei soliti noti” solo perché è vicino all’IT è un rischio calcolato al contrario.
Cosa si deve notificare: la soglia dell’“incidente significativo”
Il lavoro del referente CSIRT ruota intorno a una definizione: quella di “incidente significativo” prevista dall’articolo 25 del decreto NIS2.
Il legislatore dice che i soggetti essenziali e importanti devono notificare, senza ingiustificato ritardo, ogni incidente che abbia un impatto significativo sulla fornitura dei servizi. La soglia non è banale: un incidente è significativo quando provoca, o potrebbe provocare, una grave perturbazione operativa o perdite finanziarie rilevanti per il soggetto, oppure quando ha – o può avere – ripercussioni importanti su altre persone fisiche o giuridiche, con danni materiali o immateriali considerevoli.
Non stiamo parlando del singolo server in manutenzione o della classica interruzione di servizio di pochi minuti. Stiamo parlando di eventi che, per scala o impatto, mettono seriamente in discussione la continuità dei servizi o la tutela di dati e diritti di clienti, utenti e cittadini.
Capire se un incidente supera o meno questa soglia non è un esercizio da fare a colpo d’occhio: richiede informazioni tecniche, capacità di valutazione del rischio e un minimo di sensibilità giuridica.
Per rendere meno teorica questa nozione interviene la Determinazione ACN n. 164179/2025, che per soggetti NIS importanti ed essenziali individua, negli allegati, una serie di “incidenti significativi di base”. Ed è proprio qui che si apre il primo nodo interpretativo.
Gli allegati 3 e 4, in realtà, descrivono tipologie di incidenti informatici che, se combinati con i criteri di impatto dell’art. 25, diventano incidenti significativi e quindi da notificare. Non sono una “lista automatica”: non tutto ciò che rientra negli allegati va notificato a prescindere, ma va valutato alla luce dell’articolo 25.
In pratica il percorso è a due step:
- l’evento rientra in una delle categorie di incidente informatico individuate dagli allegati;
- l’impatto è tale da soddisfare i requisiti di significatività dell’articolo 25.
Solo quando entrambe le condizioni sono vere si entra nel perimetro della notifica obbligatoria.
Dentro questo quadro, la Determinazione ACN definisce per i soggetti NIS importanti tre incidenti “di base”:
- perdita di riservatezza verso l’esterno di dati digitali dell’organizzazione o di soggetti su cui essa esercita il controllo (anche parziale);
- perdita di integrità dei dati con impatto verso l’esterno;
- violazione dei livelli di servizio attesi dei servizi e/o delle attività, misurata rispetto ai service level definiti dalla misura DE.CM-01.
Per i soggetti essenziali ritroviamo gli stessi tre casi, con l’aggiunta del famigerato IS-4, che introduce un’ulteriore fattispecie: l’accesso non autorizzato o l’abuso di privilegi su dati digitali di proprietà del soggetto NIS o di soggetti da esso controllati, anche in modo parziale.
Come osserva giustamente chi sta analizzando la Determinazione in queste ore, la lettura corretta è quindi questa: gli IS-1, IS-2, IS-3 (e, per gli essenziali, IS-4) sono incidenti informatici “tipici”; diventano incidenti significativi quando, e solo quando, incrociano i requisiti di impatto dell’art. 25.
Per il referente CSIRT rappresentano una griglia minima molto concreta: se ci troviamo davanti a una perdita di riservatezza, integrità, livello di servizio o a un abuso di privilegi sul perimetro NIS, la domanda da farsi non è più “se” valutare la notifica, ma “quanto è grande l’impatto rispetto alla soglia dell’articolo 25”.
Le tempistiche: 24 ore, 72 ore, rapporto intermedio e relazione finale
Lo stesso articolo 25 fissa una vera e propria tabella di marcia per le comunicazioni verso il CSIRT Italia. Qui l’elenco puntato è inevitabile, perché le scadenze sono il cuore operativo del processo:
- Entro 24 ore dal momento in cui l’organizzazione viene a conoscenza dell’incidente significativo deve partire una pre-notifica. Quando possibile, dovrebbe già indicare se l’evento può avere origine in atti illeciti o malevoli e se è ipotizzabile un impatto transfrontaliero.
- Entro 72 ore dalla stessa conoscenza deve essere trasmessa la notifica vera e propria, con una prima valutazione della gravità e dell’impatto, oltre agli eventuali indicatori di compromissione disponibili.
- Su richiesta del CSIRT Italia può essere inviata una relazione intermedia, con aggiornamenti sulla gestione della situazione.
- Entro un mese dalla notifica va predisposta una relazione finale, che descrive nel dettaglio l’incidente, il suo impatto, la minaccia o la causa originaria che lo ha innescato e le misure di mitigazione adottate o ancora in corso, includendo, se noto, l’eventuale impatto transfrontaliero.
Se al momento della relazione finale l’incidente è ancora in corso, l’articolo prevede anche report mensili sull’evoluzione finché la gestione non è chiusa.
È evidente che il referente CSIRT, da solo, non può materialmente produrre tutte queste informazioni: serve un processo interno che metta in moto SOC, IT, CISO, fornitori, legale e comunicazione. Ma è lui – o lei – che dovrà tenere il filo, verificare la coerenza dei dati, presidiare le scadenze e interfacciarsi con il CSIRT Italia.
Se questo ruolo viene assegnato “all’ultimo minuto”, senza procedure chiare, il conto da pagare si vedrà proprio in queste 24 e 72 ore.
Le notifiche volontarie: non solo incidenti, ma anche minacce e quasi-incidenti
È dunque sugli incidenti “di base”, filtrati dalla lente dell’art. 25, che il referente CSIRT dovrà muoversi in fretta per capire se scattano pre-notifica e notifica formale.
Inoltre, accanto agli obblighi dell’articolo 25, l’articolo 26 apre un altro fronte: quello delle notifiche volontarie di informazioni pertinenti.
Qui lo spirito è di cooperazione: oltre agli incidenti significativi obbligatori, i soggetti essenziali e importanti possono decidere di segnalare al CSIRT Italia anche incidenti diversi, minacce informatiche rilevanti o cosiddetti quasi-incidenti, cioè eventi che avrebbero potuto avere un forte impatto ma che sono stati intercettati in tempo. Non solo: anche soggetti che non rientrano nel perimetro NIS2 possono effettuare notifiche volontarie quando un incidente o una minaccia ha un peso particolare sui propri servizi.
Le notifiche volontarie vengono trattate seguendo la stessa procedura dell’articolo 25, ma, com’è logico, restano secondarie rispetto a quelle obbligatorie.
Un passaggio importante chiarisce che la notifica volontaria non può trasformarsi da sola in un nuovo obbligo di legge: chi segnala di propria iniziativa non deve trovarsi in una posizione peggiore rispetto a chi tace.
È un modo per favorire la circolazione di informazioni utili alla difesa collettiva, non per punire chi collabora.
Anche qui il referente CSIRT è il punto naturale di raccordo: dovrà valutare, insieme alle funzioni di sicurezza e alla direzione, quando ha senso usare questo canale e con quali contenuti.
Punto di Contatto, referente CSIRT, CISO: ruoli da coordinare, non da confondere
Il quadro normativo introduce diversi attori: il Punto di Contatto verso ACN, il referente CSIRT verso il CSIRT Italia, e le figure interne già esistenti (CISO, responsabile sicurezza, responsabile continuità operativa, ecc.).
Questi ruoli possono in parte coincidere, soprattutto nelle realtà più piccole, ma non devono sovrapporsi in modo confuso. Il rischio, altrimenti, è quello che molti di noi hanno già visto: nomine formali fatte per rispettare l’obbligo, modulistica compilata all’ultimo minuto, e poi, quando arriva l’incidente vero, nessuno che sappia esattamente chi deve parlare con chi, e su quali basi.
La designazione sul portale ACN dovrebbe essere l’ultimo passo di un lavoro fatto a monte: chiarire responsabilità, aggiornare il processo di gestione incidenti, integrare piano di crisi e comunicazione, definire come vengono raccolte le informazioni, chi le valida e chi autorizza l’invio al CSIRT Italia.
Cosa dovrebbero fare adesso i soggetti NIS2
Alla vigilia dell’apertura della procedura, la domanda è pratica: cosa fare, subito, per non farsi trovare impreparati?
Il primo passo è verificare che il Punto di Contatto sia individuato, consapevole del proprio ruolo e nelle condizioni operative di accedere al portale ACN. Senza questo passaggio, la designazione non parte nemmeno.
Il secondo passo è selezionare con cura la persona che diventerà referente CSIRT, guardando meno al titolo in organigramma e più alla sostanza: esperienza in incident response, capacità di lettura del rischio, attitudine al coordinamento tra livelli tecnico e direzionale, lucidità nella gestione di situazioni critiche.
Terzo passo: individuare uno o più sostituti, che conoscano dossier, infrastruttura e processi quasi quanto il referente, in modo da non trovarsi con un “single point of failure umano” proprio nel momento meno opportuno.
Infine, è necessario rimettere mano al processo interno di gestione incidenti, verificando che sia effettivamente in grado di produrre in 24 e 72 ore le informazioni che gli articoli 25 e 26 richiedono: descrizione degli eventi, impatto, gravità, indicatori di compromissione, misure di contenimento e mitigazione, valutazione di eventuali impatti transfrontalieri e coerenza con le categorie di incidente significativo di base (IS-1, IS-2, IS-3 e, per gli essenziali, IS-4) definite dalla Determinazione ACN n. 164179/2025.
Solo a questo punto ha senso andare sul portale ACN e inserire nomi e dati: non come riempimento di caselle, ma come ultimo atto di una scelta consapevole.
Da domani, con l’apertura della procedura sul portale ACN, il referente CSIRT smette di essere una sigla in un articolo e diventa un ruolo reale, con responsabilità concrete. Sarà la voce dell’organizzazione davanti al CSIRT Italia quando si verificherà un incidente significativo.
Si può scegliere in fretta, perché “bisogna chiudere entro fine anno”. Oppure si può scegliere bene, sapendo che, quando le cose andranno storte, sarà proprio a quella persona che affideremo le parole più delicate da pronunciare a nome della nostra organizzazione.
