RTS TLPT DORA: requisiti e scadenze di 2025/1190

La decisione che questa guida vi aiuta a prendere

Le norme tecniche di regolamentazione (RTS) definitive sul TLPT traducono l’obbligo previsto da DORA in uno specifico processo operativo. Iniziate distinguendo le tempistiche di preparazione, test attivo e chiusura, quindi assegnate le decisioni e le evidenze richieste ai responsabili competenti. Questa guida segue il Regolamento (UE) 2025/1190 e non considera una bozza precedente come norma applicabile.

Che cosa sono le norme tecniche di regolamentazione (RTS) per il TLPT DORA?

Le RTS TLPT di DORA sono il Regolamento delegato (UE) 2025/1190 della Commissione. Il regolamento traduce l’obbligo previsto da DORA di svolgere test di penetrazione avanzati basati sulle minacce in un processo dettagliato: quali entità finanziarie vengono selezionate, come si governa e definisce l’ambito di un test, cosa devono dimostrare i fornitori, come si svolgono i test e quali evidenze seguono.

Per un CISO, il responsabile di un team di controllo o chi si occupa degli acquisti, la sfida pratica consiste nel collegare questi requisiti in un unico programma realizzabile. Un eccellente rapporto tecnico non può compensare la mancanza di autorizzazioni delle autorità, un ambito giustificato in modo insufficiente o un processo di chiusura mai pianificato. Allo stesso modo, una documentazione completa è di utilità limitata se non sa spiegare cosa è accaduto alle funzioni critiche sottoposte a test.

Questa guida segue le RTS definitive e distingue i requisiti di legge dai nostri suggerimenti pratici di pianificazione. Per una panoramica dell’incarico, visitate la homepage dei servizi TLPT DORA. Per un’introduzione più breve, consultate la guida ai requisiti TLPT DORA.

Fonti: RTS definitive sul TLPT, incluso l’articolo 17; articolo 26 del DORA. Le due fotografie sono illustrazioni generate dall’IA, non documentazione di un incarico cliente.

DORA, gli RTS TLPT e TIBER-EU: quale prevale?

DORA è il regolamento quadro. Gli articoli 26 e 27 riguardano i test avanzati e i requisiti per i tester. Gli RTS TLPT aggiungono le regole dettagliate adottate in base a tale mandato. TIBER-EU fornisce un quadro operativo consolidato e indicazioni di supporto per i test di red team basati su intelligence.

Nel 2025 la BCE ha aggiornato TIBER-EU per allinearlo a DORA. La guida all’attuazione per gli enti significativi distingue espressamente la normativa vincolante dal quadro utilizzato per attuarla. La guida riguarda la procedura della BCE per gli enti significativi individuati; non va presentata come la procedura dell’autorità competente applicabile a ogni entità finanziaria in Europa.

In fase di approvvigionamento, richiedere che la proposta identifichi tutti e tre i livelli: i requisiti legali, la procedura dell’autorità competente e il metodo di esecuzione. «TIBER-style» non è uno stato di approvazione. Un’esercitazione red team volontaria, anche se rigorosa, non ottiene automaticamente il riconoscimento come TLPT DORA richiesto all’entità.

Riferimenti ufficiali utili: l’annuncio della BCE sull’aggiornamento del framework TIBER-EU, la biblioteca del framework e delle linee guida TIBER-EU e la guida all’attuazione di TIBER-EU nell’SSM.

Chi deve svolgere il TLPT ai sensi degli RTS?

L’articolo 2 combina i criteri di selezione con una valutazione dell’autorità competente relativa all’impatto, all’importanza sistemica e al rischio ICT. La platea non è definita da un numero universale di dipendenti, da una soglia generica di fatturato o dal solo fatto che un’impresa venda un prodotto finanziario. Né il mancato superamento di una singola soglia numerica risolve ogni questione di applicabilità.

Le RTS riguardano categorie quali gli enti creditizi a rilevanza sistemica, gli istituti qualificati di pagamento e di moneta elettronica, i depositari centrali di titoli, le controparti centrali, alcune sedi di negoziazione elettronica e le imprese di assicurazione o riassicurazione qualificate. Le condizioni dettagliate variano a seconda della categoria. Nell’ambito del quadro di selezione, le autorità dispongono inoltre di poteri che rendono inaffidabile un semplice calcolatore online con risposta sì/no.

