1. Introducción

Un gran grupo financiero que opera en toda la Unión Europea rara vez opera como una sola entidad jurídica. Opera como una matriz y un abanico de filiales, normalmente una sociedad regulada por Estado miembro, cada una con su propia licencia, cada una respondiendo ante su propio supervisor nacional, cada una moldeada por las normas locales que se suman a las europeas comunes. La razón es en parte histórica, en parte regulatoria y en parte comercial: las licencias son nacionales, los supervisores son nacionales, y una entidad local con un nombre local y un balance local es más fácil de autorizar, de supervisar y de usar como canal de venta. Lo que el grupo sí centraliza, casi siempre, es la tecnología de la información. Resulta derrochador construir la misma plataforma de banca central, el mismo sistema de administración de pólizas, el mismo centro de datos, el mismo centro de operaciones de seguridad once veces, de modo que el grupo los construye una sola vez, en la matriz o en una sociedad de TI del grupo dedicada, y los suministra a cada filial como un servicio compartido. El negocio es local; la fontanería es central.

La Ley de Resiliencia Operativa Digital atraviesa esta configuración de un modo fácil de pasar por alto hasta que se implementa. DORA, Regulation (EU) 2022/2554, se aplica desde el 17 de enero de 2025, y su unidad básica es la entidad regulada individual, no el grupo (DORA, arts. 1–2). Cada filial debe mantener por sí misma un marco de gestión del riesgo de TIC, clasificar y notificar sus propios incidentes graves, probar su propia resiliencia, llevar su propio registro de terceros de TIC y gobernarlos bajo su propio consejo (DORA, arts. 5–30). A la regulación no le importa que la filial no haya construido la plataforma sobre la que opera y no pueda cambiarla; el deber es de la filial de todos modos. Y cuando el grupo se vuelve hacia la entidad que sí construyó la plataforma, la matriz, descubre que DORA ya ha nombrado la relación: una sociedad de grupo que suministra TIC a las entidades reguladas de su propio grupo es un proveedor de servicios TIC intragrupo, y DORA lo trata, a casi todos los efectos, como un tercero (DORA, art. 3(20)).

Dos problemas se derivan de ello, y son el objeto de este artículo. El primero es un desajuste entre dónde recae el deber y dónde reside el control. DORA pone el deber en la filial y deja el control en la sociedad holding, y la holding, si no es ella misma una entidad financiera regulada, queda fuera del alcance directo de la regulación, tocada solo a través de los contratos y la supervisión que sus filiales están obligadas a imponerle. Llamamos a esto la asimetría cumplimiento–control, y la Sección 3.1 la anatomiza. El segundo es que centralizar las TIC concentra el riesgo. Un núcleo compartido es un único punto cuyo fallo no es el problema de una filial, sino el de todas las filiales a la vez, un evento correlacionado de modo común en lugar de uno independiente y diversificable, y como cada filial afectada debe notificar a su propio supervisor, un fallo técnico se convierte en un abanico de presentaciones regulatorias simultáneas por toda la Unión. La Sección 3.2 lo expone y la Sección 4 lo modela.

La contribución es un diagnóstico y un diseño, no un comentario jurídico. Enunciamos los dos problemas estructurales con claridad, damos un pequeño modelo cuantitativo del de concentración para que un grupo pueda ver cómo su grado de centralización intercambia fiabilidad por entidad frente a riesgo correlacionado para todo el grupo (Sección 4), y recorremos lo que las principales obligaciones de DORA, el registro y los contratos (Sección 5), la notificación de incidentes (Sección 6), las pruebas (Sección 7) y la gobernanza (Sección 8), exigen de un grupo centralizado en particular. La Sección 9 propone un modelo operativo objetivo que satisface la regulación mientras conserva la eficiencia que llevó al grupo a centralizar en primer lugar. Las Secciones 10 a 12 responden a objeciones, enuncian límites y concluyen. La pregunta a lo largo de todo el texto es: ¿cómo cumple un grupo, entidad por entidad, con una regulación que presupone que cada entidad controla sus propias TIC, cuando en realidad un único núcleo compartido las controla todas?

2. Qué exige DORA, y a quién

2.1 Los cinco pilares

