Guida completa Regolamento DORA: obblighi e scadenze

DORA: Il Nuovo Quadro UE per la Resilienza Digitale del Settore Finanziario

Nell’era della finanza digitale, la stabilità del sistema non dipende più soltanto dalla solidità patrimoniale degli istituti, ma anche e soprattutto dalla loro capacità di resistere a shock di natura tecnologica. Partendo da questa consapevolezza, l’Unione Europea ha introdotto il Regolamento (UE) 2022/2554, universalmente noto come DORA (Digital Operational Resilience Act). Prima di questo intervento, il panorama legislativo in materia di sicurezza informatica era estremamente frammentato, con norme disomogenee che creavano incertezza e lasciavano pericolose lacune nella difesa collettiva contro minacce informatiche sempre più globali e sofisticate. Questa guida completa al Regolamento DORA ha lo scopo di illustrare in modo dettagliato il nuovo quadro normativo, fornendo una bussola per orientarsi tra obblighi, scadenze e opportunità.

L’obiettivo primario di DORA è duplice: da un lato, armonizzare le normative esistenti per creare un framework giuridico unico e coerente per tutta l’UE; dall’altro, affrontare in modo olistico la gestione del rischio legato alle tecnologie dell’informazione e della comunicazione (TIC). Il fine ultimo è il raggiungimento di un «livello comune elevato di resilienza operativa digitale» per l’intero settore finanziario, con una data cerchiata in rosso sul calendario di tutti gli operatori: la sua piena applicabilità è fissata per il 17 gennaio 2025.

Pilastro I: Gestione dei Rischi Informatici (Capo II, Art. 5-16)

Il primo e più fondamentale pilastro di DORA ridefinisce le fondamenta della gestione del rischio tecnologico, ponendo una responsabilità inequivocabile al vertice dell’organizzazione.

La Governance del Rischio ICT: Responsabilità dell’Organo di Gestione (Art. 5)

La novità più dirompente è l’attribuzione della responsabilità ultima, diretta e non delegabile per la gestione del rischio ICT (Information and Communication Technology) all’organo di gestione dell’entità finanziaria (es. il Consiglio di Amministrazione). Questo non è un ruolo passivo. L’organo di gestione deve «definire, approvare, sovrintendere e essere responsabile» di tutte le strategie relative al rischio ICT. Ciò si traduce in due obblighi precisi:

• I membri devono possedere e «mantenere attivamente aggiornate conoscenze e competenze adeguate per comprendere e valutare i rischi informatici», introducendo di fatto un obbligo di formazione continua per i vertici aziendali.
• Devono approvare e riesaminare periodicamente una strategia globale di resilienza operativa digitale, che definisca chiaramente il livello di tolleranza al rischio ICT dell’entità.

Per garantire l’efficacia di questo quadro, DORA richiede l’istituzione di una funzione di controllo del rischio ICT indipendente. In una comunicazione specifica, la Banca d’Italia ha chiarito che, nel rispetto del principio di proporzionalità, tale funzione può essere un’unità autonoma oppure i suoi compiti possono essere attribuiti alle funzioni di risk management e compliance esistenti. È invece esplicitamente vietato affidare tale funzione di controllo alla funzione di internal audit (terzo livello), per preservarne l’indipendenza di giudizio.

Un Ciclo di Vita Completo della Sicurezza (Art. 7-14)

DORA struttura la gestione del rischio in un ciclo di vita continuo e interconnesso, garantendo un approccio sistematico che copre tutte le fasi della sicurezza.

1. Identificazione (Art. 8): La base di tutto è la conoscenza. Le entità devono costantemente identificare, mappare e documentare tutte le loro risorse ICT e i processi aziendali che da esse dipendono. È fondamentale classificare queste risorse in base alla loro criticità, ad esempio tramite una Business Impact Analysis (BIA).
2. Protezione e Prevenzione (Art. 9): Sulla base dell’analisi dei rischi, devono essere implementate policy e strumenti adeguati a proteggere le infrastrutture. Questo include misure tecniche come la gestione rigorosa delle identità e degli accessi (es. autenticazione a più fattori), la segmentazione delle reti e la crittografia dei dati.
3. Individuazione (Art. 10): Poiché la protezione assoluta non esiste, è essenziale disporre di meccanismi per il monitoraggio continuo e il rilevamento tempestivo di attività anomale. L’implementazione di sistemi come SIEM (Security Information and Event Management) e l’analisi dei log di sistema sono cruciali in questa fase.
4. Risposta e Ripristino (Art. 11-12): Quando un incidente viene rilevato, l’entità deve essere pronta a reagire con piani di risposta (Incident Response Plans) e piani di continuità operativa (Business Continuity Plans) per ripristinare le funzioni critiche. Un elemento chiave è l’adozione di strategie di backup solide, testate e idealmente immutabili.
5. Apprendimento ed Evoluzione (Art. 13): Il ciclo si chiude con l’apprendimento. Ogni incidente, reale o simulato, deve essere seguito da un’analisi post-mortem per identificare le cause profonde e migliorare le difese future, anche attraverso la formazione continua del personale (programmi di awareness).

