Preparazione al DORA per entità finanziarie e fornitori ICT

Il DORA, il regolamento (UE) 2022/2554 relativo alla resilienza operativa digitale per il settore finanziario, si applica dal 17 gennaio 2025. Per le entità finanziarie, essere preparati significa oggi mantenere un modello operativo per la resilienza operativa digitale, non prepararsi a una scadenza futura. Per i fornitori di tecnologia, significa comprendere le responsabilità nei confronti dei clienti e capire se si applica un distinto regime di sorveglianza diretta.

La domanda per il vertice è pratica: l'organizzazione è in grado di spiegare quali servizi finanziari dipendono da quali sistemi ICT, come verrà gestita un'interruzione e quali evidenze supportano le ipotesi di ripristino? Le policy contano, ma da sole non possono rispondere a questa domanda. La direzione ha bisogno di una visione collegata di responsabilità, dipendenze, contratti, test, incidenti e rischi non risolti.

Determinare il proprio ruolo prima di costruire la checklist

Partite da una decisione documentata sull'applicabilità per ciascuna entità giuridica pertinente. L'articolo 2 del DORA individua le categorie coperte e le esclusioni. Un'impresa che si definisce FinTech, startup o PMI non rientra automaticamente nell'ambito di applicazione né ne è automaticamente esclusa.

Tra gli esempi di entità finanziarie coperte figurano enti creditizi, istituti di pagamento, imprese di investimento e imprese di assicurazione, fatte salve le norme dettagliate del regolamento sull'ambito di applicazione. Registrate la categoria applicabile, eventuali esclusioni o esenzioni, l'autorità competente e il ragionamento alla base della conclusione.

Per i fornitori, distinguete tre posizioni:

Un fornitore che supporta una funzione finanziaria essenziale o importante non è, per questo solo motivo, un fornitore terzo critico di servizi ICT designato. Le entità finanziarie valutano l'importanza delle proprie funzioni e dipendenze; la designazione dei fornitori critici avviene attraverso il quadro di vigilanza previsto dall'articolo 31.

La sede non risolve la questione del fornitore. Un provider cloud o di software con sede negli Stati Uniti può trovarsi di fronte a requisiti dei clienti legati al DORA quando serve entità finanziarie dell'UE. Questo rapporto commerciale non lo assoggetta automaticamente a ogni obbligo imposto a un'entità finanziaria.

Anche la proporzionalità richiede una valutazione motivata. L'articolo 4 considera fattori quali le dimensioni, il profilo di rischio complessivo e la natura, la portata e la complessità dei servizi. L'articolo 16 prevede un quadro semplificato per la gestione dei rischi ICT per determinate categorie. Non si tratta di concetti intercambiabili, e il normale status di PMI non è una scorciatoia universale. Conservate l'analisi dei requisiti di ammissibilità insieme alla decisione sull'ambito di applicazione.

Rendere visibile la responsabilità della direzione

Ai sensi dell'articolo 5 del DORA, l'organo di gestione ha la responsabilità ultima della gestione dei rischi informatici dell'entità finanziaria. Delegare l'attuazione a un CISO, a un team tecnologico o a un fornitore esterno non trasferisce tale responsabilità.

Il vertice dovrebbe stabilire chi propone le decisioni, chi le approva e chi verifica che l'attuazione funzioni. Il modello operativo dovrebbe coprire continuità operativa, risposta agli incidenti e ripristino, accordi con terzi, budget e le conoscenze necessarie per una supervisione effettiva.

Una raccomandazione pratica è fornire alla direzione un pacchetto di reporting orientato alle decisioni invece di una dashboard con percentuali di completamento. Includete:

• Funzioni essenziali o importanti con ipotesi di ripristino non testate.
• Incidenti rilevanti, effetti sui clienti e azioni correttive in sospeso.
• Dipendenze da fornitori con contratti incompleti o opzioni di uscita deboli.
• Lacune significative nei controlli, responsabili e date di correzione.
• Decisioni che richiedono finanziamenti, un cambio di fornitore o una risposta esplicita al rischio.

