Come adeguarsi a DORA in modo operativo: percorso in 7 fasi

Risposta rapida

L’adeguamento a DORA non dovrebbe partire da un documento, ma da un percorso operativo misurabile. La sequenza più efficace è: perimetro, mappa dei servizi critici, gap analysis, remediation, gestione fornitori ICT, incident workflow e monitoraggio continuo. Ogni fase deve produrre evidenze verificabili, owner responsabili e scadenze. In assenza di un sistema unico, il rischio è creare policy formalmente corrette ma scollegate da contratti, test, incidenti e registri.

Perché questo tema è importante

Per molte entità finanziarie il punto debole non è la mancanza totale di controlli, ma la frammentazione. L’IT possiede informazioni sugli asset, il procurement conosce i fornitori, il legal ha i contratti, il risk manager valuta gli impatti e la compliance prepara i report. DORA richiede che questi pezzi siano riconciliati in un processo unico, perché la resilienza operativa digitale deve essere dimostrabile nel tempo.

Un percorso DORA maturo permette di rispondere a tre domande semplici ma decisive: quali servizi finanziari dipendono da quali sistemi ICT, quali fornitori supportano funzioni critiche o importanti, e quali evidenze provano che il rischio è governato. Se una di queste domande richiede giorni di ricerca tra e-mail, fogli Excel e cartelle condivise, l’adeguamento non è realmente operativo.

Quadro normativo e fonti ufficiali

Il Regolamento (UE) 2022/2554 è direttamente applicabile e costruisce un quadro uniforme per la resilienza operativa digitale del settore finanziario. Le fonti ESA richiamano i cinque pilastri: ICT risk management, gestione e segnalazione degli incidenti ICT, digital operational resilience testing, gestione del rischio da terze parti ICT e condivisione volontaria di informazioni sulle minacce. La Banca d’Italia ha inoltre reso disponibili istruzioni operative per la comunicazione dei gravi incidenti ICT e ha indicato le tempistiche annuali di trasmissione del Register of Information.

Le fonti da usare come base sono il Regolamento (UE) 2022/2554 su EUR-Lex, la pagina EBA dedicata a DORA, gli atti delegati e di esecuzione della Commissione europea e, per gli operatori vigilati in Italia, le comunicazioni della Banca d’Italia su incidenti ICT e Register of Information.

Cosa significa per l'azienda

Per l’azienda, adeguarsi significa trasformare requisiti normativi in workflow. Il perimetro deve essere approvato, i servizi critici devono essere collegati agli asset e ai fornitori, gli incidenti devono essere classificati secondo criteri coerenti, i contratti ICT devono essere tracciati e il management deve ricevere una vista sintetica ma non superficiale.

Il lavoro non termina con il primo assessment. DORA richiede manutenzione: nuovi fornitori, modifiche contrattuali, cambiamenti architetturali, test, incidenti, audit e aggiornamenti degli atti tecnici devono alimentare la stessa base informativa.

Metodo operativo per come adeguarsi DORA

1. Costituire un gruppo DORA con compliance, risk, IT, security, procurement, legal e internal audit.
2. Definire il perimetro: entità, funzioni, servizi, sistemi ICT, fornitori e dipendenze.
3. Mappare i requisiti sui cinque pilastri DORA, distinguendo requisiti normativi, controlli interni ed evidenze disponibili.
4. Eseguire una gap analysis documentata, assegnando gravità, owner, scadenze e dipendenze.
5. Creare o aggiornare il Register of Information con dati contrattuali e classificazione dei servizi ICT.
6. Collegare incident management, business continuity, test di resilienza e remediation in un unico ciclo di miglioramento.
7. Preparare dashboard e report periodici per management, funzioni di controllo e audit.

Mappa pratica: requisito, controllo, evidenza

| Area | Domanda di controllo | Evidenza utile | Rischio se manca | |---|---|---|---| | Governance | Chi approva e riesamina il presidio? | Verbali, policy approvate, dashboard | Decisioni non dimostrabili | | ICT risk | Il rischio ICT è valutato e aggiornato? | Risk register, assessment, remediation | Rischio residuo non governato | | Incidenti | L'incidente viene classificato ed escalato? | Ticket, timeline, report, post-mortem | Ritardi e segnalazioni incoerenti | | Fornitori ICT | Il servizio esterno è censito e valutato? | ROI, contratto, assessment, exit strategy | Dipendenze non presidiate | | Test e continuità | La resilienza è provata periodicamente? | Piano test, risultati, lesson learned | Piani teorici non verificati |

Esempio pratico

Una società di gestione del risparmio parte da una policy cybersecurity già esistente e pensa di essere quasi pronta. Durante lo scoping emerge però che il portale clienti, il sistema documentale, il provider cloud e il software AML sono gestiti da team diversi e non esiste una vista unica delle funzioni supportate. Il progetto DORA viene quindi diviso in sette fasi: inventario dei servizi, collegamento ai processi critici, raccolta contratti, prima gap analysis, aggiornamento clausole, test di resilienza e report al board. Dopo tre mesi l’organizzazione non ha solo “documenti DORA”, ma una matrice interrogabile che mostra per ogni servizio il rischio, il fornitore, le evidenze e le remediation aperte.