DORA organiza la resiliencia operativa de una entidad financiera en cinco áreas, y vale la pena enunciarlas una vez porque el problema de grupo toca las cinco. La primera es la gestión del riesgo de TIC (capítulo II, arts. 5–16): un marco de gobernanza y control, del que es titular el órgano de dirección, que cubre identificación, protección, detección, respuesta y recuperación, con un marco simplificado más ligero disponible para ciertas entidades más pequeñas (art. 16). La segunda es la gestión y notificación de incidentes relacionados con las TIC (capítulo III, arts. 17–23): un proceso para detectar y gestionar incidentes, una clasificación armonizada de su gravedad (art. 18), y la obligación de notificar los incidentes graves a la autoridad competente según un calendario fijo de informes inicial, intermedio y final (art. 19). La tercera es las pruebas de resiliencia operativa digital (capítulo IV, arts. 24–27): un programa de pruebas periódicas para toda entidad, y pruebas avanzadas de penetración basadas en amenazas (TLPT) al menos cada tres años para aquellas que las autoridades señalen como significativas (arts. 26–27). La cuarta es la gestión del riesgo de terceros proveedores de TIC (capítulo V, arts. 28–44), que es donde la estructura de grupo muerde con más fuerza, y que tratamos extensamente más adelante. La quinta es el intercambio de información sobre ciberamenazas (capítulo VI, art. 45), que es voluntario y no necesita detenernos aquí.

2.2 El principio de entidad

La característica de DORA que gobierna todo lo de este artículo es que sus obligaciones se adhieren a la entidad autorizada individual. Un grupo bancario no está autorizado; lo están sus filiales bancarias. La disposición de ámbito de DORA enumera las clases de entidad financiera que vincula, y cada una es una entidad que posee una licencia (art. 2). La consecuencia es que el cumplimiento se evalúa, y se exige, de una entidad en una entidad, por la propia autoridad competente de esa entidad. No hay una licencia de grupo que cumpla en nombre de las filiales, ni un único supervisor europeo ante el que el grupo en su conjunto responda de su resiliencia. El registro de información es el único lugar donde la dimensión de grupo es explícita: una entidad debe llevarlo no solo a su propio nivel sino, cuando forma parte de un grupo, también a nivel subconsolidado y consolidado (art. 28(3)), de modo que una entidad consolidante ensambla una visión para todo el grupo. Pero el deber de cumplir, de gobernar, de notificar y de probar sigue siendo de la filial individual, y no puede descargarse señalando hacia arriba a la matriz.

2.3 Las TIC intragrupo son TIC de terceros

La segunda característica que gobierna este artículo es el tratamiento que DORA da a las TIC suministradas desde dentro del grupo. Sería natural suponer que los servicios que una filial recibe de su propia matriz son internos, y quedan fuera del régimen de terceros que DORA dirige a los proveedores externos. DORA cierra esa suposición. Define un proveedor de servicios TIC intragrupo como una empresa que forma parte del grupo y presta servicios de TIC predominantemente a entidades del mismo grupo (art. 3(20)), y lleva a tal proveedor dentro de las normas de terceros: la filial receptora debe registrar el acuerdo en su registro (art. 28(3)), gobernarlo bajo un contrato escrito que incorpore las disposiciones obligatorias (art. 30), evaluar la concentración que crea (art. 29) y mantener acuerdos de salida para él cuando sustente una función esencial o importante (art. 28(8)). La naturaleza intragrupo de la relación es algo que debe registrarse, no una razón de exención. En resumen, cuando la matriz suministra la plataforma, DORA lee a la matriz como un proveedor tercero y a la filial como su cliente, con todas las obligaciones que tendría un cliente de un proveedor externo de nube o de software. Un grupo que trata la relación como un asunto puramente interno, gobernado por un catálogo de servicios y una refacturación intragrupo en lugar de un contrato conforme a DORA, no es conforme.

3. El patrón de holding centralizado

La Figura 1 dibuja el patrón del que trata este artículo. Una sociedad holding o de TI del grupo opera el núcleo de TIC crítico y lo suministra a varias filiales reguladas, cada una en su propio Estado miembro y cada una supervisada por su propia autoridad nacional competente. Las flechas de servicio corren hacia abajo desde el núcleo; las flechas de supervisión y de notificación de incidentes corren desde cada filial hacia su propia autoridad. Los dos problemas de la Introducción son visibles en la imagen: aquello que une al grupo, el núcleo, lo suministra una entidad a la que los reguladores alcanzan solo indirectamente, y un fallo en la parte superior del diagrama se propaga a todas las ramas a la vez mientras la notificación se fragmenta entre todas las autoridades de la parte inferior.

3.1 La asimetría cumplimiento–control

En una entidad de manual, la firma que soporta el deber de DORA también opera los sistemas, de modo que el deber y las palancas para cumplirlo están en las mismas manos. El grupo centralizado los separa. La filial soporta el deber, porque es la entidad autorizada, pero no opera el núcleo, no puede parchearlo, no puede elegir su arquitectura, no puede fijar sus objetivos de recuperación y no puede, por sí sola, probarlo. La sociedad holding opera el núcleo y tiene todas esas palancas, pero no soporta ningún deber directo de DORA si no es ella misma una entidad financiera autorizada, lo que una sociedad de TI o holding pura normalmente no es. La regulación anticipa exactamente esto y lo sortea: alcanza a la holding a través de la filial, exigiendo a la filial que imponga, por contrato, los derechos de acceso, auditoría, cooperación, notificación de incidentes, pruebas y salida que permiten a la filial cumplir un deber sobre sistemas que no posee (art. 30). El cumplimiento de la filial depende por tanto de su poder contractual sobre su propia matriz, que es algo inusual e incómodo de tener que ejercer.

