Un software per la gestione di DORA deve fare quattro cose: aiutarti a conoscere sistemi e dipendenze, rilevare ciò che non torna, organizzare le evidenze di incidenti e decisioni, e fornire dati tecnici per il registro dei fornitori di tecnologie dell'informazione e della comunicazione (ICT). Non può invece assumersi la responsabilità della conformità: approvare la strategia sul rischio, classificare gli incidenti, validare il registro e inviare le segnalazioni alle autorità restano atti dell'ente finanziario e del suo organo di amministrazione. Questa guida ti aiuta a distinguere, durante la valutazione, un supporto operativo documentato da una promessa di conformità automatica.
Quali processi DORA devono essere coperti, e da chi
DORA è il Digital Operational Resilience Act, il regolamento UE 2022/2554 sulla resilienza operativa digitale del settore finanziario, applicabile dal 17 gennaio 2025. Secondo la pagina ufficiale ESMA, il quadro riguarda più di venti tipologie di entità finanziarie e si articola in pilastri: gestione del rischio ICT, gestione degli incidenti con notifica di quelli gravi, test di resilienza digitale, gestione del rischio da terze parti ICT e condivisione volontaria delle informazioni sulle minacce. Non è un testo unico: accanto al regolamento esistono atti di esecuzione e delegati (per esempio sui modelli del registro delle informazioni e sui test avanzati) e materiale di vigilanza. Un buon software ti aiuta a muoverti in questo quadro, non lo sostituisce.
Il primo criterio di valutazione è quindi la copertura dei processi, non la quantità di funzioni. Chiedi per ciascun pilastro che cosa lo strumento osserva, quali dati produce e chi li usa. La responsabilità ultima resta dell'organo di amministrazione, che definisce e approva la strategia di resilienza e risponde delle scelte: un tema che approfondiamo nella guida su DORA e l'organo di amministrazione. Nessuno strumento può ereditare questa responsabilità, e chi suggerisce il contrario va trattato con cautela.
Registro fornitori, incidenti ed evidenze: funzioni da dimostrare
Tre aree meritano una verifica puntuale in demo, perché è qui che il confine tra supporto operativo e promessa eccessiva si vede meglio.
Registro delle informazioni e fornitori ICT
Il registro delle informazioni raccoglie i contratti con i fornitori terzi ICT, ai livelli individuale, sub-consolidato e consolidato. Come spiega la pagina EBA sul reporting dei registri DORA, serve a tre scopi: il monitoraggio del rischio terze parti da parte dell'ente, la vigilanza delle autorità competenti e la designazione dei fornitori terzi critici da parte delle autorità europee di vigilanza. Contiene dati contrattuali e identificativi che un inventario tecnico non possiede. Un software può censire sistemi, servizi e dipendenze visibili e segnalare ciò che manca o è cambiato; compilazione, validazione e trasmissione del registro ufficiale restano dell'ente. Per il dettaglio, vedi l'articolo sul registro delle informazioni DORA e quello sulla gestione delle terze parti ICT.
Incidenti ICT: raccolta elementi, non invio
Sugli incidenti la distinzione è netta. Lo strumento può raccogliere orari, eventi, sistemi colpiti e azioni intraprese in una cronologia consultabile. La classificazione dell'incidente, la compilazione dei modelli ufficiali e l'invio della segnalazione restano del referente aziendale. In Italia le entità finanziarie segnalano i gravi incidenti ICT a Banca d'Italia tramite la piattaforma INFOSTAT, mentre la segnalazione delle minacce informatiche significative è volontaria; la pagina di Banca d'Italia sugli incidenti ICT riporta anche la trasmissione annuale delle stime di costi e perdite, in genere entro il 31 maggio (per la segnalazione 2026 la pagina indica un rinvio al 30 giugno, informazione consultata il 5 ottobre 2026). Approfondiamo tempi e passaggi nell'articolo sulla notifica degli incidenti ICT secondo DORA. La frase corretta da cercare in una demo è «prepara gli elementi per la segnalazione»: chi promette invii automatici all'autorità descrive una funzione diversa da quella prevista dai canali ufficiali.
Evidenze consultabili
La terza area è la conservazione delle evidenze: proposte, autorizzazioni, esiti e fonti devono poter essere ricostruiti a distanza di mesi, in vista di controlli e riesami. Anche qui lo strumento conserva e organizza, mentre la valutazione di completezza spetta all'organizzazione; ne parliamo nella guida sulle evidenze DORA per le ispezioni.
Le prove da chiedere
Porta in demo questa griglia e chiedi di vedere ogni funzione su un caso, non su una diapositiva.
| Funzione attesa | Prova da chiedere in demo |
|---|---|
| Inventario e dipendenze | La mappa di sistemi e dipendenze nel perimetro concordato, con le informazioni mancanti evidenziate invece che nascoste. |
| Monitoraggio e rilevamento | Un allarme che spieghi cosa è stato osservato, da quali fonti e perché è rilevante, inclusi i casi di fonte mancante. |
| Supporto al registro | L'export dei dati tecnici raccolti e la distinzione esplicita tra inventario e registro ufficiale, che resta di competenza dell'ente. |
| Incidenti | Una cronologia completa di un caso dimostrativo: orari, sistemi, azioni e decisioni, pronta per essere valutata dal referente. |
| Evidenze e approvazioni | La ricostruzione di chi ha approvato cosa e quando, compresa la registrazione di un rifiuto o di una mancata risposta. |
| Limiti dichiarati | Un elenco scritto di ciò che il software non fa: invii alle autorità, classificazioni ufficiali, decisioni al posto dell'ente. |
Cosa resta responsabilità umana, anche con un buon software
La seconda domanda della valutazione riguarda i confini. Anche con uno strumento ben integrato, restano all'organizzazione almeno queste attività:
- Strategia e tolleranza al rischio. L'organo di amministrazione definisce, approva e riesamina il quadro di gestione del rischio ICT.
- Classificazione degli incidenti. Il materiale tecnico raccolto dagli strumenti alimenta una valutazione che resta dell'ente, secondo i criteri applicabili.
- Segnalazioni alle autorità. Compilazione e invio sui canali ufficiali sono atti dell'ente finanziario, con le scadenze previste dalle istruzioni vigenti.
- Valutazione dei fornitori. Affidabilità, rischio di concentrazione, negoziazione delle clausole e piani di uscita sono decisioni strategiche: il dato tecnico sulle dipendenze è un supporto, non la decisione.
- Test ed esercitazioni. Il programma di test di resilienza e gli eventuali test avanzati richiedono governance e responsabilità dell'ente.
Un software serio rende questi confini visibili nella propria documentazione. Se la demo li nasconde, il problema non è di funzionalità ma di metodo.
Esempio illustrativo: il servizio comparso in rete
Esempio illustrativo. Lo scenario seguente mostra come supporto operativo e responsabilità umana si dividono il lavoro; non racconta un caso avvenuto presso un cliente.
Un istituto finanziario scopre, tramite l'inventario tenuto sotto osservazione, un nuovo servizio esterno che scambia dati con il portale clienti: un fornitore attivato da una direzione interna senza passare dal processo previsto. Il software evidenzia il servizio, le dipendenze che lo riguardano e il fatto che nel registro delle informazioni non compare alcun contratto corrispondente. A quel punto lo strumento si ferma: il referente compliance recupera la documentazione, verifica che mancano identificativo del fornitore e clausole richieste, e avvia il percorso di regolarizzazione. Il software ha trovato lo scostamento e ha conservato le evidenze; la persona ha chiuso l'adempimento. Se lo strumento avesse «aggiornato il registro da solo», l'ente avrebbe un dato non validato al posto di un adempimento verificato.
Come valutare il contributo circoscritto di OverZeus in una demo
OverZeus per DORA è un sistema di agenti AI installato presso l'organizzazione che supporta attività ed evidenze del percorso di resilienza. Non è un gestore completo del registro delle informazioni, non invia nulla alle autorità in autonomia e non certifica la conformità: è un supporto operativo dei sistemi collegati, e va valutato come tale. Sulle funzioni di questo articolo lavorano in particolare quattro agenti:
- Daedalus mappa asset, servizi e dipendenze nel perimetro concordato ed evidenzia dispositivi nuovi e informazioni mancanti: è il dato di supporto per l'inventario e per il confronto con il registro.
- Argus osserva in continuo eventi, servizi, rete e dispositivi collegati, segnalando anomalie e scostamenti dalla situazione attesa.
- Odysseus collega gli indizi provenienti dai moduli e riunisce analisi e proposte in un piano comprensibile, con le informazioni ancora mancanti indicate apertamente.
- Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti, in modo che ogni intervento sia ricostruibile anche a distanza di tempo.
In demo chiedi di vedere il percorso completo di un caso: l'osservazione di Argus, la mappa di Daedalus, il piano di Odysseus e la traccia conservata da Mnemosyne. Verifica che ogni intervento attivo richieda l'approvazione prevista dal responsabile e che il silenzio non autorizzi l'azione. E chiedi per iscritto dove si ferma il sistema: un fornitore che dichiara i propri limiti ti sta dando un criterio di valutazione, non una debolezza.
In sintesi
Il software giusto per la gestione di DORA copre i processi con dati verificabili, dimostra le funzioni su casi concreti e dichiara i propri confini. La conformità resta un percorso dell'ente finanziario: gli strumenti preparano elementi ed evidenze, le persone decidono e rispondono delle scelte. Usa la griglia di questo articolo in ogni demo, OverZeus compreso, e porta nell'offerta solo ciò che hai visto funzionare.
Valuta quali evidenze operative OverZeus può preparare per il tuo percorso DORA.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.