Il monitoraggio della postura di sicurezza dei fornitori esterni è una delle discipline più difficili da rendere sistematica nelle organizzazioni e non per mancanza di consapevolezza, in quanto il rischio supply chain è oggi ampiamente riconosciuto, ma per un problema strutturale: senza metriche definite, il monitoraggio rimane discontinuo, soggettivo e dipendente dall’iniziativa dei singoli.

Un vendor valutato positivamente durante l’onboarding può deteriorare la propria postura di sicurezza nei mesi successivi senza che l’organizzazione cliente se ne accorga, fino a quando un incidente rende il problema visibile in modo drammatico.

Perché i KPI di sicurezza sono il cuore del monitoraggio continuo dei vendor

I KPI di sicurezza (Key Performance Indicator) applicati al dominio della cyber security sono la risposta strutturale a questo problema.

Definendo in anticipo quali metriche misurare, con quale frequenza, rispetto a quali soglie e con quali conseguenze al superamento delle soglie, l’organizzazione trasforma il monitoraggio da un’attività discrezionale in un processo governato.

Ogni vendor critico ha un profilo di KPI associato: ogni deviazione dai valori attesi genera un alert e ogni alert innesca un processo di risposta definito. Il risultato è un sistema di early warning che rileva il deterioramento della postura di sicurezza di un fornitore prima che si traduca in un incidente.

Sul piano normativo, la definizione e il monitoraggio di KPI di sicurezza per i vendor non è solo una buona pratica: è un requisito implicito di NIS2 e DORA. Entrambe le normative richiedono che le organizzazioni dimostrino di gestire attivamente il rischio della supply chain e la dimostrazione più convincente è un programma di monitoraggio continuo con metriche documentate, soglie definite e processi di escalation formalizzati.

Un programma di Vendor Risk Management senza KPI è un programma che non può essere verificato né migliorato nel tempo.

Dal monitoraggio spot al monitoraggio continuo: il cambio di paradigma

Il modello tradizionale di valutazione dei vendor è fondamentalmente discontinuo: un assessment approfondito all’onboarding, un audit annuale, e nel mezzo una sostanziale assenza di visibilità sulla postura di sicurezza del fornitore.

Questo modello ha un limite intrinseco: il panorama delle minacce e la postura di sicurezza dei vendor cambiano continuamente, mentre gli snapshot annuali fotografano una realtà che potrebbe essere già obsoleta al momento della valutazione.

Un vendor che supera brillantemente un audit in gennaio può essere coinvolto in un incidente significativo in marzo e l’organizzazione cliente potrebbe non saperlo fino al successivo audit.

Il monitoraggio continuo risolve questo gap attraverso la raccolta automatizzata e continuativa di dati sulla postura di sicurezza dei vendor, integrata con feed di threat intelligence che segnalano in tempo reale eventi rilevanti come nuove vulnerabilità nei software del vendor, segnalazioni di breach, variazioni nel security rating esterno, cambiamenti nella struttura societaria.

Questo approccio non sostituisce gli audit periodici: li completa fornendo il contesto necessario per interpretare i risultati dell’audit e per identificare le aree che richiedono attenzione nelle verifiche successive.

La transizione dal monitoraggio spot al monitoraggio continuo richiede tre ingredienti:

1. metriche definite (i KPI);
2. strumenti di raccolta automatizzata dei dati (le piattaforme di security rating e i tool di monitoraggio);
3. processi di risposta agli alert (le procedure di escalation).

La mancanza di uno qualsiasi di questi tre elementi rende il monitoraggio continuo inefficace: metriche senza automazione generano overhead manuale insostenibile; automazione senza metriche definite genera rumore senza segnale; metriche e automazione senza processi di risposta generano alert che nessuno gestisce.

KPI lagging e KPI leading: misurare il passato e anticipare il futuro

Il framework concettuale più utile per strutturare un programma di KPI di sicurezza vendor è la distinzione tra indicatori lagging e indicatori leading: una classificazione mutuata dalla letteratura manageriale sul performance management e applicata con piena pertinenza al dominio della cyber security.

La distinzione non è solo accademica, ma ha implicazioni dirette su come i KPI vengono raccolti, interpretati e utilizzati per le decisioni operative.

I KPI lagging misurano outcome già verificatisi, ossia eventi che sono accaduti e il cui impatto è già stato prodotto.

