Incidente significativo ai sensi della NIS 2
Due criteri qualitativi, un regolamento con numeri per l'infrastruttura digitale e un registro decisionale scritto per tutti gli altri.
Perché la definizione è importante
La significatività è ciò che avvia l'intero orologio della segnalazione previsto dall'articolo 23 NIS 2: un preallarme entro 24 ore, una notifica dell'incidente entro 72 ore, una relazione finale entro un mese. Se l'evento è significativo, l'orologio parte nel momento in cui ne venite a conoscenza. Se non lo è, non dovete nulla né al CSIRT né all'autorità competente.
L'articolo 23, paragrafo 3, NIS 2 vi fornisce solo due formule generali. Il regolamento di esecuzione (UE) 2024/2690 della Commissione (CIR) aggiunge numeri precisi, ma solo per un ristretto gruppo di fornitori digitali (DNS, TLD, cloud, data center, CDN, MSP, MSSP, marketplace, motori di ricerca, social network, servizi fiduciari). Per ogni altro settore NIS 2 il criterio resta qualitativo.
La maggior parte dei CISO sottovaluta questo divario. Se operate nel settore manifatturiero, alimentare, sanitario o della gestione dei rifiuti, non esiste alcuna cifra in euro, alcun conteggio dei minuti, alcuna soglia di utenti. Dovete decidere, dovete decidere in fretta e dovete essere in grado di spiegarne il motivo in seguito.
Direttiva NIS 2 (UE) 2022/2555, art. 23, par. 3
Un incidente è considerato significativo se: a) ha causato o è in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per il soggetto interessato; b) si è ripercosso o è in grado di ripercuotersi su altre persone fisiche o giuridiche causando danni materiali o immateriali considerevoli.
Questa è l'unica definizione generale di incidente significativo nel diritto dell'UE. Entrambi i punti usano la formula "è in grado di causare", quindi dovete valutare il danno potenziale oltre al danno effettivo. Il testo non quantifica mai grave, considerevole o materiale.
CIR (UE) 2024/2690, art. 3
Un incidente è considerato significativo se ha causato o è in grado di causare: a) una perdita finanziaria diretta superiore a 500 000 EUR o al 5 per cento del fatturato annuo totale dell'esercizio finanziario precedente, se inferiore; b) l'esfiltrazione di segreti commerciali del soggetto ai sensi dell'articolo 2, punto 1, della direttiva (UE) 2016/943; c) il decesso di una persona fisica; d) un danno considerevole alla salute di una persona fisica; e) un accesso riuscito, sospettato come doloso e non autorizzato a sistemi informatici e di rete in grado di causare una grave perturbazione operativa; f) i criteri di cui all'articolo 4 (incidenti ricorrenti); o g) uno o più dei criteri di cui agli articoli da 5 a 14 (specifici per soggetto). Un solo criterio è sufficiente.
Sette criteri (lettere da a a g): cinque sostanziali più due rinvii. L'art. 1 del CIR stabilisce che questi numeri si applicano solo a specifici fornitori digitali (DNS, TLD, cloud, data center, CDN, MSP, MSSP, marketplace online, motori di ricerca, piattaforme di social network, servizi fiduciari). Gli articoli da 5 a 14 aggiungono per lo stesso gruppo soglie minime di disponibilità specifiche per settore. Se il vostro settore non figura in tale elenco, questi numeri non sono vincolanti per voi e il criterio qualitativo dell'art. 23, par. 3, è tutto ciò di cui disponete.
§32 BSIG (Germania, esempio di recepimento)
Wesentliche und wichtige Einrichtungen melden dem BSI erhebliche Sicherheitsvorfälle unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung als Frühwarnung, innerhalb von 72 Stunden als Sicherheitsvorfallsmeldung und innerhalb eines Monats als Abschlussbericht.
Ogni Stato membro trasforma l'art. 23 in diritto nazionale. Il §32 BSIG ripete la cascata e designa il BSI come destinatario. Non aggiunge alcun numero proprio per i settori non digitali. Paesi Bassi, Austria e Francia seguono lo stesso schema.
Sette criteri (lettere da a a g)
Cinque criteri sostanziali più due rinvii. a) 500 000 EUR o 5 per cento del fatturato (se inferiore), b) segreti commerciali esfiltrati, c) una persona deceduta, d) grave danno alla salute di una persona, e) un'intrusione dolosa riuscita in grado di causare una grave perturbazione, f) incidenti ricorrenti ai sensi dell'art. 4, g) soglie specifiche per soggetto ai sensi degli artt. da 5 a 14. Uno solo di essi fa scattare la significatività per i fornitori digitali rientranti nell'ambito di applicazione.
Incidenti ricorrenti
I piccoli incidenti si sommano. Se la stessa causa originaria produce almeno due incidenti in sei mesi e, insieme, essi superano la soglia di perdita finanziaria di cui all'art. 3, par. 1, lett. a), il CIR li tratta come un unico incidente significativo. Conteggiarli singolarmente è errato.
Specifiche per DNS e TLD
Per i resolver DNS e i registri TLD: risoluzione dei nomi non disponibile per più di 30 minuti, tempo medio di risposta superiore a 10 secondi per più di un'ora, oppure integrità dei dati compromessa per più di 1 000 domini o l'1 per cento del portafoglio. Gli articoli da 6 a 14 stabiliscono soglie minime analoghe per cloud, CDN, MSP, MSSP, marketplace, motori di ricerca, social network e servizi fiduciari.
Criterio A: grave perturbazione operativa o perdite finanziarie per il vostro soggetto
È il criterio rivolto verso l'interno. La direttiva non vi fornisce alcuna cifra in euro, alcuna durata, alcuna percentuale. Il considerando 101 indica tre elementi da esaminare: quanta parte del servizio è interessata, quanto dura l'incidente e quanti utenti colpisce. Usateli per strutturare il vostro ragionamento. Non trattateli come una lista di controllo.
Criterio B: danno materiale o immateriale considerevole a terzi
È il criterio rivolto verso l'esterno. Clienti, cittadini, operatori a valle, la vostra catena di approvvigionamento. Il danno immateriale comprende i danni alla reputazione e alla fiducia. Un breve disservizio che blocca il flusso di lavoro di un ospedale, espone dati dei clienti o mette fuori servizio un servizio cittadino può soddisfare questo criterio anche se la vostra perdita è modesta.
Un ransomware blocca la produzione per due giorni
Le operazioni si fermano. Il criterio A dell'art. 23, par. 3, NIS 2 (grave perturbazione operativa) è soddisfatto. Preallarme 24 h, notifica dell'incidente 72 h, relazione finale 1 mese (art. 23 NIS 2 / §32 BSIG).
E-mail di phishing cliccata, nessuna password inserita
Contenimento riuscito, nessun impatto sui servizi o su terzi. La notifica volontaria ai sensi dell'art. 30 NIS 2 è disponibile se desiderate condividerla e non impone alcun obbligo aggiuntivo (art. 30, par. 4).
Interruzione del fornitore cloud, il vostro servizio risulta rallentato
Se il vostro servizio diventa significativamente più lento o si interrompe, il criterio A è soddisfatto. Verificate anche il criterio B: ne risentono i clienti o gli operatori a valle? (art. 23, par. 3, NIS 2)
Un attacco DDoS mette fuori servizio il portale clienti per quattro ore
Interruzione significativa per i clienti. Entrambi i criteri dell'art. 23, par. 3, NIS 2 sono potenzialmente soddisfatti. Per i fornitori DNS, cloud o di servizi fiduciari, verificate anche gli artt. da 5 a 14 del CIR.
Una configurazione errata espone dati dei clienti
Articolo 33 GDPR: 72 h all'autorità di controllo. Se viene superata anche una soglia NIS 2 (art. 23, par. 3, NIS 2 o art. 3 CIR), in aggiunta l'articolo 23 NIS 2: preallarme di 24 h al CSIRT. Entrambi gli orologi partono nel momento in cui se ne viene a conoscenza.
Fornitore violato, il vostro servizio risulta interessato
Verificate per primo il danno al vostro soggetto o ai vostri clienti. Non ogni incidente di un fornitore fa scattare il vostro obbligo di notifica. In parallelo: documentate la vigilanza sui fornitori ai sensi dell'art. 21, par. 2, lett. d), NIS 2.
Non siete sicuri se la soglia sia superata? Inviate il preallarme e aggiornatelo in seguito. L'art. 23, par. 4, lett. a), NIS 2 è concepito esattamente per questo. L'autorità competente preferisce un precoce "non ne siamo ancora sicuri" a un tardivo "abbiamo aspettato troppo a lungo".
L'articolo 30, paragrafo 1, NIS 2 consente la notifica volontaria di incidenti, minacce informatiche e quasi-incidenti al CSIRT. Ciò si applica ai soggetti rientranti nell'ambito di applicazione della direttiva e ai soggetti che ne sono al di fuori e desiderano notificare un evento significativo.
L'articolo 30, paragrafo 4, NIS 2 è la tutela fondamentale: la notifica volontaria non comporta l'imposizione di alcun obbligo aggiuntivo al soggetto notificante. Segnalare un caso al limite non comporta alcun rischio di obblighi supplementari. Ciò elimina la scusa più ovvia per non notificare un incidente poco chiaro.
L'articolo 23, paragrafo 2, NIS 2 aggiunge un obbligo distinto. I soggetti essenziali e importanti comunicano, senza indebito ritardo, ai destinatari dei loro servizi le eventuali misure o azioni correttive che questi possono adottare per attenuare i rischi derivanti da una minaccia informatica significativa. Non si tratta della notifica al CSIRT, bensì della comunicazione esterna verso i clienti.
In Germania, il §35 BSIG attua questa disposizione. Il §35, par. 1, consente al BSI di ordinare la comunicazione. Il §35, par. 2, obbliga inoltre determinati settori (finanza, previdenza sociale, infrastruttura digitale, gestione dei servizi TIC, servizi digitali) a effettuare la comunicazione di propria iniziativa. La comunicazione può avvenire mediante pubblicazione sul sito web del soggetto.
Orientamenti del BSI ai sensi del §32 BSIG
Il BSI ripete la formulazione dell'art. 23, par. 3, e vi rimanda al suo modulo di segnalazione standard (MIRP). Non pubblica alcun numero per i settori non digitali. La posizione del BSI: valutate la significatività rispetto ai criteri qualitativi, mettete per iscritto il vostro ragionamento e segnalate in caso di dubbio.
Technical Implementation Guidance dell'ENISA
La Technical Implementation Guidance (TIG, v1.2 agosto 2025) dell'ENISA fornisce indicazioni pratiche sulla valutazione dell'impatto e rinvia alle soglie del CIR ove applicabili. La TIG non è vincolante e rimanda esplicitamente i settori al di fuori dell'ambito del CIR alle autorità nazionali.
Altri recepimenti degli Stati membri
La Cyberbeveiligingswet olandese, la bozza del NISG 2024 austriaco e il regime OIV/REC francese ripetono tutti il criterio dell'art. 23, par. 3, parola per parola. Nessuno di essi ha finora pubblicato numeri per i settori non digitali. Lo schema in tutta l'UE è il medesimo: criterio qualitativo più il CIR per il gruppo digitale.
Mito 1: lo capiremo quando lo vedremo.
Realtà: l'art. 23, par. 3, vi concede 24 ore per decidere, mettere per iscritto il ragionamento e difenderlo in sede di audit. Se non avete messo per iscritto i vostri criteri prima dell'incidente, dovrete decidere sotto pressione senza alcuna documentazione su cui basarvi. Costruite il quadro decisionale ora, non il giorno stesso.
Mito 2: solo le violazioni di dati contano come incidenti significativi.
Realtà: l'art. 23, par. 3, lett. a), riguarda la perturbazione operativa e le perdite finanziarie senza alcun riferimento ai dati personali. Una linea di produzione bloccata da un ransomware senza esfiltrazione di dati è un incidente significativo. Una piattaforma logistica fuori servizio per tre ore è un incidente significativo. La NIS 2 non è il GDPR.
Mito 3: i piccoli incidenti al di sotto della soglia non si sommano.
Realtà: l'art. 4 del CIR (e la stessa logica vale per i criteri qualitativi) stabilisce che incidenti ripetuti con la stessa causa originaria si sommano. Due disservizi di 20 minuti dovuti allo stesso componente difettoso entro sei mesi possono superare insieme la soglia. Conteggiare ciascuno separatamente è errato.
Gli allegati I e II della NIS 2 coprono all'incirca 18 settori. Solo il gruppo digitale di cui all'art. 1 del CIR (circa 11 tipi di soggetto) ottiene dei numeri. Si tratta di una piccola fetta dei soggetti rientranti nell'ambito di applicazione. Per energia, trasporti, settore bancario, infrastrutture dei mercati finanziari, sanità, acqua potabile, acque reflue, pubblica amministrazione, spazio, settore postale, gestione dei rifiuti, prodotti chimici, prodotti alimentari, settore manifatturiero e ricerca, il criterio resta qualitativo.
È qui che potete essere utili nella stanza. La risposta onesta alla domanda del consiglio di amministrazione ("che cosa conta come significativo per noi?") è: l'UE l'ha rimesso al vostro giudizio, ecco i tre fattori del considerando 101, ecco il registro decisionale che produrremo il giorno stesso, ecco chi lo firma, ecco il modulo di segnalazione del BSI che presenteremo. La risposta difendibile non è un numero. È una decisione messa per iscritto.
Il modulo incidenti di nisd2.eu acquisisce il ragionamento della vostra classificazione come campo strutturato collegato all'art. 23, par. 3. Per i soggetti dell'infrastruttura digitale, i numeri degli artt. 3, 4 e 5 del CIR compaiono come guard rail. Per tutti gli altri, i tre fattori del considerando 101 compaiono come modello guidato, il ragionamento viene firmato e marcato temporalmente e il record alimenta le relazioni di 24 e 72 ore.
Il risultato è un record che potete difendere: la decisione, il ragionamento, il firmatario, la marca temporale. È ciò che l'autorità competente e il BSI richiedono dopo un evento al limite. È anche ciò che tutela l'organo di gestione ai sensi dell'art. 20 NIS 2 qualora qualcuno contesti in seguito la decisione.
- Direttiva (UE) 2022/2555 (NIS 2), art. 23 e considerando 101 — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regolamento di esecuzione (UE) 2024/2690 della Commissione, articoli 1, 3, 4, da 5 a 14 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSIG §32 (Germania) — portale normativo bsi.bund.de
- ENISA Technical Implementation Guidance sulla segnalazione degli incidenti NIS 2 (TIG) — enisa.europa.eu
- Modulo di segnalazione MIRP del BSI e orientamenti sugli incidenti — bsi.bund.de