DORA, dalla carta alla prova: nel 2026 la resilienza operativa diventa esecutiva e risale la catena dei fornitori ICT

Un istituto può aver scritto le policy giuste: governance del rischio ICT definita, responsabile nominato, procedure archiviate. Poi arriva il momento della verità — un test di ripristino che non rientra nei tempi dichiarati, un fornitore cloud senza una strategia di uscita praticabile, il subappaltatore di un subappaltatore che nessuno aveva mappato. Il regolamento europeo DORA (UE 2022/2554) sulla resilienza operativa digitale nasce esattamente per spostare l’attenzione da ciò che è scritto a ciò che regge sotto stress. E nel 2026 quel passaggio ha smesso di essere teorico: è diventato una sequenza di scadenze, liste ufficiali e controlli.

Dal principio all’esecuzione

Pienamente applicabile dal 17 gennaio 2025, DORA è entrato nel 2026 nella fase che conta davvero: quella dell’esecuzione. Non basta più dichiarare di avere un programma di conformità; le autorità hanno iniziato a raccogliere dati, incrociarli e verificarli. Due fatti recenti lo rendono evidente.

Il primo. Il 18 novembre 2025 le tre Autorità europee di vigilanza — EBA, EIOPA ed ESMA — hanno pubblicato la prima lista dei fornitori terzi critici (CTPP): i grandi operatori ICT da cui dipende una fetta rilevante del sistema finanziario, ora sottoposti a una vigilanza diretta europea con un Lead Overseer assegnato. È il segnale che il regolamento guarda oltre le singole banche, alla concentrazione del rischio su pochi fornitori.

Il secondo, tutto italiano. Con comunicazione del 13 febbraio 2026, la Banca d’Italia ha fissato le tempistiche del registro delle informazioni sugli accordi contrattuali con i fornitori ICT: trasmissione tramite la piattaforma INFOSTAT entro il 15 marzo 2026, con dati riferiti al 31 dicembre 2025, e poi a cadenza annuale sempre al 15 marzo. Non è un elenco archiviato: è la fonte da cui le autorità estraggono la mappa delle dipendenze dell’intero settore.

Cinque pilastri, un’unica domanda

DORA poggia su cinque pilastri: gestione del rischio ICT, segnalazione degli incidenti gravi, test di resilienza operativa (fino ai Threat-Led Penetration Test per i soggetti più significativi), gestione del rischio di terze parti e condivisione delle informazioni sulle minacce. Dietro l’architettura c’è però una sola domanda, operativa e scomoda: se qualcosa si rompe, l’azienda è in grado di resistere, reagire e ripristinare entro tempi definiti? Non in linea di principio — misurandolo.

Il perimetro risale la catena

Il vero bersaglio del regolamento non sono soltanto le banche. Gli articoli 28-30 disciplinano il rapporto con i fornitori terzi ICT e cambiano la natura del contratto: clausole minime obbligatorie su livelli di servizio, sicurezza e continuità, diritti di audit e ispezione, obblighi di cooperazione durante gli incidenti, vincoli sul subappalto e — spesso il punto più trascurato — una strategia di uscita che permetta al cliente di cambiare fornitore senza interrompere il servizio.

Il risultato è a cascata: una software house, un provider cloud, un gestore di data center, un MSP o un operatore di sicurezza che serve un’entità finanziaria non può più considerarsi «esterno» al problema. Se il cliente è dentro il perimetro DORA, quelle clausole finiscono nel contratto del fornitore — e vanno onorate, non firmate e dimenticate.

DORA non chiede al fornitore ICT di dichiararsi affidabile: chiede di dimostrarlo, con contratti verificabili, ripristini provati e una via d’uscita già scritta.

Resilienza è ripristino provato

C’è una differenza sostanziale tra avere un piano di continuità e avere un piano che funziona. Il pilastro dei test esiste proprio per chiudere questa distanza: il ripristino va esercitato su base regolare, e i risultati vanno documentati. In Italia il processo di individuazione dei soggetti tenuti ai TLPT — i test di penetrazione guidati dalle minacce reali — è ancora in corso in Banca d’Italia, con una timeline operativa che si colloca a cavallo tra fine 2026 e inizio 2027. Ma il messaggio non riguarda solo i pochi soggetti «significativi»: per tutti, la resilienza dichiarata sulla carta e quella misurata sotto stress sono due cose diverse, e DORA premia la seconda.

Da non confondere con la NIS2: le entità finanziarie già soggette a DORA sono trattate come lex specialis e dispensate dagli adempimenti equivalenti della direttiva. Un fornitore ICT, però, può servire clienti su entrambi i fronti — la finanza sotto DORA, gli altri soggetti essenziali sotto NIS2 — e ritrovarsi a rispondere a due regimi di obblighi contrattuali che, nella sostanza, chiedono la stessa maturità operativa.

Il nostro punto di vista

Per un operatore ICT come ITCARMAT, DORA non è una norma da leggere dall’esterno: è una descrizione, piuttosto precisa, di come dovrebbe già lavorare chi eroga infrastruttura e servizi critici. La parte che consideriamo il cuore del regolamento — «resistere, reagire, ripristinare» — è il terreno su cui lavoriamo ogni giorno: un disaster recovery che si misura in ripristini provati e non in promesse, un presidio degli incidenti che rileva e reagisce in tempo utile, procedure e accessi tracciati che reggono a un audit.

È anche la ragione per cui trattiamo la continuità e la conformità come un unico modo di gestire l’infrastruttura, non come due voci separate: i managed services e il monitoraggio continuo del SOC sono il modo concreto in cui un fornitore diventa, per il suo cliente, un anello che regge invece di un rischio da mappare. Per le aziende della finanza — e per chi le serve — il 2026 è l’anno in cui questa differenza smette di essere una sfumatura e diventa una clausola.