1. Introduzione

Un grande gruppo finanziario che opera in tutta l’Unione europea raramente opera come un’unica entità giuridica. Opera come una capogruppo e un ventaglio di controllate, tipicamente una società regolamentata per Stato membro, ciascuna titolare della propria licenza, ciascuna rispondente alla propria autorità di vigilanza nazionale, ciascuna plasmata dalle regole locali che si aggiungono a quelle europee comuni. La ragione è in parte storica, in parte regolamentare e in parte commerciale: le licenze sono nazionali, le autorità di vigilanza sono nazionali, e un’entità locale con un nome locale e un bilancio locale è più facile da autorizzare, da vigilare e tramite cui vendere. Ciò che il gruppo centralizza, quasi sempre, è la tecnologia dell’informazione. È dispendioso costruire la stessa piattaforma di core banking, lo stesso sistema di amministrazione delle polizze, lo stesso data center, lo stesso centro operativo per la sicurezza undici volte, perciò il gruppo li costruisce una sola volta, nella capogruppo o in una società IT di gruppo dedicata, e li fornisce a ogni controllata come servizio condiviso. L’attività è locale; l’impianto è centrale.

Il Digital Operational Resilience Act attraversa questo assetto in un modo facile da trascurare finché non viene implementato. DORA, Regulation (EU) 2022/2554, si applica dal 17 gennaio 2025, e la sua unità di base è la singola entità regolamentata, non il gruppo (DORA, Arts 1–2). Ciascuna controllata deve mantenere in proprio un quadro di gestione del rischio informatico, classificare e segnalare i propri incidenti gravi, testare la propria resilienza, tenere il proprio registro delle terze parti ICT e governarle sotto il proprio consiglio di amministrazione (DORA, Arts 5–30). Al regolamento non importa che la controllata non abbia costruito la piattaforma su cui opera e non possa modificarla; il dovere è comunque della controllata. E quando il gruppo si rivolge all’entità che ha effettivamente costruito la piattaforma, la capogruppo, scopre che DORA ha già denominato la relazione: una società di gruppo che fornisce ICT alle entità regolamentate del proprio gruppo è un fornitore infragruppo di servizi ICT, e DORA la tratta, per quasi ogni scopo, come una terza parte (DORA, Art 3(20)).

Ne derivano due problemi, che sono l’oggetto di questo articolo. Il primo è un disallineamento tra dove risiede il dovere e dove risiede il controllo. DORA pone il dovere sulla controllata e lascia il controllo alla holding, e la holding, se non è essa stessa un’entità finanziaria regolamentata, è al di fuori della portata diretta del regolamento, toccata solo attraverso i contratti e la supervisione che le sue controllate sono obbligate a imporle. Chiamiamo questo l’asimmetria tra conformità e controllo, e la Sezione 3.1 ne fa l’anatomia. Il secondo è che centralizzare l’ICT concentra il rischio. Un nucleo condiviso è un punto singolo il cui guasto non è il problema di una controllata ma il problema di ogni controllata in una volta sola, un evento correlato di modo comune anziché uno indipendente e diversificabile, e poiché ciascuna controllata colpita deve segnalare alla propria autorità di vigilanza, un singolo guasto tecnico diventa un ventaglio di segnalazioni regolamentari simultanee in tutta l’Unione. La Sezione 3.2 lo espone e la Sezione 4 lo modella.

Il contributo è una diagnosi e una progettazione, non un commento giuridico. Enunciamo chiaramente i due problemi strutturali, forniamo un piccolo modello quantitativo di quello della concentrazione affinché un gruppo possa vedere come il proprio grado di centralizzazione scambi l’affidabilità per entità con il rischio correlato a livello di gruppo (Sezione 4), e analizziamo che cosa i principali obblighi di DORA — il registro e i contratti (Sezione 5), la segnalazione degli incidenti (Sezione 6), i test (Sezione 7) e la governance (Sezione 8) — richiedano in particolare a un gruppo centralizzato. La Sezione 9 propone un modello operativo di destinazione che soddisfa il regolamento mantenendo l’efficienza che ha indotto il gruppo a centralizzare in primo luogo. Le Sezioni da 10 a 12 rispondono alle obiezioni, enunciano i limiti e concludono. La domanda di fondo è: come fa un gruppo a conformarsi, entità per entità, a un regolamento che presuppone che ogni entità controlli il proprio ICT, quando in realtà un unico nucleo condiviso le controlla tutte?

2. Che cosa richiede DORA, e a chi

2.1 I cinque pilastri

DORA organizza la resilienza operativa di un’entità finanziaria in cinque aree, e vale la pena enunciarle una volta perché il problema del gruppo tocca tutte e cinque. La prima è la gestione del rischio informatico (Capo II, Arts 5–16): un quadro di governance e controllo, di competenza dell’organo di gestione, che copre identificazione, protezione, rilevamento, risposta e ripristino, con un quadro semplificato più leggero disponibile per talune entità minori (Art 16). La seconda è la gestione e segnalazione degli incidenti connessi all’ICT (Capo III, Arts 17–23): un processo per rilevare e gestire gli incidenti, una classificazione armonizzata della loro gravità (Art 18) e un obbligo di segnalare gli incidenti gravi all’autorità competente secondo un calendario fisso di segnalazioni iniziali, intermedie e finali (Art 19). La terza è il test della resilienza operativa digitale (Capo IV, Arts 24–27): un programma di test regolari per ogni entità e test avanzati di penetrazione guidati dalle minacce (TLPT) almeno ogni tre anni per quelle che le autorità individuano come significative (Arts 26–27). La quarta è la gestione del rischio informatico derivante da terze parti (Capo V, Arts 28–44), che è il punto in cui la struttura di gruppo morde più a fondo e che trattiamo diffusamente più avanti. La quinta è la condivisione delle informazioni sulle minacce informatiche (Capo VI, Art 45), che è volontaria e non deve trattenerci qui.

