Pentesting: come funziona, quando serve e dove fa la differenza

Pentesting come verifica concreta della sicurezza aziendale: un test mirato a valutare l’impatto di scenari di compromissione e l’efficacia dei controlli

Il pentesting serve a rispondere a una domanda molto concreta: se qualcuno provasse davvero a entrare, quanto riuscirebbe ad andare avanti? È questo il punto che spesso sfugge quando la sicurezza viene letta solo attraverso scanner, dashboard e checklist. Una vulnerabilità segnalata non è ancora un rischio compreso; diventa tale quando si capisce se è sfruttabile, in quali condizioni e con quali effetti.

Per questo il penetration testing resta uno degli strumenti più utili quando si vuole uscire dal piano teorico. Aiuta a capire cosa regge, cosa no, e soprattutto dove conviene intervenire prima che un problema tecnico si trasformi in un incidente. Nelle sezioni che seguono vedremo cosa distingue un pentest da altre attività di verifica, quando ha senso farlo, quali approcci esistono e perché continua a pesare anche nei percorsi di audit e conformità.

Cos’è il pentesting

In termini semplici, un pentest è una simulazione d’attacco autorizzata. Serve a verificare se un sistema, un’applicazione o una rete possano essere compromessi davvero, non solo se presentano debolezze note. La differenza rispetto a una scansione automatica sta tutta qui: non ci si ferma all’elenco dei problemi potenziali, si prova a capire se quei problemi aprono un accesso reale e quanto pesano nel contesto specifico.

È una distinzione meno banale di quanto sembri. Molte organizzazioni hanno visibilità sulle vulnerabilità, ma non sempre riescono a capire quali siano davvero pericolose, quali possano essere concatenate e quali restino, in pratica, poco rilevanti. Il pentest serve proprio a fare questa selezione, portando il discorso dal volume dei finding alla sostanza del rischio.

Vale anche la pena chiarire un punto terminologico: nel linguaggio comune, pentesting e penetration testing vengono spesso usati come sinonimi. In ambito professionale, però, il termine richiama un’attività strutturata, autorizzata e guidata da obiettivi precisi. Non significa semplicemente “provare qualche attacco”, ma verificare in modo controllato se un difetto sia sfruttabile, quale percorso di compromissione possa aprire e quali conseguenze concrete possa avere su dati, processi e continuità operativa.

Perché fare pentesting

Fare pentesting ha senso quando non basta sapere che esistono controlli, ma serve capire se funzionano davvero, anche attraverso sistemi di monitoraggio e difesa avanzati. È il passaggio dalla sicurezza dichiarata alla sicurezza messa alla prova. Firewall, segmentazione, MFA, monitoraggio e hardening possono essere presenti sulla carta e comunque lasciare scoperti punti deboli che emergono solo durante un test realistico.

Il valore pratico sta soprattutto nelle priorità che aiuta a chiarire. Un buon pentest non produce solo un elenco di vulnerabilità: mostra quali esposizioni sono davvero sfruttabili, dove i controlli stanno reggendo e quali problemi meritano attenzione immediata. Questo aiuta i team tecnici a intervenire meglio, e il management a spendere con più criterio.

Un altro aspetto spesso sottovalutato è il ritorno sull’investimento. Un buon programma di pentesting aiuta a evitare spese disperse su contromisure poco efficaci e orienta i budget verso remediation ad alto impatto. In pratica, riduce l’incertezza: mostra quali vulnerabilità rappresentano davvero un rischio di compromissione, quali controlli stanno funzionando e dove invece esistono gap che richiedono interventi immediati o revisione progettuale.

Perché non attuare il pentesting è un rischio

Il problema, quando il pentesting manca, non è solo quello che non si vede. È anche l’illusione che tutto stia andando bene solo perché non ci sono stati incidenti evidenti. In molti ambienti le vulnerabilità restano sfruttabili per mesi senza produrre segnali chiari, finché qualcuno non le intercetta e le usa davvero.

A quel punto il danno non resta confinato al piano tecnico. Possono entrare in gioco fermo operativo, perdita di dati, costi di risposta più alti, rilievi in audit e difficoltà a dimostrare di aver gestito il rischio in modo credibile. Nei contesti regolati, trascurare la verifica periodica dei sistemi è sempre più difficile da giustificare.

