Gestione continua del rischio delle terze parti: attuare in modo conforme alle verifiche di audit il monitoraggio e le procedure di escalation

Inviare una volta all’anno un questionario ai fornitori e archiviare il risultato è ancora pratica comune in molte organizzazioni. Nella realtà però i rischi non cambiano annualmente, ma continuamente: vengono pubblicate vulnerabilità di sicurezza, i servizi cloud vengono ristrutturati, si aggiungono subfornitori, i modelli di business cambiano, i certificati scadono, i team di supporto vengono riorganizzati – e improvvisamente un processo critico si trova senza un fornitore affidabile. Proprio qui interviene la gestione continua del rischio dei fornitori terzi: non come burocrazia aggiuntiva, ma come disciplina operativa che trasforma segnali in decisioni concrete.

Questo contributo mostra come costruire un processo di monitoraggio e escalation in modo che funzioni nella pratica quotidiana: con indicatori di rischio chiari (KRIs, cioè metriche di allerta misurabili), soglie fisse, ruoli inequivocabili, documentazione pulita (Audit-Trail) e una logica di esecuzione che mette assieme Acquisti, Esercizio IT, Security e Compliance. Il focus è su approvvigionamento e governo – non sugli hype degli strumenti – e sulla domanda: come si trasforma un “dovremmo” in un processo solido che regge nei casi critici?

Perché la gestione continua del rischio dei fornitori terzi è più di un questionario

Third-Party Risk Management (TPRM) o Vendor Risk Management descrive la gestione dei rischi che derivano da fornitori esterni: piattaforme SaaS, provider di hosting, Managed Services, partner di sviluppo e di esercizio, fornitori di servizi di pagamento, subfornitori di supporto o anche fornitori di dati. Il rischio non è solo nel “Cyber”, ma altrettanto nella disponibilità, nella sovranità dei dati, nella conformità legale, nella capacità di fornitura e nella stabilità finanziaria.

La debolezza tipica della due diligence classica: è puntuale. Risponde se il fornitore allora soddisfaceva determinati requisiti. La gestione continua invece domanda: cosa è cambiato da allora, e quanto rapidamente lo rileviamo? Per i decisori questa è la differenza tra “abbiamo verificato” e “stiamo governando”.

Un buon processo di monitoraggio e escalation produce tre esiti:

• Segnalazione precoce: segnali prima che si verifichi un’interruzione, un problema sui dati o una constatazione di audit.
• Capacità decisionale: livelli chiari su chi decide cosa e quando (p. es. accettare, mitigare, sostituire il rischio).
• Dimostrabilità: documentazione riproducibile e a prova di audit che spieghi perché sono state prese determinate decisioni.

Regolamentazione e prospettiva di audit: quali requisiti dovete concretamente soddisfare

Indipendentemente dal fatto che siate formalmente regolati: requisiti dei clienti, revisione interna e auditor esterni si aspettano sempre più che i fornitori terzi non siano solo controllati inizialmente, ma siano monitorati per tutta la durata contrattuale. A seconda del settore e del contesto, giocano un ruolo, tra gli altri, i seguenti framework:

• ISO 27001: richiede relazioni con i fornitori e controlli; decisiva è l’attuazione nell’ISMS (Informationssicherheitsmanagementsystem) inclusi i riscontri di efficacia.
• DSGVO: richiede, nel caso di trattamento per conto, misure tecniche e organizzative adeguate (TOMs) nonché controllo e documentazione; rilevanti nella pratica sono i subfornitori, i flussi di dati, le politiche di cancellazione e la comunicazione degli incidenti.
• NIS2: affronta, tra l’altro, i rischi della supply chain; nella pratica conta che i fornitori critici siano identificati, monitorati e integrati nei processi di gestione degli incidenti e nei processi BCM.

La prospettiva dell’audit non è quasi mai «che strumento?», ma: esiste una procedura controllata, sono definite soglie, la tracciabilità è verificabile e in caso di deviazioni si procede con escalation coerenti? Un monitoraggio senza escalation assomiglia a un sistema di allarme senza piano d’intervento.

Definire chiaramente l’ambito: quali terze parti appartengono davvero al monitoraggio