2.2 Il principio dell’entità

La caratteristica di DORA che governa tutto in questo articolo è che i suoi obblighi si attaccano alla singola entità autorizzata. Un gruppo bancario non è autorizzato; lo sono le sue controllate bancarie. La disposizione di DORA sull’ambito di applicazione elenca i tipi di entità finanziaria che vincola, e ciascuna è un’entità titolare di una licenza (Art 2). La conseguenza è che la conformità viene valutata, e fatta rispettare, un’entità alla volta, dall’autorità competente di quell’entità. Non esiste una licenza di gruppo per conformarsi in nome delle controllate, né un’unica autorità di vigilanza europea cui il gruppo nel suo complesso risponda della propria resilienza. Il registro delle informazioni è l’unico luogo in cui la dimensione di gruppo è esplicita: un’entità deve tenerlo non solo al proprio livello ma, qualora faccia parte di un gruppo, anche a livello subconsolidato e consolidato (Art 28(3)), cosicché un’entità consolidante assembli una visione a livello di gruppo. Ma il dovere di conformarsi, di governare, di segnalare e di testare resta della singola controllata, e non può essere assolto additando verso l’alto la capogruppo.

2.3 L’ICT infragruppo è ICT di terze parti

La seconda caratteristica che governa questo articolo è il trattamento che DORA riserva all’ICT fornito dall’interno del gruppo. Sarebbe naturale presumere che i servizi che una controllata riceve dalla propria capogruppo siano interni, e al di fuori del regime sulle terze parti che DORA rivolge ai fornitori esterni. DORA preclude questa presunzione. Definisce un fornitore infragruppo di servizi ICT come un’impresa che fa parte del gruppo e fornisce servizi ICT prevalentemente a entità dello stesso gruppo (Art 3(20)), e porta tale fornitore all’interno delle regole sulle terze parti: la controllata ricevente deve registrare l’accordo nel proprio registro (Art 28(3)), governarlo mediante un contratto scritto recante le disposizioni obbligatorie (Art 30), valutare la concentrazione che esso crea (Art 29) e disporre di strategie di uscita per esso qualora supporti una funzione essenziale o importante (Art 28(8)). La natura infragruppo della relazione è qualcosa da registrare, non una ragione di esenzione. In breve, quando la capogruppo fornisce la piattaforma, DORA legge la capogruppo come fornitore terzo e la controllata come suo cliente, con tutti gli obblighi che un cliente di un fornitore esterno di cloud o software dovrebbe assumere. Un gruppo che tratta la relazione come una questione puramente interna, governata da un catalogo di servizi e da un riaddebito infragruppo anziché da un contratto conforme a DORA, non è conforme.

3. Il modello della holding centralizzata

La Figura 1 disegna il modello di cui tratta questo articolo. Una holding o società IT di gruppo gestisce il nucleo ICT critico e lo fornisce a diverse controllate regolamentate, ciascuna nel proprio Stato membro e ciascuna vigilata dalla propria autorità nazionale competente. Le frecce dei servizi corrono verso il basso dal nucleo; le frecce della vigilanza e della segnalazione degli incidenti corrono da ciascuna controllata alla propria autorità. I due problemi dell’Introduzione sono visibili nell’immagine: ciò che tiene insieme il gruppo, il nucleo, è fornito da un’entità che i regolatori raggiungono solo indirettamente, e un guasto in cima al diagramma si propaga a ogni ramo in una volta sola mentre la segnalazione si frammenta tra ogni autorità in fondo.

3.1 L’asimmetria tra conformità e controllo

In un’entità da manuale, l’impresa che porta il dovere DORA gestisce anche i sistemi, cosicché il dovere e le leve per assolverlo sono nelle stesse mani. Il gruppo centralizzato li separa. La controllata porta il dovere, perché è l’entità autorizzata, ma non gestisce il nucleo, non può applicarvi patch, non può sceglierne l’architettura, non può fissarne gli obiettivi di ripristino e non può, da sola, testarlo. La holding gestisce il nucleo e detiene tutte quelle leve, ma non porta alcun dovere DORA diretto se non è essa stessa un’entità finanziaria autorizzata, cosa che una pura società IT o holding di solito non è. Il regolamento anticipa esattamente questo e lo aggira: raggiunge la holding attraverso la controllata, imponendo alla controllata di imporre, per contratto, i diritti di accesso, audit, cooperazione, notifica degli incidenti, test e uscita che consentono alla controllata di assolvere un dovere su sistemi che non possiede (Art 30). La conformità della controllata dipende perciò dal suo potere contrattuale sulla propria capogruppo, il che è una cosa insolita e scomoda da dover esercitare.

