DORA si aspetta che un ente finanziario nel suo perimetro sappia accorgersi per tempo di ciò che non torna: segnali raccolti in modo continuativo dalle fonti concordate, collegati tra loro per distinguere un'anomalia da un incidente, e portati ai responsabili in una forma che permetta di decidere. «Continuo» non significa solo «sempre acceso»: significa che la catena dal segnale alla decisione funziona, è documentata e lascia evidenze consultabili.
Il requisito di rilevamento in DORA
Il Regolamento (UE) 2022/2554, noto come DORA (Digital Operational Resilience Act), si applica dal 17 gennaio 2025 a più di venti tipologie di entità finanziarie: banche, imprese di investimento, gestori, istituti di pagamento e di moneta elettronica, assicurazioni e altri soggetti elencati dall'art. 2. Come ricorda la pagina ufficiale di ESMA, DORA non è un testo unico ma un quadro a livelli: il regolamento di base, gli atti tecnici di esecuzione e delegati e il materiale di vigilanza delle autorità europee.
Il rilevamento si colloca nel cuore della gestione del rischio ICT (tecnologie dell'informazione e della comunicazione): dopo l'identificazione di asset e dipendenze e dopo le misure di protezione, prima della risposta e del recupero. La logica è semplice: non puoi rispondere a ciò che non hai visto. Le misure devono essere proporzionate al profilo di rischio, alle dimensioni e alla complessità dell'ente, ma la proporzionalità non è un alibi: un piccolo istituto di pagamento può avere strumenti più semplici di una banca sistemica, non un rilevamento assente.
C'è poi un collegamento diretto con la gestione degli incidenti. Ciò che il monitoraggio rileva alimenta la classificazione degli eventi e, per gli incidenti gravi, la segnalazione all'autorità competente: in Italia, per i soggetti che indica, Banca d'Italia raccoglie le comunicazioni tramite la piattaforma INFOSTAT, mentre la segnalazione delle minacce informatiche significative resta volontaria. Un monitoraggio che non prepara gli elementi per questo passaggio — orari, sistemi colpiti, azioni intraprese — risponde solo a metà al requisito.
Dalla raccolta eventi alla segnalazione utile
Per capire se il tuo rilevamento regge, conviene scomporlo in tre passaggi e verificarli separatamente. Un problema in uno qualunque dei tre rende fragile tutta la catena.
1. La raccolta dei segnali
Serve un elenco esplicito delle fonti osservate: registri degli accessi, configurazioni di rete, stato dei servizi, esiti dei backup, eventi di sicurezza. Per ogni fonte va annotato chi l'ha autorizzata, cosa contiene e con quale frequenza viene letta. Il punto critico sono i buchi: un sistema critico i cui log non arrivano da nessuna parte è una zona cieca, e va registrata come tale invece di essere dimenticata.
2. La correlazione
Il singolo evento raramente basta. Un accesso insolito, una modifica di configurazione e un picco di traffico possono essere tre coincidenze oppure un solo problema: la correlazione confronta i segnali con la situazione attesa e con le attività pianificate, per separare l'anomalia da spiegare dalla manutenzione legittima. Questo passaggio è anche dove si governano i falsi allarmi: se ogni deviazione diventa un'emergenza, i responsabili smettono di leggere le segnalazioni, e il monitoraggio esiste solo sulla carta.
3. La segnalazione ai responsabili
Un segnale rilevato ma non consegnato a nessuno non è rilevamento. Va definito chi riceve cosa, in che forma e con quale contesto: cosa è stato osservato, da quali fonti, quali spiegazioni sono possibili e quali informazioni mancano. Serve anche una regola per l'escalation fuori orario e per i casi senza risposta: il silenzio del destinatario va trattato come un problema da gestire, non come un'approvazione implicita né come un caso chiuso.
Esempio illustrativo: i lunedì lenti del portale clienti
Esempio illustrativo. Lo scenario seguente mostra un percorso di rilevamento possibile; non racconta un incidente avvenuto presso un cliente.
In un istituto di pagamento di medie dimensioni, per tre lunedì consecutivi il portale clienti risponde più lentamente al mattino e recupera nel pomeriggio. Nessun servizio va giù, nessun allarme tradizionale scatta: ogni metrica, presa da sola, resta entro le soglie. Un agente di monitoraggio come Argus, che osserva eventi, servizi e rete nel perimetro concordato, rileva però uno scostamento dalla situazione attesa: la crescita dei tempi di risposta si accompagna a un aumento dei log di un servizio interno e a connessioni notturne che non c'erano prima.
Artemis, che cerca segnali di compromissione nelle fonti autorizzate, confronta le connessioni con il ruolo noto dei sistemi: una delle destinazioni non è mai stata osservata per quel server. Non è una prova di attacco: potrebbe essere un aggiornamento, un nuovo servizio, un errore di configurazione. Odysseus riunisce i tre segnali in un'unica timeline e propone un piano di verifica, indicando ciò che manca ancora per capire. Hermes porta il caso al responsabile nell'app, con le opzioni: continuare a osservare, verificare con il proprietario del servizio, aprire la gestione dell'incidente. La decisione è della persona; un intervento attivo sui sistemi richiede l'approvazione prevista, e Mnemosyne conserva segnali, proposte, scelta e motivazione.
Il punto dell'esempio è la distinzione dei ruoli: il sistema ha visto, collegato e spiegato; la persona ha deciso. Se alla quarta settimana il responsabile avesse scelto di attendere, anche quella scelta resterebbe tracciata, con le sue ragioni.
Le evidenze del monitoraggio per le verifiche
«Dimostra che il tuo rilevamento è continuo» è una richiesta tipica in sede di verifica. La risposta non è una schermata accesa al momento, ma un insieme di evidenze che coprono un periodo. In pratica conviene poter produrre:
- Perimetro e fonti: l'elenco aggiornato di ciò che è osservato, con le lacune dichiarate e i piani per chiuderle.
- Regole e soglie: i criteri di rilevamento, chi li ha approvati e quando sono stati rivisti l'ultima volta.
- Casi gestiti: per ogni segnalazione rilevante, timeline, fonti, decisione presa, motivazione ed esito — incluse le decisioni di non intervenire.
- Verifiche della catena: prove periodiche che i segnali arrivano davvero ai responsabili, per esempio controllando che un caso di test percorra tutto il percorso previsto.
- Lezioni apprese: le correzioni fatte dopo un caso o un'esercitazione, collegate all'episodio che le ha motivate.
Queste evidenze alimentano direttamente il dossier che serve in caso di ispezione o richiesta della vigilanza e rendono più rapida la ricostruzione necessaria quando un'anomalia diventa un incidente da classificare e, se grave, da notificare.
Il contributo di OverZeus al rilevamento
Nel progetto OverZeus per DORA il rilevamento è affidato ad agenti con ruoli distinti, coerenti con i tre passaggi visti sopra. Argus osserva in modo continuo eventi, servizi, rete e dispositivi collegati ed evidenzia gli scostamenti dalla situazione attesa. Artemis correla i comportamenti sospetti che meritano un'indagine, distinguendo un'anomalia da una compromissione confermata. Odysseus riunisce gli indizi in un piano comprensibile, Hermes consegna la segnalazione ai responsabili — senza interpretare il silenzio come autorizzazione — e Mnemosyne conserva fonti, timeline, autorizzazioni ed esiti.
Due limiti vanno detti con chiarezza. Primo: gli agenti osservano solo le fonti e il perimetro concordati nel progetto; ciò che non è collegato resta invisibile e va gestito dall'organizzazione. Secondo: OverZeus raccoglie e organizza gli elementi tecnici per la gestione dell'incidente, ma classificazione, compilazione dei modelli ufficiali e invio delle segnalazioni alle autorità restano del referente aziendale. Il supporto alle evidenze non equivale a una conformità automatica a DORA: la valutazione finale spetta all'ente.
Domande frequenti sul monitoraggio continuo DORA
Che livello di monitoraggio si aspetta DORA dai soggetti finanziari?
Un livello proporzionato a rischio, dimensioni e complessità, ma effettivo: meccanismi per rilevare tempestivamente le anomalie, collegati alla gestione del rischio ICT e alla gestione degli incidenti. Per un ente piccolo può bastare una copertura essenziale ma completa dei sistemi critici; ciò che non regge è l'assenza di fonti, di responsabili o di traccia delle decisioni.
Come dimostrare che il rilevamento è davvero continuo?
Con evidenze che coprono un periodo, non un istante: elenco delle fonti osservate, regole approvate, casi gestiti con timeline ed esiti, verifiche periodiche della catena di segnalazione e correzioni successive. Un cruscotto acceso durante la verifica dimostra che lo strumento esiste, non che ha funzionato negli ultimi mesi.
Quali segnali devono arrivare ai responsabili e in che forma?
Quelli che richiedono una decisione, in una forma che la renda possibile: cosa è stato osservato, da quali fonti, perché è rilevante, quali spiegazioni sono plausibili e quali informazioni mancano. Il canale deve funzionare anche fuori orario per i casi che non possono attendere, e la mancata risposta deve avere una regola di escalation, non trasformarsi in un'autorizzazione tacita.
Dal segnale alla decisione, con traccia
Il monitoraggio continuo che DORA si aspetta è una catena: fonti conosciute, correlazione che separa il rumore dal segnale, consegna ai responsabili e conservazione delle evidenze. Rafforzare un solo anello lasciando deboli gli altri produce strumenti costosi e verifiche difficili. Meglio partire dalla mappa della propria catena e chiudere prima i vuoti più visibili.
Valuta quali evidenze operative OverZeus può preparare per il tuo percorso DORA.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.