Molte organizzazioni dispongono di un registro dei rischi formalmente corretto, ma raramente di un controllo solido nella gestione quotidiana. Nella pratica non conta il numero di rischi documentati, ma se i responsabili riconoscono precocemente dove il rischio si sta effettivamente accumulando e se le misure sono efficaci. Proprio qui interviene la governance del rischio basata sui KPI: essa traduce rischi astratti in poche metriche misurate in modo coerente, comparabili tra team, sistemi e fornitori – e che sfociano in decisioni su budget, priorità, eccezioni ed escalation.
Il punto critico: i KPI (Key Performance Indicators) misurano prestazione e attuazione, i KRI (Key Risk Indicators) misurano l’esposizione al rischio. In molti report vengono confusi. Questo porta a cruscotti apparentemente «verdi», pur restando l’azienda di fatto vulnerabile (per esempio buona percentuale di patch complessiva, ma elevata vulnerabilità nei sistemi esposti a internet). Questo contributo mostra quali metriche si sono dimostrate valide per i rischi IT, come definirle, quali fonti dati sono tipicamente necessarie e come impostare la governance in modo che audit e realtà operativa coincidano.
Perché le metriche nella governance del rischio spesso falliscono
I modelli di errore tipici sono sorprendentemente costanti – indipendentemente dal settore o dagli strumenti:
- Troppe metriche: i team riportano 30–60 valori, ma nessuno riesce a derivarne decisioni. Conseguenza: il reporting diventa un adempimento formale, non uno strumento di governo.
- Definizioni incoerenti: „kritische Systeme“, „Patch‑Stand“ oder „Incident“ significano cose diverse in esercizio, security e audit. Questo rende inutilizzabili i trend.
- Nessun collegamento con le responsabilità: senza una chiara logica RACI (Responsible, Accountable, Consulted, Informed) rimane incerto chi debba agire – e chi sopporta il rischio.
- Metriche senza igiene dei dati: se inventario degli asset e identità non sono corretti, le metriche diventano una falsa precisione. Le richieste dell’audit non possono poi essere soddisfatte.
- Nessuna soglia e percorsi di escalation: un valore „rosso“ senza una decisione conseguente definita genera solo discussione, non riduzione del rischio.
Una logica KPI solida è meno una questione di cruscotto che di governance: definizioni, fonti dati, soglie, catalogo delle misure, procedure di eccezione e evidenze per l’audit devono essere coerenti.
Governance del rischio basata sui KPI: modello di base, ruoli e logica decisionale
Per i rischi IT si è dimostrato efficace un modello a tre livelli, facilmente tracciabile anche negli audit:
1) Esposizione al rischio (KRIs): «Quanto è grande il rischio in questo momento?»
I KRIs mostrano la superficie di attacco o di guasto attuale, ad es. vulnerabilità critiche non patchate in sistemi produttivi esposti a internet. Sono indicatori anticipatori, perché aumentano prima degli Incidents.
2) Efficacia dei controlli (Control KPIs): „I nostri controlli funzionano?“
Esempi sono la copertura MFA, test di RESTore riusciti o il tasso di successo delle modifiche. Questi KPIs mostrano se i controlli di governance operano effettivamente in esercizio.
3) Indicatori di risultato (Outcome KPIs): „Quali danni/interruzioni si verificano?“
Esempi sono tempi di inattività non pianificati, incidenti di sicurezza con esfiltrazione di dati o costi derivanti da misure di emergenza. Questi indicatori sono importanti, ma spesso arrivano troppo tardi per guidare l’operato.
Importante è l’assegnazione dei ruoli: Accountable è tipicamente un Service‑Owner o System‑Owner (per il rischio nel rispettivo scope), Responsible sono le funzioni di esercizio/Security, e Consulted/Informed sono Compliance, protezione dei dati, acquisti e direzione. Senza questa assegnazione i KPIs diventano „numeri di sicurezza“ che, pur essendo corretti dal punto di vista tecnico, rimangono inefficaci a livello organizzativo.
Principi di selezione: quali metriche servono realmente ai manager
Se è possibile selezionare solo poche metriche, queste dovrebbero soddisfare quattro criteri:
- Capacità decisionale: il valore deve poter innescare un’azione concreta (priorizzare, approvare, fermare, esentare, escalationare).
- Confrontabilità: il valore deve essere coerente nel tempo e tra unità (team/servizi/sedi).
- Resistenza alla manipolazione: la metrica non dovrebbe essere „reportabile in verde“ spostando definizioni o chiudendo ticket senza ridurre il rischio.
- Evidenza di audit: fonte dati, metodo di determinazione, responsabilità e prova devono essere riproducibili.
Praticamente significa: è preferibile avere 10–15 metriche core con soglie chiare e logica di intervento piuttosto che un set KPI ingestibile. Metriche di dettaglio aggiuntive possono esistere a livello operativo, ma non appartengono al livello decisionale del management.
Metriche chiave per i rischi IT (con definizioni, soglie e tipiche fonti dati)
Di seguito un set pratico di metriche che può servire come template e essere adattato per azienda in base a criticità, requisiti regolamentari e architettura (On‑Prem, Cloud, Hybrid).
1) Copertura degli Asset: quanto completa è la nostra visibilità?
Perché rilevante: senza un inventario affidabile degli asset (endpoint, server, risorse cloud, applicazioni, interfacce) tutti i KPIs successivi sono insicuri. Negli audit questo è spesso il primo punto di attacco.
- KPI: grado di copertura degli Asset gestiti = (Assets nell’inventario/CMDB con Owner + criticità + stato del Lifecycle) / (tutti gli Assets rilevati)
- Soglie: obiettivi di management per scope (es. produzione/internet) più stringenti rispetto alle reti di laboratorio
- Fonti dati: CMDB, discovery scanner, inventario asset cloud, MDM/EDR, inventario di rete
Nota di governance: Definire in modo univoco „Asset“ e „Owner“. Per software aziendale e soluzioni software vicine ai processi il Service‑Owner (funzionale/operativo) è nella maggior parte dei casi più appropriato rispetto a un mero host‑owner tecnico.
2) Copertura della criticità: dove manca il contesto di business?
KPI: Percentuale di asset/service con criticità classificata (ad es. per disponibilità, riservatezza, integrità) e categoria dei dati (dati personali, riservati, pubblici)
Perché è rilevante: I terminI per le patch, la densità del monitoring e le barriere al change devono dipendere dalla criticità, altrimenti si genera sovraccarico operativo o volo al buio.
3) Patch‑Compliance come KRI: rischio derivante dai ritardi in zone critiche
Importante: „Patch‑Compliance“ è rilevante ai fini del rischio solo se viene segmentata (ad es. sistemi esposti a Internet, sistemi privilegiati, OT/produzione, database strategici).
- KRI: Percentuale di sistemi con aggiornamenti di sicurezza scaduti nelle classi di criticità definite (p.es. > 14/30/60 giorni oltre lo SLA)
- KPI supplementare: Tempo mediano fino alla patch (MTTP: Mean Time To Patch) per aggiornamenti critici
- Fonti dati: Patch‑Management, Configuration Management, Vulnerability‑Scanner, pipeline di immagini cloud
Logica delle soglie: Definire per zona valori limite stringenti e una procedura formale di eccezione. „Kann aktuell nicht gepatcht werden“ è una decisione con accettazione del rischio – non uno stato.
4) Vulnerabilità: vulnerabilità critiche esposte (Exploit‑Risk)
I conteggi di vulnerabilità senza contesto sono inutili. Determinante è la combinazione di gravità, sfruttabilità ed esposizione.
- KRI: Numero/percentuale di „critic, sfruttabili“ vulnerabilità in sistemi di produzione accessibili esternamente
- Opzionale: Percentuale di finding con piano di remediation definito e Owner
- Fonti dati: Vulnerability‑Scanner, EDR, inventario WAF/Ingress, Cloud‑Security‑Scanner
Prospettiva di audit: Documentare come viene operationalizzato il concetto di „sfruttabile“ (ad es. Known Exploited Vulnerabilities, avvisi di exploit, threat‑intel‑flags). Senza definizione diventa una questione di opinione nell’audit.
5) Sicurezza di identità e accessi: copertura MFA e Privileged Access
Molti attacchi riusciti sono guidati dall’identità. Per questo le metriche IAM (Identity and Access Management) devono far parte della governance del rischio.
- KPI: Copertura MFA per account privilegiati e accessi remoti (account amministrativi, VPN, console cloud, O365/Workspace)
- KRI: Numero di account privilegiati senza un Owner rintracciabile o senza ricertificazione regolare
- KPI: Tempo fino al deprovisioning (offboarding) per ruoli critici
- Fonti dati: IAM/IdP, PAM (Privileged Access Management), sistema HR, ticketing
Decisione di governance: Definire quali ruoli sono „privilegiati“ (admin locali, DB‑admin, Cloud‑Owner, CI/CD‑admin, Backup‑admin). Questa lista è un artefatto di audit e deve essere versionata.
6) Logging e Detection: copertura, qualità, capacità di reazione
„Abbiamo un SIEM“ non è una metrica. Misurabile è se le fonti rilevanti sono collegate e se gli allarmi portano a decisioni.
- KPI: Copertura delle fonti di log nei servizi critici (autenticazione, azioni amministrative, accessi ai dati, egress di rete)
- KPI: MTTD/MTTA (Mean Time To Detect/Acknowledge) per allarmi di sicurezza di gravità definita
- KRI: Percentuale di allarmi senza triage entro lo SLA o con causa ricorrente senza azione correttiva
- Datenquellen: SIEM, EDR, IdP‑Logs, Cloud‑Audit‑Logs, Ticketing/IR‑Plattform
Conseguenze operative: Un alto numero di allarmi non è automaticamente negativo; il problema è quando gli allarmi non vengono gestiti o non si realizza una risoluzione durevole delle cause.
7) Rischio Backup e Recovery: tasso di test, rispetto di RPO/RTO
Il successo del backup da solo non è una rete di sicurezza. Determinante è se il ripristino funziona in condizioni reali.
- KPI: Percentuale di sistemi critici con test di ripristino regolare (secondo piano, con protocollo)
- KPI: Conformità a RPO/RTO (Recovery Point/Time Objective) nei test e negli eventi reali
- KRI: Numero di job di backup con errori ricorrenti o senza crittografia verificata/immutabilità (backup immutabile)
- Datenquellen: sistema di backup, runbook di test, protocolli di emergenza, monitoraggio
Evidenza di audit: I protocolli dei test di ripristino sono una solida forma di prova. Importante: ambito, stato dei dati, durata, deviazioni, approvazione da parte del proprietario.
8) Rischio di Change: le modifiche come principale fattore di interruzioni
Il Change‑Management è una leva di rischio, non solo un processo ITIL. Per soluzioni aziendali digitali con numerose interfacce ciò è particolarmente rilevante.
- KPI: Change‑Failure‑Rate (percentuale di change con rollback/incident entro un periodo definito)
- KPI: Percentuale di change con controllo completo del rischio (impact, backout‑plan, evidenza dei test, security‑review per classi rilevanti)
- KRI: Percentuale di “Emergency Changes” senza valutazione successiva e analisi delle cause
- Datenquellen: ITSM, deployment‑logs, monitoring, post‑incident‑reviews
Prassi di governance: Definite le classi di change (standard/normal/emergency) e associate a ciascuna requisiti minimi e obblighi di evidenza. Questo riduce le discussioni caso per caso.
9) Maturità Incident‑Response: velocità, qualità, apprendimento
Gli outcome‑KPI (numero di incident) dipendono fortemente dalla capacità di rilevamento. La maturità si misura nei tempi di reazione e nella capacità di imparare dagli eventi.
- KPI: MTTR (Mean Time To RESTore) per interruzioni di servizio definite
- KPI: Percentuale di security‑incidents con analisi completa della root‑cause e tracciamento delle azioni
- KRI: Tasso di ricorrenza delle stesse classi di incident (indica mancanza di prevenzione)
- Datenquellen: ITSM/IR‑Tool, postmortem, problem‑management
10) Rischio fornitori e catena di fornitura: governabilità invece che sensazione
Il Third‑Party‑Risk è spesso l’area in cui la governance esiste formalmente ma non viene seguita operativamente.
- KRI: Percentuale di fornitori critici senza valutazione di sicurezza aggiornata, senza clausole contrattuali su segnalazione incident/SLAs o senza piano di exit
- KPI: Tempo per chiudere i finding identificati dei fornitori
- Datenquellen: gestione fornitori, dati contrattuali, report di audit, ticketing
Prospettiva di audit: Importante non è tanto uno “score” quanto la tracciabilità: classificazione, requisiti minimi, deviazioni, accettazione del rischio, follow‑up.
Modello: scheda KPI (definizione, responsabile, soglie, evidenza)
Affinché gli indicatori non diventino fonte di interpretazioni divergenti, ogni metrica di management necessita di una scheda identificativa. La seguente struttura è adatta per gli audit:
- Nome e scopo (quale decisione viene supportata?)
- Ambito (quali sistemi/servizi, quali zone, quali finestre temporali)
- Definizione/Formula (incl. filtri dati, eccezioni, arrotondamento)
- Owner (Accountable) e responsabili dei dati (Responsible)
- Soglie (verde/giallo/rosso) e percorso di escalation
- Catalogo delle misure (cosa è obbligatorio in caso di giallo/rosso?)
- Evidenza (quali log/report sono prova, dove vengono archiviati, per quanto tempo)
- Ciclo di revisione (mensile/trimestrale, oltre a revisione ad evento dopo un incidente grave)
Scheda KPI (modello breve)
KPI-Name:
Obiettivo/Decisione:
Scope (Servizi/Zone):
Definizione/Formula:
Fonti dati (sistemi, report):
Qualità dati/Validazione:
Owner (Accountable):
Gestione (Responsible):
Soglie (G/Y/R):
Escalation (organo, termine):
Misure obbligatorie in caso di giallo:
Misure obbligatorie in caso di rosso:
Evidenza (archiviazione, retention):
Ciclo di revisione:
Ultima modifica/Versione:Dagli indicatori alle decisioni: soglie, eccezioni, accettazione del rischio
Gli indicatori diventano gestibili ai fini di governance solo quando è chiaro quale decisione prendere in corrispondenza di un determinato valore. Questo può essere operationalizzato con tre elementi:
Le soglie devono essere legate alla criticità
Un Patch‑SLA di 30 giorni può essere adeguato per sistemi backoffice interni, ma spesso è troppo lungo per interfacce amministrative esposte a Internet. Definite soglie per ciascuna classe di criticità, non come soluzione unica per tutti.
Le eccezioni richiedono una scadenza e misure compensative
Se un sistema non è aggiornabile (legacy, vincoli del fornitore, finestre di produzione), l’eccezione necessita di:
- Motivazione del rischio e approvazione del Business‑Owner (Accountable)
- Data di termine (es. 60/90 giorni) o piano di migrazione
- Controlli compensativi (es. segmentazione di rete, rilevazione aggiuntiva, accesso solo tramite jump‑host)
- Obbligo di prova (evidenza, chi ha autorizzato)
L’accettazione del rischio è una decisione, non uno stato
Nella pratica i rischi scompaiono nelle colonne „Accettato“ senza che sia chiaro chi sostiene quale rischio residuo. Stabilite un formato in cui l’accettazione del rischio sia documentata esplicitamente (ambito, periodo, rischio residuo, responsabile). Questo riduce i rischi „silenziosi“ che possono poi evolvere in escalation durante un incidente.
Prontezza all’audit: cosa i verificatori tipicamente chiedono sulla governance dei KPI
Indipendentemente dal fatto che vi allineiate a ISO‑27001, al BSI‑Grundschutz, a requisiti vicini a NIS2 o a sistemi di controllo interni: i revisori pongono spesso le stesse domande. Una Governance del rischio basata su KPI può essere molto efficace in questo contesto — se è documentata in modo accurato.
1) Tracciabilità della catena dei dati
Da dove proviene il valore, come viene generato e è riproducibile? Se consolidate dati provenienti da più strumenti, documentate la logica di trasformazione (anche se si tratta solo di un job di reporting).
2) Completezza e ambito
Quali sistemi sono inclusi, quali no — e perché? Un ambito definito in modo consapevole è auditabile; un ambito casuale sembra una lacuna di controllo.
3) Evidenza delle misure
“Abbiamo dato priorità” non basta. I revisori vogliono vedere che in caso di superamento delle soglie sono state prese decisioni (ticket, autorizzazioni di change, deroghe, verbali dei comitati).
4) Verifica periodica dell’efficacia
I KPI devono essere rivisti e adattati in caso di cambiamenti architetturali (migrazione al cloud, nuova piattaforma IAM, nuova business‑software). Senza un verbale di review il set di KPI appare rapidamente obsoleto.
Prospettiva sui costi e sulle capacità: indicatori come strumento per budget e prioritizzazione
La governance del rischio spesso non fallisce per mancanza di volontà, ma per risorse. Buoni indicatori aiutano a usare la capacità dove hanno il maggior effetto sul rischio. Tre pattern pratici:
- Backlog basato sul rischio: le misure sono prioritarie non per volume, ma per contributo al KRI (es. riduzione delle “vulnerabilità criticamente sfruttabili nei sistemi esposti”).
- Controlli minimi finanziabili: per ogni classe di criticità definite standard minimi (MFA, logging, test di backup). Tutto ciò che supera questi standard viene gestito come progetto con business case.
- Debito tecnico trasparente: se i sistemi legacy generano costantemente eccezioni, diventa una decisione di management: modernizzazione, sostituzione o accettazione del rischio residuo. Gli indicatori forniscono la giustificazione.
È importante che i KPI non vengano introdotti come “strumento punitivo”. Altrimenti i team ottimizzano per i numeri anziché per il rischio (per esempio riducendo l’ambito). La governance deve quindi tutelare sempre l’integrità dei dati e gli incentivi corretti.
Piano di implementazione in 6 settimane: da zero a una KPI‑Governance affidabile
Se oggi avete un reporting frammentato, è cruciale un avvio snello e realistico. Un piano tipico:
Settimana 1: definire ambito e decisioni sul rischio
- Definire classi di criticità (servizi/applicazioni, non solo server)
- Stabilire il comitato di gestione (es. Security‑/Risk‑Board) e i tipi di decisione
- Selezionare le top‑10 rischi che possono essere gestiti tramite indicatori
Settimana 2: selezionare il set di KPI e redigere le schede
- 10–15 indicatori (KRIs + Control KPIs + pochi outcome)
- Per ogni indicatore: scheda, owner, soglie, logica delle misure
Settimana 3: collegare le sorgenti dati e verificare la qualità dei dati
- Confrontare inventario asset/CMDB con discovery/inventario cloud
- Verificare le definizioni (es. “esposto”, “critico”, “in ritardo”)
Settimana 4: standardizzare reporting e archivio delle evidenze
- Formato di reporting uniforme (mensile) incl. trend e stato delle azioni
- Luogo di archiviazione per le evidenze (verbali, eccezioni, rapporti di test) con periodo di retention
Settimana 5: condurre un comitato pilota e esercitare i percorsi di escalation
- Simulare 2–3 casi reali basandosi sulle soglie
- Testare il processo di deroga e le approvazioni
Settimana 6: Stabilizzare e trasferire al regime operativo
- Adeguare le definizioni, eliminare i rischi di ‚gaming‘
- Documentare il RACI in modo chiaro, informare i responsabili
- Stabilire il ciclo di revisione e i trigger di change per le modifiche dei KPI
Checkliste für Manager: KPI‑Governance, die im Betrieb funktioniert
- KRIs e KPIs sono chiaramente separati (rischio vs. performance)?
- Per ogni indicatore esiste un Owner (Accountable) con mandato decisionale?
- I limiti sono collegati a criticità ed esposizione?
- Esiste una procedura formale di deroga con data di scadenza e compensazione?
- La catena dei dati è documentata e auditabile (origine, determinazione, evidenza)?
- Esiste una routine di governance definita (agenda, verbale, monitoraggio delle azioni)?
- Le lezioni apprese dagli incidenti vengono ricondotte ai limiti/controlli?
Conclusione: pochi indicatori, decisioni chiare, prove documentali solide
La governance del rischio basata sui KPI non è un progetto di reporting, ma un meccanismo di controllo: collega la realtà tecnica (asset, vulnerabilità, identità, modifiche) con le decisioni di management (priorità, budget, deroghe, accettazione del rischio). Il beneficio maggiore si ottiene quando non si ‚misura tutto‘, ma si definiscono pochi indicatori rigorosi, collegati alla criticità e che, in caso di superamento dei limiti, attivano conseguenze vincolanti. Solo così il rischio non viene solo documentato, ma effettivamente gestito — in esercizio, nei progetti e in sede di audit.
Per questo tema sono importanti anche la gestione del rischio IT e la governance IT. L’articolo inquadra questi aspetti in modo comprensibile e mostra a cosa prestare attenzione nella quotidianità.