Penetration test obbligatorio: per chi, con NIS2 e DORA

No, in Italia nessuna legge impone il penetration test a tutte le aziende. Lo nominano tre regole precise: le misure di sicurezza ACN per i soggetti NIS2 essenziali (misura ID.RA-01), il Regolamento DORA per le entità finanziarie, con il TLPT solo per quelle individuate dalle autorità, e il PCI DSS per chi tratta dati di carte di pagamento (requisito 11.4).

Per gli altri, dai soggetti NIS2 importanti a chi tratta dati personali, la norma chiede di verificare che le misure di sicurezza funzionino, ma non dice con quale test. Qui vediamo regime per regime cosa c'è scritto davvero, con il riferimento da controllare. Se ti serve prima il quadro generale, cos'è un pentest e come si svolge è nella guida al penetration test; ogni quanto farlo è nell'articolo sulla frequenza del penetration test.

La risposta breve, regime per regime

• NIS2, soggetti essenziali: vulnerability assessment e/o penetration test, periodicamente e prima della messa in esercizio, almeno sui sistemi rilevanti: il pentest da solo non è imposto.
• NIS2, soggetti importanti: no. Le misure ACN chiedono di identificare le vulnerabilità dalle informazioni del CSIRT Italia, non di testarle.
• DORA, entità finanziarie: per tutte tranne le microimprese, test adeguati almeno annuali sui sistemi a supporto di funzioni essenziali o importanti; il test di penetrazione è tra quelli elencati, non l'unico. Il TLPT è obbligatorio solo per le entità individuate dalle autorità competenti.
• PCI DSS: sì, penetration test interni ed esterni, per chi conserva, elabora o trasmette dati delle carte. È un obbligo contrattuale, non di legge.
• GDPR e ISO/IEC 27001: nessuno dei due nomina il pentest. Il GDPR chiede una procedura per testare l'efficacia delle misure, e per la ISO 27001 l'auditor verifica se fai test periodici in base al rischio.

NIS2 in Italia: cosa dicono davvero le misure ACN

La Direttiva (UE) 2022/2555 non impone il penetration test (lo cita solo nei considerando 86 e 87, come servizio di sicurezza), e non lo nomina nemmeno il D.Lgs. 138/2024 che la recepisce. L'art. 24, comma 2, del decreto chiede tra gli elementi minimi la gestione e la divulgazione delle vulnerabilità (lettera e) e politiche e procedure per valutare l'efficacia delle misure di gestione dei rischi (lettera f). Il dettaglio operativo sta nelle misure di sicurezza di base della determinazione ACN 379907/2025: l'allegato 1 vale per i soggetti importanti, l'allegato 2 per gli essenziali. Ed è qui che le due categorie si separano.

Soggetti essenziali: la misura ID.RA-01, punto 2

L'allegato 2 chiede che, per almeno i sistemi informativi e di rete rilevanti e in accordo al piano di gestione delle vulnerabilità, siano eseguite periodicamente e comunque prima della loro messa in esercizio "attività per l’identificazione delle vulnerabilità che comprendano almeno vulnerability assessment e/o penetration test", fatte salve motivate e documentate ragioni normative o tecniche. Tre dettagli contano:

• e/o: la misura accetta il vulnerability assessment da solo. Il pentest non è obbligatorio per definizione, lo diventa quando la valutazione del rischio sui sistemi rilevanti lo giustifica. La differenza tra i due è spiegata in penetration test e vulnerability assessment.
• Relazioni: il punto 3 chiede di documentare le attività con relazioni che contengano almeno la descrizione delle attività e degli esiti, delle vulnerabilità trovate e del loro livello di impatto sulla sicurezza.
• Deroga motivata, non libera: il punto 2 della ID.RA-01 è nella tabella 2 dell'allegato. Se per ragioni normative o tecniche non lo attui, la misura ID.RA-06, punto 2, chiede misure di mitigazione compensative, ove applicabili, descritte nel piano di trattamento dei rischi insieme al rischio residuo.

Sempre per i soli essenziali, la misura ID.IM-01, punto 3, chiede un piano per la valutazione dell'efficacia delle misure che indichi quali misure valutare e con quali metodi. Il pentest è uno dei metodi possibili, la misura non lo impone.

Soggetti importanti: nessun requisito di test