Pilastro II: Gestione e Segnalazione degli Incidenti (Capo III, Art. 17-23)

Questo pilastro introduce un regime di notifica armonizzato e stringente, volto a fornire alle autorità di vigilanza una visione tempestiva e completa delle minacce che colpiscono il settore.

Classificazione e Segnalazione degli Incidenti Gravi (Art. 18-20)

Un elemento centrale del nuovo regime è la classificazione degli incidenti. Un incidente è considerato “grave” (major) quando supera determinate soglie di rilevanza relative a criteri come il numero di clienti interessati, la durata dell’interruzione, la diffusione geografica, le perdite di dati e la criticità dei servizi colpiti.

Per gli incidenti classificati come “gravi”, DORA introduce un obbligo di segnalazione all’autorità nazionale competente strutturato in più fasi, con tempistiche estremamente rigorose. Le bozze delle Norme Tecniche di Regolamentazione (RTS) indicavano un termine di 4 ore per la prima notifica, a testimonianza dell’urgenza richiesta.

Esempio Pratico: Gestione di un Attacco Ransomware

Per rendere concreti questi obblighi, si consideri una compagnia di assicurazioni che subisce un attacco ransomware che cripta il sistema di gestione dei sinistri. L’iter di gestione e notifica sarebbe:

1. Attivazione Interna (T=0): Il team di sicurezza rileva l’anomalia, isola i sistemi compromessi e attiva il Piano di Risposta agli Incidenti, informando immediatamente vertici, CISO e DPO.
2. Classificazione (T < 2 ore): L’incidente viene classificato come “grave” perché impatta un servizio critico, causa una perdita di disponibilità dei dati e interessa un numero elevato di clienti.
3. Notifica Iniziale (T < 4 ore): La compagnia invia la notifica iniziale (early warning) all’autorità di vigilanza (IVASS).
4. Gestione e Analisi (T = 4-24 ore): Mentre il team tecnico avvia il ripristino dai backup, un team di analisi forense investiga per determinare se, oltre alla cifratura, vi sia stata anche esfiltrazione di dati.
5. Rapporto Intermedio (T < 24 ore): Viene inviato il rapporto intermedio all’IVASS con i dettagli dell’attacco e le prime misure adottate.
6. Notifica GDPR (se applicabile, T < 72 ore): Se l’analisi conferma un accesso non autorizzato a dati personali, il DPO notifica la violazione al Garante per la Protezione dei Dati Personali.
7. Rapporto Finale (T < 1 mese dalla risoluzione): A operatività ripristinata, viene inviato il rapporto finale con l’analisi forense completa, l’impatto finanziario e le azioni correttive implementate per prevenire futuri incidenti.

Pilastro III: Test di Resilienza Operativa Digitale (Capo IV, Art. 24-27)

Non è sufficiente implementare controlli di sicurezza; è necessario testarli regolarmente e in modo realistico. DORA introduce un obbligo strutturato di testing, che culmina nei sofisticati test di penetrazione guidati dalla minaccia.

Un Programma di Test Completo e Basato sul Rischio (Art. 24-25)

Le entità finanziarie devono istituire e mantenere un programma di test solido e completo, la cui frequenza e intensità devono essere commisurate alla criticità degli asset. Il programma deve prevedere una gamma appropriata di test, che includono, tra gli altri:

• Valutazioni di vulnerabilità e scansioni (Vulnerability Assessments).
• Test di sicurezza delle applicazioni (Application Security Testing).
• Test di compatibilità e delle performance.
• Test di penetrazione (Penetration Testing).

Tutti i sistemi e le applicazioni che supportano funzioni critiche devono essere testati almeno una volta all’anno.