L’asimmetria ha un risvolto pratico tagliente. DORA dice al consiglio di amministrazione di una controllata che esso è responsabile in ultima istanza del rischio informatico dell’entità e non può delegare tale responsabilità (Art 5(2)); eppure l’influenza reale del consiglio sul nucleo che porta la maggior parte di quel rischio passa attraverso una funzione di gruppo che risponde alla capogruppo, non a esso. Se il consiglio si limita a fidarsi del centro, ha delegato nella sostanza ciò che non può delegare per legge. Se cerca di esercitare una vigilanza genuina, ha bisogno di informazioni, garanzie e diritti che una relazione infragruppo informale non fornisce. La risposta progettuale, sviluppata nella Sezione 9, è conferire alla relazione la formalità che avrebbe con un fornitore esterno proprio affinché il consiglio della controllata possa vedere dentro il nucleo e contestarlo, e costruire il quadro di gruppo in modo che la vigilanza di ciascun consiglio sia un input reale anziché una cortesia.

3.2 Il rischio di concentrazione

Il secondo problema è che il nucleo condiviso è una concentrazione. DORA nomina direttamente il rischio di concentrazione e richiede a ciascuna entità di valutarlo prima di contrattare e di tenerlo sotto osservazione, includendo esplicitamente il rischio derivante dagli accordi infragruppo e dai fornitori difficili da sostituire (Art 29). In un gruppo centralizzato la concentrazione è pressoché totale: un nucleo, un centro operativo per la sicurezza, un insieme di dispositivi di ripristino, al servizio di ogni entità regolamentata del gruppo. L’argomento dell’efficienza a suo favore è esattamente il suo pericolo. La stessa unica piattaforma che è più economica da costruire e più facile da proteggere una volta sola è anche un punto singolo il cui guasto è condiviso da tutti coloro che vi dipendono. Laddove un gruppo federato di controllate, ciascuna con il proprio ICT, subirebbe i guasti uno alla volta, indipendentemente, un gruppo centralizzato li subisce insieme, perché i guasti hanno una causa comune.

Questa è la distinzione tra guasto indipendente e guasto di modo comune su cui la letteratura sulla sicurezza e sul rischio sistemico insiste da tempo (Perrow, 1999; Leveson, 2011; ESRB, 2022). I guasti indipendenti si diversificano: la probabilità che molti cadano in una volta sola è il prodotto di piccole probabilità, ed è infinitesimale. I guasti di modo comune non si diversificano: quando la causa condivisa cede, tutto ciò che sta a valle di essa cede insieme, e la resilienza del gruppo è limitata dalla resilienza del suo componente condiviso più debole, non migliorata dal numero di entità che distribuiscono il carico. Concentrare l’ICT non distribuisce il rischio tra le controllate; accoppia le controllate a un rischio unico. La prossima sezione rende preciso il punto.

4. Un modello minimo del rischio di gruppo correlato

Il modello è uno schizzo, inteso a rendere esplicito il meccanismo e a permettere a un gruppo di ragionare sul proprio grado di centralizzazione, non una stima di rischio calibrata. Separa il guasto che una controllata subisce per conto proprio dal guasto che l’intero gruppo subisce insieme, e mostra come la centralizzazione sposti il rischio dal primo tipo al secondo.

4.1 La compromissione per entità

Si consideri un gruppo di $n$ controllate regolamentate. Una quota $c$ di esse, che tratteremo come la probabilità che una data controllata dipenda dal nucleo condiviso della holding per una funzione essenziale o importante, è collegata al nucleo; chiamiamo $c$ il rapporto di centralizzazione. In un dato periodo il nucleo condiviso subisce un’interruzione critica con probabilità $p_0$. Si tratta di un evento di modo comune: quando si verifica, ogni controllata collegata è compromessa nello stesso momento, per la stessa ragione. Indipendentemente dal nucleo, l’ICT locale di ciascuna controllata si guasta nel periodo con probabilità $q$. Una controllata collegata è perciò compromessa quando si guasta o il nucleo o il suo ICT locale,

che è la cifra che il consiglio di una singola controllata vede quando guarda il proprio registro degli incidenti. La centralizzazione che collega la controllata a un nucleo ben gestito tende ad abbassare $q$, perché una piattaforma condivisa e professionale è di solito gestita meglio di una piccola piattaforma locale, cosicché $u$ può calare man mano che il gruppo si centralizza. Guardata un’entità alla volta, la centralizzazione migliora la resilienza, e questa è la metà onesta dell’argomento dell’efficienza.

4.2 Dall’indipendente al correlato

Il gruppo non vive il proprio rischio un’entità alla volta. Ciò che conta per il gruppo, e per i regolatori, è la probabilità che diverse controllate siano compromesse nello stesso momento, perché quello è l’evento sistemico, transfrontaliero e simultaneamente segnalabile. Senza un nucleo condiviso, l’unico modo in cui due controllate cadono insieme è che due di esse si guastino localmente nello stesso periodo, una coincidenza di eventi indipendenti la cui probabilità è dell’ordine di $q^{2}$, cioè piccola al secondo ordine. Con un nucleo condiviso, una singola interruzione del nucleo abbatte ogni controllata collegata in una volta sola, cosicché la probabilità di un evento simultaneo e multi-entità è dell’ordine della probabilità di guasto del nucleo stesso,

