Penetration Testing per la Compliance DORA: Cosa devono sapere gli enti finanziari UE

Il Digital Operational Resilience Act (DORA) rappresenta il cambiamento più significativo nella regolamentazione della cybersecurity che il settore finanziario dell'UE abbia mai visto. Al suo centro, affiancato ai framework di gestione del rischio ICT e agli obblighi di segnalazione degli incidenti, c'è una serie di requisiti di testing che trasforma il Penetration Testing da un'attività volontaria a un'attività legalmente obbligatoria con frequenze, regole di scoping, qualifiche dei tester e supervisione definite.

Se sei una banca, un assicuratore, un istituto di pagamento, una società di investimento o qualsiasi altra entità regolamentata ai sensi della legge sui servizi finanziari dell'UE, questo si applica a te. Se sei di importanza sistemica, la situazione si fa ancora più intensa. E se sei un fornitore ICT terzo che serve queste entità, non sei escluso.

Questa guida illustra tutto ciò che devi capire: cosa richiede DORA, chi è coinvolto, la differenza tra i test annuali standard e il regime avanzato di Threat-Led Penetration Testing (TLPT) e come costruire un programma di testing che ti mantenga conforme senza annegare nella complessità normativa.

Cos'è DORA e perché esiste?

Il Digital Operational Resilience Act (Regolamento UE 2022/2554) è stato adottato dal Consiglio Europeo nel dicembre 2022, è entrato in vigore il 16 gennaio 2023 ed è diventato applicabile il 17 gennaio 2025. A differenza di una Direttiva, che richiede il recepimento nel diritto nazionale, DORA è un Regolamento, il che significa che è direttamente applicabile in tutti gli Stati membri dell'UE senza modifiche.

DORA esiste perché il settore finanziario dell'UE aveva un problema di frammentazione. Prima di DORA, i diversi paesi applicavano requisiti di cybersecurity differenti ai loro istituti finanziari. Alcuni avevano solidi framework di testing (i Paesi Bassi avevano TIBER-NL, la Germania aveva TIBER-DE), mentre altri avevano requisiti tecnici minimi. Una banca transfrontaliera poteva trovarsi di fronte a tre diversi regimi di testing a seconda della giurisdizione di riferimento.

Nel frattempo, il settore finanziario dipendeva sempre più dall'infrastruttura digitale e dai fornitori ICT terzi. Una singola interruzione del cloud o un attacco cibernetico poteva propagarsi a cascata tra istituzioni, confini e mercati. DORA è stato progettato per creare un framework armonizzato che garantisca che ogni entità finanziaria nell'UE possa resistere, rispondere e riprendersi da interruzioni legate all'ICT.

Il regolamento si basa su cinque pilastri: gestione del rischio ICT, gestione e segnalazione degli incidenti relativi all'ICT, digital operational resilience testing, gestione del rischio di terze parti ICT e condivisione delle informazioni. Il Penetration Testing rientra nel terzo pilastro, trattato nel Capitolo IV (Articoli da 24 a 27) del regolamento, ed è il pilastro con i denti più affilati per i team di sicurezza quotidiani.

Chi è coinvolto?

DORA si applica ampiamente al settore finanziario. Le entità soggette ai suoi requisiti includono istituti di credito (banche), istituti di pagamento, istituti di moneta elettronica, società di investimento, compagnie di assicurazione e riassicurazione, fornitori di servizi di cripto-asset ai sensi di MiCA, depositari centrali di titoli, sedi di negoziazione, repertori di dati sulle negoziazioni, società di gestione del risparmio, agenzie di rating del credito e fornitori di servizi di crowdfunding, tra gli altri.

In termini pratici: se la tua organizzazione è regolamentata ai sensi della legge sui servizi finanziari dell'UE, sei quasi certamente coinvolto in DORA. Il regolamento getta deliberatamente una rete ampia per garantire che la digital operational resilience sia coerente in tutto il settore.

C'è un'eccezione che vale la pena notare. Le microimprese, definite come entità con meno di 10 dipendenti e un fatturato annuo o un bilancio inferiore a 2 milioni di euro, sono soggette a un regime di testing più leggero. Devono comunque applicare un approccio basato sul rischio al testing ICT, ma i requisiti sono proporzionalmente ridimensionati. Per tutti gli altri, si applicano tutti gli obblighi di testing.

