Il Regolamento DORA, spiegato dagli avvocati

È pienamente applicabile dalla metà di gennaio 2025 il DORA, il Regolamento Europeo che ha l’obiettivo di creare un quadro normativo uniforme per garantire la resilienza operativa digitale del settore bancario, finanziario e assicurativo in Europa.

Abbiamo approfondito il tema dell’impatto di questo regolamento nei primi due episodi della sesta stagione di #define banking, il nostro podcast: il primo, di cui questo articolo è una versione testuale, racconta la normativa con una prospettiva legale, grazie al contributo di Valerio Vertua e Marco Tullio Giordano, avvocati e partner di 42 Law Firm.

Il secondo episodio affronta invece il tema del DORA dalla prospettiva di un esperto di tecnologia.

AG. Marco, proviamo a sintetizzare l’impatto di DORA con tre parole chiave?

MTG. La prima è resilienza, che troviamo già nel titolo della norma: Digital Operative Resilience Act. In questo senso, quindi, DORA rafforza la capacità delle istituzioni finanziarie di resistere, e rispondere, agli incidenti informatici od operativi.

La seconda keyword è “gestione del rischio”. DORA introduce una procedura operativa con requisiti stringenti per valutare anticipatamente, e gestire, il rischio tramite da un lato il monitoraggio e, dall’altro, la mitigazione dei cosiddetti rischi ICT, quelli informatici operativi.

La terza parola chiave, secondo me, è supervisione. Il controllo e il monitoraggio fanno parte del quadro normativo introdotto da DORA, che prevede impegni e obblighi di controllo e di conformità per tutte quelle entità finanziarie che utilizzano dei fornitori per l’erogazione dei propri servizi.

I fornitori, e subfornitori, che partecipano ad aspetti critici essenziali per il servizio finanziario devono essere monitorati nel corso della loro attività ed eventualmente accompagnati in un percorso per aumentare il loro grado di resilienza.

AG. La gestione del rischio informatico è un aspetto chiave: come evolverà all’interno delle banche e delle altre aziende toccate dal DORA?

VV. L’approccio basato sul rischio è ormai abituale nelle Direttive e nei Regolamenti europei. Un cambiamento si vede già dalla definizione di “rischio informatico”, che mi sembra particolarmente ampia. Si parla di qualunque circostanza ragionevolmente identificabile in relazione all’uso dei sistemi informatici di rete che, qualora si concretizzi, può comprendere la sicurezza dei sistemi informatici e di rete, eventuali strumenti o processi dipendenti da tecnologie, oppure la fornitura dei servizi.

In pratica, tutti gli aspetti tecnologici che possono causare effetti avversi nell’ambito digitale, ma anche in quello fisico.

DORA richiede quindi un approccio strutturato e continuo al rischio: “continuo” significa che non è sufficiente una compliance iniziale, ma serve adattare continuamente l’approccio e il monitoraggio alle esigenze dell’istituzione finanziaria. E serve anche implementare un quadro di test di resilienza operativa per identificare le vulnerabilità e mitigare i rischi in modo proattivo.

La normativa vuole evitare che venga sottovalutata la complessità del processo di adeguamento, specialmente per quanto riguarda la mappatura completa dei servizi ICT critici e, quindi, anche l’implementazione di sistemi di monitoraggio efficaci.

AG. Una delle keyword individuate da Marco Tullio Giordano è “supervisione”: c’è una forte attenzione alle attività di monitoraggio e agli stress test. Come si svolgeranno queste attività?

MTG. Con il DORA, l’importanza del monitoraggio continuo e degli stress test si sintetizza in due aspetti.

Il monitoraggio continuo serve a individuare in tempo reale le vulnerabilità, quasi in modo proattivo. Bisogna mantenere alto il livello di attenzione sia per prevenire incidenti informatici o violazioni di sicurezza, sia nel loro rilevamento, intercettando immediatamente eventuali anomalie operative.

Gli stress test, con attività di vulnerability assessment o di penetration test, permettono di saggiare il livello di resilienza dei sistemi e l’effettiva capacità di risposta di un ente finanziario in caso di attacco o incidente informatico.

Queste attività servono anche a mantenere elevato il livello di attenzione così da essere in grado di intervenire efficacemente in caso di effettiva necessità, analogamente a quanto si fa nelle aziende e nelle scuole con i test antincendio. Tutti devono sapere che cosa fare, ripetendo una procedura che hanno provato più volte.