Le esposizioni più comuni che emergono quando il pentesting manca o viene eseguito in modo superficiale includono pannelli amministrativi accessibili dall’esterno, configurazioni cloud troppo permissive, account di servizio con privilegi eccessivi, API non adeguatamente protette, segmentazioni di rete aggirabili e processi di autenticazione che resistono ai controlli formali ma non a un attacco realistico. Sono debolezze che raramente vengono comprese fino in fondo senza una verifica pratica.

Tipi di pentest: black-box testing, grey-box e white-box

Le metodologie del pentest si distinguono soprattutto per il livello di conoscenza iniziale e di accesso fornito ai tester. La scelta tra black-box, grey-box e white-box non è solo metodologica: influenza profondità del test, tempi, costi, copertura e tipo di vulnerabilità che è più probabile individuare. Non esiste una modalità universalmente migliore; esiste piuttosto l’approccio più coerente con l’obiettivo del test, con la maturità dell’organizzazione e con il rischio da validare.

Black-box testing. Nel black-box testing il tester parte senza informazioni interne rilevanti: nessun accesso privilegiato, niente codice sorgente, documentazione minima o assente. L’obiettivo è simulare il comportamento di un attaccante esterno e verificare cosa sia effettivamente raggiungibile e sfruttabile dall’esterno. Questo approccio è molto utile per misurare l’esposizione reale del perimetro e la capacità di resistenza ai tentativi di intrusione più realistici. Il suo limite è la copertura: se il tempo è limitato o la superficie è ampia, alcune debolezze interne possono restare fuori dal test.

Grey-box testing. Nel grey-box testing il tester dispone di informazioni parziali, ad esempio credenziali a basso privilegio, diagrammi architetturali, documentazione applicativa o dettagli limitati sull’ambiente. È spesso l’approccio più utile in contesto aziendale perché combina realismo e profondità: riduce il tempo speso in ricognizione e lo sposta sull’analisi delle logiche autorizzative, dei flussi autenticati, dell’escalation dei privilegi e delle interazioni tra componenti. È particolarmente efficace per verificare i rischi che emergono dopo un primo accesso o in presenza di insider threat limitati.

White-box testing. Nel white-box testing il team di test riceve un livello elevato di conoscenza del sistema: codice sorgente, configurazioni, documentazione tecnica, flussi applicativi, dettagli infrastrutturali e, quando previsto, accessi amministrativi o ambienti dedicati. Questo consente di andare molto più in profondità, verificando vulnerabilità difficili da osservare dall’esterno, errori di autorizzazione, gestione insicura dei segreti, difetti crittografici, trust relationship improprie e combinazioni di debolezze interne. In cambio, richiede più coordinamento, più disponibilità di informazioni e un perimetro chiaramente definito.

In pratica, il black-box risponde bene alla domanda “cosa vede e cosa può fare un attaccante esterno?”, il grey-box alla domanda “cosa accade se qualcuno ottiene un accesso iniziale o dispone di informazioni limitate?”, il white-box alla domanda “quali debolezze strutturali esistono anche se non sono immediatamente visibili dall’esterno?”. Molte organizzazioni mature alternano o combinano questi approcci in base al tipo di asset da testare.

La scelta tra black-box, grey-box e white-box dovrebbe dipendere dall’obiettivo del test. Se si vuole simulare un aggressore esterno e misurare l’esposizione del perimetro, il black-box testing è spesso il punto di partenza più realistico. Se invece l’obiettivo è capire cosa possa accadere dopo una compromissione iniziale o verificare i rischi legati ad accessi autenticati e privilegi limitati, il grey-box offre un equilibrio molto efficace. Il white-box resta ideale quando serve massima profondità, per esempio su applicazioni business critical, API complesse, architetture cloud-native o sistemi soggetti a requisiti rigorosi di assurance.

Il processo e le fasi del pentesting

