DORA, la filiera sotto esame: cosa deve verificare il CdA

Nel 2025 le entità finanziarie europee hanno notificato 3.383 incidenti ICT rilevanti ai sensi di DORA. Circa un terzo ha avuto un impatto transfrontaliero e, soprattutto, i principali fattori scatenanti non sono stati gli attacchi cyber, ma i malfunzionamenti dei sistemi e gli eventi esterni.

Le stesse Autorità europee di vigilanza hanno collegato il dato alla necessità di rafforzare il third-party risk management e il controllo sui servizi esternalizzati. Per anni abbiamo chiamato “governo dei fornitori” cose molto diverse: un contratto quadro, una checklist di due diligence, un questionario rispedito compilato a metà.

Poi il lessico si è fatto scomodo, registro, subappalto, strategia di uscita, e nel 2026 la domanda che circola in ispezione non è più “avete una policy sui fornitori?”. È un’altra: “fatemi vedere come lo verificate”. Il 17 luglio 2026 quella domanda ha preso una data di scadenza.

Il 31 dicembre 2026 è una scadenza di filiera

Con la Comunicazione al mercato di quella data, replicata in pari data da IVASS, Banca d’Italia mette nero su bianco una constatazione tecnica, non retorica: i modelli di IA di ultima generazione individuano le vulnerabilità del software e generano contemporaneamente le modalità di sfruttamento, in tempi ridottissimi e senza competenze specialistiche. Si comprime l’intervallo tra scoperta e sfruttamento. Cresce l’asimmetria tra attaccanti e difensori.

La risposta richiesta non è documentale. Il Consiglio di Amministrazione, in seduta congiunta con il Collegio Sindacale, deve esaminare la Comunicazione e avviare una Relazione che, area per area, rappresenti esposizione, adeguatezza dei presidi, carenze e priorità, con un piano di lavoro su azioni, tempi e investimenti. Va individuato un punto di responsabilità aziendale da comunicare alla Vigilanza. Termine: 31 dicembre 2026.

Ora rileggete le sei aree: governance, igiene informatica, gestione degli asset e della superficie d’esposizione, vulnerabilità e patch, monitoraggio e difesa, test.

Per la maggior parte degli intermediari, cinque di quelle sei attività non si svolgono dentro casa: si svolgono dentro il perimetro di un fornitore. La Relazione la firma il vostro CdA; le evidenze le ha qualcun altro. E la Comunicazione lo dice: catene articolate su più livelli e concentrate in pochi operatori trasformano criticità circoscritte in problemi di ampia portata, e le iniziative degli intermediari devono essere supportate anche dai fornitori esterni e se quelle evidenze le chiedete a novembre, non arrivano per tempo.

Il registro dice “chi”. La Relazione chiede “quanto bene”

Il registro previsto dall’articolo 28, paragrafo 3, di DORA viene ancora trattato come un file da produrre e inviare, entro il 15 marzo di ogni anno, dati al 31 dicembre precedente, via INFOSTAT.

Il Regolamento di esecuzione (UE) 2024/2956 dice tutt’altro. Il registro si tiene a livello di entità, ma anche su base subconsolidata e consolidata, e i dati si legano attraverso quattro chiavi:

• riferimento dell’accordo contrattuale;
• identificativo dell’entità e del fornitore;
• identificativo della funzione;
• tipo di servizio ICT.

Non sono un tecnicismo di popolamento, sono la struttura logica del controllo. Dicono che l’unità di misura non è il fornitore, e nemmeno il contratto. È il servizio ICT collegato a una funzione.

Ma il registro resta un’anagrafica: dice chi c’è. La Relazione di dicembre chiede un giudizio di adeguatezza: quanto bene quel qualcuno fa il suo mestiere. Sono due oggetti diversi, e il secondo non si ricava dal primo, soprattutto se il registro lo compila chi gestisce i contratti e non chi possiede il rischio.

DORA e IA nella filiera dei fornitori: materialità, non onniscienza

