L’audit NIS2 in ambito OT è uno di quei passaggi che, per molte realtà industriali, segnano il vero confine tra ciò che è stato pianificato e ciò che è realmente governato in produzione.
Quando le verifiche riguardano impianti, macchine, sistemi legacy e accessi remoti, non bastano policy ben scritte: servono controlli concreti, tracciabilità delle decisioni e prove che raccontino come la cybersecurity OT viene gestita ogni giorno, senza fermare le linee.
È un tema che Innovio affronta quotidianamente al fianco delle aziende manifatturiere, proprio nel punto di contatto tra IT, OT e operation.
In questo articolo entriamo in quella zona spesso poco chiara dell’audit, dove le domande diventano operative e le risposte devono essere dimostrabili sul campo.
Per saperne di più sulla normativa NIS2 e su come essere conformi a 360° leggi Cybersecurity e NIS2: com’è e come essere conformi.
Audit NIS2: cosa cambia quando l’audit entra in impianto OT
Un audit NIS2 in ambito industriale diventa davvero “serio” quando smette di essere solo un esercizio di compliance e si trasforma in una verifica di controlli dimostrabili: non basta dichiarare che esistono procedure o strumenti, bisogna far vedere come vengono applicati in OT, con quali responsabilità e con quali prove.
In pratica, rispetto a un audit IT classico, in OT cambiano tre cose fondamentali:
- Il contesto operativo conta quanto (e spesso più di) quello documentale. In fabbrica non puoi “aggiustare dopo”: molte misure devono convivere con vincoli reali (impianti legacy, finestre di fermo limitate, disponibilità come priorità). L’auditor tende quindi a verificare se la cybersecurity OT è stata progettata tenendo conto di questi vincoli, senza lasciare zone grigie.
- Le evidenze richieste sono più “di campo”. Non si guarda solo che cosa è scritto, ma come lo dimostri: inventario OT aggiornato, gestione accessi remoti dei fornitori, tracciamento delle modifiche su asset critici, backup e (soprattutto) test di ripristino, monitoraggio e gestione eventi. Il punto è far emergere la tua OT cybersecurity e NIS2 come pratica quotidiana, non come teoria.
- Le interfacce IT/OT diventano il punto caldo. Molti problemi saltano fuori dove IT e OT si incontrano: segmentazione/DMZ, integrazioni con MES/ERP, jump server o VPN di manutenzione, identità e privilegi, flussi dati verso historian o cloud. Sono aree dove, se manca governance, anche un singolo accesso “comodo” può diventare una scorciatoia per un hacker.
In questa guida partiamo proprio da qui: capire come si presenta un impianto “audit-ready”, quali controlli rendono credibile la sicurezza in produzione e quali prove conviene preparare prima che qualcuno le chieda, quando i margini di manovra sono molto più stretti.
OT cybersecurity e NIS2: partire da asset, confini OT/IT e dipendenze critiche
Se c’è un punto in cui OT cybersecurity e NIS2 si incontrano in modo molto concreto, è qui: avere una visione chiara di cosa stai proteggendo, dove finisce l’OT e quali dipendenze rendono davvero critico un impianto. Senza questa base, qualunque misura (monitoraggio, segmentazione, gestione accessi) rischia di essere “a macchia di leopardo” e difficile da dimostrare durante un audit.
1) Inventario OT “auditabile”: non basta sapere che esiste, deve essere usabile
In ambito OT, l’inventario non è un elenco generico: è uno strumento operativo che deve permetterti di rispondere velocemente a domande tipiche da audit come:
- Quali asset sono in produzione e quali sono critici per continuità, qualità, safety o compliance
- Chi li gestisce (IT, OT, manutenzione, fornitore) e con quali responsabilità
- Quali versioni/firmware girano, quali protocolli usano, come comunicano tra loro
- Quali accessi remoti esistono e con quali credenziali/privilegi
Per essere davvero utile (e difendibile), l’inventario OT dovrebbe includere almeno:
- Asset (PLC, HMI, SCADA, historian, engineering workstation, switch industriali, gateway, sistemi di teleassistenza)
- Ruolo e criticità (cosa succede se si ferma/si altera: fermo linea, scarto qualità, impatto safety, ecc.)
- Owner e processo di change (chi approva modifiche, chi le esegue, come vengono tracciate)
- Connessioni e dipendenze (verso IT, verso fornitori, verso cloud/servizi esterni)
Qui spesso emerge il primo gap: “lo sappiamo a memoria” non regge. In un audit, serve poterlo mostrare, aggiornare e motivare.
2) Confini OT/IT: definire zone e varchi, non solo “reti separate”
Molte aziende dicono: “OT e IT sono separati”. Poi però, quando si guarda meglio, compaiono eccezioni che nessuno governa: una VPN storica, un PC di reparto con due schede di rete, un accesso del fornitore “perché altrimenti non si lavora”, un passaggio diretto verso MES o ERP.
Per rendere il confine credibile, l’approccio più efficace è descriverlo come:
- Zone (celle/linee/aree OT con funzioni omogenee)
- Varchi controllati (DMZ OT, jump server, proxy/segregazione servizi)
- Flussi consentiti (chi parla con chi, su quali porte/servizi, con quale logica)
Questo non significa entrare in tecnicismi inutili: significa poter dimostrare che l’architettura non è casuale, ma governata. E in un audit NIS2 questo fa la differenza, perché trasforma una rete storica in un sistema con regole e motivazioni.
3) Dipendenze critiche: il vero “effetto domino” in fabbrica
Un impianto OT raramente cade per un singolo componente: spesso si blocca perché una dipendenza invisibile viene meno. Ecco perché in cybersecurity OT le dipendenze sono una parte fondamentale delle evidenze.
Le più sottovalutate, ma spesso decisive in audit:
- Dipendenze di identità e accesso (utenze condivise, privilegi non tracciati, credenziali del fornitore “di sempre”)
- Dipendenze di connettività (link IT/OT non documentati, Wi-Fi industriale, modem/4G “di emergenza”)
- Dipendenze di dati (historian, MES, sistemi qualità, reportistica: se si fermano, l’impianto “funziona” ma l’azienda non produce valore)
- Dipendenze di manutenzione (software di programmazione, licenze, laptop tecnici, tool proprietari del vendor)
Mappare queste dipendenze serve a due cose: capire dove mettere controlli mirati e, soprattutto, avere una narrazione solida durante l’audit: “questi sono i punti critici, questi sono i controlli, queste sono le prove che li rendono verificabili”.
In altre parole: prima ancora di parlare di strumenti, l’audit ti chiede di dimostrare che l’OT non è un insieme di eccezioni, ma un perimetro con asset noti, confini tracciati e dipendenze governate. Da qui in poi, tutto il resto (accessi, backup, logging, monitoraggio) diventa molto più semplice da sostenere con evidenze.
Cybersecurity OT: le evidenze che l’auditor si aspetta di vedere (non solo policy)
Durante un audit NIS2 in impianto, la differenza non la fa avere “tante carte”, ma avere evidenze coerenti: prove che collegano ruoli, controlli e risultati. In OT, soprattutto, l’auditor tende a cercare tracce verificabili del fatto che la cybersecurity OT non sia affidata alla buona volontà dei singoli, ma funzioni come un processo ripetibile.
Di seguito trovi le evidenze più richieste (e più utili), organizzate in modo pratico: cosa sono, dove si trovano, e perché contano.
1) Evidenze di governance e responsabilità (chi decide cosa in OT)
Qui l’obiettivo è dimostrare che OT e IT non lavorano “a compartimenti stagni” e che esiste un presidio chiaro sulle decisioni che impattano la produzione.
Esempi di evidenze:
- Matrice ruoli/responsabilità (IT, OT, manutenzione, produzione, fornitori) con escalation e reperibilità
- Registro delle eccezioni (es. “questa macchina non può essere patchata”: chi lo ha approvato, per quanto tempo, con quali compensazioni)
- Piano di audit readiness / programma di controlli periodici (anche semplice, ma concreto)
Perché serve: se non è chiaro chi governa, qualunque controllo può essere aggirato “per urgenza”, e un hacker trova sempre la scorciatoia più comoda.
2) Evidenze tecniche “hard” (configurazioni e controlli realmente attivi)
Qui si entra nel vivo: non basta dire “abbiamo segmentato” o “abbiamo MFA”. Bisogna mostrare elementi oggettivi.
Esempi tipici:
- Estratti di configurazione o screenshot di regole (firewall/ACL), DMZ OT, jump server/bastion, whitelist dei servizi ammessi
- Prove di hardening sugli endpoint OT (engineering workstation, server SCADA/HMI): criteri di local admin, servizi disattivati, baseline applicata
- Evidenze di controllo accessi: MFA dove possibile, policy password, gestione account nominali vs condivisi, dismissione credenziali di fornitori
Perché serve: in OT cybersecurity e NIS2, l’auditor vuole vedere che i “punti di ingresso” (soprattutto accessi remoti e privilegi) sono sotto controllo.
3) Evidenze di change management e tracciabilità (cosa è cambiato, quando, e perché)
In OT non si può aggiornare tutto in automatico, ma si deve poter dimostrare che i cambiamenti sono gestiti.
Evidenze utili:
- Registro cambi (anche in forma snella) con approvazione, esecuzione, rollback plan
- Ticket o verbali di intervento (interni o del vendor) legati a modifiche su PLC/HMI/SCADA
- “Golden config” o backup delle configurazioni (dove applicabile) e confronto versioni
Perché serve: un audit cerca segnali di controllo nel tempo. Se un parametro critico cambia senza traccia, è difficile dimostrare integrità e responsabilità.
4) Evidenze di backup e ripristino (la prova che “si torna su” davvero)
Questa è una delle aree dove molte aziende cadono: hanno backup, ma manca la prova del ripristino.
Cosa mostrare:
- Elenco dei backup OT (server, macchine virtuali, configurazioni, immagini workstation) con frequenza e retention
- Evidenza di test di restore (report, screenshot, checklist firmata) su campioni significativi
- Priorità di ripristino per asset critici (ordine e tempi attesi)
Perché serve: la resilienza è un fatto, non una promessa. E in OT il tempo di ripartenza è parte della sicurezza.
5) Evidenze di monitoraggio e gestione eventi (cosa vedi e cosa fai quando succede)
Non serve “avere un SIEM” per forza; serve dimostrare che gli eventi rilevanti vengono raccolti e gestiti, soprattutto per i punti ad alto rischio.
Evidenze:
- Elenco fonti log OT/IT rilevanti (accessi remoti, jump server, firewall OT, server SCADA, antivirus/EDR dove presente)
- Esempi di alert e relativa gestione (apertura ticket, analisi, azione correttiva, chiusura)
- Procedure di incident handling adattate all’impianto (chi decide, chi isola, come si comunica senza impattare safety/continuità)
Perché serve: l’audit verifica che non stai “guardando i log” solo quando succede un problema.
6) Evidenze su terze parti e manutenzione remota (il nervo scoperto dell’OT)
In fabbrica i fornitori sono indispensabili, ma spesso sono anche il varco più facile.
Evidenze chiave:
- Elenco fornitori con modalità di accesso (sempre attivo vs on-demand), autorizzazioni, tracciamento sessioni
- Prove di approvazione accesso (workflow o ticket) e scadenza credenziali
- Regole di ingaggio: cosa è consentito fare, in quali orari, con quale supervisione
Perché serve: se l’accesso remoto è “sempre lì”, prima o poi qualcuno lo sfrutta. Un hacker non ha fretta: aspetta l’occasione migliore.
Prove tecniche richieste in OT: accessi, patching, backup e restore, monitoring e remote maintenance
In un audit, la parte più “delicata” non è dichiarare che esistono controlli, ma dimostrare che funzionano in condizioni reali di fabbrica. Qui la cybersecurity OT viene valutata su elementi molto concreti: chi entra in OT, con quali privilegi, cosa cambia sugli asset critici, quanto sei in grado di ripristinare, cosa monitori e come reagisci. È anche il punto in cui un audit NIS2 tende a far emergere scorciatoie storiche e procedure rimaste implicite.
Accessi e privilegi: chi entra in OT, come e con quali regole
Gli auditor guardano con attenzione tutto ciò che riguarda accessi remoti, account privilegiati e identità condivise. In OT, questi aspetti sono spesso legati alla manutenzione e all’urgenza operativa, quindi vanno resi governabili senza bloccare il lavoro.
Prove tecniche tipiche che conviene preparare:
- Elenco degli accessi verso l’ambiente OT, distinguendo accessi locali e remoti, e indicando quali sistemi abilitano l’ingresso (VPN, jump server, bastion host, gateway)
- Evidenze di autenticazione forte dove possibile, ad esempio MFA o meccanismi equivalenti, almeno per accessi remoti e account ad alto privilegio
- Elenco account privilegiati e modalità di gestione, con prova della rimozione o disabilitazione di utenze non più necessarie
- Evidenze di tracciamento delle sessioni, quando disponibile, oppure log di accesso e attività sui sistemi di frontiera (jump server, firewall, sistemi di accesso remoto)
- Regole operative per la manutenzione, ad esempio accesso on demand con approvazione, orari, durata, supervisione
Per un auditor, il segnale positivo è vedere che l’accesso non è una “porta sempre aperta”, ma un processo controllato e verificabile. Questo è un pilastro di OT cybersecurity e NIS2, perché gli accessi sono spesso il punto più sfruttabile da un hacker.
Patching e vulnerabilità: quando non puoi aggiornare, devi dimostrare come compensi
In OT è normale non poter patchare subito, o non poter patchare affatto su alcuni asset. Il problema non è il vincolo in sé, ma l’assenza di un metodo per gestirlo. Un audit NIS2 tende a verificare che esista una logica di priorità, un processo decisionale e misure compensative coerenti.
Prove tecniche utili:
- Report di vulnerability assessment o almeno un inventario con versioni, firmware e informazioni di obsolescenza sugli asset critici
- Piano di patching con finestre di manutenzione e criteri di priorità basati su criticità dell’asset e esposizione
- Registro delle eccezioni di patching con motivazione, approvazione e durata dell’eccezione
- Evidenze delle misure compensative adottate quando non si patcha, ad esempio segmentazione più restrittiva, riduzione servizi esposti, accesso remoto on demand, controllo applicativo dove applicabile, monitoraggio mirato su eventi anomali
Qui la cybersecurity OT viene giudicata per la capacità di governare il rischio nel tempo, non per l’ideale di avere tutto aggiornato.
Backup e restore: la prova non è il backup, è il ripristino riuscito
Questa è una delle aree dove gli auditor insistono di più, perché è direttamente collegata a resilienza e continuità produttiva. Avere backup senza test di ripristino è un buco tipico.
Prove tecniche che fanno la differenza:
- Elenco dei backup OT con periodicità e retention, includendo server SCADA, historian, engineering workstation, configurazioni di apparati e, dove possibile, configurazioni PLC
- Evidenza di segregazione e protezione dei backup, ad esempio repository dedicati, accessi limitati, copie offline o immutabili se disponibili
- Report o verbali di test di restore effettuati su un campione significativo, con data, esito, tempi e azioni correttive
- Definizione delle priorità di ripristino per asset critici e evidenze che l’ordine è stato validato con OT e produzione
In un audit NIS2, questa sezione si traduce spesso in una domanda semplice: quando è stata l’ultima volta che avete ripristinato davvero, e cosa avete imparato.
Monitoring e logging: cosa osservi in OT e come gestisci gli eventi
Non esiste una sola architettura valida per tutti, ma l’auditor si aspetta di vedere una copertura coerente almeno sui punti di ingresso e sui sistemi più critici. L’obiettivo non è collezionare log, ma dimostrare capacità di rilevazione e risposta.
Prove tecniche da portare:
- Elenco delle fonti log e degli eventi considerati rilevanti per la cybersecurity OT (accessi remoti, jump server, firewall OT, server SCADA, sistemi di autenticazione, endpoint critici)
- Esempi di alert o incidenti gestiti, con ticket o registrazioni che mostrino analisi, azione e chiusura
- Regole di retention dei log e modalità di consultazione, chiarendo chi è responsabile del monitoraggio e dell’escalation
Nell’ottica OT cybersecurity e NIS2, il monitoraggio credibile è quello che ha un flusso operativo, non quello che esiste solo come strumento.
Remote maintenance: governare i fornitori senza perdere velocità operativa
La manutenzione remota è indispensabile in molte fabbriche, ma spesso è anche la parte meno formalizzata. In audit, viene valutata come un controllo chiave perché un accesso di terza parte con privilegi elevati è un rischio diretto.
Prove tecniche rilevanti:
- Elenco fornitori con modalità di accesso, privilegi, sistemi coinvolti e regole di attivazione
- Evidenze di approvazione e tracciamento degli accessi, almeno per interventi su asset critici
- Prove di segmentazione o limitazione del perimetro raggiungibile dal fornitore, per ridurre l’impatto di credenziali compromesse
- Procedure di revoca e revisione periodica degli accessi
Questa sezione, più di altre, mostra se la cybersecurity OT è progettata per il mondo reale. Non serve rendere impossibile la manutenzione, serve renderla controllata e dimostrabile.
Audit readiness OT: trasformare l’audit NIS2 in uno strumento di governo dell’impianto
Arrivare preparati a un audit NIS2 in ambito OT non significa solo “superare la verifica”, ma usare l’audit come occasione per rendere più solido e governabile ciò che già esiste in fabbrica. Quando asset, accessi, dipendenze e controlli sono chiari, l’audit smette di essere un evento straordinario e diventa una fotografia coerente dello stato reale della cybersecurity OT.
Le aziende che affrontano meglio questo passaggio hanno in comune alcuni elementi chiave: evidenze raccolte in modo continuativo e non all’ultimo momento, responsabilità condivise tra IT, OT e operation, e un set di controlli realistici, progettati tenendo conto dei vincoli produttivi. In questo scenario, anche le inevitabili eccezioni tipiche dell’OT diventano gestibili, perché documentate, motivate e compensate.
Un approccio di OT cybersecurity e NIS2 davvero efficace non punta alla perfezione teorica, ma alla coerenza nel tempo: sapere cosa proteggere, dimostrare come lo si controlla e migliorare progressivamente dove emergono i punti deboli.
È proprio su questo equilibrio tra sicurezza, continuità e compliance che Innovio affianca le aziende industriali, aiutandole a costruire percorsi di audit readiness concreti e funzionali. Se stai valutando come preparare o rafforzare il tuo impianto in vista delle verifiche NIS2, confrontarti con un team che conosce a fondo l’OT può fare la differenza.
