Classificazione e notifica degli incidenti ICT: un caso pratico

La notifica degli incidenti ai sensi di DORA funziona in tre passi: rilevi l'anomalia, valuti con criteri documentati se l'incidente è grave e, se lo è, segnali il caso all'autorità competente con i contenuti e i tempi previsti dalle istruzioni vigenti. A inviare la notifica è sempre l'entità finanziaria, non un fornitore: il software può preparare orari, eventi e autorizzazioni, ma classificazione e invio restano responsabilità dell'organizzazione.

Il quadro: cosa chiede DORA sugli incidenti

DORA, il Digital Operational Resilience Act (Regolamento UE 2022/2554), è applicabile dal 17 gennaio 2025 e riguarda più di venti tipologie di entità finanziarie. Tra i suoi pilastri c'è la gestione degli incidenti ICT, dove ICT indica le tecnologie dell'informazione e della comunicazione: il regolamento prevede un processo per rilevare, gestire e classificare gli incidenti e per segnalare quelli gravi alle autorità competenti, con facoltà di segnalare anche le minacce informatiche significative.

In Italia, per i soggetti vigilati elencati nella propria pagina — banche, imprese di investimento, gestori, istituti di pagamento, istituti di moneta elettronica e altre categorie — Banca d'Italia richiede la comunicazione di tutti i gravi incidenti ICT tramite la piattaforma INFOSTAT; la segnalazione delle minacce significative è volontaria. Per banche, istituti di pagamento, prestatori di servizi di informazione sui conti e istituti di moneta elettronica gli obblighi si estendono anche agli incidenti operativi o relativi alla sicurezza dei pagamenti. Se il tuo ente è vigilato da un'altra autorità, verifica il canale indicato dalla fonte ufficiale di riferimento: le istruzioni nazionali non sono necessariamente identiche.

Gli articoli 17-20 del Regolamento UE 2022/2554 coprono gestione, classificazione e segnalazione degli incidenti, mentre i dettagli operativi — criteri, soglie e modelli — sono definiti dagli atti di esecuzione europei e dalle istruzioni dell'autorità competente. Controlla sempre la versione vigente sulle fonti ufficiali: questo articolo descrive il flusso organizzativo, non sostituisce il testo normativo né una consulenza legale.

Quando un incidente ICT diventa grave

Un incidente ICT è un evento imprevisto, o una serie di eventi collegati, che compromette la sicurezza dei sistemi, dei processi o dei dati. Non tutti gli incidenti vanno notificati: la segnalazione obbligatoria scatta quando l'incidente è classificato come grave. La valutazione si basa su criteri definiti a livello europeo, che il regolamento organizza intorno ad aspetti come:

• il numero di clienti, controparti o utenti colpiti;
• la durata dell'interruzione o del degrado del servizio;
• l'estensione geografica dell'impatto;
• la perdita di disponibilità, autenticità, integrità o riservatezza dei dati;
• la criticità dei servizi interessati per l'attività dell'ente;
• i costi e le perdite economici stimati.

Le soglie e i pesi di questi criteri sono stabiliti dagli atti di esecuzione e dalle istruzioni dell'autorità: prima di applicarli a un caso reale, verifica i modelli e i criteri vigenti presso la tua autorità competente. Il punto organizzativo è un altro: la classificazione deve essere documentata. Anche la conclusione «non grave» va motivata e conservata, perché in una verifica ispettiva può essere chiesto di ricostruire come è stata presa la decisione.

Chi invia la notifica e con quali contenuti

La notifica è un atto dell'entità finanziaria: la invia il referente designato, secondo le deleghe interne, attraverso il canale ufficiale indicato dall'autorità competente. Per i soggetti vigilati da Banca d'Italia il canale è la piattaforma INFOSTAT, con istruzioni operative e modulistica pubblicate sulla pagina dedicata. Il flusso di segnalazione previsto dal quadro europeo si articola in più momenti: una notifica iniziale tempestiva, aggiornamenti intermedi quando evolvono le informazioni disponibili e una relazione finale a chiusura del caso, nei tempi stabiliti dalle istruzioni vigenti. Le istruzioni operative sulle segnalazioni pubblicate dall'EBA sono materiale di supporto dello staff delle autorità europee: utili per capire come operare, non una fonte di nuovi obblighi.

I contenuti tipici riguardano: descrizione dell'incidente e della sua origine accertata o presunta, servizi e processi colpiti, impatto su clienti e dati, misure di contenimento e ripristino adottate o pianificate, tempi stimati di ritorno alla normalità. Esiste poi un adempimento annuale: i soggetti direttamente vigilati trasmettono a Banca d'Italia, di regola entro il 31 maggio, le stime aggregate dei costi e delle perdite causati da gravi incidenti ICT; per la segnalazione dovuta nel 2026 la scadenza indicata dalla pagina ufficiale, consultata il 5 ottobre 2026, è posticipata al 30 giugno.

Esempio illustrativo: il venerdì sera dei pagamenti

Esempio illustrativo. Lo scenario seguente è inventato e serve a mostrare un flusso decisionale possibile; non racconta un incidente avvenuto presso un'organizzazione reale.

