Condivisione informazioni cybersicurezza NIS2: aderire è volontario, comunicarlo no

Il suo cliente è entrato in un ISAC di settore l'autunno scorso. Scelta sensata: allerta precoce sui gruppi ransomware che lavorano quel comparto, in cambio dei propri indicatori.

Nove mesi dopo un ispettore chiede a quali accordi di condivisione delle informazioni di cybersicurezza il soggetto partecipa. La partecipazione c'è. La comunicazione no. Nessuno l'ha fatta, perché nessuno ha letto oltre la parola «volontario».

Questo è l'articolo 29 della NIS2. La condivisione informazioni cybersicurezza NIS2 sfugge proprio perché tutto ciò che si vede sembra facoltativo.

L'articolo 29 rende volontario lo scambio e obbligatoria la comunicazione

L'articolo 29, paragrafo 1, impone agli Stati membri di garantire che i soggetti nell'ambito di applicazione — e, ove pertinente, quelli fuori ambito — possano scambiare volontariamente informazioni rilevanti di cybersicurezza. La direttiva le elenca: minacce informatiche, quasi incidenti, vulnerabilità, tecniche e procedure, indicatori di compromissione, tattiche degli avversari, informazioni specifiche sugli attori della minaccia, allerte e raccomandazioni sulla configurazione degli strumenti di rilevamento.

Due test di finalità delimitano il perimetro. Alla lettera a), lo scambio deve mirare a prevenire, rilevare, gestire incidenti o ripristinare, oppure ad attenuarne l'impatto. Alla lettera b), deve elevare il livello di cybersicurezza: consapevolezza, limitazione della diffusione delle minacce, rimedio e divulgazione delle vulnerabilità, rilevamento, contenimento e prevenzione, strategie di mitigazione, risposta e ripristino, o ricerca collaborativa tra soggetti pubblici e privati.

Il paragrafo 2 fissa la forma. Lo scambio avviene all'interno di comunità di soggetti essenziali e importanti e, ove pertinente, dei loro fornitori o prestatori di servizi, attraverso un accordo di condivisione delle informazioni di cybersicurezza, proprio perché la materia è sensibile.

Poi il paragrafo 4, la frase che quasi tutti i programmi saltano: gli Stati membri assicurano che i soggetti essenziali e importanti comunichino alle autorità competenti la propria partecipazione a tali accordi al momento dell'adesione, o il ritiro non appena questo produce effetti.

Nessuna soglia. Nessun test di rilevanza. Nessun periodo di grazia scritto nell'articolo.

Un accordo non è una chat di gruppo

La parola «accordo» qui pesa davvero, ed è dove le valutazioni sbagliano in entrambe le direzioni.

Non è un accordo: quattro responsabili sicurezza che si scambiano IOC su Signal. Il blog pubblico sulle minacce di un vendor. Una chiacchierata in corridoio a una conferenza.

È un accordo: un ISAC di settore con carta e condizioni di adesione. Una comunità MISP con regole TLP definite. Una piattaforma gestita da un CSIRT o da un'autorità. Un accordo formalizzato con i fornitori, scritto nel contratto.

Il paragrafo 3 conferma la forma: gli accordi possono specificare elementi operativi, comprese piattaforme ICT dedicate e strumenti di automazione, oltre a contenuti e condizioni dello scambio. Se c'è adesione, ci sono regole e c'è uno schema di classificazione, trattatelo come comunicabile.

La zona grigia è la community sulle minacce gestita da un fornitore, quella che un vendor EDR o di threat intelligence anima per i propri clienti. Se il cliente ha firmato condizioni e alimenta il ritorno, è un accordo, comunque lo chiami la pagina di prodotto.

Italia: ACN, il decreto 138 e le adesioni che nessuno ha censito

L'Italia è partita prima di molti: il d.lgs. 138/2024 recepisce la NIS2 e affida all'Agenzia per la Cybersicurezza Nazionale il ruolo di autorità nazionale competente, con il CSIRT Italia come punto di riferimento operativo.

Proprio questo vantaggio temporale crea il problema. Le comunità di condivisione italiane — settoriali, associative, legate a CSIRT o a fornitori — esistevano prima che l'adempimento diventasse visibile. Molte adesioni risalgono a ben prima dei cicli di registrazione e categorizzazione gestiti sul portale ACN, e non compaiono in nessun fascicolo finché qualcuno non ce le mette. Chi ha seguito la scadenza di categorizzazione ACN conosce il meccanismo: ciò che non entra nel portale non esiste per l'autorità.

La regola che risolve i dubbi: si comunica all'autorità che vigila sul soggetto, non a chi organizza l'ISAC. Se non è chiaro quale sia, partite da l'articolo 26 e il test di giurisdizione.

