DORA chiede a ogni entità finanziaria in perimetro un programma di test di resilienza operativa digitale, proporzionato a dimensioni e profilo di rischio: test ordinari periodici su sistemi e strumenti, condotti dall'organizzazione o da suoi incaricati. Ad alcune entità — individuate dalle autorità competenti — viene richiesto in più il TLPT (Threat-Led Penetration Testing, test di penetrazione guidato dalle minacce), un test avanzato su sistemi di produzione con regole di governance stringenti. Per prepararti devi definire l'ambito, conservare le evidenze di ogni test e trasformare gli esiti in lezioni apprese documentate.
Il programma di test di resilienza digitale
Il Regolamento (UE) 2022/2554, DORA (Digital Operational Resilience Act) inserisce i test nel quadro complessivo di gestione del rischio legato alle tecnologie dell'informazione e della comunicazione (ICT): non sono un'attività a sé, ma il modo con cui verifichi che identificazione, protezione, rilevamento, risposta e recupero funzionino davvero. Il programma di test riguarda tutte le entità in perimetro ed è proporzionato: una piccola società di intermediazione non avrà lo stesso programma di una grande banca, ma entrambe devono poter mostrare cosa testano, con che logica e con quali esiti.
Nel programma rientrano attività difensive e verifiche, per esempio:
- Valutazioni di vulnerabilità e configurazione sui sistemi nel proprio perimetro, con cadenza definita dal rischio;
- Test basati su scenari, che verificano la capacità di reggere un evento plausibile (per esempio l'indisponibilità di un fornitore);
- Prove di ripristino di backup e sistemi, in ambiente controllato, con obiettivi di tempo e di integrità misurati;
- Esercitazioni di risposta agli incidenti, che provano ruoli, escalation e comunicazioni.
Ogni test deve lasciare una traccia: obiettivo, ambito, data, esito, problemi emersi e azioni correttive assegnate. Senza questa catena documentale, il test non esiste agli occhi di un ispettore. Ne parliamo nella checklist sulle evidenze DORA per le ispezioni.
Test ordinari e TLPT: le differenze che contano
Il TLPT è la parte di DORA che genera più timore, spesso per confusione. La prima distinzione da fare è che non riguarda tutti: i test avanzati basati sulle minacce sono previsti per le entità individuate dalle autorità competenti secondo criteri definiti dal regolamento e dagli atti delegati. Il Regolamento delegato (UE) 2025/1190 disciplina criteri, responsabilità e governance di questi test, inclusi i requisiti di chi li esegue.
Il confronto, limitato agli aspetti organizzativi:
| Aspetto | Test ordinari | TLPT (test avanzati) |
|---|---|---|
| Chi riguarda | Tutte le entità finanziarie nel perimetro DORA, con programma proporzionato al rischio. | Le entità individuate dalle autorità competenti in base ai criteri del quadro DORA. |
| Chi decide | L'entità, nell'ambito del proprio programma di test approvato. | L'autorità competente individua e valida; l'entità gestisce l'esecuzione con governance dedicata. |
| Dove si esegue | Ambienti di prova o produzione, secondo il tipo di test e la cautela necessaria. | Su sistemi di produzione che supportano funzioni critiche o importanti, con misure di gestione del rischio. |
| Chi esegue | Personale interno o fornitori, con competenze adeguate e indipendenza proporzionata. | Tester che rispettano requisiti specifici di competenza, indipendenza e assicurazione previsti dal regolamento delegato. |
| Evidenze | Verbali, esiti, azioni correttive e loro verifica. | Documentazione di ambito, governance, esecuzione, piano di remediation e attestazioni previste dal quadro. |
Due conseguenze pratiche. Se la tua entità non è stata individuata per i TLPT, il tuo obbligo resta il programma ordinario, fatto bene. Se invece sei individuato, il TLPT non sostituisce i test ordinari: si aggiunge ad essi, con una preparazione organizzativa che richiede mesi, non settimane.
Preparare il primo ciclo: ambito, evidenze, lezioni apprese
Un percorso proporzionato per chi parte da zero:
- Definisci l'ambito dal rischio. Parti dai sistemi che supportano funzioni critiche o importanti, già identificati nella gestione del rischio ICT. Un programma che testa tutto superficialmente vale meno di uno che testa bene ciò che conta.
- Stabilisci obiettivi misurabili per ogni test. Per una prova di ripristino: quale sistema, quale punto di recupero, in quanto tempo. Il collegamento con backup e continuità è trattato nella pagina su backup e ripristino secondo DORA.
- Documenta durante, non dopo. Chi ha approvato il test, chi lo ha eseguito, cosa è successo, quali anomalie sono emerse.
- Chiudi il ciclo. Ogni problema emerso diventa un'azione correttiva con responsabile e scadenza, e la sua efficacia va verificata. DORA parla di lezioni apprese: un esito senza correttivo è un'occasione persa, e in sede ispettiva si nota.
La frequenza dei singoli test va definita in funzione del rischio, dei cambiamenti ai sistemi e degli obblighi applicabili alla tua categoria di entità: non esiste una cadenza unica valida per tutti, e chi la promette sta semplificando troppo.
Esempio illustrativo: il primo programma di una società di pagamenti
Esempio illustrativo. Lo scenario è inventato per mostrare il metodo; non descrive un'organizzazione reale.
Il responsabile della sicurezza di un istituto di pagamento di medie dimensioni — non individuato per i TLPT — costruisce il primo programma annuale di test. L'ambito iniziale copre tre sistemi: la piattaforma di pagamento, l'archivio documentale e la rete della sede. Per la piattaforma pianifica una prova di ripristino in ambiente isolato, con obiettivo di recupero concordato con la direzione; per la rete, una valutazione delle configurazioni; per tutta l'organizzazione, un'esercitazione di risposta a un incidente simulato, con ruoli e escalation provati su un caso di fantasia e nessuna azione sulla produzione.
La prova di ripristino impiega il doppio del tempo previsto: la procedura scritta faceva riferimento a un server dismesso. Il problema viene registrato, la procedura corretta dal suo proprietario e la prova ripetuta con esito positivo. In sede di verifica, il valore non è il test riuscito: è la catena completa — obiettivo, esito negativo, correzione, nuova verifica — conservata e ricostruibile.
Dove si colloca OverZeus
OverZeus per DORA supporta la preparazione e la documentazione, non sostituisce i test. Oracle, in modalità Shadow Mode, osserva il perimetro concordato in sola lettura per un periodo limitato e prepara un report che distingue osservazioni, interpretazioni e proposte: è un modo per vedere lo stato dei sistemi prima di definire il programma, non è un audit né un TLPT e non modifica la produzione. Ares organizza priorità, escalation e gestione dei casi: nelle esercitazioni di risposta aiuta a provare ruoli e passaggi in un ambiente concordato, e in un incidente reale coordina il contenimento solo dopo il piano visibile e l'approvazione prevista — il silenzio non autorizza.
Le attività di test formali, la scelta dei tester, la validazione verso l'autorità e ogni TLPT restano responsabilità dell'entità finanziaria e dei professionisti incaricati. OverZeus produce evidenze tecniche e tracciabilità delle decisioni; non esegue test di penetrazione né invia attestazioni alle autorità.
In sintesi
Se sei in perimetro DORA, hai già l'obbligo di un programma di test proporzionato: parti dall'ambito e dalle evidenze. Il TLPT riguarda solo le entità individuate dalle autorità e segue regole proprie; se ti riguarda, affrontalo come un progetto di governance, non come un test tecnico qualsiasi.
Valuta quali evidenze operative OverZeus può preparare per il tuo percorso DORA.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.