Il Regolamento delegato (UE) 2025/532, GUUE del 2 luglio 2025, in attuazione dell’art. 30, par. 5, di DORA, sposta l’oggetto del controllo: non più il soggetto contrattualizzato, ma la filiera che eroga il servizio. Si incastra con il Regolamento delegato (UE) 2024/1773, che pretende un livello di garanzia dichiarato sull’efficacia del framework di rischio del fornitore, il riesame indipendente con inclusione nel piano di audit e le strategie di uscita.

Nessuna delle due norme chiede però l’onniscienza sull’ennesimo anello. Chiedono materialità: identificare chi eroga effettivamente il servizio o parti rilevanti di esso, e governare per eccezione tutto il resto. È la differenza tra un programma sostenibile e un cantiere permanente che brucia budget senza produrre assurance.

Cinque verifiche che reggono in Relazione

1. Perimetrare per servizio, non per contratto. Un accordo quadro può contenere quindici servizi, di cui tre critici. Trattarlo come unità di rischio significa sovra-controllare il banale e sotto-controllare il vitale.
2. Estendere la due diligence alla catena. Stratificazione, localizzazione di attività e dati, giurisdizione e regimi di accesso di autorità di paesi terzi, segregazione degli ambienti, concentrazione e sostituibilità. Dopo la firma il potere negoziale evapora.
3. Trasformare le clausole in leve. Notifica preventiva delle modifiche alla catena, opposizione motivata, audit e ispezione estesi ai subappaltatori, escalation degli incidenti lungo la filiera, assistenza all’uscita. Un diritto mai esercitato è, nei fatti, un diritto decaduto.
4. Leggere le certificazioni per quello che sono. ISO/IEC 27001, SOC 2 Type II, ISAE 3402 sono evidenze, non sostituti della verifica. Contano il perimetro certificato, comprende l’entità che eroga davvero il servizio, e le eccezioni rilevate.
5. Monitorare in continuo. Livelli di servizio, incidenti, patch, cambi di controllo, modifiche della catena intervenute tra due invii del registro. È in quell’intervallo che la mappa smette di corrispondere al territorio.

La concentrazione che il registro di primo livello non mostra

C’è un rischio che nessuna anagrafica di primo livello intercetta: tre fornitori diversi, contrattualizzati da tre funzioni diverse, che poggiano sullo stesso hyperscaler, nella stessa region. Sulla carta la diversificazione è impeccabile. Nella realtà, un singolo evento infrastrutturale li spegne insieme.

Questa concentrazione di quarto livello emerge solo da un’analisi condotta a livello consolidato: è per questo che il registro va tenuto anche su base subconsolidata e consolidata. Non è un dettaglio di reporting, è l’unico livello di osservazione a cui il fenomeno diventa visibile. Ed è esattamente ciò che la Comunicazione di luglio intende quando parla di catene concentrate in pochi operatori che trasformano criticità circoscritte in problemi di ampia portata.

Da qui un malinteso da smontare, spesso incoraggiato dai fornitori in fase di rinegoziazione: la sorveglianza europea sui fornitori critici non sposta di un millimetro la responsabilità. Il CTPP è sorvegliato dalle Autorità; il servizio resta governato da voi. E poiché le autorità possono in ultima istanza imporre di sospendere o risolvere il ricorso a quei servizi, il piano di uscita deve contemplare l’ipotesi in cui l’uscita non sia una vostra scelta, né avvenga nei vostri tempi.

La finestra di patch che i vostri contratti non reggono

Qui sta il punto operativo che la Comunicazione rende urgente, e che quasi nessuno ha tradotto in azione.

Banca d’Italia chiede di individuare rapidamente le vulnerabilità, applicare i rimedi in via prioritaria, mettere in sicurezza per primi i software open source e i sistemi accessibili dall’esterno, con attenzione agli zero-day. E di monitorare il traffico da e verso i fornitori terzi.

Andate a rileggere gli SLA di patching dei vostri contratti ICT. Sono stati scritti quando la finestra tra scoperta e sfruttamento si misurava in settimane. Oggi si misura in ore.

Tre domande, da porre per iscritto a ogni fornitore di servizi critici:

