Vulnerability scan o penetration test: cosa chiedono davvero ISO 27001 e NIS2

Il momento più imbarazzante di un audit è quasi sempre lo stesso. Chiediamo l’evidenza sulla gestione delle vulnerabilità e arriva un PDF di duecento pagine: l’esportazione dello scanner, con le sue righe rosse, gialle e verdi. Poi domandi «e queste tre critiche del trimestre scorso, che impatto avrebbero avuto sull’azienda?», e cala il silenzio. Il documento c’è. La risposta no.

La confusione fra scansione automatica delle vulnerabilità e penetration test è comprensibile, perché la prima è spesso una delle tecniche usate dentro il secondo. Ma sono due servizi con obiettivi e livelli di garanzia diversi, e in sede di verifica la differenza si vede tutta.

Cosa fa lo scanner, e cosa non fa

Lo scanner confronta i tuoi asset con un database di problemi noti e ti restituisce vulnerabilità già catalogate, configurazioni sbagliate e aggiornamenti mancanti. È rapido, costa poco e copre tanto: sono qualità vere, e nessuno qui sta dicendo di smettere di usarlo.

Quello che lo scanner non ha è il contesto. Non sa cosa fa la tua azienda, non conosce il disegno di sicurezza che avete adottato, non sa quale sia il comportamento previsto di quell’applicazione. Elenca le debolezze, non ne valuta l’effetto sul business. E soprattutto le guarda una per una, mentre chi attacca fa esattamente il contrario.

Il penetration test manuale parte da lì e prosegue: un professionista valida a mano i risultati per togliere i falsi positivi, li pesa nell’ambiente specifico, e cerca le cose che uno strumento automatico non vede per costruzione. Due esempi concreti, che riprendo da un’analisi che li spiega bene e che ritrovo puntualmente sul campo.

Le falle nella logica di business. Un IDOR su un’applicazione web, cioè un riferimento diretto a un oggetto non controllato, permette di entrare nell’account di un altro utente semplicemente cambiando un identificativo nell’indirizzo. Per lo scanner quella pagina risponde correttamente: nessun software non aggiornato, nessuna configurazione errata, nessun allarme. Per un attaccante è la porta principale.

Le catene. Su una rete interna, un avvelenamento LLMNR combinato con un relay SMB può portare alla compromissione completa del dominio, e da lì al ransomware. Prese una alla volta, quelle due debolezze in un rapporto automatico stanno in fondo all’elenco, magari classificate come «medie». Messe in fila, sono la fine dell’azienda per una settimana.

Questa è la differenza che conta: lo scanner dice quali porte sono aperte, il penetration test dimostra dove portano.

Cosa chiede davvero la ISO 27001

Qui va detta una cosa che spesso viene venduta male, e la dico chiara perché è il cuore del discorso: la norma non ti obbliga a fare un penetration test. Non c’è un controllo intitolato così, e chi te lo presenta come un obbligo di legge sta semplificando per vendere.

Quello che la ISO/IEC 27001 chiede è diverso, e più esigente. Il controllo A.8.8, gestione delle vulnerabilità tecniche, pretende che l’organizzazione ottenga informazioni sulle vulnerabilità dei sistemi in uso, valuti la propria esposizione e adotti misure adeguate. La parola chiave è «valuti»: non «elenchi». Un rapporto che classifica una vulnerabilità come critica secondo un punteggio standard non dice nulla sulla tua esposizione, perché quel punteggio è calcolato senza sapere se quel sistema è isolato, esposto su internet o collegato al gestionale che fa fatturato.

Il controllo A.8.29, test di sicurezza in sviluppo e accettazione, chiede invece di definire e attuare processi di test lungo il ciclo di vita, prima che una cosa vada in produzione. Anche qui il come è lasciato a te. Ma se sviluppi software, o se ne fai sviluppare, un processo di accettazione che consiste nel far girare uno scanner difficilmente regge alla domanda successiva dell’auditor: «e la logica applicativa chi l’ha verificata?».

Il punto quindi non è l’obbligo. È che la norma non prescrive lo strumento, pretende l’evidenza, e per certe evidenze lo scanner da solo non basta. È una differenza che in audit si sente subito.

Cosa chiede davvero la NIS2, e la data che conta

Stessa logica, con una differenza di temperatura: qui non c’è un auditor che ti fa una raccomandazione, c’è un’autorità che ispeziona.

L’articolo 24 del decreto legislativo 138/2024, che ha recepito la direttiva NIS2, elenca le misure minime di gestione del rischio. Due voci di quell’elenco riguardano direttamente questo tema. La prima è la sicurezza dello sviluppo dei sistemi, ivi compresa la gestione e la divulgazione delle vulnerabilità. La seconda, che secondo me è la più sottovalutata di tutto il decreto, sono le politiche di valutazione dell’efficacia delle misure di gestione dei rischi.

Fermiamoci su quest’ultima. Valutare l’efficacia significa rispondere alla domanda «le misure che abbiamo adottato funzionano davvero?», e per rispondere servono prove. Un audit interno prova che il processo esiste. Un riesame di direzione prova che qualcuno lo guarda. Ma la prova che una misura tecnica regge la si ottiene provando a superarla, ed è precisamente quello che fa un test manuale.

Poi c’è la data, ed è vicina. La determinazione ACN n. 379907 del 18 dicembre 2025, che ha sostituito la precedente n. 164179/2025 e si applica dal 15 gennaio 2026, fissa le specifiche di base. Il termine per averle implementate e operative è il 31 ottobre 2026, cioè diciotto mesi dalle comunicazioni di inserimento nell’elenco NIS arrivate fra aprile e maggio 2025.

