Vulnerabilità e patch NIS2: piano, aggiornamenti, vulnerability assessment e pentest

Molti attacchi riusciti sfruttano vulnerabilità note da mesi, per cui l'aggiornamento esisteva già. La NIS2 mette tra gli elementi minimi delle misure la «sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, ivi comprese la gestione e la divulgazione delle vulnerabilità» (d.lgs. 138/2024, art. 24, c. 2, lett. e). L'ACN la traduce in un piano di gestione delle vulnerabilità approvato dai vertici, in regole precise sugli aggiornamenti e, per i soggetti essenziali, in vulnerability assessment o penetration test periodici.

In questa guida: cosa chiede ciascun requisito, quando VA e pentest sono obbligatori, come trattare il software che non si può aggiornare e quali prove tenere.

Cosa chiede l'ACN

I requisiti sono nella determinazione ACN 379907/2025 (allegato 1 per gli importanti, allegato 2 per gli essenziali):

Il piano di gestione delle vulnerabilità

Il centro di tutto è il piano previsto da ID.RA-08, punto 3. Deve contenere almeno:

1. come identificate le vulnerabilità dei vostri sistemi e come pianificate queste attività (lettera a);
2. come monitorate, ricevete, analizzate e gestite le informazioni sulle vulnerabilità che arrivano da fuori (lettera b);
3. procedure, ruoli e responsabilità per entrambe le cose (lettera c).

Il piano va approvato dall'organo di amministrazione (punto 4), che non può delegare questa approvazione (FAQ ACN ODA.8 e ODA.10). Come per gli altri documenti approvati, può restare a livello di indirizzo e rimandare a procedure operative, che si aggiornano senza tornare in consiglio (ODA.11 e ODA.12).

Le fonti da seguire sono indicate: almeno i canali del CSIRT Italia e quelli di eventuali CERT e centri di condivisione (ISAC) del vostro settore (punto 1). I soggetti essenziali seguono anche i canali dei produttori del software ritenuto critico (punto 5). In pratica: iscrivetevi agli avvisi del CSIRT Italia, decidete chi li legge e annotate per ogni avviso se tocca i vostri sistemi, usando l'inventario con le versioni del software. È proprio ciò che chiede ID.RA-01, punto 1.

Le vulnerabilità vanno poi risolte prontamente, con gli aggiornamenti o con misure di mitigazione, oppure accettando e documentando il rischio nel piano di trattamento (ID.RA-08, punto 2). Non c'è una terza strada: una vulnerabilità nota, non corretta e non documentata è una non conformità.

Gli aggiornamenti di sicurezza

La misura PR.PS-02 dà due regole che valgono per tutti, salvo ragioni normative o tecniche motivate e documentate:

• solo software ancora supportato: va installato esclusivamente software, sistemi operativi compresi, per cui è garantita la disponibilità di aggiornamenti di sicurezza, in base alla valutazione del rischio (punto 1);
• aggiornamenti senza ingiustificato ritardo: gli ultimi aggiornamenti di sicurezza del produttore si installano senza ingiustificato ritardo, in coerenza con il piano di gestione delle vulnerabilità (punto 2).

Il testo non fissa giorni. Conviene che sia il piano a farlo, per gravità: per esempio tempi più stretti per le vulnerabilità critiche sfruttate attivamente sui sistemi esposti a Internet, più larghi per quelle basse sui sistemi interni. Sono numeri da decidere voi e da rispettare, con un report periodico che lo dimostri.

I soggetti essenziali, inoltre, verificano in un ambiente di test l'aggiornamento del software ritenuto critico prima di installarlo in produzione, in base alla valutazione del rischio (punti 4 e 5).

Il PC della macchina con un sistema operativo fuori supporto

È il caso tipico in fabbrica: il computer che governa una linea gira su un sistema non più aggiornato e il costruttore non ne certifica un altro. Qui entra la clausola «fatte salve motivate e documentate ragioni normative o tecniche»: scrivete il vincolo, adottate misure di mitigazione compensative, come isolare quel computer in una rete separata e limitare chi può collegarsi, e descrivetele nel piano di trattamento con il rischio residuo (ID.RA-06, punto 2; guida alla lettura ACN v2.1, par. 2.3.3). I requisiti di PR.PS-02 sono infatti tra quelli della tabella 2 in appendice agli allegati, per cui questa strada è prevista. Ne parliamo anche nella guida per le aziende manifatturiere.

Vulnerability assessment e penetration test: sono obbligatori?

Per i soggetti essenziali sì. Sui sistemi rilevanti, secondo il piano di gestione delle vulnerabilità e salvo ragioni motivate e documentate, vanno svolte periodicamente, e comunque prima della messa in esercizio, attività di ricerca delle vulnerabilità che comprendano almeno vulnerability assessment e/o penetration test (ID.RA-01, punto 2). Ogni attività va documentata con una relazione che descriva cosa è stato fatto, gli esiti e le vulnerabilità trovate con il loro livello di impatto (punto 3). Il testo non dice ogni quanto: una volta l'anno e a ogni cambiamento importante è una cadenza ragionevole.

