DORA: Resilienza Operativa Digitale per Settore Finanziario 2026

Nota metodologica. La presente analisi è aggiornata al 17 giugno 2026. Il Regolamento (UE) 2022/2554 (DORA) è in vigore dal 16 gennaio 2023 ed è applicabile dal 17 gennaio 2025. I Regulatory Technical Standards (RTS) e Implementing Technical Standards (ITS) sono stati adottati dalle European Supervisory Authorities (ESA) e pubblicati nella Gazzetta Ufficiale UE tra gennaio e dicembre 2024. Il contenuto ha finalità esclusivamente informativa e non costituisce parere legale.

Fonti primarie: Reg. UE 2022/2554 (DORA), EUR-Lex · Reg. UE 2022/2555 (NIS2), EUR-Lex · Banca d'Italia, DORA

DORA nasce dall'esigenza di uniformare a livello europeo la disciplina della resilienza digitale del settore finanziario, superando la frammentazione delle regolamentazioni nazionali che rendeva disomogenei i presidi di sicurezza tra uno Stato membro e l'altro. È un regolamento direttamente applicabile, non richiede recepimento nazionale, e si inserisce in un quadro normativo più ampio che include NIS2 e la Direttiva CER (Critical Entities Resilience).

1. DORA vs NIS2: perché il settore finanziario segue regole proprie

La relazione tra DORA e NIS2 è governata dal principio di lex specialis (Art. 4 NIS2): le entità finanziarie soggette a DORA sono escluse dagli obblighi NIS2 per le materie coperte da DORA. In concreto:

La differenza pratica più rilevante per gli operatori è che DORA impone obblighi di test (TLPT) e di controllo della supply chain ICT significativamente più granulari e onerosi rispetto a NIS2. Un fornitore SaaS che serve sia una banca sia un'azienda manifatturiera deve soddisfare due set di requisiti diversi.

2. I cinque pilastri del framework di resilienza DORA

Pilastro 1: Gestione del rischio ICT (Art. 5-16)

L'entità finanziaria deve istituire un quadro completo di gestione del rischio ICT che includa:

• Identificazione, classificazione e mappatura di tutti gli asset ICT
• Analisi dell'impatto aziendale (Business Impact Analysis) per ogni asset critico
• Strategie di protezione, inclusi crittografia, controllo accessi, segmentazione di rete
• Meccanismi di rilevamento delle anomalie (monitoring continuo, SOC interno o esternalizzato)
• Piani di risposta e ripristino, con obiettivi di Recovery Time (RTO) e Recovery Point (RPO) documentati
• Meccanismi di apprendimento post-incidente e aggiornamento continuo del framework

La responsabilità ultima del framework ricade sull'organo di amministrazione, che deve approvarlo, riesaminarlo almeno annualmente e ricevere formazione adeguata sui rischi ICT.

Pilastro 2: Gestione degli incidenti ICT (Art. 17-23)

DORA introduce una classificazione armonizzata degli incidenti ICT gravi a livello europeo. Le entità finanziarie devono:

• Registrare tutti gli incidenti ICT in un registro interno
• Classificare gli incidenti secondo i criteri definiti dagli RTS (numero di clienti impattati, durata, entità economica, diffusione geografica, perdita di dati)
• Notificare gli incidenti classificati come gravi all'autorità di vigilanza competente entro i termini prescritti:
  • Notifica iniziale: entro 4 ore dalla classificazione, e comunque non oltre 24 ore dal rilevamento
  • Notifica intermedia: aggiornamento sullo stato della risposta
  • Notifica finale: entro 30 giorni dalla classificazione, con rapporto completo

In Italia, le autorità di notifica sono Banca d'Italia (per banche e IP), Consob (per imprese di investimento e gestori), IVASS (per assicurazioni).

Pilastro 3: Test di resilienza operativa (Art. 24-27)

Obbligatorio per tutte le entità finanziarie: un programma annuale di test di resilienza basato su scenari di minaccia realistici. Non è sufficiente un penetration test annuale generico.

Obbligatorio per le entità finanziarie più significative: Threat-Led Penetration Testing (TLPT) con cadenza almeno triennale. Il TLPT è un test di intrusione guidato dall'intelligence sulle minacce, che simula le tattiche, tecniche e procedure (TTP) di un attore malevolo reale. Deve essere condotto da tester esterni qualificati, coprire più vettori di attacco e includere i fornitori ICT critici nel perimetro di test.

Pilastro 4: Rischio della catena di fornitura ICT (Art. 28-30)

È la novità con il maggiore impatto sui fornitori di servizi cloud, SaaS, data center e cybersecurity che servono il settore finanziario. L'entità finanziaria deve:

• Mantenere un registro informativo completo di tutti gli accordi contrattuali con fornitori ICT (Art. 28.3)
• Condurre due diligence pre-contrattuale sul fornitore, valutando rischi di concentrazione, subfornitura, localizzazione dei dati e dipendenza
• Inserire nei contratti clausole minime obbligatorie: livelli di servizio, sedi di trattamento dati, obblighi di assistenza in caso di incidente, diritti di audit e test, obblighi di notifica di modifiche rilevanti, strategie di uscita