I Test di Penetrazione Guidati dalla Minaccia (TLPT) (Art. 26)

Il requisito più innovativo è il Test di Penetrazione Guidato dalla Minaccia (TLPT), obbligatorio con frequenza almeno triennale per le entità finanziarie più critiche. A differenza di un normale test, un TLPT è una vera e propria simulazione di attacco reale, condotta da hacker etici (Red Team) che usano le stesse tattiche, tecniche e procedure (TTP) degli avversari reali (es. gruppi criminali), sulla base di un’analisi di threat intelligence specifica per l’entità. Un aspetto cruciale è che i TLPT devono coprire anche i fornitori terzi di servizi ICT critici.

Esempio Pratico: Le Fasi di un TLPT

Pilastro IV: Gestione del Rischio Informatico Derivante da Terzi (Capo V, Art. 28-44)

Questo è forse il pilastro più complesso e dirompente di DORA, poiché estende il perimetro normativo ben oltre i confini dell’entità finanziaria, disciplinando in modo granulare l’intera catena di fornitura tecnologica.

Principi Generali e Responsabilità (Art. 28)

L’articolo 28 stabilisce il principio cardine: l’entità finanziaria rimane pienamente responsabile del rispetto di tutti i suoi obblighi normativi, anche quando esternalizza funzioni o servizi a fornitori terzi. L’esternalizzazione di un’attività non comporta mai una delega della responsabilità legale. Per consentire un’efficace vigilanza, l’Art. 28 introduce anche l’obbligo di mantenere un “Registro delle Informazioni”, un inventario dettagliato di tutti gli accordi contrattuali per la fornitura di servizi ICT.

Le Clausole Contrattuali Obbligatorie (Art. 30)

L’articolo 30 è il cuore normativo della gestione dei fornitori. Trasforma il contratto da semplice accordo commerciale a strumento legale primario di controllo. Questa guida completa al Regolamento DORA sottolinea che non è più possibile accettare clausole generiche di “best effort”, ma occorre imporre impegni precisi e verificabili. DORA prescrive un set minimo di clausole obbligatorie per tutti i contratti ICT, con requisiti ancora più stringenti per quelli che supportano Funzioni Essenziali o Importanti (FEI). Tra queste, le più significative sono:

• Descrizione completa dei servizi e SLA quantificabili.
• Indicazione precisa dei paesi in cui i dati saranno trattati e conservati.
• Obblighi specifici di sicurezza delle informazioni.
• Obbligo del fornitore di notificare senza ritardo qualsiasi incidente ICT.
• Diritti illimitati di accesso, ispezione e audit per l’entità finanziaria e per le autorità di vigilanza (per contratti FEI).
• Strategie di uscita (exit strategy) dettagliate e testate per garantire una migrazione sicura in caso di risoluzione del contratto (per contratti FEI).

Il Subappalto e la Fine del “Black Box” (Reg. Delegato 2025/532)

La gestione del rischio non si ferma al fornitore diretto (terza parte), ma deve estendersi a tutta la catena, includendo i subappaltatori (quarte parti e oltre). Un apposito Regolamento Delegato sancisce la fine dell’era del fornitore “black box”, in cui l’entità finanziaria non aveva visibilità sui subappaltatori del proprio outsourcer. L’entità finanziaria è ora tenuta a garantire il controllo effettivo lungo tutta la filiera. Ciò avviene tramite clausole contrattuali specifiche che obbligano il fornitore primario a:

• Ottenere un’autorizzazione scritta e preventiva dall’entità finanziaria prima di poter subappaltare una funzione critica.
• Imporre al proprio subappaltatore gli stessi identici obblighi a cui è soggetto lui stesso (clausole “flow-down”), inclusi i diritti di ispezione e audit.

Esempio Pratico: Subappalto di un Servizio Cloud per una Banca

Una banca stipula un contratto con un grande provider cloud (CloudProvider X) per l’hosting della sua piattaforma di mobile banking (una FEI). Il contratto prevede che il disaster recovery sia fornito da un subappaltatore (DR-Specialist Y).

