Che cos’è un penetration test e quando serve a un’azienda

Scansione, audit e penetration test sono tre lavori diversi, con tre prezzi diversi. Quale risponde alla Sua domanda, e che cosa la normativa italiana chiede davvero.

Lei chiede un preventivo per la sicurezza del sito e ne riceve tre, che differiscono di dieci volte, e sul primo sta «scansione di sicurezza», sul secondo «audit di sicurezza», sul terzo «penetration test», ma in tutti e tre c’è la stessa parola «sicurezza», che non dice nulla di ciò che li distingue. Non sono un solo lavoro in tre gradini e non sono tre prezzi per la stessa cosa, ma tre incarichi diversi, che rispondono a tre domande diverse, quindi il primo passo non è confrontare i prezzi, ma capire a quale delle tre domande Lei vuole davvero una risposta.

Questo articolo risponde a due: che cos’è un penetration test e se serve proprio alla Sua azienda. La seconda è la più importante, perché per la maggior parte delle piccole e medie imprese italiane nessun atto normativo chiede un penetration test per nome, e un preventivo che tace questo Le vende il servizio giusto nel momento sbagliato.

Lo scriviamo vendendo un audit di sicurezza, e non c’è contraddizione, perché un audit in cui c’è spazio per una verifica manuale e il penetration test che chiede la normativa non sono lo stesso lavoro, ma l’azienda che compra il secondo quando le serviva il primo paga di più e scopre di meno.

Tre incarichi venduti con nomi simili

La terminologia di settore qui è sporca, ma sotto c’è un confine netto, che formula meglio di tutti un’autorità di standard: NIST SP 800-115 definisce il penetration test come una prova di sicurezza in cui i valutatori imitano attacchi reali per trovare vie intorno alle difese del sistema, e precisa che cerca combinazioni di vulnerabilità, non singoli reperti. La stessa pubblicazione descrive il vulnerability scanning come la tecnica con cui si identificano le risorse e le vulnerabilità note che vi corrispondono.

In pratica significa quattro incarichi distinti, che conviene nominare uno per uno. La scansione è automatica, e in essa uno strumento confronta il Suo sistema con una banca dati di vulnerabilità note e restituisce un elenco. Il vulnerability assessment è lo stesso elenco, che una persona ha verificato e ordinato, di solito senza sfruttare nessuna delle vulnerabilità trovate. Il penetration test è un lavoro guidato da una persona, in cui i punti deboli trovati vengono usati e collegati in catena, per capire fino a dove un aggressore arriva davvero. L’audit di conformità risponde a una domanda del tutto diversa: se il sistema soddisfa uno standard o una norma nominati.

Il confine tra i primi tre lo formula nel modo più chiaro lo standard delle carte di pagamento, e lo fa non con una definizione, ma con lo scopo: le linee guida del PCI Security Standards Council distinguono il penetration test dalla scansione in base all’obiettivo: la scansione identifica, ordina e segnala le vulnerabilità; il secondo cerca i modi per sfruttarle e aggirare le difese del sistema. Lo stesso Consiglio, nel proprio standard, aggiunge i due bordi: la scansione di per sé non è un penetration test, e una prova che si limita a tentare di sfruttare i reperti dello scanner non è sufficiente.

Perciò la domanda «se Le serve un penetration test» non è una domanda di budget, ma su che cosa vuole come risposta: se nel Suo sistema ci sono punti deboli noti, oppure se qualcuno con quelli può davvero fare qualcosa.

A che cosa risponde ciascuno, e che cosa non dice

La scansione risponde in fretta e a poco prezzo, e il suo punto debole è il contesto, perché lo strumento non sa quale delle cento righe segnate sta nel Suo modulo di pagamento e quale sta in un ambiente di prova che nessuno raggiunge da internet, e non sa neppure che due errori isolatamente innocui insieme danno accesso al database — perciò l’elenco è l’inizio del lavoro, non il risultato del lavoro.

Il penetration test risponde più lento e costa di più, e il suo valore sta proprio nella catena, perché chi lo esegue non cerca «se qui c’è una vulnerabilità», ma «che cosa ci posso fare» — se da un modulo pubblico si arriva ai privilegi di amministratore, se da un account cliente se ne vedono i dati di un altro, se da un ambiente di prova si raggiunge il database di produzione. La risposta a questa domanda è quella che un titolare capisce senza bisogno di traduzione.

