VA/PT e NIS2: cosa impongono il D.Lgs. 138/2024 e le misure di sicurezza ACN

Non per nome. L'articolo 21 della direttiva (UE) 2022/2555 elenca dieci misure minime e nessuna è il «penetration test». Il termine compare solo nei considerando: una volta a proposito dei fornitori di servizi di sicurezza gestiti che offrono penetration test, un'altra come strumento che le stesse autorità possono usare.

La direttiva richiede invece risultati difficili da dimostrare senza test:

• Art. 21(2), lettera e): sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, compresa la gestione e la divulgazione delle vulnerabilità.
• Art. 21(2), lettera f): politiche e procedure per valutare l'efficacia delle misure di gestione dei rischi.
• Art. 21(1): misure adeguate e proporzionate al rischio, tenendo conto dello stato dell'arte, dell'esposizione del soggetto, delle sue dimensioni, della probabilità e della gravità degli incidenti.
• Art. 21(4): il soggetto che rileva di non essere conforme adotta senza indebito ritardo le misure correttive.

La formulazione esplicita arriva un livello più in basso. Il regolamento di esecuzione (UE) 2024/2690 traduce questi punti in requisiti di test e di gestione delle vulnerabilità per i fornitori di infrastrutture digitali e servizi ICT, e in Italia le misure di base ACN scrivono «vulnerability assessment e/o penetration test» tra i requisiti dei soggetti essenziali. Chi sostiene che la NIS2 imponga a tutti un penetration test annuale forza il testo; chi sostiene che i test siano facoltativi sottovaluta ciò che gli articoli 21 e 32 ti chiedono di dimostrare.

Gli articoli 32 e 33 danno alle autorità competenti il potere di testarti e di chiederti i risultati dei tuoi test. Per i soggetti essenziali (art. 32(2)) la vigilanza è ex ante: ispezioni in loco e a distanza, compresi controlli casuali, audit di sicurezza periodici e mirati svolti da un organismo indipendente o dall'autorità, audit ad hoc, scansioni di sicurezza basate su criteri di valutazione del rischio oggettivi e richieste di prove dell'attuazione delle politiche di sicurezza, come i risultati degli audit svolti da un auditor qualificato e le relative evidenze.

Per i soggetti importanti (art. 33) gli stessi strumenti, senza audit periodici, si usano ex post, quando l'autorità dispone di prove, indicazioni o informazioni di una possibile non conformità.

In Italia l'ACN applica la stessa distinzione. La FAQ MVE.3 sulla vigilanza chiarisce che le ispezioni sui soggetti essenziali, compresi i controlli casuali, possono essere disposte anche ex ante, mentre quelle sui soggetti importanti solo se l'ACN ha acquisito elementi che suggeriscono possibili violazioni (art. 36, comma 2, D.Lgs. 138/2024). Per un soggetto importante la richiesta dei registri dei test arriverà quindi con ogni probabilità dopo un incidente: il momento peggiore per scoprire che non esistono.

La Commissione ha adottato il regolamento di esecuzione (UE) 2024/2690 il 17 ottobre 2024 in base all'art. 21(5) della NIS2. È direttamente applicabile e riguarda un elenco preciso di soggetti pertinenti: fornitori di servizi DNS, gestori di registri dei nomi di dominio di primo livello, fornitori di servizi di cloud computing, di data center e di reti di distribuzione dei contenuti, fornitori di servizi gestiti e di servizi di sicurezza gestiti, mercati online, motori di ricerca online, piattaforme di social network e prestatori di servizi fiduciari. Per gli altri settori non è vincolante, ma resta la lettura più dettagliata dell'art. 21(2) pubblicata dall'UE.

I punti dell'allegato che contano per i test:

• 6.5 Test di sicurezza: una politica e procedure per i test di sicurezza; necessità, perimetro, frequenza e tipo dei test stabiliti in base alla valutazione del rischio; test eseguiti secondo una metodologia documentata, sui componenti individuati come rilevanti per un funzionamento sicuro; tipo, perimetro, data e risultati documentati, con la valutazione di criticità e le azioni di mitigazione per ogni finding; mitigazioni applicate per i finding critici; politica riesaminata a intervalli pianificati.
• 6.10 Gestione e divulgazione delle vulnerabilità: monitorare le informazioni sulle vulnerabilità da CSIRT, autorità e fornitori; eseguire, ove opportuno, scansioni di vulnerabilità e registrarne i risultati, a intervalli pianificati; trattare senza indebito ritardo le vulnerabilità critiche per l'operatività; rendere la gestione delle vulnerabilità coerente con change, patch, risk e incident management; definire una procedura di divulgazione in linea con la politica nazionale di divulgazione coordinata. Se una vulnerabilità non richiede correzione, il motivo va documentato e giustificato (6.10.3).
• 7 Valutazione dell'efficacia: una politica e procedure che stabiliscono cosa si misura, con quali metodi, quando, chi lo fa, e quando e da chi i risultati vengono valutati.
• 2.3 Riesame indipendente: l'approccio complessivo alla sicurezza è riesaminato in modo indipendente, da persone con competenze di audit estranee alla linea gerarchica dell'area esaminata, a intervalli pianificati e dopo incidenti o cambiamenti significativi.

Il considerando 15 indica i test a cui pensa: test automatici o manuali, penetration test, scansioni di vulnerabilità, test statici e dinamici di sicurezza applicativa, test di configurazione e audit, eseguiti all'avvio, dopo aggiornamenti o modifiche significative o dopo la manutenzione. È un elenco di opzioni, non un obbligo. Vale per tutto l'allegato una regola (art. 2(2)): quando un requisito si applica «ove opportuno» e decidi che per te non lo è, devi documentarne le ragioni in modo comprensibile.

L'articolo 24, comma 2, del D.Lgs. 138/2024 recepisce l'art. 21(2) quasi alla lettera: la lettera e) riguarda la gestione e la divulgazione delle vulnerabilità, la lettera f) le politiche e procedure per valutare l'efficacia delle misure. Il dettaglio lo fornisce l'ACN. La determinazione ACN 379907 del 19 dicembre 2025, che ha sostituito la determinazione 164179 del 14 aprile 2025 e si applica dal 15 gennaio 2026, fissa le misure di sicurezza di base in due allegati: Allegato 1 per i soggetti importanti, Allegato 2 per i soggetti essenziali. Le misure seguono i codici del Framework nazionale per la Cybersecurity e la Data Protection (edizione 2025) e ognuna ha requisiti numerati.

I requisiti su test e vulnerabilità, così come sono scritti nei due allegati:

• ID.RA-01, punto 1 (entrambi): le informazioni raccolte ai sensi della misura ID.RA-08 sono usate per identificare eventuali vulnerabilità sui sistemi informativi e di rete.
• ID.RA-01, punto 2 (solo essenziali): per almeno i sistemi informativi e di rete rilevanti, in accordo al piano di gestione delle vulnerabilità e fatte salve motivate e documentate ragioni normative o tecniche, sono eseguite periodicamente e comunque prima della messa in esercizio attività di identificazione delle vulnerabilità che comprendano almeno vulnerability assessment e/o penetration test.
• ID.RA-01, punto 3 (solo essenziali): queste attività sono documentate in relazioni che contengono almeno la descrizione generale delle attività e dei loro esiti e la descrizione delle vulnerabilità rilevate con il relativo livello di impatto sulla sicurezza.
• ID.RA-08 (entrambi): monitorare almeno i canali del CSIRT Italia e di eventuali CERT e ISAC settoriali; risolvere tempestivamente le vulnerabilità con aggiornamenti o mitigazioni, oppure accettare e documentare il rischio nel piano di trattamento; mantenere un piano di gestione delle vulnerabilità, approvato dagli organi di amministrazione e direttivi, che stabilisce come si identificano le vulnerabilità ai sensi di ID.RA-01 e come si pianificano queste attività. I soggetti essenziali monitorano anche i canali dei fornitori del software ritenuto critico.
• ID.IM-01, punti 3 e 4 (solo essenziali): un piano per la valutazione dell'efficacia delle misure di gestione del rischio, con l'indicazione delle misure da valutare e dei metodi, e relazioni periodiche agli organi di amministrazione e direttivi.
• PR.PS-02, punto 4 (solo essenziali): in accordo alla valutazione del rischio, l'aggiornamento del software critico è verificato in ambiente di test prima dell'impiego in esercizio.

Due dettagli cambiano la pianificazione. La clausola «per almeno i sistemi informativi e di rete rilevanti» consente di limitare il punto 2 di ID.RA-01 ai sistemi la cui compromissione avrebbe un impatto significativo sui servizi per cui sei nel perimetro (FAQ ACN MSB.7): l'elenco dei sistemi rilevanti deve quindi esistere prima. Inoltre il punto 2 di ID.RA-01 è tra i requisiti che, se non attuati per motivate e documentate ragioni normative o tecniche, vanno coperti da misure compensative descritte nel piano di trattamento dei rischi approvato dai vertici (ID.RA-06, punto 2, e tabella 2 dell'Allegato 2).

La determinazione 379907/2025 fissa due termini, entrambi calcolati dalla ricezione della comunicazione di inserimento nell'elenco dei soggetti NIS (art. 3):

• Misure di sicurezza di base (Allegati 1 e 2): 18 mesi. Per i soggetti inseriti nel 2025 le pagine NIS dell'ACN indicano ottobre 2026.
• Notifica degli incidenti significativi di base (Allegati 3 e 4): 9 mesi, che l'ACN colloca a gennaio 2026 per i soggetti inseriti nel 2025.

La determinazione ACN 127434/2026, applicabile dal 30 aprile 2026, fissa date precise per i soggetti inseriti per la prima volta nel corso del 2026: misure di sicurezza entro il 31 luglio 2027, obbligo di notifica dal 1° gennaio 2027. Per i soggetti inseriti nel 2025 che restano nell'elenco 2026 valgono i termini originari.

Soggetti essenziali e importanti hanno la stessa scadenza; cambia l'allegato da attuare. Per un soggetto essenziale inserito nel 2025 il primo ciclo periodico di VA/PT sui sistemi rilevanti, le relative relazioni e il piano di gestione delle vulnerabilità approvato dai vertici dovrebbero quindi essere già operativi, e da ora ogni nuovo sistema rilevante richiede il test prima della messa in esercizio.

Prima di dimensionare il budget dei test conviene separare il testo dal sentito dire.

Scritto nelle norme:

• Ogni soggetto NIS2: gestione e divulgazione delle vulnerabilità, politiche e procedure per valutare l'efficacia delle misure (art. 21(2), lettere e) e f)).
• Soggetti del regolamento 2024/2690: una politica di security testing con perimetro, frequenza e tipo stabiliti dalla valutazione del rischio; risultati documentati con criticità e mitigazione per ogni finding; scansioni di vulnerabilità a intervalli pianificati ove opportuno, con evidenza dei risultati; riesami indipendenti.
• Soggetti essenziali italiani: vulnerability assessment e/o penetration test almeno sui sistemi rilevanti, periodicamente e prima della messa in esercizio, documentati in relazioni; un piano di valutazione dell'efficacia.
• Soggetti importanti ed essenziali italiani: un piano di gestione delle vulnerabilità approvato dai vertici e risoluzione tempestiva, oppure accettazione documentata del rischio.

Non scritto in nessuno di questi testi:

• Un penetration test annuale come obbligo generale NIS2.
• Una frequenza fissa per scansioni o test: «periodicamente» e «a intervalli pianificati» indicano l'intervallo che stabilisci e motivi tu.
• L'obbligo di un tester esterno o certificato. Il regolamento 2024/2690 chiede competenze di audit e indipendenza per il riesame indipendente, non per ogni singolo test.
• Red teaming guidato dalla minaccia o TLPT: è uno strumento DORA per i soggetti finanziari designati; vedi il TLPT nel DORA.

Le parti basate sul rischio non sono più morbide. Quando una norma ti lascia scegliere la frequenza, l'ispettore verifica che la scelta sia scritta, discenda dalla valutazione del rischio e sia stata davvero applicata.

Il vulnerability assessment enumera le debolezze note su molti sistemi e le classifica. Il penetration test prova a sfruttarle, le concatena e mostra cosa un attaccante raggiunge davvero. Il testo ACN accetta l'uno o l'altro («e/o»): la scelta va quindi nel piano di gestione delle vulnerabilità, con le sue ragioni. Una struttura facile da difendere:

1. Parti dall'elenco dei sistemi rilevanti. Senza di esso non puoi usare il perimetro «almeno i sistemi rilevanti» e la copertura non è misurabile.
2. Vulnerability assessment su tutti i sistemi rilevanti, con l'intervallo stabilito dalla valutazione del rischio, dopo modifiche significative e quando i canali che monitori pubblicano vulnerabilità che riguardano il tuo stack.
3. Penetration test dove la domanda è la sfruttabilità: servizi esposti su internet, accesso remoto, infrastruttura di identità e sistemi che sostengono i servizi per cui sei nel perimetro. Testa dall'esterno e dall'interno con i privilegi di un utente standard; vedi black box e gray box.
4. Test prima della messa in esercizio per i nuovi sistemi rilevanti e i rilasci importanti, come chiede ai soggetti essenziali il punto 2 di ID.RA-01.
5. Retest dopo la correzione, così ogni finding si chiude con un'evidenza e non con lo stato di un ticket.

Se decidi che un sistema non può essere testato, per esempio un componente OT fragile, scrivi la ragione normativa o tecnica e le misure compensative nel piano di trattamento dei rischi: è la strada prevista dagli allegati ACN.

