Cinque mesi di DORA in un’entità finanziaria: cosa è servito davvero

Questa case history racconta un programma di readiness DORA svolto per un’entità finanziaria soggetta al Regolamento (UE) 2022/2554, il Digital Operational Resilience Act. È descritta senza dati che permettano di riconoscere il cliente: restano il percorso, le scelte tecniche e ciò che si è dimostrato utile.

Il programma è durato cinque mesi e si è chiuso con 38 gap risolti tra quelli rilevati e con il registro completo dei fornitori ICT critici. Più dei numeri, però, conta come ci si è arrivati.

Prima domanda: DORA o NIS2?

Le banche compaiono anche nell’allegato I della direttiva NIS2, e la domanda arriva sempre: quale delle due norme si applica? La risposta è nell’articolo 4 della NIS2. Quando un atto settoriale dell’Unione impone obblighi di gestione del rischio o di notifica degli incidenti almeno equivalenti a quelli della direttiva, le corrispondenti disposizioni della NIS2 non si applicano a quei soggetti. Per le entità finanziarie quell’atto è DORA.

In pratica significa un solo quadro di riferimento per il rischio ICT e per gli incidenti, non due programmi paralleli. Non significa che la NIS2 sparisca del tutto: continua ad applicarsi ai soggetti che l’atto settoriale non copre, e il perimetro va verificato caso per caso, anche alla luce del recepimento nazionale. Nel programma di cui parlo, il riferimento operativo è stato DORA dall’inizio.

Il punto di partenza: un IT solido, poche evidenze

La funzione IT era solida sul piano operativo. Mancava invece il livello di formalizzazione e di evidenza documentale che DORA richiede: non bastava fare le cose, bisognava poterlo dimostrare in modo strutturato.

Tre aree erano le più critiche: la governance del rischio ICT; un processo di classificazione e segnalazione degli incidenti coerente con le soglie regolamentari; e soprattutto la gestione dei fornitori ICT terzi, con un registro degli accordi e una valutazione dei fornitori critici da costruire quasi da zero. Il vincolo era altrettanto chiaro: non sovraccaricare un team già impegnato nelle attività ordinarie e non produrre documenti scollegati dalla realtà operativa.

La gap analysis sui cinque pilastri

Il primo passo è stata una gap analysis rispetto ai cinque pilastri del Regolamento: gestione del rischio ICT (capo II), gestione, classificazione e segnalazione degli incidenti (capo III), test di resilienza operativa digitale (capo IV), rischio dei fornitori terzi di servizi ICT (capo V) e condivisione delle informazioni (capo VI).

Per ogni requisito le risposte possibili erano tre: c’è già, c’è ma va formalizzato, va costruito. Sembra una distinzione banale, ma decide il costo del programma. Ciò che esiste va reso dimostrabile, non rifatto; ciò che manca va costruito una volta sola, senza duplicare controlli già in uso.

Governance del rischio ICT: ruoli, responsabilità, reporting

DORA attribuisce all’organo di gestione la responsabilità ultima della gestione del rischio ICT (articolo 5). Senza un flusso di informazioni regolare, nessun consiglio può esercitare davvero quella responsabilità.

Il framework messo a terra ha definito ruoli e responsabilità e ha fissato un reporting periodico verso l’organo di gestione. Un framework di governance serve a questo: ogni responsabilità con un titolare riconoscibile e un consiglio che riceve informazioni su cui decidere.

Incidenti: classificare prima di notificare

Sugli incidenti ho definito criteri di classificazione, soglie e flussi coerenti con gli obblighi, integrandoli nei processi di incident management già in uso invece di affiancarne uno nuovo.

Il motivo è pratico. Le norme tecniche di regolamentazione sulla segnalazione degli incidenti (Regolamento delegato (UE) 2025/301) fissano tempi stretti: la notifica iniziale va inviata entro 4 ore dalla classificazione dell’incidente come grave e comunque entro 24 ore da quando l’entità ne è venuta a conoscenza; la relazione intermedia entro 72 ore dalla notifica iniziale; la relazione finale entro un mese dall’ultima relazione intermedia aggiornata. Il primo termine si misura dalla classificazione, con un tetto di 24 ore dalla conoscenza dell’incidente. Se chi gestisce l’incidente non sa applicare i criteri in fretta, i termini diventano irraggiungibili proprio quando servono.

Fornitori ICT: il registro costruito quasi da zero

Era il punto più critico. Il registro delle informazioni previsto dall’articolo 28, paragrafo 3, raccoglie tutti gli accordi contrattuali con i fornitori terzi di servizi ICT, e costruirlo richiede di collegare ogni contratto ai servizi forniti e alle funzioni che quei servizi supportano.

Sul registro si è innestata una metodologia per identificare i fornitori critici per l’entità, a partire dai servizi che supportano funzioni essenziali o importanti (da non confondere con i fornitori terzi critici designati dalle autorità europee di vigilanza ai sensi dell’articolo 31), con la revisione delle clausole contrattuali chiave previste dall’articolo 30 e delle strategie di uscita richieste dall’articolo 28, paragrafo 8.

Nella mia esperienza le strategie di uscita sono la parte che più facilmente resta sulla carta. Scrivere che si può cambiare fornitore è facile; dimostrare come, in quanto tempo e con quale impatto sulle funzioni lo è molto meno.

Test di resilienza proporzionati

Il programma ha impostato un ciclo di test di resilienza operativa proporzionato al profilo dell’istituto. DORA chiede alle entità finanziarie, escluse le microimprese, un programma di test (articolo 24); i test avanzati basati su minacce reali, i TLPT dell’articolo 26, riguardano invece le entità individuate dalle autorità competenti. Partire da ciò che il profilo richiede davvero evita di spendere su test impegnativi lasciando scoperti quelli di base.

Un programma che resta, non un adempimento una tantum

La readiness è stata consegnata come programma trasferibile al team interno: documentazione, registri e processi progettati per essere mantenuti nel tempo. È la differenza tra un progetto che chiude un perimetro e un’entità che può rispondere a una richiesta dell’autorità senza ricominciare da capo.

Cosa porterei in un nuovo programma DORA

Partire dal registro dei fornitori. Nel caso descritto era il punto più critico, e alimenta tutto il resto: senza sapere quali servizi ICT supportano quali funzioni non si identificano i fornitori critici, non si scrivono strategie di uscita credibili e si classifica male un incidente che nasce da un fornitore.

Provare la classificazione degli incidenti prima che serva. Un’esercitazione su un caso concreto mostra subito se i criteri sono applicabili nei tempi richiesti.

Non costruire un secondo sistema. Integrare DORA nei processi che esistono già, dall’incident management alla gestione dei contratti al reporting verso il consiglio, costa meno e regge di più di una struttura parallela che vive solo per la conformità.

In sintesi

Per un’entità finanziaria la scelta tra NIS2 e DORA, sugli obblighi di rischio ICT e di notifica, è già fatta: è DORA. La domanda utile è quanto di ciò che esiste si può rendere dimostrabile e quanto va costruito. In questo caso sono serviti cinque mesi, un registro dei fornitori costruito quasi da zero e un framework progettato per essere mantenuto dal team interno. Il caso completo è nella sezione casi studio.

Le informazioni contenute in questa pagina hanno carattere generale e non costituiscono consulenza legale. L’applicabilità dipende dal caso concreto, dal settore e dalla giurisdizione.