Consideri questi esempi come spunti per indirizzare una verifica di applicabilità, non come una determinazione completa. Registri la persona giuridica, il perimetro di vigilanza, la notifica pertinente, l’autorità capofila e gli eventuali accordi a livello di gruppo. Non si dovrebbe presumere con leggerezza che un’istruzione rivolta a una società del gruppo si applichi a tutte le controllate o piattaforme condivise.

Criteri di selezione: articolo 2 delle RTS TLPT.

La nostra guida su chi necessita di un TLPT aiuta a organizzare le domande iniziali. Confermi la conclusione tramite la procedura dell’autorità competente prima di impegnarsi su una data di esecuzione.

Ruoli, segretezza e processo decisionale

L’articolo 3 richiede che l’autorità designi un responsabile dei test e almeno un sostituto. L’articolo 4 richiede che l’entità finanziaria nomini un responsabile del team di controllo e istituisca adeguate garanzie organizzative. Il responsabile del team di controllo deve avere il mandato per prendere decisioni tempestive; il ruolo non può limitarsi alla gestione del calendario.

La riservatezza è importante perché il test esamina il comportamento difensivo effettivo. Limiti le informazioni sui test pianificati e in corso alle persone pertinenti che devono esserne a conoscenza. Concordi come informare il team di controllo delle rilevazioni senza rivelare inutilmente l'esercitazione e come comunicare con i responsabili dei test prima di coinvolgere il team blue. Utilizzi con coerenza il nome in codice concordato e canali sicuri.

Un pacchetto operativo di governance dovrebbe individuare chi può approvare un adattamento, sospendere le attività, coinvolgere un fornitore di servizi ICT, gestire un incidente reale e autorizzare la ripresa. Designi sostituti e referenti fuori orario. Se una decisione incide sull’ambito o sul piano di test, segua il percorso di approvazione previsto dalle RTS anziché affidarsi a una conversazione informale tra i team di esecuzione.

• Organo di gestione: approvi la specifica dell'ambito e destini risorse alle responsabilità dell'entità.
• Team di controllo: mantenere il quadro dei rischi, la riservatezza e le decisioni per tutta la durata del test.
• Responsabili dei test dell’autorità: supervisionano la conformità e partecipano al processo di approvazione definito.
• Fornitore di informazioni sulle minacce: sviluppare informazioni specifiche per l'entità e restare disponibile durante i test.
• Team red e blue: producono evidenze complementari delle attività offensive e della risposta difensiva.

Requisiti organizzativi: articolo 4 delle RTS TLPT.

Per ulteriori dettagli sulla preparazione, consultate come organizzare il team di controllo del TLPT.

Scadenze delle RTS sul TLPT DORA: non confondere i termini

Le ultime due scadenze vengono spesso interpretate in modo errato. Il termine decorre dalla notifica dell’autorità di aver valutato i rapporti del red team e del blue team rispetto ai contenuti richiesti dagli allegati. Non coincide automaticamente con l’ultimo giorno delle operazioni del red team. Conservi la notifica stessa nella documentazione del progetto, così che la data sia verificabile.

La scadenza di sei mesi per definire l’ambito non significa che debba aspettare sei mesi prima di agire. L’approvvigionamento dei fornitori, la mappatura delle dipendenze, l’approvazione della direzione e le autorizzazioni di terze parti possono diventare fattori limitanti. Pianifichi a ritroso rispetto alle consegne richieste e riservi tempo per domande e revisioni. Le RTS non trasformano l’intero incarico in un pacchetto fisso di dodici settimane.

Requisiti di chiusura: articolo 12 delle RTS TLPT.

Per informazioni utili alla pianificazione, consultate la nostra guida alle tempistiche del TLPT.

Definire l'ambito: partire dalle funzioni e seguire le dipendenze