dove la parentesi è la probabilità che almeno due delle $n$ controllate siano collegate, cosicché un guasto del nucleo ne comprometta almeno due in una volta sola. Il punto non è la forma esatta ma l’ordine: la centralizzazione converte la probabilità di un evento a livello di gruppo da secondo ordine in una piccola probabilità locale a primo ordine nella probabilità del nucleo. Un nucleo che si guasta solo di rado è comunque, come fonte di guasto simultaneo e multi-entità, assai più pericoloso della somma dei rischi indipendenti delle controllate, perché i suoi guasti sono condivisi anziché distribuiti. La Figura 2 traccia questa probabilità rispetto al rapporto di centralizzazione per le due architetture: un gruppo federato, con ciascuna controllata sui propri ICT, la mantiene piatta quasi a zero, mentre quella di un gruppo centralizzato si solleva al di sopra di quella linea di base man mano che una parte maggiore del gruppo viene collegata al nucleo condiviso.

4.3 Il moltiplicatore del carico regolamentare

C’è una seconda conseguenza dell’evento di modo comune che è specifica di DORA e della struttura di gruppo, e riguarda non la resilienza ma la segnalazione. Poiché ciascuna controllata è un’entità regolamentata distinta che risponde alla propria autorità competente (Sezione 2.2), un singolo guasto del nucleo non genera una sola segnalazione di incidente; ne genera una da ogni controllata che compromette, ciascuna a un’autorità diversa, ciascuna secondo i tempi di quell’autorità, eventualmente nella lingua di quell’autorità. Il numero atteso di segnalazioni simultanee di incidente grave innescate da un’unica interruzione del nucleo è semplicemente il numero atteso di controllate collegate,

cosicché un gruppo di una dozzina di controllate pienamente collegate a un nucleo condiviso trasforma un singolo evento tecnico in una dozzina di segnalazioni regolamentari parallele in una dozzina di giurisdizioni, entro il termine della segnalazione iniziale di DORA, tutte descriventi la stessa causa radice. Questo moltiplicatore del carico regolamentare è invisibile nella pianificazione di una singola controllata e diventa visibile solo a livello di gruppo, che è esattamente il livello per cui DORA non rende responsabile alcuna singola entità. È l’argomento pratico più forte a favore del coordinamento a livello di gruppo che la Sezione 9 costruisce.

5. Il registro, la concentrazione e i contratti

Il capo di DORA sulle terze parti dà al gruppo centralizzato tre strumenti che deve usare, e ciascuno di essi, applicato onestamente, fa emergere i problemi di cui sopra anziché nasconderli.

Il registro delle informazioni (Art 28(3)) è un inventario di ogni accordo contrattuale per i servizi ICT, tenuto secondo un modello standard fissato dalle norme tecniche di attuazione (ITS 2024/2956) e distinguente gli accordi che supportano funzioni essenziali o importanti da quelli che non lo fanno. Per un gruppo centralizzato il registro è il luogo in cui la dipendenza infragruppo diventa innegabile: il registro di ogni controllata elenca la holding come fornitore dei propri servizi critici, e il registro consolidato che il gruppo deve assemblare (Art 28(3)) mostra, su un’unica pagina, che un solo fornitore sta dietro le funzioni critiche dell’intero gruppo. Un gruppo che compila il registro come si deve ha documentato la propria concentrazione; un gruppo tentato di lasciar fuori l’accordo infragruppo, nella teoria che sia interno, viola l’obbligo del registro e allo stesso tempo si acceca proprio rispetto al rischio che il registro esiste per mostrare. La Tabella 1 espone i tre livelli ai quali il registro è tenuto e a che cosa serve ciascuno.

La valutazione del rischio di concentrazione (Art 29) pone poi la domanda che il registro solleva: che cosa succede se questo fornitore si guasta o deve essere sostituito? Per un fornitore esterno la risposta è un’analisi di sostituzione; per il nucleo infragruppo è più difficile, perché il nucleo di solito non è affatto sostituibile su alcun orizzonte ragionevole, essendo stato costruito una sola volta per l’intero gruppo. DORA non vieta la concentrazione, ma richiede all’entità di vederla e di ponderarla, e la risposta onesta di un gruppo centralizzato, ossia che il nucleo è un singolo punto di guasto per il gruppo ed è di fatto insostituibile nel breve termine, è essa stessa la constatazione che dovrebbe guidare l’investimento in resilienza e la pianificazione dell’uscita che il regolamento parimenti richiede (Art 28(8)).

Gli accordi contrattuali (Art 30) sono il meccanismo con cui la controllata acquisisce potere su un nucleo che non possiede. DORA prescrive un minimo di disposizioni per ogni accordo e un elenco più lungo per gli accordi che supportano funzioni essenziali o importanti: descrizioni complete dei livelli di servizio, ubicazioni del servizio e dei dati, diritti di accesso, ispezione e audit, obblighi di assistenza in caso di incidenti, cooperazione con le autorità, diritti di monitoraggio, condizioni sul subappalto (ora dettagliate dagli RTS 2025/532) e strategie di uscita documentate (Arts 28(8), 30(2)–(3)). Il contesto infragruppo non allenta nulla di tutto ciò. L’istruzione progettuale, sviluppata più avanti, è redigere il contratto infragruppo come se la controparte fosse un fornitore esterno a condizioni di mercato, perché è l’unico modo in cui il consiglio della controllata ottiene, sulla carta, i diritti che l’asimmetria altrimenti gli nega.

6. Un incidente, molti regolatori

