La gestione del rischio TIC secondo DORA richiede alle entità finanziarie comprese nel regolamento un processo governato, documentato e verificato per proteggere la resilienza operativa digitale. Il lavoro non si esaurisce nell’acquisto di strumenti di sicurezza: deve collegare responsabilità dell’organo di gestione, inventario, protezione, rilevazione, risposta, recupero e apprendimento.
Il regolamento UE 2022/2554, DORA, applicabile dal 17 gennaio 2025, definisce ambito e requisiti. Prima di costruire il programma, qualificare l’entità secondo l’articolo 2, verificare esclusioni e proporzionalità e individuare l’autorità competente. Questa guida riguarda il processo di rischio; per i rapporti contrattuali il percorso dedicato ai fornitori TIC e alle strategie di uscita sviluppa un fascicolo distinto ma collegato.
Determinare il regime applicabile senza usare soltanto la dimensione
Documentare categoria dell’entità, servizi svolti, gruppo di appartenenza e caratteristiche rilevanti. La proporzionalità dell’articolo 4 tiene conto di dimensione, profilo complessivo di rischio e natura, portata e complessità di servizi e attività. Non significa scegliere liberamente quali obblighi ignorare.
Il quadro semplificato dell’articolo 16 riguarda le categorie espressamente individuate dalla disposizione. Non è un’esenzione generale per tutte le imprese piccole o per ogni microimpresa. Prima di usare un modello semplificato, registrare il presupposto preciso e le conseguenze sui requisiti applicabili.
Le specificazioni del regolamento delegato UE 2024/1774 completano il quadro di gestione del rischio e quello semplificato. La matrice normativa deve distinguere testo base, atti tecnici e istruzioni dell’autorità pertinente, con versione e data della verifica.
Attribuire responsabilità all’organo di gestione
L’articolo 5 attribuisce all’organo di gestione compiti di definizione, approvazione, supervisione e responsabilità del quadro di rischio TIC. Predisporre una rendicontazione che permetta decisioni su priorità, risorse, dipendenze e rischi residui. Un rapporto esclusivamente tecnico può non rendere comprensibile l’effetto sul servizio finanziario.
Individuare responsabilità operative e funzioni di controllo secondo la struttura e i requisiti applicabili. Chi gestisce una configurazione deve sapere a chi segnalare un difetto che non può correggere. Chi sorveglia deve avere informazioni sufficienti e un percorso per portare questioni rilevanti al livello decisionale.
La formazione dell’organo di gestione deve rendere possibile comprendere e valutare i rischi TIC. Una registrazione di presenza non dimostra da sola la capacità di interpretare una dipendenza critica o una prova di recupero fallita. Collegare gli argomenti ai servizi effettivamente erogati.
Inventariare funzioni, risorse e dipendenze
L’identificazione prevista dall’articolo 8 richiede una visione delle funzioni supportate dalle TIC, delle risorse e delle interdipendenze. La mappatura dei sistemi informativi deve collegare applicazioni, dati, persone, sedi e servizi di terzi. Un elenco di hardware non descrive la resilienza di un processo finanziario.
Per ogni servizio, registrare proprietario, funzione supportata, classificazione, dipendenze e modalità alternative. Individuare i punti in cui una singola credenziale, un collegamento o un fornitore può interrompere più attività. Le relazioni devono essere aggiornate quando entrano nuovi servizi o cambiano quelli esistenti.
La classificazione delle funzioni critiche o importanti richiede una valutazione motivata. Non attribuire automaticamente la stessa importanza a tutti gli strumenti per comodità amministrativa e non escludere un servizio piccolo solo perché il contratto ha valore limitato. Conta l’effetto della sua indisponibilità o compromissione.
Tradurre la protezione in controlli misurabili
Il quadro di protezione e prevenzione deve essere coerente con il rischio e includere le politiche e procedure pertinenti. La politica di sicurezza informatica deve collegarsi a configurazioni, accessi, gestione delle modifiche, aggiornamenti e protezione dei dati. Evitare documenti che descrivono controlli mai attivati.
Per ciascuna misura, indicare il rischio affrontato, il responsabile e la prova di efficacia. Una politica di accesso privilegiato può essere verificata confrontando ruoli autorizzati e account reali. Un controllo delle modifiche può essere verificato attraverso una modifica recente, inclusi approvazione, collaudo e possibilità di ritorno.
L’hardening dei sistemi deve prevedere eccezioni limitate e riesaminate. Un’applicazione incompatibile con una misura non dovrebbe generare una disattivazione permanente senza proprietario, compensazioni e percorso di soluzione.
Preparare rilevazione ed escalation
L’articolo 10 richiede meccanismi di rilevazione delle attività anomale, dei problemi di prestazione e degli incidenti pertinenti. Definire eventi osservati, soglie, responsabilità e tempi di gestione coerenti con il servizio. La raccolta di dati senza un processo di analisi può produrre un archivio esteso senza capacità effettiva di rilevazione.
L’architettura dei log di sicurezza deve permettere correlazione, integrità e accessi controllati. Verificare che gli alert raggiungano una funzione presidiata e che l’assenza del referente non interrompa la gestione. Misurare anche gli eventi non coperti e i limiti delle fonti.
Un indicatore di anomalia non equivale automaticamente a un incidente grave DORA. La classificazione segue criteri propri e deve essere documentata, con aggiornamenti quando emergono nuovi fatti. Il gruppo tecnico e la funzione responsabile delle segnalazioni devono condividere una cronologia coerente.
Collegare risposta, continuità e recupero
Gli articoli 11 e seguenti collegano risposta, recupero, backup e apprendimento. Il piano di continuità operativa deve identificare attività prioritarie e soluzioni alternative; il disaster recovery deve dimostrare come i sistemi tornano utilizzabili.
Definire obiettivi di recupero coerenti con funzioni e dati, sequenze, autorità di attivazione e criteri di riapertura. Un ripristino tecnico non conclude necessariamente l’incidente: possono restare riconciliazioni, comunicazioni ai clienti e verifiche sulla compromissione.
Per le entità cui si applicano, le istruzioni della Banca d’Italia sugli incidenti TIC identificano modalità operative e soggetti interessati. Non trasferire automaticamente il medesimo canale a ogni entità finanziaria soggetta a un’altra autorità. Inserire nel piano riferimenti aggiornati e persone abilitate all’invio.
Costruire un programma di prove proporzionato
DORA disciplina il testing della resilienza operativa digitale con requisiti da applicare al perimetro pertinente. Il programma deve considerare risorse, funzioni, rischi e tipologie di prova. Distinguere controlli ordinari e test avanzati basati sulla minaccia, che non si applicano indistintamente a tutte le entità.
Un audit di sicurezza può verificare architetture, configurazioni o processi; un test di recupero valuta altre capacità. Definire copertura e limiti di ciascun risultato. Una prova riuscita su un’applicazione non certifica automaticamente l’intero quadro di resilienza.
La metodologia EBIOS Risk Manager può contribuire a costruire scenari motivati, se scelta dall’organizzazione. DORA non richiede universalmente quel metodo. L’analisi deve comunque essere coerente con i requisiti applicabili e includere le dipendenze effettive del servizio.
Un esempio ipotetico di fascicolo di rischio
Un’entità finanziaria valuta un servizio di accesso ai documenti dei clienti. Il servizio dipende da un sistema di identità, un archivio e un fornitore di manutenzione. La funzione responsabile rileva che il piano di recupero copre l’archivio ma non la riconfigurazione dell’identità.
| Elemento del fascicolo | Decisione dell’esempio | Prova o azione |
|---|---|---|
| Funzione supportata | Classificazione motivata dall’impatto sul servizio | Verbale del responsabile competente |
| Dipendenza | Identità inclusa nel percorso di recupero | Mappa aggiornata e istruzione tecnica |
| Accesso del fornitore | Riduzione ai compiti necessari | Confronto dei privilegi prima e dopo |
| Recupero | Prova integrata con autenticazione e documenti | Verbale con tempi e operazioni riuscite |
| Rischio residuo | Dipendenza ancora aperta su un servizio esterno | Decisione, compensazione e riesame |
La direzione non riceve soltanto un punteggio. Vede quale funzione può interrompersi, quale prova ha fallito e quale risorsa serve a correggere il problema. Il responsabile del piano aggiorna la situazione quando la prova viene ripetuta, distinguendo decisione, implementazione e verifica.
Tenere collegata la disciplina privacy
DORA non sostituisce il GDPR. Quando il servizio tratta dati personali, servono anche base giuridica, informazione, minimizzazione, conservazione e gestione dei diritti. La guida al coordinamento DORA e GDPR aiuta a condividere le evidenze utili mantenendo separate le valutazioni richieste dai due regimi.
Il rischio per la continuità dell’entità e quello per diritti e libertà delle persone possono sovrapporsi ma non coincidono. Un sistema sempre disponibile può divulgare dati a un destinatario errato; un’interruzione senza divulgazione può comunque danneggiare persone che dipendono dal servizio.
Riesaminare il quadro e seguire le azioni aperte
Il quadro di rischio deve essere documentato e riesaminato secondo i requisiti applicabili, anche in relazione a incidenti rilevanti, risultati dei test e cambiamenti. Per il quadro ordinario, l’articolo 6 prevede il riesame almeno annuale, con la specificità della revisione periodica per le microimprese e gli ulteriori eventi previsti. Verificare sempre il regime effettivamente applicabile all’entità.
Il rapporto di riesame dovrebbe mostrare cambiamenti, carenze, misure completate, risultati e decisioni ancora necessarie. Una tabella di azioni scadute deve arrivare a chi può assegnare risorse o modificare il servizio. Le deroghe interne non devono diventare un archivio di rinvii senza effetto.
L’accountability e la gestione delle prove offrono una disciplina utile anche nell’organizzazione del fascicolo: collegare requisito, decisione e risultato. Conservare versioni e limiti permette di spiegare come il quadro sia stato governato, mentre la verifica delle azioni assicura che continui a funzionare nel servizio reale.
Verificare la qualità degli indicatori presentati
Un indicatore deve avere definizione, fonte e denominatore. «Novanta per cento dei sistemi aggiornati» può essere rassicurante anche quando il dieci per cento residuo contiene tutte le dipendenze della funzione più importante. Presentare quindi copertura per criticità, eccezioni e conseguenze, oltre al totale.
Lo stesso vale per formazione e test: distinguere persone convocate e partecipanti, prove pianificate ed eseguite, rilievi dichiarati chiusi e verificati. Una variazione improvvisa del risultato può dipendere da un cambiamento del perimetro invece che da un miglioramento reale. Il responsabile del rapporto deve renderlo esplicito, così che l’organo di gestione possa confrontare periodi diversi senza interpretare numeri costruiti con criteri incompatibili.