Un penetration test professionale non coincide con l’uso di qualche tool offensivo. È un processo strutturato, con regole di ingaggio, perimetro definito, obiettivi condivisi e criteri di reporting chiari. Le fasi possono variare in base alla metodologia adottata, ma seguono quasi sempre una logica ricorrente che consente di produrre risultati tecnicamente affidabili e utili per il business.

• Scoping e regole di ingaggio: definizione di asset, ambienti, finestre temporali, limiti operativi, esclusioni, obiettivi e contatti di escalation.
• Ricognizione e raccolta informazioni: identificazione della superficie di attacco, dei servizi esposti, delle tecnologie utilizzate e dei possibili punti di ingresso.
• Analisi e discovery delle vulnerabilità: combinazione di scansioni, ispezione manuale, enumerazione e verifica delle configurazioni per identificare debolezze tecniche e logiche.
• Sfruttamento controllato: prova pratica della reale sfruttabilità per validare l’impatto, senza eccedere i limiti concordati.
• Post-exploitation e validazione dell’impatto: verifica di escalation, movimento laterale, accesso a dati sensibili o compromissione di processi critici, quando previsto dal perimetro.
• Reporting e remediation guidance: redazione di un report con evidenze, livello di rischio, priorità, raccomandazioni tecniche e sintesi executive.
• Retesting: verifica successiva delle correzioni per confermare l’effettiva riduzione del rischio.

Tra le fasi più importanti, spesso meno visibili all’esterno, ci sono la definizione delle regole di ingaggio e la qualità del report finale. Le regole di ingaggio servono a evitare impatti non desiderati, chiarire cosa è consentito, stabilire finestre di test, nominare referenti e definire criteri di escalation nel caso emergano vulnerabilità critiche. Il report, invece, è il punto in cui il lavoro tecnico diventa azione concreta: deve descrivere il rischio con chiarezza, mostrare prove verificabili, spiegare l’impatto e suggerire remediation realistiche e prioritarie.

Pentest tools: strumenti utili e criteri di scelta

Quando si parla di strumenti conviene evitare un equivoco comune: non esiste il tool che “fa il pentest” da solo. Esistono categorie diverse di strumenti, utili in momenti diversi del lavoro. Alcuni aiutano nella ricognizione, altri nella verifica delle vulnerabilità, altri ancora nell’analisi del traffico o nella validazione pratica dei percorsi di attacco. La qualità del risultato, però, continua a dipendere molto da chi li usa e da come li inserisce nel contesto giusto.

Tra gli strumenti più citati e diffusi sul mercato si trovano soluzioni come Burp Suite e OWASP ZAP per il testing delle web application, Nmap per la ricognizione di rete, Metasploit per la validazione dell’exploitability, Wireshark per l’analisi del traffico, sqlmap per casi specifici legati alle injection, oltre a piattaforme di vulnerability assessment come Nessus, Qualys, OpenVAS o servizi PTaaS che combinano automazione, dashboard di remediation e supporto di analisti. Nel mondo enterprise stanno crescendo anche piattaforme che uniscono continuous scanning, attack surface management, integrazioni CI/CD e report orientati alla compliance. La scelta, quindi, non deve partire dal brand più noto, ma dallo scenario di utilizzo.

Per scegliere bene conviene guardare ad alcuni aspetti molto concreti: quali asset copre davvero, quanto riesce a spingersi oltre la semplice rilevazione, come si integra con i processi già in uso, quanto è affidabile il reporting e quanto rumore genera. Contano anche la scalabilità, la facilità di adozione e la capacità di trasformare i risultati in attività di remediation gestibili. In molti casi il punto non è avere più dati, ma avere dati che si riescono davvero a usare.

Per orientarsi tra i pentest tools conviene ragionare per categoria. Esistono strumenti di ricognizione ed enumerazione, strumenti per il web application testing, framework di exploitation e post-exploitation, piattaforme di vulnerability management, tool per l’analisi del traffico, soluzioni per Active Directory assessment e servizi PTaaS che uniscono testing continuo, dashboard e collaborazione tra team. Questa classificazione è utile perché una rete aziendale moderna difficilmente può essere valutata con un solo strumento: servono tool diversi per coprire perimetro esterno, rete interna, identità, applicazioni, API e ambienti cloud.

