La diga digitale: DORA, NIS2 e la resilienza che diventa legge

Il 18 novembre 2025 le tre Autorità europee di vigilanza — EBA, EIOPA, ESMA — hanno pubblicato la prima lista ufficiale dei fornitori ICT «critici» del settore finanziario europeo. Diciannove nomi. In cima, come prevedibile, i soliti: Amazon Web Services, Microsoft, Google Cloud, Oracle, SAP, Deutsche Telekom (EIOPA, 18 novembre 2025). Diciannove aziende — quasi tutte non europee — sulle cui infrastrutture poggia la tenuta operativa di banche, assicurazioni e fintech di mezzo continente. Da quel giorno, quei diciannove fornitori sono soggetti alla vigilanza diretta delle Autorità europee. È la prima volta che un’Autorità finanziaria mette le mani, formalmente, dentro la sala macchine di un colosso del cloud.

Questo è il punto dove la «sovranità tecnologica» smette di essere uno slogan da conferenza e diventa un registro da compilare, un incidente da segnalare entro quattro ore, un penetration test da superare. Si chiama DORA. Si chiama NIS2. E per chi maneggia denaro altrui non sono più un’opzione.

1. DORA: la resilienza diventa legge, non buona volontà

Il Regolamento (UE) 2022/2554 — Digital Operational Resilience Act, DORA per gli amici — si applica dal 17 gennaio 2025 (EUR-Lex; Banca d’Italia). Essendo un regolamento e non una direttiva, non ha bisogno di recepimento: vale identico, parola per parola, in tutti gli Stati membri. Niente alibi nazionali, niente «ce lo siamo dimenticati a Roma».

L’idea di fondo è brutale nella sua semplicità. Per anni la regolamentazione finanziaria ha misurato la solidità di una banca con il capitale: quanti soldi hai messo da parte per assorbire le perdite. DORA aggiunge una domanda che fino a ieri stava nel cono d’ombra: e se ti spengono i sistemi? Se il fornitore cloud va giù, se un ransomware ti cripta i server, se un attacco ti tiene fuori dai pagamenti per tre giorni, quanto reggi? La resilienza operativa digitale è diventata una grandezza vigilata al pari del capitale.

DORA si rivolge a una platea larghissima — venti tipologie di entità finanziarie (EUR-Lex): banche, imprese di investimento, assicurazioni, istituti di pagamento e di moneta elettronica, gestori di cripto-attività, piattaforme di crowdfunding, e perfino i fornitori ICT che le servono. In Italia rientrano nell’ambito anche Cassa Depositi e Prestiti e Poste Italiane per il Bancoposta (Banca d’Italia).

2. I cinque pilastri (e dove ti fanno male)

DORA poggia su cinque blocchi. Vale la pena conoscerli per nome, perché ognuno corrisponde a un obbligo concreto, datato, con scadenze già passate.

Primo: la gestione del rischio ICT. Ogni entità finanziaria deve dotarsi di un quadro di gestione del rischio informatico solido, documentato, parte integrante del sistema di governo complessivo (art. 6 DORA). Non un faldone da mostrare all’ispettore, ma strategie, politiche, procedure e strumenti che proteggano davvero gli asset informativi. E qui scatta un principio che ai consigli di amministrazione italiani non piace sentire: la responsabilità ultima è dell’organo di gestione. Non del responsabile IT. Non del fornitore. Del board.

Secondo: la segnalazione degli incidenti. Su questo torno più sotto, perché è il pilastro che genera più adrenalina.

Terzo: i test di resilienza. Dai test di base annuali fino ai famigerati TLPT — threat-led penetration testing — di cui parlo tra poco.

Quarto: il rischio dei fornitori terzi. Il cuore politico della faccenda.

Quinto: la condivisione delle informazioni sulle minacce tra operatori, su base volontaria.

3. Segnalare l’incidente: la corsa contro le quattro ore

Qui DORA mostra i denti. Quando un’entità finanziaria subisce un incidente ICT classificato come «grave», scatta un cronometro a tre tempi (RTS sulla segnalazione degli incidenti): una notifica iniziale entro quattro ore dalla classificazione dell’incidente come grave, un rapporto intermedio entro 72 ore, e un rapporto finale entro un mese.

