DORA entra in vigore. Le PMI finanziarie non sono pronte, e non per i motivi che pensano

Il 17 gennaio 2025 il Digital Operational Resilience Act è diventato applicabile in tutta l’Unione Europea. Dopo due anni di fase transitoria, la norma non è più un elemento del calendario della compliance: è una variabile operativa attiva. Le sanzioni sono reali, le ispezioni sono iniziate, e gli obblighi non attendono.

Eppure la grande maggioranza delle PMI finanziarie italiane ed europee è impreparata. Non per mancanza di consapevolezza — negli ultimi diciotto mesi DORA è stato uno degli argomenti più discussi nei convegni di settore — ma per un errore di diagnosi. Le organizzazioni che si sono preparate male lo hanno fatto perché hanno trattato DORA come un problema di cybersecurity. Non lo è.

DORA è un problema di governance, di struttura contrattuale e di ridisegno della catena di responsabilità.

La tesi

Il rischio principale che DORA introduce nelle PMI finanziarie non è tecnico. È organizzativo e contrattuale. La maggior parte degli operatori mid-market ha costruito la propria infrastruttura digitale su una catena di dipendenze da fornitori ICT esterna — cloud provider, SaaS finanziari, piattaforme di core banking — pensata per l’operatività quotidiana, non per la resilienza regolata. DORA non chiede di rendere quei sistemi più sicuri in senso tecnico. Chiede di dimostrare che l’organizzazione li controlla, li conosce in profondità, e sa cosa fare quando smettono di funzionare.

Questa è una domanda a cui la maggior parte dei board non sa rispondere.

La struttura degli incentivi

Per capire dove si concentra il problema reale, è necessario guardare all’architettura degli obblighi DORA e al modo in cui si distribuisce la responsabilità nella catena ICT tipica di un operatore finanziario mid-market.

Il perimetro è più ampio di quanto si pensi. DORA si applica a banche, assicuratori, intermediari del credito, gestori di fondi, istituti di pagamento, exchange di criptoattività e — novità rilevante — ai fornitori ICT critici che servono queste organizzazioni. Per una PMI finanziaria, questo significa che non basta mettere in ordine casa propria: occorre mappare e gestire contrattualmente ogni fornitore che contribuisce ai processi critici.

La dipendenza dal cloud è il nodo strutturale. La quasi totalità degli operatori mid-market utilizza infrastrutture cloud di terze parti — AWS, Azure, Google Cloud — per funzioni che DORA considera critiche o importanti. Questi provider hanno dimensioni, strutture contrattuali e SLA pensati per clienti enterprise globali, non per le esigenze di conformità di una finanziaria italiana con 50 milioni di attivi. Il risultato è che i contratti esistenti, nella maggior parte dei casi, non contengono le clausole richieste da DORA: diritti di audit, obblighi di notifica degli incidenti, garanzie di continuità operativa, clausole di uscita con tempistiche definite.

Il risk assessment ICT è una funzione nuova, non un audit esteso. DORA richiede che le organizzazioni finanziarie identifichino e classifichino sistematicamente tutti gli asset ICT, le loro interdipendenze, i rischi associati e i piani di risposta. Questo non è un esercizio una tantum: è una funzione ricorrente che richiede ownership organizzativa, metodologia documentata e aggiornamento continuo. La maggior parte delle PMI finanziarie non ha questa funzione. Ha, nel migliore dei casi, un responsabile IT che gestisce l’operatività e una funzione compliance che gestisce le scadenze normative. DORA richiede che queste due funzioni siano integrate in un framework di gestione del rischio operativo digitale — un livello di maturità organizzativa che molte strutture mid-market non hanno ancora raggiunto.

Il TLPT è un onere sproporzionato per gli operatori minori. Il Threat-Led Penetration Testing — i test di penetrazione basati su scenari di minaccia reale — è obbligatorio per le istituzioni finanziarie significative. Per gli operatori di dimensioni minori l’obbligo è attenuato, ma non eliminato: è richiesta comunque una strategia di testing documentata e coerente con il profilo di rischio. Anche questo è un investimento che richiede risorse specialistiche che il mercato mid-market stenta a trovare e a pagare.

L’effetto sistemico

Quando si analizza DORA dal punto di vista degli effetti di sistema, emergono tre dinamiche che raramente vengono discusse nelle analisi standard.

La fragilità a cascata. DORA introduce il concetto di “concentrazione ICT” come rischio sistemico: quando troppi operatori finanziari dipendono dallo stesso fornitore cloud o dalla stessa piattaforma SaaS, un’interruzione di quel fornitore produce un’interruzione coordinata nel sistema finanziario. La norma chiede agli operatori di valutare e gestire questo rischio di concentrazione. Ma la valutazione individuale non risolve il problema sistemico: se tutti i concorrenti usano AWS e la tua analisi di rischio conclude che AWS è critico, il tuo piano di continuità — migrare su Azure in caso di incidente — è razionale per te, ma è un’illusione sistemica se lo fanno tutti contemporaneamente.

Il vendor lock-in come rischio regolatorio. I grandi fornitori ICT — e in particolare i cloud hyperscaler — sono nella posizione più favorevole immaginabile: i loro clienti finanziari non possono permettersi di cambiarli facilmente, ma allo stesso tempo DORA richiede ai clienti di dimostrare che potrebbero farlo. Questo crea una negoziazione strutturalmente asimmetrica: i fornitori devono concedere clausole contrattuali DORA-compliant, ma sanno che il cliente non li abbandonerà. Il risultato è che molti grandi provider stanno offrendo “pacchetti di compliance DORA” a pagamento — essenzialmente facendo pagare ai clienti il costo di adeguarsi agli obblighi che la norma impone su di loro.

