Il 17 gennaio 2025 è la data in cui il Regolamento UE 2022/2554 sulla resilienza operativa digitale (DORA) è diventato pienamente applicabile per banche, assicurazioni e operatori dei mercati finanziari nell'Unione. A oltre un anno dall'entrata in vigore, le compagnie italiane stanno completando il consolidamento operativo dei processi richiesti. Questo articolo descrive cosa è effettivamente cambiato nella gestione quotidiana del rischio ICT per una compagnia assicurativa di taglia media e quali sono le evidenze concrete che IVASS si aspetta in caso di ispezione.
Il contesto: perché DORA, perché ora
Prima di DORA, la regolamentazione UE sulla resilienza ICT del settore finanziario era frammentata: linee guida EBA sull'outsourcing (2019), linee guida EIOPA sulla cybersecurity (2020), linee guida ESMA sui cloud (2021), più normative nazionali (in Italia: IVASS Reg. 38/2018 per il governo societario, Reg. 24/2018 per il ramo cauzioni, Comunicato IVASS 2019 su cloud). Ogni autorità chiedeva cose simili ma con linguaggi e formati diversi.
DORA sostituisce tutta questa stratificazione con un framework armonizzato direttamente applicabile (regolamento, non direttiva — quindi non necessita di recepimento nazionale). Per le compagnie italiane il cambio non è stato sostituire processi esistenti, ma riorganizzarli secondo le 5 categorie DORA, in linguaggio e formati standardizzati a livello UE.
I cinque pilastri DORA in pratica
1. ICT risk management framework (art. 5-15)
Framework documentato di gestione del rischio ICT con: governance (responsabilità del CdA, ruolo del CISO/responsabile sicurezza), identificazione e classificazione asset ICT, business impact analysis, policy di protezione (accessi, crittografia, vulnerabilità), backup e disaster recovery testati. È il "cappello" che tiene insieme tutto il resto. Per chi viene dal Reg. 38/2018 IVASS è in larga parte materiale già esistente, da ri-categorizzare nei capitoli DORA.
2. Incident reporting (art. 17-23)
Classificazione tecnica degli incidenti ICT secondo i criteri RTS UE 2024/1772 (durata, geographic spread, data losses, criticità servizi, reputational impact, ecc.) e notifica obbligatoria a IVASS dei "major incidents" entro tempi precisi. Vedi sezione dedicata sotto.
3. Resilience testing (art. 24-27)
Programma annuale di test di resilienza commisurato alla dimensione: penetration test, vulnerability assessment, scenario-based testing su business continuity, end-to-end testing dei piani di disaster recovery. Per le compagnie significative scatta in più l'obbligo del TLPT (Threat-Led Penetration Test), test red-team avanzato basato su framework TIBER-EU, con cadenza triennale.
4. Third-party risk (art. 28-44)
Registro di tutti i fornitori ICT (non solo "esternalizzazioni" in senso stretto), valutazione concentration risk, exit strategy testate, monitoraggio continuo. I "critical ICT third-party providers" possono essere designati direttamente dalle ESA (EBA, EIOPA, ESMA) per oversight UE — al momento la designazione riguarda pochissimi hyperscale; nei prossimi anni si estenderà.
5. Information sharing (art. 45)
Partecipazione (opzionale ma incoraggiata) a iniziative di scambio informazioni su minacce cyber tra operatori finanziari. Per le compagnie italiane il riferimento è CERTFin (presso ABI Lab) e ENISA per il livello UE.
Il registro third-party: cosa c'è dentro e in che formato
Il registro è probabilmente l'evidenza più ricorrente nelle ispezioni DORA. La struttura è standardizzata dal Regolamento UE 2024/2956 (RT ESA — Register Template): ogni voce contiene 14 sezioni con dati anagrafici fornitore, descrizione servizio, criticità, livello di sostituibilità, paese di esecuzione, sub-outsourcing eventuali, SLA, condizioni contrattuali DORA, audit rights.
Per una compagnia assicurativa di taglia media, il registro tipico include 40-80 voci: fornitore di PAS (es. NewPicass 14.Net), provider cloud (AWS, Azure, Google Cloud), software di posta e collaborazione (Microsoft 365), CRM, sistemi attuariali e di riassicurazione, gateway di firma elettronica, conservatore digitale AgID, provider antifrode, sistemi di rating creditizio (Cerved, CRIF), gateway pagamenti SEPA, eccetera.
Il PAS è quasi sempre classificato come "fornitore ICT che supporta funzioni essenziali" (operatività polizze, sinistri, contabilità tecnica). Va nel registro con descrizione dettagliata, valutazione concentration risk, exit strategy documentata (in caso di sostituzione del PAS quanto tempo serve e come si esegue), audit rights contrattuali. Le condizioni minime di contratto DORA sono stringenti: il fornitore PAS deve garantire access rights e audit rights alle ESA, non solo alla compagnia cliente.
Incident reporting: cosa, a chi, in quanto tempo
Non tutti gli incidenti vanno riportati. La classificazione "major" si basa su 7 criteri quantitativi del RTS UE 2024/1772: clienti impattati, durata, geographic spread, perdite dati, criticità servizi colpiti, perdita economica, impatto reputazionale. Servono soglie superate su almeno 2 dei 7 criteri (semplificando, in realtà ci sono sotto-regole più articolate).
Per gli incidenti classificati come major:
- Initial notification entro 4 ore dalla classificazione (massimo 24h dal rilevamento), via portale dedicato IVASS.
- Intermediate report entro 72 ore con dettagli aggiuntivi (cause indagate, impatto stimato, azioni mitigative).
- Final report entro 1 mese con root cause analysis completa, impatto effettivo, lessons learned, miglioramenti del framework.
Le minacce cyber significative (anche se non sfociate in incidente effettivo) possono essere notificate su base volontaria. Il vantaggio: si entra in un flusso di information sharing con peer e autorità che spesso restituisce informazioni utili in tempi rapidi.
Cosa cambia se usi un PAS in cloud
Chi usa un PAS in cloud (sia SaaS multi-tenant come NewPicass 14.Net che private cloud) sotto DORA ha responsabilità specifiche aggiuntive:
- Due diligence rafforzata. Valutazione fornitore PAS + provider cloud sottostante (se diverso): ISO 27001, audit SOC 2, attestazioni AgID, certificazioni cybersecurity, evidenze di penetration test recenti.
- Concentration risk. Se il provider cloud sottostante (es. AWS) ospita anche altri servizi critici della compagnia, c'è una concentrazione che va monitorata. La normativa non vieta la concentrazione ma richiede consapevolezza e mitigations (es. multi-region deploy, exit plan).
- Continuous monitoring. SLA dichiarati vs effettivi, alert proattivi su degradi performance, dashboard con KPI di disponibilità.
- Exit strategy testata. Sapere in astratto che si può cambiare PAS non basta: serve aver eseguito (o quantomeno simulato) un'estrazione dati completa, valutato i tempi reali di migrazione, identificato i fornitori alternativi sul mercato.
Cosa avere pronto per un'ispezione DORA
Le ispezioni IVASS in chiave DORA si stanno standardizzando su un set di evidence pack che vengono richiesti in apertura ispezione:
- ICT risk management framework documentato, datato, approvato dal CdA. Include policy di sicurezza, schema governance, mappatura ruoli/responsabilità.
- Asset inventory e business impact analysis: mappatura sistemi → processi business → criticità (RTO/RPO).
- Third-party register in formato RT ESA aggiornato (ultima trasmissione alle ESA), con focus sui fornitori critici.
- Incident log degli ultimi 12 mesi con classificazione applicata, evidenze delle notifiche fatte (o motivazioni per cui non si è notificato).
- Test plan dell'anno corrente, evidenze dell'ultimo test eseguito (penetration test, BCP test, DR test), action plan derivante dai findings.
Su questi cinque, mancare uno rende già difficile la posizione; mancarne due o più espone a rilievi formali e possibili azioni sanzionatorie. La buona notizia: questi materiali sono strutturali, non si producono dall'oggi al domani. Le compagnie che hanno completato il setup nel 2024 li hanno ormai consolidati come parte della normale operatività di compliance.
Domande frequenti
DORA si applica alle compagnie sotto soglia o solo alle grandi?
DORA si applica a tutte le imprese di assicurazione e riassicurazione UE indipendentemente dalla dimensione — ma con principio di proporzionalità: gli obblighi tecnici si scalano in base alla complessità del rischio ICT. Per micro-imprese (Solvency II) e piccole compagnie ci sono semplificazioni significative su TLPT, gestione del registro third-party e frequenza test. La proporzionalità non riduce gli obblighi sostanziali (ICT risk framework, incident reporting, governance) ma adatta come implementarli.
Devo riportare TUTTI gli incidenti ICT a IVASS?
No, solo quelli classificati come 'major' secondo i criteri tecnici EBA/EIOPA/ESMA del RTS UE 2024/1772. La classificazione si basa su 7 criteri (durata, geographic spread, data losses, criticità servizi, reputational impact, ecc.) con soglie quantitative. Incidenti minori restano nei log interni; major incidents si notificano a IVASS entro 4 ore dalla classificazione, con report intermedio entro 72h e report finale entro 1 mese.
Il mio fornitore di PAS in cloud è considerato 'third-party critico'?
Dipende. La criticità è una valutazione della compagnia stessa: il PAS è normalmente un fornitore ICT 'che supporta funzioni essenziali o importanti'. Va inserito nel registro third-party e — se la compagnia decide che è critico — applicare i requisiti rafforzati (concentration risk assessment, exit strategy testata, monitoring continuo SLA). Le autorità europee mantengono un registro UE dei 'critical ICT third-party service providers' che possono designare a livello sovranazionale (per ora limitato a pochissimi provider hyperscale).
Cosa serve davvero per superare un'ispezione DORA di IVASS?
Le ispezioni DORA verificano sostanzialmente 5 evidence pack: (1) framework documentato di ICT risk management con responsabilità chiare, (2) catalogo asset ICT e processi business mappati, (3) registro third-party aggiornato e segnalato in formato ESA, (4) policy + log degli incidenti con classificazione applicata, (5) piani di resilience testing con risultati dell'ultimo test eseguito. Senza questi cinque, è praticamente impossibile dimostrare conformità.
DORA cambia qualcosa rispetto al pre-esistente IVASS Reg. 38/2018?
Sì, parecchio. Il Reg. 38/2018 e le linee guida IVASS su esternalizzazione (recepimento EBA Guidelines 2019) coprivano una parte degli aspetti DORA (outsourcing, sicurezza dei dati, BCP), ma DORA è più sistemico e prescrittivo: introduce TLPT (test pen avanzati simil red-team), incident reporting centralizzato a livello UE, registro third-party in formato standardizzato (RT ESA), oversight diretto delle ESA sui critical providers. Le compagnie devono allineare i framework esistenti, non sostituirli da zero.
Quando devo eseguire il TLPT (Threat-Led Penetration Test)?
Solo le compagnie significative (in genere: imprese di rilevanza sistemica o quelle con esposizioni elevate sui servizi ICT critici) sono soggette a TLPT obbligatorio, con cadenza minima triennale. Le compagnie minori restano obbligate a programmi di test di resilienza scalati alla loro complessità — penetration test classici, vulnerability assessment, scenario-based testing — ma non al TLPT formale TIBER-EU.