Playbook per un ingaggio TLPT DORA — dalla notifica dell’autorità all’attestazione

Usa questo playbook quando sono vere entrambe le condizioni:

• La tua entità rientra nello scope di DORA — Regolamento (UE) 2022/2554 ed è stata individuata dall’autorità competente come tenuta a svolgere threat-led penetration testing ex art. 26. La designazione non discende automaticamente dalla dimensione: l’autorità applica i criteri qualitativi e quantitativi del Regolamento Delegato (UE) 2025/1190, tenendo conto dell’impatto dell’entità sul settore finanziario, del suo profilo di rischio ICT e della sua rilevanza sistemica.
• Hai ricevuto la notifica formale dall’autorità TLPT che un TLPT dovrà essere svolto. Quella notifica è il tempo zero di ogni scadenza qui sotto.

La stessa sequenza vale per i test volontari condotti sotto un framework nazionale — in Italia TIBER-IT è lo strumento metodologico unico sia per i test DORA obbligatori sia per quelli volontari — ma solo le entità designate ricevono un’attestazione rilasciata dall’autorità.

Fuori dallo scope di questo playbook: il programma ordinario di test di resilienza operativa digitale ex artt. 24 e 25 DORA (vulnerability assessment, network security assessment, code review, test scenario-based, penetration test ordinari), che gira in continuo ed è ispezionato separatamente; gli obblighi di segnalazione su un incidente in corso (vedi il playbook incidenti ICT gravi DORA); e gli obblighi di test di vigilanza nazionali antecedenti a DORA, che continuano in parallelo invece di essere assorbiti dal TLPT.

Due ancore governano tutto: T0, la notifica dell’autorità, ed E0, la fine concordata della fase di red teaming attivo. Ogni scadenza qui sotto è vincolante ai sensi dell’RTS 2025/1190.

Fase di preparazione

• T0 + 3 mesi — documenti di avvio del TLPT ai test manager (art. 8(1)): project charter con piano di alto livello, contatti del control team lead, intenzione dichiarata di usare tester interni o esterni o entrambi, canali di comunicazione, code name del TLPT.
• T0 + 6 mesi — scope specification document (art. 8(5)), approvato dall’organo di gestione dell’entità, non dal solo CISO.
• Prima che la fase di test possa iniziare: tester e provider di threat intelligence contrattualizzati (art. 8(8)), risk assessment del TLPT consultato con i test manager (art. 8(9)), evidenza di conformità dei provider depositata (art. 8(10)).

Fase di test

• Targeted threat intelligence report prodotto e approvato dall’autorità (artt. 9(5)-(6)). Nel final report delle Autorità Europee di Vigilanza sull’RTS questa fase è descritta come della durata tipica di circa quattro settimane.
• Red team test plan approvato dal control team e dall’autorità TLPT (art. 10(3)).
• Fase di red teaming attivo: almeno 12 settimane (art. 10(5)). Gli scenari possono essere eseguiti in sequenza o in parallelo. La data di fine è concordata congiuntamente da control team, provider di threat intelligence, tester e test manager: quell’accordo è E0.

Fase di closure

• E0 + 4 settimane — red team test report al control team (art. 11(2)).
• E0 + 10 settimane — blue team test report al control team (art. 11(4)), e replay delle azioni offensive e difensive con l’esercizio di purple teaming (art. 11(5)).
• N0 — l’autorità notifica al control team lead di aver valutato che entrambi i report contengono i contenuti richiesti.
• N0 + 8 settimane — il report di sintesi dei finding rilevanti, l’artefatto che l’art. 26(6) DORA richiede davvero (art. 11(7)).
• N0 + 8 settimane — il piano di remediation (art. 12(1)).
• Attestazione rilasciata dall’autorità TLPT ex art. 26(7) DORA, che conferma lo svolgimento del test conforme ai requisiti.

Fai la somma onestamente prima di impegnare una data col consiglio: sei mesi di preparazione, circa un mese di threat intelligence, un minimo di tre mesi di test attivo, quattro-cinque mesi di closure. Dodici-diciotto mesi è la finestra realistica, e la cadenza TLPT è almeno triennale: la pianificazione dell’ingaggio successivo inizia prima che l’attestazione precedente sia invecchiata.

È la fase che i team sottostimano, ed è dove sta la prima scadenza mancabile.