Il monitoraggio continuo di tutti i fornitori è costoso e genera rumore. La leva iniziale è quindi una categorizzazione chiara. Un modello collaudato nella pratica è a due livelli:

1) Criticità del processo aziendale

Valutate quanto un’interruzione o una degradazione del fornitore impatti i vostri processi core. Termini chiave:

• RTO (Recovery Time Objective): quanto rapidamente il processo deve tornare operativo?
• RPO (Recovery Point Objective): quanta perdita di dati è tollerabile?
• BCM (Business Continuity Management): quadro organizzativo che rende operativi RTO/RPO e i piani di ripristino.

2) Esposizione al rischio (dati, accesso, infrastruttura)

Qui si valuta l’«impatto in caso di compromissione»: il fornitore tratta dati personali o dati particolarmente sensibili? Ha privilegi amministrativi nei vostri sistemi (ad es. via Remote Management)? Ospita infrastrutture critiche per voi (hosting, DNS, sicurezza e-mail, backbone VPN)? Utilizza subfornitori?

Come risultato dovreste definire almeno tre classi, ad esempio kritisch, wesentlich, unkritisch. Solo le classi kritisch e wesentlich rientrano in un monitoraggio reale e continuo — con frequenze diverse e livelli di escalation differenziati.

Il modello operativo: monitoraggio, KRIs e escalation come ciclo di controllo integrato

Un processo solido segue un semplice ciclo di controllo: rilevare segnali → valutare → decidere → monitorare l’esecuzione. L’errore tipico è implementare il monitoraggio «come raccolta dati». Per il funzionamento e per l’audit, però, conta se dai dati derivano azioni.

Definire pragmaticamente ruoli e responsabilità (RACI)

RACI significa: Responsible (esegue), Accountable (decide), Consulted (coinvolto), Informed (informato). Per i fornitori si consiglia un set minimo:

• Service Owner (Accountable): è responsabile a livello funzionale/tecnico dell’utilizzo del fornitore e decide sull’accettazione/azioni correttive.
• Vendor Owner (Responsible): gestisce operativamente il rapporto con il fornitore, raccoglie evidenze e coordina le revisioni.
• Security/ISMS (Consulted): definisce i requisiti di sicurezza, valuta i finding e gestisce l’interfaccia per gli incidenti.
• Compliance/Protezione dei dati (Consulted): verifica GDPR/contratti, contratti di trattamento (AVV), sub-processori, conservazione/cancellazione.
• Acquisti (Responsible/Consulted): integra i requisiti nei contratti, gestisce rinnovi/exit, si occupa della documentazione.
• Management (Informed/Accountable a seconda del rischio): assume consapevolmente elevati rischi residui.

Importante: senza un Accountable chiaro l’escalation è inefficace. I revisori chiedono spesso esplicitamente chi approva il rischio residuo – e se ciò è documentato in modo verificabile.

Quali segnali dovRESTe monitorare: fonti di dati invece dell’intuito

Il monitoraggio continuo si basa su fonti di dati che possono essere aggiornate regolarmente. Non ogni fonte deve essere tecnicamente «automatica»; ciò che conta è che sia affidabile, ripetibile e documentata.

Segnali tecnici e rilevanti per la sicurezza

• Segnali di vulnerabilità ed esposizione: segnalazioni di vulnerabilità critiche che riguardano il fornitore (p.es. in componenti ad uso pubblico), inclusi i tempi di reazione.
• Variazioni nei rating di sicurezza: i rating esterni possono servire come segnale, ma non dovrebbero mai costituire l’unica base decisionale (metodologia «black box»).
• Segnalazioni di incidenti e violazioni: incidenti di sicurezza confermati, incl. «near misses», purché il fornitore sia trasparente.
• Eventi di cambiamento: cambiamenti significativi di architettura o piattaforma, nuovi sub-processori, spostamento tra regioni dei data center.

Indicatori operativi e di performance

• Adempimento SLA/SLO: disponibilità, tempi di risposta, tempi di reazione del supporto. (SLO = Service Level Objective, obiettivo interno; SLA = impegno contrattuale.)
• Qualità del supporto: backlog di ticket, frequenza delle escalation, «Time to RESTore» dopo interruzioni.
• Finestre di rilascio e manutenzione: frequenza, pianificabilità, qualità della comunicazione.