Il regime di segnalazione degli incidenti è il punto in cui il moltiplicatore del carico regolamentare della Sezione 4 diventa un problema operativo. DORA richiede a un’entità di classificare un incidente connesso all’ICT a fronte di criteri armonizzati e, se è grave, di notificarlo alla propria autorità competente con una segnalazione iniziale entro un termine breve, poi una segnalazione intermedia man mano che il quadro si consolida, poi una segnalazione finale con la causa radice (Arts 18–19). I criteri di classificazione, le soglie e i modelli sono armonizzati in tutta l’Unione dalle norme di livello 2, il che è un aiuto; ma le segnalazioni vanno comunque all’autorità di ciascuna entità, e il cronometro parte per ciascuna entità quando quell’entità ne viene a conoscenza.

Per un gruppo centralizzato un singolo guasto del nucleo è, simultaneamente, un incidente grave per ogni controllata che compromette. Ciascuna controllata deve classificarlo, ciascuna deve decidere se supera la soglia di gravità, e ciascuna deve presentare la segnalazione, alla propria autorità, entro il termine. Se le controllate classificano in modo indipendente e redigono in modo indipendente, il gruppo produce una dispersione di segnalazioni che descrivono lo stesso evento in modo incoerente, arrivano in momenti diversi ed espongono il gruppo all’ovvia domanda di vigilanza del perché le sue entità non concordino su che cosa sia accaduto al loro sistema condiviso. La modalità di fallimento non è la sotto-segnalazione ma la sovra-segnalazione incoerente. Il rimedio non è centralizzare la segnalazione, cosa che DORA non consente, poiché l’obbligo è di ciascuna entità, ma centralizzare i fatti: un’unica tassonomia degli incidenti, un’unica determinazione della causa radice e un unico cronometro gestiti dal centro operativo per la sicurezza del gruppo, che alimentano un nucleo coerente di fatti in ciascuna segnalazione delle singole controllate, che la funzione responsabile di ciascuna controllata fa poi propria, firma e trasmette alla propria autorità. Il gruppo fornisce la verità; ciascuna entità fornisce la segnalazione. La Sezione 9 lo rende concreto.

7. Testare un nucleo condiviso

Il regime di test di DORA ha due livelli, e la struttura di gruppo complica entrambi. Il livello di base richiede a ogni entità di condurre un programma di test di resilienza, proporzionato alle sue dimensioni e al suo rischio (Art 24–25). Il livello avanzato richiede test di penetrazione guidati dalle minacce, all’incirca ogni tre anni, per quelle entità che le autorità individuano come abbastanza significative da giustificarli (Arts 26–27). In un gruppo centralizzato l’oggetto che vale la pena testare è in gran parte il nucleo condiviso, perché è lì che si trovano i sistemi critici e la concentrazione; ma l’obbligo di testare grava sulle controllate, che non gestiscono il nucleo.

Testare lo stesso nucleo condiviso separatamente per ciascuna controllata sarebbe dispendioso e, peggio, rischioso, poiché il ripetuto red-teaming dal vivo di una piattaforma di produzione che serve l’intero gruppo moltiplica la probabilità che un test stesso provochi un incidente. DORA prevede i fornitori condivisi e consente, a determinate condizioni, che i test siano messi in comune o condotti congiuntamente qualora più entità si affidino allo stesso fornitore ICT o appartengano allo stesso gruppo e condividano sistemi, cosicché un unico test adeguatamente governato del nucleo condiviso possa soddisfare le entità partecipanti (Arts 26–27 e le norme tecniche sul TLPT). La messa in comune non dissolve l’obbligo individuale: ciascuna controllata partecipante deve comunque essere parte dell’accordo, deve comunque assicurarsi che il test copra le proprie funzioni critiche e deve comunque agire sulle risultanze. Ma consente al gruppo di testare la cosa che conta davvero, il nucleo, una volta e bene, anziché molte volte e male. L’implicazione progettuale è che il gruppo dovrebbe pianificare i test dal nucleo verso l’esterno, includere nel perimetro del test condiviso le funzioni critiche di ciascuna controllata e detenere i diritti contrattuali (Art 30) che consentono a una controllata di esigere che il proprio fornitore, qui la propria capogruppo, partecipi.

8. Una responsabilità che non può essere delegata verso l’alto

Il filo che attraversa ogni sezione è l’insistenza di DORA sul fatto che l’organo di gestione di ciascuna entità porta la responsabilità ultima del rischio informatico di quell’entità, e che tale responsabilità non può essere affidata per contratto né delegata (Art 5). In un gruppo centralizzato questa è la disposizione più in tensione con la realtà operativa, perché la realtà è che le controllate hanno delegato l’ICT, nella sostanza, al gruppo. DORA non vieta al gruppo di gestire l’ICT centralmente; ciò che vieta è che il consiglio della controllata tratti quell’assetto come una ragione per smettere di essere responsabile. Il consiglio deve conservare una comprensione sufficiente del nucleo da cui dipende, informazioni sufficienti su come è gestito e su come sta fallendo, e un potere contrattuale e di governance sufficiente per contestare e, in extremis, per agire, così che la sua responsabilità statutaria sia reale anziché nominale.

Questo va contro un istinto centralizzatore naturale e di solito ben intenzionato, ossia risparmiare ai consigli delle controllate il dettaglio tecnico e lasciare che siano gli esperti al centro a occuparsene. DORA richiede l’opposto: che ciascun consiglio di controllata sia attrezzato e obbligato a governare un rischio che ha esternalizzato alla propria capogruppo. Le conseguenze pratiche sono una linea di reporting dalla funzione ICT di gruppo verso ciascun consiglio di controllata, non solo verso la capogruppo; una competenza sul rischio informatico a livello di consiglio presso ogni controllata, non solo al centro; e un quadro di gruppo progettato in modo che la vigilanza di ciascun consiglio sia un punto di controllo genuino. Un gruppo che costruisce il nucleo condiviso ma lascia i consigli delle controllate disinformati ha creato l’asimmetria tra conformità e controllo nella sua forma più pericolosa, in cui le persone responsabili per legge sono, di fatto, le meno in grado di esercitare la responsabilità.

