Penetration test report: cosa contiene e come leggerlo

Un penetration test report è il documento con cui chi ha condotto il test consegna i risultati: cosa è stato provato, cosa è stato sfruttato, con quale impatto e come si corregge. Un report fatto bene ha due livelli, una sintesi per la direzione e una parte tecnica per chi deve sistemare, più perimetro, limiti, piano di remediation e retest. Se manca uno di questi pezzi, il test è stato pagato per metà.

Qui trovi come è strutturato, come si legge quando ti arriva sulla scrivania, quali segnali indicano un report debole e cosa ci cerca un auditor NIS2, ISO/IEC 27001 o DORA. Per la definizione dell'attività c'è la guida al penetration test.

A cosa serve il report, e per chi è scritto

Il NIST, nella Technical Guide to Information Security Testing and Assessment (SP 800-115, settembre 2008, sezione 8.2), dice che a fine analisi va prodotto un report che identifichi le vulnerabilità di sistemi, rete e organizzazione insieme alle azioni di mitigazione raccomandate. Elenca anche gli usi: punto di riferimento per le azioni correttive, base per definire la mitigazione, metro per misurare i progressi nel tempo, ingresso per l'analisi dei rischi.

Lo stesso paragrafo aggiunge un punto che spiega la forma di quasi tutti i report seri: siccome un report ha più pubblici, possono servire più formati. Chi approva il budget della correzione non legge una catena di exploit, e chi deve applicare la patch non sa che farsene di una frase sul rischio reputazionale. Per questo due riferimenti pubblici molto diffusi, il Penetration Testing Execution Standard (PTES) e la Web Security Testing Guide di OWASP, dividono il documento in una parte esecutiva e una parte tecnica.

Come è fatto un penetration test report

La sintesi per la direzione

La guida OWASP la paragona a un elevator pitch: l'obiettivo del test e il bisogno di business che lo ha motivato, i risultati principali letti in termini di impatto sul business (per esempio conformità e reputazione) e le raccomandazioni strategiche, senza dettagli tecnici. Il PTES aggiunge due elementi utili: un giudizio complessivo sulla postura, e la distinzione fra problemi sistemici e problemi sintomatici. L'esempio del PTES rende l'idea: una patch mancante su una macchina è il sintomo, un processo di patch management che non funziona è il problema sistemico.

Una buona sintesi si legge in cinque minuti e lascia al consiglio di amministrazione una decisione chiara, non un elenco di sigle.

Perimetro, metodo e limiti

È la parte che si salta più spesso ed è quella che dice quanto vale il resto. OWASP indica nell'introduzione il controllo delle versioni del documento, il team con le sue competenze, il perimetro concordato, la finestra temporale e i limiti: aree escluse, funzionalità non operative, credenziali o accessi non forniti, tempo insufficiente. Il PTES chiede in più gli obiettivi, l'approccio e la scala di valutazione usata.

Se il perimetro dichiarato nel report è più stretto di quello del contratto, deve esserci scritto perché. Una sezione limiti vuota non indica un test perfetto: indica che nessuno ha annotato cosa non si è riusciti a provare.

Le singole vulnerabilità

Ogni finding, secondo la guida OWASP, dovrebbe riportare:

• un identificativo univoco, per riferirsi a quel punto in mail, ticket e retest;
• il titolo della vulnerabilità;
• la probabilità di sfruttamento, basata su facilità, esistenza di codice di exploit funzionante, livello di accesso richiesto e motivazione dell'attaccante;
• l'impatto sul sistema e il livello di rischio risultante, con la scala spiegata in appendice;
• la descrizione di cosa è, come si sfrutta e quale danno produce, con i dati sensibili mascherati;
• i passi di remediation e le risorse di approfondimento (CVE, guide, immagini).

La guida chiede che le descrizioni bastino all'ingegnere che legge per agire: se il tuo team deve richiamare il fornitore per capire come riprodurre un finding, il report non ha fatto il suo lavoro.