• I soggetti importanti devono aver adottato le 37 misure e gli 87 requisiti dell’Allegato 1.
• I soggetti essenziali devono aver adottato le 43 misure e i 116 requisiti dell’Allegato 2.

Da quella data l’Agenzia per la Cybersicurezza Nazionale esce dalla fase di accompagnamento ed entra in quella di verifica. Con una asimmetria da tenere presente quando si pianificano i budget: sui soggetti essenziali la vigilanza è ex ante, cioè proattiva, mentre sugli importanti è prevalentemente ex post, dopo un incidente o una segnalazione. Se sei un soggetto essenziale, non aspettare che succeda qualcosa per scoprire se le tue misure tengono.

La differenza si vede sull’evidenza

Messa in pratica, la distanza fra i due approcci è tutta in cosa riesci a mettere sul tavolo quando qualcuno chiede conto.

Con il solo scanner porti un elenco di problemi noti e, se il processo è fatto bene, la prova che li hai chiusi entro i tempi che ti sei dato. È già qualcosa, ed è indispensabile: senza quella base non si va da nessuna parte.

Con un test manuale porti tre cose in più, e sono esattamente quelle che le norme chiedono. Una valutazione dell’esposizione reale, perché il tester ha visto il tuo ambiente e non un database. Una dimostrazione di impatto, cioè un percorso di attacco ricostruito passo per passo fino a dove arriva davvero. E una verifica di efficacia: se il test si è fermato, le tue misure hanno funzionato, e questa è la prova che l’articolo 24 ti chiede.

C’è anche il rovescio della medaglia, e va detto perché nessuno lo dice mai. Un test manuale fatto male è peggio di nessun test: produce un rapporto che sembra un’evidenza, viene messo agli atti, e crea la stessa falsa sicurezza dello scanner, con in più il costo. La qualità qui dipende da chi lo fa, non da cosa hai comprato.

Cosa chiedere a chi te lo vende

Se stai valutando un fornitore, queste cinque domande separano un test vero da uno scanner con la fattura di un test.

• I risultati sono validati a mano? Se il rapporto è l’esportazione dello strumento, con i falsi positivi ancora dentro, hai comprato una scansione.
• Verificate la logica applicativa e i controlli di autorizzazione? È la famiglia di problemi, come l’IDOR, che nessuno strumento automatico trova.
• Concatenate le debolezze? Chiedete un esempio di percorso di attacco ricostruito su un cliente precedente, anche anonimizzato. Se la risposta è vaga, la risposta è no.
• Il rapporto dimostra l’impatto sul business o si ferma al punteggio di gravità? Il punteggio è calcolato senza sapere niente di voi.
• Cosa succede dopo? Un test che non produce azioni tracciate nel sistema di gestione non è un’evidenza di efficacia: è una fotografia.

Come lo facciamo noi

Su questo sono trasparente, perché è il modo in cui lavoriamo e perché credo sia anche il modo giusto. Il test tecnico non lo eseguiamo internamente: lo affidiamo a partner professionali specializzati, selezionati e coordinati da noi. Chi fa penetration test seriamente lo fa a tempo pieno, e un consulente di sistemi di gestione che improvvisa un test offensivo è esattamente il fornitore da cui vi ho appena detto di stare alla larga.

Quello che portiamo noi è la parte che, in sede di audit o di ispezione, fa la differenza fra un rapporto e un’evidenza:

• La definizione del perimetro a partire dall’analisi del rischio e dagli asset che contano davvero, invece che da un elenco di indirizzi IP.
• La scelta del partner giusto per quel perimetro, con i criteri di qualità di cui sopra scritti nel capitolato.
• Il collegamento ai controlli: A.8.8 e A.8.29 per la ISO 27001, gestione delle vulnerabilità e valutazione dell’efficacia per l’articolo 24, con il riferimento esplicito nella documentazione del sistema.
• Il rientro dei risultati nel sistema di gestione: azioni, responsabilità, scadenze, riesame. È il pezzo che trasforma un test in una misura di efficacia dimostrabile.
• La ripetizione nel tempo, perché una prova di efficacia vale finché l’ambiente non cambia, e l’ambiente cambia sempre.

Il test è un pezzo di un percorso, non un acquisto isolato. Chi lo compra da solo, senza il resto, si ritrova con un PDF e con lo stesso problema di prima: l’evidenza che manca quando qualcuno la chiede.

Se vuoi capire da che parte stai, il punto di partenza è sempre lo stesso: prendi l’ultimo rapporto di sicurezza che hai in mano e guarda se risponde alla domanda «cosa sarebbe successo davvero». Se risponde solo «ecco cosa non è aggiornato», sai già cosa ti manca. Ne parliamo volentieri: trovi il percorso completo sulle pagine dedicate a ISO/IEC 27001 e alla NIS2, oppure scrivici e partiamo dal tuo perimetro reale. Se preferisci farti prima un’idea da solo, fra i nostri strumenti gratuiti c’è la verifica di posizione su NIS2.

Nota: l’applicabilità delle misure e la loro estensione dipendono dalla classificazione del soggetto e dal perimetro concreto. Questo articolo ha finalità informative generali e non sostituisce una valutazione sul caso specifico. Articolo aggiornato ad agosto 2026, con riferimento alla determinazione ACN n. 379907/2025 e al termine del 31 ottobre 2026.