DORA e outsourcing ICT: le lacune più comuni negli IMEL e come colmarle

Introduzione

Il Regolamento (UE) 2022/2554 sulla resilienza operativa digitale del settore finanziario — meglio noto come DORA (Digital Operational Resilience Act) — è pienamente applicabile dal 17 gennaio 2025. Per gli Istituti di Moneta Elettronica (IMEL), la conformità a DORA rappresenta una sfida particolarmente articolata, che si intreccia con la struttura operativa tipica di questi soggetti: fortemente dipendente da fornitori ICT terzi, spesso in regime di outsourcing ICT integrale o parziale delle funzioni tecnologiche core.

L’esperienza maturata nell’assistenza a IMEL in fase di adeguamento rivela un pattern ricorrente di lacune strutturali, che questo contributo si propone di analizzare sistematicamente, con indicazioni operative per la loro risoluzione.

1. Il perimetro dell’outsourcing ICT sotto DORA: una questione spesso sottovalutata

Il primo errore che si riscontra frequentemente è una perimetrazione incompleta dei soggetti e dei contratti rientranti nell’ambito applicativo di DORA.

DORA distingue tra fornitori di servizi ICT “critici o importanti” e fornitori ordinari, applicando obblighi differenziati. Tuttavia, molti IMEL tendono a qualificare come “non critici” servizi che invece supportano funzioni essenziali — quali la gestione dei pagamenti, l’autenticazione dei clienti, la conservazione dei dati transazionali — per il solo fatto che il fornitore è una grande piattaforma cloud o un provider affermato sul mercato.

La criticità di un servizio ICT va valutata in relazione all’impatto che la sua interruzione avrebbe sulla continuità operativa dell’ente e sulla tutela dei clienti, non in base alla reputazione del fornitore. Questa distinzione è fondamentale ai fini dell’applicazione degli obblighi di cui agli articoli 28-44 di DORA.

2. I contratti di outsourcing ICT: cosa manca (quasi sempre)

L’analisi dei contratti di outsourcing ICT degli IMEL rivela lacune ricorrenti rispetto ai requisiti minimi imposti dall’articolo 30 di DORA. In particolare:

a) Assenza di diritti di audit contrattualmente garantiti

DORA impone che i contratti con fornitori ICT critici prevedano esplicitamente il diritto dell’ente finanziario — e delle autorità competenti — di effettuare audit e ispezioni presso il fornitore. Molti contratti esistenti, stipulati prima dell’entrata in vigore del regolamento, non contengono questa previsione o la limitano in modo incompatibile con i requisiti normativi.

b) Mancanza di SLA adeguati in termini di RTO e RPO

I livelli di servizio (Service Level Agreement) devono includere obiettivi di ripristino misurabili — Recovery Time Objective (RTO) e Recovery Point Objective (RPO) — coerenti con il piano di continuità operativa dell’IMEL. La prassi contrattuale degli IMEL italiani mostra spesso SLA generici, non calibrati sulle specificità del servizio di moneta elettronica.

c) Assenza di clausole di exit strategy

L’articolo 30, paragrafo 2, lettera f), di DORA richiede che i contratti prevedano piani di uscita che consentano all’ente di migrare verso fornitori alternativi senza compromettere la continuità del servizio. Questa previsione è sistematicamente assente o formulata in termini eccessivamente vaghi.

d) Subcatena del fornitore non mappata

DORA impone la trasparenza sulla catena di subfornitura ICT. Gli IMEL devono conoscere e monitorare i sub-fornitori dei propri fornitori critici. Nella pratica, questa mappatura è spesso inesistente o aggiornata solo in sede di due diligence iniziale.

3. Il registro delle informazioni: lo strumento più trascurato

L’articolo 28, paragrafo 3, di DORA impone la tenuta di un registro dettagliato di tutti gli accordi contrattuali relativi all’uso di servizi ICT forniti da terzi. Le autorità di vigilanza — in Italia Banca d’Italia — hanno già indicato che questo registro sarà uno dei principali oggetti di verifica ispettiva.

Nella realtà degli IMEL, il registro delle informazioni ICT è frequentemente:

• assente nella forma strutturata richiesta dal regolamento
• compilato in modo incompleto, omettendo fornitori secondari o servizi cloud accessori

non aggiornato in tempo reale al variare delle relazioni contrattuali.

Le Regulatory Technical Standards (RTS) emanate dalle ESA nel 2024 specificano il contenuto minimo del registro con un livello di dettaglio molto elevato, che include la classificazione per criticità, i dati del fornitore, le giurisdizioni coinvolte e le dipendenze funzionali.

4. Il testing della resilienza operativa: i piani teorici non bastano

DORA introduce un framework articolato di test della resilienza operativa digitale (articoli 24-27), che include test di base — quali vulnerability assessment e penetration test — e, per gli enti di maggiori dimensioni, test avanzati basati sulla metodologia TLPT (Threat-Led Penetration Testing).

Per gli IMEL, la lacuna più comune non riguarda l’assenza di un piano di testing, ma la disconnessione tra il piano teorico e la realtà operativa:

• i test non coprono i sistemi dei fornitori terzi critici
• i risultati dei test non alimentano un processo formalizzato di remediation

non esiste un calendario di testing aggiornato e coerente con l’evoluzione del profilo di rischio ICT dell’ente.

5. La gestione degli incidenti ICT: notifiche e classificazione

DORA standardizza la classificazione e la notifica degli incidenti ICT gravi (articoli 17-23). Gli IMEL devono disporre di procedure documentate per la classificazione degli incidenti secondo i criteri fissati dalle RTS, e devono essere in grado di effettuare le notifiche all’autorità competente nei termini previsti — notifica iniziale entro 4 ore dalla classificazione, relazione intermedia entro 72 ore, relazione finale entro un mese.

Le lacune più frequenti riguardano:

• l’assenza di criteri di classificazione formalizzati e allineati alle RTS
• la mancata integrazione del processo di notifica con i fornitori ICT (che spesso sono i primi a rilevare l’incidente)

l’assenza di esercitazioni periodiche di risposta agli incidenti.

6. Il ruolo del management: governance e responsabilità

DORA attribuisce all’organo di gestione una responsabilità diretta e non delegabile in materia di rischio ICT (articolo 5). Questo implica che il CDA degli IMEL debba approvare la politica di rischio ICT, monitorarne l’attuazione e ricevere reportistica periodica adeguata.

Nella pratica, la governance del rischio ICT negli IMEL è spesso concentrata nelle funzioni operative, con un coinvolgimento del CDA limitato all’approvazione formale di documenti che non riflettono una reale comprensione del profilo di rischio dell’ente.

Conclusioni: un approccio integrato alla compliance DORA

La conformità a DORA non è un esercizio documentale una tantum. Richiede un approccio integrato che coinvolga la funzione legale, la funzione IT, il risk management e l’organo di gestione in un processo continuativo di valutazione e mitigazione del rischio ICT.

Per gli IMEL, il punto di partenza è una gap analysis strutturata che consenta di mappare le lacune rispetto ai requisiti del regolamento e di definire un piano di remediation prioritizzato, con particolare attenzione alla revisione dei contratti di outsourcing ICT e alla costruzione del registro delle informazioni.

ADLP Studio Legale assiste IMEL, IP e altri soggetti vigilati nella strutturazione dei processi di compliance DORA, dalla gap analysis alla negoziazione dei contratti con i fornitori ICT, fino alla predisposizione della documentazione richiesta dalle autorità di vigilanza.