Ogni lacuna dovrebbe distinguere il requisito normativo, la debolezza operativa attuale e il rimedio proposto. Un registro di approvazione mancante è cosa diversa da un backup che non può essere ripristinato. Entrambi possono richiedere un intervento, ma con responsabili e priorità diversi.

L'approvazione di un piano di correzione da parte della direzione non autorizza a rinviare indefinitamente gli obblighi applicabili. Quando una lacuna è rilevante, valutate misure di salvaguardia immediate, l'escalation ed eventuali implicazioni di vigilanza insieme alla soluzione di lungo periodo.

Costruire il programma attorno alle funzioni finanziarie

Un inventario degli asset è necessario, ma la pianificazione della resilienza dovrebbe partire dal servizio che deve continuare a funzionare. Identificate la funzione finanziaria, il suo responsabile di business, le conseguenze di un'interruzione e i sistemi e i fornitori che la supportano.

Per un servizio di pagamento, mappate identità, infrastruttura cloud, elaborazione delle transazioni, monitoraggio ed escalation verso i fornitori. Includete dipendenze meno visibili come DNS, connettività, accessi privilegiati, chiavi di cifratura e strumenti di supporto. Un ambiente di produzione alternativo può risultare inutilizzabile se dipende dallo stesso servizio di identità guasto.

La mappa risultante dovrebbe collegare ciascuna funzione a:

• Applicazioni, infrastruttura, asset informativi e servizi esterni di supporto.
• Contratti pertinenti e responsabili dei servizi.
• Obiettivi di ripristino e l'analisi d'impatto sul business che li sostiene.
• Dispositivi di rilevamento, risposta, ripristino e comunicazione.
• Test, risultanze e rischi di dipendenza non risolti.

Convalidate la mappa con i team operativi e di business. I registri degli acquisti mostrano che cosa è stato acquistato; non mostrano necessariamente come un servizio funziona oggi.

Utilizzate questo modello per organizzare la gestione dei rischi ICT, la gestione e la segnalazione degli incidenti, i test di resilienza e il rischio derivante da terzi fornitori di servizi ICT. Il DORA contiene anche disposizioni sulla condivisione volontaria di informazioni sulle minacce informatiche. Se partecipate, definite adesione, riservatezza, uso consentito e regole di gestione, invece di trattare la condivisione come uno scambio illimitato di dati sugli incidenti.

Trasformare la gestione dei rischi ICT in lavoro finanziato

Le disposizioni del DORA sulla gestione dei rischi ICT coprono identificazione, protezione e prevenzione, individuazione, risposta e ripristino, apprendimento e comunicazione. Il quadro deve collegare queste attività invece di lasciarle come raccolte separate di policy.

Avviate la gap analysis dalle funzioni mappate. Chiedetevi se i controlli degli accessi proteggono i relativi sistemi, se le vulnerabilità vengono affrontate, se le modifiche sono controllate, se le attività sospette vengono rilevate e se i meccanismi di ripristino riflettono guasti realistici. Considerate i guasti tecnici e gli errori operativi oltre agli attacchi malevoli.

Per ogni debolezza rilevante, create un registro di correzione che contenga un responsabile, l'impatto sul business, l'azione richiesta, i criteri di completamento e le evidenze della chiusura. Le dipendenze contano: migliorare le procedure di ripristino può richiedere modifiche all'accesso ai backup, agli impegni dei fornitori e alla formazione del personale prima che sia possibile un test riuscito.

Gli obiettivi di ripristino dovrebbero derivare dalle esigenze di business e dall'analisi d'impatto, non da ciò che il livello di servizio standard di un fornitore offre. Quando la capacità tecnica non è in grado di raggiungere l'obiettivo, la direzione deve decidere se migliorare l'architettura, modificare l'accordo di servizio o riconsiderare il modello operativo. Un obiettivo scritto in un piano di continuità non è una prova di ripristinabilità.

