Il Regolamento DORA (Digital Operational Resilience Act), applicabile dal 17 gennaio 2025 agli enti individuati nell’articolo 2, ha imposto alle stesse un quadro armonizzato e rafforzato di resilienza operativa digitale polarizzato sulla gestione del rischio ICT (ICT risk – based – regulation).
Questa nuova normativa ha ridefinito il processo di gestione degli incidenti ICT, spostando l’approccio da reattivo a proattivo.
In particolare, il DORA uniforma i criteri di classificazione, le tempistiche e i destinatari delle segnalazioni, raggruppando procedure a volte incomplete e frammentate in più fonti normative.
Ecco le fasi chiave del processo di gestione degli incidenti e le relative novità previste dal Regolamento DORA e della norma tecnica di secondo livello in materia, valutando come le nuove disposizioni stiano trasformando la preparazione e la risposta delle aziende coinvolte in eventi critici di sicurezza.
Indice degli argomenti
Identificazione e segnalazione degli incidenti ICT nuovi criteri e soglie
L’articolo 18 del Regolamento DORA dà mandato a BCE, Enisa e AEV al fine di elaborare un progetto di norme tecniche, oggi pubblicate nel Regolamento delegato della Commissione n. 1772 del 2024, il quale prevede sei criteri principali di classificazione e le corrispondenti soglie di rilevanza per valutare la gravità degli incidenti ICT.
Questi elementi sono per l’appunto:
- numero di utenti/controparti impattati e impatto reputazionale dell’evento;
- durata dell’incidente e del periodo di inattività del servizio;
- estensione geografica dell’incidente (per esempio, coinvolgimento di più Stati membri);
- perdite di dati (integrità, riservatezza o disponibilità compromesse);
- criticità dei servizi colpiti ovvero quanto le funzioni aziendali essenziali sono state interessate;
- impatto economico dell’incidente, in termini assoluti e relativi.
Un primo elemento che merita di essere osservato è per l’appunto la scelta del legislatore di seguire la strada adottata già da EBA all’interno degli “Orientamenti in materia di segnalazione dei gravi incidenti ai sensi della PSD2”, oggi abrogati, e quindi adottare per ciascun criterio dei valori soglia quantitativi precisi.
Superati i limiti imposti dal valore soglia (ad esempio il numero di clienti colpiti, l’ammontare di perdite, il numero di paesi coinvolti eccetera), l’incidente ICT è da considerarsi major o “significativo” e per questo motivo dovrà essere segnalato immediatamente all’autorità di vigilanza, nonché ai clienti ed eventualmente alle controparti.
I valori soglia tengono conto delle dimensioni e del profilo di rischio complessivo di ciascuna entità finanziaria, garantendo criteri uniformi, guidati sempre dal principio di proporzionalità.
Questo aspetto è di fondamentale importanza considerata l’ampia schiera di soggetti ai quali sono applicabili le disposizioni.
Comunicazione verso Autorità e stakeholder
Altro adempimento uniformato è il tema della comunicazione sia nei confronti delle Autorità di vigilanza, sia nei confronti dei clienti e delle controparti.
In caso di incidente ICT classificato come major, infatti, l’organizzazione dovrà notificare senza indugio l’evento all’autorità competente, seguendo tempistiche stringenti e organizzate su più livelli. In Italia, la Banca d’Italia per il settore bancario, l’Ivass per il settore assicurativo, la Consob gli attori rientranti nel perimetro dei mercati finanziari e la Covip per il mercato della previdenza complementare.
Oltre all’incidente Ict major, alle entità finanziarie viene data la possibilità, senza un obbligo specifico previsto, di segnalare volontariamente minacce informatiche rilevanti (per le quali vi sono distinti criteri di classificazione e soglie di rilevanza).
Pertanto, le notifiche da effettuare nei confronti dell’AEV competente sono:
- notifica iniziale: entro 4 ore dalla classificazione dell’incidente ICT come major, e comunque entro 24 ore dal momento in cui l’entità finanziaria è venuta a conoscenza dell’incidente ICT;
- relazione intermedia: entro 72 ore dalla trasmissione della notifica iniziale, anche se lo stato o il trattamento dell’incidente non sono cambiati, e in ogni caso quando sono state riprese le regolari attività;
- relazione finale: entro un mese dalla trasmissione della relazione intermedia o, se del caso, dall’ultima relazione intermedia aggiornata.
Inoltre, gli enti sono tenuti a predisporre piani di comunicazione chiari ed esaustivi, sia verso stakeholder interni che esterni. I piani devono prevedere avvisi tempestivi al top management, alle funzioni di controllo interne e, quando rilevante, anche ai clienti o ai partner commerciali colpiti.
Analisi e contenimento degli incidenti ICT: le cause che li hanno provocati
Successivamente alle fasi di identificazione e segnalazione, nonché di gestione e risoluzione, un processo strutturato per la gestione degli incidenti ICT dovrà prevedere la cosiddetta root cause analysis.
Il Regolamento DORA richiede infatti che, dopo la gestione immediata dell’incidente, l’ente indaghi a fondo sulle cause dell’evento e ne registri i risultati in apposita documentazione.
Questo aspetto è strettamente collegato alla fase di segnalazione, l’analisi delle cause di fondo diventa parte integrante dell’obbligo di reporting, infatti con la notifica finale l’impresa precisa all’Autorità competente le cause reali dell’incidente.
Ciò comporta che, internamente si tratta di condurre verifiche tecniche approfondite (come per esempio: attività di digital forensic, collaudi sui sistemi colpiti, analisi sui registri di log eccetera) e di valutare anche eventuali debolezze organizzative o di processo che hanno favorito l’incidente.
Lo scopo è chiaro: comprendere con precisione il perché dell’evento per evitare che si ripeta.
Poi si formalizza il risultato dell’analisi come report interno. L’insight principale viene condivisa con gli organi di governance, in particolare con la funzione di gestione del rischio Ict, al fine di integrare le misure correttive nelle politiche e procedure adottate.
Monitraggio e follow up: l’apprendimento dall’incidente ICT
DORA incoraggia un ciclo di miglioramento continuo, attraverso la traduzione delle lezioni apprese da ogni evento in meccanismi e pratiche che rafforzino la resilienza futura dell’ente.
In sintesi, l’analisi post-incidente implica non solo la mera rilettura tecnica dell’evento, ma l’effettiva implementazione di azioni correttive e il rafforzamento delle misure difensive, alimentando in questo modo il processo di apprendimento che rende l’organizzazione più resiliente.
In conclusione, a due anni dall’entrata in vigore di DORA, la gestione degli incidenti ICT nelle realtà finanziarie europee è mutata profondamente.
I processi sono ora più strutturati e integrati con la continuità operativa, grazie a criteri unificati di classificazione e a scadenze comuni di disclosure.
L’attenzione non è più solo sul contenimento e reporting, ma sull’intero ciclo PDCA (Plan-Do-Check-Act): dalla prevenzione e identificazione, al reporting e lezioni apprese, tutto si riallaccia a una visione proattiva ed olistica di resilienza digitale.
I professionisti ICT (e non solo) devono oggi presidiare ogni fase di questo processo – dall’investimento in strumenti di rilevamento avanzati alla definizione di politiche di risposta – per garantire che, di fronte a ogni nuova minaccia, l’organizzazione sia pronta a proteggere i propri asset essenziali e a riprendersi più rapidamente possibile.
