La sottocategoria ID.RA-08 del Framework Nazionale e i relativi requisiti operativi fissati dall’ACN segnano un passaggio preciso nella gestione della sicurezza: l’organizzazione non può più limitarsi a reagire agli incidenti, ma deve intercettare e governare le vulnerabilità prima che diventino eventi.
Il primo capitolo della nuova tetralogia, dedicata alla sottocategoria ID.RA-08, analizza il significato reale della misura e dei requisiti operativi e ne traduce i contenuti in una logica operativa concreta, mostrando come il monitoraggio delle informazioni sulle vulnerabilità sia oggi una funzione organizzativa strutturata e una responsabilità di vertice.
Indice degli argomenti
La sottocategoria FNCDP merita una tetralogia: ecco perché
L’articolo 24 del D.Lgs. 138/2024 fissa l’obbligo legale di realizzare degli obiettivi di sicurezza, ma non spiega come raggiungerli.
Quindi indica cosa deve essere garantito, ma lascia aperto il passaggio più delicato, quello dell’attuazione.
Questo vuoto è stato colmato dall’ACN, che ha tradotto quegli obiettivi in un sistema concreto e utilizzabile e lo ha fatto individuando in determinate sottocategorie del Framework Nazionale per la Cybersecurity e la Data Protection (FNCDP) le capacità che ogni organizzazione deve sviluppare.
Poi per ogni sottocategoria individuata ha definito i requisiti operativi cioè le azioni precise da realizzare.
Con questo passaggio la compliance alla NIS 2 è diventata un percorso verificabile.
Dentro questo impianto, abbiamo scelto di riflettere a fondo su una sola sottocategoria, la ID.RA-08, dedicandole un’intera tetralogia.
Abbiamo fatto questa scelta, non perché le altre sottocategorie siano meno importanti, ma perché questa misura regola il momento in cui l’informazione sulle vulnerabilità deve essere trasformata in decisione.
È qui che si misura la capacità dell’organizzazione di intercettare i segnali, comprenderli e trasformarli in azione, oppure la sua incapacità di reagire.
Per questo motivo, abbiamo deciso di analizzarla fino in fondo, per mostrare come una singola misura possa incidere sull’efficacia di tutto il sistema NIS 2.
Dalla vulnerabilità all’incidente
La maggior parte degli incidenti informatici non si genera nel momento in cui si manifesta, ma prende forma molto prima, a partire da vulnerabilità già note, già analizzate, già comunicate attraverso canali ufficiali e comunità specializzate.
In molti casi, l’informazione è disponibile, accessibile, condivisa.
Ciò che manca non è il dato, ma la capacità dell’organizzazione di intercettarlo, comprenderlo e trasformarlo in decisione.
È su questo punto che interviene la sottocategoria ID.RA-08 e i relativi requisiti operativi fissati dall’ACN nella determinazione n.379907 del 19 dicembre 2025.
Questo set di misure introduce una disciplina: stabilisce che l’organizzazione deve collocarsi in modo attivo all’interno del flusso informativo sulle vulnerabilità e deve costruire un sistema capace di leggere quei segnali prima che vengano sfruttati da attori ostili.
Questo spostamento è profondo ed impattante ben oltre la routine quotidiana. Non riguarda solo la sicurezza, ma il modo in cui l’organizzazione si relaziona al rischio.
Il significato operativo della misura ID.RA-08
Il primo requisito operativo della sottocategoria in esame richiede che vengano monitorati almeno i canali di comunicazione del CSIRT Italia, nonché di eventuali CERT e Information Sharing & Analysis Centre (ISAC) settoriali – e solo per i soggetti essenziali anche i canali dei fornitori del software ritenuto critico – al fine di acquisire, analizzare e rispondere alle informazioni sulle vulnerabilità.
Questa indicazione, se letta superficialmente, può sembrare un mero ed arido elenco tecnico.
In realtà rappresenta una presa di posizione molto chiara. La vulnerabilità non è un fatto interno all’organizzazione ma un’informazione che frequentemente è già disponibile all’esterno e che deve essere acquisita, analizzata e gestita.
Il monitoraggio diventa quindi una funzione permanente e non può essere un’attività occasionale.
Questo implica che l’organizzazione non può più limitarsi a controllare ciò che accade nei propri sistemi, ma deve anche essere in grado di osservare ciò che accade nel contesto in cui quei sistemi esistono e quindi deve:
- conoscere le fonti;
- selezionare quelle valide, tempestivamente aggiornate ed affidabili;
- presidiare i canali informativi;
- strutturare un flusso informativo continuo.
La sicurezza, in questa prospettiva, non è più solo difesa ma è capacità di “giocare d’anticipo”.
Il peso della parola “almeno” e la costruzione del perimetro informativo
Un passaggio spesso trascurato è l’utilizzo del termine “almeno” nella descrizione dei canali da monitorare. Questo dettaglio cambia completamente l’approccio. La norma non fornisce un elenco esaustivo ma certamente indica una soglia minima.
Tutto il resto è responsabilità dell’organizzazione.
Ciò significa che ogni realtà deve costruire il proprio perimetro informativo in funzione dei sistemi utilizzati, delle tecnologie adottate, delle dipendenze dai fornitori e del proprio contesto operativo.
Quindi non esiste una soluzione standard.
Questo porta a una conseguenza diretta: per poter monitorare in modo efficace, l’organizzazione deve primaconoscere sé stessa, cioè deve avere una visione chiara dei propri asset, delle applicazioni utilizzate, delle componenti critiche e delle interdipendenze tecnologiche.
Senza questa consapevolezza, il monitoraggio diventa un’attività formale. Si raccolgono informazioni ma non si riesce a capire se riguardano davvero il proprio perimetro.
Ovviamente, se manca la comprensione, mancherà anche la decisione.
Il collegamento implicito con la gestione degli asset e del software critico
La misura non impone esplicitamente la costruzione di un elenco del software critico, ma lo rende inevitabile.
Se i soggetti essenziali sono chiamati a monitorare anche i canali dei fornitori di software ritenuto critico, allora è necessario sapere quale software rientra in questa categoria e quali fornitori lo supportano.
Questo introduce un livello di maturità organizzativa che non può essere improvvisato.
Infatti, il software critico non si identifica per intuizione ma deve essere il risultato di una valutazione del rischio coerente con il contesto aziendale.
Inoltre, il concetto di software oggi è molto più ampio rispetto al passato perché include piattaforme cloud, servizi esterni, componenti integrate, sistemi basati su intelligenza artificiale e, in molti contesti, anche tecnologie operative legate al mondo industriale.
Il perimetro è dinamico e cambia nel tempo e quindi, ogni aggiornamento, ogni nuova introduzione, ogni modifica architetturale può alterare il quadro complessivo.
Se questo aggiornamento non avviene in modo continuo, il sistema di monitoraggio perde efficacia e lascia scoperti interi segmenti dell’infrastruttura.
Dal monitoraggio alla decisione
La ricezione di un’informazione postula la necessità di aprire un processo decisionale.
Il secondo requisito operativo della ID.RA-08 stabilisce che le vulnerabilità debbano essere risolte, mitigate oppure accettate. Non esistono altre opzioni.
Questo implica che ogni segnalazione deve essere valutata in relazione al perimetro aziendale, alla criticità dei sistemi coinvolti, all’impatto potenziale e alla probabilità di sfruttamento.
La decisione può portare a un aggiornamento immediato, all’adozione di misure compensative, alla loro diluizione nel tempo o, in alcuni casi, all’accettazione del rischio, ma in ogni caso deve essere una scelta consapevole, motivata e documentata.
Qui si manifesta il vero cambiamento introdotto dalla ID.RA-08.
La gestione delle vulnerabilità non è più un’attività tecnica ma un processo organizzativo che richiede metodo, responsabilità e coerenza con la gestione complessiva del rischio.
Il piano di gestione delle vulnerabilità come strumento di governo
Il terzo requisito operativo della sottocategoria in esame richiede la definizione, l’attuazione e l’aggiornamento di un piano di gestione delle vulnerabilità.
Questo piano non va inteso come un semplice documento descrittivo, ma deve rappresentare un sistema operativo che chiarisca:
- come vengono identificate le vulnerabilità;
- quali canali vengono monitorati;
- chi è responsabile delle diverse fasi del processo;
- quali sono le modalità di gestione.
Il piano deve anche stabilire tempi, priorità e criteri decisionali ma soprattutto deve rendere il processo verificabile.
Ogni passaggio deve poter essere ricostruito e ogni decisione deve essere tracciabile.
Il fatto che questo piano debba essere approvato dagli organi di amministrazione e direttivi è un elemento centrale perché sposta il tema dal livello tecnico/tattico al livello strategico.
Il ruolo del vertice e la responsabilità organizzativa
L’approvazione del piano da parte del vertice organizzativo, prevista dal quarto requisito della ID.RA-08, non è un atto formale, ma il riconoscimento che la gestione delle vulnerabilità incide direttamente sul rischio dell’organizzazione.
Il vertice può delegare l’operatività, ma non può delegare la responsabilità.
Deve quindi assicurarsi che il sistema esista, che funzioni e che sia coerente con gli obiettivi e la propensione al rischio dell’organizzazione.
Questo conferma la nuova logica che caratterizza tutta la normativa NIS 2: la sicurezza non è più un ambito separato affidato all’IT, ma una componente del governo dell’organizzazione.
Se l’organo di governo non vede, l’organizzazione diventa vulnerabile in modo strutturale.
Peraltro bisogna tener presenta che ogni vulnerabilità rappresenta una possibilità di danno, per cui la gestione delle vulnerabilità è strettamente collegata al piano di trattamento del rischio.
Conseguentemente, le decisioni non possono essere prese in modo isolato, ma devono essere integrate in una visione complessiva che tenga conto delle priorità strategiche, delle risorse disponibili e della capacità dell’organizzazione di sostenere il rischio.
Senza questo collegamento, si rischia di prendere decisioni tecnicamente corrette, ma organizzativamente incoerenti.
La logica delle organizzazioni che iniziano a governare il rischio
Si è mostrato come i requisiti operativi della sottocategoria ID.RA-08 introducano una disciplina che cambia il tradizionale punto di osservazione: le organizzazioni non devono limitarsi a proteggere solo ciò che accade all’interno, ma devono anche intercettare ciò che si muove all’esterno prima che diventi un problema interno.
Costruire questo sistema comporta lo sviluppo di una capacità che non è solo tecnica, ma anche organizzativa e decisionale e consente di trasformare l’informazione in consapevolezza e la consapevolezza in azione.
Le organizzazioni che adottano questa logica non si limitano più a reagire agli incidenti e iniziano a governare il rischio.
Le altre continuano a muoversi in ritardo, restando esposte a eventi che
avrebbero potuto intercettare.
Nel prossimo capitolo della nostra tetralogia, il focus si sposterà su un punto altrettanto rilevante: l’attribuzione chiara e non ambigua di ruoli e responsabilità nella gestione delle vulnerabilità; perché senza un soggetto identificato che analizza, decide e agisce, anche il miglior sistema di monitoraggio resta privo di efficacia.