Oltre agli aspetti tecnici, nella scelta dei tool contano anche criteri organizzativi. È importante verificare il modello di licensing, la facilità di adozione, il supporto del vendor, la curva di apprendimento per il team interno, la possibilità di delegare alcune analisi a fornitori esterni e la capacità dello strumento di inserirsi in un processo già esistente. In molte aziende il problema non è acquistare un buon tool, ma far sì che venga usato con continuità, governato correttamente e tradotto in remediation efficaci.

VA vs PT: differenze, complementarità e quando usarli

Vulnerability Assessment e Penetration Test vengono spesso messi nello stesso contenitore, ma non fanno la stessa cosa. Il primo serve a trovare e classificare esposizioni note su larga scala; il secondo serve a capire se quelle esposizioni si traducono davvero in un percorso di compromissione. Detto in modo diretto: il VA dà ampiezza, il PT dà conferma e profondità.

Quando usare l’uno o l’altro? Il vulnerability assessment è ideale per ottenere copertura ampia e frequente, specialmente in ambienti vasti o soggetti a cambiamenti continui. È utile per igiene di sicurezza, discovery delle esposizioni, gestione delle patch e monitoraggio ricorrente. Il penetration test è più adatto quando serve validare il rischio su asset critici, verificare l’efficacia dei controlli, supportare un audit, testare una nuova applicazione, una rete segmentata, un ambiente cloud o una trasformazione infrastrutturale. Nella pratica più efficace, VA e PT non si escludono: si completano.

Un esempio pratico aiuta a capire la complementarità tra VA e PT. Un vulnerability assessment può rilevare decine o centinaia di vulnerabilità distribuite su host, servizi e applicazioni, offrendo una vista ampia e continua dell’esposizione. Il penetration test interviene poi sui sistemi o sulle vulnerabilità più critiche per capire se quelle esposizioni siano davvero sfruttabili, se possano essere concatenate e se consentano accesso a dati sensibili, privilegi elevati o movimento laterale. Il VA fornisce ampiezza; il PT fornisce profondità e priorità reale.

I limiti degli strumenti automatici

Gli strumenti automatici restano indispensabili, ma hanno un limite chiaro: funzionano molto bene quando il problema assomiglia a qualcosa che sanno già riconoscere. Quando invece servono contesto, interpretazione o ragionamento su più passaggi, iniziano a perdere precisione.

È qui che spesso sfuggono i casi più interessanti: abusi di workflow, problemi di autorizzazione, concatenazioni di debolezze modeste prese singolarmente ma rilevanti insieme, scenari che si manifestano solo dopo autenticazione o in presenza di condizioni particolari. Per questo l’automazione aiuta molto, ma da sola non basta a sostituire un’analisi fatta bene.

Quando si valutano gli strumenti automatici, bisogna considerare sia i falsi positivi sia i falsi negativi. I primi generano lavoro inutile e riducono fiducia nei risultati; i secondi sono ancora più pericolosi perché trasmettono una falsa sensazione di sicurezza. Un perimetro può sembrare “pulito” non perché sia davvero robusto, ma perché il tool non ha avuto il contesto necessario, non ha potuto autenticarsi, non ha compreso una logica applicativa o non ha riconosciuto una catena di attacco multi-step.

Come valutare l’efficacia di un vulnerability assessment tool

L’efficacia di un vulnerability assessment tool non si misura solo dal numero di vulnerabilità che trova. Un buon criterio è la precisione: quanti finding sono realmente utili e quanti sono falsi positivi o duplicati. Conta poi la copertura del perimetro, la tempestività degli aggiornamenti rispetto a nuove CVE e configurazioni insicure, la capacità di autenticarsi correttamente per test più profondi, la qualità della prioritizzazione basata sul rischio e la facilità con cui i risultati possono essere trasformati in azioni di remediation.

Dal punto di vista pratico, conviene verificare se lo strumento supporta ambienti ibridi, asset temporanei, API, sistemi autenticati, cloud e workload moderni; se integra contesto come criticità dell’asset, esposizione Internet e disponibilità di exploit; se offre workflow chiari per assegnazione, tracking e retesting; e se consente di produrre report leggibili sia per i tecnici sia per auditor e management. Un tool eccellente non è quello che mostra più dati, ma quello che aiuta a ridurre il rischio in modo misurabile e sostenibile.