L’audit di conformità non fa né l’una né l’altra cosa, perché verifica se il sistema soddisfa una norma, e il suo risultato è un giudizio di conformità, non un elenco di debolezze tecniche; proprio per questo un’azienda può superare un audit di conformità e nella stessa settimana subire una violazione, e non c’è alcuna contraddizione, perché i due documenti rispondono a due domande diverse.

Nessuno di questi incarichi sostituisce gli altri e nessuno è «migliore» degli altri, quindi l’unica domanda che ha senso è quale di essi, adesso, risponde a ciò che Lei deve davvero sapere.

La confusione sui nomi non è un problema soltanto italiano, e lo si vede confrontando i mercati: in Finlandia, in Svezia e in Norvegia il mercato vende due incarichi — la scansione e il penetration test — e la via di mezzo non ha un nome; la si considera un risultato della scansione, non un servizio a sé. In Germania è il contrario, perché là una sola parola tende a coprire tutti e tre gli incarichi, compreso quello stesso, e proprio per questo, nel confronto tra preventivi, il nome è l’orientamento più debole che ci sia, mentre l’unica domanda sicura resta se le vulnerabilità trovate verranno sfruttate.

Se la legge lo chiede proprio a Lei

Qui conviene essere precisi, perché è il punto in cui i preventivi esagerano più spesso: in Italia un penetration test nominato come tale non è dovuto a ogni azienda che ha un sito web.

Il decreto legislativo 4 settembre 2024, n. 138, entrato in vigore il 16 ottobre 2024 e che recepisce la direttiva (UE) 2022/2555, impone obblighi ai soggetti: una valutazione del proprio status, una persona di contatto, la gestione del rischio e la notifica degli incidenti. Il penetration test, nel decreto, non è nominato in nessun articolo.

A nominarlo è la determinazione dell’Agenzia per la Cybersicurezza Nazionale (ACN) n. 379907 del 19 dicembre 2025 sulle misure di sicurezza di base. La misura ID.RA-01 chiede, almeno per i sistemi informativi e di rete rilevanti, che siano eseguite periodicamente e comunque prima della loro messa in esercizio attività di identificazione delle vulnerabilità che comprendano almeno un vulnerability assessment e/o un penetration test — ma soltanto se Lei è un soggetto NIS, essenziale o importante. Lo stesso decreto, all’articolo 37, prevede che l’Autorità possa intimare l’esecuzione di audit sulla sicurezza o di scansioni di sicurezza anche in altri casi.

Sono due condizioni insieme, non una: un’azienda che non è soggetto NIS da questa misura non ricava alcun obbligo, e un soggetto il cui sistema non rientra tra quelli rilevanti neppure, quindi il primo passo non è chiedere un preventivo, ma una valutazione su se Lei è soggetto.

Come capire se è un soggetto NIS

Il decreto NIS non elenca le aziende per nome, ma descrive settori e dimensioni, e l’obbligo di valutare il proprio status è dell’azienda stessa, il che in pratica significa due domande: se l’attività rientra in uno dei settori indicati dal decreto, e se le dimensioni raggiungono la soglia prevista. Alle due deve rispondere Lei, e la risposta va documentata — proprio per questo la prima spesa in questo campo è di solito una consulenza legale, non un servizio tecnico.

Se la risposta è «no», i punti successivi sui sistemi rilevanti non La riguardano affatto, e se la risposta è «sì», viene la seconda domanda: se il sistema concreto rientra tra i sistemi informativi e di rete rilevanti. L’obbligo di vulnerability assessment e/o penetration test è legato a quei sistemi, non allo status di soggetto in quanto tale, e un’azienda può essere soggetto NIS senza che a nessuno dei suoi sistemi si applichi questo requisito.

C’è anche una terza via, distinta dall’obbligo periodico della misura ID.RA-01: l’Autorità può intimare, in un caso particolare, un audit sulla sicurezza o una scansione di sicurezza. Non è un obbligo che si pianifica, ma è un motivo per sapere chi, da Lei, risponderebbe a una richiesta del genere.

