In seguito all’effettiva entrata in vigore del Regolamento DORA, avvenuta il 17 gennaio dello scorso anno, le entità finanziarie a cui la normativa è rivolta si sono trovate alle prese con le sfide legate alla messa a terra della compliance operativa del regolamento. Il Regolamento europeo DORA (Digital Operational Resilience Act) è stato elaborato con l’obiettivo di stabilire standard rigorosi per la gestione del rischio informatico, la segnalazione degli incidenti e la continuità operativa per le financial entities su scala europea, delineando un approccio armonizzato e uniforme. La natura principle-based dello strumento lascia però ampi margini di interpretazione, che in questo primo anno di accoglimento hanno posto i soggetti interessati in uno stato di incertezza applicativa su diversi aspetti.
Una prima grande evidenza che sta emergendo dalla pratica operativa del DORA è che il regolamento introduce un cambio di paradigma soprattutto culturale prima ancora che tecnologico. Il Regolamento infatti richiede alle entità finanziarie di ripensare radicalmente il modo in cui percepiscono e gestiscono il rischio informatico. Grande elemento distintivo del DORA è in particolare il coinvolgimento diretto dell’organo di governance nella gestione del rischio ICT, per cui l’articolo 5 stabilisce responsabilità precise e non delegabili per il board aziendale. L’organo di gestione deve infatti oggi approvare, supervisionare e assumersi la responsabilità finale del framework di gestione del rischio ICT. Questo comporta che le figure direttive devono possedere conoscenze sufficienti a comprendere e valutare i rischi informatici e il loro possibile impatto sull’operatività dell’azienda. Una comprensione che deve essere reale, ragion per cui molte organizzazioni nel mondo delle entità finanziarie stanno implementando programmi di formazione specifici per il board, che includono sessioni specifiche con simulazioni di scenari di crisi cyber, analisi di casi reali di attacchi informatici e incidenti nel settore finanziario e sessioni di war gaming, volte a mettere il board davanti a decisioni strategiche in condizioni di stress.
Il DORA introduce inoltre un ulteriore requisito organizzativo: le entità diverse dalle microimprese devono attribuire la responsabilità della gestione del rischio ICT a una funzione di controllo indipendente (art. 6, par. 4). Questo aspetto si è rivelato particolarmente delicato, poiché il regolamento non indica una specifica collocazione organizzativa per tale funzione. In merito è intervenuta la Banca d’Italia, precisando che la scelta della collocazione non deve in alcun modo compromettere l’efficace svolgimento dei compiti assegnati alla funzione di controllo ICT. Nella pratica della compliance al DORA stanno progressivamente emergendo diversi modelli organizzativi: alcuni soggetti hanno istituito una funzione autonoma dedicata, altri hanno integrato i relativi compiti nell’ambito del risk management, mentre altre realtà li hanno ricondotti alla funzione di compliance. È importante sottolineare che la funzione di controllo ICT non può essere attribuita alla struttura che svolge l’internal audit, al fine di evitare possibili conflitti di interesse. Nel complesso, il criterio da seguire non pertiene tanto la collocazione formale della funzione, quanto la sua indipendenza, le competenze disponibili e la sua capacità di dialogare in maniera proficua sia con i team tecnici che con i vertici in azienda.
Altro ambito in cui il divario tra forma e sostanza applicativa del DORA rischia di essere ampio riguarda poi i Test di resilienza operativa digitale, la cui tassonomia all’articolo 25 include test di vulnerabilità e scansioni, analisi open source, valutazioni di sicurezza di rete, gap analysis, esami di sicurezza fisica, questionari e soluzioni software di scansione, penetration test basati su sorgenti e, infine, Threat-led penetration testing (TLPT). Questi ultimi devono in particolare essere condotti almeno ogni tre anni da parte delle entità finanziarie di maggiori dimensioni. Nella pratica per la compliance al Regolamento, molti soggetti del settore hanno quindi dovuto constatare che i penetration test condotti negli anni precedenti, anche se corretti nella forma, erano poco utili nel rivelare l’effettiva capacità dell’azienda di resistere e reagire a situazioni di stress tecnologico significativo. In particolare, quindi, il TLPT viene definito dal DORA non come un semplice test tecnico, ma come una simulazione avanzata che mima tattiche, tecniche e procedure di threat actor reali. Ciò richiede dunque il ricorso a una threat intelligence che sia aggiornata e sempre fornita da un soggetto esterno, e l’utilizzo di tester qualificati capaci di ragionare come veri hacker. Questo richiede dunque di applicare un approccio di attacco che non sia volto solo a testare la tenuta dei sistemi di sicurezza informatica adottati, ma anche le capacità di detection, response e recovery dell’organizzazione nel suo insieme. Il DORA consente quindi anche l’utilizzo di tester interni, a condizione che questi siano approvati dall’autorità competente e che sia garantita l’assenza di conflitti d’interesse. Inoltre, ogni terzo test deve essere comunque condotto mediante ricorso a tester esterni.
Infine, un elemento centrale della conformità al DORA riguarda la corretta classificazione degli incidenti ICT. L’articolo 18 individua sei criteri che le entità finanziarie devono applicare per stabilire se un incidente debba essere qualificato come “major” e, quindi, notificato alle autorità competenti.
I criteri prevedono soglie quantitative e qualitative riferite a: il numero di clienti o controparti finanziarie coinvolte; la durata e la persistenza dell’incidente o dell’interruzione del servizio, considerata un indicatore chiave; l’estensione geografica dell’impatto in relazione alle attività dell’entità; le perdite o compromissioni di dati — inclusa qualsiasi violazione di integrità, disponibilità, riservatezza o autenticità, anche relativa a un singolo dato sensibile — e, infine, l’impatto economico, comprensivo dei costi diretti e indiretti, effettivi o potenziali, derivanti dall’evento.
Il superamento anche di una sola di queste soglie può determinare la classificazione dell’incidente come major, e molte organizzazioni finanziarie stanno implementando sistemi di scoring automatizzati in grado di valutare in tempo reale gli incidenti sulla base dei sei criteri sopra indicati. Sistemi che si rivelano preziosi per consentire una rapida presa di decisione sulla necessità di segnalazione alle autorità di vigilanza competenti, ripensando così i processi interni di incident response. Le tempistiche di segnalazione previste dal DORA sono particolarmente stringenti: è richiesta una segnalazione iniziale entro quattro ore dalla classificazione dell’incidente e comunque non oltre 24 ore dalla sua identificazione; una relazione intermedia entro 72 ore dalla prima notifica, con gli aggiornamenti sulle informazioni nel frattempo disponibili; infine, una relazione finale entro un mese dalla risoluzione dell’incidente, contenente l’analisi delle cause, la valutazione dell’impatto definitivo e le misure correttive adottate. Tutte le notifiche vanno trasmesse tramite i canali di vigilanza competenti, ovvero Banca d’Italia per le entità finanziarie nel settore bancario, IVASS per quelle nel settore assicurativo, Consob nei mercati finanziari e COVIP nella previdenza complementare.