Gestisci un gestionale verticale, un’app SaaS o l’IT in outsourcing di qualche cliente, e tra questi c’è una banca di credito cooperativo, una SIM o una compagnia assicurativa. Va tutto liscio finché un giorno l’ufficio acquisti del cliente ti manda un PDF di venti pagine intitolato “Addendum DORA al contratto di fornitura”: diritto di audit, registro delle informazioni, exit plan, notifica incidenti entro tempi stretti. La domanda non è più “DORA mi riguarda?”, ma “cosa sto per firmare e quanto mi costa rispettarlo?”.
Questa guida è scritta per te che fornisci servizi ICT al mondo finance, non per l’entità finanziaria regolata. Vediamo cosa ti viene chiesto, perché, e come arrivarci preparato.
ℹ️ Disclaimer: contenuto informativo aggiornato a giugno 2026, non sostituisce una consulenza legale o contrattuale. I testi normativi e gli orientamenti delle autorità possono cambiare: verifica sempre le fonti ufficiali e fatti assistere su contratti specifici.
DORA in due righe (dal lato del fornitore)
Il Regolamento UE 2022/2554, noto come DORA (Digital Operational Resilience Act), è pienamente applicabile dal 17 gennaio 2025. Impone alle entità finanziarie europee — banche, assicurazioni, SIM, istituti di pagamento, gestori di cripto-attività e molte altre — di garantire la resilienza operativa digitale: devono cioè dimostrare di reggere a guasti IT, attacchi e incidenti senza interrompere i servizi.
Il punto che ti riguarda è uno solo: una fetta importante del rischio ICT di una banca non è dentro la banca, è nei suoi fornitori. Per questo DORA dedica un intero capo (gli articoli 28-30) alla gestione del rischio derivante da fornitori terzi di servizi ICT. E quel fornitore, nel 2026, sei tu.
Il 2025 è stato l’anno dell’adeguamento interno delle entità finanziarie. Il 2026 è l’anno in cui scaricano gli obblighi a valle, sulla filiera. Concretamente: rinegoziazioni di contratto, addendum, questionari di due diligence e richieste di evidenze che arrivano in massa ai fornitori.
Non confonderlo con “l’effetto filiera NIS2”
Se segui il tema compliance avrai già letto del cosiddetto effetto a cascata di NIS2: anche le PMI non soggette si trovano obblighi contrattuali perché forniscono soggetti regolati (ne abbiamo parlato in NIS2 e fornitori della filiera). DORA produce un effetto simile, ma non è la stessa cosa e vale la pena tenerli distinti:
- NIS2 è un effetto trasversale a molti settori critici (energia, sanità, manifattura, fornitori digitali) e arriva spesso come richiesta di sicurezza generica nella catena di approvvigionamento.
- DORA è settoriale e molto più prescrittivo: riguarda solo la filiera del settore finanziario, ma per quella filiera le clausole contrattuali non sono “buone pratiche”, sono requisiti minimi di legge che il cliente è obbligato a inserire nel contratto, pena sanzioni per lui.
In altre parole: con NIS2 il cliente vorrebbe certe garanzie; con DORA il cliente finance deve ottenerle da te per essere a sua volta conforme. Hai molto meno margine di negoziazione. Per la mappa completa di come si incastrano le due norme con AI Act e GDPR, vedi la guida alla compliance IT 2026 per le PMI.
Cosa ti chiede di firmare il cliente: gli articoli 28-30
L’addendum DORA che ricevi non è arbitrario: ricalca le clausole minime che l’articolo 30 impone di mettere a contratto. Ecco le voci che troverai, tradotte in linguaggio da fornitore.
1. Descrizione completa del servizio e livelli (SLA)
Devi descrivere in modo puntuale cosa fai, dove vengono trattati e conservati i dati, e con quali livelli di servizio misurabili (disponibilità, tempi di ripristino). Niente più SLA generici da brochure: servono soglie quantitative e indicatori. Se i dati del cliente sono ospitati su cloud, devi indicare le sedi di trattamento (regioni/data center).
2. Diritto di audit e ispezione
Questa è la clausola che spaventa di più i fornitori. Il cliente — e, per i servizi più rilevanti, l’autorità di vigilanza — ha diritto di accedere, ispezionare e fare audit sui tuoi sistemi e processi. Significa che potresti dover ospitare audit on-site, rispondere a questionari periodici, fornire report di test e penetration test. Avere documentazione e certificazioni pronte trasforma un audit da incubo in un invio di PDF.
3. Gestione e notifica degli incidenti
Devi impegnarti a rilevare, gestire e notificare al cliente gli incidenti ICT entro tempi contrattuali stretti, perché il cliente ha a sua volta obblighi di segnalazione verso le autorità con finestre temporali serrate. Serve un processo di incident response che funzioni davvero, non un foglio Word. Un buon punto di partenza è strutturare la risposta come nel playbook dei primi 60 minuti dopo un incidente.
4. Subappalto (sub-outsourcing)
Se per erogare il servizio ti appoggi ad altri fornitori (un altro cloud, un servizio di backup, un sub-fornitore di sviluppo), devi dichiararlo. Il contratto regola se e come puoi subappaltare funzioni che supportano servizi critici, e il cliente può pretendere di approvare o vietare certi subappalti. Devi quindi avere mappata la tua intera catena di fornitura tecnologica.
5. Exit strategy
Il cliente deve poter lasciarti senza traumi. Il contratto prevede clausole di uscita che garantiscono continuità: portabilità dei dati in formato usabile, periodo di transizione, supporto alla migrazione verso un altro fornitore o internamente. Lock-in tecnologico aggressivo e formati proprietari chiusi diventano un problema commerciale, non solo etico.
6. Cooperazione con le autorità e diritti di accesso ai dati
Devi garantire piena cooperazione con le autorità di vigilanza e l’accesso/recupero dei dati in caso di risoluzione. Per i fornitori di servizi ICT critici o importanti i requisiti dell’articolo 30, par. 3 sono ancora più stringenti (es. partecipazione ai programmi di test di resilienza del cliente, livelli di servizio dettagliati con allerta tempestiva).
Il “registro delle informazioni”: il documento che ti riguarda da vicino
L’articolo 28 obbliga ogni entità finanziaria a tenere un registro delle informazioni su tutti gli accordi con i fornitori ICT, da trasmettere alle autorità in un formato standard. Tu non compili il registro, ma ne sei la materia prima: il cliente avrà bisogno da te di dati anagrafici precisi, identificativi (incluso il codice LEI se lo hai), descrizione delle funzioni supportate, indicazione se la funzione è “critica o importante”, sedi di erogazione e di trattamento dati, e l’eventuale catena di subappalto.
Tradotto: aspettati un questionario dettagliato a corredo del contratto. Più i tuoi dati sono ordinati e già pronti, più sei un fornitore “facile” — e in un mercato dove le banche stanno razionalizzando i fornitori non conformi, essere facile è un vantaggio competitivo concreto.
Come lo stack Microsoft ti aiuta a rispondere
La buona notizia: se eroghi su Azure e Microsoft 365, gran parte delle evidenze che il cliente ti chiede esistono già e puoi ereditarle, invece di costruirle da zero. Funziona secondo il modello di responsabilità condivisa: il cloud provider è responsabile della resilienza dell’infrastruttura, tu lo sei delle tue configurazioni e dei tuoi dati.
- Certificazioni e audit di terze parti: Azure e Microsoft 365 dispongono di un ampio set di certificazioni e report di audit indipendenti (ISO 27001, SOC, e framework specifici per il finance). Quando il cliente chiede evidenze di sicurezza dell’infrastruttura, puoi fare riferimento a questi report tramite la documentazione di compliance ufficiale Microsoft, invece di sottoporre i tuoi data center a ispezione.
- Resilienza e continuità: ridondanza geografica, zone di disponibilità e SLA contrattuali del cloud coprono buona parte dei requisiti di resilienza operativa. Una solida strategia di backup e disaster recovery ben documentata risponde direttamente alle clausole su continuità ed exit.
- Sicurezza e gestione incidenti: con Microsoft Defender e i log di sicurezza centralizzati hai la telemetria per rilevare e documentare gli incidenti nei tempi richiesti. Le sedi di trattamento dati sono selezionabili (es. data region europee), risposta diretta alla clausola sulle sedi.
- Controllo accessi e governance: gestione delle identità, MFA e accessi privilegiati su Microsoft 365 sono i controlli che il cliente si aspetta di vedere documentati nel questionario di due diligence.
Attenzione, però: ereditare i controlli del cloud non ti scarica della tua parte. Resti responsabile di come configuri i tenant, di chi ha accesso, di come fai backup applicativi, del tuo piano di continuità e della catena di subappalto. La maturità di un fornitore DORA-ready sta proprio nel documentare con chiarezza la ripartizione: questo è del provider, questo è mio, ecco le evidenze di entrambi.
Quando ha senso un servizio gestito
Mettere in piedi incident response, gestione delle identità, backup verificabili e documentazione di compliance pronta per gli audit del cliente finance non è un progetto da un pomeriggio. Per una software house o un MSP, ogni ora spesa a inseguire questionari è un’ora tolta al prodotto e ai clienti.
Con il servizio di Assistenza cybersecurity gestita ti aiutiamo a costruire e mantenere i controlli e le evidenze che i tuoi clienti finance ti chiederanno: hardening di Defender, gestione degli incidenti, documentazione delle misure. Con l’Assistenza Microsoft 365 gestita teniamo in ordine identità, accessi e configurazioni del tenant — la base su cui poggia tutto il resto. Se vuoi capire da dove partire rispetto al tuo specifico addendum DORA, parla con un nostro consulente: mappiamo insieme le clausole che hai ricevuto e cosa serve per rispondere.
Vale anche la pena ricordare che molti di questi requisiti si intrecciano con quelli delle polizze cyber: le stesse evidenze che chiede il cliente finance le chiede l’assicuratore, come spiegato nei requisiti assuntivi delle cyber insurance 2026.
Domande frequenti
La mia software house non è una banca: DORA mi riguarda davvero?
Non sei tu il soggetto regolato, ma se fornisci servizi ICT a una banca, una SIM o un’assicurazione diventi un “fornitore terzo di servizi ICT” ai fini DORA. L’entità finanziaria è obbligata a scaricare su di te, via contratto, requisiti su sicurezza, audit, gestione incidenti ed exit strategy. In pratica DORA ti arriva sotto forma di addendum contrattuale da firmare.
Cosa cambia di concreto nei contratti che firmo con un cliente finance?
Il contratto deve contenere clausole minime previste dagli art. 28-30 del Regolamento: descrizione completa del servizio e dei livelli, diritto di audit e ispezione (anche da parte dell’autorità di vigilanza), gestione e notifica degli incidenti, regole sul subappalto, e una exit strategy che consenta al cliente di lasciarti senza interrompere il servizio. Per i servizi critici i requisiti sono più stringenti.
Devo certificarmi ISO 27001 per lavorare con le banche sotto DORA?
DORA non impone una certificazione specifica al fornitore, ma il cliente finance deve valutare il tuo rischio ICT prima e durante il rapporto. Certificazioni come ISO 27001, SOC 2 e l’uso di piattaforme già certificate (es. Azure e Microsoft 365) riducono enormemente l’attrito: rispondi ai questionari del cliente con evidenze già pronte invece di costruirle da zero.
Come mi aiuta lo stack Microsoft a rispondere ai requisiti DORA del cliente?
Azure e Microsoft 365 portano in dote certificazioni, audit di terze parti, SLA contrattuali, ridondanza geografica e log di sicurezza che coprono buona parte delle evidenze richieste. Tu resti responsabile della tua quota (configurazioni, accessi, backup, piano di continuità), ma puoi ereditare e citare i controlli del cloud provider invece di reinventarli. Documentare bene questa ripartizione è ciò che il cliente finance si aspetta.