La asimetría tiene un filo práctico agudo. A un consejo de una filial DORA le dice que es, en última instancia, responsable del riesgo de TIC de la entidad y que no puede delegar esa responsabilidad (art. 5(2)); sin embargo, la influencia real del consejo sobre el núcleo que porta la mayor parte de ese riesgo discurre a través de una función de grupo que reporta a la matriz, no a él. Si el consejo simplemente confía en el centro, ha delegado en sustancia lo que no puede delegar en derecho. Si trata de ejercer una supervisión genuina, necesita información, aseguramiento y derechos que una relación intragrupo informal no proporciona. La respuesta de diseño, desarrollada en la Sección 9, es dar a la relación la formalidad que tendría con un proveedor externo precisamente para que el consejo de la filial pueda ver dentro del núcleo y cuestionarlo, y construir el marco del grupo de modo que la supervisión de cada consejo sea un insumo real y no una cortesía.

3.2 Riesgo de concentración

El segundo problema es que el núcleo compartido es una concentración. DORA nombra el riesgo de concentración directamente y exige a cada entidad evaluarlo antes de contratar y mantenerlo bajo revisión, incluyendo explícitamente el riesgo de los acuerdos intragrupo y de los proveedores difíciles de sustituir (art. 29). En un grupo centralizado la concentración es casi total: un núcleo, un centro de operaciones de seguridad, un conjunto de acuerdos de recuperación, al servicio de cada entidad regulada del grupo. El argumento de eficiencia a favor de esto es exactamente su peligro. La misma plataforma única que es más barata de construir y más fácil de asegurar una vez es también un único punto cuyo fallo comparten todos los que dependen de él. Donde un grupo federado de filiales que operaran cada una sus propias TIC sufriría los fallos de uno en uno, de forma independiente, un grupo centralizado los sufre juntos, porque los fallos tienen una causa común.

Esta es la distinción entre fallo independiente y fallo de modo común que las literaturas de la seguridad y del riesgo sistémico han insistido en subrayar desde hace tiempo (Perrow, 1999; Leveson, 2011; ESRB, 2022). Los fallos independientes diversifican: la probabilidad de que muchos caigan a la vez es el producto de pequeñas probabilidades, y es ínfima. Los fallos de modo común no diversifican: cuando la causa compartida falla, todo lo que está aguas abajo de ella falla junto, y la resiliencia del grupo queda acotada por la resiliencia de su componente compartido más débil, no mejorada por el número de entidades que reparten la carga. Concentrar las TIC no reparte el riesgo entre las filiales; acopla las filiales a un único riesgo. La siguiente sección precisa el punto.

4. Un modelo mínimo de riesgo de grupo correlacionado

El modelo es un boceto, pensado para hacer explícito el mecanismo y para permitir a un grupo razonar sobre su propio grado de centralización, no una estimación de riesgo calibrada. Separa el fallo que una filial sufre por sí sola del fallo que el grupo entero sufre junto, y muestra cómo la centralización desplaza el riesgo del primer tipo al segundo.

4.1 Deterioro por entidad

Consideremos un grupo de $n$ filiales reguladas. Una proporción $c$ de ellas, que trataremos como la probabilidad de que una filial cualquiera dependa del núcleo compartido de la sociedad holding para una función esencial o importante, está cableada al núcleo; llamemos a $c$ la razón de centralización. En un periodo dado el núcleo compartido sufre una disrupción crítica con probabilidad $p_0$. Este es un evento de modo común: cuando ocurre, toda filial cableada queda deteriorada en el mismo momento, por la misma razón. Independientemente del núcleo, las propias TIC locales de cada filial fallan en el periodo con probabilidad $q$. Una filial cableada queda por tanto deteriorada cuando falla o bien el núcleo o bien sus propias TIC locales,

que es la cifra que ve el consejo de una sola filial cuando mira su propio registro de incidentes. La centralización que cablea la filial a un núcleo bien gestionado tiende a reducir $q$, porque una plataforma compartida profesional suele gestionarse mejor que una pequeña local, de modo que $u$ puede caer a medida que el grupo se centraliza. Mirada de una entidad a la vez, la centralización mejora la resiliencia, y esta es la mitad honesta del argumento de eficiencia.

4.2 De lo independiente a lo correlacionado

