Gestione degli incidenti NIS2: perché l'articolo 21(2)(b) fa fallire più audit dell'articolo 23
Un'analista di sicurezza di un managed service provider olandese rileva traffico in uscita anomalo dal file server di un cliente alle 02:14 di sabato. Apre un ticket, lo etichetta "da verificare" e torna alla coda. L'account manager lo legge lunedì alle 09:30, chiama il cliente e finalmente qualcuno pone la domanda che conta: è notificabile?
A quel punto la finestra di 24 ore per il preallarme è chiusa da 31 ore.
Non è un errore di notifica. È un errore di gestione degli incidenti NIS2 — articolo 21(2)(b) — ed è la misura che decide silenziosamente se ogni altro termine della direttiva sia raggiungibile.
L'articolo 23 prende l'attenzione. L'articolo 21(2)(b) decide se lo rispetti
Quasi tutte le conversazioni sulla compliance partono dall'orologio delle notifiche: 24 ore, 72 ore, un mese. Quei termini vengono dall'articolo 23. Sono visibili, misurabili e facili da mettere su una slide.
L'articolo 21(2)(b) è la misura sottostante. Richiede la gestione degli incidenti: un processo documentato ed esercitato di rilevazione, analisi, contenimento, risposta e ripristino.
La relazione è a senso unico. Non puoi notificare un incidente che non hai classificato. Non puoi classificare un incidente che nessuno ha escalato. E non puoi escalare un incidente che passa il fine settimana in una coda di ticket con l'etichetta "da verificare".
Quando un'autorità di vigilanza rileva un termine di 24 ore mancato, non si ferma al termine. Chiede come il soggetto ne sia venuto a conoscenza, chi abbia deciso e in base a quali criteri. Quella linea di domande atterra esattamente sull'articolo 21(2)(b) — e di solito non trova nulla di scritto.
Cosa richiede davvero il testo vincolante
L'articolo 21(2)(b) della direttiva è una riga. Il dettaglio sta nel Regolamento di esecuzione (UE) 2024/2690 della Commissione, direttamente applicabile in tutti i 27 Stati membri, senza recepimento nazionale.
Il CIR vincola un elenco preciso di tipologie di soggetti: fornitori di servizi DNS, registri dei nomi di dominio di primo livello, fornitori di servizi di cloud computing, fornitori di servizi gestiti ICT e di servizi di sicurezza gestiti, mercati online, motori di ricerca online, piattaforme di social network e prestatori di servizi fiduciari. Se gestisci un MSP o un MSSP, sei in quell'elenco: non come fornitore, ma come soggetto regolato a pieno titolo. Abbiamo trattato questo doppio obbligo in NIS2 per MSP e MSSP.
Per tutti gli altri — energia, sanità, trasporti, manifattura, pubblica amministrazione — il CIR non è formalmente vincolante, ma è la formulazione più autorevole disponibile di cosa significhi "adeguato e proporzionato". Dai per scontato che il tuo regolatore lo leggerà così, perché non ha niente di meglio.
Il punto 3 dell'allegato al CIR riguarda la gestione degli incidenti. Richiede politiche e procedure per rilevazione, analisi, contenimento, risposta e ripristino; ruoli e responsabilità definiti; logging; percorsi di escalation e comunicazione; e una revisione post-incidente strutturata che riporti le lezioni apprese nelle altre misure.
È proprio quest'ultima clausola che i team saltano. La gestione degli incidenti non è un ciclo che si chiude quando il sistema torna operativo. È un input per l'analisi dei rischi, il programma di formazione e la valutazione di efficacia prevista dall'articolo 21(2)(f).
Articolo 21 — 10 Misure di Cybersicurezza NIS2
Articolo 21
10 Misure di Cybersicurezza
Governance & Strategia
1Analisi dei rischi & politiche di sicurezza delle informazioni6Valutazione dell'efficacia delle misure di sicurezzaIncidenti & Continuità
2Gestione degli incidenti & notifica3Continuità operativa & ripristino di emergenzaCatena di Fornitura & Sistemi
4Sicurezza della catena di fornitura5Sicurezza nello sviluppo di sistemi di rete e informativiControlli Tecnici
8Crittografia & cifratura10Autenticazione a più fattori & comunicazioni sicurePersone & Risorse
7Igiene informatica & formazione9Sicurezza HR & controllo degli accessi
La soglia di significatività è un controllo, non una valutazione a sensazione
Il CIR non lascia "significativo" all'interpretazione. L'articolo 3 fissa i criteri: un incidente è significativo se causa una perdita finanziaria diretta superiore a 500.000 EUR o al 5 % del fatturato annuo, comporta l'esfiltrazione di segreti commerciali, oppure provoca il decesso o danni considerevoli alla salute.
L'articolo 4 aggiunge una regola che quasi tutti i processi ignorano: incidenti ricorrenti che singolarmente restano sotto soglia possono essere aggregati e trattati come un unico incidente significativo se, insieme, soddisfano i criteri entro un periodo di sei mesi. Cinque piccoli episodi di credential stuffing sul parco clienti non sono cinque non-eventi. Possono essere un unico incidente notificabile, e nessuno se ne accorge se nessuno monitora l'aggregato.
L'articolo 5 stringe ulteriormente per i fornitori DNS e i registri TLD: una disponibilità inferiore al 99,9 % per qualsiasi periodo è già sufficiente di per sé.
Conseguenza pratica per i consulenti: i criteri di classificazione del cliente devono essere scritti prima dell'incidente, mappati su queste soglie e assegnati a un ruolo nominato. Un'analista alle 02:14 di sabato non deve inventare un test di significatività. Deve applicarne uno.
L'orologio parte dalla conoscenza, non dall'accordo
L'articolo 23(3) avvia la finestra di 24 ore quando il soggetto viene a conoscenza di un incidente significativo. Non quando il management concorda che sia significativo. Non quando si attiva il retainer di incident response. Non lunedì.
È da questa distinzione che nasce la maggior parte dei termini mancati. L'organizzazione aveva l'informazione sabato e la decisione lunedì, e considera il divario un fatto di processo interno. Il regolatore lo considera un ritardo di 31 ore.
Costruisci invece il processo a ritroso dal termine. Se il preallarme scade in 24 ore, l'escalation verso un decisore deve avvenire in ore, quindi la rilevazione deve produrre un alert classificato, quindi qualcuno deve essere raggiungibile fuori orario con autorità decisionale. Ognuno di questi è una scelta di design che fai adesso o che scopri durante un incidente.
La sequenza completa — preallarme a 24 ore, notifica a 72 ore, relazione finale a un mese — è nella nostra guida ai termini di notifica, e i modelli ufficiali di notifica mostrano esattamente quali campi dovrai compilare sotto pressione.
Cronologia delle Notifiche di Incidenti NIS2
24hAllerta Precoce
Notificare all'autorità competente (CSIRT/ANC) entro 24 ore dalla conoscenza di un incidente significativo.
Fase 172hNotifica dell'Incidente
Presentare una notifica dettagliata entro 72 ore con una valutazione iniziale della gravità, dell'impatto e degli indicatori di compromissione.
Fase 21moRapporto Finale
Consegnare un rapporto finale completo entro un mese che copra la causa principale, le misure adottate e l'impatto transfrontaliero.
Fase 324hAllerta Precoce
Notificare all'autorità competente (CSIRT/ANC) entro 24 ore dalla conoscenza di un incidente significativo.
72hNotifica dell'Incidente
Presentare una notifica dettagliata entro 72 ore con una valutazione iniziale della gravità, dell'impatto e degli indicatori di compromissione.
1moRapporto Finale
Consegnare un rapporto finale completo entro un mese che copra la causa principale, le misure adottate e l'impatto transfrontaliero.
Cinque punti in cui la gestione degli incidenti si rompe in un ambiente cliente reale
La rilevazione produce alert, non incidenti. Un SIEM che genera 400 alert al giorno non è rilevazione di incidenti. Rilevazione secondo il punto 3 dell'allegato significa alert triati in un modello di severità definito, con responsabile e tempo di risposta.
L'escalation dipende da una sola persona. Il processo funziona perché Marco sa cosa fare. Marco è in ferie. Documenta il ruolo, non la persona, e nomina un sostituto.
La copertura fuori orario è presunta, non contrattualizzata. Fai la domanda diretta: tra venerdì alle 18:00 e lunedì alle 08:00, chi ha l'autorità di dichiarare un incidente significativo? Se la risposta richiede una riunione, la risposta è nessuno.
Le dipendenze da terzi restano fuori dal processo. L'incidente del tuo cliente può iniziare presso il suo cloud provider, o presso di te. Gli obblighi dell'articolo 21 non si trasferiscono con il carico di lavoro. Gli obblighi contrattuali di notifica verso i fornitori fanno parte del piano — vedi contratti con i fornitori e NIS2.
La revisione post-incidente è un debriefing, non un registro. Una conversazione non è una prova. Il CIR si aspetta una revisione strutturata con risultanze, responsabili e modifiche apportate. Nessun documento, nessuna misura.
La vigilanza si intensifica quando la gestione manca
I soggetti essenziali sono soggetti a vigilanza ex ante: le autorità possono effettuare audit in modo proattivo, senza attendere un incidente. I soggetti importanti sono soggetti a vigilanza ex post, attivata da un incidente o da informazioni credibili di non conformità.
Entrambi i percorsi finiscono allo stesso punto se la gestione degli incidenti manca. Le autorità possono emettere istruzioni vincolanti, ordinare rimedi specifici, imporre la notifica ai clienti interessati, pubblicare la non conformità e comminare sanzioni amministrative. Per i soggetti essenziali il tetto è di 10 milioni di EUR o il 2 % del fatturato annuo mondiale, se superiore. Le conseguenze non finanziarie sono spesso le più pesanti: le abbiamo trattate in 7 sanzioni NIS2 peggiori del denaro.
Nel 2026 tutto questo ha smesso di essere teorico. Il recepimento negli Stati membri è in gran parte completato, la Cyberbeveiligingswet olandese è entrata in vigore il 15 agosto 2026 e a luglio la Commissione ha deferito Irlanda, Spagna, Francia e Paesi Bassi alla Corte di giustizia per recepimento incompleto. Le autorità di vigilanza stanno svolgendo ispezioni su una normativa nazionale che esiste.
Escalation delle sanzioni NIS2 — Oltre la multa
!Evento scatenante
Non conformità rilevata o incidente verificatosi
Un'autorità di vigilanza identifica una lacuna di conformità o un'organizzazione non soddisfa i requisiti NIS2
Le autorità possono imporre▼Sanzioni non finanziarie1Ordini di conformità con scadenze vincolanti
2Audit di sicurezza obbligatori a vostre spese
3Divulgazione pubblica delle violazioni
4Istruzioni vincolanti su misure di sicurezza specifiche
Scala verso▼Conseguenze operative e personali1Sospensione di certificazioni o licenze operative
2Divieto temporaneo di funzioni dirigenziali per individui
3Denominazione pubblica delle persone fisiche responsabili
Evento scatenanteNon finanziarioOperativo / personale
Le prove che dimostrano l'esistenza del processo
Un auditor non valuta le tue intenzioni. Valuta ciò che riesci a produrre. Per l'articolo 21(2)(b) il fascicolo deve contenere:
- Una policy di gestione degli incidenti approvata dal management, con data di revisione entro gli ultimi 12 mesi
- Criteri di classificazione scritti e mappati sulle soglie dell'articolo 3 del CIR
- Una catena di escalation nominata, con sostituti e reperibilità fuori orario
- Ticket di incidente con orario di rilevazione, di classificazione e di decisione come timestamp distinti
- Almeno un'esercitazione o tabletop dell'ultimo anno, con le risultanze prodotte
- Revisioni post-incidente con responsabili assegnati e prova della chiusura delle azioni
- Configurazione e retention dei log che consentano di ricostruire la cronologia a posteriori
Quest'ultimo punto pesa più di quanto sembri. Se la retention è di 30 giorni e depositi la relazione finale a un mese, potresti scrivere di eventi che non sei più in grado di documentare.
Parti dai timestamp. Estrai gli ultimi cinque incidenti da un qualsiasi ambiente cliente e verifica se rilevazione, classificazione e decisione sono registrate separatamente. Se non lo sono, la finestra di 24 ore non è mai stata testata — e scoprirai quanto dura davvero durante l'incidente che conta.
Se vuoi una vista strutturata della posizione di un cliente su tutte e dieci le misure dell'articolo 21 prima di impegnarti su un piano di rimedio, esegui un quick scan NIS2 gratuito. Richiede pochi minuti e offre un punto di partenza difendibile per la conversazione.
La gestione degli incidenti è la misura che trasforma ogni altro controllo in una risposta. Se processo, criteri e orologio sono giusti, l'articolo 23 diventa un passaggio amministrativo. Se sono sbagliati, nessuno strumento salverà il termine.