Guida definitiva al DORA: conformità, scadenze RoI e adeguamento IT per la supply chain

Il DORA, acronimo di Digital Operational Resilience Act, non è più una promessa regolatoria né un cantiere normativo per uffici legali. Dal 17 gennaio 2025 il regolamento europeo sulla resilienza operativa digitale è pienamente applicabile e impone al settore finanziario un cambio di paradigma: banche, assicurazioni, intermediari, società di investimento, istituti di pagamento, operatori crypto regolati e molte altre entità finanziarie devono dimostrare di poter resistere, reagire e riprendersi da incidenti ICT, attacchi cyber, interruzioni dei servizi e crisi operative digitali. Le autorità europee descrivono il DORA come il quadro comune per rafforzare la sicurezza ICT del settore finanziario e armonizzare regole che prima erano disperse tra discipline nazionali e settoriali. Il 2026 rappresenta però l’anno della verità. Dopo l’entrata in applicazione del 2025, le entità finanziarie non possono più limitarsi a dichiarare di avere un programma di compliance. Devono produrre evidenze, registri, contratti, policy, test, procedure di incident response e documentazione sulla catena di fornitura ICT. Il punto più delicato è il Register of Information, spesso abbreviato in RoI, cioè il registro informativo degli accordi contrattuali con i fornitori ICT di terze parti. Le autorità nazionali raccolgono questi registri e li trasmettono alle autorità europee di vigilanza, anche per supportare l’individuazione dei fornitori ICT critici per il settore finanziario. L’EBA ha pubblicato risorse dedicate alla preparazione e alla trasmissione dei Register of Information, mentre alcune autorità nazionali, come la Banca centrale irlandese e la banca centrale olandese, hanno previsto finestre di invio nel mese di marzo 2026 per i registri riferiti al 2025. Il vero bersaglio del DORA non sono soltanto le banche. Il regolamento colpisce a cascata tutta la supply chain tecnologica della finanza europea. Una startup SaaS, un cloud provider, un fornitore API, una software house, un outsourcer IT, un gestore di data center, un provider di sicurezza, un MSP o un’azienda tech che vende servizi a una banca non può più considerarsi esterna al problema. Formalmente molti obblighi ricadono sull’entità finanziaria, ma nella pratica l’istituto vigilato scarica parte della pressione sui fornitori attraverso contratti, audit, richieste documentali, clausole di exit strategy, verifiche di sicurezza, mappatura dei subfornitori e garanzie di continuità operativa.

La conseguenza è semplice: nel 2026 la conformità DORA diventa una license to operate. Chi non riesce a dimostrare sicurezza, governance, tracciabilità, resilienza e controllo della propria catena ICT rischia di essere tagliato fuori dai processi di procurement finanziario. La compliance non è più un vantaggio reputazionale, ma una condizione minima per entrare o restare nelle filiere della finanza europea.

Che cos’è il DORA e quale problema risolve

Il DORA è il Regolamento (UE) 2022/2554 sulla resilienza operativa digitale del settore finanziario. A differenza di una direttiva, un regolamento europeo è direttamente applicabile negli Stati membri. Il suo obiettivo è costruire un livello uniforme di sicurezza e continuità operativa digitale nel settore finanziario, superando la frammentazione precedente. Le autorità europee di vigilanza individuano nel DORA un quadro che copre gestione del rischio ICT, incident reporting, test di resilienza digitale, rischio ICT di terze parti e condivisione delle informazioni sulle minacce. Il punto centrale è che la stabilità finanziaria non dipende più soltanto da capitale, liquidità, controlli contabili e governance prudenziale. La stabilità finanziaria dipende anche dalla capacità dei sistemi informatici di continuare a funzionare durante un attacco, un guasto, un disservizio cloud o una crisi nella supply chain. Se una banca non riesce a erogare pagamenti, se una piattaforma assicurativa resta indisponibile, se un servizio di trading viene bloccato, se un outsourcer ICT subisce un ransomware o se un cloud provider critico interrompe una funzione essenziale, l’incidente non è più solo tecnico. Diventa operativo, economico, reputazionale e sistemico. Il DORA nasce esattamente per questa ragione. Non si limita a imporre misure di sicurezza informatica. Chiede alle entità finanziarie di dimostrare una capacità complessiva di resilienza operativa digitale, cioè la capacità di prevenire, assorbire, contenere, rispondere e ripristinare servizi critici anche quando l’incidente si verifica davvero.