Il contratto con il fornitore ICT deve consentire all'autorità di vigilanza di ispezionare il fornitore e di richiedere documentazione direttamente. Questa disposizione trasforma i fornitori ICT da soggetti esterni a soggetti direttamente esposti al potere ispettivo delle autorità finanziarie.

Pilastro 5: Condivisione di informazioni (Art. 45-46)

Meccanismi volontari di condivisione di informazioni sulle minacce cyber tra entità finanziarie, nel rispetto della riservatezza e delle regole di concorrenza.

3. Fornitori ICT critici: chi sono e cosa rischiano

Le European Supervisory Authorities (ESA) designano i fornitori terzi di servizi ICT come critici quando la loro interruzione potrebbe avere un impatto sistemico sul settore finanziario europeo. I fornitori designati sono soggetti a:

• Supervisione diretta da parte di un Lead Overseer designato tra le ESA
• Poteri ispettivi e di richiesta documentale estesi
• Raccomandazioni vincolanti sulle misure di mitigazione del rischio
• Penalità di mora per inadempimento (fino all'1% del fatturato medio giornaliero mondiale)

Allo stato attuale (giugno 2026), le ESA hanno designato come critici i principali fornitori di servizi cloud (AWS, Microsoft Azure, Google Cloud), diversi fornitori SaaS per il settore finanziario e operatori di infrastrutture di comunicazione dati.

4. Cosa fare subito

1. Classificare se l'organizzazione ricade nell'ambito DORA: verificare il perimetro delle entità finanziarie (Art. 2) e, in caso affermativo, identificare le autorità di vigilanza competenti
2. Mappare tutti i fornitori ICT e inserirli nel registro informativo, con indicazione del tipo di servizio, criticità, subfornitori e meccanismi di uscita
3. Rivedere i contratti con i fornitori ICT per verificare la presenza delle clausole obbligatorie ex Art. 30 DORA
4. Pianificare il programma annuale di test di resilienza, identificando se l'entità rientra tra quelle soggette a TLPT obbligatorio
5. Predisporre le procedure di classificazione e notifica degli incidenti secondo lo schema armonizzato europeo

Per una consulenza specifica sugli obblighi DORA, si rimanda al servizio di consulenza DORA e NIS2.

Domande Frequenti (FAQ)

Una startup fintech autorizzata come istituto di pagamento è soggetta a DORA? Sì. Tutti gli istituti di pagamento autorizzati ai sensi della PSD2 rientrano nell'ambito DORA. L'intensità degli obblighi (incluso l'obbligo di TLPT) dipende dalla classificazione dimensionale e dal profilo di rischio determinato dall'autorità di vigilanza. Le startup fintech in fase early-stage possono non essere soggette a TLPT, ma devono comunque istituire il framework di gestione del rischio ICT, il registro dei fornitori e le procedure di notifica incidenti.

DORA si applica ai fornitori SaaS che non operano nel settore finanziario? Sì, se il fornitore SaaS ha come clienti entità finanziarie soggette a DORA. In tal caso, le entità finanziarie clienti devono includere nel contratto con il fornitore le clausole obbligatorie ex Art. 30 DORA (audit, ispezione, notifica modifiche, strategia di uscita) e inserire il fornitore nel proprio registro informativo. Se il fornitore SaaS viene designato come fornitore ICT critico dalle ESA, è soggetto a supervisione diretta con poteri ispettivi e sanzionatori.

Qual è il rapporto tra incidente DORA e data breach GDPR? Un incidente ICT grave ai sensi DORA può coincidere con un data breach GDPR se coinvolge dati personali. In tal caso, l'entità finanziaria deve effettuare una doppia notifica: all'autorità di vigilanza finanziaria (Banca d'Italia/Consob/IVASS) per DORA ed entro 72 ore al Garante Privacy per GDPR. I criteri di classificazione e i termini di notifica sono diversi e indipendenti.

Le sanzioni DORA sono diverse per banche e fintech? Sì. DORA non stabilisce importi sanzionatori autonomi: demanda alle autorità nazionali l'applicazione delle sanzioni previste dalle normative di settore. Per le banche, il TUB prevede sanzioni fino al 10% del fatturato annuo; per gli istituti di pagamento e IMEL, le sanzioni sono parametrate su fasce dimensionali. Le ESA hanno comunque il potere di irrogare penalità di mora fino all'1% del fatturato medio giornaliero per inottemperanza alle loro raccomandazioni.

Approfondimenti consigliati:

• NIS2 e DORA: Obblighi e Scadenze per le Aziende
• NIS2: Sicurezza Supply Chain e Responsabilità Board
• Data Breach e Mancata Notifica: Sanzioni del Garante

Fonti: Reg. UE 2022/2554, EUR-Lex; Banca d'Italia, DORA; ESAs, DORA Regulatory Technical Standards.