Ogni quanto fare un penetration test: cosa dicono le norme

Non esiste una frequenza unica valida per tutte le aziende. Le regole esplicite sono poche: il PCI DSS chiede un penetration test almeno ogni 12 mesi e dopo ogni modifica significativa, DORA test adeguati almeno annuali e, per le entità individuate, un TLPT almeno ogni tre anni, le misure ACN per i soggetti NIS2 essenziali test periodici e prima della messa in esercizio. Per tutti gli altri il riferimento ragionevole è un test l'anno sui sistemi esposti, più un test dopo ogni cambiamento rilevante.

Se ti serve prima il quadro generale, cos'è un pentest e come si svolge è nella guida al penetration test. Qui vediamo cosa dicono davvero le fonti sulla frequenza e come decidere quando nessuna norma la fissa per te. Chi è tenuto a farlo è spiegato in penetration test obbligatorio.

Cosa dicono davvero le fonti

Molte cadenze che circolano sono prassi di mercato, non obblighi. Le fonti che fissano un intervallo sono poche, e ognuna vale per un perimetro preciso.

PCI DSS: almeno ogni 12 mesi e dopo le modifiche significative

Il PCI DSS, lo standard del PCI Security Standards Council per chi conserva, elabora o trasmette dati delle carte di pagamento, è la fonte più esplicita. Nella formulazione dei requisiti riportata nel Self-Assessment Questionnaire D per gli esercenti (versione 4.0, aprile 2022):

• i penetration test interni (requisito 11.4.2) ed esterni (11.4.3) si eseguono almeno una volta ogni 12 mesi e dopo ogni aggiornamento o modifica significativa dell'infrastruttura o delle applicazioni, da una risorsa interna qualificata o da un terzo qualificato, con indipendenza organizzativa del tester;
• la metodologia di test (11.4.1) tiene conto delle minacce e delle vulnerabilità degli ultimi 12 mesi e conserva i risultati per almeno 12 mesi;
• le vulnerabilità sfruttabili trovate si correggono e il test si ripete per verificare le correzioni (11.4.4);
• se la segmentazione serve a ridurre il perimetro, i controlli di segmentazione si testano almeno ogni 12 mesi e dopo ogni loro modifica (11.4.5);
• in parallelo, le scansioni delle vulnerabilità interne ed esterne si fanno almeno una volta ogni tre mesi (11.3.1 e 11.3.2).

La versione oggi in vigore è la 4.0.1, pubblicata nel giugno 2024: il Council ha spiegato che è una revisione limitata, senza requisiti aggiunti o eliminati, e che la 4.0 è stata ritirata il 31 dicembre 2024 (annuncio del PCI SSC).

DORA: test annuali e TLPT almeno triennale

Il Regolamento (UE) 2022/2554 (DORA) chiede alle entità finanziarie diverse dalle microimprese di eseguire, con cadenza almeno annuale, test adeguati su tutti i sistemi e le applicazioni di TIC a supporto di funzioni essenziali o importanti (art. 24, par. 6). Il regolamento non dice che il test annuale debba essere per forza un penetration test: l'art. 25, par. 1, elenca i test possibili, dalla scansione delle vulnerabilità all'esame del codice sorgente, e il test di penetrazione è uno di questi. La scelta segue un approccio basato sul rischio (art. 24, par. 3).

Due regole particolari. I depositari centrali di titoli e le controparti centrali fanno valutazioni della vulnerabilità prima di ogni rilascio di applicazioni e componenti a supporto di funzioni essenziali o importanti (art. 25, par. 2). Le entità individuate dalle autorità competenti svolgono invece un test di penetrazione guidato dalla minaccia (TLPT) con cadenza almeno triennale, sui sistemi di produzione, e l'autorità può chiedere di ridurre o aumentare la frequenza in base al profilo di rischio (art. 26, par. 1 e 2). Come funziona il TLPT è spiegato nell'articolo sui test di resilienza DORA e TLPT.

NIS2 e misure ACN: dipende dalla categoria