Costituisci il control team. Il control team supporta il control team lead e possiede, ex art. 8(3): i canali di comunicazione con tester e provider di threat intelligence, l’informativa all’organo di gestione su avanzamento e rischi, le decisioni di merito lungo tutto il test, la conformità dell’esecuzione all’RTS, la selezione del provider di threat intelligence, la selezione dei tester e la preparazione dello scope specification document. L’autorità valida la composizione e ogni sua modifica successiva.

Definisci lo scope sulle funzioni critiche o importanti. L’art. 8(6) fissa i criteri da considerare per l’inclusione: criticità della funzione e possibile impatto sul settore finanziario e sulla stabilità finanziaria a livello nazionale e unionale, importanza per l’operatività quotidiana, sostituibilità, interconnessione con altre funzioni, collocazione geografica, dipendenza settoriale di altre entità dalla funzione e, ove disponibile, la threat intelligence che la riguarda. Documenta il ragionamento per ogni funzione inclusa e per ogni esclusione: le esclusioni sono ciò che i supervisori leggono per primo.

Fai procurement contro le soglie RTS, non contro un listino. L’art. 5(2) fissa requisiti minimi che un’offerta al ribasso non supera:

• Provider di threat intelligence: almeno tre referenze da incarichi precedenti; staff composto almeno da un manager con 5+ anni di threat intelligence e un ulteriore membro con 2+ anni; partecipazione combinata ad almeno tre incarichi precedenti di threat intelligence in contesto di testing; nessuna attività blue team simultanea per l’entità; separazione organizzativa dallo staff red team dello stesso provider.
• Tester esterni: almeno cinque referenze; un manager con 5+ anni di penetration e red team testing più almeno due tester con 2+ anni ciascuno; partecipazione combinata ad almeno cinque incarichi precedenti; non impiegati presso, né fornitori di, un provider che svolge attività blue team per l’entità.
• Entrambi: certificazioni adeguate agli standard di mercato riconosciuti e polizza di responsabilità professionale che copra dolo e negligenza.

Se l’autorità valuta che il provider selezionato non garantisce conformità, non puoi contrattualizzarlo (art. 8(10)). Prepara una seconda scelta prima di averne bisogno.

Checklist di preparazione

• Notifica dell’autorità protocollata con la sua data, e date T0 + 3 e T0 + 6 inserite nel piano di programma.
• Control team nominato, lead individuato, validazione dell’autorità ricevuta.
• Code name assegnato; accordi di segretezza documentati per il personale dell’entità, dei fornitori ICT terzi, dei tester e del provider di threat intelligence.
• Scope specification document redatto, mappato sull’Allegato II, portato all’organo di gestione con delibera a verbale.
• Risk assessment del TLPT prodotto, che copra il test sui sistemi di produzione live e il potenziale impatto sul settore finanziario e sulla stabilità finanziaria, e consultato con i test manager.
• Pacchetto di evidenze di conformità dei provider (referenze, certificazioni, assicurazione, CV mappati sulle soglie dell’art. 5(2)) depositato prima della contrattualizzazione.
• Policy sui tester interni in vigore se si usano tester interni: un test lead più almeno due membri, tutti impiegati dall’entità o da un fornitore ICT infragruppo nei 12 mesi precedenti.

La threat intelligence viene prima e guida gli scenari, non il contrario. Il provider analizza intelligence generica e settoriale, individua minacce e vulnerabilità esistenti o potenziali riguardanti l’entità e raccoglie target e threat intelligence concreta, azionabile e contestualizzata (art. 9(1)). Propone quindi scenari che differiscono per attore di minaccia e per TTP associate e che colpiscono ciascuna funzione critica o importante in scope (art. 9(2)).

La regola di selezione è precisa. Il control team lead seleziona almeno tre scenari (art. 9(3)) pesando la raccomandazione del provider e la natura threat-led di ciascuno, l’input dei test manager, il giudizio di fattibilità dei tester e dimensione, complessità e profilo di rischio dell’entità. Non più di uno degli scenari selezionati può essere non threat-led, cioè basato su una minaccia prospettica e potenzialmente fittizia con valore predittivo rispetto all’evoluzione attesa del panorama di minaccia (art. 9(4)). Tre avversari reali e al massimo un’ipotesi: un test costruito su quattro ipotesi non è un TLPT.