Le altre soglie nominano le prove, non il penetration test

L’articolo 32 del GDPR chiede di testare, verificare e valutare con regolarità l’efficacia delle misure di sicurezza, e l’ampiezza dell’obbligo è legata al rischio. Non è la stessa cosa di un dovere di ordinare ogni anno un penetration test, e un preventivo che presenta l’articolo 32 come tale riformula il Regolamento più liberamente di quanto sia scritto. L’obbligo di dimostrare che le verifiche avvengono è reale; l’obbligo di scegliere proprio questo tipo di prova dall’articolo 32 non deriva.

Lo standard delle carte di pagamento PCI DSS, al requisito 11.4, nomina il penetration test per nome, una volta ogni dodici mesi e dopo modifiche sostanziali, ma è un obbligo contrattuale e riguarda il modo in cui Lei accetta le carte. Un negozio online che dirotta i pagamenti interamente a un prestatore di servizi di pagamento e non tratta esso stesso i dati delle carte, e gli altri, nel cui ambiente quei dati arrivano, rispondono a questo requisito in modo diverso. È una domanda a cui risponde la Sua banca acquirer, non un articolo.

Nel settore finanziario il regolamento (UE) 2022/2554 chiede prove regolari, e i test di penetrazione guidati dalla minaccia (TLPT) li prevede soltanto per gli enti che l’autorità di vigilanza ha indicato in modo specifico. Lo standard ISO/IEC 27001 chiede la gestione delle vulnerabilità e le prove di sicurezza, senza nominare il penetration test; l’affermazione che senza di esso la certificazione non si rilascia è diffusa e nello standard non si trova.

Se nessuna di queste soglie La riguarda, allora un obbligo normativo di ordinare un penetration test non ce l’ha, e ciò non significa che non ci sia nulla da fare, ma che il da farsi è un altro.

Se nessuna soglia è superata

Per un’azienda che non è soggetto NIS, non tratta i dati delle carte e non opera nel settore finanziario, il lavoro più sensato è di solito quello che avviene con regolarità, non un esercizio una tantum a distanza di anni. Sono gli aggiornamenti, che hanno un responsabile e una scadenza; i backup, che qualcuno ha già ripristinato una volta e si è accertato che si ripristinano davvero; l’autenticazione a più fattori (MFA) per gli account amministratore, che le misure di base dell’ACN nominano a parte per i soggetti NIS e che per gli altri è altrettanto utile; e una scansione regolare, i cui risultati qualcuno li legge davvero.

Questa non è una risposta minore, ma un altro tipo di lavoro. La maggior parte delle compromissioni con cui lavoriamo non comincia con un attacco raffinato, ma con un componente non aggiornato o con una password che andava bene anche altrove, e un penetration test che arriva una volta ogni tre anni da questo non protegge. Se il Suo sito ha già subito un danno, l’ordine è un altro e lo descrive un articolo a parte su come ripristinare un sito hackerato.

Il penetration test diventa giustificato quando c’è qualcosa da perdere, e quando la misura della perdita è più grande del prezzo dell’incarico: un sistema in cui stanno i dati di altre persone, un’integrazione che tocca il denaro, o un committente che chiede una prova. Fino a quel momento è il lavoro giusto nell’ordine sbagliato.

Che cosa accade durante la verifica

Il lavoro comincia con la definizione del perimetro e finisce con un report, e in mezzo ci sono tre fasi che conviene capire prima di confrontare i preventivi, perché sono proprio quelle a spiegare perché un incarico costa quanto costa, e perché un altro, sullo stesso sistema, costa dieci volte di meno.

La prima fase è la ricognizione, in cui il tester raccoglie tutto ciò che sul sistema si può sapere dall’esterno — quali indirizzi sono pubblici, quali tecnologie e versioni si vedono, dove stanno i moduli di accesso, quali file sono raggiungibili senza autorizzazione. In questa fase non si sfrutta ancora nulla, ma è proprio qui che più spesso si trovano reperti che nessuno si aspettava: un ambiente di prova dimenticato, un elenco delle directory lasciato aperto, un backup che sta a un indirizzo prevedibile.