Quattro ore. Chiunque abbia vissuto un incidente informatico vero sa cosa significhi: sono le quattro ore in cui i sistemi vanno a fuoco, nessuno capisce ancora cosa stia succedendo, il telefono squilla e tu devi già avere pronto un canale, un modulo, una catena di comando che dica chi firma la segnalazione. Improvvisare, lì, non è un’opzione.

Cosa rende un incidente «grave»? Le norme tecniche fissano soglie di materialità: numero di clienti colpiti, durata del disservizio, estensione geografica, perdita di dati, criticità dei servizi coinvolti, impatto economico (RTS sulla classificazione degli incidenti). In Italia la segnalazione passa dalla piattaforma INFOSTAT della Banca d’Italia, che il 27 dicembre 2024 ha pubblicato le istruzioni operative (Banca d’Italia). La platea italiana — banche, SIM, istituti di pagamento, gestori di cripto-attività e gli altri soggetti vigilati — segnala lì gli incidenti gravi e, su base volontaria, le minacce informatiche significative.

Vale la pena fissare la differenza con il binario gemello: per i soggetti NIS2 il cronometro è diverso e in parte più stretto sul primo gradino — pre-notifica (early warning) entro 24 ore dall’evidenza dell’incidente significativo, notifica completa entro 72 ore (Aegister, su art. 25 NIS2 / linee guida ACN, 2025). Due regimi paralleli, due orologi che partono in momenti diversi: chi sta in entrambi i perimetri deve sapere quale far scattare, e quando.

4. I fornitori terzi: chi controlla chi tiene in piedi tutto

Veniamo al nodo che apre l’articolo. La storia degli ultimi vent’anni di finanza è anche la storia di una migrazione: dai server nello scantinato della banca al cloud di tre o quattro giganti americani. Comodo, scalabile, economico. E concentrato in modo pericoloso.

I numeri spiegano l’ansia regolatoria meglio di mille premesse. Nel 2025 i tre big — AWS, Microsoft Azure e Google Cloud — controllavano circa il 68% del mercato globale dell’infrastruttura cloud, con AWS intorno al 33%, Azure al 23% e Google Cloud al 12% (BusinessTats / Quantumrun, dati di mercato 2025, da verificare nelle stime puntuali). La concentrazione cresce ogni anno dal 2018, perché il costo del capitale per costruire data center competitivi ha di fatto chiuso la porta ai nuovi entranti. Non a caso la Commissione europea ha aperto istruttorie per valutare se Amazon e Microsoft vadano designati come gatekeeper per il cloud sotto il Digital Markets Act (CIO Dive, 2025). Se uno di questi tre cade, non cade una banca: cade un pezzo di sistema.

C’è poi un secondo strato, meno visibile e più insidioso: il subappalto. La banca firma con il fornitore cloud, ma quel fornitore a sua volta si appoggia ad altri — data center fisici, servizi di rete, sicurezza gestita, manutenzione — in una catena che può allungarsi di tre o quattro anelli. Il rischio non sta solo nel contraente di primo livello: sta nel sub-fornitore del sub-fornitore, quello che la banca non ha mai visto e che pure può spegnerle i sistemi (Cyber Security 360, 2025). DORA pretende che questa catena sia mappata, non lasciata nel buio.

DORA affronta il problema su due livelli. Il primo è il registro delle informazioni: ogni entità finanziaria deve tenere un registro strutturato e costantemente aggiornato di tutti gli accordi con i fornitori ICT terzi (art. 28 DORA). Non un elenco a uso interno: è uno strumento di vigilanza, ispezionabile in qualsiasi momento e da trasmettere alle Autorità. In Italia la prima trasmissione del registro alla Banca d’Italia era fissata al 15 aprile 2025 (Banca d’Italia).