Il red team test plan è un documento controllato. Costruito a partire dallo scope specification document e dal targeted threat intelligence report, va consultato con control team, provider di threat intelligence e test manager, coprendo gli assetti di comunicazione, procedurali e di project management, la preparazione e i casi d’uso per l’attivazione dei leg-up e gli accordi di reporting (art. 10(2)). Viene poi approvato dal control team e dall’autorità TLPT. Dopo l’approvazione, ogni modifica a timeline, scope, sistemi bersaglio o flag richiede il via libera del control team lead e dei test manager (art. 10(6)).

Gestire la finestra

• Minimo 12 settimane di red teaming attivo, proporzionate allo scope e al numero di entità e fornitori coinvolti.
• I tester riportano almeno settimanalmente a control team e test manager; il provider di threat intelligence resta disponibile per intelligence aggiuntiva su richiesta (art. 10(7)).
• I leg-up — assistenza o informazioni fornite dal control team per sbloccare uno scenario, tipicamente informativi o di accesso — sono progettati in anticipo nel test plan e forniti tempestivamente (art. 10(8)). Leg-up improvvisati e negoziati durante il test sono un rilievo di governance, non una cortesia.
• Se personale dell’entità o dei fornitori rileva le attività di test, il control team propone misure per proseguire preservando la segretezza, da validare a cura dei test manager (art. 10(9)).
• In circostanze eccezionali con rischio di impatto sui dati, danno agli asset o disservizio a funzioni critiche, controparti o settore, il control team lead può sospendere il test o, come ultima risorsa e previa validazione dell’autorità, proseguirlo come esercizio di purple teaming limitato. Quel tempo conta comunque ai fini del minimo di 12 settimane (art. 10(10)).

Checklist della finestra di test: targeted threat intelligence report mappato sull’Allegato III e approvato dall’autorità; almeno tre scenari selezionati con la motivazione a verbale; red team test plan mappato sull’Allegato IV e approvato; catalogo dei leg-up con criteri di attivazione e scadenze; report settimanali conservati; ogni richiesta di modifica al piano registrata con approvatore e timestamp; eventi di detection loggati con la misura di prosecuzione e la relativa validazione.

La closure è dove l’ingaggio viene valutato, e le sue scadenze corrono in parallelo più che in serie: pianifica il calendario a ritroso da E0.

Subito dopo E0: il control team lead informa il blue team che un TLPT ha avuto luogo (art. 11(1)). Fino a quel momento il blue team ha risposto a quella che credeva un’intrusione reale; il debrief che gli devi è operativo, non cerimoniale.

E0 + 4 settimane — red team test report (art. 11(2), contenuti dell’Allegato V), fornito senza indebito ritardo a blue team e test manager. Su richiesta dei test manager viene prodotto senza informazioni sensibili.

E0 + 10 settimane — blue team test report (art. 11(4), Allegato VI): cosa è stato rilevato, quando, tramite quale controllo, cosa è stato escalato e cosa è sfuggito. È il documento che decide se la tua narrativa di detection regge all’impatto con le evidenze.

E0 + 10 settimane — replay e purple teaming (art. 11(5)): blue team e tester ripercorrono insieme le azioni offensive e difensive, e il control team conduce un esercizio di purple teaming su temi identificati congiuntamente — vulnerabilità emerse durante il test e questioni non testabili nella fase attiva. Il purple teaming in closure è obbligatorio sotto l’RTS, non opzionale come nelle versioni precedenti del framework. Al termine control team, blue team, tester e provider di threat intelligence si scambiano feedback strutturati sul processo (art. 11(6)).

N0 + 8 settimane — il report di sintesi (art. 11(7), Allegato VII), presentato una volta che l’autorità ha confermato che entrambi i report di team contengono i contenuti richiesti. È l’artefatto che l’art. 26(6) DORA nomina.

N0 + 8 settimane — il piano di remediation (art. 12), all’autorità TLPT e, se diversa, all’autorità competente. Per ciascun finding deve riportare: descrizione della carenza; misure di remediation proposte con prioritizzazione e completamento atteso, incluse le misure per migliorare capacità di identificazione, protezione, detection e risposta; una root cause analysis; il personale o la funzione responsabile dell’implementazione; e i rischi derivanti dal non implementare le misure, oltre agli eventuali rischi generati dall’implementarle.