Nell'allegato 1 la misura ID.RA-01 ha solo il punto 1: le vulnerabilità si identificano usando le informazioni raccolte monitorando i canali del CSIRT Italia e dei CERT settoriali (misura ID.RA-08). Non c'è il requisito di vulnerability assessment o penetration test, e non c'è il piano di valutazione dell'efficacia della ID.IM-01, punto 3. Resta l'obbligo generale dell'art. 24, comma 2, lettera f), del decreto: come dimostri che le misure funzionano lo decidi tu, ma devi poterlo dimostrare.

Termini e controlli dell'ACN

Secondo la pagina ACN sulle specifiche di base, le misure si adottano entro 18 mesi dalla ricezione della comunicazione di inserimento nell'elenco nazionale NIS, e tra parentesi indica ottobre 2026: per i soggetti entrati nell'elenco nel 2025 il requisito è quindi già in vigore. Per chi vi è entrato per la prima volta nel 2026, la determinazione ACN 127434/2026 fissa il termine al 31 luglio 2027. Il quadro completo dei requisiti, misura per misura, è nell'articolo sulle misure di sicurezza NIS2.

C'è poi un canale diverso, che non è un obbligo di pentest ma gli somiglia nella pratica. L'ACN può chiedere ai soggetti di eseguire audit sulla sicurezza, periodici o mirati, e scansioni di sicurezza (art. 35, comma 3, lettere b e c, del D.Lgs. 138/2024). Audit e scansioni sono svolti da organismi indipendenti e i costi sono a carico del soggetto, salvo casi giustificati (art. 34, comma 7). Ai soggetti importanti l'ACN non può prescrivere audit di sicurezza periodici (art. 37, comma 3).

Fornitori di servizi digitali

Per cloud, data center, servizi gestiti, servizi di sicurezza gestiti e gli altri fornitori elencati all'art. 1 vale direttamente il Regolamento di esecuzione (UE) 2024/2690. Al punto 6.5 dell'allegato chiede una politica e procedure per i test di sicurezza, con necessità, portata, frequenza e tipo stabiliti dalla valutazione dei rischi, risultati documentati e azioni di mitigazione sulle risultanze critiche. Il considerando 15 cita i test di penetrazione tra i test possibili, accanto a scansioni delle vulnerabilità, test di configurazione e audit.

DORA: test annuali, TLPT solo per chi è individuato

Il Regolamento (UE) 2022/2554 (DORA) si applica dal 17 gennaio 2025 alle entità finanziarie, e il testing sta negli articoli da 24 a 27. Qui l'obbligo di testare c'è ed è esplicito, ma va letto su due livelli.

Il programma di test (art. 24 e 25)

• Le entità finanziarie diverse dalle microimprese mantengono un programma di test di resilienza operativa digitale, con un approccio basato sul rischio (art. 24, par. 1 e 3).
• Con cadenza almeno annuale eseguono test adeguati su tutti i sistemi e le applicazioni di TIC a supporto di funzioni essenziali o importanti (art. 24, par. 6).
• I test sono svolti da soggetti indipendenti, interni o esterni, e i problemi trovati si classificano, si correggono e si convalida la correzione (art. 24, par. 4 e 5).
• L'art. 25, par. 1, elenca i test possibili, dalla scansione delle vulnerabilità all'esame del codice sorgente fino ai test di penetrazione. DORA non dice che il test annuale debba essere un pentest: chiede che sia adeguato al sistema.
• Depositari centrali di titoli e controparti centrali fanno valutazioni della vulnerabilità prima di ogni rilascio a supporto di funzioni essenziali o importanti (art. 25, par. 2). Le microimprese testano combinando approccio basato sul rischio e pianificazione strategica (art. 25, par. 3).

Il TLPT (art. 26 e 27)

Il test di penetrazione guidato dalla minaccia è obbligatorio, con cadenza almeno triennale, solo per le entità finanziarie identificate dalle autorità competenti (art. 26, par. 1). Le autorità le scelgono valutando l'impatto dei servizi sul settore finanziario, i possibili problemi di stabilità finanziaria e il profilo di rischio informatico e di maturità delle TIC (art. 26, par. 8). Sono escluse le microimprese e le entità del quadro semplificato per la gestione dei rischi informatici (art. 16, par. 1, primo comma). Chi esegue il TLPT deve rispettare i requisiti dell'art. 27: esperienza in analisi delle minacce, penetration test e red team, certificazione o codici di condotta, assicurazione di responsabilità professionale. Come si svolge è spiegato in test di resilienza DORA e TLPT.

PCI DSS: un obbligo contrattuale, requisito 11.4