AG. Abbiamo iniziato a introdurre il tema dei fornitori, sui cui il DORA introduce molte novità. Di fatto, ridisegnando il rapporto contrattuale tra loro e le banche, ma anche richiedendo la definizione di una exit strategy, cioè di un piano per interrompere il rapporto con un fornitore, passando a un altro oppure internalizzando i servizi. Che cosa sta cambiando?

VV. Rispetto ad altre normative europee, c’è una parte corposa dedicata ai contratti, un vero unicum. DORA introduce degli obblighi più stringenti nella gestione dei fornitori ITC critici, con clausole contrattuali che devono essere presenti.

Devono esserci dettagli chiari sugli SLA, sulla gestione degli incidenti e altre componenti obbligatorie.

Il contratto è, tra l’altro, un punto di arrivo. Perché la norma prevede una fase precedente, con una valutazione iniziale del tipo di servizi informatici, della tipologia di fornitore, della sua capacità di assicurare standard appropriati in materia di sicurezza informatica.

L’exit strategy serve a garantire una continuità operativa nei servizi critici, al di là dei rapporti contrattuali. Bisogna tenere conto di una serie di rischi, come disfunzioni dei fornitori stessi, il deterioramento della qualità dei servizi, problematiche commerciali e così via.

La normativa definisce delle linee guida generali per prevenire ogni tipo di tematica.

AG. C’è poi il tema dei subfornitori, su cui banche e compagnie assicurative devono comunque avere piena visibilità, secondo il DORA. Come si gestisce questo aspetto?

VV. Qui la normativa è chiara: viene richiesto un monitoraggio costante dei subfornitori. Questo vuol dire che, nella procedura che porta alla selezione di un fornitore, deve essere chiaro sin da subito se sono previsti subfornitori, di quali tipologia, se hanno caratteristiche di sicurezza adeguate e così via. E occorre tutelarsi da qualunque modifica, proprio perché lungo la filiera non possono esserci zone d’ombra.

AG. Un altro punto relativo ai fornitori è quello del rischio di dipendenza da uno o pochi fornitori, sia a livello di singola banca sia come settore nel suo complesso. Penso, ad esempio, all’importanza delle BigTech americane nella fornitura di servizi cloud. Come si gestisce il rischio di dipendenza?

VV. La normativa tiene bene in considerazione questo rischio potenziale. Le entità finanziarie devono vagliare in maniera adeguata i benefici e i costi, così come le soluzioni alternative: sono costrette a optare per l’unico fornitore, oppure ce ne sono altri che possono offrire lo stesso servizio?

La normativa prevede anche che le autorità europee di vigilanza identifichino i fornitori critici a livello di sistema, in modo da potere imporre loro delle misure specifiche per mitigare eventuali rischi.

AG. Un altro aspetto chiave è il rischio informatico tollerato, che va commisurato al business svolto da ciascuna realtà finanziaria. Ci sono realtà fintech attive nel trading o nei criptoasset che devono garantire una operatività continua ai loro clienti. La sfida del DORA, per il mondo Fintech, è particolarmente forte?

MTG. La tolleranza al rischio deve essere proporzionata al tipo di business, alla complessità e alla criticità delle operazioni svolte da un’azienda. In questo senso i cripto asset service provider (CASP), quindi le piattaforme che permettono lo scambio di valute virtuali, hanno un grande vantaggio competitivo sulle borse tradizionali: attirano sempre più investitori e sono sempre operative, 24 ore su 24, tutto l’anno.

Non chiudono mai, a differenza delle Borse tradizionali. Ma buona parte di queste attività sono poco più che startup, sono partite focalizzandosi su aspetti operativi e di mercato. Non sono quindi così mature nella business continuity, nel disaster recovery e forse, più in generale, nella sicurezza informatica.

DORA, insieme ad altre misure del Digital Finance Package, aiuterà queste aziende a crescere. Penso al MICAR, che impone obblighi per i CASP, o al Transfer Found Regulation, che gli impone ulteriori obblighi nel settore dell’antiriciclaggio.

Queste normative accompagneranno queste aziende nella loro maturazione e nella loro crescita. Il banking tradizionale ha avuto secoli per diventare ciò che è oggi, mentre il Fintech sta bruciando le tappe.

AG. Torniamo sugli stress test: come si svolgono e chi coinvolgono all’interno delle banche e dei fornitori?

