Blog

DORA compliance per intermediari ex 106: guida completa

18 settembre 2026

Dora compliance per gli intermediari finanziari

Che cos’è il Regolamento DORA?

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:

  1. governance e responsabilità degli organi aziendali,
  2. gestione del rischio ICT,
  3. incident management e reporting,
  4. testing di resilienza operativa digitale,
  5. gestione dei rischi delle terze parti ICT.

Conformità DORA, i tempi stringono

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:

  • Il Registro delle Informazioni (RoI) è impegnativo: richiede template standard, identificatori LEI/EUID e qualità dei dati. È necessario tempo per mappare contratti, fornitori e subfornitori e per impostare la conversione xBRL-CSV.
  • Tempistiche per la negoziazione delle clausole contrattuali: DORA richiede una particolare attenzione nella gestione dei rischi di terze parti ICT e della catena di fornitura. Predisporre addendum contrattuali richiede tempo e trattative con i fornitori ICT. Anticipare queste negoziazioni evita blocchi operativi futuri.
  • Investimento su resilienza e affidabilità: l’adeguamento a DORA non è solo un obbligo, ma una leva per dimostrare la capacità di resilienza. Un’organizzazione resiliente ispira la fiducia di clienti, partner e stakeholder.
  • La conformità non è soltanto "documentale": adeguarsi a DORA non consiste solo nella burocratica revisione e/o stesura di policy, procedure e regolamenti, ma passa anche e soprattutto dalla loro messa a terra all’interno della struttura organizzativa aziendale, tanto in senso orizzontale, quanto in senso verticale.

Perché gli intermediari ex 106 faticano a rendere DORA concreto

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.

6 passi per raggiungere la conformità DORA

Per trasformare i requisiti normativi in attività concrete, il percorso può essere articolato in sei ambiti operativi:

  1. Governance e responsabilità degli organi aziendali: Formalizzare un organo di gestione del rischio e individuare ruoli e responsabilità.
  2. Adeguamento di policy e procedure: aggiornare o adottare ex novo politiche e procedure per garantire la resilienza operativa.
  3. Gestione incidenti e reporting: aggiornare il processo di rilevazione, classificazione, escalation e notifiche dei gravi incidenti ICT all’autorità competente. Istituire post-incident analysis.
  4. RoI - Register of Information: costruire un registro unico di tutti gli accordi contrattuali ICT secondo le specifiche delle Autorità.
  5. Contratti ICT: rinegoziare le clausole DORA-critical: audit/access, sicurezza & BCP, localizzazione dati, subappalto, exit/reversibilità, KPI/SLA, concentrazione.
  6. Testing di resilienza digitale: Pianificare un programma risk-based, eseguire test annuali sui sistemi a supporto di funzioni essenziali/importanti, individuare vulnerabilità.

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.

7 errori comuni e come evitarli

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.

1. Trattare DORA come un progetto esclusivamente IT

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.

2. Confondere la documentazione con la resilienza operativa

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.

3. Lasciare poco chiari ruoli e responsabilità

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.

4. Gestire funzioni e terze parti ICT come ambiti separati

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.

5. Costruire una roadmap generica

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.

6. Considerare la conformità un intervento una tantum

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.

7. Portare al CdA un reporting sporadico o poco leggibile

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:

  • rischi ICT sopra soglia;
  • incidenti significativi e relativi tempi di risposta;
  • disponibilità dei servizi critici;
  • avanzamento dei test di continuità operativa e disaster recovery;
  • copertura contrattuale delle terze parti ICT che supportano funzioni essenziali o importanti;
  • stato delle azioni correttive e degli eventuali scostamenti dalla roadmap.

Questi indicatori permettono agli organi aziendali di collegare lo stato del programma alle decisioni su priorità, risorse, investimenti e interventi correttivi.

Implementazione della conformità DORA: un esempio concreto

Scenario

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.

Azioni da intraprendere

1. Assessment iniziale

  • Mappatura e individuazione degli asset critici
  • Predisposizione di una BIA, analisi della criticità dei processi, individuazione delle dipendenze da servizi forniti da TPSP
  • Individuazione degli impatti sui processi core dell’intermediario in caso di interruzioni o guasti prolungati
  • Predisposizione di un Business Continuity Plan
  • Predisposizione di un Disaster Recovery
  • Definizione di ruoli e responsabilità per la gestione degli incidenti ICT
  • Notifica alle autorità competenti nel caso di incidente significativo

2. Predisposizione di una strategia di resilienza

3. Implementazione piano di risposta agli incidenti

Risultato atteso

  • Maggiore resilienza operativa e riduzione del rischio di interruzioni.
  • Conformità alle disposizioni DORA e riduzione del rischio di sanzioni.
  • Rafforzamento della fiducia di clienti e partner grazie a una governance ICT solida.

Dalla conformità a un presidio DORA sostenibile

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.

New call-to-action

FAQ

Un intermediario ex 106 deve svolgere test TLPT basati sulle minacce?

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.

 

Topic: Gestione Incidenti Informatici, Continuità e Resilienza Operativa, DORA