La BCE richiede alle banche sottoposte alla sua vigilanza diretta, i cosiddetti enti «significativi», un piano d'azione contro gli attacchi informatici basati sull'IA. In Italia, la Banca d'Italia ha esteso un'esigenza analoga a una larga parte del mercato che vigila direttamente a livello nazionale. Tuttavia, non viene richiesto un documento strategico, bensì la prova di una capacità operativa. Questo articolo chiarisce cosa si richiede concretamente, dove si annidano le difficoltà pratiche e come sfruttare al meglio le settimane rimanenti, in vista di entrambe le scadenze.
Il 7 luglio, la vigilanza bancaria della BCE ha inviato una lettera a circa 110 enti significativi. L’indicazione è chiara: presentare, entro il 31 ottobre, un piano d’azione dedicato contro gli attacchi informatici basati sull’IA. Che la BCE affronti il tema non sorprende; ciò che colpisce è il livello di precisione raggiunto. Un semplice documento strategico non basta più: viene richiesta la prova di una capacità operativa. Il ritmo di correzione delle vulnerabilità ne è l’esempio più eloquente. Se un tempo tre mesi potevano sembrare difendibili per colmare una falla, oggi conta una risposta nel giro di poche ore. E la responsabilità ricade sul consiglio di amministrazione.
La lettera è stata deliberatamente indirizzata alla direzione generale, non al reparto informatico. A ciò si aggiunge un avvertimento del CERS del 25 giugno sui rischi cyber sistemici legati ai modelli di IA e, nel contempo, il rinvio del questionario annuale sui rischi informatici da parte del supervisore. Il segnale è inequivocabile: questo tema ha il suo posto all’ordine del giorno del consiglio di amministrazione!
I fondamenti del piano d'azione
Il piano d'azione non crea un nuovo corpus di regole: rende operativi requisiti che DORA già impone, ma con un livello nettamente più elevato di rapidità e verificabilità. Il regolamento (UE) 2022/2554 sulla resilienza operativa digitale è pienamente applicabile dal 17 gennaio 2025 e struttura la resilienza del settore finanziario attorno a cinque pilastri: la gestione del rischio legato alle TIC, la gestione e la notifica degli incidenti legati alle TIC, i test di resilienza digitale, la gestione del rischio legato a terzi e la condivisione delle informazioni.
In questo quadro, il piano d'azione cyber IA non introduce nulla di nuovo: chiede di rafforzare tre di questi pilastri sotto la pressione degli attacchi basati sull'IA. In particolare: la gestione del rischio TIC (so con precisione che cosa devo proteggere? Con quale rapidità posso reagire?), i test di resilienza (le mie ipotesi reggono sotto un carico reale?) e il rischio legato a terzi (quanto dipendo, e da chi?). Gli enti che hanno già preso sul serio DORA non ripartono da zero; quelli che l'hanno affrontato come un semplice esercizio documentale vedranno ora dove si trovano le lacune.
Cosa significa questo per gli enti italiani
La lettera della BCE si applica agli enti posti sotto la sua vigilanza diretta, tra cui rientrano i grandi gruppi bancari italiani. Per il resto del mercato, l’autorità di vigilanza diretta è la Banca d’Italia: banche e gruppi bancari meno significativi (compresa Bancoposta), istituti di pagamento e di moneta elettronica, imprese di investimento, fornitori di servizi per le cripto-attività, gestori di fondi alternativi, società di gestione, fornitori di servizi di crowdfunding e intermediari finanziari ex articolo 106 del TUB. Gli obblighi DORA sono già effettivi per tutti: notifica degli incidenti gravi legati alle TIC dal 17 gennaio 2025 e trasmissione del registro delle informazioni che censisce l’insieme dei fornitori TIC. La Banca d’Italia ha inoltre integrato questo impianto nella Circolare 285: il 51° aggiornamento, pubblicato a febbraio 2026, ha sostituito le precedenti disposizioni nazionali sulla governance informatica e sulla gestione dei rischi con un rinvio diretto al regolamento DORA.
Il 17 luglio 2026 la Banca d’Italia ha pubblicato una comunicazione al mercato che estende alle entità da essa vigilate un’esigenza analoga a quella della BCE. Il testo chiede di rafforzare cinque aree: governance, igiene informatica, gestione delle risorse informatiche e della superficie di esposizione, gestione delle vulnerabilità e degli aggiornamenti, nonché monitoraggio e test di resilienza. Richiede inoltre l’esame del tema in consiglio di amministrazione congiuntamente al collegio sindacale e la designazione di un punto di responsabilità, ad esempio la funzione di controllo dei rischi informatici di secondo livello. La relazione e il relativo piano di lavoro devono essere trasmessi alla Vigilanza entro il 31 dicembre 2026, non entro il 31 ottobre. Nessuna soglia dimensionale esenta le entità appartenenti a queste categorie: attendere un ulteriore chiarimento non è dunque una strategia.
Come il supervisore valuterà l'attuazione
Il gruppo di vigilanza congiunto (JST) — o, a seconda del vostro status, la Vigilanza della Banca d'Italia — non si limiterà a leggere il documento: ne valuterà la sostanza. Quattro elementi distinguono un piano solido da una semplice dichiarazione di intenti:
- Misure concrete, non principi: il piano deve indicare quali sistemi sono coinvolti, in quale ordine saranno trattati e quali valori obiettivo si applicano. Vaghe intenzioni di miglioramento non bastano.
- Persone nominate, non solo comitati: occorre designare un titolare del piano, dotato di un mandato reale e non di una responsabilità puramente formale.
- Risorse allocate: budget e personale devono risultare impegnati in modo visibile, non soltanto promessi.
Il quarto elemento è anche la domanda decisiva: potete dimostrare ciò che affermate? In questo contesto, «dimostrare» significa poter fornire, su richiesta, tre elementi di prova:
- Sul ritmo di correzione: un'analisi che mostri, per le più recenti vulnerabilità critiche pubblicate, quante ore o giorni siano trascorsi tra la pubblicazione e l'implementazione della correzione sull'intero parco. I dati devono essere presentati come distribuzione nel tempo, con marcatura temporale. Una media arrotondata non soddisferà il supervisore. Ad esempio: il 95% delle CVE critiche è stato corretto entro 72 ore.
- Sulla trasparenza degli asset: un confronto tra l'inventario effettivamente rilevato e la vostra CMDB, che renda evidente lo scarto. Deve mostrare quanti endpoint, server e carichi di lavoro cloud esistano senza figurare in alcun elenco ufficiale e con quali mezzi vengano individuati sistemi non gestiti e obsoleti. Lo scarto stesso è la prova più eloquente.
- Sull'avanzamento: un rapporto che possiate generare rapidamente — in pochi minuti e a partire da un'unica fonte di dati — datato e tracciabile. Se il supervisore pone la domanda oggi, la risposta deve essere pronta, non assemblata manualmente da sistemi diversi.
Il denominatore comune: cifre con marcatura temporale, provenienti da una fonte affidabile e riproducibili in qualsiasi momento.
Dove si annidano le difficoltà pratiche
Le esigenze possono sembrare ovvie. Eppure, per molti enti, le difficoltà non dipendono dalla mancanza di volontà, bensì da strutture sedimentate nel tempo. Cinque schemi ricorrono con costanza:
- Un panorama di strumenti frammentato: inventario, vulnerabilità, correzioni e reportistica sono distribuiti su soluzioni distinte. Ogni richiesta del supervisore si traduce in una raccolta di dati che attraversa i confini tra sistemi.
- Una CMDB in ritardo: la base di configurazione riflette lo stato target, non quello reale. Tra realtà e base si crea uno scarto che nessuno riesce a colmare in tempo reale.
- Punti ciechi: dispositivi non gestiti, shadow IT e sistemi obsoleti non compaiono in alcun elenco. Sono proprio questi i punti d’ingresso più ambiti dagli attaccanti.
- Mondi separati tra IT e sicurezza: spesso chi individua una vulnerabilità non è chi la corregge. Ogni passaggio di consegne aggiunge ritardi che oggi non ci si può più permettere.
- Dipendenza dalla finestra di manutenzione: quando l’IA genera exploit in poche ore, cicli di correzione reattivi e periodici non sono più sufficienti.
A ciò si aggiunge che molte organizzazioni producono ancora manualmente le prove destinate al supervisore, con fogli di calcolo assemblati durante la notte. Non è un processo né ripetibile né robusto e non regge se il supervisore pone domande in tempi rapidi.
Avranno successo le organizzazioni che vedranno questa scadenza non come un fastidioso esercizio di conformità, ma come un catalizzatore per realizzare automazione e cambiamenti operativi attesi da tempo.
La vostra tabella di marcia per le prossime settimane
Nel poco tempo che resta prima della scadenza — il 31 ottobre o il 31 dicembre, a seconda del vostro status — ciò che conta è rendere il piano operativo. I quattro compiti seguenti sono strettamente interconnessi:
- Definite un inventario completo. Ottenete una visione in tempo reale di endpoint, server e carichi di lavoro cloud, includendo anche i sistemi non gestiti e obsoleti. Confrontate i risultati con la vostra CMDB: lo scarto è rischio. Solo sapendo cosa gestite potete stabilire le priorità.
- Rendete la velocità misurabile. Adottate come indicatore il tempo che intercorre tra la pubblicazione di una vulnerabilità critica e l’implementazione della correzione sull’intero parco (tempo medio di correzione) e iniziate a misurarlo. Sganciate la misurazione dalle finestre di manutenzione; altrimenti misurerete il calendario, non la capacità di reazione.
- Predisponete le prove. Assicuratevi che i progressi siano dimostrabili con un clic, da un’unica fonte di dati, con marcatura temporale, pronti per la supervisione (JST o Vigilanza, a seconda del vostro status). Un rapporto generato in pochi minuti è più convincente di uno assemblato in più giorni.
- Ancorate la responsabilità. Designate un responsabile con mandato e budget e portate il tema in una cadenza regolare del consiglio di amministrazione, sugli stessi indicatori utilizzati dal supervisore.
In pratica, la sequenza è questa: prima trasparenza e indicatori; poi automazione e prove costruite su di essi, con la governance avviata in parallelo fin dall’inizio. Le organizzazioni che seguono questo schema arriveranno alla scadenza con un piano e, soprattutto, con le prove a sostegno.
Dal piano a una realtà dimostrabile
In qualità di piattaforma per l’IT autonomo, Tanium riunisce inventario, vulnerabilità, correzioni e prove in un’unica base dati, sempre aggiornata. Un agente leggero sostituisce così un ecosistema di strumenti frammentato. Il risultato è una visibilità in tempo reale su tutti gli endpoint, l’automazione delle correzioni e una capacità di reazione autonoma. Un piano d’azione credibile si traduce quindi in una realtà operativa dimostrabile, in grado di reggere all’esame del supervisore, sia esso la BCE o la Banca d’Italia.
Le scadenze sono già fissate. La domanda non è se potete presentare un piano, ma se regge.