E, cosa fondamentale, la portata di DORA si estende oltre le stesse entità finanziarie. I fornitori di servizi ICT terzi, come piattaforme cloud, fornitori SaaS, provider di servizi gestiti, società di analisi dei dati, rientrano nel framework di supervisione di DORA, soprattutto se sono ritenuti critici per la stabilità del settore finanziario. Se sei un fornitore di tecnologia che serve istituti finanziari dell'UE, gli obblighi DORA dei tuoi clienti stanno rapidamente diventando un tuo problema.

I due livelli di Testing DORA

DORA stabilisce un approccio a due livelli per il resilience testing. Comprendere questa struttura è essenziale perché i requisiti, la frequenza e la complessità differiscono in modo significativo tra i livelli.

Livello 1: Penetration Testing Annuale ai sensi degli Articoli 24 e 25

Il requisito di testing di base si applica a ogni entità finanziaria regolamentata da DORA che non sia una microimpresa. L'articolo 24 richiede alle entità finanziarie di stabilire, mantenere e rivedere un programma completo di digital operational resilience testing come parte del loro framework di gestione del rischio ICT.

L'articolo 24(6) è la clausola fondamentale: le entità finanziarie devono garantire che vengano condotti test appropriati su tutti i sistemi e le applicazioni ICT che supportano funzioni critiche o importanti almeno una volta all'anno.

L'articolo 25 elenca quindi i tipi di test che il programma di testing dovrebbe includere. Il regolamento non richiede a ogni entità di eseguire ogni tipo di test (si applica il principio di proporzionalità), ma gli esempi forniscono un quadro chiaro di ciò che si aspettano i regolatori. Questi includono valutazioni e scansioni delle vulnerabilità, analisi open source, valutazioni della sicurezza della rete, analisi dei gap, revisioni della sicurezza fisica, revisioni del codice sorgente (ove possibile), test basati su scenari, test di compatibilità, test delle prestazioni, test end-to-end e Penetration Testing.

Per la maggior parte delle entità finanziarie con un'infrastruttura ICT significativa, il Penetration Testing sarà una componente fondamentale del loro programma annuale. Il regolamento è chiaro: è necessario dimostrare che i propri sistemi possono resistere alle tecniche di attacco del mondo reale, non solo che sono stati scansionati alla ricerca di vulnerabilità note.

Cosa significa "Funzioni Critiche o Importanti"

DORA definisce una funzione critica o importante come quella la cui interruzione comprometterebbe materialmente le prestazioni dell'entità finanziaria, la solidità o la continuità dei suoi servizi o la sua continua conformità agli obblighi normativi. In termini pratici, ciò copre le tue principali operazioni commerciali: elaborazione dei pagamenti, piattaforme di trading, portali rivolti ai clienti, sistemi di credit decisioning, piattaforme di gestione dei sinistri assicurativi, infrastrutture di regolamento e i sistemi backend che li supportano.

L'identificazione di queste funzioni è il primo passo per definire lo scope del tuo programma di testing. Se un sistema supporta una funzione critica o importante, direttamente o tramite dipendenze, rientra nello scope del testing annuale.

Proporzionalità: Ridimensionare i test in base al tuo profilo di rischio

DORA riconosce esplicitamente che non tutte le entità finanziarie hanno le stesse dimensioni o affrontano lo stesso profilo di rischio. L'articolo 4(2) stabilisce un principio di proporzionalità: la profondità e la frequenza del tuo testing devono essere calibrate in base alle dimensioni e alla complessità della tua entità, al profilo di rischio complessivo, alla criticità dei sistemi ICT testati, all'esposizione attraverso l'outsourcing o le dipendenze dal cloud, alle modifiche materiali alla tua infrastruttura ICT e alla gravità e agli esiti degli incidenti precedenti.

Ciò significa che una piccola società fintech con un prodotto mirato e un'infrastruttura limitata non è tenuta a eguagliare il programma di testing di un G-SII (istituzione di importanza sistemica globale). Ma significa anche che non puoi usare la proporzionalità come una scusa generale per fare un testing minimo. Il principio ridimensiona la profondità del testing, non l'obbligo di testare.

Livello 2: Threat-Led Penetration Testing (TLPT) ai sensi degli Articoli 26 e 27

Se il testing annuale standard è la linea di base di DORA, TLPT è il livello avanzato ed è una bestia fondamentalmente diversa.

