Per molti intermediari ex 106, DORA continua a essere percepito come una normativa ampia, trasversale e difficile da tradurre in scelte operative concrete.
Ed è proprio qui che nasce il problema.
Il quadro regolamentare richiede un presidio strutturato su governance ICT, gestione del rischio, incidenti, test di resilienza e terze parti critiche. La piena conformità entro il 1° gennaio 2027 può sembrare ancora lontana. In realtà, non lo è affatto.
DORA non chiede un semplice aggiornamento di policy o un set di controlli tecnici aggiuntivi: chiede la capacità di governare il rischio ICT in modo continuativo, tracciabile e proporzionato, con responsabilità definite, processi verificabili ed evidenze coerenti.
Il punto, quindi, non è “fare DORA”.
Il punto è evitare di affrontarlo nel modo sbagliato.
Il problema, nella maggior parte dei casi, non è la mancanza di attenzione. È la difficoltà di tradurre una cornice regolamentare complessa in un programma operativo sostenibile.
Le strutture sono snelle, i ruoli si sovrappongono, e funzioni come IT, Risk, Compliance, Operations ed esternalizzazione lavorano sugli stessi rischi con linguaggi, priorità e livelli di formalizzazione diversi.
In questo contesto, DORA rischia di essere gestito come un insieme di cantieri paralleli: una policy da aggiornare, un assessment da chiudere, un registro fornitori da completare, qualche test da pianificare.
Il risultato è prevedibile: molte attività aperte, poca integrazione, responsabilità non perfettamente definite e un avanzamento sostanziale modesto.
Il rischio più serio non è arrivare tardi.
È arrivare al 2027 con una conformità solo apparente, ma con una governance frammentata e poco difendibile in sede ispettiva.
È l’errore più frequente: collocare DORA nell’area tecnologica e affrontarlo come se riguardasse soprattutto la sicurezza informatica e i controlli tecnici.
In realtà, DORA richiede un presidio organizzativo trasversale, che coinvolge governo societario, funzioni di controllo e strutture operative.
Quando il tema resta confinato nell’IT:
le decisioni rilevanti non arrivano al board nel formato corretto;
le priorità non vengono tradotte in scelte aziendali;
il programma perde forza prima ancora di partire.
Per un ex 106, DORA deve essere impostato come iniziativa di governance aziendale, non come cantiere tecnico.
Un secondo errore è quello di ritenersi pienamente conformi attraverso un percorso meramente "documentale":
Avere una policy non significa saper gestire un incidente.
Avere un registro non significa governare una dipendenza critica da un fornitore.
Avere un piano di continuità non significa garantire tempi di ripristino realistici.
DORA spinge verso una resilienza dimostrabile: non un insieme di documenti, ma un sistema coerente di regole, responsabilità, misure ed evidenze.
Il rischio per un ex 106 è costruire un impianto ordinato solo in superficie ma fragile nei passaggi decisivi: classificazione degli incidenti, escalation, gestione delle dipendenze esterne, continuità dei servizi critici.
La domanda giusta non è: “Abbiamo il documento?”
Ma: “Siamo in grado di dimostrare come governiamo un’interruzione grave?”
DORA richiede una logica integrata che impone il superamento del "silos".
I suoi pilastri non funzionano se vengono gestiti come compartimenti separati.
Quando governance, rischio, incidenti, terze parti e continuità non dialogano:
i fornitori essenziali non vengono classificati correttamente;
SLA e KPI risultano incoerenti con i servizi critici;
i diritti di audit sono insufficienti;
i ruoli interni in caso di disservizio non sono chiari;
il reporting è incompleto.
Il salto di qualità sta nella costruzione di un unico programma DORA, con dipendenze esplicite tra i vari ambiti.
Molte roadmap falliscono perché corrette sulla carta ma deboli nella pratica.
Una roadmap credibile per un ex 106 è asciutta, pragmatica e centrata sui fondamentali:
Governance ICT formalizzata, con ruoli e escalation chiare.
Gestione degli incidenti ICT con criteri di classificazione, registro ed evidenze.
Mappatura delle terze parti ICT critiche con revisione progressiva dei contratti, KPI e SLA misurabili.
Il resto viene dopo: senza questi tre pilastri, il programma produce documenti ma non resilienza.
Se il board riceve aggiornamenti episodici, troppo tecnici o poco decisionali, non può esercitare un presidio efficace.
La chiave è presentare pochi indicatori chiari, ad esempio:
rischi ICT sopra soglia;
incidenti significativi e tempi di risposta;
disponibilità dei servizi critici;
avanzamento dei test di continuità e DR;
copertura contrattuale dei fornitori critici.
Il punto non è aumentare il reporting: è renderlo utile.
Il valore di DORA, per un intermediario ex 106, è proprio questo: costringere l’organizzazione a integrare ambiti che finora erano gestiti in modo separato.
Governance, rischio ICT, incidenti, test e terze parti sono distinti solo sulla carta: nella realtà devono convergere in un unico impianto di governo.
Il percorso parte da domande essenziali:
Chi decide sulle priorità ICT rilevanti?
Quali servizi e fornitori sorreggono davvero l’operatività critica?
Quali scenari di interruzione metterebbero sotto stress l’organizzazione?
Quali evidenze avremmo oggi in caso di verifica ispettiva?
Un programma DORA credibile nasce da una fotografia sincera, non da una rappresentazione ideale.
Da qui al 1° gennaio 2027 c’è ancora spazio per impostare correttamente il percorso.
Il tempo non va letto come un rinvio rassicurante, ma come una finestra per costruire una conformità sostenibile.
In sede di vigilanza, non farà la differenza un documento aggiornato all’ultimo minuto. Farà la differenza la capacità di mostrare:
assessment iniziale,
gap chiari,
priorità definite,
roadmap eseguita,
responsabilità attribuite,
evidenze prodotte,
risultati misurabili.
È questo che distingue una conformità difensiva da una governance matura.
Ed è questo il contributo più utile di DORA: trasformare il rischio ICT da tema tecnico da rincorrere a materia di governo da presidiare con metodo.