Notifica degli incidenti ex art. 23 NIS2 — il playbook pratico

Il conto alla rovescia non parte dal momento in cui il SOC apre l'alert, ma da quello in cui vieni a conoscenza dell'incidente; e la data che registri deve reggere anche quando un'autorità, a posteriori, rileggerà i tuoi alert. In pratica:

• Appena ne vieni a conoscenza, avvia il registro cronologico interno dell'incidente e annota il timestamp del primo segnale (umano o automatico).
• Se sospetti che il ritardo nel rilevamento sia esso stesso parte del problema, documentane le cause (lacune nella copertura dei sensori, SIEM in modalità batch, ecc.) per includerle nell'analisi post-incidente.
• Informa il DPO designato e il responsabile degli affari legali in parallelo al SOC: ciascuno ha obblighi propri che possono far scattare altre notifiche (art. 33 GDPR, DORA per il settore finanziario, obblighi settoriali ove applicabili).

Obiettivo: inviare l'early warning ad ACN/CSIRT Italia entro 24 ore dal momento in cui sei venuto a conoscenza dell'incidente.

Contenuto minimo dell'early warning:

• Data e ora di rilevamento dell'incidente (o di inizio stimato).
• Classificazione preliminare: tipo di incidente (intrusione, ransomware, esfiltrazione, DoS, compromissione della supply chain, ecc.).
• Perimetro iniziale: quale servizio essenziale o importante è coinvolto, diffusione geografica, numero stimato di utenti interessati.
• Se si sospetta un impatto transfrontaliero.
• Un unico punto di contatto, con email e numero di telefono.

Cosa NON serve a 24 ore: causa radice completa, elenco completo degli IOC, attribuzione. L'early warning è preliminare per sua natura: in questa fase comunicare troppo poco è peggio che comunicare troppo.

Errore tipico in questa fase: aspettare l'"allineamento" interno prima di inviare. Il decreto non prevede questa attesa e si aspetta l'early warning anche se l'indagine interna è ancora in corso.

Obiettivo: inviare la notifica completa entro 72 ore.

Rispetto all'early warning vanno aggiunti obbligatoriamente:

• Valutazione d'impatto aggiornata (gravità, impatto sui clienti, impatto sui processi aziendali, stima dell'impatto finanziario, se disponibile).
• Indicatori di compromissione: IP, domini, hash, TTP in notazione MITRE ATT&CK.
• Una prima ipotesi sulla causa radice (vulnerabilità sfruttata, vettore di accesso iniziale, percorso di movimento laterale).
• Azioni di contenimento già eseguite; azioni di remediation in corso.
• Se sono stati coinvolti dati personali (e quindi è scattato l'art. 33 GDPR).
• Se si sospetta che l'incidente sia intenzionale (di matrice criminale o statuale): la risposta cambia l'elenco degli interlocutori a valle.

Errore tipico: inviare allo scadere delle 72 ore presentando come conclusioni quelle che sono ancora ipotesi. L'ACN si aspetta ipotesi preliminari oneste, dichiarate chiaramente come tali. Dover ritrattare nella relazione finale a 1 mese una conclusione data per certa è peggio che segnalare l'incertezza fin dall'inizio.

Obiettivo: inviare la relazione finale entro un mese dalla notifica delle 72 ore (art. 23, par. 4, lett. d).

Contenuto della relazione finale:

• Causa radice verificata (o spiegazione dettagliata del perché non è possibile determinarla).
• Elenco completo degli IOC, con attribuzione dove il grado di confidenza lo consente.
• Stato completo della remediation: quali correttivi sono già in produzione, quali sono ancora in corso, date previste per i restanti.
• Lezioni apprese: modifiche a processi, controlli e strumenti.
• Riferimenti alle altre notifiche inviate (art. 33 GDPR, DORA, notifiche settoriali, forze dell'ordine).

È qui che si vede la qualità della catena delle evidenze. Se ogni artefatto è stato firmato al momento della scrittura e la catena è verificabile, la relazione finale è in gran parte un documento di sintesi con i rimandi alle evidenze. Se gli artefatti sono stati raccolti a mano da strumenti diversi, la relazione finale richiede settimane di riconciliazione tra strumenti: un lavoro che il team, nel pieno dell'incident response, non ha le persone per sostenere.

Per tutte e tre le comunicazioni, tieni pronti (firmati, datati e con catena di custodia):

• Cronologia degli alert del SOC (con i timestamp originali, senza modifiche manuali).
• Esportazione della telemetria dei sistemi di rilevamento sulla finestra dell'incidente, più i 7 giorni precedenti.
• Registro delle azioni di contenimento (blocchi sul firewall, disattivazione di account, isolamento di sistemi) con timestamp.
• Registro delle azioni di remediation (patch applicate, configurazioni modificate, ricostruzioni di sistemi) con timestamp e nome di chi le ha approvate.
• Elenco degli IOC con la provenienza di ciascun indicatore.
• Documento di analisi della causa radice, con lo storico delle versioni.
• Registro delle comunicazioni (al personale, ai clienti, alle autorità, alle forze dell'ordine).

Se anche uno solo di questi documenti va ricomposto a mano durante l'incident response, il conflitto sulle risorse è immediato. La lezione operativa che arriva da organizzazioni analoghe: dotarsi di un Trust Center, o di uno strumento equivalente, che firma tutto in anticipo e in continuo, così il playbook si riduce a "esporta, rivedi, firma, invia".

Un singolo incidente fa spesso scattare più regimi di notifica. Le combinazioni più frequenti:

• Violazione di dati dei pazienti in un ospedale: art. 23 NIS2 + art. 33 GDPR + eventuale notifica ad AgID se i dati risiedono in cloud.
• Interruzione di un sistema di trading in una banca: artt. 17-22 DORA + art. 23 NIS2 + notifica di settore alla Banca d'Italia.
• Violazione in una pubblica amministrazione: art. 23 NIS2 + art. 33 GDPR + notifica al Garante + eventuale notifica PSNC se il soggetto rientra nel Perimetro.

In tutti i casi la base di evidenze è la stessa: le notifiche sono sintesi diverse di un'unica documentazione di partenza. Costruirla una sola volta, ed esportarla per ciascun regime, è molto più semplice che gestire in parallelo più percorsi di evidenze. La maggior parte delle implementazioni moderne di Trust Center lo consente; gli strumenti GRC tradizionali di norma no.