Venerdì sera, ore 21:40. In un istituto di pagamento, il servizio di disposizione dei pagamenti online mostra errori crescenti e tempi di risposta anomali, mentre alcune sessioni presentano comportamenti insoliti. Ares, l'agente OverZeus dedicato al centro operativo di sicurezza (SOC, Security Operations Center) e alla risposta agli incidenti, riunisce i segnali disponibili: orari dei primi errori, sistemi coinvolti, indizi sulle sessioni anomale. Apre la gestione del caso e propone un piano di contenimento che indica impatti e responsabilità — per esempio la limitazione di specifiche sessioni tramite gli strumenti collegati — senza eseguire nulla da solo.

Ore 22:05. Hermes, l'app dei responsabili, porta la segnalazione al referente reperibile con il contesto raccolto e il piano proposto. Il responsabile vede le opzioni, le conseguenze operative e autorizza solo le misure elencate. L'assenza di risposta non varrebbe come autorizzazione: senza l'approvazione prevista, il contenimento non parte.

Ore 22:30. Il servizio si stabilizza. Ora la domanda è: l'incidente è grave? Qui gli agenti si fermano e la decisione torna all'organizzazione. Il referente applica i criteri vigenti: clienti potenzialmente colpiti, durata del degrado, servizio critico interessato, possibile compromissione di dati. In parallelo Mnemosyne, l'agente per audit ed evidenze, conserva fonti, timeline, proposte, autorizzazioni ed esiti, così che la ricostruzione del caso non dipenda dalla memoria di chi era in turno.

Il punto del caso è la linea di demarcazione: gli agenti raccolgono, spiegano e preparano; la persona classifica, decide e invia. OverZeus non invia segnalazioni alle autorità per conto dell'ente e non classifica automaticamente gli incidenti ai fini ufficiali.

Preparare in anticipo il flusso decisionale

La pubblicazione SP 800-61 revisione 3 del NIST, l'istituto nazionale statunitense per standard e tecnologia, colloca la risposta agli incidenti dentro la gestione complessiva del rischio: preparazione, rilevamento, risposta e recupero coinvolgono persone, processi e terze parti. Lo stesso vale per DORA. Chi arriva alla notifica improvvisando, sotto pressione e di notte, perde tempo proprio dove il tempo conta. Una preparazione ragionevole comprende:

• Ruoli e deleghe scritti. Chi apre il caso, chi applica i criteri di classificazione, chi approva il contenimento, chi compila e invia la notifica, chi sostituisce chi nei festivi.
• Criteri e modelli pronti. Le soglie e i modelli vigenti dell'autorità competente conservati in un punto noto, con un controllo periodico della versione.
• Accessi al canale ufficiale. Credenziali, profili e procedure della piattaforma di segnalazione verificati prima dell'incidente, non durante.
• Evidenze abituali. Timeline, segnalazioni, approvazioni ed esiti conservati come prassi, così la notifica attinge a dati già raccolti invece di ricostruzioni successive.
• Esercitazioni proporzionate. Simulazioni del flusso decisionale su scenari concordati, in un ambiente che non esegue interventi sulla produzione; la frequenza va definita in base a rischio, cambiamenti e obblighi applicabili, non a una regola universale.

Cosa deve fare davvero un software di supporto DORA

Di fronte a un incidente, un software di supporto DORA è utile se fa tre cose: raccoglie le evidenze mentre accadono, rende visibili decisioni e autorizzazioni con nomi e orari, e prepara gli elementi per la classificazione e la segnalazione. È invece un segnale di attenzione se promette ciò che i canali ufficiali non prevedono: la segnalazione passa per le piattaforme delle autorità ed è un atto dell'entità, quindi diffida di chi dichiara invii automatici o una «classificazione ufficiale automatica». Sul software per la gestione di DORA e sui criteri per valutarlo torniamo in un articolo dedicato; per la risposta operativa può aiutare anche la guida alla scelta di un SOC AI.

Nel progetto OverZeus il contributo documentato per gli incidenti ICT è quello mostrato nell'esempio: Ares organizza priorità, indagini e proposte di contenimento autorizzate; Hermes porta segnalazioni e piani ai responsabili e ne raccoglie le decisioni; Mnemosyne conserva fonti, autorizzazioni ed esiti per la ricostruzione. Le stesse evidenze alimentano i materiali utili in caso di ispezione e si inseriscono nella più ampia gestione del rischio ICT. Classificazione, compilazione dei modelli ufficiali, invio all'autorità e responsabilità complessiva restano all'ente: la pagina dedicata al supporto DORA distingue per ogni scheda cosa produce il sistema e cosa resta in azienda.

Dall'incidente alla decisione

La notifica DORA smette di fare paura quando il flusso è già scritto: criteri di gravità noti, ruoli e deleghe definiti, canale ufficiale pronto, evidenze raccolte mentre gli eventi accadono. L'incidente resta un momento difficile, ma la decisione di notificare diventa un passaggio documentato invece di un'improvvisazione notturna.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus