DORA: cosa devi chiedere al tuo fornitore ICT prima del prossimo rinnovo

Quando un fornitore IT propone a una banca italiana il rinnovo automatico del contratto SaaS, ci sono buone probabilità che in calce ci sia ancora una clausola di “general security best practices” generica. Se sei dal lato banca, e DORA si applica al tuo istituto, quel rinnovo automatico è il problema più grande della tua settimana. Se sei dal lato fornitore, e ti accorgi che il tuo cliente sta per chiederti audit rights e exit plan obbligatorio, è il problema della tua trimestrale.

Il Digital Operational Resilience Act (Regolamento UE 2022/2554) è entrato in piena vigenza il 17 gennaio 2025. Le linee guida secondarie sono ormai tutte pubblicate: i Regulatory Technical Standards (RTS) della Commissione, gli Implementing Technical Standards (ITS) delle ESAs, e — per l’Italia — le indicazioni operative di Banca d’Italia, IVASS e CONSOB. Non c’è più transitorio. La differenza pratica con NIS2 è importante: DORA è un regolamento, non una direttiva, quindi si applica direttamente senza filtro nazionale, e sotto regolamento europeo le sanzioni vere arrivano prima.

Chi rientra (più di quanto pensi)

Il perimetro DORA non è “banche”. È “entità finanziarie”, e l’elenco dell’art. 2 è lungo:

• banche tradizionali
• istituti di pagamento ed emittenti di moneta elettronica
• imprese di investimento
• imprese di assicurazione e riassicurazione
• intermediari assicurativi (sopra una certa soglia)
• gestori di fondi comuni (UCITS, AIFM)
• fornitori di servizi su cripto-attività (MiCA-regolati)
• agenzie di rating del credito
• repository di operazioni
• gestori di sedi di negoziazione

E poi — questa è la parte che molti dimenticano — i fornitori ICT critici (“Critical Third-Party Providers”, CTPPs), designati direttamente dalle Autorità di Vigilanza Europee. Se sei un grosso cloud provider o un grosso vendor SaaS con clientela finanziaria europea concentrata, scoprirai un giorno di essere CTPP, e da quel momento sei vigilato direttamente dall’EBA/ESMA/EIOPA, non più via i tuoi clienti. Per le PMI fintech non cambia molto: significa che i tuoi grandi fornitori (AWS, Microsoft, Google) saranno vigilati in casa loro, e tu erediti la pressione a cascata.

Il pivot è il “Register of Information”

Cuore operativo di DORA è il Register of Information (Art. 28). Ogni entità finanziaria deve mantenere — e consegnare annualmente all’Autorità competente — un registro completo dei suoi “contractual arrangements” con fornitori ICT. Banca d’Italia ha indicato la scadenza al 30 aprile di ogni anno per le banche italiane. Le prime consegne sono già passate; la prossima è ad aprile 2027, e il tempo per sistemare i contratti prima di quella data è adesso.

Cosa c’è dentro il Register? Per ogni contratto con un fornitore ICT, una quarantina di campi suddivisi in tabelle:

• B.01.01 anagrafica del fornitore (LEI obbligatorio se disponibile, altrimenti EUID)
• B.02.01 descrizione funzionale del servizio
• B.02.03 classificazione: “supports a critical or important function”? sì/no
• B.03.01 sub-fornitori dei tuoi fornitori (la parte fastidiosa)
• B.05.01 date di scadenza contratto e di notice period

Solo per riempire B.03.01 — la chain of sub-outsourcing — molti istituti hanno scoperto di non sapere quali sub-fornitori usa il loro ERP cloud. La risposta del fornitore “abbiamo un giro internazionale di hosting” non basta più. Serve la lista.

Le 6 clausole da pretendere prima del prossimo rinnovo

Se gestisci IT in una banca o fintech italiana, queste sono le clausole che il tuo legale dovrebbe inserire nel prossimo rinnovo. Niente di esotico, sono tutte derivabili dagli artt. 28-30 di DORA + RTS sub-outsourcing.

1. Right to audit with teeth

Non basta “le parti collaboreranno con i revisori”. Serve la possibilità per te, i tuoi auditor e l’Autorità di Vigilanza di eseguire audit on-site senza preavviso eccessivo, accesso ai sistemi rilevanti, copia della documentazione di test. I fornitori SaaS storicamente respingono on-site con il classico “abbiamo SOC2 Type II, basta quello”. Per DORA non basta. SOC2 è un baseline; il diritto di audit indipendente va comunque pretesto in contratto, anche se in pratica lo si esercita raramente.

2. Notifica incidenti contrattualizzata con SLA stretto

DORA ti obbliga a notificare incidenti gravi all’Autorità nazionale entro 4 ore dal momento in cui sono “classificati come gravi”, con timeline ben definita di follow-up (notifica intermedia entro 72h, relazione finale entro 1 mese). Se il tuo fornitore SaaS notifica un incident dopo 36 ore, sei in ritardo strutturale. Pretendi notifica entro 6 ore dalla scoperta del fornitore. In pratica, contrattualizza una webhook + un canale fuori-banda (es. PagerDuty su un cellulare dedicato del tuo SOC).

