Il 7 luglio 2026 la Banca Centrale Europea (BCE) ha inviato una lettera a tutte le banche significative dell’Eurozona, quelle sottoposte alla vigilanza diretta nell’ambito del Meccanismo di vigilanza unico, chiedendo di presentare entro il 31 ottobre un piano d’azione per rafforzare la resilienza informatica contro le minacce abilitate dall’intelligenza artificiale.
Il documento innesta sui requisiti già previsti dal Digital Operational Resilience Act (DORA) una scadenza precisa e un elenco di priorità operative.
Al centro della lettera figura un blocco di misure, dettagliato nell’Annex alla stessa, volto a illustrare cosa devono fare esattamente le banche vigilate da Francoforte da qui a ottobre. Disposizioni che si prestano ad essere estese anche alle aziende che banche non sono.
Indice degli argomenti
La lettera alle banche della BCE
Le ragioni dell’iniziativa sono anzitutto tecniche: l’intelligenza artificiale consente oggi di individuare vulnerabilità software e generare exploit funzionanti in tempi assai più rapidi rispetto al passato, e operazioni che fino a poco tempo fa richiedevano giorni di lavoro manuale da parte di ricercatori esperti, come l’analisi di un codice sorgente alla ricerca di una falla o la costruzione di un exploit funzionante a partire da quella falla, possono oggi essere automatizzate in larga misura.
A contrarsi è soprattutto il margine temporale a disposizione di un’organizzazione per individuare e correggere una vulnerabilità prima che venga sfruttata, un margine su cui si sono storicamente calibrati i cicli di patch periodici adottati dalla maggior parte delle infrastrutture aziendali.
È su questa compressione, l’elemento realmente inedito del fenomeno, che la BCE chiede alle banche di intervenire, collegando esplicitamente il tema alla resilienza operativa richiesta da DORA.
I 4 fronti al centro della lettera alle banche della BCE
Nel breve periodo, la BCE chiede di intervenire su quattro fronti precisi. Il primo consiste nella protezione della superficie di attacco, attraverso la mappatura di tutti gli asset ICT, compresi software di terze parti e componenti open source, e il monitoraggio continuo degli asset esposti su Internet, degli ambienti cloud e delle connessioni verso soggetti esterni, dove si concentra la maggior parte dei tentativi di intrusione automatizzati.
Il secondo passo è organizzativo: predisporre processi capaci di applicare
correzioni critiche a un ritmo assai più sostenuto di quello abituale, senza compromettere la stabilità dei sistemi in produzione, il che comporta la revisione delle procedure di change management e, dove necessario, dei contratti con i fornitori tecnologici affinché consentano interventi rapidi anche sui sistemi più critici.
Il terzo passo riguarda la capacità di rilevare tempestivamente un attacco, attraverso il rafforzamento del monitoraggio dei log applicativi e del traffico di rete, eventualmente supportato da strumenti di intelligenza artificiale, a condizione che la loro adozione sia preceduta da una valutazione dei rischi e accompagnata da una supervisione umana effettiva.
Il quarto concerne la governance: verificare che budget, personale e strumenti siano adeguati, estendere la formazione, oggi spesso confinata ai soli team di sicurezza, all’insieme del personale, e rafforzare la due diligence sui fornitori ICT critici, anche a livello contrattuale e negli accordi sui livelli di servizio.
Ogni piano dovrà essere trasmesso al Joint Supervisory Team competente, che lo discuterà con la singola banca, mentre la BCE condurrà in parallelo un’analisi complessiva di tutti i piani ricevuti per individuare debolezze ricorrenti e prassi meritevoli di essere condivise con l’intero settore.
Le due direttrici: la difesa in profondità e cyber hygiene e la resilienza operativa
Sul piano strutturale, le banche devono inoltre lavorare su due direttrici di medio e lungo periodo.
La prima è rafforzare la difesa in profondità e la cyber hygiene, muovendo dal presupposto che il perimetro possa comunque essere violato, attraverso la segmentazione e la microsegmentazione delle reti, principi zero trust con verifica continua di utenti e dispositivi, inventari accurati degli asset, privilegi minimi, autenticazione a più fattori, logging esteso e la sostituzione progressiva delle tecnologie legacy o non più supportate.
La seconda è migliorare la resilienza operativa, con test regolari di gestione delle crisi, backup e ripristino coerenti con il quadro DORA, esercitazioni su scenari ad alta velocità e volume, vulnerabilità zero-day, ransomware e interruzioni della filiera cloud, oltre a meccanismi di condivisione delle informazioni sulle minacce tra istituti.
Per alleggerire il carico in questa fase, la BCE ha differito da settembre 2026 a febbraio 2027 la scadenza del questionario annuale sul rischio informatico.
È in questo passaggio, quello che trasforma un principio generale in una domanda operativa, che il ragionamento si estende oltre il perimetro bancario.
Il Digital Operational Resilience Act, richiamato esplicitamente nella lettera, si applica a un insieme di soggetti finanziari, assai più ampio delle sole banche, tra cui assicurazioni, gestori patrimoniali e istituti di pagamento, che condividono dunque lo stesso quadro di riferimento senza aver ricevuto alcuna lettera diretta.
Al di fuori di questo perimetro normativo, qualunque azienda dipendente da fornitori software esterni, componenti open source o infrastrutture cloud, categoria che oggi comprende la quasi totalità delle imprese, si trova esposta al medesimo fenomeno descritto dalla BCE: un margine di reazione più ristretto di quello per cui i processi di sicurezza di molte organizzazioni risultano ancora tarati.
Esercizi utili
Per un’azienda non bancaria il primo esercizio utile coincide con quello richiesto alle banche: conoscere con certezza quali sistemi risultano esposti su Internet e quali dipendono da software di terzi, poiché è da lì che origina la maggior parte degli scenari di compromissione descritti dalla BCE e, nell’avvertimento pubblicato lo stesso giorno, dall’European Systemic Risk Board (ESRB), secondo cui simili incidenti possono propagarsi rapidamente attraverso fornitori tecnologici condivisi da più settori, quello finanziario compreso.
Il secondo esercizio consiste nel verificare i tempi reali con cui vengono applicate le patch critiche, un dato spesso distante da quanto previsto dalla policy interna, poiché è proprio questo scarto tra teoria e prassi a determinare la finestra effettiva di esposizione.
Il terzo esercizio è rileggere i contratti con i fornitori tecnologici, verificando se prevedano tempi di intervento compatibili con una vulnerabilità sfruttabile nel giro di poche ore.
Il quarto è verificare se le decisioni su budget e priorità di sicurezza informatica raggiungano davvero i vertici dell’organizzazione, oppure restino confinate alla sola funzione tecnica, replicando lo stesso nodo che la BCE ha voluto sciogliere imponendo alle banche una responsabilità esplicita a livello di board.
La convergenza trasversale a più giurisdizioni e settori
Le stesse priorità individuate dalla BCE, la mappatura degli asset, l’accelerazione delle patch, il monitoraggio rafforzato e la verifica dei fornitori, trovano peraltro riscontro in indicazioni pubblicate negli ultimi mesi da agenzie come il National Cyber Security Centre britannico, CERT-EU ed ENISA, rivolte alla generalità delle organizzazioni.
Si tratta di una convergenza trasversale a più giurisdizioni e più settori, segno che il problema descritto dalla BCE viene percepito nello stesso modo da chi si occupa di sicurezza informatica, a prescindere dal comparto in cui opera.
Esiste poi un aspetto del rischio che riguarda le aziende in modo trasversale, indipendentemente dall’utilizzo diretto di strumenti di intelligenza artificiale.
Lo stesso avvertimento dell’ESRB richiamato dalla lettera segnala che lo sviluppo dei modelli di AI di frontiera resta concentrato in poche mani fuori dall’Unione Europea, circostanza che spinge un numero crescente di aziende, comprese quelle che adottano tali strumenti per le proprie difese, a dipendere dagli stessi fornitori tecnologici, con il rischio che una singola falla o un singolo incidente si propaghi contemporaneamente a più organizzazioni indipendenti tra loro.
Si tratta di un rischio di concentrazione che merita di entrare nelle valutazioni sui fornitori critici, accanto a quelle più tradizionali su continuità del servizio e
protezione dei dati.
Velocizzare i tempi per correggere una falla critica, appena scoperta
Le risorse a disposizione di una grande banca restano fuori dalla portata della maggior parte delle aziende. La logica di fondo, tuttavia, resta applicabile a qualunque scala.
Anche un’organizzazione di dimensioni contenute può partire dal punto più economico ed efficace, ossia conoscere con esattezza quali sistemi espone su Internet e quanto tempo impiega, oggi, a correggere una falla critica una volta individuata.
Molte realtà, anche al di fuori del settore bancario, potrebbero non essere in grado di rispondere con sicurezza a questa domanda ed è proprio questa la ragione per cui una lettera indirizzata a un centinaio di banche europee finisce per riguardare, nella sostanza, chiunque gestisca sistemi esposti al pubblico.
Partecipa alla community