Vulnerability assessment e penetration test sono obbligatori per legge?

La domanda arriva quasi sempre in questa forma: il penetration test è obbligatorio per legge?
La risposta breve è no.
Nessuna norma italiana o europea nomina il penetration test fra gli adempimenti e chi ve lo vende dicendo il contrario sta dicendo il falso.

La risposta complessa è però più interessante.
Diverse norme impongono alle aziende di valutare l’efficacia delle misure di sicurezza adottate, di farlo con regolarità e di poterlo dimostrare.
Come farlo è lasciato alla scelta dell’organizzazione, ma le opzioni tecniche sono poche e note.

Questo articolo mette in fila le norme che generano quell’obbligo, chi riguardano, che cosa chiedono esattamente e su chi ricade la responsabilità quando non vengono rispettate.

È scritto per chi deve decidere: titolari, responsabili IT, referenti privacy e organismi di vigilanza.

1. NIS2 e D.Lgs 138/2024: valutare l’efficacia
2. Chi rientra nella NIS2 e chi ci finisce di riflesso
3. GDPR: l’obbligo più esplicito
4. Legge 90/2024: il settore pubblico allargato
5. Perimetro di sicurezza nazionale
6. Chi risponde: amministratori, 231 e ODV
7. Il vincolo penale che riguarda chi verifica
8. Che cosa serve documentare

NIS2 e D.Lgs 138/2024: valutare l’efficacia

La direttiva europea 2022/2555, nota come NIS2, è stata recepita in Italia con il decreto legislativo 4 settembre 2024 numero 138, pubblicato nella Gazzetta Ufficiale numero 230 del 1 ottobre 2024 e in vigore dal 16 ottobre 2024.

Il riferimento che interessa sta nell’articolo 21 paragrafo 2 della direttiva, che elenca le misure minime di gestione del rischio. Alla lettera f compare questa formulazione:

Nel decreto italiano quel contenuto è all’articolo 24, che impone ai soggetti essenziali e importanti misure tecniche, operative e organizzative adeguate e proporzionate.

Due parole della norma meritano attenzione. Parla di strategie e procedure, non di singole attività: non basta una verifica una tantum, serve un processo che stabilisca come e quando si valuta. E parla di efficacia, non di presenza: non è sufficiente avere una misura, bisogna poter dire se funziona.

Un vulnerability assessment e un penetration test sono due dei modi tecnicamente riconosciuti per farlo. La norma non li impone e non li nomina, ma è difficile immaginare come si possa valutare l’efficacia di una misura senza verificarla, e l’abbiamo approfondito parlando di vulnerability assessment e conformità NIS2.

Lo stesso articolo 21 contiene altre lettere che si collegano direttamente alle verifiche.

La lettera e riguarda la sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi, “compresa la gestione e la divulgazione delle vulnerabilità”. È il fondamento normativo del patch management e della divulgazione responsabile.

La lettera d, insieme al paragrafo 3, impone di tenere conto delle vulnerabilità specifiche di ogni fornitore e della qualità delle sue pratiche di sicurezza, comprese le procedure di sviluppo sicuro. È la base del vendor risk assessment.

La lettera j prevede l’uso di soluzioni di autenticazione a più fattori. E la lettera g riguarda igiene informatica e formazione, su cui torniamo più avanti perché il decreto la trasforma in un obbligo esplicito.

Infine il paragrafo 4, che chiude il cerchio: qualora un soggetto constati di non essere conforme, adotta “senza indebito ritardo” tutte le misure correttive. La verifica genera un obbligo di intervento, non lo esaurisce.

Chi rientra nella NIS2 e chi ci finisce di riflesso

Il decreto distingue fra soggetti essenziali e soggetti importanti, individuati per settore e dimensione secondo gli allegati I, II, III e IV.

I settori coperti sono molto più ampi rispetto alla precedente direttiva. L’allegato I comprende energia, trasporti, settore bancario, infrastrutture dei mercati finanziari, sanità, acqua potabile, acque reflue, infrastrutture digitali, gestione dei servizi TIC, pubblica amministrazione e spazio. L’allegato II aggiunge servizi postali, gestione dei rifiuti, chimica, produzione e distribuzione alimentare, manifattura di dispositivi medici, elettronica, macchinari e veicoli, fornitori di servizi digitali e ricerca. I criteri di appartenenza li abbiamo dettagliati nell’articolo su chi è tenuto a conformarsi alla NIS2.

Due cose vanno dette a chi si chiede se è incluso.

La prima è che gli obblighi sono proporzionati e graduali.
L’articolo 31 del decreto stabilisce che l’Agenzia per la cybersicurezza nazionale, in qualità di Autorità nazionale competente NIS, fissa termini e modalità tenendo conto della dimensione del soggetto, del grado di esposizione al rischio e del livello di maturità iniziale. Una media impresa manifatturiera non ha gli stessi tempi di un operatore energetico.

La seconda riguarda i fornitori, ed è quella che sorprende di più. Anche un’azienda non direttamente soggetta può trovarsi obbligata di fatto, perché i suoi clienti soggetti devono valutare le pratiche di sicurezza della propria catena di fornitura. È il meccanismo che sta portando molte imprese a ricevere questionari di sicurezza dai committenti, e la risposta a quei questionari richiede evidenze che solo una verifica documentata può fornire.

GDPR: l’obbligo più esplicito

Il riferimento normativo più chiaro in materia di verifiche non viene dalla NIS2 ma dal Regolamento europeo 2016/679 sulla protezione dei dati, ed esiste dal 2018.

Qui la parola testare c’è, ed è la formulazione più diretta di tutto il panorama normativo. Riguarda titolare e responsabile del trattamento, cioè chiunque tratti dati personali, indipendentemente dal settore e dalla dimensione. In pratica ogni azienda.

L’avverbio che conta è regolarmente. La norma non chiede una verifica, chiede una procedura ripetuta nel tempo. Un test fatto una volta tre anni fa non soddisfa quel requisito, e in caso di violazione dei dati è la prima cosa che l’autorità di controllo chiede di vedere. Le implicazioni per le aziende le abbiamo aggiornate nell’articolo su cosa cambia nel GDPR nel 2026.

C’è un aspetto pratico che collega GDPR e NIS2. Il GDPR chiede di testare; la NIS2 chiede strategie e procedure per valutare. Chi imposta un programma di verifiche periodiche con un criterio dichiarato risponde a entrambe con un solo processo.

Legge 90/2024: il settore pubblico allargato

La legge 28 giugno 2024 numero 90, “Disposizioni in materia di rafforzamento della cybersicurezza nazionale e di reati informatici”, ha introdotto obblighi specifici per una platea di soggetti pubblici e parapubblici che spesso non si considerano interessati.

L’articolo 1 riguarda amministrazioni centrali, regioni e province autonome, città metropolitane, comuni con popolazione superiore a 100.000 abitanti e comunque i capoluoghi di regione, società di trasporto pubblico urbano con bacino non inferiore a 100.000 abitanti, società di trasporto extraurbano nelle città metropolitane, aziende sanitarie locali e le rispettive società in house che forniscono servizi informatici, di trasporto, di gestione delle acque reflue o dei rifiuti.

Gli obblighi sono di notifica degli incidenti: segnalazione entro 24 ore dal momento in cui se ne viene a conoscenza, notifica completa entro 72 ore, tramite le procedure disponibili sul sito dell’ACN.

La sanzione per reiterata inosservanza nell’arco di cinque anni va da 25.000 a 125.000 euro. E la violazione può costituire causa di responsabilità disciplinare e amministrativo-contabile per funzionari e dirigenti responsabili: la sanzione non colpisce solo l’ente.

Per chi opera in sanità questo si somma agli obblighi NIS2, che includono il settore nell’allegato I. Un’azienda sanitaria o una società che le fornisce servizi informatici si trova quindi con due regimi sovrapposti, e la coerenza fra i due dipende dalla capacità di dimostrare di aver verificato i propri sistemi.

Perimetro di sicurezza nazionale

Chi rientra nel Perimetro di sicurezza nazionale cibernetica, istituito dal decreto-legge 21 settembre 2019 numero 105, ha obblighi più stringenti e sanzioni molto più alte.

Fra le misure previste dall’articolo 1 comma 3 lettera b compaiono esplicitamente, al numero 6, il monitoraggio, test e controllo, insieme alla gestione del rischio, alla protezione fisica e logica dei dati, alla continuità del servizio e alla formazione.

Le sanzioni amministrative per l’inosservanza delle misure di sicurezza vanno da 250.000 a 1.500.000 euro, e arrivano a 1.800.000 per alcune violazioni relative alle forniture.

Riguarda però un numero ristretto di soggetti, individuati con atto amministrativo non pubblicato, a cui viene data comunicazione individuale. Se non avete ricevuto quella comunicazione, non siete nel Perimetro.

Va segnalata una regola di coordinamento: l’articolo 33 del decreto NIS2 stabilisce che gli obblighi del Perimetro sono equivalenti a quelli NIS2, quindi chi è già conforme al primo non deve adempiere due volte.

Chi risponde: amministratori, 231 e ODV

Le norme viste finora dicono cosa fare. Questa sezione dice chi ne risponde, ed è la parte che dovrebbe interessare di più chi siede in un consiglio di amministrazione o in un organismo di vigilanza.

L’articolo 23 del decreto 138/2024 attribuisce agli organi di amministrazione e direttivi dei soggetti essenziali e importanti tre obblighi diretti. Devono approvare le modalità di implementazione delle misure di gestione dei rischi. Devono sovrintendere alla loro attuazione. E sono ritenuti responsabili delle violazioni del decreto, con una responsabilità personale che non si delega al reparto IT.

Lo stesso articolo impone ai membri di quegli organi di seguire una formazione in materia di sicurezza informatica e di garantire una formazione periodica ai dipendenti. Non è un consiglio: è un obbligo con sanzione.

C’è poi il piano della responsabilità dell’ente. Il decreto legislativo 231/2001, all’articolo 24-bis, include i delitti informatici fra i reati presupposto della responsabilità amministrativa delle società. L’accesso abusivo a un sistema informatico, il danneggiamento di dati e sistemi, la detenzione di strumenti per l’accesso: se commessi nell’interesse o a vantaggio dell’ente, ne fanno rispondere anche l’ente.

Per un organismo di vigilanza questo significa che le verifiche di sicurezza non sono solo una misura tecnica ma un elemento del modello organizzativo. Un modello 231 che non preveda controlli periodici sull’infrastruttura, e non ne conservi le evidenze, ha una lacuna proprio sull’area di rischio che le norme recenti hanno reso più pesante.

Il vincolo penale che riguarda chi verifica

C’è un aspetto che riguarda tutti, anche chi commissiona la verifica, e che quasi nessuno considera prima di firmare un incarico.

L’articolo 615-ter del codice penale punisce con la reclusione fino a tre anni chi abusivamente si introduce in un sistema informatico protetto da misure di sicurezza, “ovvero vi si mantiene contro la volontà espressa o tacita di chi ha il diritto di escluderlo”. Due parole pesano: si mantiene, perché il reato non è solo entrare ma anche restare oltre l’autorizzazione e tacita, perché non serve un divieto scritto.

La legge 90/2024 ha inasprito le pene quando i sistemi riguardano interesse militare, ordine pubblico, sicurezza pubblica, sanità, protezione civile o comunque interesse pubblico: reclusione da tre a dieci anni, e da quattro a dodici nei casi aggravati. Sanità è nominata espressamente.

Per un’attività di verifica questo ha una conseguenza pratica: la stessa operazione tecnica è lecita con un mandato scritto e illecita senza. Il perimetro, i tempi, le esclusioni e le regole d’ingaggio vanno definiti prima di cominciare, e l’abbiamo descritto nel dettaglio parlando di chi autorizza un test e cosa si scrive nel perimetro. Su ambienti sanitari o di interesse pubblico l’aggravante rende quel documento ancora più necessario.

La stessa legge ha introdotto un articolo che va nella direzione opposta, ed è utile conoscerlo. L’articolo 623-quater prevede che le pene per questi delitti siano diminuite quando il fatto è di lieve entità, e ridotte dalla metà a due terzi per chi si adopera per evitare conseguenze ulteriori. È il riconoscimento normativo di una condotta precisa: chi scopre un problema per caso e si ferma, invece di approfondire, sta in una posizione molto diversa da chi va avanti.

Va infine ricordato l’articolo 615-quater, che punisce chi fornisce “indicazioni o istruzioni idonee” all’accesso a un sistema protetto. È la ragione per cui i contenuti tecnici di sicurezza, compresi quelli di questo sito, non contengono sequenze operative di attacco.

Che cosa serve documentare

Tutte le norme viste hanno una cosa in comune: chiedono di documentare, non solo di fare.
E il documento che soddisfa questa esigenza è meno ovvio di quanto sembri.

Non basta l’elenco delle vulnerabilità trovate. Quello che un’autorità di controllo, un cliente o un organismo di vigilanza si aspetta di trovare è:

• la data dell’attività e il perimetro esatto verificato, con l’indicazione di cosa è rimasto fuori e perché
• il criterio con cui sono state assegnate le priorità, distinguendo la gravità teorica dalla sfruttabilità nel contesto specifico
• le azioni correttive indicate per ciascuna vulnerabilità e, dove la correzione non è possibile, le misure di contenimento adottate nel frattempo
• che cosa è stato fatto dopo: una vulnerabilità segnalata e mai corretta, con la segnalazione agli atti, è una posizione peggiore di una mai cercata
• la verifica successiva che conferma l’avvenuta correzione, perché senza quella il ciclo resta aperto

L’ultimo punto è quello che si trascura di più. La NIS2 parla di procedure, il GDPR di regolarità: un report isolato, senza il successivo e senza traccia degli interventi intermedi, non descrive un processo. Descrive un episodio.

Vale la pena aggiungere una considerazione sulla catena di prova. Il report di una verifica è utile anche fuori dal contesto normativo: è il documento che un assicuratore chiede prima di riconoscere un sinistro, come abbiamo descritto parlando di cosa serve documentare perché la polizza paghi, ed è quello che un cliente soggetto a NIS2 chiede ai propri fornitori.

Una nota sul settore finanziario, che qui non abbiamo trattato: banche, assicurazioni e intermediari sono soggetti al regolamento europeo 2022/2554, noto come DORA, che agli articoli 24-27 disciplina i test di resilienza operativa e introduce all’articolo 26, per le entità identificate dalle autorità, il threat-led penetration testing con cadenza almeno triennale. È un’attività specialistica che non eroghiamo.