VV. La normativa individua una serie di valutazioni, test, metodologie e pratiche di primo livello, e altri invece che possiamo definire avanzati.

Nella prima categoria troviamo valutazione, scansione delle vulnerabilità, analisi open source, la valutazione della sicurezza, un’analisi della carenza, la valutazione della sicurezza fisica, questionari, soluzioni di scansione del software, una serie di esami anche del codice sorgente, dove sia fattibile.

E poi, ancora, test basati su scenari, test di compatibilità di prestazione, eccetera.

Tra gli strumenti avanzati, troviamo invece test di penetrazione basati su minacce con cadenza almeno triennale, quindi qualcosa di molto più forte. Qui i fornitori ICT vengono coinvolti direttamente, specie se erogano servizi critici. E qui l’Autorità di Vigilanza può imporre una partecipazione obbligatoria a questi test. Alcuni fornitori critici, poi, devono a loro volta effettuare dei test di penetrazione contro varie minacce.

AG. Che cosa succede, operativamente, in caso di un attacco o di un evento significativo?

MTG. Bisogna seguire un approccio strutturato, a cui si è pensato a monte. Le azioni che vengono richieste sono finalizzate a tre obiettivi:

• mitigare immediatamente il danno;
• ripristinare le operazioni;
• garantire la conformità normativa.

Come si ottengono questi obiettivi? Con tre fasi. La prima è il rilevamento dell’incidente e il suo contenimento immediato. Va quindi attivato il piano di risposta di cui parlavamo poco fa, e che dovrebbe essere stato metabolizzato dall’azienda.

Si vanno a isolare i sistemi compromessi e a fare una raccolta delle prime evidenze, per determinare la natura dell’attacco e identificare le vulnerabilità che sono state sfruttate per sferrarlo.

Una volta che si hanno queste informazioni, bisogna pensare ai passi regolamentari imposti dal DORA, come la notifica e la comunicazione. Il Regolamento amplifica gli obblighi di segnalazione che troviamo in normative come il GDPR. I vari dipartimenti devono immediatamente contattare il team di sicurezza, senza perdere tempo.

E, a quel punto, va effettuata la notifica alle autorità competenti: uso il plurale, perché ci sono diversi attori istituzionali. In Italia, Banca d’Italia e le autorità di cyber security, come ACN e i cosiddetti CSIRT, i centri di risposta agli incidenti informatici. Se l’attacco ha riguardato i dati di individui, bisogna inviare una comunicazione ai clienti e alle parti interessate, come accade per il GDPR.

E poi bisogna intervenire per mitigare il danno, applicando misure di contenimento e ripristinando i sistemi e i servizi critici, garantendo la cosiddetta business continuity.

Ecco, fatto tutto questo e ripristinato il servizio, ci si può concentrare sull’analisi post mortem. E analizzare quei dati che sono stati raccolti nella fase di rilevamento, per capire cosa non ha funzionato e andare poi ad aggiornare e migliorare sia i sistemi, sia le strategie di sicurezza. Per scongiurare il ripetersi di quell’evento in futuro.

AG. Negli ultimi anni abbiamo visto attacchi clamorosi contro grandi aziende e istituzioni pubbliche. E sappiamo che queste violazioni non sono così semplici da individuare e, una volta scoperte, ricostruirne le dinamiche richiede tempo. I tempi di reazione sono molto più lenti, rispetto alla rapidità con cui un attacco viene sferrato. Il DORA introduce però dei requisiti stringenti già a 4 e a 72 ore, e prevede poi un report finale dopo un mese. Queste tempistiche sono realistiche e sostenibili per le aziende?

VV. Sono requisiti davvero stringenti, quelli a 4 e 72 ore, non c’è tempo da perdere. La norma chiede uno sforzo ben preciso da parte delle banche e degli istituti in generale, perché devono adottare delle procedure concrete.

Non basta definire una procedura che resta su carta, ma devo verificare quella procedura, facendo delle simulazioni sulla loro capacità di potere rispettare queste scadenze in caso di incidente. È una questione di efficienza ed è evidente un qualcosa a cui la banca deve pensare con ampio anticipo.

AG. Alcuni clamorosi attacchi portati a termine in passato hanno colpito aziende finanziarie o dei pagamenti, sfruttando una falla di sicurezza di un fornitore. Di chi è la responsabilità in questo caso?