Preparare le decisioni sugli incidenti prima dell'interruzione

Il DORA impone alle entità finanziarie di gestire gli incidenti connessi alle TIC e di segnalare i gravi incidenti all'autorità competente. Gli articoli da 17 a 23 stabiliscono il quadro; le norme tecniche di regolamentazione e di attuazione applicabili forniscono criteri di classificazione, soglie, contenuti delle segnalazioni e procedure dettagliati.

Non affidatevi a una checklist generica sugli incidenti per il calendario dettagliato delle segnalazioni. Mantenete una matrice di segnalazione aggiornata che identifichi le norme applicabili, le istruzioni dell'autorità, il canale di invio, le fasi della segnalazione e il calcolo delle scadenze. Assegnate a qualcuno la responsabilità di tenerla aggiornata.

Il processo di risposta dovrebbe rendere eseguibili sotto pressione diverse decisioni:

• Chi registra le marcature temporali di rilevamento, valutazione e classificazione?
• Chi ottiene le informazioni sull'impatto dalle funzioni operative e dai fornitori?
• Chi decide se i criteri di grave incidente sono soddisfatti?
• Chi approva e invia le segnalazioni, anche fuori dal normale orario di lavoro?
• Chi gestisce la comunicazione con i clienti e le altre notifiche applicabili?

Registrate il ragionamento della classificazione anche quando un incidente non viene segnalato come grave. Un quadro iniziale incompleto dovrebbe portare a una nuova valutazione man mano che le informazioni si sviluppano, non al presupposto permanente che l'evento sia di lieve entità.

Gli impegni di notifica dei fornitori dovrebbero lasciare all'entità finanziaria tempo sufficiente per valutare e adempiere i propri obblighi. Le attività di segnalazione possono essere esternalizzate ove consentito, ma la responsabilità resta in capo all'entità finanziaria.

Quando un grave incidente connesso alle TIC incide sugli interessi finanziari dei clienti, il DORA impone alle entità finanziarie di informare tali clienti senza indebito ritardo dell'incidente e delle misure adottate per attenuarne gli effetti negativi. Valutate separatamente gli obblighi relativi alle violazioni dei dati personali e le altre norme applicabili. Una sola interruzione può generare diverse decisioni di notifica, con destinatari e criteri giuridici diversi.

Testare le ipotesi su cui fa affidamento la direzione

Un programma di test di resilienza operativa digitale dovrebbe essere proporzionato e basato sul rischio. Valutazioni delle vulnerabilità, esercitazioni su scenari, test di sicurezza e test di ripristino rispondono a domande diverse; nessuno di essi dovrebbe essere considerato un sostituto universale degli altri.

Un'esercitazione da tavolo può stabilire se i decisori comprendono l'escalation. Non può dimostrare che i dati delle transazioni possano essere ripristinati con precisione. Un penetration test può far emergere debolezze sfruttabili senza dimostrare che un fornitore alternativo sia in grado di subentrare in un servizio.

Per ogni test, definite la funzione, lo scenario, il perimetro, i criteri di successo, i requisiti di indipendenza ove previsti e le evidenze attese. Conservate risultati, risultanze, decisioni di correzione ed esiti dei nuovi test. Verificate i requisiti di copertura e frequenza applicabili rispetto al DORA e alle norme pertinenti, comprese eventuali esenzioni o disposizioni del quadro semplificato.

I test di penetrazione guidati dalla minaccia (TLPT) sono un requisito di vigilanza distinto, previsto dall'articolo 26 per determinate entità finanziarie. Non costituiscono un obbligo generalizzato per ogni impresa finanziaria o fornitore ICT.

