Regolamento DORA: cosa cambia davvero
Il regolamento DORA non è un adempimento da confinare alla funzione compliance. Per banche, assicurazioni, intermediari, payment provider e soggetti ICT critici, introduce un cambio di scala nella gestione del rischio digitale: dalla somma di controlli tecnici e policy separate a un modello di resilienza operativa misurabile, governato e verificabile.
La differenza, per chi opera in contesti regolamentati, è netta. Non basta più dimostrare di avere presidi cyber, procedure di continuità o contratti con i fornitori ben scritti. Occorre provare che l’organizzazione sia in grado di prevenire, assorbire, rispondere e recuperare da disruption ICT con responsabilità chiare, test credibili e una supervisione strutturata della catena di fornitura tecnologica.
Cos’è il regolamento DORA e perché conta
DORA, Digital Operational Resilience Act, è il quadro normativo europeo che disciplina la resilienza operativa digitale del settore finanziario. L’obiettivo non è solo rafforzare la cybersecurity. Il perimetro è più ampio e riguarda la capacità dell’organizzazione di mantenere servizi critici e processi essenziali anche in presenza di incidenti ICT, guasti, attacchi, errori di terze parti o eventi combinati.
Questo punto merita attenzione perché spesso il regolamento viene letto in chiave esclusivamente tecnologica. In realtà, la logica di DORA è manageriale prima ancora che tecnica. Chiede governance, accountability, integrazione tra risk management, security, continuità operativa, procurement, incident management e controllo sui fornitori.
Per molte organizzazioni il vero tema non è introdurre nuovi documenti, ma raccordare strutture che storicamente hanno lavorato per silos. Dove questo raccordo manca, la compliance tende a diventare formale. Dove invece esiste una governance coerente, DORA può migliorare la qualità effettiva della resilienza.
I pilastri del regolamento DORA
Il regolamento DORA si fonda su alcuni assi portanti che incidono direttamente sull’assetto organizzativo.
Il primo è il framework di gestione del rischio ICT. Le entità finanziarie devono disporre di un impianto strutturato per identificare asset, dipendenze, vulnerabilità, scenari di impatto e misure di protezione. Non si tratta solo di classificare i rischi, ma di collegarli ai processi di business e ai servizi critici.
Il secondo è la gestione e segnalazione degli incidenti ICT. DORA richiede una disciplina più rigorosa nella classificazione, nell’escalation e nella notifica degli incidenti maggiori. Questo comporta procedure chiare, ruoli definiti e criteri omogenei per distinguere il rumore operativo dagli eventi con impatto regolamentare.
Il terzo è il digital operational resilience testing. I test non possono essere episodici o limitati a verifiche documentali. Devono essere proporzionati al profilo di rischio, coprire scenari severi ma plausibili e, nei casi previsti, includere attività avanzate come il threat-led penetration testing.
Il quarto riguarda il rischio derivante da terze parti ICT. Qui DORA è particolarmente incisivo. La dipendenza da cloud provider, software vendor, managed service provider e altri fornitori tecnologici non può essere trattata come un tema puramente contrattuale. Serve una valutazione preventiva, un monitoraggio continuo, una chiara mappatura delle concentrazioni di rischio e strategie di uscita realistiche.
Infine, il regolamento promuove la condivisione di informazioni sulle minacce tra operatori, laddove applicabile e utile. È un segnale preciso: la resilienza digitale non si costruisce solo all’interno del perimetro aziendale, ma anche attraverso un ecosistema informativo più maturo.
Dove le organizzazioni trovano le maggiori criticità
Sul piano operativo, le difficoltà emergono quasi sempre negli stessi punti.
La prima è la mappatura. Molte aziende conoscono l’inventario tecnico dei sistemi, ma non hanno una vista affidabile delle dipendenze tra applicazioni, processi critici, fornitori e dati. Senza questa base, classificare i servizi essenziali e valutare gli impatti reali diventa complesso.
La seconda riguarda la governance. DORA chiama in causa il management body e impone un livello di coinvolgimento più sostanziale. Questo significa che la resilienza operativa digitale non può restare confinata all’IT o alla cybersecurity. Va tradotta in decisioni, priorità, appetito al rischio, investimenti e reporting verso gli organi di governo.
La terza criticità è la qualità dei test. Esercitazioni troppo semplici, checklist scollegate dagli scenari reali o test che non coinvolgono le funzioni chiave producono evidenze deboli. La conformità documentale, in questi casi, non coincide con la capacità di tenuta in situazione critica.
La quarta è il governo delle terze parti. I contratti spesso non riflettono appieno i requisiti di resilienza richiesti, soprattutto quando si tratta di subcontracting, portabilità, accesso alle evidenze, diritti di audit e gestione dell’exit. Il problema aumenta nelle organizzazioni con un parco fornitori ampio e frammentato.
Regolamento DORA e business continuity: il punto di contatto reale
Chi lavora in business continuity riconosce subito un aspetto centrale del regolamento DORA: la resilienza digitale non sostituisce lacontinuità operativa, ma la rende più esigente, più integrata e più verificabile.
Un piano di continuità, da solo, non è sufficiente se non dialoga con architetture ICT, asset critici, scenari cyber, dipendenze esterne e capability di recovery effettivamente testate. Allo stesso modo, una funzione cyber matura non basta se non è inserita in un modello che considera tempi di ripristino, impatti sul servizio, comunicazione di crisi e decisioni cross-funzionali.
Per questo DORA va letto come un acceleratore di integrazione tra discipline.Business continuity, disaster recovery, incident response, crisis management e third-party risk management devono convergere su un linguaggio comune. Nelle organizzazioni più evolute, questo passaggio porta a una maggiore chiarezza sui servizi critici, sulle tolleranze operative e sulle responsabilità in caso di disruption. In quelle meno mature, fa emergere incoerenze che erano già presenti ma non ancora visibili.
Come impostare un percorso di adeguamento credibile
Un adeguamento serio al regolamento DORA parte da unagap analysiscondotta con criteri tecnici e non solo regolamentari. Occorre verificare ciò che esiste davvero, non ciò che è descritto nelle policy. La distanza tra i due livelli, in molti casi, è il dato più utile.
Il passaggio successivo consiste nel definire il perimetro dei servizi critici o importanti, mappando asset, processi, risorse, dipendenze interne ed esterne. Senza questa vista, il framework di rischio ICT resta astratto e i test perdono significato.
Serve poi rivedere la governance. Il board e il top management devono ricevere informazioni sintetiche ma concrete: esposizioni principali, concentrazioni su fornitori, stato delle capability di risposta, esiti dei test, remediation aperte e priorità di investimento. Un reporting troppo tecnico o troppo generico fallisce nello stesso modo.
Sul fronte dei test, conviene costruire una roadmap plurilivello. Alcuni controlli saranno ricorrenti e tattici, altri richiederanno esercitazioni interfunzionali, simulazioni di crisi e verifiche avanzate su scenari ad alto impatto. L’efficacia dei test dipende dalla capacità di stressare davvero l’organizzazione, non dal numero di evidenze raccolte.
Infine, la gestione delle terze parti va trattata come un programma. Non basta aggiornare qualche clausola contrattuale. Servono criteri di due diligence, classificazione dei fornitori, monitoraggio delle performance, valutazione del rischio di concentrazione e piani di exit che siano operabili anche sotto pressione.
Un errore frequente: leggere DORA come progetto IT
Tra gli errori più ricorrenti c’è quello di assegnare DORA all’IT come se fosse una estensione della sicurezza informatica. È una scelta comprensibile, ma limitante. Il regolamento incide su procurement, legale, compliance, risk management, continuità operativa, internal audit e governance aziendale.
Anche l’approccio opposto, puramente normativo, presenta limiti. Se l’adeguamento viene guidato solo dalla logica documentale, il rischio è produrre policy corrette ma poco applicabili. La vera tenuta si misura durante un’interruzione, un incidente maggiore o un malfunzionamento di un fornitore critico, non in fase di archiviazione delle evidenze.
Per questo le organizzazioni più solide stanno impostando DORA come programma trasversale di resilienza, con ownership chiare, priorità fondate sul rischio e una connessione stretta tra requisiti normativi e capacità operative reali.
Il valore di un approccio integrato al regolamento DORA
Nel concreto, il regolamento DORA premia le organizzazioni capaci di combinare disciplina regolamentare e execution. Significa saper leggere il testo normativo, ma anche tradurlo in assessment, architetture di controllo, metriche, test ed esercitazioni che reggano nel tempo.
È qui che formazione specialistica, audit indipendenti e consulenza tecnica fanno la differenza. Non tanto per produrre più documentazione, quanto per elevare la qualità del modello di resilienza. Continuitaly opera precisamente in questo spazio: trasformare requisiti complessi in programmi applicabili, verificabili e coerenti con standard internazionali e contesti operativi ad alta esposizione.
DORA, in definitiva, non chiede perfezione teorica. Chiede consapevolezza del rischio, governo delle dipendenze e capacità di risposta dimostrabile. Per le organizzazioni che sapranno affrontarlo con rigore, rappresenta meno un vincolo e più un test di maturità manageriale.
This post is also available in:
