2026-07-21 · GUIDA · Il team di Offensive Technology

Ogni quanto bisognerebbe effettuare un penetration test?

Risposta breve: almeno una volta ogni 12 mesi, e di nuovo dopo qualsiasi modifica significativa ai sistemi nel perimetro. Questa regola in due parti, calendario più modifiche, è la base minima pratica in tutti i framework con cui un acquirente si confronta. Solo PCI DSS la definisce come un requisito vincolante. SOC 2 e ISO 27001 non indicano affatto una frequenza; sono basati sul rischio, e la cadenza annuale è semplicemente diventata ciò che gli auditor si aspettano. Se il tuo ambiente rilascia codice ogni settimana o gestisce dati ad alto valore, una volta all'anno è un limite minimo da superare, non un obiettivo a cui puntare.

La domanda sorge perché "annuale" sembra una regola calata dall'alto da qualche autorità ufficiale. Per uno standard lo è. Per gli altri è una convenzione nata attorno a un linguaggio basato sul rischio, e sapere qual è la differenza ti evita di acquistare più del necessario o di farti cogliere impreparato durante un audit. Ecco cosa dice effettivamente ciascuno.

La versione breve, per framework

Sono quattro i fattori che spingono la maggior parte degli acquirenti a richiedere un test: un circuito di carte di credito, un report SOC 2, un certificato ISO o un modulo assicurativo. Solo uno di questi prescrive una frequenza specifica.

La regola in due parti: calendario più modifiche

Ogni risposta credibile sulla frequenza consiste in realtà in due regole sovrapposte, e saltarne una lascia una vulnerabilità scoperta.

La componente legata al calendario esiste perché un penetration test è un'analisi puntuale riferita a un momento specifico. Descrive i sistemi nel perimetro, durante la finestra di test, rispetto alle tecniche previste dalle regole di ingaggio. Vengono scoperte nuove classi di vulnerabilità, vengono pubblicati nuovi exploit e il tuo team continua a rilasciare codice. Un test annuale azzera quell'orologio prima che il quadro d'insieme diventi troppo obsoleto.

La componente legata alle modifiche esiste perché il calendario non sa quando hai riscritto il flusso di autenticazione o esposto una nuova API. Un test di marzo non ti dice nulla sul servizio lanciato a giugno. Per questo motivo ogni framework serio affianca "almeno ogni 12 mesi" a "e dopo qualsiasi modifica significativa", ed è proprio questa la parte che gli acquirenti trascurano più spesso.

Cosa si intende per modifica significativa

PCI DSS lascia ogni organizzazione libera di definire e giustificare il concetto di "significativo", ma gli esempi del settore sono coerenti. Considera ognuno di questi elementi come un trigger per testare il perimetro impattato, indipendentemente da quando è stato eseguito l'ultimo test annuale:

• Una release applicativa principale o il rifacimento di un componente rilevante per la sicurezza.
• Un nuovo servizio esposto su Internet, un sottodominio o un'API che amplia la superficie raggiungibile da un attaccante.
• Una migrazione in cloud, o una modifica sostanziale all'architettura cloud o all'IAM.
• Una modifica all'autenticazione, al single sign-on o alla gestione delle sessioni.
• Una modifica alla segmentazione di rete, alle regole del firewall o alla modalità di isolamento degli ambienti.
• Un'acquisizione o un'integrazione con terze parti che ingloba la superficie di qualcun altro nella tua.

Il filo conduttore è l'esposizione. Se la modifica altera ciò che è raggiungibile dall'esterno, il modo in cui viene verificata l'identità o la posizione di un confine di fiducia, l'ultimo test non descrive più la realtà.

Cosa dice davvero ciascun framework

PCI DSS v4.0 è quello prescrittivo. Il Requisito 11.4 richiede penetration test interni ed esterni almeno una volta ogni 12 mesi e dopo qualsiasi aggiornamento o modifica significativa all'infrastruttura o alle applicazioni, seguendo una metodologia documentata basata su un approccio riconosciuto dal settore come NIST SP 800-115. Quando si utilizza la segmentazione per tenere i sistemi fuori dal cardholder data environment, tale segmentazione viene verificata almeno ogni 12 mesi per i merchant e almeno ogni 6 mesi per i service provider, con re-test dei rilievi a seguito della remediation. Questa è la risposta più chiara alla domanda "ogni quanto" fornita tra tutti i framework.

SOC 2 non specifica alcuna frequenza. I Trust Services Criteria dell'AICPA sono scritti sotto forma di obiettivi, non di scadenze, quindi non esiste una riga che richieda un test annuale. Nella pratica, gli auditor se ne aspettano uno con cadenza almeno annuale, pianificato per rientrare nella finestra di osservazione del Type 2. Abbiamo approfondito quali criteri richiedono i test nell'articolo il SOC 2 richiede un penetration test?

L'ISO/IEC 27001 è esplicitamente basato sul rischio. Richiede la gestione delle vulnerabilità tecniche e la verifica dei controlli, e lega la frequenza alla tua valutazione del rischio e al piano di trattamento, piuttosto che a un calendario fisso. Le organizzazioni certificate concordano sul test annuale come baseline difendibile, con asset a maggior rischio testati più di frequente. La frequenza spetta a te giustificarla, non è un dato fisso fornito dall'esterno.