TLPT è un esercizio di red team su vasta scala, guidato dall'intelligence, condotto su sistemi di produzione live, in segreto dai team di difesa dell'organizzazione, che imita le tattiche, le tecniche e le procedure che i veri attori delle minacce userebbero contro l'entità. Non è una scansione delle vulnerabilità con un nome fantasioso. È un attacco informatico controllato progettato per verificare se la tua istituzione (la sua tecnologia, i suoi processi e le sue persone) può resistere e rilevare un'intrusione sofisticata e mirata.

TLPT è obbligatorio solo per alcune entità finanziarie identificate dalle loro autorità competenti in base all'importanza sistemica, al profilo di rischio e alla maturità ICT. Le entità più propense a essere designate includono banche di importanza sistemica globale (G-SII) e altre istituzioni di importanza sistemica (O-SII), i più grandi istituti di pagamento (quelli che elaborano oltre 150 miliardi di euro in transazioni totali in ciascuno dei due anni precedenti), grandi compagnie di assicurazione e riassicurazione, controparti centrali e depositari centrali di titoli e importanti sedi di negoziazione.

Se la tua autorità competente ti designa per TLPT, devi eseguire test avanzati almeno ogni tre anni. L'autorità può anche aumentare o diminuire questa frequenza in base al tuo profilo di rischio e alle circostanze operative.

Come funziona TLPT: le sei fasi

Gli Standard Tecnici Regolamentari su TLPT (Regolamento delegato della Commissione UE 2025/1190, pubblicato nel giugno 2025) definiscono un processo strutturato che coinvolge diverse fasi distinte.

La fase di preparazione inizia quando l'autorità competente (la tua autorità TLPT) notifica alla tua entità che deve condurre un TLPT. Riunisci un team di controllo, un piccolo gruppo fidato all'interno della tua organizzazione che gestisce il test, e identifichi le funzioni critiche da testare. Lo scope viene quindi sottoposto all'autorità TLPT per la convalida.

La fase di threat intelligence prevede che un fornitore di threat intelligence produca un report di threat intelligence mirato e specifico per la tua istituzione. Questo report analizza gli attori delle minacce che hanno maggiori probabilità di prendere di mira la tua entità, le loro tattiche e tecniche note e gli scenari di attacco più rilevanti per il tuo modello di business, il tuo stack tecnologico e la tua area geografica. Questa intelligence guida l'intero test, garantendo che rifletta le minacce del mondo reale, non i playbook di attacco generici.

La fase di red team testing è l'esecuzione. Il red team, lavorando a partire dalla threat intelligence, conduce una campagna offensiva prolungata contro i tuoi sistemi di produzione live. A differenza del pentesting standard, il test viene eseguito per un periodo prolungato (in genere da tre a quattro mesi), il blue team (i tuoi difensori) non è informato e l'obiettivo è simulare una vera e propria minaccia persistente avanzata.

La fase di chiusura include un esercizio obbligatorio di purple teaming, che è una differenza fondamentale rispetto al precedente framework TIBER-EU in cui il purple teaming era solo raccomandato. Durante il purple teaming, il red team e il blue team collaborano per esaminare gli scenari di attacco, rivedere ciò che è stato rilevato e ciò che è stato perso e identificare in modo collaborativo i miglioramenti. Ciò garantisce che il test generi apprendimento, non solo risultati.

Infine, la fase di reporting e remediation produce la documentazione che viene presentata all'autorità competente per la convalida e l'attestazione. L'autorità conferma che il TLPT è stato condotto in conformità con i requisiti di DORA e rilascia un'attestazione formale.

TLPT vs. Pentesting Standard: Comprendere il divario

La distinzione tra TLPT e Penetration Testing standard è uno dei concetti più importanti per la conformità a DORA e uno dei più comunemente fraintesi.

Un Penetration Testing standard in genere si rivolge a un sistema o applicazione specifica: un'applicazione web, un'API, un segmento di rete. Viene eseguito per una o tre settimane. Il team di sicurezza sa che sta accadendo. Lo scope è delimitato e concordato in anticipo. Il tester cerca vulnerabilità tecniche, tenta di sfruttarle e produce un report con risultati e indicazioni per la remediation. È una valutazione tecnica di una superficie definita.

