Test di resilienza DORA oltre il TLPT — il programma degli articoli 24 e 25

Il capo IV del regolamento (UE) 2022/2554 organizza i test su due livelli.

• Il programma di test (artt. 24 e 25) si applica alle entità finanziarie diverse dalle microimprese. Anche le microimprese testano, ma ai sensi dell'art. 25(3) combinano un approccio basato sul rischio con una pianificazione strategica, bilanciando le risorse impiegate con l'urgenza e il tipo di rischio.
• Il threat-led penetration testing (artt. 26 e 27) si applica solo alle entità finanziarie individuate dalle autorità competenti in base a impatto, rilevanza sistemica e profilo di rischio ICT. Sono escluse le microimprese e le entità soggette al quadro semplificato dell'art. 16(1). Le entità designate svolgono un TLPT almeno ogni tre anni.

La maggior parte di banche, assicurazioni, imprese di investimento, istituti di pagamento e di moneta elettronica non riceverà mai una notifica TLPT. Nessuna però è esentata dal primo livello, ed è lì che le autorità verificano se i test sono regolari, coprono le funzioni essenziali o importanti e portano davvero a correzioni. Per il secondo livello vedi il TLPT ex art. 26 DORA e il playbook sull'ingaggio TLPT.

L'articolo 24 definisce la cornice. Il programma deve essere:

1. Solido e completo, parte integrante del quadro di gestione dei rischi ICT dell'art. 6, per valutare la preparazione agli incidenti ICT, individuare debolezze, carenze e lacune e attuare rapidamente misure correttive (art. 24(1)).
2. Un insieme di valutazioni, test, metodologie, pratiche e strumenti, applicati secondo gli artt. 25 e 26 (art. 24(2)).
3. Basato sul rischio, considerando l'evoluzione dei rischi ICT, i rischi specifici dell'entità e la criticità degli asset informativi e dei servizi (art. 24(3)).
4. Eseguito da soggetti indipendenti, interni o esterni. I tester interni richiedono risorse sufficienti e l'assenza di conflitti di interesse in fase di progettazione ed esecuzione (art. 24(4)).
5. Legato alla correzione: procedure e politiche per classificare, prioritizzare e risolvere tutti i problemi emersi, e metodologie interne di convalida che accertino che ogni debolezza sia stata pienamente risolta (art. 24(5)).
6. Annuale su ciò che conta: almeno una volta l'anno, test adeguati su tutti i sistemi e le applicazioni ICT a supporto di funzioni essenziali o importanti (art. 24(6)).

L'articolo 25(1) elenca i test previsti dal programma, secondo i criteri di proporzionalità dell'art. 4(2): valutazioni e scansioni delle vulnerabilità, analisi open source, valutazioni della sicurezza delle reti, analisi delle lacune, esami della sicurezza fisica, questionari e soluzioni software di scansione, revisioni del codice sorgente ove possibile, test basati su scenari, test di compatibilità, test di prestazione, test end-to-end e penetration test. L'articolo 25(2) aggiunge un solo evento esplicito: depositari centrali di titoli e controparti centrali effettuano valutazioni delle vulnerabilità prima di ogni installazione o reinstallazione di applicazioni, componenti infrastrutturali e servizi ICT nuovi o esistenti a supporto di funzioni essenziali o importanti.

Il regolamento delegato (UE) 2024/1774, l'RTS sul quadro di gestione dei rischi ICT, aggiunge dettagli operativi che alimentano il programma di test.

• Scansione settimanale (art. 10(2)): le procedure di gestione delle vulnerabilità devono garantire scansioni e valutazioni automatiche delle vulnerabilità sugli asset ICT, con frequenza e perimetro commisurati alla classificazione e al profilo di rischio, e almeno settimanali per gli asset ICT a supporto di funzioni essenziali o importanti. Lo stesso articolo chiede di tracciare le librerie di terze parti e open source, di prioritizzare le patch in base a criticità e rischio dell'asset, di monitorare e verificare la correzione e di registrare ogni vulnerabilità rilevata fino alla sua risoluzione.
• Test del codice e dei pacchetti (art. 16): la procedura di acquisizione, sviluppo e manutenzione comprende revisioni del codice sorgente con test statici e dinamici, test di sicurezza dei sistemi e delle applicazioni esposti su internet, test di sicurezza dei pacchetti software al più tardi in fase di integrazione e, ove possibile, analisi e test del codice di terze parti e open source prima della produzione.
• Quadro semplificato (art. 36): le entità dell'art. 16(1) DORA adottano un piano di test di sicurezza ICT che convalida l'efficacia delle misure e le aggiornano senza indebito ritardo dopo i test sui sistemi a supporto di funzioni essenziali o importanti.