Il secondo livello è il colpo di teatro: la vigilanza diretta sui fornitori critici. Per la prima volta, soggetti che non sono entità finanziarie — i grandi cloud provider — finiscono sotto il controllo diretto delle Autorità europee di vigilanza. Il 18 novembre 2025 le ESA hanno designato 19 fornitori ICT critici (CTPP), seguendo una metodologia basata su quattro criteri: l’impatto sistemico di un eventuale collasso del fornitore, l’importanza sistemica delle entità finanziarie che ne dipendono, la concentrazione della dipendenza nei settori bancario, assicurativo e dei mercati, e la sostituibilità dei suoi servizi (EIOPA, 18 novembre 2025).

Cosa possono fare le ESA verso un fornitore critico? Valutarne i presidi di gestione del rischio e di governance, le procedure su segnalazione incidenti, subappalto e sicurezza ICT — il lavoro lo svolgono i Joint Examination Team, squadre miste di personale ESA, autorità di vigilanza finanziaria e autorità NIS (2B Advice, luglio 2025). E, se trovano falle, emettere raccomandazioni. Se il fornitore non si adegua, deve spiegarne il perché; in ultima istanza, l’Autorità può rendere pubblica la non conformità e — arma estrema — imporre alle entità finanziarie di sospendere o risolvere il contratto con quel fornitore (Morgan Lewis, novembre 2025). Un regolatore finanziario europeo che può, in teoria, ordinare a una banca di staccarsi da un hyperscaler americano. Questa è sovranità tecnologica tradotta in potere coercitivo.

5. Le clausole che ora DEVONO esserci nei contratti ICT (art. 30)

Qui il discorso scende dal piano dei princìpi a quello della penna dell’avvocato. L’art. 30 DORA non si limita a dire «fate dei buoni contratti»: detta un contenuto minimo obbligatorio, parola che ai negoziatori dei colossi cloud — abituati a contratti di adesione «prendere o lasciare» — suona come una dichiarazione di guerra. Il comma 2 fissa le clausole valide per ogni accordo ICT; il comma 3 aggiunge un pacchetto rinforzato quando il servizio sostiene funzioni essenziali o importanti (art. 30, par. 2 e 3, DORA; DB — dirittobancario.it, 2025).

Tradotto in concreto, dentro un contratto ICT a regola d’arte oggi devono comparire, tra l’altro:

Clausola	Cosa impone in pratica
Sicurezza e protezione dei dati	Garanzie su disponibilità, autenticità, integrità e riservatezza dei dati — a riposo, in uso, in transito
Livelli di servizio (SLA)	Descrizione puntuale delle prestazioni e obiettivi misurabili, non formule vaghe
Accesso, ispezione e audit	Diritto della banca (e dell’Autorità) di monitorare e ispezionare il fornitore
Subappalto	Condizioni e limiti al ricorso a sub-fornitori per le funzioni critiche
Recesso e strategia di uscita	Diritti di risoluzione con preavviso e piano per migrare via senza restare bloccati
Cooperazione con le Autorità	Assistenza in caso di incidente e partecipazione ai programmi di sicurezza ICT

La clausola che pesa di più è la strategia di uscita. Per anni i contratti cloud sono stati congegnati per trattenere: formati proprietari, costi di migrazione proibitivi, dipendenza progettata a tavolino. DORA pretende che la banca possa andarsene — ordinatamente, senza interruzione del servizio — perché un fornitore da cui non puoi separarti non è un fornitore, è un padrone. Chi ancora oggi tiene nel cassetto vecchi contratti di outsourcing senza queste clausole non ha un contratto: ha un’esposizione.

6. TLPT: farsi attaccare per davvero

C’è un pilastro che separa i test di facciata dai test che fanno paura. Si chiama TLPT, threat-led penetration testing: penetration test guidati dalle minacce reali. Non una checklist, ma una squadra di red team che simula l’attacco di un avversario vero contro i sistemi di produzione — quelli veri, non l’ambiente di prova — per vedere se reggono.