3. Exit plan documentato

L’art. 28.8 di DORA ti chiede un exit plan per ogni contratto che supporta funzioni critiche o importanti. Non un “exit strategy” generica: un piano scritto con:

• runbook tecnico di estrazione dati (formato, tempi)
• alternative di mercato già identificate
• migration window stimata
• responsabilità del fornitore uscente durante la transizione

Se non è mai stato chiesto, il fornitore tipicamente offre “30 giorni di accesso ai dati post-termination”. Per un ERP bancario, 30 giorni sono ridicoli. Negozia 6-12 mesi, e ottieni il diritto a estendere se l’autorità lo richiede.

4. Sub-outsourcing chain trasparente

L’RTS sulle politiche verso i fornitori ICT (Regolamento delegato (UE) 2024/1773) e quello sul subappalto ti chiedono non solo di sapere chi sono i sub-fornitori del tuo fornitore, ma di approvare i cambi materiali. Pretendi:

• elenco scritto e aggiornato di tutti i sub-fornitori che toccano dati o sistemi del tuo workload
• diritto di opporsi a nuovi sub-fornitori entro 30 giorni dalla notifica
• diritto di terminare senza penali se un sub-fornitore introduce rischio inaccettabile (es. data center in giurisdizione esposta a CLOUD Act mentre tu vuoi solo Europa)

5. Data location e data sovereignty

DORA non impone data residency in Europa, ma in combinato disposto con GDPR + decisioni di adeguatezza + giurisdizioni esposte ad accessi extraterritoriali (USA, Cina, Russia), il regolatore italiano si aspetta che tu sappia dove finiscono i dati. La clausola minima:

• elenco delle giurisdizioni in cui i dati possono essere processati
• divieto di trasferimento in giurisdizioni nuove senza notifica
• riferimento esplicito alle decisioni di adeguatezza GDPR (EU-US Data Privacy Framework, UK adequacy)

6. TLPT readiness

Threat-Led Penetration Testing è obbligatorio (con cadenza triennale) per le entità “significative” (banche grandi, IORP, alcuni asset manager). I framework di riferimento sono TIBER-EU e i suoi declinati nazionali. Per il fornitore: contratto che gli imponga di cooperare quando il tuo TLPT entra nel suo perimetro. Senza questa clausola, il provider può legittimamente respingere il red team — e tu sei bloccato.

Cosa cambia per il fornitore (lato vendor)

Se sei dal lato vendor — un SaaS B2B che ha clienti bancari/fintech europei — DORA non si applica direttamente a te (salvo designazione CTPP), ma diventa una condizione di mercato. I tuoi clienti devono mettere il tuo nome nel Register of Information con classificazione “supports a critical or important function” o no. Se la classificazione è sì, e tu non sei pronto, perdi il rinnovo.

Tre azioni concrete da fare ora se vendi software a banche europee:

1. Prepara un DORA pack standardizzato: politiche di security, SOC2 Type II o ISO 27001 attivo, attestazione TIBER-EU se applicabile, runbook exit, lista sub-fornitori. I clienti lo chiederanno via questionario; risparmi 40 ore per cliente se hai già il pack pronto.
2. Aggiorna i contratti standard con le 6 clausole sopra in forma “preferred default”. Negoziale al ribasso solo dove serve.
3. Mappa i tuoi sub-fornitori critici (CDN, cloud, monitoring, email): per ognuno, hai documentazione, audit recente, residency commitment? Se no, è il momento di chiederla.

Il punto cieco italiano

Una cosa che nei progetti DORA si vede spesso: gli istituti medi italiani sottostimano il peso del Register di B.03.01 (chain di sub-outsourcing). I fornitori grandi (hyperscaler, ERP enterprise) hanno strutture multi-tier di sub-vendor che generano 200-500 righe nel Register per un singolo contratto. Compilarlo a mano è impraticabile. Le piattaforme commerciali per il Register (Aravo, Prevalent, ServiceNow GRC) costano $80k-$200k/anno. Le banche piccole le rifuggono e finiscono per fare il Register in Excel — il che funziona finché qualcosa non si rompe.

Una strada intermedia esiste: foglio Excel ben strutturato + un team di compliance/IT che aggiorna trimestralmente con discipline. Il regolatore non chiede uno strumento commerciale, chiede un Register accurato. Quello che non perdona è l’incertezza di chi non sa chi sono i sub-fornitori del fornitore.

Cosa fare lunedì mattina

Apri il tuo Register of Information. Se non esiste, apri Excel. Censisci i primi 10 fornitori ICT per impatto sul tuo business. Per ognuno, compila la chain di sub-outsourcing chiedendola scritta al fornitore. Se rifiutano o tergiversano, hai il primo candidato al non-rinnovo della prossima trimestrale — e una conversazione necessaria con il legale prima ancora che con il vendor. Te lo dico io.