A chi si applica il DORA

Il DORA si applica a un’ampia gamma di entità finanziarie. Rientrano nel perimetro banche, istituti di pagamento, istituti di moneta elettronica, imprese di investimento, fornitori di servizi crypto regolati, depositari centrali, controparti centrali, sedi di negoziazione, gestori di fondi, imprese di assicurazione e riassicurazione, enti pensionistici aziendali o professionali, agenzie di rating, fornitori di servizi di crowdfunding e altri operatori finanziari previsti dal regolamento. Le autorità europee sottolineano che DORA copre molte tipologie di entità finanziarie e introduce un quadro armonizzato anche per i fornitori ICT di terze parti ritenuti critici. Per le aziende tech, il punto più importante è un altro: anche quando il fornitore ICT non è direttamente vigilato come entità finanziaria, entra comunque nel raggio d’azione del DORA attraverso i contratti con i clienti finanziari. Una banca deve conoscere, valutare, monitorare e documentare i propri fornitori ICT. Di conseguenza, chiederà al fornitore evidenze di sicurezza, certificazioni, piani di continuità, mappatura dei sub-processori, gestione delle vulnerabilità, tempi di ripristino, logiche di backup, controlli sugli accessi e procedure di incident notification.

Per molte PMI tech, questo è il passaggio più sottovalutato. Il DORA non arriva necessariamente con una lettera dell’autorità di vigilanza. Arriva con una richiesta del cliente bancario, con un questionario di procurement, con una clausola contrattuale, con un audit, con una revisione del fornitore o con una domanda apparentemente semplice: siete in grado di dimostrare la vostra resilienza operativa digitale?

I cinque pilastri della resilienza operativa digitale

Il DORA viene spesso spiegato attraverso cinque pilastri. Questa rappresentazione è utile perché traduce il regolamento in aree operative comprensibili: gestione del rischio ICT, segnalazione degli incidenti, test di resilienza, gestione del rischio di terze parti e condivisione delle informazioni. EIOPA sintetizza il perimetro del regolamento proprio attorno a questi ambiti, includendo anche il quadro di oversight sui fornitori ICT critici.

Gestione del rischio ICT

Il primo pilastro è la gestione del rischio ICT. Ogni entità finanziaria deve costruire un framework strutturato per identificare, proteggere, rilevare, rispondere e ripristinare. Non si tratta solo di installare strumenti di sicurezza, ma di governare l’intero ciclo di vita del rischio digitale. Asset, applicazioni, dati, identità, reti, infrastrutture cloud, fornitori e processi devono essere mappati, classificati e protetti in modo coerente. Framework come ISO 27001, NIST Cybersecurity Framework o approcci equivalenti possono aiutare le organizzazioni a costruire una struttura documentale e operativa solida, anche se il DORA non va ridotto a una singola certificazione. La certificazione può essere un acceleratore, ma non sostituisce la responsabilità effettiva del management, la conoscenza degli asset critici e la capacità di dimostrare che i controlli funzionano nella pratica. Il rischio ICT va letto come rischio d’impresa. Se un sistema digitale sostiene una funzione critica o importante, quel sistema non è un semplice asset tecnico: è una componente della continuità aziendale. Questa impostazione obbliga CIO, CISO, risk manager, compliance, legal e direzione a lavorare insieme, perché la resilienza digitale non può restare confinata nel reparto IT.

Segnalazione degli incidenti