El grupo no experimenta su riesgo de una entidad a la vez. Lo que importa al grupo, y a los reguladores, es la probabilidad de que varias filiales queden deterioradas al mismo tiempo, porque ese es el evento que es sistémico, transfronterizo y notificable simultáneamente. Sin un núcleo compartido, la única manera de que dos filiales caigan juntas es que dos de ellas fallen localmente en el mismo periodo, una coincidencia de eventos independientes cuya probabilidad es del orden de $q^{2}$, es decir, pequeña de segundo orden. Con un núcleo compartido, una única disrupción del núcleo derriba a toda filial cableada a la vez, de modo que la probabilidad de un evento simultáneo y multientidad es del orden de la propia probabilidad de fallo del núcleo,

donde el corchete es la probabilidad de que al menos dos de las $n$ filiales estén cableadas, de modo que un fallo del núcleo deteriore al menos a dos a la vez. Lo relevante no es la forma exacta sino el orden: la centralización convierte la probabilidad de un evento para todo el grupo de segundo orden en una pequeña probabilidad local a primer orden en la probabilidad del núcleo. Un núcleo que falla solo rara vez es, aun así, como fuente de fallo simultáneo multientidad, mucho más peligroso que la suma de los riesgos independientes de las filiales, porque sus fallos son compartidos en lugar de repartidos. La Figura 2 dibuja esta probabilidad frente a la razón de centralización para las dos arquitecturas: un grupo federado, con cada filial sobre sus propias TIC, la mantiene plana casi en cero, mientras que la de un grupo centralizado se eleva por encima de esa línea base a medida que se cablea más del grupo al núcleo compartido.

4.3 El multiplicador de carga regulatoria

Hay una segunda consecuencia del evento de modo común que es específica de DORA y de la estructura de grupo, y no concierne a la resiliencia sino a la notificación. Como cada filial es una entidad regulada separada que responde ante su propia autoridad competente (Sección 2.2), un único fallo del núcleo no genera un informe de incidente; genera uno de cada filial que deteriora, cada uno a una autoridad distinta, cada uno según el reloj de esa autoridad, posiblemente en la lengua de esa autoridad. El número esperado de informes de incidente grave simultáneos que desencadena una disrupción del núcleo es simplemente el número esperado de filiales cableadas,

de modo que un grupo de una docena de filiales plenamente cableadas a un núcleo compartido convierte un único evento técnico en una docena de presentaciones regulatorias paralelas en una docena de jurisdicciones, dentro del plazo del informe inicial de DORA, todas describiendo la misma causa raíz. Este multiplicador de carga regulatoria es invisible en la planificación de cualquier filial individual y solo se hace visible a nivel de grupo, que es precisamente el nivel del que DORA no hace responsable a ninguna entidad única. Es el argumento práctico más fuerte a favor de la coordinación a nivel de grupo que construye la Sección 9.

5. El registro, la concentración y los contratos

El capítulo de terceros de DORA da al grupo centralizado tres instrumentos que debe usar, y cada uno de ellos, aplicado honestamente, aflora los problemas anteriores en lugar de ocultarlos.

El registro de información (art. 28(3)) es un inventario de todo acuerdo contractual para servicios de TIC, llevado conforme a una plantilla estándar fijada por normas técnicas de ejecución (ITS 2024/2956) y que distingue los acuerdos que sustentan funciones esenciales o importantes de los que no. Para un grupo centralizado el registro es donde la dependencia intragrupo se vuelve innegable: el registro de cada filial lista a la sociedad holding como proveedor de sus servicios críticos, y el registro consolidado que el grupo debe ensamblar (art. 28(3)) muestra, en una sola página, que un proveedor está detrás de las funciones críticas de todo el grupo. Un grupo que rellena el registro debidamente ha documentado su propia concentración; un grupo tentado de dejar fuera el acuerdo intragrupo, bajo la teoría de que es interno, incumple a la vez la obligación de registro y se ciega al mismísimo riesgo que el registro existe para mostrar. La Tabla 1 expone los tres niveles a los que se lleva el registro y para qué sirve cada uno.

La evaluación del riesgo de concentración (art. 29) plantea entonces la pregunta que el registro suscita: ¿qué ocurre si este proveedor falla o debe ser sustituido? Para un proveedor externo la respuesta es un análisis de sustitución; para el núcleo intragrupo es más difícil, porque el núcleo normalmente no es sustituible en absoluto en ningún horizonte razonable, habiéndose construido una sola vez para todo el grupo. DORA no prohíbe la concentración, pero exige a la entidad verla y sopesarla, y la respuesta honesta de un grupo centralizado, que el núcleo es un único punto de fallo para el grupo y efectivamente irreemplazable a corto plazo, es ella misma el hallazgo que debería impulsar la inversión en resiliencia y la planificación de salida que la regulación también exige (art. 28(8)).