La seconda fase è la verifica vera e propria, in cui si lanciano gli strumenti automatici per non saltare il noto, ma le decisioni le prende una persona, che controlla se il reperto è reale, tenta di sfruttarlo e guarda che cosa se ne ottiene. Qui nasce la catena — l’accesso a un account, da lì l’accesso a una funzione che non doveva essere raggiungibile, da quella l’accesso ai dati. Presi uno per uno, nessuno dei passi è drammatico; insieme sono una storia.

La terza fase è la dimostrazione e la documentazione, perché a ogni reperto deve restare una prova ripetibile: quale richiesta è stata inviata, quale è stata la risposta, che cosa è cambiato. Senza di essa il report è un’opinione, e lo sviluppatore che lo riceve passa una giornata a cercare di capire che cosa abbia visto il tester.

Perciò anche i tempi sono quelli che sono: la verifica di un sito piccolo è qualche giorno, ma un sistema con più ruoli, integrazioni e pagamenti è settimane, e un preventivo che promette un penetration test completo in un solo giorno descrive non una verifica, ma una scansione.

Perché i preventivi differiscono di dieci volte

Quando due preventivi sullo stesso sito differiscono di dieci volte, la differenza quasi mai sta nel margine, e quasi sempre sta nel perimetro e nel metodo: uno offre una scansione automatica con uno strumento che si lancia in un’ora e il cui report lo genera lo stesso strumento, l’altro offre una settimana di lavoro di una persona, in cui gli strumenti sono soltanto l’inizio, e proprio questa differenza è quella che il nome «verifica di sicurezza» nasconde in entrambi i casi.

Il secondo fattore di prezzo è la complessità del sistema, e la si può valutare prima che il colloquio cominci: un solo sito web pubblico, senza account utente, è un lavoro, ma un sistema con più ruoli, pagamenti, un’integrazione esterna e dati che appartengono ai clienti è tutt’altra cosa, perché ogni ruolo è un confine da verificare a parte e ogni integrazione è un punto in cui due sistemi si fidano l’uno dell’altro più di quanto dovrebbero.

Il terzo è che cosa riceve dopo, e per quanto il fornitore resta a disposizione: un report senza priorità, senza prove e senza una nuova verifica costa meno perché è un lavoro minore, e per l’azienda che poi deve correggere i reperti proprio queste tre cose decidono se il documento diventa un elenco di compiti o una cartella che nessuno riapre.

Perciò confrontare i preventivi sul prezzo è possibile soltanto quando il perimetro è scritto allo stesso modo, e il modo più semplice per ottenerlo è scrivere il perimetro da soli e chiedere a tutti di offrire su quello, invece di lasciare che ogni fornitore definisca il proprio.

Quando la verifica invecchia

Il risultato di un penetration test descrive un sistema concreto in una data concreta, il che è ovvio, e tuttavia è proprio qui che nasce la maggior parte dei malintesi tra fornitore e committente, perché un report vecchio di un anno descrive un codice che da allora è cambiato decine di volte.

I termini normativi lo riconoscono da sé: nelle misure ACN, accanto alla cadenza periodica, sta l’obbligo di eseguire le attività prima della messa in esercizio, e nello standard delle carte di pagamento, accanto all’intervallo annuale, sta «dopo modifiche sostanziali», così che in entrambi i casi il calendario è soltanto un minimo, e il vero motivo per testare è il cambiamento.

In pratica significa che un nuovo motivo per testare è un cambiamento che sposta il perimetro dell’attacco: una nuova funzione pubblica, una nuova integrazione con un sistema esterno, un cambio di autenticazione, il passaggio a un altro hosting, un nuovo ruolo utente con privilegi più ampi. Un cambio di colori o una correzione di testo non diventano un motivo del genere, per quanto visibili siano.

Il secondo motivo è che è cambiato l’intorno, non il Suo codice: una vulnerabilità nel framework che Lei usa viene scoperta dopo, e la verifica che non la menzionava non ha sbagliato, perché a quel momento non c’era ancora. Perciò la scansione regolare e il processo di aggiornamento sono ciò che avviene tra una prova e l’altra, e questa non li sostituisce.

Senza l’autorizzazione del proprietario le stesse azioni sono illecite