1. Due Diligence: La banca richiede a CloudProvider X tutta la documentazione relativa alla due diligence effettuata su DR-Specialist Y (audit report, certificazioni, etc.).
2. Negoziazione Contrattuale: La banca inserisce nel contratto con CloudProvider X clausole che richiedono l’approvazione scritta per il subappalto a DR-Specialist Y e obbligano CloudProvider X a imporre a quest’ultimo tutti gli obblighi di sicurezza e audit (flow-down), garantendo anche un diritto di ispezione diretto per la banca e per la Banca d’Italia.
3. Monitoraggio Continuo: La banca integra DR-Specialist Y nel suo programma di monitoraggio del rischio, richiedendo report periodici sulle sue performance.
4. Gestione delle Modifiche: Se DR-Specialist Y decide di spostare un data center in un altro paese, deve notificarlo alla banca tramite CloudProvider X. La banca deve condurre una nuova valutazione del rischio e, se il rischio è ritenuto inaccettabile, può negare l’approvazione, costringendo il fornitore a trovare un’alternativa o attivando la clausola di risoluzione del contratto.

Pilastro V: Condivisione delle Informazioni e Sanzioni (Capo VI-VII, Art. 45-56)

Gli ultimi capitoli di DORA completano il quadro normativo, da un lato incoraggiando la collaborazione e dall’altro definendo un regime sanzionatorio robusto per garantirne l’applicazione.

Condivisione di Informazioni e Dati sulle Minacce (Art. 45)

Riconoscendo che la resilienza è un obiettivo collettivo, l’Articolo 45 incoraggia attivamente le entità finanziarie a scambiarsi, su base volontaria, informazioni e analisi relative alle minacce informatiche. Questo scambio, che può includere dati tecnici come indicatori di compromissione (IoC) e tattiche, tecniche e procedure (TTP) degli aggressori, deve avvenire all’interno di comunità fidate (trusted communities). L’obiettivo è creare un ecosistema di difesa collaborativa.

Poteri delle Autorità e Regime Sanzionatorio (Art. 50)

Per assicurare l’effettiva applicazione del Regolamento, le autorità nazionali competenti sono dotate di ampi poteri di vigilanza, indagine e sanzione. Le sanzioni amministrative pecuniarie devono essere “efficaci, proporzionate e dissuasive”. È importante notare che anche i fornitori terzi critici (CTPP), sotto la sorveglianza diretta delle autorità europee, possono essere soggetti a sanzioni pecuniarie significative in caso di mancato rispetto delle raccomandazioni ricevute.

Il decreto legislativo italiano di adeguamento (ipotizzato come D.Lgs. 23/2025 nel materiale di ricerca) ha dettagliato il regime sanzionatorio per le entità finanziarie:

• Violazioni “più gravi”: Riguardano obblighi fondamentali di governance (Art. 5), la gestione dei fornitori critici (Art. 30) o la mancata segnalazione di un incidente grave (Art. 19). La sanzione pecuniaria può arrivare fino al 10% del fatturato annuo totale dell’ente.
• Violazioni “meno gravi”: Riguardano obblighi più operativi, come inadempienze minori nei test periodici o ritardi in notifiche di incidenti non critici. La sanzione massima è comunque significativa, arrivando fino al 7% del fatturato annuo totale.

Conclusioni: Come Agire in Pratica

Il Regolamento DORA rappresenta un cambiamento epocale per il settore finanziario europeo, elevando la resilienza operativa digitale da questione puramente tecnica a priorità strategica di governance, con piena responsabilità dell’organo di gestione. L’adeguamento richiede un impegno significativo, ma questa guida completa al Regolamento DORA dimostra come esso offra anche l’opportunità di rafforzare le difese, ottimizzare i processi e aumentare la fiducia del mercato.

È fondamentale che le entità finanziarie non percepiscano DORA semplicemente come un ulteriore onere di conformità, ma come un’opportunità strategica. Un’implementazione efficace porta a benefici tangibili:

1. Rafforzamento della Postura di Sicurezza: Riduzione della superficie di attacco e miglioramento della capacità di resistere e riprendersi da incidenti.
2. Aumento della Fiducia: Dimostrare una solida resilienza aumenta la fiducia di clienti, investitori e regolatori.
3. Vantaggio Competitivo: La resilienza diventa un fattore di differenziazione e un prerequisito per l’innovazione sicura.

Domande Frequenti (FAQ)

Link Utili e Riferimenti Normativi

• Testo del Regolamento (UE) 2022/2554 (DORA)
• Testo del Regolamento Delegato (UE) 2025/532 sul subappalto (come da fonte)
• Testo della Direttiva (UE) 2022/2555 (NIS 2)
• Testo del Regolamento (UE) 2016/679 (GDPR)