Il secondo pilastro riguarda la segnalazione degli incidenti ICT rilevanti. DORA impone processi per identificare, classificare e notificare gli incidenti maggiori alle autorità competenti. Le bozze tecniche elaborate dalle autorità europee indicano una struttura a più fasi, con notifica iniziale, relazione intermedia e relazione finale; per gli incidenti maggiori, i tempi proposti includono una notifica iniziale entro quattro ore dalla classificazione e comunque entro ventiquattro ore dalla rilevazione, una relazione intermedia entro settantadue ore e una relazione finale entro un mese. Questi tempi rendono evidente un fatto: non si può improvvisare la notifica durante l’incidente. Un’organizzazione che non ha log centralizzati, playbook di incident response, ruoli chiari, escalation interna, canali di comunicazione e criteri di classificazione non riuscirà a rispettare la norma nel momento della crisi. La segnalazione è solo l’ultimo anello di una catena che parte dalla detection e arriva alla governance. Per la supply chain ICT, questo significa che anche il fornitore deve essere in grado di avvisare rapidamente il cliente finanziario quando un incidente può impattare servizi critici o importanti. Se il contratto non prevede tempi, contatti, soglie e responsabilità, la banca si espone a un rischio regolatorio e il fornitore diventa un punto debole.

Test di resilienza e TLPT

Il terzo pilastro è il digital operational resilience testing. Le entità finanziarie devono testare regolarmente sistemi, applicazioni, processi e controlli. I test possono includere vulnerability assessment, penetration test, analisi del codice, test di performance, scenari di failover, esercitazioni di business continuity, simulazioni di incident response e verifiche della capacità di ripristino. Per le entità più rilevanti, il DORA introduce anche i Threat-Led Penetration Test, spesso indicati come TLPT. Non sono semplici penetration test standardizzati, ma simulazioni avanzate basate su minacce realistiche, intelligence sugli attori ostili e tecniche di attacco coerenti con il profilo dell’organizzazione. In pratica, il TLPT avvicina il test alla logica del Red Team: non si limita a cercare vulnerabilità isolate, ma prova a verificare se un attaccante qualificato può compromettere funzioni critiche. Il messaggio per il management è chiaro: la resilienza non si dichiara, si prova. Un piano di continuità mai testato è un documento fragile. Un backup mai ripristinato è una promessa. Un SOC che non rileva movimenti laterali è un costo senza controllo reale. DORA spinge il settore finanziario a passare dalla compliance di carta alla verifica operativa.

Gestione del rischio di terze parti

Il quarto pilastro è il più importante per la supply chain. Il DORA stabilisce che il rischio ICT di terze parti deve essere gestito come parte integrante del framework di rischio ICT. Le entità finanziarie devono mantenere un registro degli accordi contrattuali con i fornitori ICT e distinguere i servizi che supportano funzioni critiche o importanti. Il Register of Information serve proprio a rendere visibile questa rete di dipendenze. Questo produce un cambio di potere nei rapporti commerciali. Una banca non può più scegliere un fornitore solo per prezzo, performance o funzionalità. Deve valutarne sicurezza, continuità, governance, subfornitori, capacità di audit, localizzazione dei dati, exit strategy e resilienza. Il fornitore ICT diventa parte del rischio regolatorio della banca. Per le PMI tech, questo significa che la documentazione di sicurezza non è più materiale accessorio. Servono policy, inventario dei sub-processori, procedure di vulnerability management, registro degli incidenti, piano di business continuity, piano di disaster recovery, evidenze di backup, controlli MFA, gestione privilegi, crittografia, tracciamento degli accessi e capacità di rispondere agli audit.

Condivisione delle informazioni

Il quinto pilastro è la condivisione delle informazioni. Il DORA incoraggia lo scambio di informazioni e intelligence sulle minacce tra entità finanziarie, nel rispetto delle regole applicabili. L’obiettivo è creare un fronte difensivo più coordinato, dove indicatori di compromissione, tecniche di attacco, vulnerabilità sfruttate e campagne attive possano circolare più rapidamente tra soggetti esposti a rischi simili. La logica è semplice: nessuna entità finanziaria difende soltanto sé stessa. Un attacco a un fornitore comune, una vulnerabilità in un software diffuso o una campagna ransomware contro servizi finanziari può avere effetti sistemici. La condivisione controllata delle informazioni diventa quindi un elemento di resilienza collettiva.