L’attestazione è poi rilasciata dall’autorità TLPT ex art. 26(7) DORA e conferma che il test è stato svolto in conformità ai requisiti. È l’artefatto che revisori, assicuratori e controparti chiederanno di vedere — e l’unico che non puoi produrti da solo.

Assembla queste evidenze mentre l’ingaggio procede, firmate e datate al momento della creazione. Ordinate per il gate che le consuma.

Consumate al gate T0 + 3: notifica dell’autorità con data di ricezione; project charter mappato sull’Allegato I; roster del control team con i ruoli e la relativa validazione dell’autorità; intenzione dichiarata su tester interni o esterni; inventario dei canali di comunicazione; registro del code name.

Consumate al gate T0 + 6: scope specification document mappato sull’Allegato II; motivazione funzione per funzione di inclusioni ed esclusioni contro i criteri dell’art. 8(6); verbale dell’organo di gestione che registra l’approvazione; risk assessment del TLPT e misure di gestione del rischio con il record della consultazione dei test manager.

Consumate prima della fase di test: pacchetto di due diligence sui provider — referenze, certificazioni, polizze di responsabilità professionale e CV nominativi mappati riga per riga sulle soglie di esperienza dell’art. 5(2); policy sui tester interni ed evidenza dei 12 mesi di impiego ove applicabile; contratti con gli accordi di segretezza.

Consumate durante la fase di test: approvazione dell’autorità sul targeted threat intelligence report; motivazione della selezione degli scenari; red team test plan approvato e ogni modifica successiva con approvatore e timestamp; report settimanali di avanzamento; log dei leg-up con cosa è stato concesso, quando e perché; log degli eventi di detection con le misure di prosecuzione e la loro validazione; verbale di sospensione se è stato invocato l’art. 10(10).

Consumate in closure: red team test report; blue team test report; verbali di replay e purple teaming inclusa la lista dei temi; record dei feedback di processo; report di sintesi; piano di remediation con owner nominati e root cause; e infine l’attestazione dell’autorità.

Consumate in continuo, tra un ingaggio e l’altro: l’evidenza che i finding sono stati davvero chiusi. Il piano di remediation dichiara date di completamento attese; la successiva interazione di vigilanza chiede cosa è accaduto a quelle date, e il TLPT successivo riparte dalla postura che hai effettivamente raggiunto. È qui che l’ingaggio fallisce silenziosamente per la maggior parte delle entità — non a un gate, ma nei diciotto mesi di silenzio successivi, perché le evidenze di chiusura vivono in export di ticket la cui provenienza nessuno sa dimostrare. La posizione che il team Zero Hunt prende qui è il rail AI Generative Pentest eseguito in continuo tra gli esercizi triennali: uno swarm di dieci agenti che concatena ricognizione, sfruttamento, attacco alle credenziali, post-exploitation e pivoting su target di produzione, con ogni catena generata ribacktestata nell’AI Gym prima di girare, e ogni finding e retest firmato ECDSA al momento della scrittura. Il retest firmato di un finding TLPT diventa un artefatto di prima classe invece di uno screenshot in una slide, e il targeted threat intelligence report successivo parte da una postura misurata anziché da una sperata.

1. Trattare le 12 settimane come il progetto. I vincoli stringenti sono il gate dei tre mesi sui documenti di avvio e quello dei sei mesi sullo scope, entrambi precedenti a qualsiasi test. Le entità che avviano la pianificazione quando il red team è già in procurement hanno già mancato due scadenze.

2. Fare procurement sul prezzo e non superare l’art. 5(2). Numero di referenze, anni di esperienza per singola persona nominata, certificazioni e polizza professionale sono soglie rigide, e l’autorità può rifiutare la tua decisione di contrattualizzazione. Verifica contro le soglie durante la gara, non dopo la firma.

3. Uno scope specification document che l’organo di gestione ratifica a scatola chiusa. L’art. 8(5) richiede l’approvazione dell’organo di gestione proprio perché la decisione di scope sia posseduta a livello di consiglio. I supervisori leggono i verbali, e un punto all’ordine del giorno da cinque minuti su un documento che ha escluso tre funzioni critiche è già di per sé un rilievo di governance.