Los acuerdos contractuales (art. 30) son el mecanismo por el cual la filial adquiere poder sobre un núcleo que no posee. DORA prescribe un mínimo de disposiciones para todo acuerdo y una lista más larga para los acuerdos que sustentan funciones esenciales o importantes: descripciones completas del nivel de servicio, ubicaciones del servicio y de los datos, derechos de acceso, inspección y auditoría, obligaciones de asistencia en los incidentes, cooperación con las autoridades, derechos de supervisión, condiciones sobre la subcontratación (ahora detalladas por el RTS 2025/532) y estrategias de salida documentadas (arts. 28(8), 30(2)–(3)). El entorno intragrupo no relaja nada de esto. La instrucción de diseño, desarrollada más abajo, es redactar el contrato intragrupo como si la contraparte fuera un proveedor externo en condiciones de plena competencia, porque esa es la única manera de que el consejo de la filial obtenga, sobre el papel, los derechos que la asimetría le niega de otro modo.

6. Un incidente, muchos reguladores

El régimen de notificación de incidentes es donde el multiplicador de carga regulatoria de la Sección 4 se convierte en un problema operativo. DORA exige a una entidad clasificar un incidente relacionado con las TIC frente a criterios armonizados, y, si es grave, notificar a su autoridad competente con un informe inicial en un plazo breve, luego un informe intermedio a medida que el cuadro se afianza, y luego un informe final con la causa raíz (arts. 18–19). Los criterios de clasificación, los umbrales y las plantillas están armonizados en toda la Unión por las normas de nivel 2, lo cual es una ayuda; pero los informes siguen yendo a la propia autoridad de cada entidad, y el reloj arranca para cada entidad cuando esa entidad toma conocimiento.

Para un grupo centralizado un único fallo del núcleo es, simultáneamente, un incidente grave para cada filial que deteriora. Cada filial debe clasificarlo, cada una debe decidir si cruza el umbral de gravedad, y cada una debe presentar, a su propia autoridad, dentro del plazo. Si las filiales clasifican de forma independiente y redactan de forma independiente, el grupo produce una dispersión de informes que describen el mismo evento de forma inconsistente, llegan en momentos distintos y exponen al grupo a la pregunta supervisora obvia de por qué sus entidades discrepan sobre lo que le ocurrió a su sistema compartido. El modo de fallo no es la infranotificación sino la sobrenotificación incoherente. El remedio no es centralizar la notificación, que DORA no permite, puesto que la obligación es de cada entidad, sino centralizar los hechos: una taxonomía de incidentes, una determinación de causa raíz y un reloj gestionados desde el centro de operaciones de seguridad del grupo, que alimenten un núcleo coherente de hechos en la presentación propia de cada filial, que la propia función responsable de cada filial posee, firma y presenta a su propia autoridad. El grupo suministra la verdad; cada entidad suministra la presentación. La Sección 9 lo concreta.

7. Probar un núcleo compartido

El régimen de pruebas de DORA tiene dos niveles, y la estructura de grupo complica ambos. El nivel básico exige a toda entidad ejecutar un programa de pruebas de resiliencia, proporcionado a su tamaño y riesgo (art. 24–25). El nivel avanzado exige pruebas de penetración basadas en amenazas, aproximadamente cada tres años, para aquellas entidades que las autoridades identifiquen como suficientemente significativas para justificarlas (arts. 26–27). En un grupo centralizado el objeto que merece la pena probar es en gran medida el núcleo compartido, porque es ahí donde están los sistemas críticos y la concentración; pero la obligación de probar recae sobre las filiales, que no operan el núcleo.

Probar el mismo núcleo compartido por separado para cada filial sería derrochador y, peor, arriesgado, ya que el red-teaming en vivo repetido de una plataforma de producción que sirve a todo el grupo multiplica la probabilidad de que una prueba cause ella misma un incidente. DORA anticipa a los proveedores compartidos y permite, bajo ciertas condiciones, que las pruebas se mancomunen o se realicen conjuntamente cuando varias entidades dependen del mismo proveedor de TIC o pertenecen al mismo grupo y comparten sistemas, de modo que una prueba del núcleo compartido debidamente gobernada pueda satisfacer a las entidades participantes (arts. 26–27 y las normas técnicas sobre TLPT). La mancomunación no disuelve la obligación individual: cada filial participante debe seguir siendo parte del acuerdo, debe seguir asegurando que la prueba cubra sus propias funciones críticas, y debe seguir actuando sobre los hallazgos. Pero permite al grupo probar lo que de verdad importa, el núcleo, una vez y bien, en lugar de muchas veces y mal. La implicación de diseño es que el grupo debería planificar las pruebas desde el núcleo hacia afuera, encuadrar las funciones críticas de cada filial en la prueba compartida, y mantener los derechos contractuales (art. 30) que permiten a una filial exigir a su proveedor, aquí su propia matriz, que participe.