L’impatto sulla supply chain ICT: perché il DORA riguarda anche le PMI tech

Il DORA cambia il modo in cui le banche e gli operatori finanziari acquistano tecnologia. Ogni servizio ICT che supporta una funzione critica o importante deve essere contrattualizzato, valutato, monitorato e documentato. Questo trasforma la supply chain in un’estensione del perimetro regolatorio. Per una PMI tech, il punto non è chiedersi se il regolamento la nomini direttamente. Il punto è chiedersi se vende o vuole vendere a soggetti finanziari europei. Se la risposta è sì, la conformità DORA diventa una condizione commerciale. Una software house che fornisce una piattaforma gestionale, una startup che espone API, un provider SaaS che gestisce dati operativi, un cloud provider verticale, un MSP che amministra infrastrutture o una società di cybersecurity che eroga servizi gestiti dovranno dimostrare di essere affidabili anche dal punto di vista documentale. La banca può chiedere una Sub-Processor Map, cioè una mappa dei subfornitori coinvolti nel trattamento o nella fornitura del servizio. Può chiedere evidenze sulla gestione delle vulnerabilità, risultati di penetration test, certificazioni, report SOC, policy di access management, procedure di incident notification, localizzazione dei dati, misure di crittografia, tempi di ripristino, RPO, RTO e condizioni di uscita dal contratto.

Questo scenario crea una nuova selezione di mercato. Chi ha sicurezza documentata vende più facilmente. Chi non ce l’ha diventa un rischio di compliance. Le aziende tech che lavorano con la finanza devono quindi trattare la resilienza come parte del prodotto. Non basta dire che il software funziona. Bisogna dimostrare che resta governabile anche in caso di incidente.

Sanzioni, audit e rischio di esclusione dalla filiera

Il DORA affida alle autorità competenti poteri di vigilanza, indagine e sanzione. L’articolo 50 del regolamento prevede che gli Stati membri stabiliscano sanzioni amministrative e misure correttive effettive, proporzionate e dissuasive; le autorità possono richiedere documenti, svolgere indagini e imporre misure correttive in caso di violazione. Per i fornitori ICT critici sottoposti al quadro europeo di oversight, il regime è ancora più incisivo. Il DORA prevede poteri dei Lead Overseers e, nei casi di mancata conformità, pagamenti periodici fino all’1% del fatturato medio giornaliero mondiale del fornitore ICT critico, calcolati su base giornaliera e per un periodo massimo previsto dal regolamento. Per molte aziende tech, però, la sanzione più immediata non sarà una multa. Sarà l’esclusione commerciale. Un fornitore non conforme può essere eliminato da una gara, bloccato in fase di onboarding, sostituito da un competitor più maturo o costretto a rinegoziare il contratto. La banca deve proteggere sé stessa dal rischio regolatorio e reputazionale; se un fornitore non fornisce evidenze, il rischio diventa difficilmente accettabile.

Hardening IT e adeguamento tecnico: tradurre il DORA in infrastruttura reale

La difficoltà del DORA sta nel tradurre il linguaggio regolatorio in scelte tecniche concrete. La resilienza operativa digitale non vive nei documenti, ma nei sistemi. Per questo l’adeguamento deve toccare identità, rete, endpoint, backup, monitoraggio, logging, cloud, fornitori e procedure di crisi.

Zero Trust e controllo degli accessi

Il primo principio è lo Zero Trust. Nessun utente, dispositivo, servizio o workload deve essere considerato affidabile per impostazione predefinita. Ogni accesso critico deve essere autenticato, autorizzato, tracciato e limitato al minimo privilegio necessario. La MFA deve essere obbligatoria su tutti gli accessi amministrativi, su VPN, console cloud, pannelli SaaS, strumenti DevOps, repository, sistemi di ticketing, dashboard di monitoraggio e account privilegiati. Gli account condivisi vanno eliminati o ridotti al minimo. Gli accessi amministrativi devono essere separati dagli account ordinari. Le credenziali devono essere gestite con password manager aziendali o sistemi PAM, non con fogli Excel, chat interne o documenti condivisi. La micro-segmentazione delle reti diventa essenziale. Un ransomware non deve poter attraversare liberamente l’intera infrastruttura. Le reti di produzione, sviluppo, backup, amministrazione, utenti e servizi critici devono essere separate. I flussi devono essere autorizzati, monitorati e documentati. La segmentazione non elimina l’incidente, ma ne riduce la propagazione.

Business continuity e disaster recovery

Il DORA richiede una vera capacità di continuità operativa. Questo significa che backup, replica, failover e ripristino non possono essere affidati all’improvvisazione. Ogni servizio critico deve avere obiettivi chiari di RTO e RPO. Il primo indica il tempo massimo accettabile per ripristinare il servizio. Il secondo indica la quantità massima di dati che l’organizzazione può permettersi di perdere. I backup devono essere crittografati, segregati, testati e protetti dalla cancellazione malevola. I backup offline o immutabili sono fondamentali contro ransomware e compromissioni degli account amministrativi. Un backup raggiungibile dallo stesso dominio compromesso non è una garanzia: può diventare una vittima ulteriore dell’attacco. Il disaster recovery va testato davvero. Non basta sapere che esiste una replica. Bisogna verificare che il servizio possa ripartire, che i dati siano integri, che le credenziali siano disponibili, che la documentazione sia aggiornata e che il personale sappia cosa fare. Un piano non testato è soltanto una speranza formalizzata.

Monitoraggio, SIEM e SOC

La resilienza richiede visibilità. Un’organizzazione che non raccoglie log, non correla eventi e non rileva anomalie scopre l’incidente quando il danno è già visibile. Per questo il DORA spinge indirettamente verso sistemi di monitoraggio maturi, come SIEM, EDR, NDR, sistemi di alerting, threat intelligence e, per le realtà più strutturate, un SOC interno o gestito. I log devono coprire autenticazioni, privilegi, attività amministrative, accessi VPN, console cloud, endpoint, firewall, applicazioni critiche, database, repository e sistemi di backup. La retention deve essere adeguata alle esigenze di indagine. La correlazione deve consentire di individuare escalation di privilegi, accessi anomali, movimenti laterali, esfiltrazione, tentativi di disattivazione dei controlli e attività fuori orario. Un SOC efficace non è un cruscotto pieno di alert, ma un processo che combina tecnologia, analisti, playbook, escalation e capacità di risposta. Senza questo collegamento, il monitoraggio produce rumore, non resilienza.

Vulnerability management e patching

Il vulnerability management deve diventare un processo continuo. Ogni asset deve essere censito, classificato e scansionato. Le vulnerabilità devono essere prioritarizzate in base a esposizione, criticità del servizio, exploitability e impatto sul business. Le patch devono seguire finestre definite, ma anche procedure accelerate per vulnerabilità critiche sfruttate attivamente. Per i fornitori SaaS e cloud, il tema diventa ancora più sensibile. Il cliente finanziario deve sapere come il fornitore gestisce vulnerabilità, dipendenze software, librerie open source, container, immagini base, segreti, pipeline CI/CD e configurazioni cloud. La sicurezza della supply chain software è ormai parte della resilienza operativa digitale.

DORA vs NIS2: quali sono le differenze

DORA e NIS2 appartengono alla stessa stagione regolatoria europea, ma non sono la stessa cosa. Il DORA è verticale sul settore finanziario e sui suoi fornitori ICT. La NIS2 è una direttiva orizzontale sulla cybersicurezza di settori essenziali e importanti, con un perimetro molto più ampio che include energia, trasporti, sanità, infrastrutture digitali, pubblica amministrazione e altri settori critici. La Commissione europea descrive la NIS2 come un quadro comune per rafforzare la cybersicurezza in 18 settori critici dell’Unione.

Mentre il DORA è verticale sulla finanza, scopri se la tua azienda ricade negli obblighi trasversali nella nostra [Guida completa alla NIS2 2026].

La differenza più importante è quindi il punto di osservazione. La NIS2 guarda alla cybersicurezza dei settori critici. Il DORA guarda alla continuità digitale del sistema finanziario. In alcuni casi i due regimi possono sovrapporsi, ma il DORA contiene regole specifiche per la finanza e per la gestione del rischio ICT di terze parti.

DORA e GDPR: due obblighi diversi che si incontrano sui dati

DORA e GDPR vengono spesso confusi perché entrambi toccano sicurezza, dati, fornitori e incidenti. In realtà hanno finalità diverse. Il GDPR tutela i dati personali e i diritti degli interessati. Il DORA tutela la resilienza operativa digitale del settore finanziario. Un incidente può attivare entrambi i regimi, ma per ragioni diverse: il GDPR quando sono coinvolti dati personali, il DORA quando l’incidente impatta sistemi ICT, servizi finanziari, continuità operativa o funzioni critiche. Per una banca, questo significa che un ransomware può richiedere valutazioni parallele: notifica privacy, incident reporting DORA, comunicazione ai clienti, gestione della crisi, ripristino dei servizi e analisi forense. Per un fornitore ICT, significa che la documentazione contrattuale deve coprire sicurezza, protezione dei dati, continuità operativa, subfornitori, audit e incident notification.

La differenza è netta: il GDPR chiede conto del trattamento dei dati personali; il DORA chiede conto della capacità di continuare a operare in modo resiliente anche sotto stress digitale.

Come prepararsi al DORA nel 2026

La preparazione deve partire da una mappatura completa. Ogni entità finanziaria deve sapere quali servizi ICT usa, quali fornitori li erogano, quali subfornitori sono coinvolti, quali funzioni sono critiche o importanti e quali contratti regolano i rapporti. Senza questa mappa, il Register of Information diventa un esercizio fragile. Subito dopo serve una gap analysis. Bisogna confrontare lo stato reale dell’organizzazione con i requisiti DORA: governance ICT, risk management, incident reporting, business continuity, disaster recovery, testing, vulnerability management, controllo dei fornitori, contratti, exit strategy e capacità di audit. La gap analysis deve produrre una roadmap, non un report destinato a restare in una cartella condivisa. Per le aziende tech fornitrici della finanza, la priorità è costruire un dossier DORA-ready. Questo dossier dovrebbe includere policy di sicurezza, certificazioni disponibili, architettura del servizio, mappa dei sub-processori, controlli di accesso, procedure di incident notification, piani di continuità, test di backup, gestione vulnerabilità, risultati di penetration test e canali di escalation. Non serve aspettare che il cliente lo chieda. Nel 2026, arrivare preparati significa accorciare le trattative e ridurre il rischio di esclusione.

La conformità DORA non è un certificato, ma un audit continuo

Il DORA non va affrontato come una certificazione da ottenere una volta e poi dimenticare. È un processo di governance continua. I fornitori cambiano, le architetture cloud evolvono, le vulnerabilità emergono, i sistemi vengono aggiornati, le minacce si trasformano e gli incidenti ridefiniscono le priorità. La conformità deve quindi essere mantenuta, verificata e aggiornata. Il 2026 è l’anno in cui la resilienza operativa digitale passa dalla teoria alla rendicontazione. I Register of Information, gli audit sui fornitori, i test di resilienza, le richieste documentali e la pressione sulle supply chain ICT renderanno visibile chi ha costruito un sistema maturo e chi ha trattato il DORA come un adempimento formale. Per il settore finanziario, il regolamento è una sfida di governance. Per le aziende tech, è una sfida di mercato. Per i sysadmin, è una sfida infrastrutturale. Per i CISO, è una sfida di evidenza e controllo. Per il management, infine, è una sfida di responsabilità. La resilienza operativa digitale non si compra a pacchetto: si costruisce con processi, tecnologia, disciplina e documentazione.

FAQ sul DORA 2026