La scansione settimanale è la frequenza più concreta di tutto l'impianto di test DORA, e si trova nell'RTS sul rischio ICT, non negli articoli 24 e 25. Chi pianifica solo attorno al test annuale spesso la trascura.

Letto alla lettera, l'articolo 25(1) indica il penetration test come uno dei test previsti dal programma, in un elenco introdotto da «quali», e l'articolo 24(6) chiede «test adeguati» almeno annuali sui sistemi essenziali o importanti. Il regolamento non dice che ogni sistema debba essere sottoposto a penetration test ogni anno.

Nella pratica lo spazio per ometterlo è ridotto. Lo scopo dichiarato del programma è individuare debolezze e lacune (art. 24(1)). Una scansione di vulnerabilità dice cosa manca, non se un attaccante può sfruttarlo per arrivare a una funzione essenziale. Per un servizio esposto su internet, un gateway di accesso remoto o l'infrastruttura di identità dietro una funzione essenziale è difficile sostenere che le sole scansioni siano il test adeguato. La posizione difendibile è mettere per iscritto, per ogni funzione essenziale o importante, quali tipi di test applichi e perché, includendo il penetration test ovunque la domanda sia la sfruttabilità. Se per un sistema scegli un test più leggero, registra la motivazione: il programma è basato sul rischio e una scelta motivata è ciò che il testo chiede.

Un programma che regge alla vigilanza di solito prevede:

• Una mappa dalle funzioni essenziali o importanti ai sistemi e alle applicazioni ICT, compresi quelli affidati a fornitori terzi di servizi ICT. L'art. 24(6) si misura su questo elenco: ogni sistema che vi compare richiede almeno un test adeguato l'anno.
• Una matrice dei test per sistema: scansione automatica settimanale (art. 10 dell'RTS), vulnerability assessment e valutazione della sicurezza di rete, penetration test dall'esterno e dall'interno con i privilegi di un utente standard, revisione del codice sviluppato internamente o personalizzato ove possibile, test basati su scenari ed end-to-end sulle funzioni stesse.
• L'indipendenza documentata: chi ha testato, se interno o esterno, come sono stati evitati i conflitti di interesse e quali risorse sono state dedicate (art. 24(4)).
• Un registro dei finding: classificazione, priorità, responsabile, data obiettivo, correzione e una fase di convalida che conferma la correzione (art. 24(5)). Un finding si chiude quando il retest è superato, non quando si chiude il ticket.
• Eventi fuori calendario: modifiche rilevanti, nuovi servizi esposti su internet e, per depositari centrali e controparti centrali, ogni installazione o reinstallazione su funzioni essenziali (art. 25(2)).

Tieni esplicita nella matrice la distinzione tra black box e gray box; vedi black box e gray box. È il test dall'interno a mostrare se la segmentazione attorno a una funzione essenziale regge quando una postazione è compromessa.

Il regolamento delegato (UE) 2025/1190 del 13 febbraio 2025, pubblicato il 18 giugno 2025, è l'RTS sul TLPT. Fissa i criteri usati dalle autorità e un elenco di entità a cui il TLPT viene richiesto salvo che la valutazione non lo giustifichi: enti creditizi G-SII o O-SII o appartenenti a questi gruppi, istituti di pagamento e di moneta elettronica oltre 150 miliardi di euro di operazioni di pagamento in ciascuno dei due anni precedenti (o, per gli istituti di moneta elettronica, 40 miliardi di moneta elettronica in circolazione), depositari centrali di titoli, controparti centrali, sedi di negoziazione con la quota di mercato nazionale più alta o una quota UE rilevante, e alcune imprese di assicurazione e riassicurazione (art. 2).

Le caratteristiche che distinguono il TLPT da qualsiasi test interno:

• Sistemi di produzione a supporto di più o tutte le funzioni essenziali o importanti, con un perimetro convalidato dall'autorità (art. 26(2) DORA).
• Scenari guidati dalla threat intelligence di un fornitore che deve essere esterno all'entità finanziaria, anche quando si usano tester interni (art. 27(2), lettera c), DORA).
• Tester: esterni conformi all'art. 27(1), oppure interni solo con l'approvazione dell'autorità, risorse sufficienti e senza conflitti di interesse; chi usa tester interni deve ingaggiare tester esterni ogni tre test, e gli enti creditizi significativi vigilati nell'SSM devono usare solo tester esterni (artt. 26(8) e 27(2) DORA). Secondo i considerando dell'RTS, un team misto di tester interni ed esterni conta come test con tester interni.
• Una fase attiva di red team di almeno 12 settimane, seguita entro 10 settimane da replay ed esercizio di purple teaming con il blue team (artt. 11(5) e 12(5) dell'RTS).
• Un'attestazione dell'autorità dopo la sintesi dei risultati e i piani di correzione (art. 26(6) e (7) DORA).

Nessuno strumento, per quanto autonomo, trasforma un test interno in un TLPT. Ciò che il test interno può fare è far sì che il TLPT venga speso sulle domande giuste.

Dodici settimane di red teaming guidato dalla minaccia costano. Se il team esterno entra da un dispositivo perimetrale non aggiornato o da una credenziale di default che una scansione settimanale avrebbe trovato, il test dimostra qualcosa che avresti già dovuto sapere, e alle domande su rilevamento e risposta per cui il TLPT è pensato resta meno tempo.

I test interni continui nei mesi che precedono un TLPT colmano questo divario:

• Elimina prima i percorsi già noti come sfruttabili. Verifica quali finding sono davvero sfruttabili sui sistemi che saranno nel perimetro TLPT, correggili e ritesta.
• Testa l'interno, non solo il perimetro. Gli scenari TLPT di solito presuppongono un punto d'appoggio iniziale: le campagne gray box da un account utente standard mostrano fin dove arriva oggi il movimento laterale.
• Prova le evidenze. I piani di correzione e le sintesi dei finding richiesti alla chiusura del TLPT si producono più facilmente se l'organizzazione gestisce già un registro dei finding con convalida ai sensi dell'art. 24(5).
• Metti alla prova il blue team. Sapere che i test interni girano a calendario non equivale a sapere se il SOC li rileva: confronta ciò che è stato testato con ciò che ha generato allarmi.

Lo stesso lavoro copre il test annuale dell'art. 24(6) per le entità che non vengono mai designate: non è sprecato se la notifica TLPT non arriva.

Un red team AI autonomo per reti e infrastrutture non è un fornitore TLPT, non fornisce threat intelligence e non rende il tuo team interno indipendente nel senso dell'art. 24(4): risorse e presidi sui conflitti di interesse restano da documentare a cura tua. Ti permette però di eseguire e documentare buona parte del programma degli artt. 24 e 25 tra un ingaggio esterno e l'altro.

• Campagne a calendario e dopo ogni modifica in modalità black box dall'esterno e gray box con i privilegi di un utente standard, sui sistemi a supporto di funzioni essenziali o importanti.
• Finding dimostrati sfruttabili, il dato che serve alla prioritizzazione dell'art. 24(5), e retest su richiesta come fase di convalida che chiude ogni finding.
• Mappatura sui framework dei risultati verso i controlli DORA (artt. da 24 a 27) e TIBER-EU, tra i 34 framework supportati dal motore, con report di conformità esportabili.
• Approvazione umana dei passi rischiosi: cinque livelli di autonomia stabiliscono cosa deve attendere un operatore, e i proof of concept di exploit possono restare in attesa di revisione. Sui sistemi di produzione che sostengono funzioni essenziali è il presidio che impedisce al test di diventare l'incidente; vedi human in the loop.
• Integrità delle evidenze: ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256 per campagna, verificabile offline, e report e bundle sono firmati.
• Nessun dato del cliente lascia l'appliance: i modelli girano sull'appliance senza servizi AI esterni, quindi i finding sui tuoi sistemi critici non arrivano a un fornitore AI esterno. Vedi red team AI on-premise.

• Regolamento (UE) 2022/2554 (DORA), artt. 16 e da 24 a 27 (EUR-Lex)
• Regolamento delegato (UE) 2024/1774, RTS sul quadro di gestione dei rischi ICT, artt. 10, 16 e 36 (EUR-Lex)
• Regolamento delegato (UE) 2025/1190, RTS sul threat-led penetration testing (EUR-Lex)