Le norme tecniche sui TLPT sono state pubblicate il 18 giugno 2025 sulla base dell’art. 26 DORA (TIBER.info, giugno 2025), e si appoggiano al collaudato framework TIBER-EU della BCE. Non tutti sono obbligati: il test riguarda le entità finanziarie significative, individuate secondo criteri di rilevanza e rischio sistemico, e va ripetuto almeno ogni tre anni. La BCE ha pubblicato a novembre 2025 la guida aggiornata su come implementare TIBER-EU per i TLPT di DORA (Banking Supervision BCE, novembre 2025).

La logica è sana e antica quanto la sicurezza stessa: non puoi sapere se una serratura tiene finché qualcuno non prova a scassinarla. DORA istituzionalizza lo scassinatore, lo mette a libro paga, e pretende che il consiglio di amministrazione legga il referto.

7. NIS2: l’altra metà del cielo (e il recepimento italiano)

DORA non vive da sola. Accanto corre la Direttiva (UE) 2022/2555 — NIS2 — il quadro generale europeo sulla cybersicurezza, che alza l’asticella per un’enorme platea di soggetti pubblici e privati in settori critici. In Italia è stata recepita con il D.Lgs. 4 settembre 2024, n. 138, pubblicato in Gazzetta Ufficiale n. 230 del 1° ottobre 2024 ed entrato in vigore il 16 ottobre 2024 (ACN).

NIS2 introduce il criterio dimensionale (la cosiddetta size-cap rule) e distingue tra soggetti essenziali e soggetti importanti: i primi, operatori in settori altamente critici che superano le soglie dimensionali (oltre 250 dipendenti, oppure fatturato sopra 50 milioni o bilancio sopra 43 milioni); i secondi, gli altri operatori dei settori individuati dagli allegati (ACN). L’Autorità nazionale competente è l’Agenzia per la Cybersicurezza Nazionale (ACN).

Le scadenze italiane sono già scattate: la registrazione sulla piattaforma ACN era aperta dal 1° dicembre 2024, con autovalutazione e registrazione come soggetto essenziale, importante o fuori ambito da completare entro il 28 febbraio 2025 (ACN). E il 2026 è l’anno della verità: dalla compliance formale — dichiarare di appartenere al perimetro — si passa a quella sostanziale. Tra il 15 aprile e il 31 maggio 2026 è in calendario l’aggiornamento annuale delle informazioni sul portale ACN, e per i soggetti inclusi nella prima tornata il termine per dimostrare la piena implementazione delle misure di sicurezza cade nei diciotto mesi successivi alla notifica (ICT Security Magazine; BSD Legal, 2026; da verificare alla luce delle determinazioni ACN più recenti).

8. Chi paga: le sanzioni

Fin qui i princìpi. Ma il diritto, si sa, comincia a mordere quando si passa al conto. E i conti, qui, sono pesanti.

Sul versante DORA, il quadro sanzionatorio nazionale è affidato alle Autorità di settore — Banca d’Italia, Consob, IVASS, COVIP, ciascuna sul proprio perimetro (DB — dirittobancario.it, 2025). Per i fornitori critici (CTPP) sotto vigilanza diretta delle ESA c’è uno strumento specifico e calibrato per fare male a chi è troppo grande per le multe ordinarie: una penale periodica fino all’1% del fatturato medio giornaliero mondiale del fornitore, applicabile su base giornaliera per un massimo di sei mesi finché la non conformità non viene sanata (2B Advice, luglio 2025). Una sanzione che si misura in giorni: ogni giorno che passa senza rimedio, scatta di nuovo.

Sul versante NIS2, i tetti sono quelli classici del modello europeo «importo fisso o percentuale del fatturato, il maggiore dei due»:

Regime	Sanzione massima
NIS2 — soggetti essenziali	Fino ad almeno 10 milioni di euro o il 2% del fatturato mondiale annuo, il maggiore
NIS2 — soggetti importanti	Fino ad almeno 7 milioni di euro o l’1,4% del fatturato mondiale annuo, il maggiore
CTPP (fornitori critici, DORA)	Penale periodica fino all’1% del fatturato medio giornaliero mondiale, fino a 6 mesi

