
Il Regolamento DORA (Digital Operational Resilience Act) - vedi anche dora-info - segna un passo significativo verso l'allineamento della normativa italiana con gli standard europei in materia di resilienza digitale: rappresenta infatti un cambio di paradigma rispetto al modo in cui gli intermediari finanziari governano i rischi ICT, integrandoli stabilmente nei processi decisionali, nei controlli interni e nei rapporti con terze parti all'interno delle organizzazioni finanziarie.Mentre le norme precedenti si concentravano su specifici aspetti della sicurezza informatica, il DORA adotta un approccio olistico e integrato, costruito su cinque pilastri interdipendenti, che richiedono coerenza organizzativa e maturità operativa:
Il decreto legislativo 10 marzo 2025, n. 23 ha designato Banca d’Italia come autorità competente per gli intermediari ex 106 del TUB. Per questi soggetti, il decreto impone l’adeguamento al Regolamento DORA entro il 1° gennaio 2027.
A questa scadenza, si affianca un ulteriore adempimento richiesto dalla Vigilanza. La Banca d’Italia ha rivolto anche agli intermediari finanziari ex 106 una Comunicazione al mercato sulla resilienza operativa digitale. Il Consiglio di Amministrazione, in seduta congiunta con il Collegio Sindacale, è chiamato ad avviare una relazione sul livello di esposizione al rischio e sull’adeguatezza dei presidi, accompagnata da un piano di lavoro con azioni, tempi e investimenti. La relazione e il piano devono essere trasmessi alla Vigilanza entro il 31 dicembre 2026.
La scadenza per adeguarsi è imminente ed è fondamentale iniziare subito un percorso di conformità per diversi motivi:
Per gli intermediari ex 106, la difficoltà maggiore è riuscire a tradurre una cornice regolamentare complessa in un programma operativo sostenibile: gli organici sono spesso contenuti, le risorse specialistiche limitate e le responsabilità distribuite tra persone che ricoprono più ruoli. Funzioni come IT, Risk, Compliance, Operations ed esternalizzazione lavorano inoltre sugli stessi rischi con linguaggi, priorità e livelli di formalizzazione diversi. Policy, assessment, registro dei fornitori e test possono così trasformarsi in cantieri paralleli, con molte attività aperte ma poca integrazione, responsabilità non sempre definite e un avanzamento sostanziale modesto. Il rischio è di arrivare al 2027 avendo completato gli adempimenti formali, senza però aver costruito un sistema di governo coerente, tracciabile e capace di reggere a una verifica ispettiva.
Per trasformare i requisiti normativi in attività concrete, il percorso può essere articolato in sei ambiti operativi:
I sei step devono confluire in un unico programma DORA, governato secondo una logica integrata. La mappa dei servizi critici deve collegare rischi ICT, processi di incident management, test, dipendenze dai fornitori e requisiti contrattuali. Se questi ambiti vengono gestiti separatamente, SLA e KPI possono non riflettere la criticità dei servizi, i diritti di audit possono risultare insufficienti e il reporting può restare incompleto.
Nel percorso di adeguamento a DORA, le principali criticità non derivano soltanto da carenze tecniche. Spesso nascono da un’impostazione poco coerente, da responsabilità non definite o da presidi corretti sulla carta, ma non integrati nei processi quotidiani. Ecco gli errori più frequenti e le misure necessarie per evitarli.
Confinare DORA nell’area tecnologica significa trascurarne le implicazioni organizzative e decisionali. Le informazioni rilevanti rischiano di non arrivare al CdA in un formato utile, mentre le priorità tecniche non vengono tradotte in scelte aziendali, responsabilità e investimenti.
Il percorso deve essere impostato come un programma di governance aziendale, capace di coinvolgere organi aziendali, funzioni di controllo e strutture operative. Ai presidi tecnologici devono affiancarsi procedure, competenze, formazione e meccanismi decisionali coerenti con i rischi da governare.
La presenza di policy, registri e piani di continuità non dimostra, da sola, la capacità di affrontare un evento grave. Avere una policy non significa saper gestire un incidente; disporre di un Registro delle Informazioni non equivale a governare una dipendenza critica da una terza parte ICT; aver predisposto un piano di continuità non garantisce tempi di ripristino realistici.
Il rischio è costruire un impianto ordinato solo in superficie, ma fragile nei passaggi decisivi: classificazione degli incidenti, escalation, gestione delle dipendenze esterne e continuità dei servizi critici. Regole, responsabilità, misure operative ed evidenze devono quindi essere coerenti e verificabili.
La domanda da porsi non è soltanto se il documento esista, ma se l’intermediario sia in grado di dimostrare come governa un’interruzione grave, dalla rilevazione dell’incidente al ripristino dei servizi interessati.
Quando responsabilità, poteri decisionali e regole di escalation non sono formalizzati, le attività possono procedere senza che sia chiaro chi approva, chi controlla e chi deve intervenire in caso di anomalie o scostamenti.
Ogni presidio deve avere un responsabile, un perimetro decisionale e flussi informativi definiti, compresi quelli diretti al CdA. Ruoli e sostituzioni devono rimanere riconoscibili anche durante un incidente, un disservizio presso un fornitore o una verifica ispettiva.
DORA richiede una logica integrata tra governance, rischio ICT, incident management, continuità operativa e gestione delle terze parti. Il semplice coinvolgimento di IT, Risk, Compliance, Operations ed esternalizzazione non basta se ciascuna funzione utilizza criteri, priorità e modalità di valutazione differenti.
Quando questi ambiti non dialogano, le terze parti ICT possono essere classificate in modo non coerente con la criticità dei servizi supportati, SLA e KPI possono risultare inadeguati, i diritti di audit insufficienti e le responsabilità interne poco chiare durante un disservizio. Anche il reporting rischia così di restituire una rappresentazione incompleta del rischio.
Per superare i silos servono criteri condivisi, momenti di coordinamento strutturati e un unico programma DORA, nel quale servizi critici, rischi, incidenti, test, dipendenze dai fornitori e requisiti contrattuali siano governati secondo una logica comune.
Una roadmap standard, definita senza considerare le caratteristiche dell’intermediario, può essere formalmente corretta ma poco efficace sul piano operativo. Le priorità non devono derivare da un calendario applicato indistintamente, ma dai rischi, dai servizi critici e dalle dipendenze effettive dell’organizzazione.
Una roadmap credibile deve partire dai fondamentali: governance ICT formalizzata, gestione degli incidenti con criteri di classificazione ed evidenze, mappatura delle terze parti ICT che supportano funzioni essenziali o importanti e revisione progressiva di contratti, KPI e SLA.
Per ogni intervento devono inoltre essere definiti responsabilità, tempi, risorse ed evidenze attese. In assenza di questi elementi, il programma rischia di produrre documenti e attività isolate senza tradursi in una maggiore resilienza operativa.
DORA richiede un presidio capace di evolvere insieme all’organizzazione. Cambiamenti nei servizi, nei sistemi, nei processi, nei fornitori o nei contratti possono modificare il profilo di rischio e rendere rapidamente superate le misure adottate.
Registro delle Informazioni, analisi dei rischi, policy, contratti e programmi di test devono quindi essere sottoposti a verifiche periodiche e aggiornamenti attivati dai cambiamenti del perimetro operativo. Il monitoraggio non può limitarsi alle scadenze regolamentari o intensificarsi soltanto in prossimità di un’ispezione.
Aggiornamenti episodici, eccessivamente tecnici o privi di indicazioni decisionali non consentono al CdA di esercitare un presidio efficace. Il problema non si risolve aumentando la quantità delle informazioni: occorre selezionare quelle che permettono di valutare l’esposizione al rischio, lo stato del programma e le azioni necessarie.
Il reporting deve essere periodico, sintetico e orientato alle decisioni. Un set essenziale di indicatori può comprendere:
Questi indicatori permettono agli organi aziendali di collegare lo stato del programma alle decisioni su priorità, risorse, investimenti e interventi correttivi.
Un intermediario ex 106 TUB utilizza piattaforme cloud per la gestione dei dati e dei processi di credito. Sistemi di gestione pratiche, interfacce di pagamento e infrastrutture digitali rappresentano il cuore dell’operatività. Un’interruzione dei servizi ICT causata da un guasto del provider o da un attacco esterno può bloccare l’erogazione di credito, generare ritardi nei pagamenti e compromettere la fiducia di clienti e stakeholder.
1. Assessment iniziale
2. Predisposizione di una strategia di resilienza
3. Implementazione piano di risposta agli incidenti
Per rendere il percorso sostenibile, l’intermediario deve partire da un assessment del livello di maturità rispetto ai cinque pilastri DORA, identificare i gap e tradurli in una roadmap coerente con dimensione, complessità e modello operativo. La roadmap deve assegnare priorità, responsabilità, tempi e risorse umane, tecniche e finanziarie.
L’obiettivo non è soltanto rispettare la scadenza del 1° gennaio 2027, ma costruire un presidio che possa essere mantenuto, aggiornato e dimostrato nel tempo. Augeos affianca gli intermediari ex 106 nella definizione di questo percorso, dalla valutazione iniziale alla messa a terra delle azioni correttive.
Non automaticamente. I Threat-Led Penetration Test (TLPT) sono obbligatori solo per le entità individuate dall’autorità competente secondo criteri di proporzionalità e di rischio. Gli intermediari non selezionati devono comunque svolgere gli ordinari test di resilienza operativa digitale; il framework TIBER-IT può inoltre essere adottato su base volontaria.
No. Il RoI deve censire tutti gli accordi contrattuali per l’utilizzo di servizi ICT, distinguendo quelli che supportano funzioni essenziali o importanti. La criticità non determina se registrare il rapporto, ma il livello di attenzione da applicare a rischio, contratto, monitoraggio e strategia di uscita.
No. L’intermediario resta responsabile degli obblighi applicabili anche quando utilizza cloud, software o infrastrutture esterne. Deve quindi poter governare il rischio, ottenere informazioni ed evidenze, esercitare i diritti di accesso e audit e attivare le misure di continuità e uscita previste dal contratto.
No. Certificazioni e report di assurance possono supportare i controlli, ma non sostituiscono la valutazione dell’intermediario né i diritti contrattuali di accesso, ispezione e audit. Occorre verificare che le evidenze coprano i servizi, le sedi, i controlli e il periodo rilevanti e gestire gli eventuali gap.
L’evento deve confluire nel processo interno di incident management. Il contratto deve assicurare una comunicazione tempestiva e il supporto del fornitore nella valutazione degli impatti, nella raccolta delle evidenze e nel ripristino. L’intermediario resta responsabile della classificazione dell’incidente, dell’escalation interna e delle eventuali segnalazioni all’autorità competente.
Topic: Gestione Incidenti Informatici, Continuità e Resilienza Operativa, DORA