8. Una responsabilidad que no puede delegarse hacia arriba

El hilo que recorre cada sección es la insistencia de DORA en que el órgano de dirección de cada entidad soporta la responsabilidad última del riesgo de TIC de esa entidad, y en que esa responsabilidad no puede contratarse ni delegarse hacia fuera (art. 5). En un grupo centralizado esta es la disposición más en tensión con la realidad operativa, porque la realidad es que las filiales han delegado las TIC, en sustancia, en el grupo. DORA no prohíbe al grupo operar las TIC de forma centralizada; lo que prohíbe es que el consejo de la filial trate ese acuerdo como una razón para dejar de ser responsable. El consejo debe conservar suficiente comprensión del núcleo del que depende, suficiente información sobre cómo se gestiona y cómo está fallando, y suficiente poder contractual y de gobernanza para cuestionar y, en casos extremos, para actuar, de modo que su responsabilidad estatutaria sea real y no nominal.

Esto choca con un instinto centralizador natural y normalmente bienintencionado, que es ahorrar a los consejos de las filiales el detalle técnico y dejar que los expertos del centro se ocupen. DORA exige lo contrario: que cada consejo de filial esté equipado y obligado a gobernar un riesgo que ha externalizado a su propia matriz. Las consecuencias prácticas son una línea de reporte desde la función de TIC del grupo hacia el consejo de cada filial, no solo hacia la matriz; alfabetización en riesgo de TIC a nivel de consejo en cada filial, no solo en el centro; y un marco de grupo diseñado de modo que la supervisión de cada consejo sea un punto de control genuino. Un grupo que construye el núcleo compartido pero deja a los consejos de las filiales sin información ha creado la asimetría cumplimiento–control en su forma más peligrosa, donde las personas responsables en derecho son las menos capaces de hecho de ejercer la responsabilidad.

9. Un modelo operativo objetivo para el grupo

El diseño que responde a los dos problemas no es descentralizar las TIC, lo que tiraría por la borda la eficiencia y, según el modelo de la Sección 4, podría incluso no mejorar la resiliencia del grupo una vez que el núcleo compartido está bien gestionado. Es conservar el núcleo central y envolverlo en la estructura que DORA exige, de modo que el deber y el control se reconecten mediante la gobernanza y el contrato en lugar de mediante la propiedad. Cinco movimientos se derivan del análisis.

Gestione un único marco de gestión del riesgo de TIC del grupo, visible para cada consejo. Construya el marco de gestión del riesgo de TIC una sola vez, a nivel de grupo, conforme al estándar que exigen DORA y su RTS (art. 6; RTS 2024/1774), pero conecte su reporte al órgano de dirección de cada filial y no solo al de la matriz, de modo que cada consejo gobierne el riesgo compartido con información real. El marco es central; la responsabilidad sigue distribuida, como exige la regulación.

Contrate con la matriz como si fuera un proveedor. Dé a todo suministro intragrupo de una función esencial o importante un contrato escrito que incorpore las disposiciones completas del artículo 30, derechos de acceso y auditoría, deberes de asistencia en incidentes y de cooperación, condiciones de subcontratación y una estrategia de salida documentada, exactamente como una filial impondría a un proveedor externo de nube. La formalidad no es sobrecarga burocrática; es el instrumento que convierte la responsabilidad sobre el papel de la filial en poder real sobre el núcleo.

Lleve un registro consolidado y léalo como un mapa de riesgo. Mantenga el registro a nivel de entidad, subconsolidado y consolidado (art. 28(3)) y trate la visión consolidada no como una tarea de presentación sino como el mapa del grupo de su propia concentración, el insumo para la evaluación del riesgo de concentración (art. 29) y para la inversión en resiliencia que de ella se deriva.

Centralice los hechos de un incidente, distribuya la presentación. Gestione una taxonomía de incidentes, un proceso de causa raíz y un reloj desde el centro de operaciones de seguridad del grupo, y alimente un relato único y coherente de cualquier incidente del núcleo en la notificación propia de cada filial afectada, que esa filial posee y presenta ante su propia autoridad (arts. 18–19). El grupo suministra una única verdad; cada entidad cumple su propia obligación.

Pruebe el núcleo una vez, para todos los que dependen de él. Planifique las pruebas de resiliencia y las pruebas basadas en amenazas desde el núcleo compartido hacia afuera, usando las disposiciones de DORA sobre pruebas mancomunadas y de grupo (arts. 26–27) de modo que lo que porta la concentración se pruebe debidamente y rara vez en lugar de repetidamente y de forma superficial, con las funciones críticas de cada filial encuadradas y cada filial actuando sobre los hallazgos.