La direzione dovrebbe esaminare le ipotesi che si sono rivelate errate, non solo verificare se i test sono stati svolti. Se un'esercitazione rivela che il ripristino dipende da un unico amministratore non disponibile, l'esito è un rischio operativo che richiede un intervento, non una tappa di test completata.

Trattare il rischio legato ai terzi come una questione di continuità del servizio

Ai sensi del DORA, un'entità finanziaria resta responsabile dei propri obblighi quando si avvale di fornitori ICT. Gli articoli da 28 a 30 collegano valutazione del rischio legato ai terzi, accordi contrattuali, monitoraggio e pianificazione dell'uscita.

Mantenere il registro e il quadro operativo

Le entità finanziarie devono mantenere un registro delle informazioni relative agli accordi contrattuali per l'utilizzo di servizi ICT ai livelli richiesti: individuale, subconsolidato e consolidato. Per la sua struttura, utilizzate le norme tecniche di attuazione applicabili. Un foglio di calcolo degli acquisti o un elenco di fornitori approvati non è automaticamente sufficiente.

Riconciliate il registro con i contratti, la titolarità dei servizi e le mappe delle dipendenze. Mantenete le distinzioni richieste per i servizi che supportano funzioni essenziali o importanti. Un nuovo subappaltatore, una nuova sede del servizio o un ambito esteso possono cambiare il quadro dei rischi anche quando il nome del fornitore resta lo stesso.

Rivedere i contratti rispetto al servizio effettivo

Valutate i requisiti contrattuali applicabili, tra cui descrizione dei servizi, ubicazioni, protezione dei dati, accesso ai dati e loro recupero, assistenza in caso di incidente, cooperazione, diritti di risoluzione e livelli di servizio. Gli accordi che supportano funzioni essenziali o importanti richiedono disposizioni aggiuntive, tra cui quelle pertinenti su reporting, continuità, accesso, ispezione, audit e uscita.

I responsabili legali, degli acquisti, della tecnologia e del business dovrebbero esaminarli insieme. Un diritto di audit contrattuale può essere difficile da esercitare nella pratica; un meccanismo di ripristino promesso può non coprire l'intera catena di servizio del cliente. Individuate questi limiti prima di accettare l'accordo.

Esaminare la concentrazione e la capacità di uscita

Il rischio di concentrazione non si limita all'acquisto di più servizi da un'unica società. Fornitori diversi possono dipendere dalla stessa piattaforma cloud, dalla stessa regione, dalla stessa rete o dallo stesso subappaltatore. Valutate la sostituibilità, la complessità della migrazione e le conseguenze di un guasto comune.

Un piano di uscita dovrebbe affrontare formati dei dati, estrazione, accesso, dipendenze della migrazione, supporto alla transizione, cancellazione e continuità durante il trasferimento. Per le funzioni essenziali o importanti, trattate il test e il riesame della strategia di uscita come un lavoro sostanziale, non come un esercizio di redazione documentale.

I fornitori possono predisporre un pacchetto di garanzie coerente che contenga perimetro del servizio, confini delle responsabilità, contatti per gli incidenti, evidenze di continuità, informazioni sui subappalti e posizioni contrattuali. I requisiti specifici dei clienti richiedono comunque un riesame; un certificato non li sostituisce.

Capire dove si incontrano DORA e NIS2

Il DORA è un regolamento UE direttamente applicabile. La NIS2 è una direttiva attuata tramite il diritto nazionale, la cui applicabilità dipende da settore, dimensioni, servizio e criteri di inclusione. Il termine per il recepimento nazionale era il 17 ottobre 2024; le organizzazioni devono esaminare l'attuazione nazionale applicabile invece di presumere un unico regime operativo identico.

L'articolo 1, paragrafo 2, del DORA, insieme all'articolo 4 della NIS2, stabilisce il rapporto settoriale per le entità finanziarie coperte negli ambiti pertinenti. Non interpretatelo come un'istruzione a duplicare controlli equivalenti di gestione dei rischi e di segnalazione degli incidenti. Allo stesso modo, non presumete che elimini gli obblighi per ogni società di un gruppo finanziario o della sua catena di fornitura.

Un fornitore di servizi gestiti che serve una banca può avere bisogno di una propria valutazione NIS2 pur rispettando impegni contrattuali legati al DORA. Una matrice degli obblighi per singola entità dovrebbe registrare la base giuridica, l'ambito, l'autorità, il canale di segnalazione e le evidenze richieste.

I controlli condivisi possono supportare DORA, ISO 27001, obblighi privacy e garanzie verso i clienti quando perimetro ed evidenze coincidono. Riutilizzate una revisione degli accessi o un test di ripristino quando supporta realmente più requisiti, preservando i dettagli specifici del settore finanziario. Un certificato ISO 27001 non dimostra la conformità al DORA.

Anche l'applicazione delle norme è diversa. I poteri di vigilanza e le sanzioni nei confronti delle entità finanziarie dipendono dalle disposizioni del DORA e dalle misure nazionali applicabili; i fornitori critici designati sono soggetti a un regime di sorveglianza distinto. Non basate la pianificazione del budget per il rischio su una presunta sanzione DORA universale. Valutate l'esposizione giuridica pertinente e le conseguenze operative di una resilienza inadeguata.

Esempio pratico: il riesame delle dipendenze di un servizio di pagamento

Consideriamo, a titolo illustrativo, un istituto di pagamento che utilizza una piattaforma cloud, un provider di identità e un servizio di monitoraggio esternalizzato. Supponiamo che l'istituto rientri nell'ambito di applicazione del DORA e che l'esecuzione dei pagamenti sia classificata come funzione essenziale o importante.

Il primo riesame individua tre debolezze: gli ambienti di produzione e di ripristino condividono la stessa dipendenza dal servizio di identità; il processo di escalation degli incidenti del fornitore di monitoraggio non è chiaro; e il piano di uscita dal cloud elenca un provider alternativo senza dimostrare l'estrazione e la migrazione dei dati.

La direzione commissiona tre pacchetti di lavoro collegati:

Il responsabile di business verifica se gli obiettivi di ripristino dei pagamenti restano raggiungibili. La compliance verifica che le procedure di segnalazione e le voci del registro riflettano gli accordi. La direzione approva i finanziamenti necessari ed esamina i limiti residui.

Questo esempio non dimostra di per sé la conformità. Mostra come una sola funzione possa far emergere decisioni che resterebbero nascoste in checklist separate su policy, fornitori e test.

Stabilire un ritmo di riesame basato sulle evidenze

Il DORA non prevede alcun processo di certificazione universale che sostituisca gli obblighi continuativi. Una garanzia indipendente può informare la direzione, ma la preparazione deve essere dimostrata attraverso controlli operativi, registri e, ove richiesto, il dialogo con le autorità di vigilanza.

Un passo successivo concreto è scegliere una funzione essenziale o importante e raccoglierne la decisione sull'ambito di applicazione, la mappa delle dipendenze, la valutazione del rischio, i contratti, le procedure sugli incidenti, i risultati dei test e le azioni aperte. Verificate se questi registri raccontano una storia coerente.

Secani supporta questo flusso di lavoro modellando sistemi e servizi, collegando le dipendenze e mantenendo nel loro contesto requisiti, evidenze, responsabili, attività e decisioni di riesame. Caricate il materiale esistente sugli oggetti pertinenti, trasformate le lacune in lavoro assegnato e mantenete un'approvazione umana esplicita per i suggerimenti e le conclusioni generati con l'aiuto dell'IA.

Estendete il lavoro a partire da quella prima funzione quando responsabilità e percorsi delle evidenze sono chiari. Il vertice dovrebbe poter vedere che cosa è stato dimostrato, che cosa resta incerto e quale decisione è necessaria come passo successivo.