La FAQ ACN MSB.11 elenca i tipi di documenti a supporto dell'attuazione delle misure: elenchi, inventari, piani, politiche, procedure e registri, aggiornati e consultabili in formato cartaceo o digitale. Per test e gestione delle vulnerabilità il fascicolo di solito comprende:

• Il piano di gestione delle vulnerabilità (ID.RA-08, punto 3) con l'approvazione dei vertici, che mostra come si identificano le vulnerabilità e come si pianificano i test.
• L'elenco dei sistemi rilevanti e i criteri usati per definirlo.
• Le relazioni di VA/PT con almeno la descrizione delle attività, gli esiti e ogni vulnerabilità con il suo impatto sulla sicurezza (ID.RA-01, punto 3, per i soggetti essenziali).
• I registri dei test prima della messa in esercizio per i sistemi entrati in produzione dopo la scadenza.
• Il registro del monitoraggio dei canali CSIRT Italia, CERT e ISAC di settore e, per i soggetti essenziali, dei fornitori di software critico.
• I registri di correzione: vulnerabilità, decisione (correggere, mitigare o accettare), responsabile, date, esito del retest, e ogni accettazione del rischio nel piano di trattamento approvato.
• Per i soggetti essenziali, il piano di valutazione dell'efficacia e le relazioni periodiche agli organi di amministrazione e direttivi (ID.IM-01).
• Per i soggetti del regolamento 2024/2690: la politica di security testing, la metodologia documentata, criticità e mitigazione per ogni finding (punto 6.5.2).

Cosa succede quando mancano è trattato nel playbook sulle sanzioni dell'art. 38; il decreto nel suo insieme è spiegato nella guida al D.Lgs. 138/2024.

Un red team AI autonomo per reti e infrastrutture non decide la tua frequenza, non approva i tuoi piani e non è il riesame indipendente descritto dal regolamento 2024/2690. Cambia invece la quantità di evidenze di test disponibili tra una relazione e l'altra.

• VA e PT nella stessa campagna. Campagne black box dall'esterno e gray box con i privilegi di un utente standard, a calendario e dopo ogni modifica, trovano le vulnerabilità e provano a sfruttarle: ogni finding indica se è stato dimostrato sfruttabile nel tuo ambiente.
• Retest su richiesta. Ogni correzione si verifica con la stessa prova che ha trovato la falla, e il registro di correzione richiesto da ID.RA-08 si chiude.
• Mappatura sui framework. Il motore associa i finding ai controlli NIS2 dell'art. 21(2), lettere e) e f), tra i 34 framework supportati, ed esporta report di conformità. Non mappa sui codici delle misure ACN: il collegamento dei report a ID.RA-01, ID.RA-08 e ID.IM-01 resta nella tua documentazione.
• Approvazione umana dei passi rischiosi. Cinque livelli di autonomia stabiliscono cosa deve attendere una persona, dall'approvazione di qualsiasi scansione attiva al livello più basso fino all'assenza di soglie di approvazione al livello più alto, scelto in modo esplicito. I proof of concept di exploit possono restare in attesa della revisione dell'operatore. Vedi human in the loop.
• Registri che reggono. Ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256 per campagna, verificabile offline: il registro dei test mostrato all'ACN si può dimostrare inalterato.
• Nessun dato del cliente lascia l'appliance. I finding sui sistemi sfruttabili sono esattamente ciò che cerca un attaccante. I modelli girano sull'appliance, senza servizi AI esterni; in modalità air-gapped sono disattivati anche i download da fonti pubbliche. Vedi red team AI on-premise.

• Direttiva (UE) 2022/2555 (NIS2), artt. 21, 32 e 33 (EUR-Lex)
• Regolamento di esecuzione (UE) 2024/2690, allegato, punti 2.3, 6.5, 6.10 e 7 (EUR-Lex)
• D.Lgs. 4 settembre 2024, n. 138, art. 24 (Normattiva)
• ACN: modalità e specifiche di base, termini e allegati (acn.gov.it)
• Determinazione ACN 379907/2025, specifiche di base (PDF, acn.gov.it)
• Allegato 1, misure di sicurezza di base per i soggetti importanti (PDF, acn.gov.it)
• Allegato 2, misure di sicurezza di base per i soggetti essenziali (PDF, acn.gov.it)
• Determinazione ACN 127434/2026, termini per i soggetti inseriti nel 2026 (PDF, acn.gov.it)
• FAQ ACN: misure di sicurezza e notifica di incidenti (acn.gov.it)
• FAQ ACN: monitoraggio, vigilanza ed esecuzione (acn.gov.it)