Chi c’è dietro il fornitore? La governance ICT non può fermarsi al primo contratto

Il fornitore visibile non è sempre quello da cui dipende il servizio

Un servizio può rispettare gli SLA, superare la service review e restare comunque esposto a una dipendenza che nessuno ha guardato abbastanza. Il contratto è con il fornitore principale; l’identità, la connettività, il dato, il supporto specialistico o una parte della piattaforma possono però dipendere da altri soggetti. Quando quella catena cambia, il rischio cambia con lei, anche se il nome sulla fattura resta lo stesso.

Il 18 settembre 2026 l’European Banking Authority ha pubblicato le linee guida finali sulla gestione del rischio di terze parti. Il perimetro riguarda in particolare i servizi non ICT e le funzioni critiche o importanti, ma il messaggio manageriale si allinea con DORA: la governance non si esaurisce nella firma. Deve attraversare valutazione del rischio, due diligence, contratto, subfornitura, monitoraggio, documentazione e uscita.

Cinque giorni dopo, il 23 settembre, le autorità europee di vigilanza hanno indicato le dipendenze esterne tra le vulnerabilità del sistema finanziario europeo, richiamando in particolare l’esposizione verso fornitori e infrastrutture non europee. Due notizie vicine consegnano la stessa domanda a CIO, service owner e procurement: sappiamo davvero da chi dipende il servizio quando il fornitore dipende da qualcun altro?

Dal vendor rating alla mappa delle dipendenze

Il vendor rating tradizionale osserva solidità economica, certificazioni, incidenti, qualità e rispetto contrattuale. Sono informazioni necessarie, ma non descrivono l’architettura reale del servizio. La mappa utile deve collegare funzione aziendale, servizio, componenti, dati, localizzazioni, fornitore diretto e subfornitori materiali. Solo così emerge che due fornitori apparentemente alternativi usano la stessa infrastruttura, lo stesso operatore specializzato o la stessa regione cloud.

DORA richiede alle entità finanziarie di gestire il rischio delle terze parti ICT come parte del rischio ICT complessivo e di mantenere un registro degli accordi contrattuali. Il Regolamento delegato UE 2025/532 aggiunge elementi specifici per la subfornitura di servizi ICT che supportano funzioni critiche o importanti: valutazione preventiva, capacità di monitorare la catena, informazione sui cambiamenti materiali e diritti di terminazione.

Il registro diventa utile soltanto quando dialoga con l’operatività. Se rimane un adempimento separato, fotografato una volta l’anno, non intercetta una migrazione tecnica, un nuovo subfornitore o una modifica della localizzazione dei dati. Change management e supplier governance devono quindi scambiarsi segnali: una variazione architetturale può richiedere una rivalutazione del rischio; una modifica contrattuale può imporre test tecnici e aggiornamenti alla continuità.

La lezione è trasferibile anche fuori dal perimetro regolamentato. Non serve censire ogni microfornitore con la stessa profondità. Serve riconoscere quelli la cui indisponibilità, sostituzione o variazione può cambiare sicurezza, qualità, localizzazione dei dati, continuità o capacità di uscita. La proporzionalità non è fare meno controlli: è investire il controllo dove una dipendenza può diventare un blocco operativo.

Uno SLA verde può nascondere una concentrazione rossa

Disponibilità, tempi di presa in carico e risoluzione misurano ciò che accade nel rapporto operativo. Non dicono quanto sia sostituibile il servizio. Un fornitore può mantenere tutti gli indicatori in verde e, nello stesso tempo, accentrare competenze, dati, strumenti di amministrazione e conoscenza della configurazione in un punto che l’organizzazione non saprebbe ricostruire.

Per questo la service review dovrebbe affiancare agli SLA almeno quattro segnali: quota del servizio dipendente da subfornitori materiali; concentrazione su tecnologie e localizzazioni comuni; numero di cambiamenti nella catena non ancora valutati; tempo stimato e tempo provato di trasferimento. Non sono metriche decorative. Servono a distinguere un servizio oggi disponibile da un servizio domani governabile.

Anche il costo va letto in modo meno romantico. Il prezzo competitivo può dipendere da economie di scala reali, ma anche da lock-in, conoscenza non trasferita e costi di uscita lasciati fuori dal business case. Se per cambiare partner occorre ricostruire inventario, documentazione, accessi, competenze e capacità operativa, il risparmio iniziale ha soltanto rinviato una fattura più scomoda.

L’exit strategy non è una clausola: è una prova di attraversamento

Molti contratti contengono una sezione sull’uscita. Poche organizzazioni sanno però dimostrare quanto durerebbe, quali dati verrebbero restituiti, in quale formato, chi manterrebbe il servizio durante la transizione e quali dipendenze non potrebbero essere trasferite. DORA chiede strategie di uscita per i servizi ICT a supporto di funzioni critiche o importanti; la logica è evitare che la cessazione o il deterioramento del fornitore producano un’interruzione aziendale.

Una prova credibile non richiede necessariamente una migrazione completa. Può verificare un campione: esportare configurazioni e log, ricostruire una procedura su un ambiente alternativo, trasferire una coda operativa, revocare gli accessi, misurare i tempi di consegna della documentazione e simulare l’indisponibilità di un subfornitore. Il risultato deve produrre evidenze, scostamenti e azioni correttive, non una spunta annuale.

Qui procurement, legale, rischio, sicurezza e operation devono lavorare sullo stesso scenario. Procurement governa obblighi e leve contrattuali; l’operation conosce dipendenze e tempi reali; sicurezza e rischio valutano dati, accessi e impatti; il business decide quale degrado sia accettabile. Se l’uscita appartiene soltanto al contratto, nessuno possiede davvero il passaggio.

Una service review che guarda oltre il primo anello

Nel prossimo ciclo di governance sceglierei un solo servizio critico e chiederei al fornitore di percorrerne la catena insieme all’organizzazione. Non una presentazione generale: componenti, soggetti coinvolti, dati trattati, localizzazioni, diritti di audit, cambiamenti previsti, punti di concentrazione e condizioni di trasferimento. Ogni dipendenza materiale dovrebbe avere un owner interno e un’evidenza aggiornata.

Poi trasformerei l’exit plan in tre scenari: uscita ordinata per scelta strategica, uscita accelerata per grave deterioramento e indisponibilità improvvisa di un anello della catena. Per ciascuno servono trigger, decision maker, capacità alternativa, dati da recuperare, durata tollerabile e criterio di completamento. Il test deve entrare nel continual improvement come entrano problemi ricorrenti e vulnerabilità.

La buona governance non pretende di eliminare ogni dipendenza. Un servizio moderno vive di ecosistemi e specializzazione. Pretende però che la dipendenza sia visibile, valutata e attraversabile. La domanda da portare alla prossima service review non è quindi soltanto se il fornitore ha rispettato lo SLA. È più scomoda e più utile: se domani dovessimo cambiare strada, quale parte del servizio sapremmo davvero portare con noi?