4. Entrare senza una baseline di detection misurata. Il blue team test report a E0 + 10 settimane è dove *l’avremmo intercettato* incontra la timeline di ciò che è stato realmente rilevato. Se l’unica evidenza precedente di capacità di detection è un’esercitazione annuale, il report si scrive da sé contro di te — e il piano di remediation ti impegna poi su miglioramenti che non saprai dimostrare prima del test successivo.

5. Un piano di remediation che è una lista di ticket. L’art. 12(2) pretende root cause analysis, prioritizzazione con completamento atteso, personale o funzioni responsabili nominati e i rischi del non agire. Un export Jira non soddisfa nessuno dei quattro.

6. Usare tester interni per il terzo test consecutivo. L’art. 26(8) DORA impone tester esterni ogni tre test, e l’RTS è esplicito: un team che mescola tester interni ed esterni conta come interno a quel fine. Tieni il conteggio sull’intero ciclo triennale, non per singola business unit.

7. Lasciare che l’attestazione diventi lo stato finale. L’attestazione conferma che il test è stato condotto correttamente. Non dice nulla sulla chiusura dei finding, e invecchia: le priorità di vigilanza BCE per il 2026-2028 collocano il threat-led penetration testing dentro un programma di vigilanza continuo insieme alle ispezioni in loco, non come casella triennale da spuntare.

La metodologia è TIBER-EU. Il framework TIBER-EU della BCE e il suo corpo di guidance 2025 — procurement dei service provider, control team, purple teaming, scope specification, targeted threat intelligence, red team test plan e report, blue team report, remediation plan, test summary report e attestation guidance — è il manuale operativo dietro gli articoli dell’RTS. Vanno letti insieme: l’RTS dice cosa è dovuto e quando, TIBER-EU dice cosa il documento deve contenere.

In Italia lo strumento è TIBER-IT. Banca d’Italia, Consob e IVASS hanno pubblicato congiuntamente la versione 2.0 della Guida nazionale TIBER-IT a novembre 2025, annunciata con comunicazione congiunta l’11 dicembre 2025, che recepisce le novità DORA in materia di TLPT. È lo strumento metodologico unico per le entità finanziarie italiane, e copre sia i test DORA obbligatori sia quelli volontari delle entità non designate.

Entità transfrontaliere. Se l’entità presta servizi in più di uno Stato membro, la sua autorità TLPT determina quali autorità host coinvolgere, in base al fatto che funzioni critiche o importanti siano operate in quegli Stati o condivise tra essi (art. 14(1)). Le autorità host hanno poi 20 giorni lavorativi per manifestare interesse a seguire il test come osservatori o per assegnare un test manager. Salvo diverso accordo, l’autorità home guida il test e condivide con gli osservatori lo scope specification document, il report di sintesi, il piano di remediation e l’attestazione. Conseguenza pratica: il tuo control team potrebbe coordinarsi con più autorità su un unico calendario, e l’autorità lead può fissare un tetto ai partecipanti per mantenere il test gestibile.

TLPT pooled e joint. Un TLPT pooled ex art. 26(4) DORA consente a più entità che condividono un fornitore ICT terzo di testare insieme quando test separati inciderebbero negativamente su qualità o sicurezza del servizio. In un test pooled almeno uno scenario deve includere i sistemi, processi e tecnologie ICT sottostanti del fornitore terzo che supportano le funzioni in scope. Un TLPT joint è il caso affine di entità che usano sistemi ICT comuni o un fornitore infragruppo condiviso, di nuovo con almeno uno scenario che raggiunga il fornitore infragruppo. In entrambi i casi ogni entità partecipante mantiene il proprio control team e la propria gestione del rischio, e gli scenari non devono degradare il servizio di alcun partecipante.

Cosa questo non sostituisce. Il TLPT si aggiunge al programma di test degli artt. 24 e 25, non lo rimpiazza — il punto sollevato da Frank Elderson alla Goldman Sachs European Financials Conference del 3 giugno 2026, che ha avvertito come il tooling offensivo guidato dall’AI riesca a scoprire e sfruttare vulnerabilità a una velocità e su una scala superiori a quanto i difensori abbiano finora affrontato, e come il tempo a disposizione della difesa si stia riducendo. Una cadenza triennale risponde a una domanda di vigilanza; non risponde a una domanda operativa. Il rapporto tra esercizio triennale e validazione continua è trattato nella definizione di TLPT e in CTEM.