9. Un modello operativo di destinazione per il gruppo

La progettazione che risponde ai due problemi non è decentralizzare l’ICT, cosa che butterebbe via l’efficienza e, secondo il modello della Sezione 4, potrebbe persino non migliorare la resilienza del gruppo una volta che il nucleo condiviso è ben gestito. È mantenere il nucleo centrale e avvolgerlo nella struttura che DORA richiede, così che il dovere e il controllo siano riconnessi dalla governance e dal contratto anziché dalla proprietà. Dall’analisi discendono cinque mosse.

Gestire un unico quadro di rischio informatico di gruppo, visibile a ogni consiglio. Costruire il quadro di gestione del rischio informatico una sola volta, a livello di gruppo, secondo lo standard che DORA e i suoi RTS richiedono (Art 6; RTS 2024/1774), ma collegarne il reporting all’organo di gestione di ciascuna controllata e non solo a quello della capogruppo, così che ciascun consiglio governi il rischio condiviso con informazioni reali. Il quadro è centrale; la responsabilità resta distribuita, come il regolamento esige.

Contrattare con la capogruppo come se fosse un fornitore. Dare a ogni fornitura infragruppo di una funzione essenziale o importante un contratto scritto recante le disposizioni complete dell’Article 30, i diritti di accesso e audit, gli obblighi di assistenza in caso di incidenti e di cooperazione, le condizioni sul subappalto e una strategia di uscita documentata, esattamente come una controllata imporrebbe a un fornitore cloud esterno. La formalità non è un fardello burocratico; è lo strumento che converte la responsabilità cartacea della controllata in potere reale sul nucleo.

Tenere un registro consolidato e leggerlo come una mappa del rischio. Mantenere il registro ai livelli di entità, subconsolidato e consolidato (Art 28(3)) e trattare la visione consolidata non come un adempimento di archiviazione ma come la mappa che il gruppo ha della propria concentrazione, l’input per la valutazione del rischio di concentrazione (Art 29) e per l’investimento in resilienza che ne consegue.

Centralizzare i fatti di un incidente, distribuire la segnalazione. Gestire un’unica tassonomia degli incidenti, un unico processo di causa radice e un unico cronometro dal centro operativo per la sicurezza del gruppo, e alimentare un resoconto unico e coerente di qualsiasi incidente del nucleo nella segnalazione di ciascuna controllata colpita, che quella controllata fa propria e trasmette alla propria autorità (Arts 18–19). Il gruppo fornisce un’unica verità; ciascuna entità adempie al proprio obbligo.

Testare il nucleo una sola volta, per tutti coloro che vi dipendono. Pianificare i test di resilienza e quelli guidati dalle minacce dal nucleo condiviso verso l’esterno, usando le disposizioni di DORA sui test in comune e di gruppo (Arts 26–27) così che la cosa che porta la concentrazione sia testata adeguatamente e di rado anziché ripetutamente e superficialmente, con le funzioni critiche di ciascuna controllata incluse nel perimetro e ciascuna controllata che agisce sulle risultanze.

Nessuna di queste annulla la centralizzazione; ciascuna riconnette un dovere che DORA ha posto sulla controllata a un controllo che il gruppo ha posto nella holding. Insieme consentono a un gruppo di mantenere la piattaforma che ha costruito una sola volta e di dare comunque a ogni entità regolamentata, e a ogni autorità di vigilanza nazionale, la relazione governata, contrattualizzata, documentata e testata che il regolamento richiede.

10. Obiezioni e risposte

La capogruppo non è un’entità regolamentata, quindi DORA non le si applica. Direttamente, no; attraverso le sue controllate, interamente. DORA raggiunge la holding come fornitore infragruppo di servizi ICT obbligando ciascuna controllata a governarla, a contrattare con essa e a vigilarla (Arts 3(20), 30). Un gruppo che legge la mancanza di una licenza della capogruppo come libertà da DORA ha scambiato il percorso dell’obbligo per la sua assenza, e troverà l’obbligo ad attenderlo nel registro, nel contratto e nell’audit di ogni controllata.

Centralizzare l’ICT migliora la resilienza, quindi la concentrazione è un pregio, non un rischio. Entrambe le cose sono vere, il che è il punto della Sezione 4. Un nucleo condiviso ben gestito abbassa la probabilità di guasto propria e indipendente di ciascuna controllata; allo stesso tempo innalza la probabilità di un singolo evento correlato che comprometta l’intero gruppo in una volta sola. Le disposizioni di DORA sulla concentrazione (Art 29) esistono proprio perché il secondo effetto è reale ed è invisibile dall’interno di qualsiasi singola entità. Il compito progettuale è cogliere il primo beneficio vedendo, valutando il prezzo e mitigando il secondo, non negare che il compromesso esista.