Per i soggetti importanti VA e pentest non sono richiesti espressamente. Resta però l'obbligo di usare le informazioni sulle vulnerabilità per trovare quelle presenti nei vostri sistemi (ID.RA-01, punto 1) e di risolverle prontamente (ID.RA-08, punto 2): una scansione periodica delle vulnerabilità è il modo più semplice per dimostrarlo.

La differenza, in breve: il vulnerability assessment è una ricerca ampia, spesso con strumenti automatici, delle vulnerabilità note su un insieme di sistemi; il penetration test è una simulazione di attacco, fatta da specialisti, per capire fin dove si arriva sfruttandole. Il primo dice quante finestre sono aperte, il secondo se da una di queste si entra davvero.

Se qualcuno vi segnala una vulnerabilità

ID.RA-08 riguarda anche la ricezione delle «divulgazioni di vulnerabilità»: un ricercatore o un cliente può scrivervi di aver trovato un problema nel vostro sito o nel vostro prodotto. Serve un indirizzo noto a cui segnalarlo e qualcuno che risponda. Il CSIRT Italia fa da coordinatore per la divulgazione coordinata delle vulnerabilità e può fare da intermediario tra chi segnala e il produttore (art. 16); l'ACN ha adottato la politica nazionale di divulgazione coordinata prevista dall'art. 16, c. 4, nell'ottobre 2026.

Se sviluppate software, per voi o per i clienti, servono anche pratiche di sviluppo sicuro scritte (PR.PS-06): revisione del codice, gestione delle librerie di terze parti, test prima del rilascio.

Le prove da tenere pronte

• il piano di gestione delle vulnerabilità e la delibera che lo approva;
• il registro degli avvisi ricevuti (CSIRT Italia e altre fonti) con la valutazione fatta sui vostri sistemi;
• i report degli aggiornamenti installati, con i tempi rispetto a quelli del piano;
• l'elenco del software fuori supporto con le motivazioni e le misure compensative;
• per gli essenziali, le relazioni di VA o pentest e le verifiche prima della messa in esercizio, con le azioni correttive;
• le pratiche di sviluppo sicuro, se sviluppate software.

Gli errori più comuni

• Gli aggiornamenti automatici dei PC, e basta. Restano fuori firewall, VPN, NAS, server, stampanti e apparati di rete, che sono spesso i più esposti.
• Il pentest come certificato. Una relazione con decine di vulnerabilità e nessuna azione correttiva documenta un problema, non lo risolve.
• Il sistema fuori supporto senza una riga scritta. L'eccezione è ammessa solo se motivata, con misure compensative nel piano di trattamento.
• Gli avvisi del CSIRT che arrivano in una casella che nessuno legge.
• Il piano non approvato. Il piano di gestione delle vulnerabilità è tra i documenti che l'organo di amministrazione deve approvare.

Entro quando

Piano, aggiornamenti e, per gli essenziali, VA e pentest seguono il termine di tutte le misure di sicurezza di base. Per gli essenziali c'è anche un momento fisso: la verifica prima della messa in esercizio di ogni nuovo sistema rilevante.

• Entrati nell'elenco NIS nel 2025: 18 mesi dalla comunicazione di inserimento (det. ACN 379907/2025, art. 3), cioè entro il 12-13 ottobre 2026 per chi ha ricevuto la PEC il 12-13 aprile 2025. Il termine è passato: se scoprite che qualcosa manca, il decreto chiede di correggere «senza indebito ritardo» (art. 24, c. 4).
• Entrati per la prima volta nel 2026: entro il 31 luglio 2027 (det. ACN 127434/2026).
• Entrati dal 2027: l'ACN non ha ancora fissato il termine.

Lo stesso termine vale per le approvazioni dell'organo di amministrazione (art. 23). Tutte le date sono in scadenze 2026-2027. Dal 18 settembre 2026 l'ACN ha avviato la consultazione sulle misure «rafforzate», che integreranno e sostituiranno quelle di base: al 13 novembre 2026 non sono state adottate, e finché non lo saranno valgono i requisiti di questa pagina.

Da dove partire

1. Completate l'inventario del software con versioni e date di fine supporto.
2. Iscrivetevi agli avvisi del CSIRT Italia e decidete chi li valuta.
3. Scrivete il piano con fonti, tempi per gravità, ruoli ed eccezioni, e fatelo approvare.
4. Fate una prima scansione dei sistemi rilevanti e di quelli esposti a Internet, e documentate cosa correggete.

Se non sapete ancora se siete soggetti NIS, partite dalla verifica gratuita; per una fotografia di tutte le misure c'è l'autovalutazione, e tra i modelli gratuiti la checklist delle misure ACN. Nella sesta tappa di Pilot le misure si affrontano una per una con chi le fa e le prove, e lo scadenzario ha le voci per piano delle vulnerabilità, report degli aggiornamenti e relazioni di VA o pentest, che il fornitore può caricare dal suo link: provatelo gratis. Se volete impostare il piano con un ingegnere, c'è la consulenza NIS2 dello Studio.

Domande frequenti