Stato di Attuazione NIS2 per Paese (2025–2026)
✅
Pienamente in vigore
🇧🇪Belgio
🇭🇷Croazia
🇭🇺Ungheria
🇱🇹Lituania
🇱🇻Lettonia
🇮🇹Italia
6 paesi
📋
Adottata — fine 2025
🇩🇪Germania
🇨🇿Repubblica Ceca
🇫🇮Finlandia
3 paesi
⏳
In corso — previsto 2026
🇳🇱Paesi Bassi
🇫🇷Francia
🇪🇸Spagna
🇵🇱Polonia
🇦🇹Austria
🇸🇪Svezia
🇮🇪Irlanda
7 paesi

L'articolo 29 non è l'articolo 23 e non è l'articolo 30

Tre meccanismi diversi che nelle conversazioni con i clienti finiscono fusi in «notifica».

Articolo 23: notifica obbligatoria degli incidenti. Preallarme entro 24 ore, notifica entro 72 ore, relazione finale entro un mese. Il dettaglio nella nostra analisi dei termini di notifica NIS2.

Articolo 30: notifica volontaria. I soggetti possono segnalare incidenti, minacce e quasi incidenti sotto soglia; possono farlo anche i soggetti fuori ambito.

Articolo 29: è orizzontale, da soggetto a soggetto, non da soggetto a Stato. Lo scambio è volontario. L'unico elemento obbligatorio è dire all'autorità che si partecipa.

Ne derivano due errori tipici: clienti che presentano una comunicazione ex articolo 29 convinti di aver notificato un incidente, e clienti che notificano gli incidenti con precisione e non hanno mai citato le tre community di cui fanno parte.

Si applica al suo cliente?

In quest'ordine.

Il soggetto è essenziale o importante ai sensi della NIS2? Se non lo è, il paragrafo 4 non lo tocca, anche se le condizioni dell'accordo possono comunque vincolare un fornitore.

Il soggetto partecipa a un accordo strutturato nel senso sopra descritto?

È stata presentata una comunicazione all'autorità competente, datata al momento dell'adesione o vicino a esso? «L'abbiamo detto in fase di registrazione» non è una comunicazione.

Due su tre non è conformità.

È sul ritiro che il registro si rompe

L'adesione si ricorda perché qualcuno firma. L'uscita no.

Le adesioni decadono quando se ne va chi le aveva volute. Gli abbonamenti non si rinnovano. Una comunità MISP si spegne e nessuno esce formalmente. Si cambia fornitore di sicurezza e il cliente perde in silenzio l'accesso alla community legata a quel contratto.

Il paragrafo 4 lega la comunicazione al momento in cui il ritiro produce effetti. Qualcuno deve accorgersi di quel momento. In pratica è un problema di registro, non di diritto.

Tenete un elenco per cliente: nome dell'accordo, gestore, data di adesione, data della comunicazione, protocollo, referente interno, data di rinnovo. Rivedetelo quando aggiornate i dati di registrazione: il fascicolo è già aperto. Si veda la nostra guida all'obbligo di registrazione.

Cosa chiede davvero la vigilanza

La domanda arriva di solito dentro una richiesta documentale più ampia. Il set di prove è breve:

• L'elenco degli accordi a cui il soggetto partecipa
• La prova della comunicazione per ciascuno, con data
• Le condizioni o la carta di ogni accordo
• La vostra policy di trattamento delle informazioni ricevute: classificazione, conservazione, chi può agire
• La prova che le informazioni in uscita sono state validate prima della diffusione

L'ultimo punto è sottovalutato. Condividere indicatori durante un incidente in corso tocca insieme riservatezza contrattuale, responsabilità e GDPR. Stabilite in anticipo chi autorizza la condivisione in uscita. Si veda anche la nostra checklist delle evidenze per gli audit NIS2.

Va nell'onboarding, non nella pulizia annuale

La correzione pratica costa circa un'ora per cliente e non si rifà da zero.

Aggiungete due domande al questionario di ingresso: a quali community di condivisione appartiene questa organizzazione e chi, internamente, è titolare di ciascuna adesione. La maggior parte ne cita una e ne dimentica due; il resto si trova nello stack di sicurezza e nelle relazioni con i CSIRT.

Poi presentate le comunicazioni mancanti, registratele e mettete l'elenco nello stesso ciclo di revisione dei dati di registrazione.

Se prima volete sapere dove si trova un cliente su articolo 21, articolo 23 e obblighi degli organi di gestione, avviate una valutazione gratuita di prontezza NIS2 e lavorate sulle lacune che emergono.

Condividere threat intelligence è uno dei pochi obblighi NIS2 che rende un'organizzazione misurabilmente più sicura, non solo meglio documentata. La comunicazione è la parte economica. Fatela bene una volta e tenete il registro aggiornato.