Un penetration test, sul piano tecnico, non si distingue da un attacco, e l’unica cosa che li distingue è un documento: l’autorizzazione del proprietario, in cui sono nominati perimetro, tempo e limiti, e che conviene mettere per iscritto anche quando la legge non lo chiede espressamente. Senza di essa le stesse azioni sono le stesse azioni, e questo ha conseguenze giuridiche.

In pratica significa che l’autorizzazione la dà chi possiede il sistema, non chi lo mantiene. Se il Suo sito gira su un servizio di hosting, anche il fornitore del servizio deve sapere che la verifica avverrà, perché altrimenti i suoi sistemi di protezione lo fermeranno o Le bloccheranno l’account. Se nel sistema c’è un componente di terzi che Lei non controlla, quello non entra nel perimetro.

I limiti del perimetro vanno scritti prima, non dopo, e in quell’elenco stanno quali indirizzi sono nel perimetro e quali no, se si testa l’ambiente di produzione o una copia, che cosa succede se il lavoro interrompe il servizio, e chi da Lei è raggiungibile di notte; questa conversazione occupa un’ora e risolve la maggior parte delle controversie che altrimenti nascono a lavoro già avviato.

Che cosa il penetration test non è: red team, bug bounty e verifica di conformità

Accanto al penetration test esistono diversi incarichi che si tende a chiamare allo stesso modo, e le differenze tra essi non sono accademiche, ma pratiche — decidono che cosa ordina e che cosa riceve.

L’esercizio di red team non verifica il sistema, ma la difesa: se le Sue persone e i Suoi processi notano l’attacco e che cosa fanno. Il perimetro è più ampio, la durata più lunga, e una parte del valore sta proprio nel fatto che il lato che difende non sa che è in corso un’esercitazione. Per un’azienda che non ha nulla da notare, perché nessuno legge i log, questo lavoro è prematuro.

Il bug bounty è un modello, non una verifica: Lei pubblica delle regole e paga per i reperti chi li invia. Può trovare ciò che un solo tester non ha visto, ma non dà né una garanzia di perimetro, né una scadenza, né un report che si possa allegare a un bando.

I test di penetrazione guidati dalla minaccia (TLPT) sono un incarico a parte, regolato, nel settore finanziario, e sono definiti in un regolamento dell’Unione europea. Se la Sua azienda non è un ente finanziario indicato dall’autorità di vigilanza, questo termine nel Suo preventivo non ha posto.

Un altro confine che si tende a far cadere è quello tra «black box», «white box» e «grey box» — quanto il tester sa già del sistema all’inizio. È un’intesa di settore, non un requisito normativo, e ha un effetto diretto sul prezzo e su ciò che si troverà. Chi opera senza accesso imita uno sconosciuto; chi ha un account e la documentazione, nello stesso tempo, arriva più lontano. Nessuna delle varianti è la più giusta; la domanda è da che cosa ha paura.

Che cosa riceve e come leggerlo

Il risultato è un report, e il suo valore sta nelle priorità, non nel numero dei reperti, perché un report con cento righe in cui non è detto da quale cominciare è inutilizzabile esattamente quanto la stampa di uno scanner. Un buon report, per ogni reperto, dice che cosa un aggressore ci può fare, con quanta facilità, e che cosa cambiare in concreto.

La seconda cosa da chiedere è una verifica dopo le correzioni, perché un reperto che è stato corretto e un reperto che qualcuno pensa sia stato corretto differiscono l’uno dall’altro, e l’unico modo per accertarlo è controllare di nuovo. Noi lo facciamo entro trenta giorni dalle correzioni, e questo termine conviene chiederlo a qualunque fornitore.

La terza è che cosa farà del report il Suo sviluppatore. Un reperto descritto con un numero CVE e senza contesto, per lo sviluppatore, significa una ricerca; un reperto a cui sono allegati la richiesta concreta e il punto nel codice significa una correzione. Se lo sviluppo lo fa un’azienda e la verifica un’altra, questa differenza è quella che decide se le correzioni arriveranno in una settimana o in un trimestre.

La quarta è ciò che nel report non deve stare: l’affermazione che il sistema adesso è sicuro. La verifica mostra che cosa, in quel perimetro e in quella data, è riuscito. Non prova che non ci sia nient’altro, e il fornitore che lo promette Le vende una consolazione.