Ninguno de estos deshace la centralización; cada uno reconecta un deber que DORA puso en la filial con un control que el grupo puso en la sociedad holding. Juntos permiten a un grupo conservar la plataforma que construyó una sola vez y aun así dar a cada entidad regulada, y a cada supervisor nacional, la relación gobernada, contratada, documentada y probada que la regulación exige.

10. Objeciones y respuestas

La matriz no es una entidad regulada, de modo que DORA no se le aplica. Directamente, no; a través de sus filiales, por completo. DORA alcanza a la sociedad holding como proveedor de servicios TIC intragrupo al obligar a cada filial a gobernarla, contratar con ella y supervisarla (arts. 3(20), 30). Un grupo que lee la falta de licencia de la matriz como libertad frente a DORA ha confundido la vía de la obligación con su ausencia, y encontrará la obligación esperando en el registro, el contrato y la auditoría de cada filial.

Centralizar las TIC mejora la resiliencia, de modo que la concentración es una característica, no un riesgo. Ambas cosas son ciertas, que es el sentido de la Sección 4. Un núcleo compartido bien gestionado reduce la probabilidad de fallo propia e independiente de cada filial; eleva simultáneamente la probabilidad de un único evento correlacionado que deteriore a todo el grupo a la vez. Las disposiciones de concentración de DORA (art. 29) existen precisamente porque el segundo efecto es real y es invisible desde dentro de cualquier entidad. La tarea de diseño es capturar el primer beneficio mientras se ve, se tarifica y se mitiga el segundo, no negar que el equilibrio existe.

Redactar un contrato completo del artículo 30 entre una matriz y su propia filial es teatro legalista. Lo sería, si el único propósito del contrato fuera satisfacer una lista de comprobación. Su verdadero propósito es dar al consejo de la filial, que es responsable en derecho de un núcleo que no posee, derechos exigibles de información, auditoría, asistencia y salida sobre ese núcleo. Sin ellos la responsabilidad estatutaria del consejo (art. 5) es nominal. La formalidad es el mecanismo que hace ejercitable la responsabilidad, y el entorno intragrupo, donde la contraparte es una entidad hermana con el mismo propietario último, es exactamente donde los acuerdos informales tienden a dejar esos derechos sin escribir.

La prueba mancomunada libera al grupo del anzuelo de la prueba individual. No lo hace. La mancomunación (arts. 26–27) es una manera de probar el núcleo compartido de forma eficiente y segura, no una manera de que una entidad cumpla su obligación señalando la prueba de otro. Cada filial participante sigue estando obligada individualmente a asegurar que sus propias funciones críticas estén dentro del alcance y a actuar sobre los hallazgos; la mancomunación concierne a cómo se ejecuta la prueba, no a de quién es el deber.

11. Limitaciones

Este es un análisis orientado a los profesionales, y sus límites deben enunciarse con claridad. No es asesoramiento jurídico; el texto rector es el Reglamento y sus actos de nivel 2, leídos con la orientación de las Autoridades Europeas de Supervisión y de cada autoridad nacional competente pertinente, y los propios asesores jurídicos de un grupo deben mapear la estructura general aquí a sus entidades, licencias y Estados miembros específicos. Las referencias a los artículos son a DORA tal como estaba a principios de 2025, con los actos delegados y de ejecución entonces adoptados; el detalle de las normas técnicas, y la práctica supervisora bajo ellas, seguirán desarrollándose. El modelo de la Sección 4 es un boceto cuyas cantidades están definidas con claridad suficiente para medirse pero cuyas formas funcionales y valores ilustrativos se eligen para hacer visible el mecanismo, no estimados a partir de los datos de un grupo; un grupo debería poblar $c$, $p_0$ y $q$ a partir de su propia arquitectura e historial de incidentes antes de extraer conclusión alguna de las curvas. El artículo también trata el caso común y limpio de un único núcleo central y una clara separación matriz-filial; los grupos reales tienen varios núcleos, centralización parcial, holdings intermedias, proveedores externos compartidos detrás del intragrupo, y funciones que son críticas en un Estado miembro y no en otro, cada una de las cuales complica el cuadro sin cambiar sus dos problemas básicos.

12. Conclusión

