Quando si parla di DORA, il Regolamento europeo sulla resilienza operativa digitale del settore finanziario, in vigore dal 17 gennaio 2025, il dibattito pubblico tende a concentrarsi quasi esclusivamente sul mondo bancario.
Questo perché le banche sono il caso d’uso più citato, i fornitori di soluzioni le prendono come riferimento, i convegni costruiscono i panel attorno ai CISO degli istituti di credito. E, nel frattempo, le assicurazioni restano spesso sullo sfondo: presenti nell’obbligo normativo, ma poco rappresentate nella conversazione tecnica e operativa.
Indice degli argomenti
DORA assicurazioni: un settore con sfide ICT specifiche e spesso sottovalutate
Vero è che le compagnie assicurative e riassicurative hanno caratteristiche ICT molto specifiche, con sistemi legacy con decenni di storia, architetture costruite attorno al concetto di polizza e sinistro, processi batch notturni che alimentano calcoli attuariali complessi. Le stesse specifiche che rendono il percorso verso la conformità DORA sostanzialmente diverso da quello bancario.
Ignorare queste specificità significa affrontare il regolamento con strumenti inadeguati.
Quella che segue è dunque una guida pratica per i responsabili ICT, i CISO e i risk manager delle compagnie assicurative che devono trasformare gli obblighi DORA in un piano di lavoro concreto, tenendo insieme la pressione normativa, i vincoli tecnologici ereditati e la spinta inevitabile verso la modernizzazione cloud.
Il perimetro DORA per le compagnie assicurative: soggetti obbligati e ambito di applicazione
Il primo passo per qualsiasi organizzazione è capire con precisione se rientra nell’ambito di applicazione del regolamento e con quale livello di intensità.
DORA non si applica in modo uniforme a tutti i soggetti finanziari: prevede un principio di proporzionalità che calibra gli obblighi in funzione delle dimensioni, del profilo di rischio e della complessità operativa dell’entità.
Chi rientra nell’obbligo: imprese di assicurazione e riassicurazione
Il Regolamento DORA si applica esplicitamente alle imprese di assicurazione e riassicurazione ai sensi della Direttiva Solvency II, alle imprese di assicurazione di cui all’articolo 4 della stessa direttiva e agli intermediari assicurativi di maggiori dimensioni.
Rimangono invece fuori dall’ambito le microimprese, definite come quelle con meno di 10 dipendenti e un fatturato o totale di bilancio annuo non superiore a 2 milioni di euro.
Per le compagnie di medie e grandi dimensioni, l’obbligo è pieno e comprende tutti e cinque i pilastri del regolamento:
- gestione del rischio ICT;
- gestione degli incidenti;
- test di resilienza operativa digitale;
- gestione del rischio ICT di terze parti;
- condivisione delle informazioni.
Le imprese più piccole che rientrano nel perimetro possono applicare un framework semplificato per la gestione del rischio ICT, ma rimangono vincolate agli obblighi di notifica degli incidenti e alle disposizioni sui fornitori critici.
Il ruolo dell’IVASS come autorità competente in Italia
In Italia, l’autorità di vigilanza competente per il settore assicurativo è l’IVASS (Istituto per la Vigilanza sulle Assicurazioni), che esercita le funzioni di supervisione DORA in coordinamento con le Autorità europee di vigilanza, in particolare EIOPA (European Insurance and Occupational Pensions Authority) per il settore assicurativo.
Questo crea un livello di complessità aggiuntivo rispetto al mondo bancario, dove il perimetro di vigilanza è più consolidato.
Le compagnie assicurative devono confrontarsi con linee guida che provengono da due livelli, europeo e nazionale, e che in alcuni casi richiedono un’interpretazione coordinata.
I canali di notifica degli incidenti, i template di segnalazione e le procedure di escalation verso l’IVASS sono elementi che vanno definiti con precisione nel piano di conformità, e non possono essere semplicemente mutuati dai framework bancari senza adattamento.
Il nodo degli asset ICT nel settore assicurativo: tra legacy e trasformazione digitale
Se c’è un elemento che distingue nettamente le assicurazioni da altri soggetti finanziari, è la profondità e la pervasività dei sistemi legacy.
Non si tratta semplicemente di tecnologia datata: si tratta di architetture che nel corso di decenni si sono stratificate attorno ai processi di business assicurativi, accumulando logiche critiche difficilmente estraibili e documentate spesso in modo frammentario.
Sistemi legacy e policy engine: la specificità del core assicurativo
Il cuore tecnologico di una compagnia assicurativa tradizionale è il policy management system, il sistema che gestisce il ciclo di vita delle polizze: emissione, gestione, rinnovo, disdetta.
Attorno a questo nucleo gravitano il claims management system per la gestione dei sinistri, i motori attuariali per il calcolo dei premi e delle riserve, i sistemi di gestione degli agenti e delle reti distributive.
Molti di questi sistemi sono stati sviluppati tra gli anni Ottanta e i Duemila, spesso in linguaggi come COBOL o PL/I, su mainframe IBM o piattaforme AS/400. Negli anni sono stati oggetto di integrazioni progressive, patch, middleware di raccordo e layer applicativi moderni che si appoggiano a un nucleo che non è mai stato realmente riscritto.
Il risultato è un’architettura a cipolla: moderna in superficie, profondamente legacy nel core.
Dal punto di vista DORA, questa architettura pone sfide precise. Il requisito di mappatura completa degli asset ICT, previsto dal pilastro di gestione del rischio ICT, è particolarmente oneroso per le compagnie che non dispongono di un inventario aggiornato dei propri sistemi.
Le dipendenze tra componenti sono spesso implicite, documentate solo nella memoria dei tecnici più anziani o in documentazione obsoleta.
Prima ancora di parlare di resilienza, molte compagnie devono affrontare un lavoro di discovery e mappatura che può richiedere mesi.
La migrazione cloud nel settore assicurativo: opportunità e vincoli DORA
Parallelamente alla pressione normativa, il settore assicurativo sta vivendo una significativa accelerazione nella migrazione verso il cloud.
Le motivazioni sono molteplici: riduzione dei costi infrastrutturali, scalabilità elastica per i picchi di elaborazione (tipici nei periodi di rinnovo o a seguito di eventi catastrofali), accesso a servizi di intelligenza artificiale per l’automazione della liquidazione sinistri e la prevenzione delle frodi.
DORA non proibisce il cloud, ma lo regola con attenzione. I fornitori di servizi cloud che superano determinate soglie di utilizzo nel settore finanziario europeo possono essere designati come Fornitori Terzi ICT Critici (CTPP) e assoggettati a supervisione diretta da parte delle autorità europee.
Per le compagnie assicurative, questo significa che la scelta del provider cloud non è più una decisione puramente tecnica o commerciale: ha implicazioni normative dirette.
I contratti con i provider cloud devono rispettare i requisiti contrattuali minimi previsti da DORA: garanzie di disponibilità e continuità, diritti di audit, clausole di exit strategy, indicatori di performance verificabili.
Chi ha già stipulato contratti pluriennali con i grandi hyperscaler (AWS, Microsoft Azure, Google Cloud) deve verificare la conformità di questi accordi ai nuovi requisiti e, dove necessario, avviare rinegoziazioni che i fornitori non sempre accolgono con entusiasmo.
Gestione del rischio ICT per le assicurazioni: requisiti DORA e approccio pratico
Il pilastro della gestione del rischio ICT è il fondamento dell’intero impianto DORA. Richiede alle organizzazioni di dotarsi di un framework strutturato per identificare, classificare e gestire i rischi legati ai sistemi informatici, con un approccio che va ben oltre la tradizionale gestione della sicurezza informatica.
Il framework di risk management ICT richiesto da DORA
DORA richiede che le entità finanziarie adottino strategie, politiche, procedure e strumenti ICT che consentano una gestione del rischio solida ed efficiente.
Nel dettaglio, il framework deve coprire:
- identificazione e classificazione di tutti gli asset ICT e delle relative dipendenze;
- valutazione continua del rischio con aggiornamento almeno annuale;
- definizione di soglie di tolleranza al rischio approvate dall’organo di gestione;
- meccanismi di protezione e prevenzione;
- capacità di rilevamento delle anomalie e degli incidenti;
- piani di risposta e ripristino testati regolarmente.
Per una compagnia assicurativa, la classificazione degli asset ICT deve tenere conto della criticità in chiave assicurativa: il policy management system è certamente un asset critico, ma lo sono anche i sistemi di calcolo delle riserve tecniche (fondamentali per la solvibilità), i canali digitali di vendita (sempre più rilevanti per il business) e i sistemi di interfaccia con le reti agenziali.
La soglia di criticità va definita in relazione all’impatto che un’interruzione avrebbe sulla capacità di onorare gli obblighi verso gli assicurati.
Business continuity e scenari di stress per i sistemi assicurativi critici
DORA richiede piani di continuità operativa ICT che coprano scenari di crisi gravi, inclusi scenari climatici estremi, attacchi informatici su larga scala e guasti di fornitori critici.
Per il settore assicurativo, questo requisito ha una rilevanza particolare: le compagnie sono per definizione esposte a eventi catastrofali che possono generare picchi improvvisi e massivi di richieste di liquidazione sinistri.
Uno scenario di stress realistico per una compagnia danni, ad esempio, è quello di un evento atmosferico estremo che colpisce una vasta area geografica: migliaia di sinistri aperti simultaneamente, necessità di attivare unità mobili di liquidazione, picchi di traffico sui canali digitali.
I sistemi ICT devono essere dimensionati e testati per reggere questi carichi in condizioni di parziale degradazione dell’infrastruttura. I piani di continuità devono prevedere Recovery Time Objective (RTO) e Recovery Point Objective (RPO) differenziati per tipologia di sistema, con valori più stringenti per i sistemi di gestione sinistri rispetto, ad esempio, ai sistemi di reporting interno.
Terze parti ICT nel settore assicurativo: concentrazione del rischio e gestione dei fornitori
Il rischio di concentrazione è uno dei temi più delicati per il settore assicurativo.
A differenza delle banche, che spesso hanno sviluppato internamente competenze tecnologiche significative, molte compagnie assicurative (soprattutto di medie dimensioni) dipendono in misura elevata da un numero limitato di fornitori per i sistemi core.
La dipendenza dai grandi provider cloud e software verticali
Nel panorama assicurativo italiano ed europeo, esistono pochi fornitori di software verticale per la gestione delle polizze e dei sinistri. Questa concentrazione dell’offerta crea una dipendenza strutturale che DORA mette esplicitamente sotto la lente: se un fornitore critico subisce un incidente, quante compagnie ne risentono simultaneamente?
Il tema è ancora più acuto per i servizi cloud, dove AWS, Microsoft Azure e Google dominano il mercato e concentrano una quota crescente dell’infrastruttura del settore finanziario europeo.
DORA introduce il concetto di rischio sistemico da concentrazione: anche se una singola compagnia ha diversificato i propri fornitori, il fatto che l’intero settore si appoggi agli stessi hyperscaler crea un rischio collettivo che le autorità di vigilanza stanno monitorando con attenzione crescente.
Come costruire un registro dei fornitori ICT conforme a DORA
DORA richiede alle entità finanziarie di mantenere un registro aggiornato di tutti i contratti con fornitori terzi ICT, con un livello di dettaglio significativo.
Per ogni fornitore devono essere documentati: i servizi forniti e i sistemi supportati, la classificazione come critico o non critico, gli indicatori di performance contrattualizzati, le clausole di audit e di exit, i sub-fornitori rilevanti e la loro localizzazione geografica.
Per una compagnia assicurativa di medie dimensioni, questo registro può includere facilmente decine di fornitori, tra software house, provider cloud, società di outsourcing IT, fornitori di servizi di sicurezza gestita (MSSP) e provider di dati (banche dati catastrofali, sistemi di geolocalizzazione per i sinistri).
La costruzione di questo registro è spesso il primo cantiere concreto da aprire nel percorso verso la conformità DORA, perché senza una mappa chiara dei fornitori non è possibile valutare il rischio di concentrazione né verificare l’adeguatezza contrattuale.
Test di resilienza operativa digitale: cosa cambia per le assicurazioni
Il pilastro dei test di resilienza è quello che più di ogni altro richiede un cambio di mentalità.
Non si tratta più di eseguire vulnerability assessment periodici o penetration test occasionali: DORA impone un programma strutturato e continuo di test, con frequenze, metodologie e livelli di profondità differenziati in funzione del profilo di rischio dell’entità.
TLPT e vulnerability assessment: obblighi e pianificazione
Il livello più avanzato di test previsto da DORA è il Threat-Led Penetration Testing (TLPT), un esercizio di simulazione di attacco realistico condotto da provider certificati, basato su threat intelligence specifica per il settore e per l’organizzazione target. Le entità significative, generalmente le compagnie di maggiori dimensioni, sono obbligate a condurre TLPT almeno ogni tre anni.
Per le compagnie assicurative, la pianificazione dei TLPT richiede attenzione particolare alla scelta del perimetro di test. I sistemi core assicurativi sono spesso altamente interconnessi e un test invasivo sui sistemi di produzione può avere impatti difficili da controllare.
La pratica migliore è definire ambienti di test dedicati che replichino fedelmente la produzione, ma questa replica è particolarmente complessa per i sistemi legacy, dove le dipendenze implicite sono difficili da replicare in modo affidabile.
A un livello meno intensivo, tutte le entità nel perimetro DORA devono eseguire annualmente vulnerability assessment e penetration test sui sistemi critici, con documentazione dei risultati, dei remediation plan e del loro stato di avanzamento.
Anche qui, la mappa degli asset ICT è il prerequisito: non si può testare ciò che non si sa di avere.
Differenze operative rispetto al settore bancario
Le banche hanno generalmente una cultura del testing della sicurezza più matura, alimentata da anni di requisiti stringenti imposti da Banca d’Italia e dalla BCE.
Per molte compagnie assicurative, il programma di test DORA rappresenta un salto significativo rispetto alle pratiche precedenti, che in diversi casi si limitavano a vulnerability scan automatizzati e a penetration test condotti con frequenza irregolare.
Un’altra differenza rilevante riguarda i sistemi di pagamento e liquidazione. Le banche hanno infrastrutture di pagamento altamente regolamentate e testate, con SLA stringenti e procedure di failover consolidate.
Le compagnie assicurative, invece, gestiscono flussi di pagamento (premi in entrata, liquidazioni in uscita) attraverso sistemi spesso meno robusti, integrati con banche di appoggio e reti di pagamento che introducono dipendenze esterne aggiuntive da mappare e testare.
Roadmap pratica verso la conformità DORA per una compagnia assicurativa
La conformità DORA non è un progetto con una data di fine: è un programma continuativo che richiede governance, risorse e un piano di lavoro strutturato per fasi.
Per una compagnia assicurativa che si trova oggi in una situazione di conformità parziale, il percorso più efficace si articola tipicamente in tre orizzonti temporali.
Nel breve termine, i primi sei mesi, la priorità è la discovery e la baseline: censimento completo degli asset ICT, costruzione del registro dei fornitori, gap analysis rispetto ai requisiti DORA, nomina formale delle responsabilità interne.
Questo lavoro è spesso sottovalutato in termini di impegno, ma è il fondamento su cui si costruisce tutto il resto. Senza una mappa accurata dei sistemi e dei fornitori, qualsiasi piano successivo poggia su basi fragili.
Nel medio termine, tra sei e diciotto mesi, si lavora sulla struttura: aggiornamento delle policy di gestione del rischio ICT, revisione e negoziazione dei contratti con i fornitori critici, avvio del programma di test strutturato, implementazione dei processi di incident management e notifica.
È in questa fase che si affrontano le questioni più complesse legate ai sistemi legacy: non necessariamente sostituendoli, i tempi e i costi di una migrazione core sono proibitivi nel breve, ma costruendo attorno a loro i layer di monitoraggio, protezione e continuità che DORA richiede.
Nel lungo termine, oltre i diciotto mesi, si consolida e si migliora: i TLPT vengono pianificati e condotti, il registro dei fornitori viene mantenuto aggiornato, le metriche di resilienza vengono monitorate e riportate all’organo di gestione, le lezioni apprese dagli incidenti alimentano il miglioramento continuo del framework.
Un elemento trasversale a tutte le fasi è il coinvolgimento dell’organo di amministrazione: DORA attribuisce responsabilità esplicite al board nella supervisione della gestione del rischio ICT. Per molte compagnie assicurative, questo rappresenta un cambiamento culturale significativo, che richiede formazione specifica degli amministratori e la costruzione di un sistema di reporting ICT che traduca i dati tecnici in linguaggio strategico comprensibile al vertice.
Il settore assicurativo italiano ha le competenze, la solidità e la motivazione per affrontare questa sfida.
Ciò che manca, in molti casi, è la consapevolezza che DORA non è un obbligo da assolvere con il minimo sforzo, ma un’opportunità per costruire una resilienza digitale che protegge non solo la conformità normativa, ma la fiducia degli assicurati e la continuità del business nel lungo periodo.