L’articolo 26 del DORA richiede di testare alcune o tutte le funzioni critiche o importanti sui sistemi di produzione live che le supportano. L’articolo 9 e l’allegato II delle RTS rendono più concreta la definizione dell’ambito. Il documento elenca le funzioni critiche o importanti individuate dall’entità e spiega se sono incluse o escluse. Per quelle incluse, identifica i sistemi TIC di supporto, l’esternalizzazione, le giurisdizioni e le indicazioni preliminari.

Un flag è un obiettivo di test concordato e collegato a un aspetto della sicurezza, come riservatezza, integrità, autenticità o disponibilità. Dovrebbe rendere comprensibile la prova prevista. «Compromettere la banca» è troppo vago per guidare l’attività in sicurezza; un obiettivo definito e associato a un servizio aziendale identificato offre al team un elemento da valutare e al team di controllo un’attività da autorizzare.

Per una funzione di pagamento a titolo esemplificativo, mappate il canale cliente, il livello di identità, il flusso di approvazione, l’elaborazione delle transazioni, le operazioni privilegiate e la connettività esterna. Identificate il responsabile di ciascuna dipendenza e gli accordi con i fornitori che incidono sui test. Distinguete un componente testato direttamente da una dipendenza documentata ma soggetta a una limitazione concordata. Non presentate tacitamente quest’ultima come se fosse stata testata.

Tenga un registro delle decisioni sull’ambito. Ogni voce può riportare la funzione, i sistemi, la motivazione dell’inclusione, il responsabile, le terze parti, le dipendenze geografiche, i flag proposti e le autorizzazioni ancora da definire. È un formato operativo pratico, non sostituisce l’allegato II né il modello dell’autorità competente. Facilita la revisione delle modifiche quando le informazioni o i risultati tecnici incidono sull’approccio proposto.

Preparazione e approvazione dell’ambito: articolo 9 delle RTS TLPT.

Correlati: definizione dell’ambito di un TLPT DORA e lista di controllo della preparazione al TLPT.

Requisiti per i fornitori: cosa richiede effettivamente l’articolo 7

La due diligence sul fornitore deve valutare le persone assegnate al test e le evidenze alla base della proposta. L’articolo 7 integra l’articolo 27 del DORA con requisiti specifici per il fornitore di threat intelligence e per i tester esterni. Un logo di certificazione su un sito web non costituisce una valutazione completa.

Chiedete al fornitore di associare le prove a ciascun paragrafo pertinente anziché dichiarare genericamente la «conformità agli RTS». Verificate la disponibilità per il periodo richiesto, i controlli sul personale sostitutivo, le responsabilità relative ai report e l’interazione prevista con i responsabili dei test dell’autorità. Le referenze e l’esperienza sono questioni distinte: il portafoglio storico di un’azienda non dimostra che il team indicato per nome soddisfi i requisiti di organico.

L’articolo 7 prevede, in circostanze eccezionali, la possibilità di derogare a determinati criteri, accompagnando la deroga con adeguate misure di mitigazione e relativa documentazione. Non la consideri una scorciatoia ordinaria per gli acquisti né si conceda una deroga generalizzata. Sottoponga ogni deroga prevista alla procedura dell’autorità e ne documenti le motivazioni prima di finalizzare le nomine.

Requisiti per la selezione del fornitore: articolo 7 delle RTS TLPT.

Utilizzi la nostra guida agli acquisti e la nostra spiegazione dei requisiti per i tester previsti dall'articolo 27 del DORA per strutturare le domande. Questo articolo descrive i criteri di valutazione; non formula affermazioni non verificate sulle credenziali di un fornitore.

Tester interni, tester esterni e team di gruppo

I test interni sono un’opzione soggetta a controlli, non un diritto generalizzato. DORA stabilisce le condizioni per l’approvazione dell’autorità competente, la separazione, le risorse e la prevenzione dei conflitti di interesse. Quando si utilizzano tester interni, richiede threat intelligence esterna e tester esterni almeno ogni tre test. Gli enti creditizi significativi soggetti al Meccanismo di vigilanza unico devono utilizzare tester esterni.

