Compliance DORA 2026: perché il 70% degli istituti finanziari ha bisogno di un nuovo partner di sviluppo software

17 gennaio 2027. Questa è la data che oltre 22.000 enti finanziari dell'Unione Europea devono cerchiare in rosso sui loro calendari di compliance. Entro quel giorno, ogni banca, assicuratore, società di investimento e istituto di pagamento deve dimostrare la piena conformità al Digital Operational Resilience Act — o affrontare sanzioni fino all'1% del fatturato mondiale medio giornaliero per un massimo di sei mesi.

L'ultima valutazione dell'Autorità Bancaria Europea dipinge un quadro severo: circa il 70% degli istituti finanziari non è ancora pronto a soddisfare i requisiti di gestione dei rischi ICT e di supervisione delle terze parti della DORA. Il divario non è nella comprensione normativa — è nell'esecuzione tecnica. E questo divario può essere colmato solo con il partner di sviluppo software giusto.

Cosa richiede realmente la DORA dal tuo stack tecnologico

La DORA non è un altro obbligo di reporting. È una ri-architettura fondamentale di come gli istituti finanziari gestiscono, monitorano e riprendono dalle disruption legate all'ICT. Il regolamento impone cinque pilastri, ciascuno con implicazioni dirette per lo sviluppo software:

Pilastro 1: Framework di gestione dei rischi ICT

L'Articolo 6 richiede che gli enti finanziari implementino un framework completo di gestione dei rischi ICT che copra identificazione, protezione, rilevamento, risposta e ripristino. Non è un esercizio di policy — richiede:

• Identificazione automatizzata dei rischi — scansione e classificazione continua degli asset ICT, delle dipendenze e delle vulnerabilità nell'intero patrimonio tecnologico
• Rilevamento delle minacce in tempo reale — sistemi di monitoraggio della sicurezza capaci di rilevare pattern di comportamento anomali indicatori di attacchi informatici o guasti di sistema
• Procedure di ripristino documentate — piani di disaster recovery e business continuity tecnicamente validati con target RTO e RPO definiti, testati almeno annualmente

Per la maggior parte degli istituti, soddisfare questi requisiti significa costruire o acquisire nuove capacità di monitoraggio, rilevamento e risposta che i loro attuali stack tecnologici non supportano.

Pilastro 2: Gestione degli incidenti ICT

Gli Articoli 17-23 stabiliscono un framework obbligatorio di classificazione, reporting e risposta agli incidenti. Gli enti finanziari devono:

• Classificare gli incidenti utilizzando una scala di gravità standardizzata allineata ai modelli delle Autorità di Vigilanza Europee
• Segnalare gli incidenti maggiori all'autorità competente entro tempi rigorosi — notifica iniziale entro 4 ore dalla classificazione
• Mantenere un registro centralizzato degli incidenti con analisi delle cause radice e tracciamento delle azioni correttive

La finestra di reporting di 4 ore è particolarmente esigente. Richiede sistemi automatizzati di rilevamento, classificazione e notifica degli incidenti che operino in tempo reale — una capacità che la maggior parte degli istituti attualmente non possiede.

Pilastro 3: Test di resilienza operativa digitale

Gli Articoli 24-27 impongono test di resilienza regolari proporzionati alle dimensioni dell'ente, al profilo di rischio e all'importanza sistemica. Gli enti di importanza sistemica devono condurre threat-led penetration testing (TLPT) — esercizi avanzati di red team supervisionati dal Lead Overseer.

I requisiti TLPT includono:

• Scenari basati su intelligence sulle minacce — test progettati su intelligence attuale e credibile sulle minacce anziché scanning generico di vulnerabilità
• Test su ambienti live — test condotti contro sistemi di produzione, non ambienti di staging, per convalidare la resilienza nel mondo reale
• Rimedio alle cause radice — i risultati devono essere affrontati con fix verificati, non solo documentati

La preparazione per il TLPT richiede una significativa capacità di security engineering che la maggior parte degli istituti non può costruire internamente entro il tempo rimanente.

Pilastro 4: Gestione dei rischi delle terze parti ICT

Gli Articoli 28-44 stabiliscono il requisito più consequenziale dal punto di vista commerciale: gli enti finanziari devono gestire e monitorare il rischio di concentrazione ICT e gli accordi con i fornitori terzi. Questo pilastro da solo è il motivo per cui la maggior parte degli istituti ha bisogno di un nuovo partner di sviluppo software.

Requisiti chiave:

• Mantenere un registro di tutti gli accordi terzi ICT con dettagli contrattuali, servizi forniti e valutazioni dei rischi
• Condurre due diligence pre-contrattuale sui fornitori di servizi ICT che copra pratiche di sicurezza, risposta agli incidenti e business continuity
• Garantire che i contratti contengano disposizioni obbligatorie: diritti di audit, obblighi di notifica degli incidenti, requisiti di localizzazione dei dati e strategie di uscita
• Monitorare il rischio di concentrazione — l'eccessiva dipendenza da un numero ristretto di fornitori ICT crea vulnerabilità sistemica

Pilastro 5: Condivisione di informazioni e intelligence

Gli Articoli 45-46 incoraggiano la condivisione volontaria di informazioni su minacce informatiche e incidenti tra enti finanziari tramite accordi di condivisione delle informazioni riconosciuti. L'implementazione richiede piattaforme e protocolli di condivisione sicuri e standardizzati.

Perché il tuo attuale partner di sviluppo software probabilmente non può garantire la compliance DORA

I requisiti di gestione dei rischi delle terze parti creano un paradosso: i partner che hanno costruito i tuoi attuali sistemi potrebbero non soddisfare gli standard che la DORA ora impone loro. Ecco perché.

Il gap degli SBOM

Le disposizioni della DORA sul rischio di concentrazione, combinate con il Cyber Resilience Act dell'UE, richiedono di fatto Software Bill of Materials (SBOM) per tutti i deliverable ICT. La maggior parte delle aziende di sviluppo software attualmente non genera SBOM come parte del proprio processo di consegna standard. Se il tuo partner di sviluppo non può fornire un SBOM completo, accurato e continuamente aggiornato per ogni componente che consegna, diventa un rischio di compliance piuttosto che un asset.

Il gap nella risposta agli incidenti

La DORA richiede che i fornitori terzi ICT notifichino ai loro clienti enti finanziari gli incidenti entro ore — non giorni. La maggior parte delle aziende di sviluppo software opera con SLA di ticket di supporto misurati in giorni lavorativi. Il divario culturale e operativo tra "risponderemo al tuo ticket entro 48 ore lavorative" e "ti notificheremo qualsiasi incidente di sicurezza che colpisce i tuoi sistemi entro 4 ore" è enorme.

Il gap dei diritti di audit

L'Articolo 30 richiede che i contratti con fornitori terzi ICT includano disposizioni che garantiscano diritti di audit e ispezione all'ente finanziario, ai suoi revisori e alle autorità competenti. Molte aziende di sviluppo software — in particolare quelle che operano offshore o sotto regimi di dati restrittivi — non possono accogliere questi requisiti senza ristrutturare le proprie operazioni.

Il gap del rischio di concentrazione

Se il tuo istituto si affida a un singolo partner di sviluppo software per funzioni ICT critiche, le disposizioni della DORA sul rischio di concentrazione potrebbero richiederti di diversificare. Il regolamento non impone esplicitamente strategie multi-vendor, ma i supervisori esamineranno accordi in cui un singolo fornitore rappresenta una quota sproporzionata di servizi ICT critici.

Come appare lo sviluppo software pronto per la DORA

Un partner di sviluppo software capace di supportare la compliance DORA deve dimostrare capacità in cinque domini che vanno ben oltre le pratiche di sviluppo standard.

1. Resilience Engineering integrato

Il software conforme alla DORA deve essere progettato per la resilienza operativa fin dall'inizio. Questo significa:

• Pattern circuit breaker — degrado automatico in condizioni di guasto anziché collasso a cascata
• Chaos engineering — test proattivo di scenari di guasto in condizioni controllate
• Architettura observability-first — logging, tracing e metriche completi che consentono rilevamento e diagnosi in tempo reale degli incidenti ICT
• Degrado elegante — sistemi che continuano a operare a capacità ridotta anziché fallire completamente

Questi non sono attributi di qualità opzionali. Sono requisiti normativi che devono essere dimostrabili ai supervisori.

2. Infrastruttura di compliance automatizzata

I requisiti di reporting e monitoraggio della DORA richiedono un'automazione che i processi manuali non possono soddisfare:

• Inventario continuo degli asset ICT — registro automaticamente mantenuto di tutti hardware, software e servizi
• Gestione delle vulnerabilità in tempo reale — scanning, classificazione e tracciamento delle azioni correttive automatizzati
• Motori di classificazione degli incidenti — classificazione iniziale automatizzata allineata ai modelli delle ESA per rispettare le finestre di reporting di 4 ore
• Generazione SBOM — generazione automatizzata di software bill of materials in formato SPDX o CycloneDX con ogni release

3. Pratiche di sviluppo security-first

Oltre alle pratiche di sicurezza della supply chain che abbiamo analizzato altrove, lo sviluppo pronto per la DORA richiede:

• Threat modeling per ogni feature prima dell'implementazione
• Analisi statica e dinamica integrata nel CI/CD con policy di blocco per i risultati critici
• Penetration testing come milestone di consegna standard, non come ripensamento
• Revisioni dell'architettura di sicurezza condotte da ingegneri di sicurezza indipendenti

4. Capacità di supervisione dei fornitori terzi

Se il tuo partner di sviluppo sta costruendo sistemi che si integrano con altri fornitori ICT, deve comprendere come implementare i requisiti di supervisione della DORA:

• Conformità contrattuale — garanzia che gli accordi con sub-fornitori soddisfino le disposizioni contrattuali obbligatorie della DORA
• Monitoraggio continuo — meccanismi tecnici per monitorare la postura di sicurezza dei sub-fornitori
• Valutazione del rischio di concentrazione — framework analitici per valutare se gli accordi ICT creano concentrazione eccessiva

5. Fluenza normativa europea

La DORA è applicata diversamente tra gli Stati membri dell'UE. Un partner di sviluppo che comprende solo il testo del regolamento ma non come FCA, BaFin, Banca d'Italia, ACPR e altre autorità nazionali lo interpretano e lo applicano produrrà soluzioni tecnicamente conformi ma operativamente inadeguate.

La decisione Build-vs-Partner per la compliance DORA

Gli istituti finanziari affrontano una scelta strategica: costruire internamente le capacità di compliance DORA, o collaborare con un'azienda di sviluppo software che le possiede già.

La via del Build

Costruire internamente richiede di assumere specialisti nella gestione dei rischi ICT, security engineering e compliance normativa — un bacino di talenti già scarso che diventerà più scarso man mano che la scadenza del gennaio 2027 si avvicina. Le stime attuali suggeriscono che gli istituti finanziari europei devono ricoprire oltre 30.000 posizioni in cybersecurity e resilienza ICT per soddisfare i requisiti DORA. La carenza di talenti è strutturale, non ciclica.

La via del Partner

Collaborare con un'azienda di sviluppo software affermata offre un time-to-compliance più rapido, accesso a competenze specializzate e la capacità di scalare la capacità di compliance su richiesta. Tuttavia, il processo di selezione del partner deve esso stesso essere conforme alla DORA — il che significa condurre la due diligence pre-contrattuale, garantire che le disposizioni contrattuali soddisfino i requisiti dell'Articolo 30 e stabilire meccanismi di monitoraggio continuo.

L'approccio più efficace per la maggior parte degli istituti è un modello ibrido: i team interni possiedono il framework di gestione dei rischi e la governance, mentre i partner esterni forniscono la capacità ingegneristica specializzata necessaria per implementare i controlli tecnici.

Come valutare un partner di sviluppo software per la compliance DORA

Quando si valutano potenziali partner di sviluppo, gli istituti finanziari dovrebbero applicare il seguente framework di valutazione:

Requisito DORA	Criteri di valutazione del partner
Gestione rischi ICT	Esperienza dimostrabile nella costruzione di sistemi di monitoraggio e rilevamento in tempo reale per istituti finanziari
Gestione incidenti	Capacità di risposta agli incidenti 24/7 con SLA documentati che soddisfano le finestre di notifica della DORA
Test di resilienza	Esperienza TLPT e capacità di security engineering per programmi di testing threat-led
Rischio terze parti	Capacità di fornire SBOM, accogliere diritti di audit e supportare il monitoraggio del rischio di concentrazione
Condivisione informazioni	Esperienza nell'implementazione di piattaforme e protocolli di condivisione delle informazioni sicuri e standardizzati

Le migliori aziende di sviluppo software fintech in Europa si differenziano sempre più attraverso una dimostrata prontezza DORA — non solo claim di marketing, ma processi documentati, capacità tecniche e riferimenti da istituti finanziari che hanno già iniziato i loro percorsi di compliance.

Il tempo stringe

Con la data di applicazione di gennaio 2027 a meno di un anno di distanza, la finestra per la preparazione alla compliance si sta restringendo. Gli istituti finanziari che non hanno ancora iniziato a valutare i propri gap di resilienza ICT e a valutare partner di sviluppo affrontano una timeline sempre più stretta in cui la scarsità di talenti e la disponibilità di partner diventeranno acute.

La compliance DORA non è un esercizio di spunta. È una trasformazione fondamentale del modo in cui gli istituti finanziari gestiscono il rischio tecnologico — e i partner che scelgono per eseguire quella trasformazione determineranno se rispetteranno la scadenza con fiducia o si affretteranno ad affrontare i risultati sotto pressione supervisoria.

La statistica del 70% di impreparazione non è una previsione — è una misurazione attuale. La domanda per ogni istituto finanziario è semplice: sei nel 30% che è pronto, o nel 70% che deve agire ora?

Pubblicato il 15 aprile 2026 · SectorPunk Research