Un grupo financiero paneuropeo que opera sus TIC críticas desde el centro y su negocio regulado desde los extremos ha construido la estructura más sensata para la eficiencia y la más incómoda para DORA. La regulación vincula a cada filial individualmente, presupone que cada una controla sus propias TIC, y encuentra en cambio que un único núcleo compartido, suministrado por una matriz a la que la regulación alcanza solo de segunda mano, las controla todas. Dos problemas se derivan: el deber de cumplir recae donde el control no está, y centralizar las TIC concentra el riesgo del grupo en un único punto correlacionado cuyo fallo deteriora a todas las filiales a la vez y se notifica a cada supervisor por separado. Hemos expuesto ambos, modelado el segundo para mostrar que la centralización intercambia una menor probabilidad de fallo por entidad por una mayor probabilidad correlacionada para todo el grupo, y leído el resultado frente a las disposiciones de registro, concentración, contrato, incidente, pruebas y gobernanza de DORA.

La respuesta no es abandonar el núcleo central sino gobernarlo como DORA exige: un único marco de grupo visible para cada consejo, contratos intragrupo redactados como si fueran para un proveedor externo, un registro consolidado leído como un mapa de concentración, un único conjunto de hechos de incidente distribuido en muchas presentaciones, y el núcleo compartido probado una vez para todos los que dependen de él. Cada movimiento reconecta un deber que la regulación puso en la filial con un control que el grupo puso en la sociedad holding, de modo que lo que el grupo construyó una sola vez pueda ser operado de forma conforme por cada entidad que depende de ello. La lección más profunda es la que DORA fue escrita para enseñar: que la resiliencia operativa no es una propiedad de una plataforma sino de los acuerdos que la rodean, y que en un grupo esos acuerdos, no el organigrama, son los que deciden si un único punto de eficiencia es también un único punto de fallo.

Apéndice A. El modelo completo

El modelo de la Sección 4 usa cuatro cantidades, todas las cuales un grupo puede estimar a partir de su propia arquitectura e historial de incidentes. La razón de centralización $c$ es la proporción de las filiales reguladas del grupo cuyas funciones esenciales o importantes dependen del núcleo compartido; un grupo puede leerla del registro consolidado (art. 28(3)) contando, de sus filiales, cuántas listan el núcleo intragrupo detrás de una función crítica. La probabilidad de fallo del núcleo $p_0$ es la probabilidad de que el núcleo compartido sufra una disrupción lo bastante grave como para deteriorar la función crítica de una filial dependiente en un periodo elegido; se estima a partir del propio registro de incidentes del núcleo, no del de ninguna filial individual. La probabilidad de fallo local $q$ es la probabilidad correspondiente para las propias TIC no compartidas de una filial. El recuento $n$ es el número de filiales reguladas.

La línea base independiente es la comparación que hace visible la concentración. Si no hubiera un núcleo compartido, fallando cada filial de forma independiente con probabilidad $q$, la probabilidad de que al menos dos filiales quedaran deterioradas en el mismo periodo sería $1-(1-q)^{n}-nq(1-q)^{n-1}$, que para un $q$ pequeño es aproximadamente $\binom{n}{2}q^{2}$, una cantidad de segundo orden. Con el núcleo compartido, el término dominante de la misma probabilidad es $p_0$ por la probabilidad de que al menos dos filiales estén cableadas, una cantidad de primer orden en $p_0$. La razón entre ambas es el factor por el cual la centralización eleva la exposición del grupo a eventos simultáneos y multientidad, y es grande siempre que $p_0$ no sea mucho menor que $q^{2}$, lo que casi nunca es. Este es el contenido formal de la afirmación de que la concentración acopla las filiales a un único riesgo en lugar de repartir el riesgo entre ellas.

Dos escollos merecen nota. El primero es estimar $p_0$ a partir de la experiencia del núcleo de una sola filial, lo que lo subestima, porque una filial dada ve solo los incidentes del núcleo que resultaron deteriorarla; $p_0$ debe leerse del propio registro del núcleo a través de todos los dependientes. El segundo es tratar $c$ como fijo cuando es una decisión: el grupo elige, función por función, cuánto cablear al núcleo, y el valor del modelo está en mostrar el coste, en riesgo correlacionado para todo el grupo, de cada incremento de esa elección, de modo que la elección se haga con el equilibrio de la Figura 2 a la vista y no solo sobre bases de eficiencia.

Apéndice B. Una lista de comprobación de disposiciones contractuales intragrupo

La lista de comprobación de abajo recopila las disposiciones del artículo 30 que una filial debería asegurar en su contrato para el suministro intragrupo de una función esencial o importante. No es un sustituto del Reglamento ni del asesoramiento jurídico; es una lista de trabajo para la conversación de diseño entre la función de TI central de un grupo y los consejos de sus filiales. Cada disposición es una que la filial necesita para cumplir, sobre un núcleo que no posee, un deber que DORA le impone; el entorno intragrupo es donde cada una queda, con más frecuencia, implícita y debería en cambio ponerse por escrito.

Referencias

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