La polizza cyber risk dipende dalla compagnia assicurativa. Alcune polizze chiedono se si eseguono test regolarmente e considerano "annualmente" come la risposta attesa; altre non lo chiedono affatto. La scelta più corretta è leggere il modulo specifico invece di fare illazioni, che è il tema di serve un pentest per l'assicurazione cyber?

Quando una volta all'anno non basta

L'annuale è una soglia minima, e alcuni ambienti la superano rapidamente. Esegui i test più spesso quando:

• Rilasci codice continuamente. Se l'ambiente di produzione cambia ogni settimana, un test annuale è obsoleto per undici mesi all'anno. I team in questa situazione passano a test per ogni release sui percorsi critici, oppure a un modello di test continuo, mantenendo il test annuale completo come punto di riferimento.
• Gestisci dati di alto valore. Pagamenti, dati sanitari e grandi volumi di dati personali aumentano il costo di un errore, il che giustifica test più frequenti sui sistemi che li lavorano.
• Hai appena avuto un campanello d'allarme. Dopo un incidente, un quasi-incidente o una vulnerabilità critica in un componente da cui dipendi, ri-testare l'area impattata costa meno che dare per scontato che la patch sia risolutiva.

Niente di tutto questo sostituisce il test annuale. Si aggiunge ad esso, perché un'attività completa e circoscritta svolta da professionisti senior ha una profondità diversa rispetto a un re-test mirato di una singola modifica.

L'errore: considerare la data come il deliverable

Il modo più comune per sbagliare la frequenza è trattare il pentest come un certificato con una data di scadenza, eseguirlo l'ultimo giorno utile e non modificare nulla di ciò che si è appreso. Un test commissionato solo per spuntare una casella tende ad avere un perimetro troppo ristretto per essere superato facilmente e ad essere troppo superficiale per rilevare la reale modalità di ingresso di un attaccante. La data sul report soddisfa l'auditor; non rende la tua struttura più difficile da violare.

Tra un test programmato e l'altro, la tua esposizione continua a cambiare, che tu la controlli o meno: un sottodominio dimenticato, un servizio che non avrebbe mai dovuto essere pubblico, una credenziale trapelata. Conoscere la propria superficie di attacco esterna in modo continuo è il complemento economico all'analisi approfondita periodica, e non si tratta dello stesso servizio di un pentest. Se stai ancora cercando di capire di quale servizio hai effettivamente bisogno, l'articolo check, scan o pentest completo? traccia i confini.

Ogni quanto bisognerebbe effettuare un penetration test? Risposte rapide

Ogni quanto bisognerebbe effettuare un penetration test?

Almeno una volta ogni 12 mesi, e di nuovo dopo qualsiasi modifica significativa ai sistemi nel perimetro. Questa regola in due parti è la soglia minima pratica per tutti gli standard a cui gli acquirenti prestano attenzione. Gli ambienti dinamici o ad alto valore dovrebbero effettuare test più frequenti, fino a test per ogni release o continui.

PCI DSS richiede un penetration test annuale?

Sì. Il Requisito 11.4 di PCI DSS v4.0 richiede penetration test interni ed esterni almeno una volta ogni 12 mesi e dopo qualsiasi modifica significativa all'infrastruttura o alle applicazioni. Dove la segmentazione isola il cardholder data environment, la segmentazione viene testata almeno ogni 12 mesi per i merchant e almeno ogni 6 mesi per i service provider.

Ogni quanto SOC 2 e ISO 27001 richiedono un pentest?

Nessuno dei due indica una frequenza fissa. Entrambi sono basati sul rischio: SOC 2 lascia le evidenze alla valutazione dell'auditor, e ISO 27001 lega i test alla valutazione del rischio. Nella pratica, la cadenza annuale è diventata lo standard atteso dagli auditor, pianificata per rientrare nella finestra di osservazione del SOC 2 Type 2.

Quando occorre effettuare i test al di fuori del ciclo annuale?

Dopo qualsiasi modifica significativa: una major release, un nuovo servizio o sottodominio esposto su Internet, una migrazione in cloud, una modifica all'autenticazione o all'SSO, una modifica alla rete o alla segmentazione, oppure un'acquisizione. L'ultimo test descriveva l'ambiente solo per com'era in quel determinato giorno.

Fonti

• PCI Security Standards Council, PCI DSS v4.0 Requisito 11.4 (metodologia di penetration testing, frequenza e test di segmentazione).
• AICPA Trust Services Criteria (SOC 2), definiti come obiettivi basati sul rischio senza una frequenza di test fissa.
• ISO/IEC 27001, gestione delle vulnerabilità tecniche e verifica dei controlli basata sul rischio.
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, citata come metodologia riconosciuta.

Letture correlate

• Il SOC 2 richiede un penetration test?
• Serve un pentest per l'assicurazione cyber?
• Quanto costa un penetration test?