Le catene di attacco e l'impatto reale

Qui sta la differenza fra un penetration test e una scansione. Il PTES distingue la parte di vulnerability assessment, che individua le vulnerabilità potenziali, dalla parte di sfruttamento, che documenta i passi compiuti per confermarle, il livello di accesso ottenuto e il percorso di escalation. La sezione di post-exploitation lega poi lo sfruttamento al rischio per l'azienda: accesso ai sistemi centrali, ai dati soggetti a obblighi di conformità, possibilità di persistenza e di esfiltrazione, con schermate ed evidenze.

Cosa hanno visto i tuoi controlli

È la sezione che molti report non hanno e che per chi gestisce un SOC vale più delle altre. Il PTES prevede un capitolo sull'efficacia delle contromisure: firewall, WAF, IDS e IPS, DLP, log, persone, e le eventuali attività di risposta agli incidenti attivate durante il test. Secondo il PTES, elencare i controlli che hanno resistito serve a tarare meglio i sistemi e i processi di rilevamento. In pratica la domanda è semplice: mentre il tester si muoveva nella rete, qualcuno se n'è accorto?

Il piano di remediation

Il NIST SP 800-115 chiede che i report interni contengano metodologia, risultati, analisi e un POA&M (Plan of Action and Milestones), il piano che affronta ogni vulnerabilità con azioni specifiche, misurabili, raggiungibili, realistiche e tangibili. Il PTES lo chiama roadmap strategica: un piano di correzione in ordine di priorità, pesato sugli obiettivi di business e sull'impatto potenziale, diviso in tappe.

Le appendici

OWASP elenca la metodologia di test, la spiegazione della scala di gravità, gli output rilevanti degli strumenti (puliti, non riversati così come escono) e l'elenco dei controlli eseguiti. L'ultimo punto conta: dice cosa è stato provato con esito negativo, che è un'informazione quanto i finding.

Come leggere il report quando ti arriva

Un ordine di lettura che fa risparmiare tempo:

1. Perimetro e limiti prima dei risultati. Confronta i sistemi testati con l'elenco del contratto. Quello che è rimasto fuori non è sicuro, è solo non verificato.
2. La scala di rischio. Controlla che sia definita. Se il report usa il CVSS, ricorda che il punteggio Base, secondo la specifica CVSS v4.0 di FIRST, riflette la gravità intrinseca del difetto e assume l'impatto ragionevolmente peggiore fra i diversi ambienti: il gruppo Environmental esiste per adattarlo al tuo. Come si riordina una lista sul proprio contesto è spiegato nella guida su come leggere l'output dei penetration test tools.
3. Confermato o potenziale. Per ogni finding grave, verifica che ci sia l'evidenza dello sfruttamento. Una vulnerabilità solo segnalata da uno strumento pesa diversamente da una sfruttata con successo.
4. Le catene, non le singole voci. Tre finding medi che insieme portano a un account amministrativo valgono più di un critico isolato su un sistema senza dati.
5. La causa. Cerca se il report collega i finding a un processo che non funziona. Il PTES lo dice in forma netta: la causa radice non è mai una patch.
6. La sezione sui controlli. Se il test non ha generato nessun allarme, il risultato riguarda anche il monitoraggio, non solo la configurazione.

I segnali di un report debole

• Output di uno scanner con un logo sopra. OWASP chiede di pulire l'output degli strumenti e di non riversarlo nel documento. Se le pagine sono centinaia e i finding sono tutti a firma di uno strumento, hai comprato una scansione.
• Nessun passo per riprodurre. Senza richieste, comandi o proof of concept, nessuno può verificare la correzione.
• Scala di gravità non spiegata. Un Alto senza criteri non è confrontabile con l'Alto di un altro fornitore.
• Limiti assenti e perimetro identico parola per parola a quello del contratto.
• Raccomandazioni generiche, del tipo applicare gli aggiornamenti, senza responsabile né priorità.
• Nessuna sezione per il retest: se lo stesso report non prevede di essere riaperto, la chiusura delle vulnerabilità resta un'affermazione.