C’è un altro motivo per cui questo colloquio conviene cominciarlo prima di quanto sembri necessario: una verifica che avviene una settimana prima della messa in esercizio trova le stesse cose che avrebbe trovato tre mesi prima, ma per correggere i reperti non restano né il tempo né il budget, e in pratica finisce con un elenco che si accetta come rischio, non con le correzioni, perciò la misura che chiede di identificare le vulnerabilità prima della messa in esercizio è scritta proprio così, e la stessa logica vale anche per chi a quell’obbligo non è tenuto.

E l’ultima cosa che conviene dire esplicitamente: un penetration test non è la prova che il sistema è sicuro, ma la prova che, in una data concreta e in un perimetro concreto, una competenza nota non ha trovato una via oltre qualcosa di concreto, e perciò la parte più preziosa del report spesso non è l’elenco dei reperti, ma la descrizione di ciò che è stato tentato e non è riuscito, perché è proprio questa parte a dire al tester successivo, tra tre anni, dove non conviene ripartire da zero.

Che cosa preparare prima del colloquio

Perché un preventivo sia proprio confrontabile, il fornitore deve conoscere il perimetro, quindi prepari un elenco di indirizzi e sistemi che vi rientrano, indichi se si testa l’ambiente di produzione o una copia, dica che cosa nel sistema non si deve toccare, e nomini la persona che può autorizzare l’interruzione.

Ambiente di produzione o copia

Questa è la domanda che decide sia il prezzo sia il rischio, perché una verifica in produzione mostra ciò che è davvero raggiungibile, e proprio per questo può rompere qualcosa: saturare, riempire il database di record di prova, spedire ai clienti e-mail vere o restare impigliato in un sistema di protezione che blocca il tester e poi blocca anche una parte dei Suoi utenti.

Una verifica sulla copia è più sicura e insieme più incompleta, perché la copia di rado è identica: spesso mancano le integrazioni reali, il volume reale dei dati e la configurazione reale, e proprio nella configurazione sta spesso il problema. Se sceglie la copia, annoti in che cosa differisce dall’ambiente di produzione, perché questo elenco è anche l’elenco di ciò che non è stato verificato.

La via di mezzo che usiamo più spesso: le operazioni di lettura in produzione, quelle di scrittura e quelle potenzialmente distruttive sulla copia, con una finestra concordata in anticipo e una persona che può fermare. Non è un compromesso per il prezzo, ma un modo per ottenere le risposte di entrambe le varianti, senza interrompere il lavoro.

Serve anche l’elenco contrario, cioè ciò che non sta nel perimetro, perché i limiti accettati in silenzio sono quelli su cui poi si litiga. I servizi di terzi che Lei non mantiene non vi rientrano, e testarli senza l’autorizzazione di quelle parti è lo stesso problema della sezione precedente. Se il Suo sito usa una finestra di pagamento esterna, una chat esterna o un’analitica esterna, sono proprietà di altri, e un preventivo che promette di «verificarli anche» promette ciò che non si può.

Infine dica che cosa succederà dei reperti dopo: chi li correggerà, in quale termine, e se il fornitore dopo le correzioni controllerà di nuovo. Un incarico senza questo accordo finisce spesso con un documento che nessuno apre, ed è la versione più cara possibile: si è pagato per una conoscenza che non si usa.

Dica anche a che cosa cerca una risposta, perché «dobbiamo soddisfare un requisito» e «vogliamo sapere se qualcuno può arrivare ai dati dei clienti» sono due incarichi diversi, con due prezzi diversi, e il fornitore che non chiede quale dei due è il Suo offrirà quello che a lui conviene di più.

Se non è sicuro da che parte della soglia si trova, da lì conviene cominciare. L’audit automatizzato di solito risponde alla domanda sui punti deboli noti a meno costo e più in fretta di un lavoro manuale di un esperto, e il suo risultato dice anche se il penetration test è il passo successivo. Il colloquio sul perimetro conviene cominciarlo da una descrizione del processo, non da un elenco di tecnologie, perché il perimetro lo decide ciò che Lei perde se il sistema viene meno.