Molte organizzazioni investono in sicurezza – e si accorgono, nei casi critici, che processi, responsabilità e riavvio non sono affidabili. La differenza raramente risiede in singoli strumenti, ma nel fatto che la cyber-resilienza venga gestita come un processo operativo controllabile. Proprio qui aiuta un set di KPI per la cyber-resilienza: rende prevenzione, rilevamento e ripristino misurabili, prioritizzabili e verificabili in audit.
Questo contributo fornisce un set di indicatori praticabile per la direzione IT, la compliance e i responsabili della sicurezza. L’attenzione non è rivolta ai „belli cruscotti“, ma a: quali indicatori mostrano una reale riduzione del rischio? Quali sorgenti dati sono realistiche? Come vengono definiti valori obiettivo e tolleranze? E come si evita che i KPI diventino un esercizio di reporting mentre le superfici d’attacco, le lacune nei log o l’incertezza sul ripristino continuano a crescere?
Che cosa significa concretamente la cyber-resilienza in azienda
La cyber-resilienza viene spesso equiparata alla „sicurezza“. In pratica è più ampia: la cyber-resilienza è la capacità di prevenire interruzioni causate da eventi informatici, di rilevarle precocemente, di contenerle efficacemente e di ripristinare il funzionamento aziendale in modo controllato. Ciò comprende tecnologia, processi e decisioni.
È importante la separazione in tre dimensioni di controllo:
- Prevenzione: riduce la probabilità di insorgenza e la superficie d’attacco (ad es. gestione delle patch e hardening delle identità).
- Rilevamento & reazione: riduce il tempo fino alla scoperta e stabilizza la gestione degli incidenti (ad es. copertura dei log, qualità degli allarmi, runbook).
- Ripristino: rende nuovamente disponibili sistemi e dati entro valori obiettivo definiti (ad es. RTO/RPO, test di RESTore, catene di riavvio).
Un set di KPI per la cyber-resilienza deve coprire queste tre dimensioni – e soddisfare sia segnali tecnici sia requisiti di governance e di evidenza (ad es. verificabilità negli audit, supporto decisionale al management, responsabilità chiare).
Perché un set di KPI è migliore di una singola „Resilienz-Kennzahl“
Un unico indicatore („Resilience Score“) appare attraente, ma nella gestione spesso è inutilizzabile. Appiattisce le differenze tra asset critici e non critici, mescola cause ed effetti ed è difficile da auditare. Un set di KPI funziona meglio se soddisfa tre caratteristiche:
- Riferimento ad asset e rischio: i servizi aziendali critici (ad es. ERP, controllo della produzione, piattaforma di identità) vengono considerati separatamente.
- Indicatori leading e lagging: indicatori precoci (ad es. backlog di patch, copertura delle sorgenti di log) più indicatori di risultato (ad es. MTTD, rispetto degli RTO).
- Attuabilità operativa: ogni indicatore ha una misura concreta, un responsabile (Owner), un metodo di misurazione e una soglia per l’escalation.
Per la compliance è inoltre rilevante: gli KPI devono funzionare come controllo continuo. Un audit non chiede solo „esiste un concetto?“, ma „viene applicato, misurato, corretto – e questo può essere dimostrato?“
Governance: Come ancorare gli KPI di cyber-resilienza nelle responsabilità e nei percorsi decisionali
Senza governance le metriche diventano rapidamente „security-theater“. Perché il set di KPI sia effettivo, serve una chiara assegnazione:
- Owner: Responsabile del raggiungimento degli obiettivi (tipico: CISO/IT-Security per prevenzione/rilevamento, IT operations per il ripristino, Service Owner per le priorità di business).
- Data Steward: Responsabile della qualità e della definizione dei dati (es. SIEM-Use-Cases, oggetti CMDB, catalogo backup).
- Entscheidungsgremium: Accetta le deviazioni, prioritizza le misure, autorizza budget/modifiche (es. comitato direttivo IT, Risk Committee).
Nella pratica si è dimostrato efficace un reporting su due livelli:
- Mensile operativo: trend, principali deviazioni, stato delle azioni per dominio (patch, identità, rilevamento, backup/recovery).
- Trimestrale per il management: dichiarazione del rischio in linguaggio di business, logica a semaforo per servizio critico, esigenze di investimento e decisione.
Importante per l’efficacia: definite regole decisionali, non solo valori obiettivo. Esempio: „Se i test RTO per un servizio critico non vengono superati per due cicli consecutivi, si valuta un change-freeze per feature non critiche e si prioritizzano risorse per l’irrobustimento del recovery.“
Il set di KPI per la cyber-resilienza: metriche chiave per prevenzione, rilevamento e ripristino
Le seguenti metriche sono state scelte in modo da essere realisticamente misurabili in molte IT aziendali. Non tutte le organizzazioni devono avviare tutti i KPI. Ciò che conta è che per ogni dimensione usiate almeno 3–5 metriche affidabili, che possano essere scomposte per servizi critici.
1) Prevenzione: superficie di attacco, identità, vulnerabilità, configurazione
KPI P1: Patch-Compliance für kritische Assets
Definizione: quota di sistemi critici (server, client, componenti di rete, piattaforme centrali) aggiornati entro scadenze definite con patch rilevanti per la sicurezza.
Perché conta: il patch-backlog è uno dei fattori che maggiormente facilita attacchi riusciti. I termini devono essere basati sul rischio (es. esposto a Internet vs. interno, criticità del servizio di business).
Evidence: report di patch, ticket di change, autorizzazioni di eccezione (Risk Acceptance) con data di scadenza.
KPI P2: Vulnerability Remediation SLA (per criticità)
Definizione: tempo tra „vulnerability identificata“ e „effettivamente risolta o mitigata“; segmentato per gravità (es. critica/alta) e classe di asset.
Nota: „mitigata“ deve essere dimostrabile tecnicamente (es. regola WAF, segmentazione di rete, disattivazione di una funzionalità) – non solo „accettata“.
Evidence: esportazione dallo scanner, ticketing, risultati dei retest.
KPI P3: Copertura MFA und Conditional-Access
Definizione: quota di accessi privilegiati e normali protetti tramite autenticazione multi-fattore (MFA) e regole contestuali (Conditional Access: dispositivo, posizione, rischio).
Perché conta: la gestione delle identità è spesso il percorso più rapido verso l’ambiente. Gli account privilegiati (admin, service accounts) devono essere considerati separatamente.
Evidence: policy dell’Identity Provider, eccezioni, account break-glass con controlli (es. conservazione separata, test periodici).
KPI P4: Conformità di hardening e configurazione (baseline)
Definition: Percentuale di sistemi che corrispondono a una baseline di sicurezza definita (p. es. protocolli legacy disattivati, cipher sicuri, diritti amministrativi locali limitati).
Warum es zählt: Molti incidenti nascono dal drift di configurazione. Le baseline riducono la varianza e aumentano la capacità di ripristino.
Evidenza: esportazioni di policy, scansioni di configurazione, report di drift.
KPI P5: Precisione dell’exposure-inventory (trasparenza di asset e servizi)
Definition: Percentuale di asset/servizi con assegnazione affidabile (proprietario, criticità, classe dei dati, dipendenze) nella CMDB/catalogo dei servizi.
Warum es zählt: Senza inventario le priorità vengono definite alla cieca. Questo indicatore è un „Enabler-KPI“ – debole all’inizio, ma decisivo per la governabilità.
Evidenza: report di qualità della CMDB, controlli a campione, confronto con Discovery/account cloud.
2) Rilevamento & risposta: visibilità, qualità del segnale, capacità di reazione
KPI D1: Copertura delle sorgenti di log per servizi critici
Definition: Percentuale delle sorgenti di log obbligatorie definite (p. es. Identity-Provider, EDR, firewall, VPN, server critici, SaaS-Audit-Logs) che effettivamente arrivano in modo centralizzato ed sono analizzabili (SIEM o piattaforma di log).
Warum es zählt: Un SIEM senza sorgenti complete dà una sicurezza apparente. „Arrivare“ significa: correttamente parsato, sincronizzato nel tempo, con retention sufficiente.
Evidenza: elenco delle fonti dati, stato di ingestione, configurazione della retention, eventi di test.
KPI D2: MTTD (Mean Time to Detect) per classi di incidenti rilevanti
Definition: Tempo medio dall’insorgenza di un evento di sicurezza alla sua rilevazione; segmentato per tipo di incidente (p. es. malware, abuso di credenziali, esfiltrazione di dati) e per fonte (EDR, SIEM, segnalazione utente).
Warum es zählt: Una MTTD più breve riduce i danni e abbassa i costi di ripristino. La segmentazione impedisce che un singolo incidente distorca l’indicatore.
Evidenza: timeline degli incidenti, cronologia degli allarmi, gestione dei casi.
KPI D3: Tasso di veri positivi / qualità degli allarmi
Definition: Percentuale di alert che dopo triage vengono confermati come effettivamente rilevanti (o chiusi come „benigni“/“false positive“).
Warum es zählt: Troppi falsi allarmi generano assuefazione, troppo pochi allarmi spesso indicano lacune. L’obiettivo è una qualità stabile, non „il maggior numero possibile di alert“.
Evidenza: ticket SOC, regole di classificazione, revisioni periodiche dei casi d’uso.
KPI D4: Prontezza di Incident Response (copertura dei runbook e grado di esercitazione)
Definition: Percentuale di scenari di incidente critici (p. es. ransomware, amministratore compromesso, perdita di token cloud) per i quali esistono runbook verificati, inclusi percorso di escalation, piano di comunicazione e checklist tecniche.
Ergänzung: Quota di esercitazione (tabletop o esercitazione tecnica) per trimestre/semestre.
Evidenza: runbook versionati, protocolli delle esercitazioni, lessons learned, backlog delle azioni.
KPI D5: Copertura EDR e stato di salute dei sensori
Definition: Percentuale di endpoint/server con sensore EDR attivo (Endpoint Detection & Response: rilevamento e risposta basati sul comportamento) e percentuale „healthy“ (aggiornato, non disabilitato, non offline).
Warum es zählt: Le lacune nell’EDR sono finestre tipiche di attacco. „Installato“ non basta; lo stato di salute è determinante.
Evidenza: console EDR, liste delle eccezioni, stato del deployment.
3) Ripristino: RTO/RPO, prova del RESTore, catene di riavvio
KPI R1: Conformità RTO per servizio critico
Definizione: quota di servizi che rispettano il loro Recovery Time Objective (RTO: tempo massimo di ripristino tollerabile) nei test o in incidenti reali.
Perché conta: RTO è il linguaggio di management per i costi di downtime. Costringe a considerare dipendenze (DNS, IAM, database, interfacce) e il „cosa prima“.
Evidenza: protocolli di RESTore/failover, timestamp, accettazione da parte del Service Owner.
KPI R2: Conformità RPO e attualità dei backup
Definizione: quota di servizi che raggiungono il loro Recovery Point Objective (RPO: perdita dati massima tollerabile); misurato come «età dell’ultimo backup consistente» più stato di validazione.
Importante: per i database contano i backup consistenti a livello applicativo (p. es. con log/snapshot) – non solo copie di file.
Evidenza: catalogo dei backup, stato dei log DB, validazione del RESTore.
KPI R3: Tasso di successo dei test di RESTore (incl. accesso & integrità)
Definizione: quota di test di RESTore pianificati che hanno successo, dove „successo“ non significa solo „dati ripristinati“, ma: il sistema si avvia, l’accesso funziona, l’integrità dei dati è verificata, le interfacce rilevanti sono raggiungibili.
Perché conta: molti backup in caso reale non sono utilizzabili (chiavi mancanti, permessi errati, dati incoerenti, dipendenze non documentate).
Evidenza: protocollo del test, passaggi di verifica, schermate/log come prova, tracciamento delle deviazioni.
KPI R4: Immutabilità/Protezione dei backup contro la manipolazione
Definizione: quota di set di backup critici protetti contro cancellazione/manipolazione (p. es. WORM/archiviazione immutabile, percorsi amministrativi separati, credenziali separate), inclusa la dimostrazione che le operazioni di cancellazione non sono banali.
Perché conta: i ransomware spesso mirano prima ai backup e agli strumenti amministrativi. La protezione dei backup è un nucleo di resilienza, non solo una „feature“ di storage.
Evidenza: policy di storage, ruoli IAM, log di audit, controlli simili a penetration/red-team (senza promesse esagerate).
KPI R5: Catena di ripristino testata (Dependency-Chain Coverage)
Definizione: quota di servizi critici per i quali la catena di dipendenze (identità, rete, dati, messaging, interfacce) è stata ripristinata in un test integrato.
Perché conta: singoli componenti possono essere „verdi“ mentre il servizio end-to-end non funziona. Questa metrica obbliga a pensare per servizi invece che per server.
Evidenza: documentazione dell’architettura/delle dipendenze, piano di test, protocollo dei risultati.
Valori obiettivo, soglie e tolleranze: così le metriche diventano controllo
I KPI senza valori obiettivo sono osservazione, non controllo. I valori obiettivo devono essere coerenti con la tolleranza al rischio dell’azienda e differenziati per servizio. In pratica funzionano tre livelli:
- Minimum (Obbligo): soglia minima oltre la quale un rischio deve essere formalmente accettato o affrontato immediatamente.
- Obiettivo (Piano): stato atteso in condizioni normali di risorse.
- Ambizione (Strategico): quadro obiettivo che giustifica investimenti (p. es. automazione, cambio di piattaforma).
Per compliance e audit è fondamentale che le deviazioni siano collegate a misure o all’accettazione del rischio. „Rosso“ senza conseguenze è un rischio per l’audit: indica mancanza di efficacia della governance.
Fonti dati e disegno delle misure: da dove provengono veramente i numeri?
Un errore comune: i KPI vengono definiti prima che sia chiaro se sono misurabili in modo affidabile. È preferibile un disegno di misurazione con fonti dati, responsabilità e regole di qualità. Fonti tipiche:
- Identity Provider (stato MFA, accesso condizionale, ruoli amministrativi, rischi di accesso)
- EDR/XDR (stato dei sensori, timeline di rilevamento, azioni di risposta)
- SIEM/Log-Plattform (ingestione, conservazione, copertura dei casi d’uso)
- Vulnerability Scanner (vulnerabilità rilevate, tempi di remediation, copertura degli asset)
- Patch-/Endpoint-Management (conformità, eccezioni)
- Backup/Recovery-Lösung (esito dei job, test di ripristino, policy immutabili)
- ITSM/Ticketing (dati degli incidenti, modifiche, SLA, lezioni apprese)
- CMDB/Servicekatalog (responsabile, criticità, dipendenze)
Per l’auditabilità dovrebbe mantenere per ogni KPI una breve „Definition of Done“: quali campi dati devono essere presenti? Qual è l’aggiornamento richiesto? Come vengono documentate le eccezioni?
Modello: KPI-Steckbrief (perché ogni indicatore sia verificabile e gestibile)
Quando introduce il suo set di KPI per la cyber-resilienza, eviti lunghi documenti concettuali senza impatto operativo. Si è dimostrata efficace una scheda compatta per ogni KPI:
- Nome & scopo (quale rischio viene influenzato?)
- Ambito (quali servizi/asset, quali esclusioni?)
- Formula (chiara, senza margine di interpretazione)
- Fonti dati (sistemi, report, responsabile)
- Frequenza di misurazione (giornaliera, settimanale, mensile)
- Valori target (minimo/obiettivo/ambizione) und regola di escalation
- Catalogo delle misure (passi tipici di remediation)
- Prove (quali artefatti vengono archiviati per l’audit?)
Lista di controllo: in 6 passaggi verso un set di KPI per la cyber-resilienza affidabile
- Definire i servizi aziendali critici: cosa deve tornare operativo entro quale tempo? Chi è il Service Owner? Senza questa lista i KPI rimangono generici.
- Formulare ipotesi di rischio: ad esempio „Credential Misuse è il nostro rischio principale“, „il backup è soggetto a manipolazione“, „mancano i log cloud“.
- Selezionare i KPI per dimensione: per dimensione iniziare con 3–5 KPI, non con 20 contemporaneamente.
- Garantire pipeline dati & qualità: fonti dati, definizioni, eccezioni, timestamp, conservazione.
- Definire target e escalation: con il management e i Service Owner, incluso il processo di accettazione del rischio.
- Stabilire l’operatività regolare: review mensile, backlog delle azioni, lezioni apprese da incidenti e test.
Prospettiva audit e regolamentare: quali evidenze contano tipicamente
Indipendentemente dal fatto che il suo framework sia ISO 27001, NIS2, DORA o direttive interne del gruppo: gli audit verificano ricorrentemente tre aspetti – design, efficacia e evidenza.
- Design: i controlli e i KPI sono ricavati logicamente dai rischi e dalla criticità?
- Efficacia: i KPI vengono misurati regolarmente e le deviazioni portano a decisioni?
- Evidenza: può dimostrare, su campioni, che misurazione, review e azioni sono state eseguite?
Artefatti di evidence pratici che in sede di verifica risultano spesso utili: runbook versionati, verbali delle esercitazioni, report dei test di RESTore, autorizzazioni per change e per eccezioni, report di trend dei KPI con review del management (es. estratto del verbale), nonché evidenze sull’integrità dei dati (conservazione, sincronizzazione temporale, controlli di accesso).
Logica dei costi e delle priorità: i KPI come bussola d’investimento invece che „obbligo di report“
Un set di KPI è anche uno strumento di budget e prioritizzazione. Blocchi di costo tipici nei programmi di resilienza sono: licenze/piattaforma, tempo del personale (esercizio, triage, esercitazioni), modernizzazione (es. Identity, logging), nonché infrastruttura (Immutable Storage, zone amministrative separate).
I KPI dovrebbero quindi essere scelti in modo da giustificare decisioni di investimento. Esempi:
- Se D1 Copertura delle sorgenti di log RESTa permanentemente sotto l’obiettivo, spesso la soluzione non è „più SOC“, ma standardizzazione del log-onboarding, fonte temporale centrale (NTP), retention coerente e sorgenti obbligatorie per servizio.
- Se R3 Test di RESTore falliscono, l’upgrade del software di backup non è necessariamente il primo passo; spesso mancano gestione dei diritti/chiavi, dipendenze documentate o ambienti di riavvio testabili.
- Se P3 Copertura MFA per account privilegiati non viene raggiunta, di solito è un tema di governance e legacy: account di servizio, eccezioni, processi break-glass, automazione.
Trappole tipiche dell’operatività – e come evitarle
1) KPI privi di contesto di servizio
Una percentuale di patch globale può apparire soddisfacente, mentre un singolo servizio critico RESTa indietro per mesi. Contromisura: rendicontare sempre i KPI separatamente per „servizi critici“ e „sistemi Tier-0“.
2) La qualità dei dati non viene misurata
Se CMDB, scanner o piattaforma di log sono incompleti, i KPI sono solo approssimazioni. Contromisura: includere esplicitamente Enabler-KPI (accuratezza dell’inventario, stato di ingestione dei log).
3) Il RESTore viene frainteso come „backup riuscito“
Un job di backup verde dice poco sul riavvio effettivo. Contromisura: test di RESTore con prove di integrità e accesso, più test end-to-end a catena (R5).
4) Reporting dei KPI senza conseguenze
Se i valori in rosso non inducono decisioni, la disciplina diminuisce. Contromisura: regole di escalation, accettazione del rischio con data di scadenza, backlog di misure vincolante.
5) Sovraccarico di allarmi invece di rilevamento
Molti alert vengono presentati come attività. Contromisura: qualità degli allarmi (D3), revisioni dei casi d’uso, misurazione del MTTD per classi di incidente.
Blocchi sorgente pratici: modelli per policy e definizioni dei KPI
I modelli seguenti sono volutamente generici, in modo che possano essere inseriti in policy, cataloghi di controllo o cartelle di audit.
Scheda KPI (Template)
KPI-ID:
Nome:
Scopo / Riferimento al rischio:
Ambito (Servizi/Asset):
Esclusioni:
Formula / Metodo di misurazione:
Fonti dati (Sistemi/Report):
Frequenza di misurazione:
Valori target (Minimo/Obiettivo/Ambizione):
Soglie (Giallo/Rosso):
Owner (Responsabile per il raggiungimento):
Data Steward (Definizione/Qualità dei dati):
Percorso di escalation (Organo, scadenze):
Misure standard in caso di scostamento:
Evidenza (Artefatti, conservazione):
Ultima revisione / prossima revisione:Modulo di policy: Obbligo di test di ripristino per servizi critici
1. Per tutti i servizi di business classificati come "kritisch" devono essere eseguiti test di ripristino con una frequenza definita.
2. Un test di ripristino è considerato superato solo se:
a) il sistema/il servizio si avvia,
b) l'autenticazione e gli accessi autorizzati sono verificati,
c) l'integrità dei dati è validata sulla base di punti di controllo definiti,
d) le dipendenze rilevanti (es. DNS/IAM/DB/interfacce) sono considerate nel test.
3. Le deviazioni devono essere documentate come azioni; in caso di mancato superamento ripetuto è obbligatoria un'escalation al competente organismo IT-/Risk.
4. Le evidenze (protocolli di test, timestamp, log) devono essere conservate in modo immodificabile e rintracciabile ai fini della revisione.Modulo di policy: Accettazione del rischio (Exception Handling) per deviazioni KPI
1. Le deviazioni dei KPI al di sotto del livello minimo possono essere approvate solo tramite una formale accettazione del rischio.
2. Ogni accettazione del rischio deve contenere:
- l'ambito del servizio/asset interessato,
- la motivazione del rischio e le misure di compensazione,
- data di scadenza (periodo massimo definito) e data di revisione,
- ruolo approvante (Service Owner + IT-Security + eventualmente Compliance).
3. Le accettazioni del rischio senza data di scadenza non sono ammissibili.Conclusione: la resilienza non si dichiara – si misura e si esercita
La cyber-resilienza è una disciplina di governance e di esercizio operativo. Un set di KPI per la cyber-resilienza aiuta a portare la sicurezza fuori dalla reattività: impone chiarezza sui servizi critici, misurazioni affidabili, esercitazioni e decisioni quando gli obiettivi non vengono raggiunti. Se si parte in piccolo, si prende sul serio la qualità dei dati e si definisce il ripristino non solo come «backup disponibile», si crea uno strumento di controllo che regge sia nella gestione quotidiana sia in sede di audit.
Anche per questo tema sono importanti la cyber-resilienza e i KPI di sicurezza. Il contributo inquadra questi aspetti in modo comprensibile e mostra su cosa focalizzarsi nella pratica quotidiana.