Il numero di incidenti di sicurezza nel trimestre, il tempo medio di risposta a un breach, la percentuale di vulnerabilità critiche risolte nel periodo, il numero di violazioni degli SLA di sicurezza: questi sono indicatori del passato, utili per valutare le performance storiche del vendor e per identificare tendenze nel tempo, ma intrinsecamente retrospettivi.

Quando un KPI lagging peggiora, l’impatto si è già manifestato.

I KPI leading misurano segnali precoci che anticipano, con un certo grado di probabilità, il deterioramento futuro della postura di sicurezza.

Il numero di vulnerabilità critiche non ancora patchate oltre la soglia SLA, la percentuale di sistemi con configurazioni non conformi al baseline, il trend del security rating esterno nelle ultime quattro settimane, il numero di dipendenti del vendor che hanno cliccato su link di phishing simulato nell’ultimo trimestre: questi indicatori non misurano un danno già avvenuto, ma la probabilità crescente che un danno si verifichi.

Agire su un KPI leading significa prevenire un incidente; agire su un KPI lagging significa imparare da un incidente già accaduto.

Catalogo operativo dei KPI di sicurezza per i fornitori esterni

Il catalogo che segue organizza i KPI di sicurezza vendor in quattro domini – tecnico, operativo, governance e supply chain – con metriche specifiche, soglie di allerta e frequenza di misurazione raccomandata.

Le soglie indicate sono valori di riferimento basati sui benchmark di settore (CIS Controls, ENISA, IBM CDBR); ogni organizzazione deve calibrarle sul proprio profilo di rischio e sui requisiti contrattuali con i vendor. Il tipo (L = lagging, LD = leading) è indicato per facilitare il bilanciamento del set.

Dominio 1: KPI tecnici

I KPI tecnici misurano la qualità dei controlli di sicurezza implementati dal vendor a livello di sistemi, reti e applicazioni. Sono i KPI più direttamente verificabili attraverso strumenti automatizzati e i più correlati alla probabilità di incidenti tecnici.

Dominio 2: KPI operativi

I KPI operativi misurano la capacità del vendor di rispondere agli incidenti, mantenere i livelli di servizio e gestire le eccezioni in modo documentato. Sono prevalentemente KPI lagging, utili per valutare la maturità operativa del fornitore nel tempo.

Dominio 3: KPI di governance e compliance

I KPI di governance misurano la solidità del framework organizzativo e normativo del vendor: certificazioni attive, conformità ai requisiti normativi, qualità dei processi di gestione della sicurezza. Sono i KPI con la frequenza di misurazione più bassa ma con impatto più duraturo sulla classificazione del rischio.

Dominio 4: KPI della supply chain

I KPI della supply chain misurano la postura di sicurezza del vendor rispetto ai propri sub-fornitori e la capacità dell’organizzazione cliente di uscire dalla relazione in condizioni controllate. Sono i KPI più frequentemente assenti nei programmi VRM tradizionali e tra i più importanti per la resilienza complessiva.

KPI di sicurezza e Vendor Risk Management: il ciclo di feedback

I KPI di sicurezza non sono uno strumento autonomo: sono la componente di misurazione di un programma VRM maturo.

Il loro valore non sta nei singoli valori puntuali (un security rating di 78 su 100 dice poco senza contesto) ma nella tendenza nel tempo, nel confronto con le soglie definite e nell’integrazione con gli altri elementi del programma: il risk assessment, i contratti SLA, i risultati degli audit.

Un KPI che deteriora progressivamente nel tempo è un segnale che il risk score del vendor deve essere aggiornato; un KPI che supera la soglia di alert è un evento che attiva il processo di escalation contrattuale.

La misurazione costante del livello di cifratura dei dati previene il deterioramento della postura difensiva nel tempo. L’uso di cruscotti digitali automatizza il Vendor Risk Management, offrendo report in tempo reale sui livelli di protezione e rendendo la sicurezza della supply chain un processo governato da dati oggettivi piuttosto che da valutazioni soggettive e discontinue.

Il ciclo di feedback tra KPI e programma VRM si realizza in quattro momenti:

1. la definizione dei KPI in fase di onboarding del vendor (allineata ai risultati del risk assessment iniziale);
2. la raccolta continuativa dei dati durante l’operatività;
3. la revisione periodica dei KPI in occasione degli audit (per verificare che le metriche riflettano ancora i rischi più rilevanti);
4. l’aggiornamento del risk score del vendor in funzione dell’andamento dei KPI nel tempo.

Questo ciclo trasforma il VRM da una serie di valutazioni discontinue in un processo di miglioramento continuo governato da dati.

Il vendor scorecard: sintetizzare i KPI in un punteggio complessivo

