NIS2 e gestione delle vulnerabilità: cosa chiedono davvero le misure di base dell'ACN
Inventari, piano di gestione delle vulnerabilità, aggiornamenti senza ritardo: cosa chiede la Determinazione ACN 379907/2025 e cosa preparare entro ottobre 2026.
Se la tua azienda ha ricevuto dall’ACN la PEC che la inserisce nell’elenco dei soggetti NIS, hai 18 mesi per mettere in piedi le misure di sicurezza di base. Per chi l’ha ricevuta nel 2025 vuol dire ottobre 2026. Una parte di quelle misure riguarda la gestione delle vulnerabilità, ed è quella su cui di solito si arriva meno preparati.
Qui trovi cosa chiede la norma, con i codici e le parole esatte dell’ACN, cosa invece non dice, e cosa ti conviene avere pronto.
In breve
- La regola sta nella Determinazione ACN 379907 del 19 dicembre 2025, in vigore dal 15 gennaio 2026. Ha sostituito la 164179 dell’aprile 2025.
- Le misure che contano per le vulnerabilità sono quattro gruppi: inventari aggiornati, un piano di gestione delle vulnerabilità approvato dai vertici, l’identificazione delle vulnerabilità e l’installazione degli aggiornamenti.
- Non esiste un termine in giorni per applicare le patch. La norma dice “prontamente” e “senza ingiustificato ritardo”. I tempi li fissi tu nel piano, e poi devi rispettarli.
- La scadenza è di 18 mesi dalla PEC di inserimento. L’ACN ha iniziato a inviarle il 12 aprile 2025, quindi per i primi soggetti il termine cade a metà ottobre 2026. Il “31 ottobre” che si legge in giro non compare in nessun documento dell’ACN: conta la data della tua PEC.
- Chi è stato inserito nel 2026 ha tempo fino al 31 luglio 2027.
Da dove arriva l’obbligo
Il D.Lgs. 138/2024, all’articolo 24, chiede misure di gestione del rischio che comprendano almeno, tra le altre cose, la “sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, ivi comprese la gestione e la divulgazione delle vulnerabilità” (comma 2, lettera e) e la “gestione dei beni e degli assetti” (lettera i).
Cosa voglia dire in concreto lo stabilisce l’ACN con le specifiche di base. Sono organizzate come il Framework nazionale per la cybersecurity (le funzioni sono Governo, Identificazione, Protezione, Rilevamento, Risposta, Ripristino) e hanno due allegati:
- Allegato 1, soggetti importanti: 37 misure e 87 requisiti;
- Allegato 2, soggetti essenziali: 43 misure e 116 requisiti.
Le misure hanno codici come ID.AM-02 o PR.PS-02. Conviene usarli anche nei tuoi documenti, perché è con quei codici che un’ispezione ti chiederà conto.
Le misure che riguardano le vulnerabilità
1. Sapere cosa hai: gli inventari
Non puoi gestire le vulnerabilità di un software che non sai di avere. Per questo gli inventari vengono prima di tutto il resto:
- ID.AM-01: un inventario aggiornato dell’hardware, compresi i dispositivi IoT, OT e mobili.
- ID.AM-02: “un inventario aggiornato dei servizi, dei sistemi e delle applicazioni software che compongono i sistemi informativi e di rete, ivi incluse le applicazioni commerciali, open-source e custom”.
- ID.AM-04: un inventario dei servizi informatici erogati dai fornitori, cloud compreso.
- ID.AM-03, solo per gli essenziali: i flussi di rete verso l’esterno.
La norma non dice ogni quanto aggiornarli. Dice “aggiornato”. In pratica un inventario compilato a mano una volta l’anno difficilmente lo è.
2. Il piano di gestione delle vulnerabilità
È il documento centrale, e la misura che lo chiede è la ID.RA-08. Il piano deve comprendere almeno:
- come identifichi le vulnerabilità e con che calendario;
- come monitori, ricevi, analizzi e rispondi alle informazioni sulle vulnerabilità;
- procedure, ruoli e responsabilità.
Due dettagli che si dimenticano spesso:
- il piano va approvato dagli organi di amministrazione e direttivi (ID.RA-08, punto 4), non basta che lo firmi l’IT;
- devi monitorare almeno i canali del CSIRT Italia e, se ci sono, quelli dei CERT e degli ISAC del tuo settore (punto 1). Per gli essenziali si aggiungono i canali dei fornitori del software critico (punto 5).
Poi il punto che regge tutto il resto (ID.RA-08, punto 2): le vulnerabilità “sono prontamente risolte attraverso aggiornamenti di sicurezza o misure di mitigazione, ove disponibili, ovvero accettando e documentando il rischio”. Quindi ogni vulnerabilità finisce in uno di tre modi: corretta, mitigata, oppure accettata con una motivazione scritta. Una vulnerabilità nota e lasciata lì senza una decisione è il caso che la norma non ammette.
3. Identificare le vulnerabilità
La ID.RA-01 vale per tutti: le informazioni raccolte con il piano vanno usate per identificare le vulnerabilità nei tuoi sistemi.
Per i soggetti essenziali c’è di più: sui sistemi rilevanti vanno fatti periodicamente, e comunque prima della messa in esercizio, “vulnerability assessment e/o penetration test”, documentati in una relazione che descriva le attività, gli esiti, le vulnerabilità trovate e il loro impatto (punti 2 e 3).
4. Aggiornare il software
La PR.PS-02 chiede due cose a tutti:
- di installare solo software, sistemi operativi compresi, per cui sono garantiti gli aggiornamenti di sicurezza. Un sistema fuori supporto va motivato o sostituito;
- di installare “senza ingiustificato ritardo” gli ultimi aggiornamenti di sicurezza, in coerenza con il piano.
Per gli essenziali, gli aggiornamenti del software critico vanno provati in un ambiente di test prima della produzione (punto 4).
5. Il rischio, e quando non puoi fare quello che la norma chiede
La valutazione del rischio (ID.RA-05) va rifatta almeno ogni due anni, e ogni volta che succede qualcosa di significativo. Per gli essenziali deve tenere conto delle vulnerabilità non risolte.
Molti requisiti contengono la formula “fatte salve motivate e documentate ragioni normative o tecniche”. Non è una scappatoia: se un sistema non si può aggiornare, lo scrivi, adotti una misura compensativa e la metti nel piano di trattamento del rischio (ID.RA-06). Il macchinario con Windows che il produttore non certifica oltre una certa versione è il caso tipico.
Quello che la norma non dice
Qui molte aziende si bloccano, perché cercano un numero che non c’è.
- Nessun termine in giorni per le patch. Solo “prontamente” e “senza ingiustificato ritardo”. Nemmeno la guida alla lettura dell’ACN fissa un tempo.
- Nessuna frequenza per le scansioni. Per gli essenziali “periodicamente”, per gli importanti non è chiesto un vulnerability assessment vero e proprio.
La conseguenza pratica è che i tempi li decidi tu, li scrivi nel piano, e in caso di verifica devi dimostrare di averli rispettati. Un esempio ragionevole, da adattare al tuo rischio: le vulnerabilità che qualcuno sta già sfruttando si chiudono in pochi giorni, le critiche entro due settimane, le altre nel ciclo di aggiornamento mensile. Quello che conta è che la regola sia scritta, approvata, e che ci siano le prove di averla seguita.
Cosa preparare entro la scadenza
Tra i documenti che l’ACN elenca nelle sue FAQ, per la parte vulnerabilità servono:
- gli inventari (hardware, software e servizi, servizi dei fornitori, e per gli essenziali i flussi di rete);
- il piano di gestione delle vulnerabilità, approvato dagli organi di amministrazione;
- la politica di gestione delle vulnerabilità (misura GV.PO-01), da riesaminare almeno una volta l’anno;
- la traccia di cosa hai fatto: quali vulnerabilità sono state trovate, quando, come sono state chiuse o perché sono state accettate;
- per gli essenziali, le relazioni dei vulnerability assessment o penetration test.
L’ultimo punto dell’elenco è quello che di solito manca. Il piano si scrive in una settimana; la prova di averlo seguito per mesi si costruisce solo lavorando ogni giorno nello stesso modo.
Dove ti aiuta SentriKat, e dove no
SentriKat è fatto per la parte che richiede lavoro continuo:
- Inventario del software sempre aggiornato (ID.AM-02): gli agent su Windows, Linux e macOS riportano ogni giorno cosa è installato, senza liste compilate a mano.
- Identificazione delle vulnerabilità (ID.RA-01): ogni vulnerabilità è confrontata con la versione che hai davvero, e in cima ci sono quelle che gli attaccanti stanno già usando.
- “Prontamente”, dimostrato (ID.RA-08, punto 2): ogni vulnerabilità diventa un intervento con un responsabile e una scadenza, e resta traccia di quando è stata chiusa o del perché è stata accettata.
- Le prove: report firmati sulla gestione delle vulnerabilità, da consegnare a chi te li chiede.
E per correttezza, cosa non fa:
- non monitora per te i canali del CSIRT Italia e degli ISAC di settore: quelli restano da seguire;
- non sostituisce un penetration test, che per gli essenziali resta un’attività a parte;
- non scrive il piano né lo fa approvare: ti dà i dati per scriverlo e per dimostrare di averlo seguito.
Se non sai ancora se rientri tra i soggetti NIS, o quanto sei pronto, parti dall’autovalutazione gratuita: cinque minuti, anonima. Se vuoi vedere cosa si vede della tua azienda da fuori, c’è la scansione gratuita del dominio.
Fonti
- D.Lgs. 4 settembre 2024, n. 138, art. 24 e art. 42: Gazzetta Ufficiale
- Determinazione ACN 379907 del 19 dicembre 2025 e allegati: ACN, modalità e specifiche di base
- ACN, Linee guida NIS, Specifiche di base, Guida alla lettura: PDF
- ACN, FAQ su misure di sicurezza e notifica degli incidenti: FAQ
- ACN, Vademecum NIS (settembre 2026): notizia
Questo articolo spiega le norme in termini pratici e non è un parere legale. Le date possono essere aggiornate dall’ACN: verifica sempre sul portale NIS.
Ready to automate your vulnerability management?
Deploy SentriKat on-premises in minutes. Track exploited vulnerabilities, generate NIS2 compliance reports, and protect your infrastructure.
Request a Demo