Ambito TLPT DORA: mappare le funzioni critiche prima degli asset

La decisione che questa guida vi aiuta a prendere

Partite dalla funzione che deve mantenere la propria resilienza e ricostruite le persone, i processi, i sistemi e le dipendenze esterne a essa collegati. Registrate la copertura proposta e le esclusioni, con le relative motivazioni. L’autorità competente convalida l’ambito proposto; un fornitore non può approvarlo per suo conto.

Partite da ciò che l’organizzazione deve continuare a fare

Un ambito TLPT utile parte dalle funzioni critiche o importanti e poi individua le persone, i processi e le tecnologie che le supportano. Un inventario degli asset è un elemento di partenza, ma da solo non spiega cosa comporterebbe un’interruzione per l’azienda.

DORA richiede all’entità finanziaria di individuare i sistemi, i processi e le tecnologie ICT sottostanti pertinenti e di valutare quali funzioni debbano essere incluse. L’ambito proposto che ne deriva è convalidato dall’autorità competente. Un fornitore non può approvare tale ambito per conto dell’autorità.

Creare una mappa di funzioni e dipendenze

• Individuare la funzione e il responsabile aziendale.
• Descriva il risultato operativo che deve essere mantenuto.
• Tracciate i sistemi, le identità, i processi e i team che supportano la funzione.
• Identificare fornitori terzi di servizi TIC, servizi condivisi e dipendenze transfrontaliere.
• Registrare i confini, le ipotesi e le eventuali dipendenze che potrebbero influire sul test.

Ad esempio, una funzione legata ai pagamenti può dipendere da applicazioni, infrastruttura di identità, procedure operative e un servizio esterno. Testare soltanto l’applicazione pubblica lascerebbe inesplorata la relazione tra queste dipendenze. È uno schema illustrativo per definire l’ambito, non un’affermazione relativa all’ambiente di alcun cliente.

Rendere verificabili esclusioni e autorizzazioni

Un'esclusione proposta dovrebbe indicare perché viene proposta, quale rischio o dipendenza interessa e come sarà considerata nella progettazione dei test. Le esclusioni non motivate possono compromettere il realismo dell'esercizio.

L’autorizzazione a testare l’entità finanziaria non autorizza automaticamente attività nei confronti di terzi. Prima dell’esecuzione, chiarite i contratti, la partecipazione del fornitore, i limiti degli ambienti condivisi e i referenti. L’entità finanziaria resta responsabile di organizzare la partecipazione e il coordinamento necessari.

Collegare l’ambito alla minaccia

Le informazioni sulle minacce dovrebbero contribuire a spiegare quali avversari e percorsi di attacco siano credibili per le funzioni selezionate. Uno scenario dovrebbe avere un obiettivo significativo e un rapporto difendibile con l'esposizione dell'entità, anziché limitarsi a mostrare una tecnica.

Mantenga una relazione tracciabile tra funzione, dipendenza, ipotesi di minaccia, scenario, controllo del rischio ed evidenze attese. Ciò facilita la valutazione delle modifiche successive e aiuta i rapporti conclusivi a spiegare cosa ha dimostrato il test e cosa no.

Pianificare le modifiche controllate

Gli ambienti di produzione e le minacce cambiano. Definite chi può richiedere, riesaminare e approvare una modifica dell’ambito e quando è necessario coinvolgere le autorità. Conservate la motivazione e valutate il rischio operativo prima di adattare le attività.

Un perimetro iniziale chiaro riduce l’incertezza, ma non elimina la necessità di valutazioni professionali durante l’incarico. Utilizzi la lista di verifica della preparazione al TLPT per organizzare il primo confronto sulla definizione del perimetro.

Utilizzate valutazioni tecniche per migliorare la mappa delle dipendenze.

Una funzione critica può dipendere da identità e servizi in background facili da trascurare in un diagramma aziendale. Chiedete ai responsabili delle applicazioni e dell’infrastruttura quali identità trasferiscono dati, approvano transazioni, pubblicano release o ripristinano il servizio. Registrate il responsabile e il limite delle autorizzazioni per ogni passaggio rilevante. La mappa dovrebbe spiegare perché una dipendenza è importante per la funzione, anziché limitarsi ad aumentare il numero di sistemi inclusi nell’ambito.

La guida sull’accesso privilegiato in banca distingue tra identità, portata e autorità. La guida sulle identità dei workload cloud per il fintech estende questo ragionamento ai servizi di distribuzione e runtime. Entrambe possono contribuire alla preparazione tecnica; nessuna delle due determina l’ambito del TLPT convalidato dall’autorità competente.

Mantenere un registro decisionale per i confini complessi

Per una piattaforma condivisa o una dipendenza sensibile, documentate il trattamento proposto, il rischio operativo, il responsabile dell’autorizzazione e i limiti delle evidenze. Indicate se la dipendenza è inclusa, richiede una partecipazione coordinata o resta irrisolta. Non riducete la decisione a un colore in un diagramma. La motivazione deve restare comprensibile anche in caso di avvicendamento del personale e consentire ai responsabili dei test e al team di controllo di capire che cosa può dimostrare l’esercizio proposto.

Quando l’ambito cambia, conservare la decisione precedente e spiegare le nuove informazioni. Identificare gli scenari interessati, i controlli di sicurezza e le responsabilità del provider, quindi seguire il processo di approvazione applicabile prima di adattare l’esecuzione. In fase di chiusura, usare la stessa mappa per mostrare dove sono state raccolte osservazioni e dove permane l’incertezza. Questa continuità rende l’ambito uno strumento operativo di governance per tutta la durata dell’incarico, anziché un documento firmato una volta e poi dimenticato.

Continua la preparazione

• La metodologia dei test
• Terze parti fornitrici di servizi TIC e TLPT