Parlare di rischio cyber operativo con il consiglio di amministrazione

Dal data center alla sala del consiglio

Per anni la cybersecurity è stata percepita come una faccenda da reparto IT: firewall, patch, antivirus. Negli ambienti industriali e OT questa lettura è oggi pericolosamente riduttiva. Un attacco che ferma una linea produttiva, manomette una valvola o blocca un impianto di trattamento delle acque non è un incidente informatico: è un problema di continuità operativa, di sicurezza fisica e, alla fine, di bilancio.

Il punto chiave per chi guida la sicurezza è quindi uno solo: il rischio cyber operativo va portato al consiglio di amministrazione nel linguaggio del business, non in quello della tecnologia. Il board non deve capire come funziona un protocollo Modbus, deve capire quanto può costare il suo fallimento.

Tradurre il rischio tecnico in impatto di business

La difficoltà più comune nasce dal divario linguistico. Il responsabile della sicurezza descrive vulnerabilità, CVE e segmentazione di rete; il consiglio ragiona in termini di fatturato, reputazione, responsabilità legale. Servono alcuni passaggi di traduzione.

• Partire da casi concreti e vicini al settore. Episodi noti come l'attacco al gruppo alberghiero che ha generato perdite stimate intorno ai 100 milioni di dollari, o l'intrusione nei sistemi di un'utility idrica, sono efficaci proprio perché mostrano conseguenze tangibili. L'esempio va però sempre ricondotto alla realtà specifica dell'azienda.
• Quantificare l'impatto operativo. Non "una vulnerabilità nel PLC", ma "il fermo di questa linea per 48 ore vale X di mancata produzione, più le penali contrattuali e i costi di ripristino".
• Usare formule "se... allora". "Se vogliamo essere conformi alla normativa di settore, allora dobbiamo implementare questi controlli." È un modo semplice per legare decisione e conseguenza, e per spostare la conversazione dal costo alla scelta.

Inquadrare il cyber come rischio d'impresa

La cybersecurity OT non è un silos: è una componente dell'enterprise risk management, accanto al rischio finanziario, di mercato e di compliance. Trattarla come tale ha due vantaggi. Primo, le dà la stessa dignità delle altre voci di rischio che il consiglio già governa. Secondo, evita l'errore di pensare che la sola conformità normativa basti a mettere al sicuro l'organizzazione: standard come il NIST Cybersecurity Framework o l'ISA/IEC 62443 sono punti di partenza, non traguardi.

Molte realtà strutturano questo passaggio creando un comitato dedicato a livello di board, con un referente che riporta periodicamente lo stato del rischio. La continuità è essenziale: la sicurezza è un processo incrementale, non un obiettivo tattico da centrare una volta sola.

Le metriche che parlano al board

Il consiglio non ha bisogno di centinaia di indicatori. Ne bastano pochi, ma leggibili e collegati al business.

Metrica tecnica	Come presentarla al board
Asset OT non identificati	Quota di impianto "invisibile" e quindi non protetto
Anomalie rilevate e tempo di risposta	Capacità di accorgersi di un attacco prima del danno
Sistemi non aggiornabili	Esposizione residua che richiede mitigazioni alternative
Copertura del monitoraggio	Percentuale di processi critici sotto osservazione continua

L'angolo MON5

Nessuna di queste conversazioni regge senza dati solidi alle spalle. Non si può quantificare un rischio che non si vede. Per questo il lavoro di comunicazione verso il consiglio poggia su tre capacità tecniche che MON5 considera fondanti:

• Visibilità completa degli asset, perché ogni dispositivo OT non censito è un punto cieco nel calcolo del rischio.
• Monitoraggio continuo delle anomalie, che trasforma l'affermazione "siamo sicuri" in "ci accorgiamo di un'intrusione in tempo utile".
• Traduzione dell'evidenza tecnica in impatto operativo, così che il dato di campo diventi una frase comprensibile in sala riunioni.

Portare il rischio cyber operativo al board non significa spaventare, ma dare strumenti di decisione. Quando il consiglio capisce cosa è in gioco in termini di continuità e responsabilità, smette di vedere la sicurezza come un costo e inizia a trattarla per ciò che è: una scelta di governance.

Analisi e commento a cura di MON5 su ricerca e dati di pubblico dominio del settore OT/ICS.