L’articolo 15 delle RTS aggiunge requisiti per gli accordi relativi ai test interni. I tester impiegati da un fornitore di servizi ICT infragruppo sono considerati tester interni. Il regolamento disciplina inoltre la comunicazione dell’impiego di tester interni nelle informazioni di avvio, nel rapporto red team e nel rapporto di sintesi. Un team non diventa esterno per il solo fatto di appartenere a un’altra società del gruppo.

Ai fini della pianificazione, distinguete la capacità dall’indipendenza. Un red team interno tecnicamente molto preparato può comunque avere responsabilità in conflitto o essere necessario per attività difensive essenziali. Documentate come l’esercizio eviterà di indebolire le normali operazioni di sicurezza dell’entità. Se vengono combinati tester interni ed esterni, verificate il trattamento applicabile ai tester interni invece di presumere che la presenza di membri esterni elimini tali requisiti.

Fonti: articolo 26 del DORA, articolo 27 e articolo 15 delle RTS.

Informazioni sulle minacce e le tre dimensioni dello scenario

L’articolo 10 richiede intelligence mirata dopo l’approvazione dell’ambito da parte dell’autorità competente. L’intelligence settoriale è un elemento di partenza, ma il risultato deve riguardare la specifica entità: le informazioni esposte, i profili di minaccia pertinenti, le dipendenze e i plausibili percorsi di attacco. Un catalogo generico delle minacce informatiche attuali non è sufficiente come base per un TLPT su misura.

L’allegato III richiede almeno tre scenari di minaccia end-to-end per i profili di minaccia pertinenti con il livello di gravità più elevato, che coprano disponibilità, integrità dei dati e riservatezza delle informazioni. Ogni scenario può riguardare più di una dimensione di sicurezza. Tali requisiti non autorizzano dimostrazioni distruttive; i controlli del rischio disciplinano il modo in cui si persegue e si documenta un obiettivo.

Per ogni scenario, chieda: perché questo attore o profilo di minaccia, perché questa funzione, perché questo percorso e quale osservazione renderebbe utile il risultato? Segua poi l’ipotesi di intelligence fino al piano di test del red team. Se durante i test un’ipotesi si rivela errata, registri la modifica e la relativa approvazione, anziché sostituirla tacitamente con un attacco più conveniente.

Una riga pratica di tracciabilità può contenere il riferimento di intelligence, la funzione, lo scenario, l’indicazione di pianificazione, le tecniche consentite, i vincoli di rischio, le evidenze di esecuzione e l’esito finale. Preveda uno spazio per spiegare le incertezze. Le informazioni di intelligence possono indicare che un percorso è plausibile; non dimostrano in anticipo che il bersaglio sia vulnerabile.

Fase di threat intelligence e allegato III: articolo 10 delle RTS TLPT.

Test attivi, controlli del rischio e accessi aggiuntivi

L’articolo 11 richiede il piano di test del red team e le approvazioni pertinenti prima dell’esecuzione attiva. L’allegato IV tratta la comunicazione, le tecniche consentite e vietate, i limiti etici del social engineering, le misure di gestione del rischio e gli altri elementi richiesti del piano. Durante i test attivi, i progressi devono essere comunicati almeno ogni settimana al team di controllo e ai responsabili dei test.

Un leg-up è un’assistenza controllata che consente di esplorare le fasi successive quando, altrimenti, uno scenario non potrebbe proseguire come previsto. Non dimostra che la fase precedente abbia avuto successo. Se viene fornito un accesso per continuare uno scenario, la narrazione finale deve distinguere tale assistenza dall’accesso effettivamente ottenuto tramite il test. In questo modo, le conclusioni restano utili alla direzione e ai team di difesa.

Il team di controllo deve mantenere aggiornata la valutazione del rischio operativo. L’articolo 5 considera esplicitamente i rischi derivanti dalle attività sia del red team sia del blue team, dall’escalation degli incidenti e da un ripristino incompleto. Anche una reazione difensiva può causare interruzioni. Concordate come distinguere gli incidenti reali dagli eventi di test, quali contatti possono interrompere le attività e come documentare la pulizia finale.