Il trasferimento implicito del rischio al sistema. Le PMI finanziarie che non riescono a sostenere i costi di conformità DORA hanno due strade: affidarsi completamente a pochi fornitori infrastrutturali “pre-certificati” (concentrando il rischio sistemico) oppure operare in condizione di conformità formale ma sostanziale fragilità operativa. In entrambi i casi, il rischio non sparisce: si redistribuisce e si concentra in punti del sistema che diventano più opachi, non più trasparenti.

L’implicazione per il decisore

Per chi siede nel board o nel comitato esecutivo di una PMI finanziaria, DORA pone domande che non possono essere delegate al team IT o alla funzione compliance.

La domanda sbagliata è: abbiamo completato il gap assessment DORA?

La domanda corretta è: se il nostro principale fornitore cloud avesse un’interruzione domani mattina, quale membro del board saprebbe cosa fare, in quale sequenza, con quale autorità?

Se la risposta è “dipende dall’IT” o “lo gestiamo quando succede”, DORA non è stata capita. Non nel modo che conta.

In concreto, questo richiede tre interventi strutturali che vanno ben oltre la compliance tecnica:

Revisione contrattuale sistematica. Ogni contratto con fornitori ICT che contribuiscono a funzioni critiche o importanti deve essere rivisto alla luce dei requisiti DORA. Questo include: clausole di audit e ispezione, obblighi di notifica degli incidenti entro tempistiche definite, garanzie di portabilità dei dati, scenari di uscita con tempistiche e costi espliciti, subcatene di fornitura. Non è un esercizio legale: è un ridisegno della mappa di responsabilità operativa.

Ridefinizione della governance ICT a livello di board. DORA attribuisce responsabilità esplicita all’organo di gestione — non al CTO, non al CISO. Il board deve approvare la politica di gestione del rischio ICT, deve ricevere reportistica periodica sugli incidenti e deve essere in grado di valutare l’adeguatezza delle misure adottate. Questo richiede che almeno un membro del board abbia le competenze per farlo, o che il board si doti di un advisor con questa specializzazione.

Costruzione di una funzione di gestione del rischio ICT, non di un audit. Il risk assessment ICT richiesto da DORA non è un documento da produrre una volta per ottenere la conformità. È una funzione operativa ricorrente, con ownership chiara, metodologia documentata, integrazione con il processo di gestione del rischio aziendale e aggiornamento ad ogni cambiamento significativo dell’infrastruttura o del contesto di minaccia. Costruirla richiede tempo, risorse e — spesso — un cambio culturale su come l’organizzazione percepisce il rischio operativo digitale.

Il rischio nascosto

C’è un rischio di secondo livello in DORA che merita attenzione specifica e che la narrativa corrente sul Regolamento quasi sempre omette.

DORA crea un incentivo molto forte alla compliance documentale: produrre il registro dei fornitori ICT, completare il gap assessment, redigere il piano di risposta agli incidenti, aggiornare i contratti con le clausole richieste. Tutto questo è necessario, misurabile e verificabile dagli organi di vigilanza.

Ma crea un incentivo molto più debole alla resilienza reale: la capacità effettiva dell’organizzazione di continuare a operare — o di ripristinare l’operatività in tempi accettabili — quando un componente critico dell’infrastruttura ICT si interrompe.

La falsa sensazione di compliance formale senza resilienza reale è il rischio più pericoloso che DORA introduce nel sistema. Un’organizzazione può avere contratti DORA-compliant con tutti i suoi fornitori cloud e non aver mai testato concretamente cosa succederebbe se il servizio venisse interrotto per 48 ore. Può avere un piano di risposta agli incidenti impeccabile sulla carta e un team operativo che non lo ha mai simulato. Può aver superato il gap assessment e continuare a operare su un’architettura con single point of failure che nessuna documentazione elimina.

Questo è il pattern che i supervisori europei troveranno nelle ispezioni dei prossimi anni. Non organizzazioni che hanno ignorato DORA, ma organizzazioni che lo hanno gestito come un esercizio di compliance e non come un progetto di trasformazione operativa.

Una questione di interpretazione

DORA è una norma strutturalmente corretta: affronta un rischio reale — la fragilità operativa digitale del sistema finanziario europeo — con strumenti che, se applicati con serietà, possono migliorare la resilienza complessiva.

Il problema non è il Regolamento. È la sua interpretazione prevalente come problema tecnico e documentale, quando è un problema di governance, struttura organizzativa e mappa delle responsabilità.

Per i board delle PMI finanziarie, la finestra per un adeguamento sostanziale si sta chiudendo. Le ispezioni sono iniziate. Le sanzioni sono operative. E la differenza tra chi ha costruito resilienza reale e chi ha prodotto documenti di compliance diventerà evidente al primo incidente significativo — non al primo audit.

Chi capisce questa distinzione prima degli altri non sta solo gestendo un rischio normativo. Sta ridisegnando la propria architettura di sopravvivenza in un mercato che sta diventando più fragile, non meno.

Calvi & Partners è una boutique di advisory strategico specializzata in AI governance e fintech architecture. Operiamo dove tecnologia, capitale e regolamentazione si sovrappongono.

→ Scopri i nostri servizi
→ Leggi gli altri Insights