• in quanto tempo vi notifica una vulnerabilità critica sul proprio stack, e con quale canale;
• chi decide la priorità di remediation, e su quali criteri;
• cosa accade, contrattualmente, se quel termine non viene rispettato.

Se la risposta è “best effort”, non avete un problema tecnico. Avete un problema contrattuale, e va aperto adesso, perché una rinegoziazione richiede mesi, e dicembre è vicino.

C’è poi il rovescio della medaglia: la Comunicazione ammette l’uso di strumenti di difesa basati sull’IA, ma solo se coerenti con la strategia in materia e accompagnati da valutazione dei rischi specifici, monitoraggio del deterioramento delle prestazioni e supervisione umana. Chi introduce difese automatiche senza quei presidi non riduce il rischio: lo sposta, e lo rende meno visibile.

L’anello che nessuno ha negoziato

Intanto la catena si allunga dove la due diligence non guardava. Componenti di intelligenza artificiale nei prodotti dei fornitori, servizi inferenziali richiamati via API, modelli ospitati da soggetti terzi rispetto al terzo: anelli che entrano nella filiera senza passare da una firma, con un aggiornamento di release. Nuove dipendenze, nuove superfici di esposizione e, sul piano della sovranità del dato, nuove giurisdizioni affacciate su informazioni finanziarie. Governare la catena, oggi, significa sapere non solo chi eroga il servizio, ma dove, sotto quale legge e con quali componenti che nessuno ha mai negoziato.

Provare l’uscita, non solo la continuità

I test che coinvolgono solo il perimetro interno raccontano la metà comoda della storia. Servono prove end-to-end che includano il fornitore su scenari severi ma plausibili, perdita totale del servizio, non degrado, e prove di uscita: portabilità effettiva dei dati, ripartenza su una soluzione alternativa, tempi di migrazione misurati, non stimati. Un piano di uscita mai testato non è un controllo. È una dichiarazione d’intenti su carta intestata.

Chi possiede il rischio decide se il sistema funziona

Il rischio di terza parte non è un rischio di acquisto. Assegnarlo al procurement è la scorciatoia organizzativa più comune e più costosa: produce contratti conformi e servizi non governati.

La proprietà deve stare in capo al responsabile del servizio di business, con la funzione di rischio ICT come presidio metodologico. E l’accountability ultima resta dove la Comunicazione la colloca senza ambiguità: negli organi di amministrazione e gestione, ai quali si chiede di rivedere il RAF (Risk Appetite Framework) per incorporare i rischi delle tecnologie di frontiera, di annoverare al proprio interno competenze tecnologiche adeguate, anche in materia di IA, e di prevedere un budget per la propria formazione continua.

Tre patologie ricorrenti, riconoscibili a occhio nudo:

• la proprietà diffusa, in cui tutti controllano un pezzo e nessuno risponde del tutto;
• le evidenze non riutilizzabili, prodotte per l’ispezione e archiviate il giorno dopo;
• il disallineamento silenzioso tra ciò che il registro dichiara e ciò che l’architettura fa.

Cosa fare adesso, con dicembre alle porte

1. Riconciliare registro e architettura: per ogni funzione essenziale o importante, il servizio, il fornitore diretto e chi lo eroga materialmente.
2. Inviare la richiesta di evidenze ai fornitori critici sulle aree della Comunicazione al mercato in materia di resilienza operativa digitale e modelli avanzati di Intelligenza Artificiale, con termine e formato. Prima possibile.
3. Inventariare i diritti contrattuali e verificare se siano mai stati esercitati. L’esito è di solito imbarazzante: è per questo che è utile.
4. Programmare una prova di uscita su almeno un servizio critico. Una vera, con i tempi cronometrati.

Chi guida un intermediario non deve diventare un esperto di cloud. Deve diventare un decisore che pretende metodo, tracciabilità e capacità di ripartenza.

Perché la resilienza non si compra insieme al servizio: è l’unica parte della fornitura che resta, per intero, a carico di chi la ordina. E si misura in un solo modo, con ciò che sapete fare il giorno in cui il fornitore non c’è più.