Per una valutazione più matura, può essere utile definire anche alcune metriche: tempo medio di individuazione delle nuove vulnerabilità, percentuale di asset coperti, rapporto tra finding confermati e falsi positivi, qualità della prioritizzazione rispetto al rischio reale, tempo necessario per trasformare i risultati in ticket operativi e capacità di verificare automaticamente la chiusura di una remediation. Queste metriche aiutano a capire se il tool sta generando valore o solo volume di dati.

Come usare il pentesting in una strategia di sicurezza

Il pentesting è davvero efficace quando non viene trattato come un evento isolato, ma come una componente di una strategia di sicurezza più ampia. Questo significa collegarlo alla gestione delle vulnerabilità, al patch management, al ciclo di vita del software, ai processi di change management, al monitoraggio e alla risposta agli incidenti. Un test di penetrazione ben fatto genera evidenze che aiutano a migliorare architetture, configurazioni, priorità di investimento e controlli compensativi.

Gli output concreti di un pentest non sono solo le vulnerabilità trovate. Sono anche mappe della superficie di attacco, dimostrazioni di percorsi di compromissione, evidenze di esposizione dei dati, raccomandazioni prioritarie, indicazioni su controlli inefficaci, suggerimenti di hardening e un riferimento chiaro per il retesting. Questi risultati hanno valore tecnico, perché migliorano le difese; operativo, perché supportano la pianificazione; e di compliance, perché aiutano a dimostrare che l’organizzazione non si limita a dichiarare controlli ma li verifica in modo sostanziale.

I benefici tecnici riguardano la riduzione della superficie di attacco e la validazione dei controlli. I benefici operativi riguardano una migliore allocazione delle risorse, una remediation più mirata e una maggiore collaborazione tra security, IT e sviluppo. I benefici di compliance riguardano invece la capacità di produrre evidenze, supportare audit, migliorare la readiness verso ispezioni e rispondere alle richieste di clienti, partner o organismi di certificazione con dati oggettivi e aggiornati.

Usato correttamente, il pentesting rafforza anche un approccio secure by design. I risultati di un test ben documentato possono essere tradotti in requisiti di sviluppo più robusti, standard di hardening, checklist di rilascio, controlli di configurazione e policy di accesso più rigorose. Questo passaggio è decisivo: l’obiettivo non è solo correggere il singolo finding, ma fare in modo che la stessa classe di problema si presenti meno spesso nei progetti futuri.

L’AI può sostituire un pentester?

L’AI può velocizzare parecchie attività legate al pentesting, e in alcuni casi lo fa già molto bene. Aiuta a ordinare i finding, suggerire test, collegare vulnerabilità tra loro, ripulire il rumore e accelerare la produzione dei report. Ma da qui a dire che possa sostituire un pentester ce ne passa.

Il motivo è che il lavoro non consiste solo nel lanciare test o interpretare output tecnici. Serve capire il contesto, fare ipotesi sensate, scegliere fin dove spingersi, leggere l’impatto sul business ed evitare effetti collaterali inutili. È un tipo di giudizio che oggi l’automazione può supportare, non rimpiazzare del tutto.

In prospettiva, l’AI potrà rendere più efficienti soprattutto le attività ripetitive e di supporto: analisi preliminare di superfici di attacco, suggerimento di test case, generazione di riepiloghi, correlazione di vulnerabilità e supporto alla remediation. Ma più aumenta l’automazione, più diventa importante la capacità di governance: decidere cosa testare, con quali limiti, quali risultati considerare affidabili, quando interrompere un’azione offensiva e come interpretare l’impatto sul business resta una responsabilità che non può essere delegata ciecamente a un modello.

Ogni quanto va eseguito un pentesting?

