Il governo dei sistemi informativi in un contesto di PMI
Cos’è il governo dei sistemi informativi e perché è importante
Gli accadimenti più recenti (Covid, aumento esponenziale dei Cyber Attacks, ecc.) hanno evidenziato come l’importanza dei sistemi informativi all’interno delle aziende stia progressivamente crescendo, al fine di supportarne e garantirne l’operatività e l’evoluzione tecnologica ed organizzativa.
Di conseguenza, un governo dei sistemi informativi efficiente ed efficace sta diventando sempre più spesso un fattore cruciale per le aziende, talvolta anche in virtù di ragioni normative.
Purtroppo, nelle aziende – e in particolare nelle PMI – l’importanza di un corretto governo dei sistemi informativi viene spesso sottovalutata, talvolta considerandola riduttivamente come competenza esclusiva del dipartimento ICT.
Ma perché la problematica di una gestione “più attenta” dei sistemi informativi è così importante per l’azienda?
Come si osserva da una pluralità di “incidenti” occorsi ad aziende di dimensioni diverse, le cause ricorrenti vanno spesso individuate nelle insufficienti performances – o, addirittura, nell’indisponibilità (parziale o totale) – di applicazioni e sistemi IT, oppure dalla perdita dei dati. Queste carenze hanno quasi sempre conseguenze molto rilevanti sull’intero business dell’azienda: discontinuità produttive o logistiche, impatti economici-finanziari, impatti reputazionali. Di conseguenza, il coinvolgimento dell’imprenditore e del top management su tali temi rappresenta un fattore chiave per attuare una efficace politica di gestione dei sistemi informativi.
Vediamo alcuni esempi.
- Cosa succederebbe in azienda se alcuni dati critici venissero corrotti o criptati da un Cyber Attack e non si disponesse di dati di backup non corrotti dai quali poter ripartire?
- Cosa succederebbe in azienda se alcune applicazioni critiche (ad esempio l’ERP) non fossero disponibili per giorni o settimane, a causa della compromissione delle infrastrutture hardware o, addirittura, dell’intero data center?
- Quale sarebbe l’impatto per l’azienda se fossero cancellati (per errore o per dolo) dal repository documentale aziendale documenti vitali (ad esempio progetti o contratti) oppure se la stessa cosa accadesse per email altrettanto vitali scambiate, ad esempio, con clienti e fornitori?
- Quale sarebbe l’impatto reputazionale verso i propri stakeholder (clienti, fornitori, operatori della logistica, dipendenti, ecc.) qualora l’azienda stessa subisse un fermo operativo significativo, imputabile ad un’inefficace gestione dell’IT?
- Quali sarebbero le conseguenze (operative e relazionali interne) nel caso in cui un dipendente aprisse incautamente un documento allegato ad una email di phishing e causasse così un grave problema IT? E quali sarebbero le conseguenze se in azienda si riscontrasse un furto di identità (furto di user Id e password) e magari questo avesse causato un incauto pagamento di una cifra significativa?
- Quali sarebbero le conseguenze (legali, economiche e reputazionali) derivanti da un data breach con il conseguente furto di dati di clienti, fornitori, ecc.?
Come è possibile indirizzare il problema della gestione del rischio IT?
La problematica di una corretta gestione dei rischi legati ai sistemi informativi (IT Risk Management) può essere inquadrata all’interno di più ampi contesti quali l’Enterprise Risk Management (ERM)1 o l’IT Governance2, e ne costituisce parte integrante, come illustrato nella figura sotto riportata.
Seguendo questo approccio l’IT Risk Management può essere definito come “un processo finalizzato ad individuare e trattare, prevenire o mitigare gli eventi negativi dovuti all’utilizzo dell’IT, ma anche a concretizzare le opportunità legate ai sistemi informativi per supportare al meglio l’azienda”.3
Questa definizione sottolinea l’importanza di alcuni concetti fondamentali:
- l’oggetto del processo di IT Risk Management è il rischio IT, definibile a sua volta come “la possibile esposizione a perdite per l’organizzazione, derivanti da un fallimento in ogni possibile aspetto del sistema informativo aziendale e può rientrare in una delle seguenti classi di rischio: business disruption, impatto relazionale, tecnologico e di governance”;
- ha l’obiettivo di minimizzare la probabilità di impatto di eventi negativi e contemporaneamente quello di massimizzare i benefici conseguenti alle opportunità offerte dall’ICT;
- l’IT Risk Management è un processo e non un’attività istantanea legata ad un preciso momento temporale.
Un tale approccio può risultare sicuramente di grande valore per le aziende medio-grandi, in particolare quando esse intendano conseguire certificazioni rispetto a problematiche di gestione (ad esempio ISO 27001, ISO 22301, ecc.). Allo stesso tempo, però, impone però 5 prerequisiti fondamentali, che mal si adattano al contesto della PMI:
- Un’ampia disponibilità di tempo e delle risorse dell’azienda per definire le priorità e gli ambiti di rischio, dal punto di vista dei processi aziendali. Questo approccio implica infatti un coinvolgimento attivo delle risorse aziendali, molto dispendioso, e quindi di notevole impatto sull’operatività aziendale.
- Tempi lunghi prima di per poter disporre dei risultati di una tale analisi.
- Un costo significativo, conseguente al notevole impiego di risorse necessarie per effettuare un’analisi efficace.
- Ha la finalità di introdurre in azienda processi continuativi di monitoraggio e gestione del rischio, che quasi sempre impongono un ridisegno dei processi ICT e della stessa organizzazione ICT.
- Si basa su valutazioni probabilistiche del rischio.
Per la verità, esiste anche un approccio alternativo: quello legato alle problematiche di gestione della continuità operativa, che si esplicitano in particolare tramite la Business Impact Analysis (BIA)4 , cioè “il processo di analisi delle attività critiche dell’azienda e degli effetti che un’interruzione potrebbe avere su di esse”.
Con questo diverso approccio si potrebbe ottenere il risultato di indirizzare il problema in maniera deterministica, anziché probabilistica, direttamente legata al contesto IT. Allo stesso tempo, anch’esso segue però un’impostazione per processi, basata su azioni continuative di monitoraggio e gestione del rischio e, quindi, presenta le medesime criticità in relazione al contesto della PMI sopra evidenziate. La risoluzione di tali problematiche richiederebbe un’elevata sensibilità del management dell’azienda verso la problematica della gestione del rischio, nonché l’accettazione di costi significativi derivanti da una tale gestione. Tutte cose che, purtroppo, sono molto rare nelle aziende della PMI, dove il dipartimento ICT viene quasi sempre visto come avente mera funzione di supporto.
Ma allora come si può indirizzare tale problematica in un’azienda della PMI?
Un approccio alternativo che risulta vincente in contesti di PMI è quello di non ricorrere ad un’analisi dei rischi per processi e all’implementazione di processi di monitoraggio e controllo (continuativi nel tempo), ma, piuttosto, approcciare il problema tramite un IT Risk Assessment puntuale e la conseguente proposizione di un piano di rimedio (Remediation Plan).
Questo approccio alternativo – ovviamente – non esclude un’evoluzione successiva in chiave IT Risk Management o di gestione della continuità operativa, ma le rimanda ad un momento successivo, in cui l’imprenditore e il top management avranno maturato una diversa consapevolezza del problema.
Rispetto alle metodologie classiche – di cui s’è parlato sopra, in ambito PMI, si ritiene più efficace utilizzare un approccio bottom-up che, a partire dalle possibili esposizioni al rischio nella gestione tecnologico-applicativa dell’IT, consenta poi di risalire alle implicazioni che queste hanno sul business dell’azienda.
Quindi l’assessment deve partire da un’analisi approfondita dell’organizzazione del dipartimento IT, della relativa struttura tecnologica-applicativa, delle interdipendenze legate ai dati e alle applicazioni stesse, nonché delle politiche di alta affidabilità, di business continuity, di backup e di Cybersecurity adottate in azienda. Tale approccio consente, inoltre, di limitare l’impatto sul personale dell’azienda, circoscrivendolo alle sole risorse IT.
Successivamente, dev’essere effettuata una stima dell’impatto tecnologico e dei relativi tempi di rispristino (MTPD5, RTO6 e RPO7), che potrebbero derivare da eventuali indisponibilità dei servizi IT.
Da tale analisi si deve poi risalire – mediante l’identificazione degli impatti derivanti dalle carenze posturali IT – alle implicazioni che quest’ultime hanno sugli specifici contesti di business. In particolare, dev’essere ricalibrata la precedente analisi tecnologica-applicativa, sui diversi impatti di business (business disruption, impatti relazionali, tecnologici e di governance), in modo da poter valutare le conseguenze che le carenze posturali IT potrebbero provocare sul business dell’azienda: discontinuità produttive o logistiche, impatti economici-finanziari, impatti reputazionali diretti o indiretti, implicazioni legali (contrattuali, normative o fiscali).
Questo passaggio potrebbe essere riassunto tramite una tabella come quella riportata in figura, che mette in correlazione l’impatto tecnologico-applicativo con quello di business, e dalla quale si possono poi evincere le attribuzioni delle diverse priorità di intervento.
Ai diversi colori delle celle nella tabella corrispondono diversi indici di impatto complessivo e, conseguentemente, diversi livelli di priorità di intervento, secondo la seguente logica:
- Rosso – priorità 1 (critica)
- Arancio – priorità 2 (medio-alta)
- Giallo – priorità 3 (media)
- Grigio-Verde – priorità 4 (medio-bassa)
- Verde scuro – priorità 5 (bassa)
Come ultimo passo – ma non per questo meno importante – l’assessment si deve concludere con l’indicazione di una serie di azioni di rimedio (Remediation Plan) che, grazie ai passaggi precedenti, devono essere contestualizzate e prioritizzate, in base allo specifico contesto di business dell’azienda stessa.
Attenzione! Il risultato dell’assessment va inteso come il risultato di un’analisi puntuale, condotta in un ben determinato momento temporale. Le azioni di rimedio consigliate alla termine dell’assessment consentono all’azienda di migliorare la propria postura rispetto alle aree di rischio esaminate, ma anch’esse devono essere inquadrate come riferite al preciso momento temporale in cui l’assessment è stato condotto. Successive modificazioni in termini di architetture IT, aggiornamento dei sistemi IT, carichi di lavoro, interdipendenze applicative, ecc. potrebbero anche modificare le risultanze dell’assessment stesso. Questo però non riduce affatto l’importanza delle azioni di rimedio precedentemente consigliate ed eventualmente già adottate, le quali, in ogni caso, contribuiscono a colmare lacune importanti nella gestione dei sistemi informativi dell’azienda.
Vantaggi per l’azienda
La finalità di un tale assessment è quella di aiutare le aziende nel processo di mitigazione dei rischi IT, prevedendo le conseguenze di un degrado o di un’interruzione dell’operatività dei sistemi, ed è, quindi, indispensabile al fine di erogare in maniera efficace ed efficiente i diversi servizi aziendali supportati dalle risorse IT, cercando di minimizzare il possibile danno per gli utilizzatori del servizio (interni e/o esterni all’azienda).
Come già detto in precedenza, l’adozione della modalità di analisi in esame, a discapito di quelle più accademiche e strutturate, risponde a ragioni di convenienza temporale, economica, ma anche a ragioni pratiche.
Infatti, seguendo tale approccio è possibile ricondurre l’identificazione dei rischi e delle conseguenti azioni di rimedio, alle errate posture tecnologiche-applicative da cui esse derivano.
In altre parole, tale approccio consente di identificare con maggiore facilità e chiarezza le carenze tecnologiche, applicative ed organizzative, in modo da definire più precisamente le conseguenti azioni di rimedio consigliate, ma anche – e soprattutto – le relative priorità di intervento. Quest’ultimo aspetto è di importanza cruciale dato che non è ragionevole pensare che tutte le azioni di rimedio suggerite nel Remediation Plan possano essere implementate immediatamente.
Inoltre, queste modalità facilitano la comprensione da parte dell’azienda delle ragioni di business che stanno alla base delle azioni tecniche di rimedio consigliate e delle relative priorità ad esse associate.
Un’ulteriore possibile ricaduta positiva di una tale metodica è quella di aiutare l’organizzazione aziendale a fare proprio un atteggiamento consapevole e proattivo rispetto a queste tematiche, che sono di grande impatto per gli obiettivi di business, economici-finanziari, reputazionali, nonché per quelli normativi e contrattuali.
Conclusione
Il risultato che l’azienda può conseguire con il IT Risk Assessment sono quindi molteplici:
-
- Condurre un’analisi dettagliata, indipendente e completa sulle eventuali errate posture e vulnerabilità presenti nell’attuale gestione dei sistemi informativi;
- ricondurre tali problematiche tecnico-applicative al loro effettivo impatto sulle attività di business dell’azienda;
- attribuire a tali impatti un valore di gravità più o meno elevata, aiutando così l’azienda a definire un livello di urgenza degli interventi, tarandoli sulle specifiche necessità aziendali.
A lato dei risultati specifici di cui sopra, esistono però anche altri risultati meno tangibili, ma non per questo meno importanti, che possono essere raggiunti:
-
- La creazione di una nuova consapevolezza aziendale (soprattutto da parte dell’imprenditore e del top management) relativamente alle problematiche di gestione del rischio IT;
- una valutazione dei rischi IT che non sia meramente tecnologica-applicativa (tipica delle figure più tecniche), ma che sia maggiormente business-oriented e quindi più facilmente presentabile e comprensibile anche da parte delle diverse linee di business e dal top management;
- un atteggiamento proattivo per la gestione del rischio, cosa che potrebbe anche portare, in un secondo momento, all’implementazione di politiche continuative di monitoraggio e gestione del rischio finalizzate alla prevenzione di possibili rischi, ma anche ad un efficace e tempestivo rispetto di obblighi di compliance, fattore che sempre più frequentemente rappresenta un significativo vantaggio competitivo.
1 Secondo il framework per la gestione integrata del rischio aziendale, pubblicata nel 2004 dal Committee of Sponsoring Organizations (COSO), l’Enterprise Risk Management (ERM), si può definire come “un processo (continuo e trasversale all’organizzazione), governato dal top management dell’azienda, che ha l’obiettivo di definire la strategia a tutti i livelli dell’azienda, per al fine di identificare i potenziali eventi che possono avere un impatto sull’organizzazione e gestire il rischio, compatibilmente con il proprio livello di propensione al rischio, nonché a e fornire ragionevoli garanzie in relazione al conseguimento degli obiettivi aziendali”.
2 Secondo l’IT Governance Institute il governo dei sistemi informativi (IT Governance) è responsabilità del Board e dell’altao direzione e può essere definito come “parte integrante della Corporate Governance e si concretizza grazie alla presenza di meccanismi decisionali, strutture organizzative e processi, che assicurano che l’IT sia in grado di supportare ed eventualmente estendere obiettivi e strategie aziendali”.
3 Questo approccio suggerisce di partire da un’analisi per processi, che parte degli obiettivi di business, per poi ricondurli ad esigenze di processi specificatamente riconducibili al perimetro delle responsabilità IT. Secondo alcune metodologie top-down, ampiamente diffuse si deve quindi partire dall’’identificazione dei rischi correlati agli obiettivi aziendali (Enterprise Goals), per poi risalire agli obiettivi IT (Alignment Goals) e da questi, ai processi IT (Governance and Management Objectives) e alle relative Management (Best) Practices.
4 LA Business Impact Analysis (BIA) è “il processo di analisi delle attività dell’azienda e degli effetti che un’’interruzione potrebbe avere su di esse. Consente di stabilire le priorità per il recupero dei processi critici mediante la definizione del Maximum Tolerable Period of Disruption (MTPD). La correlata ‘Analisi delle Minacce (Risk Assessment), invece, promuove la comprensione dei rischi relativi ai processi critici, delle loro dipendenze e delle potenziali conseguenze in caso di interruzione. Queste attività costituiscono la base su cui vengono definiti – in fase di progettazione – i Recovery Time Objective (RTO) e i Recovery Point Objective (RPO), e su cui vengono selezionate le strategie e le tattiche di continuità operativa e le misure di mitigazione delle minacce” (- da Wikipedia, https://it.wikipedia.org/wiki/Gestione_della_continuit%C3%A0_operativa
5 Il ’MTPD (Maximum Tolerable Period of Disruption) rappresenta il massimo periodo di indisponibilità che un servizio si può permettere, prima che la situazione diventi critica o irrecuperabile.
6 Il Recovery Time Objective (RTO) è il tempo necessario per il pieno recupero dell’operatività di un sistema o di un processo organizzativo. È in pratica la massima durata, prevista o tollerata, del downtime occorso.
7 Il Recovery Point Objective (RPO) è uno dei parametri usati nell’ambito delle politiche di disaster recovery per descrivere la tolleranza ai guasti di un sistema informatico. Esso rappresenta la quantità di dati prodotti ma non ancora sincronizzati, in caso di incidente o disastro, su un archivio (storage o file) di sicurezza. Indica quindi il massimo tempo che deve intercorrere tra la generazione di un’informazione e la sua messa in sicurezza (ad esempio attraverso backup) e, conseguentemente, fornisce la misura della massima quantità di dati che il sistema potrebbe perdere a causa di guasto improvviso.