Un TLPT copre l'intera organizzazione. Si rivolge a funzioni aziendali critiche, non a sistemi specifici. Viene eseguito per mesi, non per settimane. Il team di difesa è completamente all'oscuro. Il test è guidato da threat intelligence su misura, non da una metodologia generica. I tester simulano l'intero ciclo di vita di un attacco reale: ricognizione, accesso iniziale, persistenza, movimento laterale, escalation dei privilegi ed esfiltrazione dei dati o interruzione operativa. E testa non solo la tecnologia, ma anche le persone (il personale cade vittima del phishing?) e i processi (il SOC rileva l'intrusione? Il piano di risposta agli incidenti funziona davvero?).

Pensala in questo modo: un pentest chiede "qualcuno può entrare in questa stanza?" TLPT chiede "un avversario sofisticato può entrare nel nostro edificio, trovare la cassaforte, aprirla, prendere ciò che vuole e andarsene senza che nessuno se ne accorga?"

Fornitori ICT Terzi: non siete fuori pericolo

Una delle innovazioni più significative di DORA è il suo trattamento del rischio di terze parti ICT come una preoccupazione sistemica piuttosto che una questione contrattuale bilaterale. Se sei un fornitore di cloud, un fornitore SaaS, un servizio di sicurezza gestito o qualsiasi altra società tecnologica che serve istituti finanziari dell'UE, DORA ti raggiunge in diversi modi importanti.

Innanzitutto, le entità finanziarie devono richiedere contrattualmente ai loro fornitori di servizi ICT terzi di partecipare e collaborare con TLPT quando tali fornitori sono inclusi nello scope del test. L'articolo 30(3)(d) di DORA lo esplicita. Se la tua piattaforma cloud ospita l'infrastruttura di elaborazione dei pagamenti di una banca e tale banca è designata per TLPT, la banca deve garantire la tua partecipazione al test e tu devi agevolarla.

In secondo luogo, i fornitori ICT ritenuti critici per la stabilità del settore finanziario saranno designati come Critical Third-Party Providers (CTPP) dalle Autorità Europee di Vigilanza (ESA). I CTPP sono soggetti alla supervisione diretta delle ESA, inclusi requisiti specifici in materia di security testing, gestione del rischio e operational resilience. La prima ondata di designazioni CTPP è prevista per il 2025, a seguito delle valutazioni di criticità da parte delle ESA.

In terzo luogo, anche se non sei designato come CTPP, DORA sta rapidamente diventando un filtro di approvvigionamento. Le entità finanziarie che valutano i fornitori di tecnologia richiederanno sempre più prove di solidi programmi di security testing, la capacità di supportare simulazioni guidate dai clienti e la preparazione per il testing operativo congiunto. La non conformità non significherà solo rischio normativo, ma significherà perdere l'accesso ai clienti finanziari europei.

Se servi entità finanziarie regolamentate dall'UE, il consiglio pratico è semplice: preparati a supportare i requisiti di testing DORA dei tuoi clienti, offri ambienti di test isolati ove appropriato e sii pronto a dimostrare la tua operational resilience attraverso programmi di testing documentati.

Chi può condurre il testing?

DORA stabilisce requisiti di qualificazione specifici per i tester, in particolare per TLPT.

Testing Standard (Articoli 24–25)

Per il programma di testing annuale, DORA consente che il testing sia eseguito da team interni indipendenti o da fornitori esterni qualificati. Il requisito chiave è l'indipendenza: i tester non devono avere conflitti di interesse e non devono avere un interesse acquisito nei risultati. Se utilizzi tester interni, è richiesta un'adeguata separazione organizzativa.

Il regolamento non impone certificazioni specifiche per il testing standard, ma richiede che i tester possiedano le competenze e le conoscenze necessarie. In pratica, le autorità competenti si aspettano che i tester abbiano qualifiche professionali riconosciute ed esperienza dimostrabile nei tipi di testing che vengono condotti.

TLPT (Articoli 26–27)

Per TLPT, i requisiti sono notevolmente più severi. Il regolamento richiede che i tester siano della massima idoneità e reputazione, possiedano capacità tecniche e organizzative con competenze specifiche in threat intelligence, Penetration Testing o red team testing, siano certificati da un organismo di accreditamento in uno Stato membro o aderiscano a codici di condotta formali o framework etici e, per i tester esterni, stipulino un'assicurazione di responsabilità civile professionale contro i rischi di cattiva condotta.

Una sfumatura significativa: DORA consente ai tester interni di condurre la componente red team di TLPT, ma con due vincoli fondamentali. La threat intelligence deve sempre essere fornita da una parte esterna e ogni terzo TLPT deve essere condotto da un fornitore di red team esterno. In pratica, ciò significa che anche se crei una capacità di red team interna, avrai bisogno di tester esterni per almeno uno su tre cicli TLPT.