Non esiste una cadenza valida per tutti, ma esistono buone pratiche abbastanza condivise. In generale, un pentest dovrebbe essere eseguito almeno periodicamente sugli asset più critici e ogni volta che si verificano cambiamenti rilevanti: rilascio di nuove applicazioni o API, migrazioni cloud, redesign architetturali, acquisizioni, integrazione con terze parti, esposizione di nuovi servizi o modifiche importanti alla segmentazione di rete. In ambienti ad alto rischio o fortemente regolati, la frequenza tende ad aumentare e ad affiancarsi a vulnerability assessment ricorrenti.

Per definire la frequenza giusta conviene considerare criticità degli asset, esposizione Internet, sensibilità dei dati, volume dei cambiamenti, dipendenze dalla supply chain, requisiti contrattuali e aspettative normative. Un approccio maturo è basato sul rischio: più un sistema è critico, esposto o soggetto a cambiamenti rapidi, più dovrebbe essere testato e ritestato con regolarità.

Accanto alla periodicità programmata, esistono eventi che dovrebbero far scattare un nuovo test o almeno un retesting mirato: introduzione di nuove funzionalità esposte su Internet, fusioni e acquisizioni, cambio di provider cloud, modifiche ai sistemi di identity management, apertura di VPN o accessi remoti, nuovi collegamenti con terze parti, scoperta di vulnerabilità critiche su componenti chiave o esiti negativi di audit interni. In questi casi, attendere il ciclo annuale può lasciare scoperto un rischio già attuale.

NIS2, audit e certificazioni: come VA e PT aiutano la conformità

Le normative e gli standard non chiedono semplicemente di “avere strumenti di sicurezza”, ma di dimostrare che i rischi cyber vengono identificati, valutati, gestiti e verificati in modo continuativo. In questo quadro, vulnerability assessment e penetration testing sono attività particolarmente utili perché generano evidenze tecniche, misurano l’efficacia dei controlli e aiutano a costruire un processo di miglioramento continuo. Il punto importante è non confondere la conformità con la sicurezza: VA e PT non sono un timbro formale, ma una base concreta per dimostrare governance e capacità di gestione del rischio.

Direttiva NIS2: gestione del rischio, resilienza operativa e importanza delle evidenze tecniche

La NIS2 rafforza gli obblighi di gestione del rischio cyber, resilienza operativa, governance, incident reporting e sicurezza della supply chain per soggetti essenziali e importanti. Non impone una frequenza unica e universale di pentest, ma si inserisce in un impianto che richiede misure tecniche e organizzative adeguate, proporzionate e verificabili. In questo quadro, vulnerability assessment e penetration test rappresentano strumenti molto utili per identificare debolezze, validare i controlli e produrre evidenze coerenti con un approccio strutturato alla gestione del rischio.

Dal punto di vista degli audit, ciò che conta non è solo dichiarare di aver effettuato controlli, ma poter esibire evidenze coerenti: perimetro testato, metodologia, risultati, priorità di remediation, tempi di presa in carico, verifica delle correzioni e collegamento con il processo di gestione del rischio. In questo senso, VA e PT aiutano a rendere tangibile la conformità perché trasformano principi generali di resilienza e sicurezza in un insieme di attività documentate e verificabili.

ISO/IEC 27001: approccio risk-based e verifica tecnica dell’efficacia dei controlli di sicurezza

La ISO/IEC 27001 non prescrive un singolo tool o un unico test, ma richiede un sistema di gestione della sicurezza delle informazioni basato su risk assessment, trattamento del rischio, controlli adeguati e riesami periodici. In questo quadro, vulnerability assessment e penetration test sono strumenti estremamente efficaci per alimentare il processo di valutazione del rischio, verificare l’efficacia dei controlli implementati e produrre evidenze utili alla dichiarazione di applicabilità, agli audit interni e agli audit di certificazione. Sono particolarmente utili quando l’organizzazione deve dimostrare che i controlli non sono solo documentati, ma anche verificati sul piano tecnico.

Il punto chiave, in ottica ISO 27001, è la coerenza con il modello risk-based. Se il risk assessment evidenzia asset critici, sistemi Internet-facing, applicazioni che trattano dati sensibili o dipendenze tecnologiche ad alto impatto, allora penetration test e vulnerability assessment diventano controlli molto difficili da escludere in modo credibile. Non perché la norma li imponga in modo letterale in ogni scenario, ma perché rappresentano spesso la misura più efficace per dimostrare che il rischio tecnico viene realmente valutato e trattato.

