Un fermo produttivo causato da un accesso non autorizzato non nasce quasi mai da un singolo errore. Spesso è il risultato di credenziali esposte, sistemi aggiornati a metà, accessi remoti cresciuti senza controllo o integrazioni tra IT e OT mai verificate dal punto di vista offensivo. Capire quando fare penetration test aziendale significa intervenire prima che una vulnerabilità tecnica diventi un costo operativo, contrattuale e reputazionale.
Per una PMI manifatturiera, il penetration test non è un esercizio teorico né un’attività da svolgere solo dopo un incidente. È una verifica controllata che simula le tecniche di un attaccante per individuare punti deboli sfruttabili in reti, applicazioni, servizi cloud, accessi VPN, dispositivi industriali e processi di gestione delle identità. L’obiettivo non è produrre un elenco di criticità, ma stabilire quali rischi possono interrompere il business e come ridurli in ordine di priorità.
Quando fare penetration test aziendale: i 7 casi concreti
1. Prima di aprire servizi o accessi verso l’esterno
Portali clienti, e-commerce B2B, VPN per tecnici e fornitori, desktop remoti, API per partner, accessi ai gestionali in cloud: ogni servizio esposto amplia la superficie d’attacco. Prima della pubblicazione o dell’attivazione, un penetration test applicativo e infrastrutturale consente di verificare configurazioni, autenticazione, gestione delle sessioni, autorizzazioni e possibili vie di accesso ai dati interni.
Questo controllo è particolarmente rilevante per le imprese che lavorano con clienti statunitensi o internazionali. Un portale progettato per semplificare ordini, assistenza o scambio documentale può diventare un punto di ingresso se ruoli, permessi e dati sensibili non sono gestiti correttamente. Testare prima del go-live evita correzioni urgenti dopo il rilascio, quando l’impatto su utenti e processi è maggiore.
2. Dopo modifiche rilevanti a infrastruttura o software
Un nuovo ERP, la migrazione a Microsoft 365 o a un ambiente cloud, l’integrazione di MES e WMS, un’applicazione custom collegata al gestionale o una nuova rete di stabilimento cambiano il profilo di rischio. Non basta verificare che il progetto funzioni: occorre controllare che funzioni senza creare percorsi inattesi verso dati, account amministrativi o sistemi di produzione.
Il momento corretto è vicino alla chiusura del progetto, prima della messa in esercizio completa, e dopo modifiche sostanziali successive. In pratica, il test deve seguire il cambiamento, non un calendario astratto. Una nuova integrazione può introdurre token troppo permissivi, porte di rete non necessarie, account di servizio senza rotazione password o flussi API privi di adeguati controlli.
3. Quando aumenta il lavoro remoto o l’accesso dei fornitori
Nelle aziende industriali, la manutenzione da remoto e il supporto dei fornitori sono spesso indispensabili. PLC, macchinari, sistemi di supervisione, server di produzione e dispositivi di raccolta dati richiedono talvolta l’accesso di terze parti. Il problema non è l’accesso remoto in sé, ma la sua gestione: chi entra, con quali privilegi, per quanto tempo e con quale tracciabilità.
Un penetration test può verificare se un attaccante riesce a usare un account esterno, una VPN mal configurata o una postazione compromessa per spostarsi dalla rete IT alla rete OT. Qui la prudenza è essenziale. I test su ambienti industriali devono essere progettati per non interferire con impianti, safety e continuità produttiva, con perimetro, finestre operative e tecniche concordate in anticipo.
4. A cadenza regolare, anche se non sono cambiati i sistemi
L’assenza di cambiamenti interni non equivale all’assenza di nuovi rischi. Ogni mese emergono vulnerabilità, tecniche di attacco e campagne mirate contro software già presenti in azienda. Una configurazione considerata adeguata dodici mesi prima può non esserlo più oggi.
Per molte PMI, una frequenza annuale rappresenta una base ragionevole, da integrare con vulnerability assessment più frequenti. Tuttavia, non esiste una cadenza identica per tutti. Un’azienda con dati sanitari, proprietà intellettuale critica, commercio elettronico, forte esposizione internazionale o produzione altamente connessa può richiedere verifiche semestrali o mirate per singolo perimetro.
La scelta deve dipendere da valore degli asset, esposizione esterna, velocità del cambiamento e conseguenze di un fermo. Un attacco che blocca per un giorno il back-office non ha lo stesso impatto di un attacco che impedisce spedizioni, pianificazione della produzione o tracciabilità dei lotti.
5. Dopo un incidente, un alert credibile o un sospetto di compromissione
Dopo ransomware, phishing con furto di credenziali, anomalie di traffico, accessi amministrativi inattesi o comportamenti sospetti sui server, il penetration test aiuta a capire fino a dove un attaccante avrebbe potuto spingersi. Non sostituisce la digital forensics né la gestione dell’incidente, ma può completarle verificando le catene di attacco ancora aperte.
In questa fase occorre distinguere tra contenimento e validazione. Prima si isolano i sistemi coinvolti, si preservano le evidenze e si ripristina l’operatività in sicurezza. Poi si verifica se le misure adottate hanno davvero eliminato il vettore iniziale e i possibili percorsi laterali. Limitarsi a reimpostare una password o applicare una patch può lasciare intatte altre debolezze strutturali.
6. Prima di audit, gare, acquisizioni o richieste di clienti enterprise
Un penetration test è spesso richiesto, direttamente o indirettamente, da clienti enterprise, assicurazioni cyber, investitori e partner di filiera. Nei rapporti internazionali, i questionari di sicurezza diventano sempre più dettagliati: chiedono evidenze su test periodici, gestione delle vulnerabilità, accessi privilegiati, segmentazione e piani di risposta.
Far eseguire il test solo pochi giorni prima di un audit è rischioso. Se emergono criticità elevate, potrebbe non esserci tempo per correggerle, ritestarle e documentare l’intervento. Meglio pianificare con anticipo, assegnare responsabilità interne e trasformare il report in un piano di remediation con date, priorità e verifiche di chiusura.
7. Quando si integra AI nei processi e nei dati aziendali
L’AI applicata a reportistica, analisi documentale, assistenza commerciale o processi operativi introduce nuovi flussi di dati, utenti e autorizzazioni. Il rischio non riguarda solo il modello AI: riguarda le integrazioni con ERP, CRM, repository documentali, database e sistemi di identità.
Se una soluzione AI può leggere ordini, margini, listini, documenti tecnici o dati dei clienti, il penetration test deve verificare che non sia possibile aggirare i permessi, estrarre informazioni tramite richieste manipolate o usare integrazioni vulnerabili come punto di accesso ai sistemi aziendali. La sicurezza va progettata insieme al caso d’uso, non aggiunta dopo l’avvio.
Penetration test o vulnerability assessment?
I due strumenti sono complementari, ma non equivalenti. Il vulnerability assessment identifica vulnerabilità note, software non aggiornato, configurazioni deboli e servizi esposti. È utile per avere una visione ricorrente e ampia del perimetro. Il penetration test verifica invece se quelle debolezze possono essere concatenate e sfruttate per ottenere un risultato concreto, come l’accesso a un server, l’escalation dei privilegi o l’esfiltrazione di dati.
Per esempio, uno scanner può segnalare una versione vulnerabile o una porta esposta. Un penetration test stabilisce se quella condizione è realmente sfruttabile nel contesto specifico, quali sistemi coinvolge e quale danno operativo potrebbe generare. Questa differenza aiuta la direzione a investire sulle priorità reali, non su una lista indifferenziata di alert.
Come pianificare un test senza fermare l’operatività
Un test efficace parte dalla definizione del perimetro. Non è sempre necessario testare tutto nello stesso momento. Per un’azienda manifatturiera può essere più utile iniziare dai servizi esposti, dagli accessi remoti, dagli account amministrativi e dalle integrazioni tra sistemi critici, per poi estendere gradualmente la verifica.
La fase di scoping deve chiarire asset inclusi, sistemi esclusi, finestre orarie, referenti tecnici, modalità di escalation e limiti operativi. Per gli ambienti OT, il principio è chiaro: la verifica deve aumentare la sicurezza senza introdurre rischi per la produzione. In alcuni casi è preferibile combinare analisi di configurazione, test non intrusivi, revisione degli accessi e simulazioni controllate.
Al termine, il valore del test dipende dal report e dalla sua gestione. Un documento utile separa le criticità per impatto e probabilità, mostra il percorso d’attacco, indica le azioni correttive e assegna priorità comprensibili anche per il management. La remediation deve poi essere verificata: una vulnerabilità dichiarata risolta non è necessariamente chiusa finché non viene ritestata.
La domanda giusta non è solo “quando”
Chiedersi quando programmare un penetration test è il primo passo. La domanda decisiva è quale scenario aziendale si vuole prevenire: fermo produttivo, furto di proprietà intellettuale, blocco della supply chain, accesso ai dati dei clienti o interruzione dei servizi digitali.
Un approccio efficace collega il test ai processi che generano valore e ai sistemi che li rendono possibili. INGENIA supporta le imprese nel definire perimetri realistici, integrare la sicurezza nei progetti di digitalizzazione e trasformare le evidenze tecniche in interventi concreti. La sicurezza produce risultati quando consente all’azienda di innovare, con controllo, senza mettere a rischio la continuità operativa.