(Fonti: Randstad / ISGroup su NIS2; 2B Advice su CTPP, 2025; cifre da verificare nei provvedimenti attuativi.) Ma la sanzione pecuniaria, per quanto salata, non è la cosa che dovrebbe far perdere il sonno a un consigliere d’amministrazione. Quella è la responsabilità personale degli organi di gestione: NIS2 prevede che, nei casi più gravi, gli organi direttivi possano essere chiamati a rispondere in prima persona dell’inadempimento, fino alla sospensione temporanea dalla carica per i ruoli apicali. Non è più solo la società a pagare: è chi sedeva al tavolo e non ha vigilato.

9. DORA contro NIS2: chi vince quando si pestano i piedi?

Domanda inevitabile: una banca, che è insieme entità finanziaria (DORA) e soggetto in settore critico (NIS2), a quale delle due risponde? La risposta è un principio giuridico vecchio quanto il diritto romano: lex specialis derogat generali. DORA è legge speciale rispetto a NIS2 per le entità finanziarie che rientrano nel suo ambito (art. 1, par. 2, DORA). Dove DORA detta una regola specifica — gestione del rischio ICT, segnalazione incidenti, test — l’entità finanziaria segue DORA. NIS2 resta sullo sfondo come quadro generale (EUR-Lex; EBA, Single Rulebook Q&A 2024_7060).

Profilo	DORA (Reg. UE 2022/2554)	NIS2 (Dir. UE 2022/2555)
Natura	Regolamento: direttamente applicabile	Direttiva: recepita in Italia con D.Lgs. 138/2024
Destinatari	20 tipologie di entità finanziarie + fornitori ICT	Soggetti essenziali e importanti in molti settori critici
Decorrenza	17 gennaio 2025	In vigore in Italia dal 16 ottobre 2024
Autorità	Banca d’Italia, Consob, IVASS + ESA (fornitori critici)	ACN (Agenzia per la Cybersicurezza Nazionale)
Per il settore finanziario	Legge speciale: prevale	Quadro generale: cede a DORA dove questa disciplina

La regola sembra pulita sulla carta. Nella pratica resta un’area grigia: per i profili che DORA non disciplina espressamente, la disciplina generale può riaffacciarsi. Tradotto per chi deve adempiere: non basta «fare DORA» e archiviare NIS2. Serve una mappatura puntuale di quale norma morde su quale obbligo. Chi semplifica troppo, qui, rischia di scoprire la lacuna nel momento peggiore — durante un’ispezione.

10. Cosa resta sul tavolo dell’avvocato (e del board)

Il filo che lega tutto — sovranità tecnologica, cloud concentrato, fornitori critici, vigilanza diretta — è questo: l’Europa ha smesso di considerare la tenuta informatica del settore finanziario una faccenda tecnica da delegare all’IT. L’ha fatta diventare una questione di vigilanza prudenziale, con responsabilità che salgono fino al consiglio di amministrazione e poteri che scendono fino a ordinare la rottura di un contratto con un gigante del cloud.

Per chi assiste banche, assicurazioni e fintech il lavoro è cambiato di natura. Non è più redigere un contratto di outsourcing e dimenticarlo nel cassetto. È ricostruire la catena delle dipendenze ICT fino al sub-fornitore nascosto, riscrivere le clausole dell’art. 30 nei contratti con i fornitori, verificare che il registro delle informazioni sia davvero ispezionabile, controllare che la procedura delle quattro ore esista su carta e funzioni nei fatti, presidiare il confine mobile tra DORA e NIS2. È un mestiere nuovo, a metà tra il diritto, la governance e l’ingegneria del rischio.

Una cosa è certa: le scadenze del 2025 sono passate, e il 2026 è l’anno in cui le Autorità smettono di accompagnare e cominciano a ispezionare. Chi pensava che la resilienza digitale fosse un esercizio di stile sta per scoprire che era una scadenza vera. Con un cronometro che, ormai, è già partito.

Tutte le affermazioni di questo articolo sono ancorate a fonti verificabili e datate, citate inline. I dati riflettono le informazioni disponibili al 23 giugno 2026 e vanno verificati alla luce degli sviluppi successivi.