Il catalogo dei KPI produce un insieme di dati potenzialmente ricco ma difficile da leggere nella sua globalità.

Il vendor scorecard risponde a questa esigenza di sintesi: è uno strumento che aggrega i KPI dei quattro domini in un punteggio complessivo ponderato, espresso su scala 0-100, che fornisce una vista immediata della postura di sicurezza complessiva del vendor e consente il confronto tra vendor diversi su una base omogenea.

La struttura del vendor scorecard che segue assegna pesi differenziati ai quattro domini in funzione del loro impatto sul rischio complessivo:

• la sicurezza tecnica riceve il peso maggiore (35%) perché è il dominio più direttamente correlato alla probabilità di incidenti;
• la performance operativa (25%) misura la capacità di risposta quando gli incidenti si verificano;
• governance e supply chain (20% ciascuno) completano il quadro con dimensioni strutturali di lungo termine.

I pesi possono essere ricalibrati in funzione del tipo di vendor e del contesto operativo: per un CSP cloud, la sicurezza tecnica potrebbe pesare fino al 45%; per un fornitore di servizi professionali, la governance potrebbe avere peso maggiore.

Dashboard e strumenti: automatizzare il monitoraggio dei KPI

Il passaggio successivo è quello di automatizzare il monitoraggio dei KPI mediante dashboard e strumenti di misurazione.

Security rating platform: visibilità esterna continua

Le piattaforme di security rating sono la categoria di strumenti più adatta per il monitoraggio continuo della postura di sicurezza esterna dei vendor.

Queste piattaforme raccolgono dati da fonti pubbliche (scansioni passive dei sistemi esposti su internet, analisi DNS e certificati SSL, feed di threat intelligence, dark web monitoring, analisi dei record di posta elettronica (SPF, DKIM, DMARC)) e li aggregano in un punteggio aggiornato continuamente per ogni vendor nel portafoglio.

Il vantaggio principale di queste piattaforme è che non richiedono la cooperazione del vendor: il monitoraggio avviene dall’esterno, in modo trasparente, senza necessità di accesso ai sistemi del fornitore.

Questo consente di avere una visibilità continuativa anche sui vendor meno collaborativi, e di rilevare deterioramenti della postura di sicurezza (nuove porte aperte, certificati scaduti, presenza di credenziali compromesse nel dark web) in tempo reale, senza attendere i report periodici del vendor.

La correlazione tra il trend del security rating e i KPI interni del programma VRM produce un quadro del rischio molto più ricco di quello ottenibile da ciascuna fonte in modo isolato.

Integrazione con GRC e SIEM per il monitoraggio interno

Le piattaforme di security rating coprono la dimensione esterna del monitoraggio, ma non la dimensione interna: i KPI che richiedono accesso ai log del vendor, ai risultati dei vulnerability scan, ai dati di configurazione.

Per questa dimensione, l’integrazione con le piattaforme GRC (Governance, Risk and Compliance) e con il SIEM dell’organizzazione cliente è lo strumento più efficace. Le piattaforme GRC con moduli VRM consentono di centralizzare la raccolta dei KPI interni attraverso questionari automatizzati inviati periodicamente ai vendor, integrazione API con gli strumenti di monitoraggio tecnico, e workflow di escalation automatici al superamento delle soglie.

Il SIEM dell’organizzazione cliente può contribuire al monitoraggio dei KPI vendor attraverso l’analisi dei log di accesso dei vendor ai sistemi interni: frequenza degli accessi, orari, sistemi visitati, anomalie comportamentali.

Questa dimensione, cioè il monitoraggio del comportamento del vendor all’interno dei propri sistemi, è spesso trascurata nei programmi VRM tradizionali ma è particolarmente rilevante per i vendor con accesso privilegiato (MSP, MSSP, system integrator): un vendor che accede a sistemi al di fuori del normale orario operativo o che scarica volumi insoliti di dati, è un segnale di allerta che il SIEM può rilevare automaticamente se opportunamente configurato.

Definire soglie, alert e processi di escalation

La definizione delle soglie di alert è uno degli aspetti più delicati del programma di KPI vendor.

Soglie troppo rigide generano alert continui che il team non riesce a gestire, producendo alert fatigue (cioè la desensibilizzazione agli alert che porta a ignorarli sistematicamente) e rendendo il sistema di monitoraggio inutile.