PCI DSS: testing continuo e validazione della sicurezza negli ambienti che gestiscono dati di pagamento

PCI DSS è uno degli standard che più chiaramente valorizza testing e validazione tecnica. Per gli ambienti che trattano dati di pagamento, la conformità richiede attività regolari di vulnerability scanning e penetration testing con attenzione a segmentazione, esposizione, cambiamenti significativi e verifica dei controlli. Qui la distinzione tra VA e PT è particolarmente importante: lo scanning continuo aiuta a mantenere igiene e visibilità, mentre il pentest verifica se un attaccante potrebbe realmente raggiungere componenti del cardholder data environment o aggirare le difese predisposte.

Per chi opera in ambito PCI DSS, è particolarmente importante ricordare che il penetration testing deve essere almeno annuale e anche successivo a cambiamenti significativi, con attenzione specifica sia alla prospettiva esterna sia a quella interna. Inoltre, quando l’organizzazione usa la segmentazione per ridurre il perimetro del cardholder data environment, la segmentazione stessa deve essere verificata come parte del test. Questo rende il pentest non un allegato alla compliance, ma uno dei meccanismi con cui si dimostra che i confini di sicurezza reggono davvero.

DORA: resilienza digitale e test proporzionati per il settore finanziario europeo

Per il settore finanziario europeo, DORA spinge con forza verso test di resilienza digitale proporzionati al rischio, all’esposizione e alla criticità dei servizi. Anche quando non si ricade nei livelli più avanzati di threat-led testing, resta centrale la necessità di validare controlli, identificare vulnerabilità e dimostrare capacità di gestione strutturata del rischio ICT. In questo scenario, VA e PT sono strumenti operativi che supportano sia la robustezza tecnica sia la dimostrabilità della conformità, specialmente quando inseriti in un programma continuo e documentato.

È importante però distinguere tra il programma generale di digital operational resilience testing richiesto da DORA e le forme più avanzate di threat-led penetration testing previste per soggetti identificati dalle autorità competenti. Non tutte le entità avranno gli stessi obblighi, ma tutte devono poter dimostrare un approccio proporzionato, documentato e orientato alla verifica effettiva dei controlli ICT. In questo quadro, vulnerability assessment, test tecnici, tabletop exercise e penetration test tradizionali possono costituire il livello di base su cui innestare attività più avanzate quando richieste.

Cosa succede dopo: gestione delle vulnerabilità e miglioramento continuo

Il vero valore del pentesting emerge dopo il test. Una volta ricevuto il report, l’organizzazione dovrebbe classificare gli interventi per priorità, assegnare owner, definire tempi di remediation, verificare eventuali controlli compensativi e pianificare il retesting. In parallelo, i risultati dovrebbero alimentare il vulnerability management, aggiornare il risk register, rafforzare i controlli architetturali e contribuire a decisioni più informate su investimenti, processi e formazione. Solo così il penetration test smette di essere una fotografia istantanea e diventa parte di un percorso di miglioramento continuo.

La remediation, infatti, non dovrebbe essere trattata come una semplice lista di correzioni tecniche. In molti casi richiede revisione delle architetture, razionalizzazione dei privilegi, aggiornamento delle pipeline di rilascio, modifica dei processi di onboarding/offboarding, revisione dei controlli di monitoraggio e formazione dei team coinvolti. Quando il pentest viene inserito in questo ciclo, il suo valore cresce nel tempo: ogni assessment successivo non ripete semplicemente il precedente, ma misura se l’organizzazione sta diventando realmente più resiliente.

In fondo, il valore del pentesting sta qui: togliere un po’ di ambiguità dal discorso sulla sicurezza. Aiuta a distinguere ciò che è solo esposto da ciò che è davvero sfruttabile, mette ordine nelle priorità e costringe l’organizzazione a misurarsi con i punti deboli che contano. Da solo non basta, naturalmente. Funziona bene quando si inserisce in un lavoro più ampio fatto di vulnerability management, remediation, retesting e governo continuo del rischio.