Segnali di conformità, contrattuali e aziendali

• Certificati e report: date di scadenza, modifiche di ambito, finding rilevanti nei report SOC/ISO (se disponibili).
• Eventi finanziari/aziendali: acquisizioni, indicatori di insolvenza, cambiamenti strategici che possono influenzare la continuità del servizio.
• Segnali relativi al GDPR: nuovi sub-processori, nuovi trasferimenti verso paesi terzi, categorie di dati modificate.

Regola pratica: ogni fonte monitorata deve avere una reazione definita. Se non sapete cosa fare in presenza di un segnale, probabilmente non è adatta come KRI.

Definire i KRI: dal «molto monitoraggio» a soglie rilevanti

KRI (Key Risk Indicator) è una grandezza misurabile che segnala precocemente un rischio in aumento. I buoni KRI sono rari. Essi hanno definizioni chiare, soglie e una assegnazione fissa a livelli di escalation. Esempi che funzionano in molti contesti:

• KRI: Riscontri di sicurezza critici aperti – Numero o gravità dei riscontri aperti derivanti da audit/assessment, incl. tempo trascorso dalla scoperta.
• KRI: Latenza di patch/mitigazione – Tempo tra la vulnerabilità critica resa pubblica e la mitigazione dimostrabile presso il fornitore.
• KRI: Violazioni SLA – Numero/andamento delle violazioni SLA per trimestre; rilevante è la correlazione con gli impatti di business.
• KRI: Modifiche ai subfornitori – Numero di cambiamenti significativi di subprocessor senza adeguata informazione preventiva.
• KRI: Capacità di uscita – „Time to Export“ (durata realistica per l’esportazione dei dati), stato dei test di exit, completezza degli artefatti di esportazione.

I valori soglia non dovrebbero essere decisi a buon senso. Definisciteli in funzione del vostro impatto: se l’RTO è 24 ore, un evento di indisponibilità che dura 12 ore deve già far scattare un allarme giallo/rosso – indipendentemente dal fatto che il fornitore sia formalmente „conforme allo SLA“. Per fornitori critici conviene rivedere le soglie su base trimestrale.

Processo di escalation nella pratica: livelli, trigger, termini, decisioni

Un processo di escalation è una procedura predefinita che entra in vigore al verificarsi di trigger di rischio. Deve essere sufficientemente breve da poter essere effettivamente utilizzato durante un incidente e sufficientemente formale da superare le verifiche di audit.

Livelli di escalation (modello d’esempio)

• Livello 0 – Operatività normale: il monitoring è attivo, nessuna anomalia.
• Livello 1 – Osservazione (giallo): il KRI supera la soglia di allerta precoce; viene richiesto un piano di azione, viene impostato un termine.
• Livello 2 – Evento di rischio (arancione): deviazione ripetuta/significativa; informazione al management, verifica dei meccanismi contrattuali ove necessario (crediti di servizio, diritti di risoluzione straordinaria), mitigazioni tecniche interne.
• Livello 3 – Critico (rosso): rischio acuto per disponibilità/integrità/confidenzialità; entra in funzione il processo incident e il BCM, attivare l’opzione di exit, preparare decisioni di approvvigionamento o migrazione.

Cosa deve contenere un Runbook di escalation?

Un runbook è una guida passo-passo per situazioni ricorrenti. Per le escalation verso terzi dovrebbe contenere almeno:

• Trigger: quali KRI, quali fonti, quale gravità.
• Responsabile: chi avvia l’escalation (p.es. responsabile del fornitore), chi decide (responsabile del servizio/direzione).
• Termini: termini di risposta e di consegna per le risposte del fornitore, date per le revisioni interne.
• Comunicazione: chi informare (Sicurezza, Protezione dei dati, unità di business, direzione), quali contenuti minimi includere.
• Opzioni decisionali: accettare, mitigare, compensare (controlli aggiuntivi), ridurre (limitare l’ambito), sostituire (uscita).
• Prove: dove documentare (ticket, sistema GRC, fascicolo di approvvigionamento), quali artefatti conservare (e‑mail, report, verbali di riunione).

Modelli per approvvigionamento e governance: checklist che collegano audit e esercizio