Il PCI DSS è lo standard del PCI Security Standards Council per chi conserva, elabora o trasmette dati delle carte di pagamento. Non è una legge: i programmi di conformità li gestiscono i circuiti di pagamento e le banche acquirer, come indica lo stesso questionario di autovalutazione, ed è a loro che si consegna l'attestazione. Nella formulazione del Self-Assessment Questionnaire D per gli esercenti (versione 4.0), il requisito 11.4 chiede:

• una metodologia di penetration test definita e documentata (11.4.1);
• penetration test interni (11.4.2) ed esterni (11.4.3), eseguiti da una risorsa interna qualificata o da un terzo qualificato con indipendenza organizzativa, non necessariamente un QSA o un ASV;
• la correzione delle vulnerabilità sfruttabili trovate e la ripetizione del test (11.4.4);
• il test dei controlli di segmentazione, se la segmentazione serve a ridurre il perimetro (11.4.5).

La versione in vigore è la 4.0.1: il Council l'ha presentata come revisione limitata, senza requisiti aggiunti o eliminati (annuncio del PCI SSC).

Chi non ha un obbligo esplicito

GDPR: testare sì, il metodo no

L'art. 32, par. 1, lettera d), del Regolamento (UE) 2016/679 elenca tra le misure adeguate, se del caso, "una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento". Vale per titolare e responsabile del trattamento. Il regolamento non indica quale test usare: un pentest sulle applicazioni che trattano dati personali è un modo di dimostrarlo, non l'unico.

ISO/IEC 27001: lo guarda l'auditor

La ISO/IEC 27001:2022 non impone il penetration test. In Italia però ACCREDIA, con la circolare tecnica DC n. 22/2026 del 17 giugno 2026 (prot. DC2026SPM088), chiede agli organismi di certificazione di accertare, con riferimento ai punti 6.1.2, 8.2 e al controllo A.8.8, se l'organizzazione si sottopone periodicamente a vulnerability assessment e/o penetration test in base al livello di rischio. Non è un obbligo per l'azienda, ma è una domanda che in audit arriva.

Fornitori di soggetti NIS2 e DORA

Nel mid-market l'obbligo arriva spesso dalla filiera. Il D.Lgs. 138/2024 chiede ai soggetti NIS2 di tenere conto delle vulnerabilità specifiche di ogni diretto fornitore e della qualità delle sue pratiche di sicurezza (art. 24, comma 3), e DORA chiede alle entità finanziarie di garantire la partecipazione al TLPT dei fornitori terzi di servizi TIC che rientrano nel suo ambito (art. 26, par. 3). Per questo un cliente soggetto a una delle due norme può chiederti l'esito di un test recente o scriverlo nel contratto: in quel caso l'obbligo è contrattuale, e lo misura il cliente.

Come capire se riguarda te

1. Sei nell'elenco NIS e con quale categoria? Se sei essenziale, vulnerability assessment e/o penetration test sui sistemi rilevanti sono un requisito. Se sei importante, non lo sono, ma devi poter dimostrare che le misure funzionano.
2. Sei un'entità finanziaria soggetta a DORA? Se non sei una microimpresa, test annuali adeguati sui sistemi critici sì; il TLPT solo se l'autorità ti ha individuato.
3. Tratti dati di carte di pagamento? Il PCI DSS chiede i penetration test del requisito 11.4; quali requisiti devi validare dipende da come gestisci i pagamenti e da cosa ti chiede la tua banca acquirer.
4. Sei certificato ISO 27001 o lo stai diventando? Prepara le evidenze dei test e la scelta della frequenza motivata dal rischio.
5. Cosa chiedono i tuoi clienti? Rileggi i contratti con i clienti soggetti a NIS2 o DORA: è lì che spesso compare la richiesta.

Se nessuna delle cinque risposte è sì, il pentest non è un obbligo ma resta una decisione di rischio. Per mettere a budget il test, i fattori che ne spostano il costo sono in quanto costa un penetration test.

Cosa serve per dimostrarlo

In tutti i regimi conta quello che è documentato, non il test in sé. Le misure ACN chiedono relazioni con attività, esiti e vulnerabilità con il loro impatto (ID.RA-01, punto 3); DORA chiede di convalidare che le carenze siano state risolte (art. 24, par. 5); il PCI DSS chiede di ripetere il test dopo le correzioni (11.4.4). Cosa deve contenere un buon esito è spiegato in penetration test report: cosa contiene e come leggerlo.

Se vuoi capire quali di questi obblighi valgono per te e impostare i test di conseguenza, partiamo dal tuo perimetro: cybersecurity gestita e penetration test con AmagisTech.