L’articolo 11 consente la sospensione in circostanze di rischio eccezionali e, come ultima risorsa e previa convalida dell’autorità competente, la prosecuzione tramite un’attività limitata di purple teaming quando non sia altrimenti possibile continuare. Tale attività limitata concorre al minimo previsto per la fase attiva. Si tratta di un’eccezione disciplinata, non di una giustificazione generale per vendere un workshop come dodici settimane di test attivi.

Test attivi, adattamento e misure eccezionali: articolo 11 delle RTS TLPT.

La nostra panoramica sulla metodologia TLPT spiega come si integrano governance e svolgimento tecnico.

Terze parti, test aggregati e test congiunti

L’esternalizzazione non elimina la responsabilità relativa alla funzione. Se l’ambito coinvolge un fornitore di servizi ICT, occorre definire come parteciperà, come avverranno le comunicazioni con l’autorità competente, a quali ambienti sarà possibile accedere e come si eviteranno impatti sugli altri clienti. Questi aspetti vanno risolti prima che il calendario di esecuzione dipenda da essi.

Le iniziative TLPT raggruppate e congiunte richiedono un coordinamento dedicato. Gli articoli 6 e 8 riguardano la gestione dei rischi e le specificità procedurali, mentre l’articolo 16 disciplina la cooperazione tra autorità. In genere, ciascuna entità coinvolta segue le fasi definite, salvo diversa decisione dell’autorità capofila. Il team di controllo di ogni entità finanziaria conduce la propria valutazione dei rischi; un piano di progetto comune non annulla i rischi specifici di ciascuna entità.

Per una piattaforma condivisa, un’utile matrice di pianificazione associa a ciascuna entità giuridica le funzioni critiche, i sistemi di supporto, i referenti dei fornitori, le giurisdizioni, le responsabilità di approvazione e le evidenze attese. Evidenziate quali rilievi sono comuni e quali conclusioni possono essere tratte solo per una specifica entità. Evitate che un rapporto di gruppo formuli affermazioni più ampie di quanto supportato dall’ambito testato.

Fonti: articolo 26 del DORA e articolo 16 delle RTS. Indicazioni correlate: fornitori terzi nel TLPT.

Gli otto allegati delle RTS: guida ai documenti

Utilizzi gli allegati come matrice di controllo dei contenuti, non come otto modelli vuoti da compilare alla fine. Assegni a ogni documento un responsabile, un revisore, un evento che determini la scadenza e uno stato di approvazione. Concordi l’ubicazione sicura per l’archiviazione e le regole di gestione dei documenti prima di avviare la raccolta di informazioni. Registri le versioni, così da poter seguire le modifiche all’ambito nel piano di test e nella reportistica.

In particolare, confrontare i contrassegni e gli scenari del rapporto di threat intelligence, del piano di test, del rapporto red team e del riepilogo. Sono rilevanti sia gli obiettivi raggiunti sia quelli non raggiunti. Mantenere la distinzione tra un controllo che ha resistito all’azione testata, un’azione non tentata per motivi di sicurezza e un’azione non riuscita perché mancava un prerequisito.

Fonte: allegati I–VIII delle RTS. La nostra panoramica dei deliverable e il rapporto fittizio di esempio sul TLPT DORA illustrano il contesto della rendicontazione. Un rapporto di esempio non sostituisce il pacchetto completo da presentare all’autorità competente.

Chiusura: rapporto del red team, rapporto del blue team, replay e purple teaming

La fase di chiusura inizia quando il responsabile del team di controllo informa il blue team che è stato svolto un TLPT. Il rapporto del red team documenta le attività offensive. Il blue team espone poi la prospettiva difensiva. Lo scopo è confrontare le due prospettive sulla stessa attività, incluse le discrepanze tra telemetria disponibile, rilevamento effettivo e decisioni prese.

La riproduzione e il purple teaming dovrebbero produrre apprendimenti concreti. Selezionare eventi in cui le ipotesi divergevano: un'azione simulata che non ha generato un allarme utilizzabile, un allarme privo di contesto sufficiente per il triage oppure un'escalation arrivata al responsabile sbagliato. Spiegare quale parte della catena deve essere modificata. Una constatazione intitolata «Il SOC non ha rilevato l'attacco» è meno operativa di una descrizione supportata dell'evento, della correlazione o della decisione di risposta mancanti.