La Direttiva (UE) 2022/2555 (NIS2) non nomina il penetration test. L'art. 21, par. 2, chiede tra le misure minime la gestione e la divulgazione delle vulnerabilità (lettera e) e strategie e procedure per valutare l'efficacia delle misure di gestione dei rischi (lettera f). In Italia il dettaglio sta nelle misure di sicurezza di base della determinazione ACN 379907/2025, e qui le due categorie si separano:

• Soggetti essenziali (allegato 2, misura ID.RA-01, punto 2): per almeno i sistemi informativi e di rete rilevanti si eseguono periodicamente, e comunque prima della messa in esercizio, attività di identificazione delle vulnerabilità che comprendono almeno vulnerability assessment e/o penetration test, salvo motivate e documentate ragioni normative o tecniche. Il punto 3 chiede di documentarle con relazioni che descrivono attività, esiti, vulnerabilità trovate e impatto.
• Soggetti importanti (allegato 1): la stessa misura ID.RA-01 chiede di identificare le vulnerabilità usando le informazioni raccolte dai canali del CSIRT Italia e dei CERT di settore, ma non contiene il requisito dei test periodici.

Nessuno dei due allegati fissa un numero di mesi. La cadenza la decide il soggetto nel piano di gestione delle vulnerabilità, che deve indicare come si identificano le vulnerabilità e come si pianificano le attività (misura ID.RA-08, punto 3). E la formula e/o lascia aperta la scelta tra vulnerability assessment e pentest: un pentest diventa necessario quando il rischio sui sistemi rilevanti lo giustifica, non per definizione. Chi è entrato nell'elenco nazionale NIS nel 2025 adotta queste misure entro 18 mesi dalla comunicazione di inserimento; per chi vi è entrato per la prima volta nel 2026, la determinazione ACN 127434/2026 fissa il termine al 31 luglio 2027.

Per alcuni fornitori digitali (cloud, data center, servizi gestiti, servizi di sicurezza gestiti e gli altri elencati all'art. 1) vale direttamente il Regolamento di esecuzione (UE) 2024/2690: al punto 6.5 dell'allegato chiede di stabilire necessità, portata, frequenza e tipo dei test di sicurezza sulla base della valutazione dei rischi, e il considerando 15 cita i test di penetrazione tra quelli utilizzabili.

ISO/IEC 27001: la frequenza la guarda l'auditor

La ISO/IEC 27001:2022 non fissa una cadenza per i 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, e di valutare anche la frequenza con cui li ripete. L'organismo verifica inoltre le registrazioni sulla qualifica di chi li esegue e sulle azioni prese. In pratica: se sei certificato, la cadenza dei test va scritta, motivata col rischio e dimostrata.

NIST SP 800-115: un riferimento, non un obbligo

Per chi non ha un obbligo specifico, un riferimento tecnico è il NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment). Indica che, per costo e impatto potenziale, un penetration test annuale della rete e dei sistemi può essere sufficiente, affiancato da scansioni di rete e di vulnerabilità regolari (§5.2.2). E aggiunge che, siccome una valutazione è una fotografia della sicurezza in un dato momento, un'organizzazione può scegliere di farne di più frequenti (§6.2).

Come decidere la frequenza se nessuna norma la fissa

Per un'azienda del mid-market che non tratta carte di pagamento, non è un'entità finanziaria e non è un soggetto NIS2 essenziale, la frequenza è una decisione di rischio. Il NIST indica i criteri con cui prenderla: classificazione dei sistemi, benefici attesi, obblighi applicabili, risorse disponibili (§6.2). In pratica, quattro domande.

1. Cosa è esposto e cosa contiene

Sistemi raggiungibili da Internet, applicazioni che trattano dati di clienti, accessi remoti e posta sono i primi candidati a un test almeno annuale. Un gestionale interno raggiungibile solo dalla rete aziendale può reggere una cadenza più lunga, se la valutazione del rischio lo motiva e la scelta è scritta.

2. Quanto spesso cambia

