Il Register of Information DORA è un registro strutturato di tutti gli accordi con fornitori ICT terzi e sub‑fornitori, che deve essere mantenuto aggiornato e trasmesso annualmente alle Autorità. Trattarlo come un file “una tantum” espone a rilievi, rigetti e rischi operativi crescenti.
Dalla prima ondata di invii del RoI è emerso un pattern chiaro: molte entità hanno rispettato la scadenza formale, salvo poi ritrovarsi in una “seconda fase” fatta di richieste di chiarimento, rilievi di data quality e reinvii correttivi. Banca d’Italia, ad esempio, ha previsto l’invio annuale del registro entro il 15 marzo tramite INFOSTAT, con controlli automatici e obbligo di reinvio in caso di anomalie sui dati trasmessi.
Il problema, nella maggior parte dei casi, non è la conoscenza del Regolamento, ma l’approccio con cui si governa l’informazione. Un RoI costruito a colpi di estrazioni locali ed Excel è fragile per definizione: non gestisce bene relazioni complesse, storici, varianti contrattuali, catene di sub‑fornitura. Quando arrivano i controlli – interni o da parte delle Autorità – l’organizzazione fatica a spiegare come è arrivata a certe classificazioni o perché due record apparentemente distinti descrivano lo stesso fornitore.
Un secondo elemento critico riguarda i fornitori di servizi ICT di terza parte (TPSP). DORA dedica l’intero Capo V all’ICT third‑party risk: identificazione dei fornitori critici, clausole contrattuali minime, diritti di audit, monitoraggio continuo. Senza un RoI “vivo”, capace di tracciare nel tempo chi eroga cosa, su quali funzioni critiche e con quali dipendenze, è impossibile avere una vista realistica sul rischio di concentrazione o sulla reale resilienza dell’ecosistema ICT.
In questo scenario, il vero pain point dei responsabili IT, risk e compliance non è produrre un file conforme agli ITS, ma riuscire a mantenere nel continuo un patrimonio dati coerente, interrogabile e riutilizzabile per tutte le esigenze DORA: incident reporting, ICT risk management, gestione delle terze parti.
Un RoI DORA governato richiede tre pilastri: un modello dati allineato agli ITS, un processo di aggiornamento continuo e una chiara attribuzione di responsabilità tra funzioni IT, Sourcing, Risk Management e Compliance. Senza questi elementi, anche la migliore tecnologia non risolve il problema alla radice.
Sul piano dei dati, il punto di partenza è la normalizzazione. Gli ITS sul Registro delle Informazioni, adottati dalla Commissione il 29 novembre 2024, fissano uno schema standard articolato per entità finanziarie, fornitori, servizi ICT, funzioni critiche, contratti e sub‑fornitori. Ogni campo va valorizzato secondo regole precise: domini codificati EBA, relazioni one‑to‑many e many‑to‑many coerenti, obblighi di completezza e coerenza inter‑tabellare. Un esempio concreto: un servizio di core banking erogato in cloud da un provider globale dovrà essere collegato sia alla funzione critica che abilita (ad esempio, pagamenti retail) sia al contratto e alle sedi di erogazione, con indicazione puntuale di eventuali sub‑fornitori infrastrutturali.
Il secondo pilastro è il processo. DORA chiede che il RoI sia mantenuto e aggiornato nel continuo, non solo “fotografato” a fine anno. Questo implica definire un workflow di onboarding, modifica e dismissione dei fornitori ICT che preveda passi obbligati: censimento iniziale dei contratti, classificazione di servizi e funzioni, validazione dei codici normativi, revisione periodica dei dati chiave. Ogni variazione rilevante – cambio di data center, introduzione di un sub‑fornitore, modifica degli SLA – deve generare un aggiornamento tracciato nel registro.
Il terzo pilastro riguarda le responsabilità. Nella pratica, gli errori di data quality spesso derivano da una governance diffusa ma non orchestrata: IT che gestisce i contratti, procurement che negozia le clausole, risk che valuta l’impatto, compliance che compila il tracciato. Una soluzione concreta è assegnare la “data ownership” dei vari domini (fornitori, servizi, funzioni critiche, contratti) e introdurre controlli di qualità integrati nel processo. Ad esempio, nessun contratto dovrebbe essere reso operativo se non è stato associato a un fornitore censito nel RoI e a una funzione aziendale con livello di criticità definito.
Passare da Excel a una piattaforma dedicata al RoI non è un vezzo tecnologico, ma una scelta strutturale per ridurre errori, tempi di gestione e rischi di non conformità. I criteri di selezione devono partire dalle richieste specifiche di DORA e degli ITS, non da mere preferenze IT.
Uno strumento adeguato deve innanzitutto modellare l’intero ciclo di vita dei rapporti con i fornitori ICT: dalla fase di gara alla dismissione del servizio. In pratica significa poter rappresentare, in un’unica base dati, contratti, addendum, servizi, funzioni critiche, sub‑fornitori, domini EBA e codici regolamentari, evitando duplicazioni. L’esperienza sul campo mostra come, nei registri costruiti manualmente, duplicazioni di fornitori e servizi possano superare il 20–30% del totale, rendendo ingestibili i controlli di coerenza.
Un secondo criterio riguarda i controlli di data quality in tempo reale. La piattaforma deve impedire, già in fase di inserimento, errori tipici come campi obbligatori formalmente compilati ma semanticamente errati, relazioni non consentite dallo schema normativo o mancata valorizzazione di attributi chiave per i fornitori critici. Alcune soluzioni avanzate traducono automaticamente i codici EBA in etichette “parlanti”, riducendo sensibilmente il tasso di errore nella scelta del dominio corretto.
Fondamentali sono anche la produzione automatica del tracciato segnaletico conforme al Regolamento di esecuzione (UE) 2024/2956 e la gestione dello storico. La piattaforma deve consentire di rigenerare, in qualsiasi momento, la “copia autentica” del RoI a una certa data – ad esempio il registro al 31/12/2025 esattamente come trasmesso nel marzo 2026 – per audit interni e ispezioni delle Autorità. Questo requisito, difficilmente realizzabile con file gestiti manualmente, diventa essenziale man mano che aumentano richieste di chiarimento e controlli a campione.
Infine, per gli intermediari con esigenze meno continuative, un modello SaaS “one‑shot” per la gestione della segnalazione annuale può rappresentare un compromesso efficace: caricamento dei file storici, normalizzazione automatica, supporto specialistico alla revisione dei dati e generazione del nuovo tracciato pronto per INFOSTAT. In molti casi, trasformare poche settimane critiche di lavoro manuale in un processo guidato consente di liberare risorse interne verso attività a maggior valore, come l’analisi dei rischi di terza parte.
Per essere davvero utile, il Register of Information DORA deve dialogare con i processi di ICT risk management e con il framework di gestione dei TPSP. In assenza di questa integrazione, il RoI resta un contenitore di record, incapace di supportare decisioni di governance e valutazioni di rischio.
Un primo esempio concreto è la valutazione del rischio di concentrazione. DORA richiede alle entità finanziarie di analizzare l’esposizione verso singoli fornitori ICT o cluster tecnologici, soprattutto in ambito cloud. Collegando il RoI ai profili di rischio dei fornitori, è possibile individuare rapidamente situazioni critiche, come l’eccessiva dipendenza da un unico hyperscaler per servizi considerati “critici o importanti” o la presenza di sub‑fornitori comuni a più TPSP.
Un secondo caso riguarda la gestione delle vulnerabilità e degli incidenti ICT. Se un fornitore segnala un incidente significativo su un servizio di payment, l’organizzazione deve poter risalire in pochi minuti a tutte le funzioni critiche impattate, agli SLA contrattuali, alle sedi di erogazione e agli eventuali requisiti regolamentari specifici. Un RoI integrato con i processi di incident management permette di automatizzare parte di questa analisi e di documentare, in modo tracciabile, le decisioni prese.
Infine, il RoI può diventare la base informativa per la risk‑based selection dei fornitori. In fase di gara, ad esempio, i dati storici su incidenti, rilievi, cambi contrattuali e sub‑fornitori di un TPSP possono essere utilizzati come criteri oggettivi per la valutazione comparativa, andando oltre i classici parametri di prezzo e servizio.
La trasformazione del RoI DORA da adempimento a asset operativo richiede un lavoro di change management che va oltre l’implementazione tecnica. Molte difficoltà emergono nel momento in cui si chiede alle funzioni coinvolte di cambiare abitudini consolidate nella gestione dei fornitori ICT.
Un primo passo consiste nel definire in modo esplicito i ruoli: chi è responsabile del modello dati, chi governa il processo di aggiornamento, chi esegue i controlli di qualità, chi valida le informazioni ai fini segnaletici. Nella pratica, una combinazione efficace vede IT e Sourcing come owner operativi dei dati su contratti e servizi, Risk Management come owner delle informazioni su criticità e impatti, Compliance come garante della coerenza regolamentare e della produzione del tracciato.
Sul piano delle competenze, DORA rende evidente quanto siano necessarie figure ibride: professionisti capaci di comprendere sia il linguaggio tecnico delle architetture ICT sia quello regolamentare dei RTS/ITS, degli articoli 28–44 e dei vademecum delle Autorità. Investire in formazione mirata – ad esempio workshop congiunti IT–Risk–Compliance sui casi d’uso reali del RoI – riduce drasticamente gli errori derivanti da incomprensioni terminologiche.
Infine, il change management deve prevedere metriche chiare per misurare l’efficacia del nuovo modello: numero di rilievi di data quality post‑invio, tempi medi di risposta alle richieste delle Autorità, percentuale di contratti ICT correttamente mappati nel RoI, riduzione delle duplicazioni di fornitori e servizi. Monitorare questi indicatori nel tempo consente di dimostrare, anche al top management, che l’investimento in dati, processi e strumenti dedicati genera benefici misurabili in termini di rischio ridotto e di efficienza operativa.
Quando il Register of Information DORA è progettato come componente strutturale della governance ICT, l’obbligo regolamentare si trasforma in un vantaggio competitivo. Le organizzazioni che riescono a mappare con precisione la propria catena di fornitura ICT dispongono di una vista che va ben oltre la compliance annuale.
In primo luogo, una base dati robusta abilita decisioni di sourcing più consapevoli: la valutazione dei TPSP non si limita alla verifica ex‑ante, ma diventa un processo dinamico supportato da evidenze oggettive su performance, incidenti, cambi tecnologici e rischio di concentrazione. In secondo luogo, la stessa informazione può alimentare altre iniziative di trasformazione digitale e di sicurezza, dal redesign delle architetture cloud‑native ai programmi di cyber‑resilience, senza dover ricostruire da zero la mappatura dei servizi.
Nel medio periodo, la capacità di rispondere in modo rapido e documentato alle richieste delle Autorità – grazie a un RoI governato e a una gestione strutturata dei fornitori ICT – riduce non solo il rischio di sanzioni, ma anche quello reputazionale. In un settore, come quello finanziario, in cui la fiducia è un asset critico, questa affidabilità operativa diventa parte integrante della value proposition verso clienti, partner e mercati.
In sintesi, il passaggio da “file per la scadenza” a “registro vivo” è il vero spartiacque della maturità DORA. Chi investe oggi in dati di qualità, processi chiari e piattaforme dedicate sta di fatto costruendo l’infrastruttura informativa su cui poggeranno le decisioni di governance ICT dei prossimi anni, trasformando un obbligo normativo in un asset strategico e sostenibile.