Distinguete l’esercitazione finale di purple teaming dal purple teaming limitato ed eccezionale consentito durante i test attivi. Nei RTS hanno funzioni diverse. Pianificate il lavoro di chiusura richiesto già in fase di appalto, compreso l’accesso ai team di difesa appropriati e il tempo sufficiente per confrontare le cronologie. Non presumete che si tratti di un’attività facoltativa aggiuntiva dopo la conclusione del red teaming.

Mantenere i dettagli sensibili nei registri controllati appropriati. L’articolo 12 consente all’autorità competente di richiedere informazioni sensibili contenute nei rapporti. Una sintesi per la direzione dovrebbe comunicare le conseguenze e le decisioni necessarie senza diventare un canale di diffusione incontrollata di dettagli operativi dell’attacco.

Chiusura e reporting: articolo 12 delle RTS TLPT.

Approfondimenti: reporting TLPT e remediation.

Rimedio e attestazione: evidenze successive all’esercitazione

L’articolo 13 richiede che il piano affronti ciascun rilievo: la carenza, le misure proposte, la priorità e la data prevista di completamento, la causa radice, il personale o le funzioni responsabili e i rischi derivanti dalla mancata attuazione delle misure o, se pertinente, dalla loro attuazione. Non trasformate una carenza trasversale in un elenco di correzioni scollegate solo perché è facile contare i ticket delle singole patch.

Considerate una debolezza esemplificativa dei controlli di identità che interessa più sistemi. L’azione immediata potrebbe limitare un’autorizzazione, ma la causa sottostante potrebbe essere una lacuna di responsabilità nel ciclo di vita degli accessi. Un piano efficace registra entrambi gli aspetti, li assegna ai responsabili appropriati e definisce una condizione di completamento osservabile. In caso contrario, lo stesso problema potrebbe ripresentarsi in un altro sistema prima del successivo TLPT.

Ritest e revisione delle evidenze sono metodi pratici per distinguere tra «modifica implementata» e «riduzione del rischio dimostrata». Collegate le evidenze di accettazione al rilievo originale e alla limitazione concordata. Se un’azione non può ancora essere completata, documentate la decisione, le misure compensative e l’esposizione residua attraverso il processo di governance dell’entità.

L’attestazione ai sensi dell’articolo 26, paragrafo 7, del DORA, dell’articolo 14 dell’RTS e dell’allegato VIII supporta il riconoscimento reciproco del TLPT. Viene rilasciata tramite la procedura dell’autorità. Un fornitore non può semplicemente sostituirla con un badge generico «certificato DORA». L’attestazione non dichiara neppure che l’organizzazione sia priva di vulnerabilità o abbia soddisfatto ogni requisito del DORA.

Requisiti del piano di rimedio: articolo 13 delle RTS TLPT.

Requisiti dell’attestazione: articolo 14 delle RTS TLPT.

Un piano pratico di preparazione di 30 giorni

Il seguente suggerimento per la mobilitazione interna non introduce una nuova scadenza normativa né afferma che un TLPT possa essere completato in trenta giorni. Mira a trasformare un obbligo in un processo controllato di approvvigionamento e preparazione prima dell’avvio delle attività tecniche.

Prevedete un budget per l’intero programma. Chiedete che le offerte distinguano le attività di intelligence, i test attivi, il supporto al team di controllo, il coordinamento con terze parti, la redazione dei rapporti, il replay, il Purple Teaming e il supporto alla remediation. Non esiste un tariffario RTS universale. Un prezzo apparentemente conveniente perché esclude attività obbligatorie può comportare costose modifiche dell’ambito in seguito.

Utilizzate il generatore del brief di definizione dell’ambito DORA TLPT per organizzare informazioni di alto livello da discutere. Non inserite credenziali, diagrammi sensibili o dati dei clienti in un modulo iniziale. Allegate un NDA o una RFP esistente tramite il flusso di contatto prima di condividere materiale dettagliato.