Redigere un contratto completo ai sensi dell’Article 30 tra una capogruppo e la propria controllata è teatro legalistico. Lo sarebbe, se l’unico scopo del contratto fosse soddisfare una lista di controllo. Il suo scopo reale è dare al consiglio della controllata, che è responsabile per legge di un nucleo che non possiede, diritti esigibili di informazione, audit, assistenza e uscita su quel nucleo. Senza di essi la responsabilità statutaria del consiglio (Art 5) è nominale. La formalità è il meccanismo che rende la responsabilità esercitabile, e il contesto infragruppo, dove la controparte è un’entità sorella con lo stesso proprietario ultimo, è esattamente dove gli accordi informali tendono a lasciare quei diritti non scritti.

La messa in comune dei test libera il gruppo dall’obbligo individuale di testare. Non è così. La messa in comune (Arts 26–27) è un modo per testare il nucleo condiviso in modo efficiente e sicuro, non un modo per assolvere l’obbligo di un’entità additando il test di qualcun altro. Ciascuna controllata partecipante resta obbligata individualmente ad assicurare che le proprie funzioni critiche siano nel perimetro e ad agire sulle risultanze; la messa in comune riguarda come il test è condotto, non di chi è il dovere.

11. Limiti

Si tratta di un’analisi rivolta ai professionisti, e i suoi limiti vanno enunciati chiaramente. Non è consulenza legale; il testo che governa è il regolamento e i suoi atti di livello 2, letti con gli orientamenti delle European Supervisory Authorities e di ciascuna autorità nazionale competente pertinente, e il legale di ciascun gruppo deve mappare la struttura generale qui esposta sulle sue entità, licenze e Stati membri specifici. I riferimenti agli articoli sono a DORA come si presentava all’inizio del 2025, con gli atti delegati e di attuazione allora adottati; il dettaglio delle norme tecniche, e la prassi di vigilanza su di esse, continuerà a svilupparsi. Il modello della Sezione 4 è uno schizzo le cui quantità sono definite in modo abbastanza chiaro da essere misurate ma le cui forme funzionali e i cui valori illustrativi sono scelti per rendere visibile il meccanismo, non stimati dai dati di un gruppo; un gruppo dovrebbe popolare $c$, $p_0$ e $q$ dalla propria architettura e dalla propria storia degli incidenti prima di trarre qualsiasi conclusione dalle curve. L’articolo tratta inoltre il caso comune e pulito di un unico nucleo centrale e di una netta separazione tra capogruppo e controllata; i gruppi reali hanno diversi nuclei, centralizzazione parziale, holding intermedie, fornitori esterni condivisi dietro quello infragruppo, e funzioni che sono critiche in uno Stato membro e non in un altro, ciascuna delle quali complica il quadro senza mutarne i due problemi di fondo.

12. Conclusione

Un gruppo finanziario paneuropeo che gestisce il proprio ICT critico dal centro e la propria attività regolamentata dalle periferie ha costruito la struttura più sensata per l’efficienza e la più scomoda per DORA. Il regolamento vincola individualmente ciascuna controllata, presuppone che ciascuna controlli il proprio ICT, e scopre invece che un unico nucleo condiviso, fornito da una capogruppo che il regolamento raggiunge solo di seconda mano, le controlla tutte. Ne derivano due problemi: il dovere di conformarsi risiede dove non risiede il controllo, e centralizzare l’ICT concentra il rischio del gruppo in un unico punto correlato il cui guasto compromette ogni controllata in una volta sola ed è segnalato a ogni autorità di vigilanza separatamente. Li abbiamo esposti entrambi, modellato il secondo per mostrare che la centralizzazione scambia una più bassa probabilità di guasto per entità con una più alta probabilità correlata a livello di gruppo, e letto il risultato alla luce delle disposizioni di DORA in materia di registro, concentrazione, contratti, incidenti, test e governance.

La risposta non è abbandonare il nucleo centrale ma governarlo come DORA richiede: un unico quadro di gruppo visibile a ogni consiglio, contratti infragruppo redatti come se fossero rivolti a un fornitore esterno, un registro consolidato letto come una mappa della concentrazione, un unico insieme di fatti sull’incidente distribuito in molte segnalazioni, e il nucleo condiviso testato una sola volta per tutti coloro che vi dipendono. Ciascuna mossa riconnette un dovere che il regolamento ha posto sulla controllata a un controllo che il gruppo ha posto nella holding, così che la cosa che il gruppo ha costruito una sola volta possa essere gestita in modo conforme da ogni entità che vi dipende. La lezione più profonda è quella che DORA è stato scritto per insegnare: che la resilienza operativa non è una proprietà di una piattaforma ma degli assetti che la circondano, e che in un gruppo sono quegli assetti, non l’organigramma proprietario, a decidere se un singolo punto di efficienza è anche un singolo punto di guasto.

Appendice A. Il modello per esteso

Il modello della Sezione 4 usa quattro quantità, tutte stimabili da un gruppo a partire dalla propria architettura e dalla propria storia degli incidenti. Il rapporto di centralizzazione $c$ è la quota delle controllate regolamentate del gruppo le cui funzioni essenziali o importanti dipendono dal nucleo condiviso; un gruppo può leggerlo dal registro consolidato (Art 28(3)) contando, tra le sue controllate, quante elencano il nucleo infragruppo dietro una funzione critica. La probabilità di guasto del nucleo $p_0$ è la probabilità che il nucleo condiviso subisca un’interruzione abbastanza grave da compromettere la funzione critica di una controllata dipendente in un periodo scelto; è stimata dal registro degli incidenti del nucleo stesso, non da quello di una singola controllata. La probabilità di guasto locale $q$ è la probabilità corrispondente per l’ICT proprio e non condiviso di una controllata. Il conteggio $n$ è il numero di controllate regolamentate.