Un test descrive i sistemi com'erano il giorno del test. Per questo la regola più utile è legare il test ai cambiamenti, oltre che al calendario, come fa il PCI DSS. Sono cambiamenti che giustificano un test nuovo, per esempio:

• una nuova applicazione o un nuovo servizio esposto su Internet;
• una migrazione in cloud o un cambio di fornitore di hosting;
• modifiche ad autenticazione, single sign-on o gestione dei ruoli;
• nuove API o integrazioni con terze parti;
• modifiche alla segmentazione della rete;
• l'integrazione dei sistemi di una società acquisita.

Se l'applicazione cambia ogni due settimane, un test l'anno descrive una versione che non esiste più. In quel caso conviene un modello continuativo, come il penetration test as a service, invece di inseguire i rilasci con incarichi singoli.

3. Cosa ti chiedono clienti e contratti

Nel mid-market l'obbligo arriva spesso dalla filiera: un cliente soggetto a NIS2 o a DORA chiede l'esito di un test recente, o lo scrive nel contratto. In quel caso la cadenza la fissa di fatto il cliente più esigente.

4. Cosa fai tra un test e l'altro

La frequenza del pentest dipende anche da cosa c'è nel mezzo. Il NIST suggerisce di affiancare ai test periodici scansioni regolari, meno onerose (§5.2.2): un vulnerability assessment ripetuto copre le vulnerabilità note tra un pentest e l'altro, e il pentest resta per quello che una scansione non vede, come le catene di vulnerabilità e gli errori di autorizzazione.

Un calendario di partenza

Questa è la nostra proposta per un'azienda senza obblighi specifici, da adattare alla valutazione del rischio. Non è una cadenza prevista da una norma:

1. Perimetro esterno e applicazioni esposte: un penetration test almeno una volta l'anno.
2. Dopo ogni cambiamento significativo: un test mirato sul pezzo cambiato, prima della messa in esercizio quando possibile.
3. Rete interna: un test a cadenza definita dalla valutazione del rischio, scritta nel piano dei test e riesaminata ogni anno.
4. Scansioni delle vulnerabilità: almeno trimestrali, la stessa cadenza che il PCI DSS chiede a chi tratta dati di carte, e più frequenti sui sistemi esposti.
5. Retest: dopo ogni correzione delle vulnerabilità gravi, senza aspettare il ciclo successivo.

Per costruire il budget su questo calendario, i fattori che spostano il costo di ogni test sono in quanto costa un penetration test.

Errori frequenti sulla frequenza

• Ripetere ogni anno lo stesso perimetro. Se il test copre sempre gli stessi indirizzi, i sistemi nuovi restano fuori. Prima di ogni ciclo si riparte dall'inventario.
• Fare il test e non il retest. PCI DSS (11.4.4) e DORA (art. 24, par. 5) chiedono di verificare che le correzioni funzionino: un test senza retest dimostra i problemi, non la loro chiusura.
• Non scrivere la scelta. Per ACN, per l'auditor ISO e per un cliente vale quello che è documentato: la cadenza, il motivo e gli esiti. Cosa deve contenere un buon esito è spiegato in penetration test report: cosa contiene e come leggerlo.

In sintesi

• Una frequenza unica per tutti non esiste: dipende dal regime a cui sei soggetto e da quanto cambiano i tuoi sistemi.
• PCI DSS: penetration test interni ed esterni almeno ogni 12 mesi e dopo ogni modifica significativa.
• DORA: test adeguati almeno annuali sui sistemi a supporto di funzioni essenziali o importanti, TLPT almeno triennale per le entità individuate.
• NIS2 in Italia: per i soggetti essenziali, vulnerability assessment e/o penetration test periodici e prima della messa in esercizio sui sistemi rilevanti, con cadenza fissata nel piano di gestione delle vulnerabilità.
• Senza obblighi specifici: un test l'anno sui sistemi esposti, un test dopo ogni cambiamento rilevante e scansioni regolari nel mezzo.

Se vuoi impostare un calendario di test sul tuo perimetro e sugli obblighi che ti riguardano, partiamo da lì: cybersecurity gestita e penetration test con AmagisTech.