Per la categoria approvvigionamento è cruciale che il monitoraggio e l’escalation non inizino solo «dopo la firma del contratto», ma siano predisposti contrattualmente e organizzativamente. I seguenti modelli si sono dimostrati efficaci:

Lista di controllo A: requisiti minimi dei contratti per il monitoraggio continuo

• Obblighi di informazione: scadenze per le segnalazioni di incidenti, modifiche ai subappaltatori, cambiamenti significativi di architettura/ubicazione.
• Diritti di verifica: report di audit (p.es. SOC/ISO), riepiloghi di penetration test, TOMs, eventualmente audit in loco/remoti a seconda della criticità.
• Struttura SLA/SLO: punti di misurazione definiti, frequenza di reporting, conseguenze in caso di violazione.
• Exit e portabilità: formati di esportazione dei dati, conferme di cancellazione, supporto alla migrazione, servizi di transizione.
• Controllo dei sub-processori: riserva di consenso o diritti di opposizione, liste di trasparenza, notifica di modifica.

Lista di controllo B: set operativo di monitoraggio per classe di fornitore

• Critico: review mensile dei KRI, review di management trimestrale, test di exit annuale (almeno esportazione dei dati), esercitazione sugli incidenti documentata.
• Essenziale: review trimestrale dei KRI, revisione contrattuale/di sicurezza annuale, aggiornamento del piano di exit.
• Non critico: verifica annuale, focus sulla durata contrattuale e sulla compliance di base.

Lista di controllo C: documentazione pronta per l’audit (ciò che i verificatori tipicamente vogliono vedere)

• registro fornitori aggiornato con classi (critico/essenziale/non critico) e motivazione
• KRI definiti incl. soglie, fonti dati, frequenza di revisione
• prove delle revisioni (verbali, ticket, piani d’azione, approvazioni dei rischi residui)
• casi di escalation incl. timeline: Trigger → Entscheidung → Maßnahme → Abschluss
• strategia di exit e test (risultati, lacune, prossimi passi)

Implementazione tecnica senza obbligo di tool: raccogliere, normalizzare, tracciare i dati

Molte organizzazioni partono con risorse proprie e poi evolvono verso un tool GRC o TPRM. Ciò che conta è la logica di processo: da dove provengono i dati, chi li verifica, dove vengono registrate le decisioni?

Una struttura pragmatica può essere:

• Registro fornitori come „Single Source of Truth“ (p.es. CMDB, sistema di approvvigionamento o GRC): contiene classificazione, responsabile, contratti, tipologie di dati, sub-processori, durate.
• Signal-Inbox: punto centrale per le segnalazioni (feed di sicurezza, stato del provider, notifiche contrattuali). Può essere una coda di ticket.
• Cadenza di revisione: appuntamenti fissi (mensili/trimestrali) e agenda chiara: KRI, azioni aperte, modifiche contrattuali o di scope.
• Tracking delle azioni: ticket con responsabile, scadenza, evidenze (allegati/link), criteri di chiusura.

Se necessitate esempi tecnici replicabili, query semplici e blocchi di policy sono spesso più utili di integrazioni complesse. Due esempi (adattare al vostro modello dati):

-- Beispiel: Lieferanten mit bald auslaufenden Nachweisen (z. B. ISO-/SOC-Berichte) finden
SELECT vendor_name,
       evidence_type,
       evidence_expires_on,
       risk_class,
       owner_email
FROM vendor_evidence
WHERE evidence_expires_on <= CURRENT_DATE + INTERVAL '60 days'
  AND risk_class IN ('kritisch','wesentlich')
ORDER BY evidence_expires_on ASC;

# Esempio: elemento di policy per scadenze di escalation (modello, indipendente dallo strumento)
third_party_risk:
  escalation:
    level_1_observation:
      trigger: "KRI oltre la soglia di preallarme"
      vendor_response_due_days: 10
      internal_review_due_days: 15
    level_2_risk_event:
      trigger: "KRI oltre la soglia critica o in caso di ripetizione"
      vendor_response_due_days: 5
      management_notification_due_hours: 24
    level_3_critical:
      trigger: "pericolo acuto o incidente grave confermato"
      incident_process: true
      bcm_invoke_due_hours: 4
      exit_assessment_due_days: 3

Decisivo: questi artefatti non devono essere „perfetti“ – ma devono essere versionati, tracciabili e parte integrante del funzionamento operativo.

Valutare costi e benefici realisticamente: dove si concentra l’impegno

Il monitoraggio continuo richiede tempo e attenzione. Le voci di costo principali raramente sono gli strumenti, ma il lavoro organizzativo:

• Inventario iniziale: ripulire la lista fornitori, trovare gli Owner, comprendere i flussi di dati.
• Classificazione e KRI: definire la logica di impatto, stabilire soglie, stabilizzare le sorgenti dati.
• Scadenze ricorrenti: revisioni, tracciamento delle misure, raccolta delle evidenze, documentazione delle eccezioni.
• Casistiche di escalation: comunicazione, chiarimenti legali, workaround tecnici, eventuali costi di migrazione.

I benefici sono anch’essi concretamente misurabili, anche senza „marketing del ROI“: meno sorprese negli audit, reazioni più rapide ai problemi dei fornitori, decisioni più chiare nei rinnovi contrattuali e, soprattutto, una capacità di uscita realistica. Proprio la capacità di uscita è spesso sottovalutata: senza export dei dati testato e piano di transizione, un cambio fornitore in fase di crisi è raramente pianificabile.

Trappole tipiche e come evitarle

Trappola 1: monitoraggio senza Owner

Se nessuno è responsabile, gli avvisi vengono „presi atto“. Soluzione: per ogni fornitore critico un Service Owner (decide) e un Vendor Owner (operativo).

Trappola 2: troppi indicatori

Troppi segnali generano assuefazione agli allarmi. Soluzione: pochi KRI legati direttamente all’impatto, più un „Signal-Backlog“ separato per osservazioni complementari.

Trappola 3: escalation come conflitto personale

Senza livelli definiti a priori, l’escalation appare come sfiducia verso il fornitore. Soluzione: definire il modello di escalation contrattualmente e a livello di processo; l’escalation diventa così operatività standard, non „dramma“.

Trappola 4: Exit solo teorico

Molti exit falliscono a causa di formati dati, API di export mancanti o dipendenze nascoste (p.es. Identity Provider, instradamento mail, DNS). Soluzione: testare l’exit almeno per i fornitori critici (export dati, ripristino, revoca accessi, conferma di cancellazione).

Logica decisionale per la direzione: quando basta la mitigazione, quando è necessario un Exit?

Per le decisioni di management aiuta una matrice chiara di impatto e controllabilità:

• Alto impatto + bassa controllabilità (p.es. SaaS senza possibilità di export, scarsa trasparenza): preparare attivamente l’opzione di exit, valutare il funzionamento in parallelo.
• Alto impatto + buona controllabilità (p.es. buon contratto, solide evidenze, canali di comunicazione chiari): mitigazione e monitoraggio stretto, ma accettare consapevolmente il rischio residuo.
• Basso impatto + alta controllabilità: monitoraggio standard, focus sulle durate contrattuali e sulla compliance di base.

L’importante è la forma della decisione sul rischio residuo: se si accetta un rischio, ciò deve includere una motivazione, un orizzonte temporale (entro quando sarà rivalutato) e un piano B. Questo non è solo protezione in sede di audit, ma governance operativa reale.

Conclusione: Un buon processo di monitoraggio e di escalation è uno strumento operativo

Il risk management continuo dei fornitori funziona se viene inteso come un circuito di controllo: pochi KRIs efficaci; responsabilità chiare; livelli di escalation definiti; e una documentazione che renda le decisioni verificabili. Per l’approvvigionamento questo significa: i requisiti devono essere ancorati contrattualmente e preparati a livello organizzativo, altrimenti il monitoraggio RESTerà solo un’aspettativa.

Avviate in modo pragmatico: pulire il registro fornitori, classificare i fornitori critici, definire tre o cinque KRIs, predisporre un escalation runbook e stabilire le prime review come routine. Successivamente è possibile integrare strumenti, automazione e segnali aggiuntivi in modo mirato – ma su una base di governance stabile che supporti sia l’audit sia l’operatività.

Per questo tema sono rilevanti anche il rischio fornitori e il processo di monitoraggio. Il contributo inquadra questi aspetti in modo comprensibile e mostra a cosa pRESTare attenzione nella pratica quotidiana.