Errori comuni nella pianificazione delle RTS e come evitarli

Prima di firmare la dichiarazione di lavoro, ponete un’ultima domanda: ogni risultato richiesto è riconducibile a un responsabile nominato, a un percorso di approvazione e a una data di attivazione? Se la risposta è no, l’ambito commerciale non è ancora abbastanza specifico da poter essere gestito con sicurezza.

RTS sul TLPT DORA: domande frequenti

Che cosa sono le norme tecniche di regolamentazione (RTS) per il TLPT DORA?

Si tratta del regolamento delegato (UE) 2025/1190 della Commissione. Integra DORA con norme sulla selezione delle entità per i TLPT, sull’organizzazione e lo svolgimento dei test, sulla scelta dei fornitori, sulla rendicontazione, sulla risoluzione delle carenze, sull’attestazione e sulla cooperazione tra autorità.

Le RTS TLPT di DORA sono definitive o ancora in bozza?

Il regolamento definitivo è stato pubblicato nella Gazzetta ufficiale il 18 giugno 2025 ed è entrato in vigore l’8 luglio 2025. Occorre fare riferimento al testo adottato, senza considerare vincolanti la precedente consultazione o la bozza finale.

Ogni entità regolamentata da DORA ha bisogno di un TLPT?

No. Il TLPT avanzato si applica agli enti finanziari individuati secondo la pertinente procedura di selezione prevista da DORA e dagli RTS. Gli obblighi più ampi di DORA relativi ai test di resilienza operativa digitale sono distinti. Verificate il vostro status con l’autorità competente.

Il minimo di 12 settimane copre l’intero progetto?

No. L’articolo 11, paragrafo 5, degli RTS stabilisce una durata minima di 12 settimane per i test attivi di red team. Preparazione, intelligence sulle minacce, rendicontazione, ripetizione dei test, purple teaming e interazioni con le autorità richiedono ulteriore tempo.

Quando devono essere consegnati la sintesi TLPT e il piano di remediation?

Entrambi prevedono un termine di otto settimane collegato alla notifica dell’autorità descritta nell’articolo 12, paragrafo 7, relativa alla valutazione dei rapporti dei team red e blue. Non conteggiate automaticamente queste otto settimane dalla fine dei test attivi.

Un normale penetration test può sostituire un TLPT DORA?

Un normale penetration test non è automaticamente un TLPT ai sensi di DORA. Devono essere soddisfatti il coinvolgimento richiesto delle autorità, l’ambito, la threat intelligence, il processo di test, le prove di chiusura e le altre condizioni. La denominazione adottata da un fornitore non costituisce riconoscimento normativo.

Un unico fornitore può offrire threat intelligence e attività di red teaming?

Le RTS contemplano fornitori appartenenti alla stessa società, ma il personale assegnato alla threat intelligence deve essere separato dal personale che fornisce tester esterni per la stessa TLPT e non deve riferire a quest’ultimo. Restano applicabili gli altri requisiti di indipendenza e gestione dei conflitti di interesse.

Un’attestazione TLPT significa che l’organizzazione è pienamente conforme a DORA?

No. L’attestazione dell’autorità riguarda il TLPT e supporta il riconoscimento reciproco. Non è una certificazione universale di conformità a DORA, un’attestazione di assenza di problemi né una garanzia che tutte le debolezze siano state eliminate.

Pianificate un incarico TLPT DORA con Atlant Security

Il servizio TLPT DORA di Atlant Security riporta la discussione sulle vostre funzioni critiche, sul contesto delle autorità competenti, sui vincoli operativi e sulle evidenze richieste. Si parta dalla persona giuridica, dallo stato della notifica, dalle funzioni candidate, dalle dipendenze da terze parti e dalle tempistiche previste. Questi dettagli consentono un confronto utile sull'ambito prima di predisporre una proposta.

Esplori la pagina principale sul TLPT DORA, prepari un documento di definizione dell’ambito oppure invii la richiesta di proposta o l’accordo di riservatezza. Se desidera prima esaminare lo stile di un deliverable tecnico, richieda il rapporto TLPT DORA di esempio; il link per il download viene inviato via e-mail.