In breve:
Cyber resilience e banche: secondo quanto riportato da ANRA, la BCE ha chiesto alle banche significative dell’area euro di presentare entro il 31 ottobre 2026 un piano d’azione dedicato. Il perimetro comprende sistemi esposti a Internet, componenti open source, software di terze parti, gestione delle vulnerabilità e tecnologie obsolete. Le priorità di vigilanza BCE 2026-2028 collocano resilienza operativa e capacità ICT tra le aree di attenzione principali, insieme al rischio delle terze parti e alla governance delle applicazioni di intelligenza artificiale. Il riferimento regolamentare resta DORA, applicabile dal 17 gennaio 2025. Cinque priorità operative traducono queste richieste in capacità misurabili.
La scadenza del 31 ottobre 2026: a chi si rivolge e su cosa interviene
L’intelligenza artificiale sta modificando il rischio cyber su due fronti. Le banche la introducono nei processi e nei servizi, mentre gli attaccanti la usano per accelerare ricognizione, individuazione delle vulnerabilità e costruzione degli attacchi. La risposta non può limitarsi a una nuova policy: deve tradursi in capacità misurabili di prevenzione, contenimento e ripristino. È in questo contesto che si colloca la scadenza di fine ottobre.
Chi è coinvolto
La richiesta riguarda gli istituti sottoposti alla vigilanza diretta della BCE, cioè le banche significative dell’area euro, non indistintamente tutte le banche europee. Per gli istituti meno significativi il quadro di riferimento resta quello nazionale, ma le aree di attenzione indicate offrono comunque un parametro utile di autovalutazione.
Su cosa interviene il piano
Il perimetro comprende sistemi esposti a Internet, componenti open source, software di terze parti, gestione delle vulnerabilità e tecnologie obsolete. Il punto centrale è la combinazione dei rischi. Una vulnerabilità su un servizio pubblico, una dipendenza software poco governata o un sistema legacy non segmentato possono offrire all’attaccante un primo accesso. Da lì, credenziali compromesse e connessioni interne troppo permissive consentono di muoversi verso servizi più critici.
L'AI cambia l'equazione del rischio per la cyber resilience delle banche
L'AI dentro i processi bancari
La BCE tratta l’intelligenza artificiale come priorità di medio e lungo periodo e chiede strategie, governance e controlli solidi per gestirne i rischi. L’avvertimento è esplicito: una valutazione insufficiente prima dell’introduzione di un’applicazione di AI può creare vulnerabilità critiche nei sistemi ICT. L’adozione, in altre parole, va governata a monte e non regolarizzata a valle.
L'AI dal lato dell'attaccante
Sul fronte opposto, l’AI riduce tempi e costi delle attività offensive. Ricognizione, individuazione delle vulnerabilità e costruzione delle campagne diventano più rapide ed economiche. Questo non introduce tecniche nuove, ma comprime la finestra temporale a disposizione del difensore e rende più importante la capacità di spezzare la catena di attacco dopo il primo accesso.
Le priorità di vigilanza BCE 2026-2028
Le priorità di vigilanza BCE 2026-2028 collocano la resilienza operativa e le capacità ICT tra le aree di attenzione principali.
Resilienza operativa e capacità ICT
La BCE richiama carenze ricorrenti nelle strategie di cybersecurity, nella gestione degli incidenti e nei framework di rischio delle terze parti. Prevede inoltre follow-up mirati, ispezioni su cybersecurity e terze parti, threat-led penetration testing e approfondimenti sulla dipendenza dai fornitori cloud. Si tratta quindi di un programma di verifica, non di una semplice dichiarazione di indirizzo.
Rischio ICT delle terze parti e dipendenza dal cloud
Il rischio ICT delle terze parti è tra i temi che la vigilanza ha indicato come ricorrentemente sottovalutati. Le dipendenze esterne non riguardano soltanto la continuità del servizio fornito: determinano anche quali comunicazioni attraversano l’infrastruttura della banca e con quale livello di privilegio. Un componente di terze parti poco governato è al tempo stesso un rischio di fornitura e un possibile percorso di attacco.
Il rapporto con DORA
Il regolamento DORA, applicabile dal 17 gennaio 2025, fornisce il quadro regolamentare di riferimento per la resilienza operativa digitale del settore finanziario. Le priorità BCE chiariscono che l’attenzione di vigilanza riguarda l’effettiva capacità di prevenire, resistere e riprendersi da interruzioni dei servizi critici, insieme alla rapida correzione delle debolezze già individuate. Gli adempimenti puntuali del regolamento sono trattati nell’approfondimento su DORA e compliance IT per le banche pubblicato su questo blog.
Cinque priorità operative per le banche
Le richieste della vigilanza si traducono in cinque azioni concrete, ordinate secondo la sequenza in cui conviene affrontarle.
1. Mappare l'esposizione reale
Identificare servizi Internet-facing, dipendenze open source, software di terze parti e sistemi legacy, collegandoli ai processi e ai servizi critici che supportano. Un inventario tecnico scollegato dai processi di business non consente di stabilire priorità.
2. Dare priorità alle vulnerabilità in base al rischio
La gravità tecnica va combinata con esposizione, sfruttabilità, valore del sistema e possibili percorsi verso asset critici. Una vulnerabilità di gravità media su un sistema esposto che comunica con un servizio critico merita più attenzione di una vulnerabilità alta su un sistema isolato.
3. Ridurre le comunicazioni non necessarie
Applicare il minimo privilegio tra workload, applicazioni e ambienti per limitare il movimento laterale dopo una compromissione. È la priorità su cui interviene direttamente la segmentazione e quella che produce il risultato più immediato in termini di contenimento.
4. Integrare terze parti e continuità operativa
Le dipendenze esterne devono entrare negli scenari di crisi, nei test, nei piani di risposta e nelle modalità di ripristino. Un piano di continuità che non contempla l’indisponibilità di un fornitore critico non copre lo scenario oggi più probabile.
5. Produrre evidenze verificabili
Il piano deve essere accompagnato da responsabilità, scadenze, metriche di avanzamento, test e tracciabilità delle misure applicate. È la differenza tra un documento presentabile e un piano che regge un’ispezione.
Completamento formale e riduzione effettiva del rischio a confronto
La distinzione più utile da portare in consiglio è tra ciò che dimostra che un’attività è stata svolta e ciò che dimostra che il rischio è diminuito. Le due colonne raramente coincidono.
| Ambito del piano | Evidenza di completamento formale | Evidenza di riduzione del rischio |
|---|---|---|
| Sistemi esposti a Internet | Inventario dei servizi pubblicati | Percorsi verificati che collegano i servizi esposti agli asset critici, e loro chiusura |
| Gestione delle vulnerabilità | Report di scansione periodica | Vulnerabilità prioritizzate per esposizione e sfruttabilità, non per sola gravità tecnica |
| Componenti open source e terze parti | Elenco delle dipendenze software | Comunicazioni dei componenti di terze parti limitate a quelle necessarie |
| Tecnologie obsolete | Piano di dismissione con scadenze | Sistemi legacy isolati e non raggiungibili dai servizi esposti |
| Risposta agli incidenti | Procedura approvata e distribuita | Tempo misurato per isolare un asset durante un test |
| Terze parti e continuità | Contratti e clausole di sicurezza | Dipendenze esterne incluse negli scenari di crisi effettivamente testati |
| Applicazioni di intelligenza artificiale | Policy di governance approvata | Valutazione del rischio eseguita prima della messa in produzione |
Dove interviene la Zero Trust Segmentation
La Zero Trust Segmentation applica il principio del minimo privilegio alle comunicazioni tra workload. La banca può visualizzare le dipendenze applicative, definire policy granulari e isolare sistemi o ambienti senza ridisegnare l’intera rete. Il controllo viene applicato via software sui workload Windows e Linux, in data center, cloud e infrastrutture ibride. Il funzionamento della misura è descritto in dettaglio nell’approfondimento dedicato alla Zero Trust Segmentation.
Separare i servizi esposti dai sistemi interni
Nel perimetro richiamato dalla richiesta di vigilanza, l’approccio consente di separare i servizi esposti a Internet dai sistemi interni e di limitare le comunicazioni dei componenti di terze parti. Sono esattamente le due superfici indicate come critiche.
Contenere il legacy che non può essere aggiornato subito
Le tecnologie obsolete non sempre possono essere dismesse nei tempi richiesti da una scadenza di vigilanza. La segmentazione permette di contenerle, riducendo il numero di sistemi che possono raggiungerle e che esse possono raggiungere, mentre il piano di dismissione procede. In caso di incidente, le policy aiutano a isolare rapidamente il perimetro coinvolto e a preservare l’operatività delle componenti non compromesse.
Cosa la segmentazione non sostituisce
La segmentazione non sostituisce vulnerability management, patching, gestione delle identità, controllo dei fornitori, incident response o business continuity. Aggiunge un livello di contenimento: se la prevenzione fallisce, riduce lo spazio in cui l’attaccante può muoversi e rende visibili le comunicazioni necessarie per valutare il rischio.
Indicatori da portare al tavolo di governance
Per rendere il piano verificabile, la banca può affiancare alle attività alcuni indicatori operativi: percentuale dei workload critici mappati, numero di flussi non necessari rimossi, copertura delle policy di segmentazione, tempo necessario per isolare un asset durante un test e avanzamento delle azioni correttive su sistemi esposti e legacy. Metriche semplici e ripetibili aiutano il management a distinguere il completamento formale delle attività dalla riduzione effettiva del rischio.
Il ruolo del system integrator nel piano di cyber resilience
Tradurre una richiesta di vigilanza in un piano eseguibile significa collegare l’inventario tecnico ai processi critici, stabilire un ordine di priorità difendibile e produrre evidenze lungo il percorso. AD Consulting propone di partire dai workload collegati ai servizi critici e dagli asset inclusi nel piano d’azione: un assessment iniziale ricostruisce flussi, dipendenze e principali percorsi di movimento laterale, un pilota su perimetro limitato verifica le policy in modalità controllata e misura la riduzione delle comunicazioni non necessarie prima dell’estensione.
La componente centrale Illumio può essere erogata attraverso la Private Cloud AD Consulting in Italia, censita nel Catalogo ACN con riferimento IN-3243, oppure installata on-premise. L’esperienza maturata sul mercato finanziario e i servizi di Governance, Risk & Compliance completano il presidio sugli adempimenti.
Il primo passo è verificare quali percorsi collegano oggi i sistemi esposti agli asset critici. Richiedi un assessment o una demo per impostare il piano di cyber resilience della tua banca prima della scadenza.
Contatta AD Consulting.
FAQ: domande frequenti
Che cosa chiede la BCE alle banche entro il 31 ottobre 2026?
Secondo quanto riportato da ANRA, la BCE ha chiesto alle banche significative dell’area euro di presentare entro il 31 ottobre 2026 un piano d’azione dedicato. Il perimetro del piano comprende i sistemi esposti a Internet, i componenti open source, il software di terze parti, la gestione delle vulnerabilità e le tecnologie obsolete. Il piano deve essere accompagnato da responsabilità, scadenze e metriche che ne rendano verificabile l’avanzamento.
Quali banche sono interessate dalla scadenza?
La richiesta riguarda gli istituti sottoposti alla vigilanza diretta della BCE, cioè le banche classificate come significative nell’area euro. Non si applica indistintamente a tutte le banche europee. Gli istituti meno significativi restano soggetti al quadro di vigilanza nazionale, pur potendo usare le stesse aree di attenzione come riferimento di autovalutazione.
Che rapporto c'è tra le priorità di vigilanza BCE e DORA?
DORA, applicabile dal 17 gennaio 2025, è il regolamento europeo che definisce il quadro di resilienza operativa digitale per il settore finanziario. Le priorità di vigilanza BCE 2026-2028 non sostituiscono il regolamento: indicano dove la vigilanza concentrerà verifiche e ispezioni, con particolare attenzione alla capacità effettiva di prevenire, resistere e riprendersi da interruzioni dei servizi critici.
In che modo l'intelligenza artificiale cambia il rischio cyber per le banche?
L’AI agisce su due fronti. Dal lato della banca introduce nuovi sistemi che, se adottati senza una valutazione preventiva adeguata, possono creare vulnerabilità critiche nei sistemi ICT. Dal lato dell’attaccante riduce tempi e costi di ricognizione, individuazione delle vulnerabilità e costruzione degli attacchi, comprimendo la finestra di reazione a disposizione della difesa.
Quali indicatori dimostrano una riduzione effettiva del rischio?
Gli indicatori più utili misurano capacità, non attività svolte: percentuale dei workload critici mappati, numero di flussi non necessari rimossi, copertura delle policy di segmentazione, tempo necessario per isolare un asset durante un test e avanzamento delle azioni correttive su sistemi esposti e legacy. Sono metriche semplici, ripetibili nel tempo e confrontabili tra un ciclo di verifica e il successivo.
Fonti e riferimenti
- ANRA, L’intelligenza artificiale cambia campo, 2026. Fonte della scadenza del 31 ottobre 2026 e del perimetro del piano d’azione richiesto alle banche significative.
- BCE, Priorità di vigilanza 2026-2028. Aree di attenzione su resilienza operativa, capacità ICT, rischio delle terze parti e governance delle applicazioni di intelligenza artificiale.
- Regolamento (UE) 2022/2554 (DORA), applicabile dal 17 gennaio 2025. Quadro europeo sulla resilienza operativa digitale per il settore finanziario.
- Catalogo ACN, AD Consulting Private Cloud, riferimento IN-3243. Censimento del servizio cloud qualificato per l’erogazione della componente centrale.