Monitorare gli ICT Risk con indicatori KRI efficaciArticolo a cura di Alessandro Salibra Bove, Partner
- 18 Ottobre, 2023
Gestione e monitoraggio dei rischi tecnologici
- Identificare e monitorare i rischi informatici
- Quali requisiti normativi rispettare
- ICT Risk Management vs Information Security
- Le sfide che attendono i Risk Managers
Indicatori di rischio per ICT Risk
- Identificare e monitorare i rischi informatici
- Quali requisiti normativi rispettare
- ICT Risk Management vs Information Security
- Le sfide che attendono i Risk Managers
A cosa servono i KRI?
Una volta che i rischi ai quali la nostra organizzazione è sottoposta sono stati individuati e valutati, quelli potenzialmente più impattanti – i rischi chiave o key risk – hanno bisogno di essere monitorati regolarmente.
I rischi chiave potrebbero accrescersi fino a manifestare i propri effetti senza che nessuno all’interno dell’organizzazione possa predisporre per tempo le opportune misure di mitigazione. È per questo motivo che sono necessari degli indicatori per i rischi chiave, ovvero i Key Risk Indicator (KRI).
I KRI sono dei segnali che ci allertano sul possibile accrescimento dei rischi chiave che abbiamo scelto di monitorare, per consentirci di verificare tempestivamente le cause ed eventualmente intervenire.
Per descrivere i KRI con un esempio, assumiamo di aver valutato in precedenza che un rischio chiave per la nostra organizzazione consiste nell’abuso dei privilegi utente (es. utilizzo di utenze con privilegi di gestione di sistemi o dati per accedere indebitamente alle informazioni dei clienti su un determinato applicativo).
Quale potrebbe essere un KRI utile a segnalarci un possibile accrescimento di questo rischio? Ad esempio, il rapporto tra il numero assoluto delle utenze abilitate e quello dei dipendenti. Se il numero delle utenze supera in misura significativa quello dei dipendenti, c’è la possibilità che siano state abilitate numerose utenze “di servizio” per la gestione di sistemi o dati, magari non nominative e date in uso anche a tecnici esterni. Il proliferare non gestito di questa tipologia di utenze può comportare l’accrescimento del rischio di abuso dei privilegi utente.
Non esiste, naturalmente, un valore corretto per questo KRI come per gli altri. Se un KRI debba o meno generare un segnale di allerta al superamento di una certa soglia deve essere stabilito di caso in caso mediante osservazione dei valori storici, rilevazione di scostamenti significativi e/o comparazione con valori di riferimento tecnici o normativi.
È utile considerare, inoltre, che quando si sceglie di sottoporre a monitoraggio un determinato KRI è perché ci si attende una correlazione significativa tra l’andamento dell’indicatore e l’effettiva variazione del rischio osservato.
Detto questo, è sempre necessario verificare le cause che portano a variazioni rilevanti degli indicatori e ad eventuali segnali di allarme, poiché potrebbero non essere necessariamente connesse al rischio osservato (seguendo l’esempio precedente, potrebbero essere state abilitate numerose utenze per un gruppo di lavoro formato da consulenti esterni).
I KRI hanno come obiettivo ultimo la segnalazione di un possibile pericolo – riferendosi ai rischi – e non necessariamente del verificarsi di un evento avverso.
Perché i KRI sono importanti nella gestione dei rischi ICT?
Il monitoraggio dei rischi complessivamente considerati è un elemento imprescindibile della più generale gestione del rischio d’impresa (enterprise risk management).
In questo contesto, il monitoraggio dei rischi connessi all’utilizzo delle tecnologie dell’informazione e della comunicazione (ICT risk) riveste un ruolo di importanza crescente, in quanto:
- la digitalizzazione dei mercati è un fenomeno in costante crescita che ha consentito lo sviluppo di nuovi servizi e modelli di business, oltre a migliorare l’offerta dei servizi tradizionali. In questo contesto, un adeguato governo dell’ICT è un fattore strategico per larga parte delle imprese;
- i sistemi informatici aziendali sono diventati sempre più complessi a causa dell’evoluzione delle tecnologie, dei processi e delle competenze richieste per la loro gestione e per la numerosità dei fornitori ICT coinvolti (cloud service provider, system integrator, software vendor, ecc.);
- le minacce alla sicurezza informatica delle aziende sono in aumento sia per numerosità che per grado di sofisticazione. A rafforzare questa tendenza ha contribuito anche il diffondersi delle nuove modalità di lavoro da remoto;
- quale conseguenza delle evoluzioni descritte, i requisiti normativi in materia di gestione dei rischi ICT per gli operatori dei principali mercati si sono progressivamente ampliati e rafforzati.
Quale perimetro di rischio considerare?
Dato il contesto descritto in precedenza, qual è un possibile perimetro di rischi ICT da valutare ed eventualmente monitorare? E con quali KRI?
Per rispondere alla prima domanda può essere utile partire dalla categorizzazione dei rischi ICT definita nelle linee guida della European Banking Autority:
- IT security risk: ovvero i rischi che impattano sulla sicurezza di sistemi e dati aziendali
- IT availability & continuity risk: i rischi che vertono sulla disponibilità di dati e sistemi, sulla capacità di garantire la resilienza e la continuità operativa dell’organizzazione e sulla qualità ed efficacia dei test di continuità operativa
- IT data quality & integrity risk: i rischi che impattano sull’integrità e qualità dei dati e, conseguentemente, sulla relativa reportistica aziendale (l’informazione non è accurata, tempestiva e completa)
- IT change risk: i rischi connessi alle eventuali inefficienze nella gestione dei cambiamenti applicati agli asset IT aziendali (reti, sistemi, applicazioni di business) e che possono impattare sull’agilità nell’eseguire il cambiamento (es. il rischio che i cambiamenti vengano effettuati nei limiti di tempo e budget previsti)
- IT HR & outsourcing risk: gli specifici rischi che possono derivare da una inadeguata gestione delle risorse umane e dei rapporti con i terzi fornitori o da carenze nella sicurezza informatica di questi ultimi
Andando più in dettaglio, per verificare la completezza del perimetro dei rischi ICT da considerare è possibile approfondire il tema utilizzando differenti framework e standard a disposizione in materia.
Tra i vari, citiamo in questa sede COBIT – Control Objectives for Information Technologies di ISACA. Più in particolare, COBIT – Design guide contiene oltre 100 esempi di ICT risk suddivisi in differenti categorie. Per ciascuna categoria di rischio è inoltre presente un cross reference alle attività di controllo e ai possibili KRI per il monitoraggio.
Vediamo nel seguito alcuni esempi di KRI per categoria di ICT risk. I KRI vengono riportati a solo scopo esemplificativo; la loro effettiva applicabilità e significatività è funzione delle specifiche caratteristiche di ciascun sistema informativo aziendale.
Esempi KRI per categoria di ICT Risk
1 – IT security risk
- Numero di data breach rilevati ai fini della protezione dei dati personali
- Numero di infezioni malware rilevate sui dispositivi ICT in uso al personale
- Numero delle vulnerabilità rilevate nel vulnerability assessment periodico
2 – IT availability & continuity
- Numero di segnalazioni relative a interruzioni dei servizi ricevute dall’assistenza clienti e/o dal supporto utenti interno
- Percentuale di indisponibilità dei sistemi
- Tempo trascorso in sovraccarico dai sistemi server (CPU, RAM)
3 – IT data quality & integrity risk
- Numero delle utenze privilegiate abilitate sui sistemi applicativi in rapporto al numero totale delle utenze abilitate
- Numero delle richieste di modifica ai dati (c.d. forzature) inviate al sistema di supporto utenti interno
4 – IT change risk
- Numero dei test accettazione utente (UAT) non andati a buon fine sul totale in fase di rilascio delle modifiche applicative
- Numero delle segnalazioni di malfunzionamento delle applicazioni inviate al sistema di supporto utenti interno
- Numero di progetti IT in ritardo significativo o sospesi presenti nel portafoglio progetti aziendale (IT agility risk)
5 – IT HR & outsourcing risk
- Tempo medio di sostituzione di personale IT chiave a seguito di dimissioni/licenziamento
- Numero di rilievi con criticità rilevante negli IT audit report prodotti dagli ICT outsourcer
- Percentuale degli SLA non rispettati rispetto al totale di quelli previsti nei contratti con gli ICT outsourcer
Com’è evidente da questi esempi, le fonti informative dalle quali acquisire i dati necessari al monitoraggio degli indicatori sono molteplici: HR, procurement, IT, organizzazione, assistenza utenti, ecc.
Più in generale, è il perimetro delle tipologie di rischi e dei relativi KRI monitorati ad essere particolarmente ampio, specie se raffrontato con gli ambiti più specifici monitorati dal procurement (es. SLA outsourcer) e dall’information security (es. eventi di sicurezza).
ICT Risk Management e Information Security: sono la stessa cosa?
L’ICT Risk Management – intesa come funzione aziendale di controllo interno – ha finalità differenti e un ambito di intervento più generale rispetto alle attività svolte dalla Funzione di Information Security, seppure siano presenti alcune aree di sovrapposizione tra le due funzioni e sia necessaria la previsione di opportuni flussi informativi tra le stesse.
L’Information Security ha per obiettivo il presidio operativo della sicurezza delle informazioni – ovvero della loro, disponibilità, integrità e riservatezza – considerando minacce, eventi, presidi e vulnerabilità. Il tipico processo circolare dell’information security è il seguente[1]:
- identificare
- proteggere
- rilevare
- rispondere
- ripristinare
L’ICT Risk Management, invece, è volto alla più complessiva gestione di tutti quei rischi che possono derivare dall’uso delle tecnologie dell’informazione e della comunicazione (data quality, change, HR & outsourcing, oltre a security). Ciò attraverso la valutazione dei rischi ICT e relativi controlli, al fine di assicurare che vi sia allineamento con la complessiva propensione al rischio d’impresa (c.d. risk appetite).
Il presupposto è che l’impresa, in quanto tale, intenda assumere una quantità ponderabile di rischio. L’ICT risk è un rischio d’impresa al pari degli altri – strategico, operativo, di mercato, ecc. – e dunque anch’esso necessita di essere compreso e ponderato dal vertice aziendale affinché il governo dell’impresa sia efficace.
A tal fine, il processo circolare dell’ICT Risk Management è così composto[2]:
- individuare
- valutare
- gestire
- monitorare
- allineare
Semplificando, il focus dell’Information Security è proteggere le informazioni dalle minacce, quello dell’ICT Risk Management è assicurare l’allineamento con la propensione al rischio d’impresa.
In questo contesto, l’ICT Risk Management monitora – anche mediante KRI – l’Information Security sulla base delle informazioni prodotte da quest’ultima.
Per approfondire questi aspetti – e per verificare l’adeguatezza del proprio assetto organizzativo in merito – si fa rimando ai seguenti processi di riferimento (c.d. obiettivi di gestione) del framework COBIT.
Framework COBIT
Funzione
ICT Risk Management
Obiettivi di gestione COBIT
- EDM03—Ensured Risk Optimization
- APO12—Managed Risk
Information Security
- APO13—Managed Security
- DSS05—Managed Security Services
Quali sono i principali requisiti normativi in materia?
Tra i principali riferimenti normativi in materia di monitoraggio dei rischi informatici, è senz’altro opportuno annoverare il Regolamento DORA (Regolamento UE 2022/2554 – Digital Operational Resilience Act).
Il Regolamento – entrato in vigore a gennaio 2023 e avente gennaio 2025 come data ultima per adempiere – è rivolto ad una ampia platea di destinatari: banche, compagnie assicurative e loro intermediari, società di gestione, istituti di pagamento e di moneta elettronica, oltre che numerosi altri operatori del mercato dei servizi finanziari.
Il Regolamento prevede, innanzitutto, che la responsabilità della gestione dei rischi informatici venga attribuita a una Funzione di controllo che assicuri un adeguato livello di indipendenza (cfr. art. 6, comma 4). Questa previsione ci suggerisce – non essendo presenti ulteriori indicazioni esplicite in merito – che la funzione di gestione dei rischi informatici debba essere distinta da quella deputata a gestire operativamente la sicurezza informatica, secondo quanto già previsto dalle best practice descritte nel paragrafo precedente.
Successivamente, il regolamento prevede che la strategia di resilienza operativa digitale di cui i destinatari devono dotarsi comprenda anche degli indicatori di rischio chiave (KRI), quale elemento del più generale quadro per la gestione dei rischi informatici (cfr. art. 6, comma 8.c).
Un ulteriore importante riferimento normativo in merito è senz’altro rappresentato dal GDPR – General Data Protection Regulation (Regolamento UE 2016/679).
In questo caso la platea dei destinatari comprende tutti gli operatori economici e – ancorché la norma abbia specificatamente ad oggetto la protezione dei dati riferibili alle persone fisiche – il perimetro dei rischi informatici, che gli obbligati sono chiamati a gestire, è ampio.
Il Regolamento GDPR prevede – in termini più generali di quanto richiesto dal DORA – che le misure a presidio della sicurezza dei dati personali vengano predisposte anche in considerazione dei rischi che insistono su tali dati e sugli interessati (art. 32). Di qui l’opportunità – seppure implicita nel testo della norma – di provvedere ad un adeguato monitoraggio dei rischi in questo ambito.
Riportiamo nel seguito ulteriori importanti riferimenti normativi di settore in materia di gestione e monitoraggio dei rischi generalmente intesi:
- Banca d’Italia – Disposizioni di vigilanza per le banche (Circolare n. 285/2013)
- IVASS – Disposizioni in materia di sistema di governo societario (Regolamento n. 38/2018)
- Borsa Italiana – Codice di corporate governance
In particolare, le Disposizioni di vigilanza per le banche (1) e le richiamate Linee guida EBA sulla gestione dei rischi ICT prevedono una articolata disciplina riguardante sia la funzione di gestione dei rischi informatici, che le attività di monitoraggio degli stessi (Parte Prima, Titolo IV, Capitolo 4, Sezione II, Paragrafo 4 – La funzione di controllo dei rischi ICT e di sicurezza).
Quali sono le principali sfide?
Abbiamo detto dell’importanza dei KRI per un efficace monitoraggio dei rischi informatici, dell’ampiezza del perimetro in oggetto, del rapporto tra le Funzioni aziendali che si occupano di ICT Risk e Information Security, dei requisiti normativi in materia.
In questo quadro – già di per sé sfidante – è opportuno tener conto di alcuni altri elementi di carattere organizzativo e metodologico se si intende dare massima efficacia al processo di monitoraggio degli ICT risk per il tramite di indicatori KRI. Riportiamo nel seguito i principali.
Aspetti chiave per gestire KRI efficaci
1 – Copertura dei rischi chiave
L’auspicio di ciascuna azienda è che i propri rischi chiave – ovvero quelli molto rilevanti – siano sempre in numero contenuto. È per questi che occorre adottare Key Risk Indicator efficaci. È bene dunque partire dai rischi chiave e non, al contrario, dalla disponibilità di dati e indicatori per definire il proprio set di KRI.
2 – Significatività degli indicatori
Anche in questo caso, è bene partire dai rischi e dai relativi indicatori in base alla loro significatività, non dalla semplice disponibilità di dati e informazioni. Talvolta vengono considerati indicatori poco significativi per i rischi considerati e, per giunta, in numero elevato (es. indicatori rivenienti dal monitoraggio tecnico dell’infrastruttura hardware). Avere tanti indicatori poco significativi si traduce in un elevato “rumore di fondo” nel quale diventa più difficile percepire i segnali più importanti.
3 – Identificazione Data Owner
È necessario designare chiaramente un Data Owner per ciascun KRI, ovvero individuare il referente aziendale che deve produrre e certificare i dati per il calcolo dell’indicatore nei tempi stabiliti. Diventa dunque fondamentale facilitare al massimo il compito al Data Owner, attraverso l’adozione di procedure operative chiare, snelle e possibilmente automatizzate.
4 – Frequenza del monitoraggio
Maggiore è la frequenza di raccolta dati e calcolo KRI (es. trimestrale, mensile o maggiore), migliore è il supporto che si fornisce al processo di monitoraggio dei rischi, in quanto quest’ultimo è finalizzato all’adozione delle azioni di mitigazione necessarie. Una frequenza più lasca (es. semestrale o annuale) rischia di trasformare il monitoraggio in una attività a supporto del solo reporting direzionale.
5 – Processo di escalation
Affinché le azioni di mitigazione adottate a seguito del monitoraggio siano efficaci e tempestive, il c.d. processo di escalation che si attiva al superamento di una o più soglie di allerta dei KRI deve essere chiaramente definito: qual è il risk owner interessato? Come e da chi viene definita l’azione? Quali sono i flussi informativi di ritorno dal risk owner?
6 – Reporting efficace
Per poter rappresentare con efficacia gli esiti del monitoraggio KRI all’interno del reporting direzionale è importante poter aggregare le misurazioni dei KRI presenti nel nostro set secondo differenti dimensioni: categoria di rischio, area organizzativa, ambito di conformità, obiettivi aziendali. Per fare ciò è quindi necessario definire chiaramente dei criteri di standardizzazione delle metriche dei KRI che, per loro stessa natura, sono differenti tra loro (valori assoluti, percentuali, rapporti).
Dato il contesto descritto, l’opportunità di digitalizzare il processo di monitoraggio degli ICT Risk e dei relativi KRI può rappresentare un fattore critico di successo per le aziende e per le loro Funzioni di controllo. Minore sarà il tempo dedicato a raccogliere e consolidare dati in Excel provenienti da una pluralità di fonti, maggiore potrà essere l’attenzione dedicata all’analisi e al governo dei rischi.
RICHIEDI UN INCONTRO
Desideri avere maggiori informazioni o richiedere un incontro con i nostri consulenti?