Remediation, Reporting e Attestazione

DORA non tratta il testing come un'attività autonoma, ma è integrato in un ciclo di miglioramento continuo. Il regolamento richiede alle entità finanziarie di stabilire procedure e politiche per dare priorità, classificare e correggere tutti i problemi rivelati dal testing e per garantire che tutte le vulnerabilità e le carenze identificate siano completamente affrontate.

Per il testing annuale standard, l'aspettativa è che il tuo programma di testing generi risultati documentati, che tali risultati vengano classificati in base alla gravità, che la remediation venga monitorata e completata e che i risultati vengano reimmessi nel tuo framework di gestione del rischio ICT. La tua documentazione deve essere disponibile alle autorità competenti su richiesta.

Per TLPT, i requisiti sono più formali. Dopo la conclusione del test, incluso l'esercizio obbligatorio di purple teaming, l'entità finanziaria e i tester esterni forniscono la documentazione all'autorità competente confermando che il TLPT è stato condotto in conformità con i requisiti di DORA. L'autorità competente convalida questa documentazione e rilascia un'attestazione. Questa attestazione può quindi essere condivisa con altre autorità competenti per consentire il riconoscimento reciproco, riducendo la necessità di testing duplicati tra le giurisdizioni.

Il meccanismo di riconoscimento reciproco è una delle innovazioni più pratiche di DORA. Se sei un'istituzione transfrontaliera che opera in più Stati membri dell'UE, una singola attestazione TLPT può soddisfare i requisiti di vigilanza in tutte le giurisdizioni, un miglioramento significativo rispetto al panorama pre-DORA in cui i framework di testing nazionali separati richiedevano test separati.

Cronologia Chiave

La cronologia è importante strategicamente. Se sei un candidato per la designazione TLPT, le prime notifiche sono previste nel 2026. La finestra di sei mesi dalla notifica alla presentazione dello scope è stretta per le organizzazioni che non hanno gettato le basi. Inizia la mappatura delle funzioni, identifica il lead del tuo team di controllo e valuta le tue opzioni di provider prima di ricevere la lettera.

Costruire il tuo programma di Testing DORA

Che tu sia un istituto di pagamento di medie dimensioni che costruisce un programma di testing da zero o un G-SII che allinea un programma esistente ai requisiti di DORA, ecco un framework pratico.

Passaggio 1: Mappa le tue funzioni critiche e importanti

Prima di poter testare qualsiasi cosa, devi sapere cosa conta. Identifica tutte le funzioni la cui interruzione comprometterebbe materialmente le prestazioni della tua entità, la continuità del servizio o la conformità normativa. Quindi mappa i sistemi ICT, le applicazioni e le dipendenze di terze parti che supportano ciascuna funzione. Questa mappatura diventa la base del tuo scope di testing e alimenta direttamente il tuo framework di gestione del rischio ICT.

Passaggio 2: Stabilisci un programma di Testing basato sul rischio

Progetta un programma di testing che copra tutti i sistemi ICT che supportano funzioni critiche o importanti, che incorpori i tipi di testing elencati nell'articolo 25 (ridimensionati in base al tuo profilo di proporzionalità), che operi almeno su un ciclo annuale e che si adatti in base a modifiche materiali alla tua infrastruttura, ai risultati di test precedenti e all'evoluzione della threat intelligence.

Documenta formalmente il programma. DORA richiede che il tuo programma di testing sia documentato, rivisto e mantenuto come parte del tuo framework di gestione del rischio ICT. Questa documentazione deve essere disponibile alla tua autorità competente su richiesta.

Passaggio 3: Coinvolgi fornitori di Testing qualificati

Per la maggior parte delle entità, i fornitori esterni di Penetration Testing forniranno la componente di testing annuale. Seleziona i fornitori che hanno dimostrato esperienza nel settore finanziario, comprendono i requisiti specifici di DORA e possono produrre report che soddisfano le aspettative normative. Assicurati che i contratti di engagement affrontino i requisiti di indipendenza, gli obblighi di riservatezza e il processo di allineamento dello scope.

Se sei un candidato per TLPT, dovrai anche identificare i fornitori di threat intelligence e i fornitori di red team che soddisfano i rigorosi requisiti di qualificazione delineati nell'articolo 27 e nel TLPT RTS. Inizia questa valutazione in anticipo: il pool di fornitori TLPT qualificati è più piccolo del mercato generale del pentest e le finestre di programmazione si riempiono rapidamente.