Cosa ci cerca un auditor

Per i soggetti NIS2 il riferimento italiano è preciso. La determinazione ACN 379907/2025 fissa le misure di sicurezza di base: allegato 1 per i soggetti importanti, allegato 2 per gli essenziali. Chi è entrato nell'elenco nazionale NIS nel 2025 le adotta entro diciotto mesi dalla comunicazione di inserimento (ottobre 2026, secondo la pagina ACN dedicata); per chi vi è entrato per la prima volta nel 2026 la determinazione ACN 127434/2026 fissa il termine al 31 luglio 2027. Il calendario completo è nella guida alle scadenze NIS2. Nell'allegato 2, la misura ID.RA-01 chiede attività periodiche, e comunque precedenti la messa in esercizio, che comprendano almeno vulnerability assessment e/o penetration test sui sistemi rilevanti, e al punto 3 prescrive che siano documentate con apposite relazioni che contengano almeno:

• la descrizione generale delle attività effettuate e gli esiti delle stesse;
• la descrizione delle vulnerabilità rilevate e il relativo livello di impatto sulla sicurezza.

Nell'allegato 1 la misura ID.RA-01 non contiene questo requisito. In entrambi gli allegati la misura ID.RA-08 chiede che le vulnerabilità, comprese quelle trovate così, siano prontamente risolte con aggiornamenti o mitigazioni, oppure accettando e documentando il rischio. Il report è quindi il primo anello di una catena documentale, non l'ultimo.

Sopra le misure ACN c'è il D.Lgs. 138/2024, che all'articolo 24, comma 2, include fra le misure minime la gestione e la divulgazione delle vulnerabilità (lettera e) e le politiche e procedure per valutare l'efficacia delle misure di gestione dei rischi (lettera f). Per la ISO/IEC 27001:2022 il riferimento è il controllo 8.8 dell'Allegato A, gestione delle vulnerabilità tecniche: il report è fra le evidenze che si possono portare in audit su quel controllo.

Nel settore finanziario, il Regolamento (UE) 2022/2554 (DORA), all'articolo 24, paragrafo 5, chiede alle entità finanziarie diverse dalle microimprese procedure per dare un ordine di priorità ai problemi riscontrati durante i test, classificarli e porvi rimedio, e metodologie di convalida interne per accertare che tutti i punti deboli individuati siano pienamente affrontati. In pratica, ed è una lettura nostra, il report è il materiale su cui quelle procedure lavorano, e il retest è uno dei modi per fare la convalida. Il TLPT dell'articolo 26 è un esercizio diverso, con regole proprie: vedi i test di resilienza DORA.

Dopo la consegna: retest e custodia

Il NIST SP 800-115 (sezione 8.3) indica la verifica delle correzioni come passo del processo di remediation, anche tramite un nuovo test, e precisa che il team di test può verificarle solo se ripete una copia speculare del test originale. Per questo il retest va chiesto sugli stessi finding, con gli stessi identificativi, e con un esito scritto per ciascuno. Se stai valutando un fornitore, il retest incluso o escluso è una delle domande da fare in preventivo, insieme alle altre elencate nella guida al VAPT.

Resta la custodia. Lo stesso documento (sezione 7.4.2) ricorda che report, regole d'ingaggio e dati grezzi, nelle mani di un avversario, sono una mappa per attaccare l'organizzazione: vanno conservati con accesso limitato a chi ne ha bisogno e cifrati. OWASP raccomanda lo stesso per il report. Un PDF con le vulnerabilità aperte inoltrato a una lista di distribuzione è un'esposizione a sé.

Se hai un report in mano e non sai da dove partire, o devi impostare un test il cui report regga davanti a un auditor, trovi come lavoriamo nella pagina dedicata ai servizi di cybersecurity.