Errori comuni da evitare

• Partire dalla redazione di una policy generale senza mappare servizi, asset e fornitori.
• Trattare il Register of Information come compilazione una tantum.
• Non coinvolgere legal e procurement nella fase di remediation.
• Confondere la sicurezza tecnica con la resilienza operativa digitale.
• Non produrre evidenze datate, versionate e riferibili a un owner.
• Non prevedere un reporting ricorrente verso l’organo di gestione.

Come GAPOFF aiuta

Nel percorso di adeguamento GAPOFF può funzionare come cabina di regia. Il modulo DORA consente di impostare il perimetro e i cinque pilastri; Vendor Risk Management collega fornitori, contratti e criticità; Incident & Breach Ops gestisce classificazione, timeline e report; Business Continuity permette di legare BIA, RTO/RPO, test e piani di ripristino. Il risultato è una compliance non limitata a un fascicolo, ma leggibile come processo: requisito, controllo, evidenza, gap, remediation, owner e stato.

Collegamenti interni consigliati per il coding agent: Modulo GAPOFF DORA, Vendor Risk Management, Incident & Breach Ops, Business Continuity, Trust Center.

Checklist operativa

• Gruppo DORA formalizzato
• Perimetro e funzioni importanti documentate
• Matrice requisiti-controlli-evidenze disponibile
• Gap analysis approvata
• Piano remediation con priorità e owner
• Register of Information popolato
• Incident workflow collegato ai criteri DORA
• Dashboard periodica per management e audit

Roadmap consigliata di mantenimento

| Frequenza | Attività | Output atteso | |---|---|---| | Settimanale | Verifica task aperti, incidenti e remediation scadute | Aggiornamento stato operativo | | Mensile | Riesame di gap, fornitori critici e qualità evidenze | Report per compliance e risk | | Trimestrale | Sintesi management su rischi, incidenti, test e budget | Dashboard executive e verbale | | Annuale | Riesame completo del framework e del Register of Information | Evidence pack e piano di miglioramento |

FAQ

Quanto tempo serve per adeguarsi a DORA?

Dipende dalla maturità iniziale. Un’entità con asset inventory, vendor management e incident process già strutturati può procedere più rapidamente; se invece i dati sono dispersi, la fase di scoping e raccolta evidenze diventa la più impegnativa.

Da dove conviene partire se l’organizzazione è in ritardo?

Conviene partire dal perimetro e dai servizi ICT che supportano funzioni critiche o importanti. Senza questa base, anche policy e procedure rischiano di restare generiche.

DORA richiede un software specifico?

La normativa non impone un software specifico, ma richiede tracciabilità, aggiornamento e capacità di dimostrare controlli ed evidenze. Una piattaforma riduce il rischio operativo rispetto a una gestione manuale frammentata.

Il percorso DORA finisce dopo la prima gap analysis?

No. La gap analysis è un punto di partenza. DORA va mantenuto con monitoraggio continuo, aggiornamento registri, test, incidenti, audit e riesami del management.

Fonti ufficiali e riferimenti

• EUR-Lex - Regolamento (UE) 2022/2554 DORA
• Commissione Europea - DORA implementing and delegated acts
• EBA - Digital Operational Resilience Act
• Banca d'Italia - Comunicazione di gravi incidenti ICT e minacce significative
• Banca d'Italia - Trasmissioni annuali Register of Information dal 2026

Disclaimer legale

Questo contenuto ha finalità informative e di orientamento generale. Non costituisce consulenza legale, tecnica, fiscale o organizzativa personalizzata. Per determinare obblighi, responsabilità e misure applicabili al caso concreto, è necessario svolgere una valutazione specifica con professionisti qualificati e fonti ufficiali aggiornate.

FAQ

Quanto tempo serve per adeguarsi a DORA?

Dipende dalla maturità iniziale. Un’entità con asset inventory, vendor management e incident process già strutturati può procedere più rapidamente; se invece i dati sono dispersi, la fase di scoping e raccolta evidenze diventa la più impegnativa.

Da dove conviene partire se l’organizzazione è in ritardo?

Conviene partire dal perimetro e dai servizi ICT che supportano funzioni critiche o importanti. Senza questa base, anche policy e procedure rischiano di restare generiche.

DORA richiede un software specifico?

La normativa non impone un software specifico, ma richiede tracciabilità, aggiornamento e capacità di dimostrare controlli ed evidenze. Una piattaforma riduce il rischio operativo rispetto a una gestione manuale frammentata.

Il percorso DORA finisce dopo la prima gap analysis?

No. La gap analysis è un punto di partenza. DORA va mantenuto con monitoraggio continuo, aggiornamento registri, test, incidenti, audit e riesami del management.