Un guasto al cloud, un attacco ransomware o un errore in un fornitore tecnologico possono bloccare pagamenti, trading e servizi assicurativi in pochi minuti. Il regolamento DORA introduce un quadro europeo comune per ridurre questi rischi e chiede agli operatori finanziari di dimostrare non solo di prevenire gli incidenti, ma anche di saper reagire e ripristinare le attività. Vediamo cosa prevede, chi deve applicarlo e quali passi concreti servono alle imprese italiane nel 2026.
Le regole DORA rendono la resilienza digitale una responsabilità misurabile
- Applicazione dal 17 gennaio 2025 per gran parte del settore finanziario europeo.
- Obblighi principali su rischio ICT, incidenti, test di resilienza e fornitori tecnologici.
- Le imprese devono mantenere un registro delle dipendenze ICT, compresi cloud e outsourcing.
- Gli incidenti ICT gravi seguono tempi di segnalazione precisi, con aggiornamenti e relazione finale.
- La proporzionalità semplifica alcuni adempimenti, ma non elimina la responsabilità del vertice aziendale.
Che cos’è DORA e perché riguarda la finanza digitale
DORA è il Regolamento europeo 2022/2554 sulla resilienza operativa digitale del settore finanziario. In parole semplici, stabilisce come banche, intermediari, assicurazioni e altri operatori debbano proteggere sistemi, dati e servizi digitali da guasti, attacchi informatici e interruzioni operative.
La logica è importante. La sicurezza informatica non viene più trattata come un problema confinato al reparto IT, ma come una componente della continuità aziendale. Se un’applicazione per i pagamenti smette di funzionare, la decisione su backup, ripristino e comunicazione al cliente coinvolge infatti direzione, risk management, compliance e consiglio di amministrazione.
A chi si applica
Il regolamento coinvolge numerose categorie di entità finanziarie, tra cui banche, imprese di investimento, istituti di pagamento, istituti di moneta elettronica, gestori di fondi, imprese assicurative e riassicurative. Rientrano nel perimetro anche determinati fornitori di servizi per cripto-attività e operatori di crowdfunding autorizzati.
Non tutte le imprese sono soggette agli stessi adempimenti. Il testo considera dimensioni, profilo di rischio, natura dei servizi e complessità organizzativa. Le microimprese possono beneficiare di un quadro semplificato in alcuni ambiti, ma devono comunque gestire i rischi ICT in modo coerente con la propria attività.
| Categoria | Impatto pratico |
|---|---|
| Banche e intermediari rilevanti | Framework ICT completo, test periodici, gestione strutturata degli incidenti e controllo dei fornitori. |
| Imprese assicurative | Presidio dei sistemi che sostengono funzioni essenziali, sinistri, polizze e comunicazioni con i clienti. |
| Istituti di pagamento e moneta elettronica | Forte attenzione a disponibilità, integrità e ripristino dei sistemi di pagamento. |
| Microimprese finanziarie | Possibili procedure proporzionate, senza esclusione automatica dagli obblighi. |
| Fornitori ICT | Controlli contrattuali, cooperazione con il cliente finanziario e, per i più critici, supervisione europea. |
In Italia la vigilanza dipende dal settore. Banca d’Italia, Consob, IVASS e COVIP operano secondo le rispettive competenze. Per un’impresa, quindi, il primo passo non è acquistare uno strumento di cybersecurity, ma capire esattamente quale perimetro regolamentare si applica alla propria autorizzazione e al proprio modello operativo.
Gli obblighi che cambiano davvero il lavoro delle imprese
Il cuore di DORA è un sistema continuo di governo del rischio, non una checklist da compilare una volta all’anno. Gli organi di gestione devono approvare la strategia di resilienza digitale, assegnare responsabilità e verificare che esistano risorse adeguate per proteggere i servizi.
Gestire il rischio ICT con metodo
Ogni entità deve identificare hardware, software, reti, dati, processi e dipendenze esterne che sostengono le attività finanziarie. Il risultato dovrebbe essere una mappa aggiornata degli asset e dei rischi, collegata alle funzioni essenziali o importanti dell’organizzazione.
Una banca, per esempio, non deve limitarsi a classificare il proprio data center. Deve sapere quali componenti rendono possibile l’home banking, quali fornitori gestiscono l’autenticazione, dove vengono conservati i dati e quanto tempo può restare indisponibile ciascun servizio prima di produrre un danno rilevante.
Prevenire, rilevare e ripristinare
Le misure richieste comprendono controllo degli accessi, gestione delle vulnerabilità, aggiornamento dei sistemi, cifratura quando appropriata, protezione delle reti, backup e piani di risposta. Il punto spesso trascurato è il ripristino verificabile: avere un backup non basta se non è stato testato e non si conoscono i tempi reali per usarlo.
Io considero particolarmente utile distinguere tra “sistema sicuro” e “sistema recuperabile”. Anche una difesa ben progettata può fallire; la differenza operativa la fanno procedure chiare, contatti reperibili e decisioni già definite per le prime ore dell’emergenza.
Segnalare gli incidenti gravi
Gli incidenti ICT devono essere classificati secondo criteri documentati. Quando un evento è considerato grave, la segnalazione iniziale deve essere trasmessa entro 4 ore dalla classificazione e, comunque, entro 24 ore dal momento in cui l’entità ne viene a conoscenza. Seguono un rapporto intermedio entro 72 ore dalla notifica iniziale e una relazione finale, normalmente entro un mese.
Non ogni malfunzionamento diventa automaticamente un incidente grave. La valutazione considera durata, clienti o controparti coinvolti, impatto geografico, perdite economiche e importanza dei servizi colpiti. Per questo serve un processo di triage, cioè una valutazione rapida e ordinata della priorità dell’evento.
Test, simulazioni e continuità operativa
DORA chiede di provare concretamente la resilienza dei sistemi. I test possono includere scansioni di vulnerabilità, valutazioni di sicurezza, simulazioni di crisi, test di ripristino, prove di backup e verifiche dell’efficacia dei controlli di accesso.
Per alcune entità e in determinate condizioni è previsto anche il Threat-Led Penetration Testing, noto come TLPT. Si tratta di un test avanzato basato su minacce realistiche, svolto almeno ogni tre anni dagli operatori tenuti a questo livello di verifica. Non è un semplice penetration test automatico, perché mira a valutare la capacità complessiva dell’organizzazione di resistere a un attacco plausibile.
Un piano di test utile nella pratica
Un programma equilibrato dovrebbe partire dai servizi più critici e distribuire le prove durante l’anno. Un possibile schema comprende:
- verifica trimestrale del ripristino di sistemi o dati selezionati;
- simulazione semestrale di un incidente con coinvolgimento di direzione e comunicazione;
- revisione annuale dei piani di continuità e disaster recovery;
- test periodici sui fornitori che sostengono funzioni essenziali;
- analisi delle criticità emerse, con responsabili e scadenze per la correzione.
Le frequenze concrete dipendono dal rischio e dalle aspettative dell’autorità competente. La cosa che fa la differenza è conservare evidenze del test, risultati misurabili e azioni correttive. Una simulazione senza verbale, esiti e follow-up ha un valore limitato anche se l’esercizio è stato ben organizzato.
Recovery time e recovery point
Due indicatori aiutano a trasformare la continuità in obiettivi comprensibili. Il RTO, Recovery Time Objective, indica entro quanto tempo un servizio deve tornare operativo. Il RPO, Recovery Point Objective, indica quanta perdita massima di dati è accettabile, per esempio gli ultimi 15 minuti o l’ultima ora.
Un servizio di pagamento in tempo reale avrà generalmente obiettivi più severi rispetto a un archivio documentale interno. Stabilire lo stesso RTO per ogni applicazione è una semplificazione rischiosa e spesso costosa senza produrre maggiore protezione.
Fornitori ICT, cloud e registro delle informazioni
Una delle novità più incisive riguarda il rapporto con i fornitori tecnologici. L’impresa finanziaria resta responsabile della propria resilienza anche quando utilizza cloud, software in outsourcing, servizi gestiti o piattaforme esterne. Delegare l’infrastruttura non significa delegare l’obbligo di controllo.
Il registro delle informazioni raccoglie dati su contratti, servizi ICT, fornitori, sedi, subfornitori e funzioni supportate. Deve essere accurato e aggiornato, perché consente di capire dove si concentrano le dipendenze e quali conseguenze avrebbe la perdita di un determinato servizio.
Le clausole contrattuali da controllare
Un contratto tecnologico coerente con DORA dovrebbe affrontare almeno livelli di servizio, sicurezza, audit, accesso ai dati, gestione degli incidenti, cooperazione con l’autorità, subappalto, reversibilità e cessazione del rapporto.
La reversibilità merita particolare attenzione. Significa poter trasferire dati e attività a un altro fornitore o riportarle internamente entro tempi realistici. Una clausola generica non risolve il problema se i dati sono in un formato proprietario, il personale non conosce l’architettura e il piano di uscita non è mai stato provato.
| Area contrattuale | Domanda da porre al fornitore |
|---|---|
| Incidenti | In quanto tempo riceveremo una notifica e quali informazioni saranno disponibili? |
| Audit | Possiamo ottenere evidenze, report indipendenti o svolgere verifiche mirate? |
| Subfornitori | Chi può accedere ai dati e come vengono comunicate le modifiche alla catena di fornitura? |
| Continuità | Quali RTO e RPO sono contrattualmente garantiti e con quali prove? |
| Uscita | Come recuperiamo dati, configurazioni e documentazione in caso di cessazione? |
Nel 2025 le autorità europee hanno individuato i fornitori terzi ICT critici soggetti a supervisione specifica. Questo controllo europeo rafforza il quadro, ma non sostituisce la due diligence dell’impresa cliente. Anche un fornitore molto grande deve essere valutato rispetto all’uso concreto che ne fa l’organizzazione.
Come organizzare l’adeguamento in Italia senza sprecare risorse
Nel 2026 l’adeguamento non dovrebbe essere impostato come un progetto puramente documentale. Il metodo più efficace parte dai servizi che generano ricavi, rispettano obblighi autorizzativi o proteggono direttamente il cliente, e collega ogni servizio a sistemi, persone e fornitori.
Una roadmap in cinque passaggi
- Definire il perimetro dell’entità, delle filiali e dei servizi soggetti agli obblighi.
- Creare l’inventario ICT, includendo applicazioni, infrastrutture, dati e dipendenze da terzi.
- Valutare i gap tra controlli esistenti e requisiti su rischio, incidenti, test e contratti.
- Stabilire priorità e budget usando impatto, probabilità e criticità del servizio.
- Misurare e migliorare con indicatori, test, audit e azioni correttive tracciate.
Non esiste un costo standard per la conformità. Per una piccola realtà con infrastruttura semplice, il lavoro può concentrarsi su governance, procedure, registro e contratti. Un gruppo bancario con più sedi e numerosi fornitori dovrà invece sostenere investimenti molto maggiori in persone, strumenti di monitoraggio, test indipendenti e revisione architetturale.
Leggi anche: Fattura semplificata - limiti, dati e invio elettronico
Gli errori che vedo più spesso
Il primo errore è confondere DORA con un certificato di sicurezza. Il regolamento richiede un processo di governo continuo, mentre una certificazione può offrire solo una fotografia limitata nel tempo.
Il secondo è trattare il registro dei fornitori come un foglio amministrativo. Se non indica quali servizi sono essenziali, quali dati circolano e quali subfornitori intervengono, non aiuta davvero a gestire il rischio.
Il terzo consiste nel coinvolgere il consiglio di amministrazione soltanto alla fine. La resilienza digitale richiede decisioni su tolleranza al rischio, investimenti e accettazione delle dipendenze tecnologiche. Sono scelte di business, non semplici dettagli tecnici.
Infine, molte organizzazioni investono nella prevenzione e trascurano la comunicazione durante la crisi. Un piano valido deve indicare chi decide, chi informa l’autorità, chi parla con i clienti e chi coordina il fornitore. L’incertezza nelle prime ore può amplificare un incidente già sotto controllo tecnico.
La vera maturità DORA si misura quando qualcosa si rompe
La conformità non si dimostra accumulando policy, ma mostrando che l’impresa sa mantenere i servizi essenziali, rilevare un problema, segnalarlo correttamente e tornare operativa entro tempi compatibili con il proprio rischio.
Il percorso più solido unisce governance, tecnologia, persone e contratti. Chi parte dai processi critici e verifica sul campo le proprie dipendenze ottiene anche un vantaggio manageriale: meno sorprese operative, decisioni più rapide e maggiore fiducia da parte di clienti e partner.
Per questo considero DORA un passaggio utile per la finanza digitale italiana. Non elimina gli incidenti, ma costringe a prepararli con numeri, responsabilità e prove concrete, trasformando la resilienza da promessa generica in una capacità aziendale verificabile.