La linea di base indipendente è il confronto che rende visibile la concentrazione. Se non vi fosse alcun nucleo condiviso, con ciascuna controllata che si guasta indipendentemente con probabilità $q$, la probabilità che almeno due controllate siano compromesse nello stesso periodo sarebbe $1-(1-q)^{n}-nq(1-q)^{n-1}$, che per $q$ piccolo è approssimativamente $\binom{n}{2}q^{2}$, una quantità di secondo ordine. Con il nucleo condiviso, il termine dominante della stessa probabilità è $p_0$ moltiplicato per la probabilità che almeno due controllate siano collegate, una quantità di primo ordine in $p_0$. Il rapporto tra le due è il fattore per cui la centralizzazione innalza l’esposizione del gruppo a eventi simultanei e multi-entità, ed è grande ogni volta che $p_0$ non è molto più piccolo di $q^{2}$, cosa che non è quasi mai. Questo è il contenuto formale dell’affermazione che la concentrazione accoppia le controllate a un rischio unico anziché distribuire il rischio tra di esse.

Due insidie meritano attenzione. La prima è stimare $p_0$ dall’esperienza del nucleo di una singola controllata, il che lo sottostima, perché una data controllata vede solo gli incidenti del nucleo che si sono trovati a comprometterla; $p_0$ va letto dal registro del nucleo stesso attraverso tutti i dipendenti. La seconda è trattare $c$ come fisso quando invece è una decisione: il gruppo sceglie, funzione per funzione, quanto collegare al nucleo, e il valore del modello sta nel mostrare il costo, in rischio correlato a livello di gruppo, di ogni incremento di quella scelta, così che la scelta sia compiuta con il compromesso della Figura 2 in vista anziché solo su basi di efficienza.

Appendice B. Una checklist delle disposizioni contrattuali infragruppo

La checklist seguente raccoglie le disposizioni dell’Article 30 che una controllata dovrebbe assicurarsi nel proprio contratto per la fornitura infragruppo di una funzione essenziale o importante. Non sostituisce il regolamento né la consulenza legale; è un elenco di lavoro per la conversazione progettuale tra la funzione IT centrale di un gruppo e i consigli delle sue controllate. Ciascuna disposizione è una di cui la controllata ha bisogno per assolvere, su un nucleo che non possiede, un dovere che DORA le pone; il contesto infragruppo è il luogo in cui ciascuna viene più spesso lasciata implicita e dovrebbe invece essere messa per iscritto.

Bibliografia

European Union (2022). Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (Digital Operational Resilience Act). Official Journal of the European Union, L 333, 1–79. https://eur-lex.europa.eu/eli/reg/2022/2554/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1774 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes and policies and the simplified ICT risk management framework. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1773 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards on the policy on contractual arrangements on the use of ICT services supporting critical or important functions. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1502 supplementing Regulation (EU) 2022/2554 with regard to criteria for the designation of ICT third-party service providers as critical for financial entities. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1502/oj

European Commission (2024). Commission Implementing Regulation (EU) 2024/2956 laying down implementing technical standards for the application of Regulation (EU) 2022/2554 with regard to the standard templates for the register of information. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj

European Commission (2025). Commission Delegated Regulation (EU) 2025/532 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the elements a financial entity must determine and assess when subcontracting ICT services supporting critical or important functions. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2025/532/oj

European Supervisory Authorities (EBA, EIOPA and ESMA) (2024). Final report on draft regulatory technical standards on subcontracting under Article 30(5) of Regulation (EU) 2022/2554 (JC 2024 53). Joint Committee of the European Supervisory Authorities. https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024_53_Final_report_DORA_RTS_on_subcontracting.pdf

Basel Committee on Banking Supervision (2021). Principles for operational resilience. Bank for International Settlements. https://www.bis.org/bcbs/publ/d516.htm

Financial Stability Board (2019). Third-party dependencies in cloud services: Considerations on financial stability implications. https://www.fsb.org/2019/12/third-party-dependencies-in-cloud-services-considerations-on-financial-stability-implications/

Financial Stability Board (2023). Enhancing third-party risk management and oversight: A toolkit for financial institutions and financial authorities. https://www.fsb.org/2023/12/enhancing-third-party-risk-management-and-oversight-a-toolkit/

European Systemic Risk Board (2022). Mitigating systemic cyber risk. European Systemic Risk Board. https://www.esrb.europa.eu/pub/pdf/reports/esrb.SystemicCyberRisk220127~b6655fa027.en.pdf

European Banking Authority (2019). Guidelines on outsourcing arrangements (EBA/GL/2019/02). https://www.eba.europa.eu/regulation-and-policy/internal-governance/guidelines-on-outsourcing-arrangements

European Union Agency for Cybersecurity (ENISA) (2023). ENISA threat landscape 2023. https://www.enisa.europa.eu/publications/enisa-threat-landscape-2023

Perrow, C. (1999). Normal accidents: Living with high-risk technologies (Updated ed.). Princeton University Press. ISBN 978-0-691-00412-9.

Leveson, N. G. (2011). Engineering a safer world: Systems thinking applied to safety. MIT Press. ISBN 978-0-262-01662-9.

Kaufman, G. G., & Scott, K. E. (2003). What is systemic risk, and do bank regulators retard or contribute to it? The Independent Review, 7(3), 371–391. https://www.independent.org/pdf/tir/tir_07_3_scott.pdf