Il Digital Operational Resilience Act (DORA) è entrato pienamente in vigore il 17 gennaio 2025. Tra i suoi obblighi principali vi è il requisito per gli enti finanziari di mantenere un Registro delle Informazioni strutturato — un inventario completo di tutti gli accordi di servizi TIC di terze parti, inclusi i subappaltatori e i servizi infragruppo.
Questa guida spiega cos'è il Registro delle Informazioni DORA, quali organizzazioni sono tenute a mantenerlo, quali campi dati sono obbligatori e come strutturare un modello operativo sostenibile. Che tu sia un responsabile della conformità che prepara la prima comunicazione, un risk manager che verifica la qualità dei dati o un vendor manager alle prese con la responsabilità interdepartimentale, questa guida ti accompagna passo dopo passo.
Imparerai: cosa si aspettano i regolatori, quali enti rientrano nell'ambito di applicazione, quali sono le categorie di dati obbligatorie, chi dovrebbe essere responsabile di ciascun campo, i sette passi per costruire il registro, gli errori più comuni che causano il rifiuto della comunicazione e come gli strumenti dedicati possono semplificare la manutenzione continuativa.
Cos'è il Registro delle Informazioni DORA?
Il Registro delle Informazioni DORA (RdI) è un insieme di dati strutturato che gli enti finanziari devono compilare e mantenere ai sensi dell'articolo 28, paragrafo 3, del Regolamento (UE) 2022/2554. Registra ogni accordo di servizi TIC di terze parti in essere — dai fornitori di infrastrutture cloud alle piattaforme SaaS, dai servizi di sicurezza gestiti ai gestori dei pagamenti e alle relazioni TIC infragruppo.
Lo scopo del registro è di vigilanza. Le Autorità Nazionali Competenti (ANC) e le Autorità di Vigilanza Europee (ABE, EIOPA, ESMA) utilizzano il registro per valutare il panorama delle dipendenze TIC di un ente, identificare il rischio di concentrazione e monitorare la postura di resilienza operativa del settore finanziario nel suo complesso. Le ESA pubblicano una relazione aggregata annuale basata sui dati comunicati dalle imprese in tutta l'UE.
Finalità regolatoria
DORA va oltre i tradizionali registri di esternalizzazione. I requisiti del Registro delle Informazioni sono definiti nelle Norme tecniche di regolamentazione congiunte sul registro delle informazioni ai sensi degli articoli 28(9) e 30(5) del DORA (JC 2023 84). Le NTR specificano i campi dati esatti, la cardinalità e le regole di validazione. Stabiliscono inoltre che il registro sia mantenuto costantemente aggiornato — non solo al momento della comunicazione.
Segnalazione di vigilanza
Gli enti finanziari sono tenuti a fornire il registro alla propria ANC su base annuale e su richiesta in qualsiasi momento. L'ANC può trasmettere i dati all'ESA competente. Le comunicazioni devono essere conformi ai modelli di dati prescritti (tipicamente in formato CSV o XBRL) e la validazione segnala campi mancanti, identificatori incoerenti ed errori di integrità referenziale.
Supervisione del rischio TIC di terze parti
Il registro alimenta diversi altri obblighi DORA. Le valutazioni di criticità, le strategie di uscita e le revisioni contrattuali fanno tutte riferimento allo stesso inventario di terze parti. Costruire correttamente il registro non è quindi un esercizio isolato — è il fulcro dell'intero quadro di gestione del rischio TIC di terze parti.
Resilienza operativa
Nella sua essenza, il Registro delle Informazioni DORA è uno strumento di resilienza operativa. Costringendo gli enti a mappare e documentare ogni dipendenza TIC — incluse le quarte parti — crea la visibilità che il management e i regolatori possono utilizzare per valutare se il fallimento di un singolo fornitore possa causare un'interruzione sistemica. Il registro non è solo documentazione di conformità; è uno strumento di gestione del rischio che supporta gli obblighi di pianificazione della continuità operativa e della strategia di uscita.
Chi deve mantenere un Registro DORA?
DORA si applica a un'ampia gamma di enti finanziari operanti nell'Unione Europea. L'articolo 2 del Regolamento definisce l'ambito di applicazione, che copre la maggior parte degli istituti finanziari regolamentati.
Enti creditizi
Banche e istituti di credito ipotecario autorizzati ai sensi della CRD.
Imprese di investimento
Imprese di investimento autorizzate ai sensi di MiFID II che forniscono servizi finanziari.
Istituti di pagamento
Istituti di pagamento e di moneta elettronica autorizzati ai sensi di PSD2.
Imprese di assicurazione
Assicuratori e riassicuratori autorizzati ai sensi di Solvency II.
Fornitori di servizi per cripto-attività
CASP autorizzati ai sensi di MiCA a partire dal loro onboarding supervisionato.
CCP, CSD e repertori di dati
Controparti centrali, depositari centrali di titoli e fornitori di servizi di comunicazione dati.
Il principio di proporzionalità
DORA riconosce che non si può pretendere da un piccolo istituto di pagamento la stessa infrastruttura di resilienza operativa di una banca di rilevanza sistemica. L'articolo 4 introduce la proporzionalità: le micro-imprese e le entità di piccole dimensioni beneficiano di un regime semplificato che riduce alcuni requisiti di documentazione e governance, preservando tuttavia l'obbligo fondamentale del registro.
Esenzioni
Le micro-imprese (meno di 10 dipendenti e fatturato annuo o bilancio inferiore a 2 milioni di euro) beneficiano di un regime DORA semplificato. Sono comunque tenute a mantenere un registro, ma i requisiti in materia di governance, test e segnalazione sono meno stringenti. Anche le micro-imprese devono identificare i servizi TIC critici e garantire protezioni contrattuali di base.
Gli enti che operano al di fuori dell'UE ma forniscono servizi a enti finanziari dell'UE non sono direttamente soggetti al DORA — ma i loro clienti lo sono e devono garantire che siano in vigore contratti e valutazioni del rischio conformi al DORA per questi accordi.
Quali informazioni devono essere incluse?
Le NTR congiunte specificano un modello di dati dettagliato per il Registro delle Informazioni. La tabella seguente riassume le principali categorie di dati e gli esempi di quanto richiesto da ciascuna.
| Categoria | Esempi |
|---|---|
| Informazioni sul fornitore | Denominazione legale, LEI, paese di incorporazione, appartenenza al gruppo |
| Servizi TIC | Hosting, SaaS, MSP, supporto IT, servizi cloud, elaborazione pagamenti |
| Classificazione della criticità | Critico / Non critico, funzione o processo supportato |
| Dettagli contrattuali | Data di inizio, data di fine, condizioni di rinnovo, periodo di preavviso per la risoluzione |
| Subappaltatori | Fornitori TIC di quarta parte, catene di subappalto, paese di operatività |
| Strategia di uscita | Stato del piano di uscita, fornitori alternativi identificati, cronologia della migrazione |
| Valutazione del rischio | Valutazioni del rischio collegate, rating del rischio, data dell'ultima valutazione |
Informazioni sul fornitore
Ogni terza parte TIC deve essere identificata tramite un identificatore di entità legale (LEI) ove disponibile. Devono essere registrati la denominazione legale, il paese e la struttura del gruppo del fornitore. L'utilizzo di identificatori di entità coerenti e validati è fondamentale — le autorità di vigilanza li utilizzano per aggregare i dati tra le imprese e identificare il rischio di concentrazione. I nomi informali, i nomi commerciali o le abbreviazioni non sono sufficienti.
Servizi TIC
Per ogni accordo, è necessario descrivere i servizi TIC forniti. Le NTR utilizzano un vocabolario controllato per i tipi di servizio. Le categorie comuni includono: servizi di cloud computing, analisi dei dati, colocation in data center, manutenzione e supporto software, servizi IT gestiti, servizi di cybersecurity e servizi di pagamento. Ogni accordo di servizio viene registrato separatamente, anche se fornito dallo stesso fornitore.
Classificazione della criticità
Determinare se un servizio TIC supporta una funzione critica o importante (FCI) è una delle decisioni più rilevanti nel registro. I servizi critici richiedono una supervisione più intensa, requisiti contrattuali più rigorosi e documentazione obbligatoria della strategia di uscita. La classificazione deve essere basata su una valutazione dell'impatto documentata — non su un giudizio generico — e riesaminata almeno annualmente o in caso di cambiamenti rilevanti.
Dettagli contrattuali
Le date di inizio e fine contratto, le condizioni di rinnovo e i periodi di preavviso devono essere accurati e allineati ai registri di gestione dei contratti. Le autorità di vigilanza utilizzano questi dati per valutare il rischio di lock-in e la concentrazione. I contratti scaduti o rinnovati automaticamente senza revisione sono una causa comune di errori di qualità.
Subappaltatori
DORA estende l'obbligo di registrazione ai subappaltatori — spesso chiamati quarte parti — che supportano l'erogazione di un servizio TIC critico o importante. È necessario identificare questi subappaltatori, il loro paese di operatività e annotare eventuali dipendenze rilevanti. Ciò richiede un coinvolgimento attivo dei fornitori primari per ottenere la divulgazione delle loro catene di fornitura.
Strategia di uscita
Per ogni accordo che supporta una funzione critica o importante, il registro deve indicare se esiste una strategia di uscita documentata, lo stato dell'identificazione di fornitori alternativi e se il piano di uscita è stato testato. Molte organizzazioni dispongono di strategie di uscita come concetto, ma mancano del dettaglio specifico per servizio e testato che DORA richiede.
Valutazione del rischio
Il registro deve collegare ogni accordo a una valutazione del rischio. Ciò include il rating complessivo del rischio, la data della valutazione più recente e le eventuali azioni di rimedio aperte. Il registro del rischio fornisce ai revisori e alle autorità di vigilanza la prova che l'ente sta gestendo attivamente — e non solo documentando — le proprie dipendenze TIC.
Modello di ownership del Registro DORA
Una delle cause più comuni della scarsa qualità del registro è l'assenza di un modello di responsabilità chiaro. Il Registro delle Informazioni DORA è per natura interfunzionale: i dati che richiede spaziano tra ambiti legale, approvvigionamento, rischio, sicurezza delle informazioni e operazioni aziendali. Nessun singolo dipartimento può mantenerlo da solo.
Legale
Titolarità dei contratti, legge applicabile, clausole di risoluzione e diritti contrattuali di accesso e audit. Il dipartimento legale deve validare le date contrattuali, i periodi di preavviso e confermare la presenza delle disposizioni richieste dal DORA in ciascun accordo.
Approvvigionamento e gestione dei fornitori
Identificazione dei fornitori, verifica del LEI, richieste di divulgazione dei subappaltatori e monitoraggio dei rinnovi. L'approvvigionamento detiene tipicamente l'elenco principale dei fornitori ed è nella posizione migliore per identificare i nuovi accordi prima che compaiano nel registro.
Sicurezza delle informazioni
Rating del rischio, valutazioni della sicurezza, collegamento agli incidenti e postura di sicurezza dei subappaltatori. I team di sicurezza delle informazioni detengono i risultati più recenti della due diligence sui fornitori e sono responsabili della validazione dei dati tecnici sul rischio.
Responsabili di business
Criticità del servizio, funzioni supportate e dipendenze operative. I responsabili di business sono nella posizione migliore per valutare se un servizio supporta una funzione critica o importante — questo giudizio non può essere espresso centralmente senza il contributo del business.
Conformità e supervisione regolamentare
Completezza complessiva del registro, preparazione delle comunicazioni e rapporti con l'ANC. La conformità deve essere titolare del framework di governance — le regole di qualità, le cadenze di revisione e i percorsi di escalation — anche se non è titolare dei singoli campi dati.
Un modello di ownership efficace definisce, per ciascun campo dati, quale dipartimento fornisce il dato, quale lo valida e con quale frequenza. Questo viene tipicamente documentato in una matrice RACI. Senza questa chiarezza, il registro si deteriorerà: i campi diventano obsoleti, sorgono conflitti tra le fonti e nessuno si assume la responsabilità degli errori di qualità.
Errori comuni nel Registro DORA
Queste sono le cause più frequenti di errori di qualità del registro e di rifiuti delle comunicazioni, basate sull'esperienza di implementazione presso gli enti finanziari.
1. Subappaltatori mancanti
La maggior parte delle imprese ha un quadro chiaro dei propri fornitori TIC diretti, ma una scarsa conoscenza delle quarte parti. Se il proprio fornitore cloud esternalizza l'elaborazione dei dati a un sub-responsabile, tale relazione deve figurare nel registro per i servizi critici. La mancata registrazione dei subappaltatori è uno degli errori di validazione più frequentemente segnalati dalle autorità di vigilanza.
2. Voci duplicate dei fornitori
Lo stesso fornitore che compare sotto nomi, identificatori o entità legali diversi è un problema di qualità dei dati che si propaga nell'intero registro. I calcoli del rischio di concentrazione diventano inaffidabili. Utilizzare codici LEI validati e un master vendor canonico per evitare la proliferazione di duplicati.
3. Classificazioni di criticità errate
Classificare eccessivamente i servizi come non critici riduce l'onere di supervisione ma crea rischi regolamentari. Sottoclassificare i servizi critici è un errore di conformità rilevante. Le classificazioni devono essere supportate da valutazioni dell'impatto documentate — non effettuate informalmente da chiunque stia compilando il foglio di calcolo.
4. Dati contrattuali obsoleti
Date di scadenza del contratto già passate, condizioni di rinnovo che non riflettono più l'accordo attuale e periodi di preavviso per la risoluzione mancanti indicano un registro non mantenuto. Questo è particolarmente comune quando il registro è stato costruito una sola volta come progetto e non è stato integrato nei processi continuativi di gestione dei contratti.
5. Nessun modello di ownership chiaro
Senza una responsabilità documentata sui dati, il registro diventa di nessuno. Quando i campi sono errati o mancanti, non esiste un percorso chiaro per la risoluzione. Le organizzazioni che hanno costruito il registro come progetto di conformità anziché come strumento operativo vivente quasi sempre si trovano di fronte a questo problema.
6. Piani di uscita mancanti
La documentazione della strategia di uscita è obbligatoria per i servizi critici, ma molte organizzazioni dispongono solo di una politica di uscita generica anziché di piani specifici per servizio. DORA richiede di poter dimostrare un percorso di transizione plausibile per ogni accordo critico — una dichiarazione generica di voler trovare un fornitore alternativo non è sufficiente.
Come costruire un Registro DORA passo dopo passo
La costruzione di un Registro delle Informazioni DORA pronto per la trasmissione è un progetto articolato in sette fasi distinte. Ogni fase ha deliverable e dipendenze chiari.
Fase 1
Definire l'ambito
Identificare quali entità legali all'interno del gruppo rientrano nell'ambito del DORA e se è richiesta una segnalazione consolidata o a livello di singola entità. Confermare con la propria ANC il formato di comunicazione richiesto. Documentare i servizi in ambito, inclusi gli accordi infragruppo, e stabilire quali funzioni sono candidate alla classificazione di criticità. La definizione dell'ambito è il fondamento — gli errori in questa fase si propagano in ogni fase successiva.
Fase 2
Censire i fornitori TIC
Compilare un elenco completo di tutti gli accordi di servizi TIC di terze parti. Le fonti includono: registri dei contratti, sistemi di contabilità fornitori, inventari delle risorse IT, elenchi dei fornitori di sicurezza e interviste con i responsabili di business. Validare le denominazioni legali delle entità confrontandole con i registri LEI. Identificare i fornitori infragruppo e verificare se sono coperti da accordi di servizio interni. In questa fase, la completezza conta più dell'accuratezza — i dati si possono correggere; non si può segnalare ciò che non si è trovato.
Fase 3
Classificare i servizi
Per ogni accordo, determinare se supporta una funzione critica o importante. Collaborare con i responsabili di business per valutare l'impatto di un'interruzione del servizio. Documentare la motivazione. Applicare il vocabolario controllato dei tipi di servizio delle NTR. Laddove un unico contratto preveda più servizi, registrare ciascun servizio separatamente. Segnalare gli accordi che richiedono la divulgazione dei subappaltatori e avviare le richieste ai fornitori.
Fase 4
Assegnare le responsabilità
Creare una matrice RACI che mappi ciascun campo dati a un owner responsabile. Confermare la responsabilità con ciascun dipartimento. Definire la cadenza di revisione per ogni campo — alcuni campi (come le date del contratto) cambiano solo al rinnovo; altri (come i rating del rischio) devono essere rivisti trimestralmente. Integrare gli aggiornamenti del registro nei processi esistenti: approvazione dei contratti, autorizzazione degli acquisti, cicli di revisione dei fornitori. La responsabilità senza integrazione nei processi non sopravviverà al primo ciclo annuale.
Fase 5
Validare la qualità dei dati
Eseguire controlli sistematici di qualità su tutti i campi dati prima di considerare il registro pronto per la trasmissione. I controlli devono riguardare: completezza dei campi obbligatori, valori di vocabolario controllato validi, logica delle date (la data di fine deve essere successiva alla data di inizio, nessun contratto scaduto senza registrazione di rinnovo), integrità referenziale (ogni servizio critico deve essere collegato a un record di strategia di uscita), rilevamento dei fornitori duplicati e completezza dei subappaltatori per i servizi critici.
Fase 6
Stabilire la governance
Definire il modello di governance continuativa. Ciò include: una revisione mensile o trimestrale della qualità con tutti i data owner; un percorso di escalation per i problemi di qualità irrisolti; un processo di gestione delle modifiche per accordi nuovi, modificati o risolti; una revisione annuale completa delle classificazioni di criticità; e uno sprint di validazione pre-comunicazione prima di ogni finestra di segnalazione regolamentare. La governance deve essere documentata in una policy o procedura operativa che sopravviva al turnover del personale.
Fase 7
Preparare le comunicazioni regolamentari
Esportare il registro nel formato richiesto dalla propria ANC (tipicamente CSV allineato ai modelli di dati JTS o XBRL). Eseguire il set di regole di validazione ESA sull'esportazione prima della trasmissione — gli errori rilevati internamente comportano costi di gran lunga inferiori rispetto a quelli segnalati dall'autorità di vigilanza. Conservare l'artefatto della comunicazione e un timestamp. Dopo la trasmissione, trattare qualsiasi feedback dell'ANC come un'opportunità di miglioramento della qualità e aggiornare il processo di governance di conseguenza.
Esempio di modello del Registro DORA
La struttura seguente mostra una riga rappresentativa di un Registro delle Informazioni DORA. Ogni riga rappresenta un singolo accordo di servizi TIC. Un unico fornitore può comparire in più righe se eroga diversi servizi distinti.
| Campo | Valore di esempio |
|---|---|
| Fornitore | Acme Cloud Services B.V. |
| LEI | 5493001KJTIIGC8Y1R12 |
| Servizio | Cloud Infrastructure (IaaS) |
| Criticità | Critico |
| Responsabile di business | Head of IT Operations |
| Inizio contratto | 2022-01-01 |
| Fine contratto | 2027-12-31 |
| Subappaltatori | DataStore GmbH (DE), NetOps Ltd (IE) |
| Strategia di uscita | Documentata — alternativa identificata, piano testato l'ultima volta a novembre 2024 |
| Rating del rischio | Alto |
| Data dell'ultima revisione | 2025-03-15 |
Registro DORA vs Registri di esternalizzazione tradizionali
Molti enti finanziari mantengono già una qualche forma di registro delle esternalizzazioni o dei fornitori — spesso costruito per soddisfare le linee guida EBA in materia di esternalizzazione o i requisiti interni di approvvigionamento. Il Registro delle Informazioni DORA è significativamente più esigente. La tabella seguente evidenzia le principali differenze.
| Dimensione | Registro tradizionale | Registro DORA |
|---|---|---|
| Finalità principale | Monitoraggio dei fornitori e gestione della spesa | Resilienza operativa e segnalazione di vigilanza |
| Ambito | Tutti i fornitori o servizi esternalizzati | Tutti gli accordi TIC, inclusi quelli infragruppo |
| Profondità dei dati | Focus su contratto e costi | Rischio, dipendenza, subappaltatori e dati sulla strategia di uscita |
| Segnalazione | Solo interno | Comunicazione annuale obbligatoria alle autorità di vigilanza |
| Formato | Forma libera (Word, Excel) | Modelli prescritti con regole di validazione |
| Quarte parti | Di solito non registrate | Obbligatorie per i servizi critici |
| Criticità | Limitata o informale | Formalmente valutata e documentata |
| Frequenza di aggiornamento | Annuale o su base progettuale | Continuo, basato sugli eventi con revisione periodica |
Se la propria organizzazione mantiene già un registro di esternalizzazione EBA, questo costituisce un utile punto di partenza — ma tipicamente coprirà solo il 60-70% di quanto richiesto dal DORA. Le lacune si trovano di solito nei dati sui subappaltatori, nel collegamento alla strategia di uscita, nella formalità della criticità e nel formato di comunicazione regolamentare. Un'analisi dei gap rispetto al modello di dati delle NTR è il primo passo consigliato.
Come RiskNow aiuta a mantenere un Registro DORA
RiskNow è una piattaforma GRC realizzata da professionisti che hanno implementato programmi DORA in enti finanziari. La piattaforma offre un modulo dedicato al Registro delle Informazioni che aiuta a mantenere un inventario completo delle terze parti, a tracciare le dipendenze della catena di fornitura e a produrre output regolamentari pronti per la trasmissione.
Registro delle terze parti
Mantieni un registro strutturato delle terze parti TIC con dati sull'entità legale, LEI, mappature dei servizi, classificazione della criticità, dettagli del ciclo di vita contrattuale e owner dei campi responsabili.
Visibilità sulla catena di fornitura
Mappa i subappaltatori e le quarte parti nell'intera catena di fornitura TIC, collega le dipendenze ai servizi critici e mantieni un registro verificabile di dove si trovano i rischi di concentrazione e resilienza.
Reportistica sulla qualità dei dati (100+ controlli)
Esegui report sulla qualità dei dati con più di 100 controlli automatizzati che coprono completezza, valori controllati, rilevamento dei duplicati, logica delle date e integrità referenziale prima della trasmissione.
Export regolamentari (XBRL / CSV)
Esporta i dati del registro in formati XBRL e CSV pronti per la regolamentazione, allineati ai modelli di vigilanza, con validazione pre-esportazione per individuare i problemi prima dell'invio.
Collegando terze parti, relazioni nella catena di fornitura, contratti, valutazioni del rischio e incidenti in un unico modello, RiskNow riduce la riconciliazione manuale e aiuta i team a mantenere il registro accurato tra un ciclo annuale di comunicazione e l'altro.
Domande frequenti
Cos'è il Registro delle Informazioni DORA?
Il Registro delle Informazioni DORA è un inventario strutturato di tutti gli accordi di servizi TIC di terze parti mantenuto da un ente finanziario ai sensi dell'articolo 28, paragrafo 3, del Regolamento (UE) 2022/2554. Comprende fornitori, servizi, criticità, contratti, subappaltatori e valutazioni del rischio.
Il Registro DORA è obbligatorio?
Sì. Tutti gli enti finanziari in ambito sono tenuti a mantenere un Registro delle Informazioni e a fornirlo all'autorità nazionale competente annualmente o su richiesta. La non conformità può comportare misure di vigilanza, tra cui la divulgazione pubblica, sanzioni pecuniarie e ordini di rimedio.
Con quale frequenza deve essere aggiornato il Registro DORA?
Il registro deve essere mantenuto costantemente aggiornato. In pratica ciò significa aggiornamenti basati sugli eventi per nuovi accordi, modifiche contrattuali rilevanti e servizi terminati — integrati da una revisione periodica (mensile o trimestrale) della qualità e da un aggiornamento annuale completo in vista della finestra di comunicazione alle autorità di vigilanza.
Cosa sono i servizi TIC critici?
I servizi TIC critici sono quelli che supportano una funzione critica o importante (FCI) — il cui fallimento o deterioramento comprometterebbe in modo significativo la conformità regolamentare, la solidità finanziaria o l'erogazione dei servizi dell'ente. La criticità deve essere valutata attraverso un'analisi dell'impatto documentata e riesaminata almeno annualmente.
I subappaltatori devono essere inclusi nel registro?
Sì, per i servizi critici e importanti. È necessario identificare i subappaltatori (quarte parti) che fanno parte della catena di erogazione di un servizio critico e includerli nel registro. Ciò richiede un coinvolgimento proattivo dei fornitori primari per ottenere la divulgazione dei subappaltatori.
In cosa si differenzia DORA dalle linee guida EBA in materia di esternalizzazione?
Le linee guida EBA in materia di esternalizzazione si concentrano principalmente sulla governance, sui requisiti contrattuali e sugli obblighi di notifica per l'esternalizzazione rilevante. DORA va oltre: copre tutti gli accordi TIC (non solo l'esternalizzazione rilevante), obbliga la divulgazione dei subappaltatori per i servizi critici, richiede strategie di uscita formalmente documentate e introduce un registro standardizzato di segnalazione alle autorità di vigilanza con campi dati prescritti.
È possibile utilizzare Excel per mantenere il Registro DORA?
Tecnicamente sì, ma in pratica crea un rischio operativo significativo. I registri su Excel presentano difficoltà con il controllo degli accessi, la gestione delle versioni, l'integrità referenziale tra tabelle e le piste di audit. Per entità di piccole dimensioni con meno di 20-30 accordi, un foglio di calcolo strutturato potrebbe essere sufficiente nel breve periodo. Per enti più grandi, è fortemente raccomandato l'utilizzo di una piattaforma dedicata.
Quali campi dati sono richiesti dal Registro DORA?
Le NTR congiunte specificano i campi obbligatori, tra cui: denominazione legale e LEI del fornitore, tipo di servizio TIC, funzione supportata, classificazione della criticità, date di inizio e fine contratto, periodo di preavviso per la risoluzione, dettagli dei subappaltatori (per i servizi critici), stato della strategia di uscita e collegamento alla valutazione del rischio. Consulta la sezione "Quali informazioni devono essere incluse?" qui sopra per una panoramica completa.
Cosa succede se il Registro DORA è incompleto al momento della comunicazione?
Un registro incompleto o inaccurato può comportare: la restituzione della comunicazione da parte dell'ANC per correzione, un dialogo formale di vigilanza sulle carenze di governance dei dati, o — in caso di problemi persistenti — l'escalation delle misure di vigilanza. Le inadempienze reiterate sono trattate come prova di carenze più ampie nella resilienza operativa.