Passaggio 4: Costruisci il ciclo di Remediation

Il testing senza remediation è performance senza scopo. Stabilisci un flusso di lavoro documentato che porti i risultati dall'identificazione alla remediation e alla verifica. Classifica i risultati in base alla gravità, assegna la proprietà, definisci le tempistiche di risposta e monitora la chiusura. Ogni remediation deve essere verificata, tramite ritesting o tramite implementazione di controlli convalidati.

Reimmetti i risultati del tuo testing nel tuo framework di gestione del rischio ICT. DORA considera il testing come un input in un quadro di resilience più ampio, non un esercizio di conformità autonomo.

Passaggio 5: Preparati per TLPT (se applicabile)

Se è probabile che la tua entità venga designata per TLPT, la preparazione dovrebbe iniziare ben prima che arrivi la notifica. Identifica un lead del team di controllo, qualcuno abbastanza senior da gestire il test attraverso i confini organizzativi e abbastanza fidato da mantenere il segreto al blue team. Mappa le funzioni critiche che probabilmente rientreranno nello scope. Valuta le dipendenze di terze parti che potrebbero dover essere incluse. Rivedi i tuoi accordi contrattuali con i fornitori ICT per garantire che siano in atto clausole di partecipazione conformi a DORA.

Errori comuni nella conformità al Testing DORA

Trattare il Testing come una casella di controllo

L'intera filosofia di DORA è la resilience, non il teatro della conformità. I regolatori hanno progettato i requisiti di testing per garantire che le entità finanziarie possano realmente resistere agli attacchi informatici, non solo produrre report che dicono di averci provato. Se il tuo programma di testing genera risultati che non vengono mai corretti, copre i sistemi facili evitando quelli complessi o produce report che rimangono in un cassetto fino al prossimo audit, stai perdendo il punto e il regolatore se ne accorgerà.

Confondere la scansione delle vulnerabilità con il Penetration Testing

L'articolo 25 elenca sia le valutazioni e le scansioni delle vulnerabilità sia il Penetration Testing come componenti di un programma di testing. Queste sono attività distinte. La scansione automatizzata delle vulnerabilità identifica le debolezze note su larga scala. Il Penetration Testing coinvolge un tester umano qualificato che tenta attivamente di sfruttare tali debolezze, concatenarle e valutarne l'impatto nel mondo reale. Eseguire una scansione Nessus e chiamarla Penetration Testing non soddisferà DORA.

Ignorare le dipendenze di terze parti

Se le tue funzioni critiche dipendono da fornitori ICT terzi (e nei moderni servizi finanziari quasi certamente lo fanno), il tuo programma di testing deve tenere conto di tali dipendenze. Per il testing standard, ciò significa valutare la postura di sicurezza delle tue connessioni e interfacce di terze parti. Per TLPT, significa garantire contrattualmente che i tuoi fornitori parteciperanno al test. Le entità finanziarie che ignorano il rischio di terze parti nel loro scope di testing creano esattamente il tipo di punto cieco che DORA è stato progettato per eliminare.

Supporre che TLPT sia solo un Pentest più grande

L'abbiamo detto prima, ma vale la pena ripeterlo. TLPT è un'attività fondamentalmente diversa dal Penetration Testing. È guidato dall'intelligence, condotto su sistemi di produzione live, eseguito in segreto dai tuoi team di difesa, eseguito per mesi piuttosto che per settimane, richiede un purple teaming obbligatorio ed è convalidato e attestato dalla tua autorità competente. Approcciare TLPT con una mentalità da pentest (scope limitato, tempistiche brevi, focus solo tecnico) comporterà un test che non soddisfa i requisiti normativi e non fornisce informazioni significative sulla resilience.

Aspettare la notifica

Se sei un'istituzione di importanza sistemica, aspettare che la tua autorità competente ti notifichi formalmente prima di prepararti per TLPT è un errore strategico. La finestra dalla notifica allo scope è di circa sei mesi e la preparazione richiesta (mappatura delle funzioni, selezione dei fornitori, negoziazione dei contratti, formazione del team di controllo, approvvigionamento della threat intelligence) è sostanziale. Le organizzazioni che iniziano presto eseguiranno test più fluidi, genereranno risultati migliori e dimostreranno ai loro supervisori che prendono sul serio l'operational resilience.