Soglie troppo permissive lasciano passare deterioramenti significativi della postura di sicurezza prima che vengano rilevati. La calibrazione corretta richiede un processo iterativo: iniziare con soglie leggermente più permissive del desiderato, osservare il volume di alert nel primo trimestre, e affinare in funzione della capacità di risposta del team.

Per ogni KPI, è utile definire due livelli di soglia: una soglia di attenzione (ambra) che attiva una verifica senza escalation formale e una soglia critica (rosso) che attiva il processo di escalation al management e le clausole contrattuali.

Questa differenziazione riduce il “rumore” mantenendo la capacità di risposta rapida per le situazioni più gravi. Il processo di escalation deve essere documentato e testato: chi riceve l’alert ambra e in quanto tempo risponde, chi riceve l’alert rosso, quali azioni deve intraprendere e entro quale termine, come viene chiuso il loop con il vendor.

Un elemento spesso trascurato è la gestione delle eccezioni: situazioni in cui un KPI supera la soglia per ragioni note e temporanee (una migrazione pianificata, un test di penetrazione in corso, una manutenzione straordinaria) che non riflettono un deterioramento reale della postura di sicurezza.

Il programma di KPI deve includere un processo formale di eccezione, con documentazione della ragione, durata prevista e approvazione interna, per evitare che alert legittimi vengano ignorati sulla base di giustificazioni informali del vendor.

KPI di sicurezza nei settori critici NIS2: requisiti e frequenze

Per i soggetti NIS2, il monitoraggio continuo dei vendor attraverso KPI strutturati non è solo una best practice: è la traduzione operativa dell’obbligo di gestire il rischio della supply chain in modo proporzionato e documentato. ACN, nelle proprie linee guida sull’attuazione dell’art. 21, indica il monitoraggio continuativo dei fornitori critici come una delle misure attese per le organizzazioni nei settori essenziali e la documentazione dei KPI, delle soglie e dei processi di escalation è esattamente il tipo di evidenza che le ispezioni ACN possono richiedere.

Le frequenze di monitoraggio raccomandate variano in funzione del livello di criticità del vendor e del tipo di KPI.

Per i vendor essenziali dei soggetti NIS2, quelli che gestiscono funzioni direttamente collegate all’erogazione dei servizi critici, il monitoraggio dei KPI tecnici deve essere continuo o almeno settimanale; i KPI operativi mensili; i KPI di governance e supply chain trimestrali o semestrali.

Per i soggetti DORA nel settore finanziario, i requisiti si sovrappongono con quelli NIS2 ma aggiungono specifiche sulla frequenza di reporting verso il management: il registro dei contratti ICT deve essere aggiornato continuamente e i rischi dei provider critici devono essere riportati al board con frequenza almeno trimestrale.

Un aspetto specifico per i settori critici riguarda la documentazione dei KPI storici. NIS2 richiede che le organizzazioni dimostrino di aver gestito il rischio nel tempo e non solo al momento dell’ispezione.

Conservare la serie storica dei KPI vendor per almeno 3 anni (5 anni per i settori con requisiti di retention più stringenti, come la sanità e la finanza) è una misura di compliance che protegge l’organizzazione in caso di ispezione post-incidente: dimostrare che il deterioramento di un vendor era monitorato e che sono state adottate misure correttive è molto più difendibile di non avere documentazione del processo di monitoraggio.

Comunicare i KPI al management: dal dato al cruscotto esecutivo

L’efficacia di un programma di KPI vendor si misura anche dalla capacità di comunicarne i risultati al management in modo comprensibile e azionabile. Il CISO che presenta al CdA una tabella con 40 KPI e relative soglie produce confusione, non decisioni.

Il management ha bisogno di una sintesi che risponda a tre domande: quali vendor rappresentano un rischio attuale? Ci sono tendenze preoccupanti? Quali azioni sono necessarie? Il vendor scorecard e le dashboard esecutive rispondono a queste domande attraverso la visualizzazione dei dati, non attraverso il dato grezzo.

Il report mensile sui KPI vendor per il management dovrebbe includere:

• il vendor scorecard aggiornato per tutti i vendor critici (con variazione rispetto al mese precedente);
• la lista degli alert attivi con vendor, KPI e azione in corso;
• gli alert chiusi nel mese con evidenza dell’azione risolutiva;
• un paragrafo narrativo di sintesi che contestualizza i numeri;

spiegando perché un vendor è in stato ambra e quale piano di miglioramento è in corso. Questo formato trasforma il report da un aggregato di dati in uno strumento decisionale: il management vede lo stato, la tendenza e l’azione, senza dover interpretare metriche tecniche.