MTG. Le regole del DORA sono molto chiare: la responsabilità non può che ricadere in prima battuta sull’ente finanziario, che viene chiamato a responsabilizzarsi non solo per la propria attività, ma anche per quella dei fornitori.

DORA introduce un obbligo di valutazione e monitoraggio anche dei rischi legati ai propri fornitori critici nel settore informatico e, oltre alla valutazione e monitoraggio dei rischi, introduce un obbligo di contrattualizzare i fornitori in modo che includano clausole specifiche sulla sicurezza e sulla continuità operativa.

L’obbligo di monitorare l’attività del fornitore perdura per l’intero rapporto contrattuale. E l’ente finanziario deve comunque prevedere dei piani di emergenza per garantire la business continuity nei casi in cui un fornitore sia colpito da un attacco.

Ciò non toglie che il fornitore critico, come un cloud provider, sia responsabile in maniera solidale. Posso fare qualche altro esempio: i data center che ospitano i sistemi dell’ente finanziario, o i servizi di cyber security che certificano e garantiscono la resilienza operativa di un fornitore ICT, non sono esenti da responsabilità e devono garantire standard di sicurezza adeguati.

Queste realtà non posso sottacere qualsiasi tipo di evento che potrebbe impattare sull’operatività dei loro clienti finanziari e devono sottoporsi a vari controlli di sicurezza. Le autorità finanziarie e di monitoraggio possono intervenire direttamente su un fornitore, chiedendogli modifiche alla operatività o, nel caso peggiore, vietandogli di operare nei confronti di enti finanziari.

AG. La segnalazione alle autorità è un atto obbligatorio, almeno nei casi significativi. C’è il rischio che venga considerata un segno di debolezza, anziché una dimostrazione di essere in grado di monitorare i propri sistemi e di accorgersi che qualcosa non va?

VV. Lo spirito della norma è che la notifica sia un obbligo di legge, perché dimostra una reale attenzione al tema della sicurezza da parte dell’ente informatico. Infatti, il DORA prevede anche una notifica volontaria, quindi una dimostrazione di maturità nella gestione della resilienza.

Il Regolamento è improntato sulla capacità di comprendere che si è sotto attacco, serve una struttura tecnico-organizzativa e procedurale proprio per adattarsi a questa richiesta del DORA.

Un ente finanziario potrebbe provare una certa ritrosia a emettere una segnalazione, perché teme eventuali sanzioni da parte dell’autorità. Vista l’importanza sistemica della condivisione dei dati, però, sarebbe utile avere certezza che non c’è un automatismo tra segnalazione e sanzione.

AG. Un ultimo commento proprio sulla condivisione delle informazioni, che va nella direzione di creare un effetto network: se l’intero settore finanziario segue le stesse regole e fa sistema nella condivisione delle informazioni, nel complesso dovrebbe essere più forte. Sarà proprio così o ci sono degli ostacoli culturali o tecnologici?

MTG. L’effetto network e la standardizzazione sono tra gli obiettivi di DORA più difficili da raggiungere. I vantaggi sono innegabili: condividere informazioni su minacce e vulnerabilità, allargando il bacino di conoscenza delle aziende che possono lavorare insieme per anticipare i rischi, anziché mitigarli.

Le campagne dei criminali informatici sono spesso rivolti a più enti. Avere una segnalazione da parte del primo a subire un attacco potrebbe aiutare l’intero settore a stare in allerta e mitigare il rischio.

Se si standardizza la sicurezza ICT con delle regole comuni si individuano più facilmente i punti deboli del sistema e i fornitori potranno lavorare sui medesimi controlli, particolarmente rigorosi.

L’esperienza dell’open banking, però, ci ha dimostrato che le banche continuano a pensare che fare da sé sia un vantaggio, senza condividere i propri segreti, anche operativi, con altri.

L’ostacolo maggiore mi sembra quindi il mindset del settore, che dovrebbe orientarsi verso il bene comune anziché innalzare barriere informative e tecnologiche.

C’è un altro aspetto che riguarda la standardizzazione dei servizi ICT. Se tutte le entità utilizzano gli stessi sistemi, una vulnerabilità diventa un punto di accesso nei confronti di tutti gli enti.

Siamo quindi a un bivio tra condivisione della knowledge, da un lato, o una personalizzazione che lasci comunque un margine di autonomia ai vari player.