EIOPA reordena el tablero: por qué su agenda de 2026 convierte DORA en un problema de negocio para aseguradoras y pensiones

El 15 de julio no se cerró ninguna “legislación”. Lo que terminó ese día fue otra cosa, y no es un matiz menor: EIOPA dio por concluido su mandato técnico en la revisión de Solvencia II con la publicación del paquete final de directrices y normas técnicas. Traducido del dialecto regulatorio al castellano corriente: Bruselas ya decidió el marco político hace tiempo; ahora el supervisor europeo ha bajado al barro operativo. Y ahí es donde empieza el trabajo incómodo para aseguradoras y grupos transfronterizos.

Conviene pararse en esa diferencia porque en compliance las palabras no son decoración. Decir que EIOPA “cerró el proceso legislativo” es jurídicamente incorrecto. EIOPA no legisla; desarrolla estándares técnicos, emite directrices y concreta expectativas supervisoras dentro del mandato que le da el legislador europeo. Lo que ha hecho ahora es cerrar la fase técnica de la revisión. Parece una precisión de jurista puntilloso. En realidad, cambia la lectura entera: ya no estamos discutiendo hacia dónde va Solvencia II, sino cómo se va a aplicar de verdad.

Para las entidades, ese cambio de fase importa más que otro titular solemne sobre la arquitectura prudencial europea. Cuando un regulador pasa de las grandes ideas a los textos operativos, se acabó el refugio de la interpretación cómoda. Los equipos de riesgos, compliance, auditoría interna, continuidad, seguridad y compras tienen que cruzar requisitos. No solo dentro de Solvencia II. También frente a DORA, GDPR, NIS2 y, según el caso, otros marcos que pueden rozar el mismo incidente desde ángulos distintos. El resultado no es elegante. Es una superposición regulatoria bastante menos glamourosa y bastante más cara.

Qué ha hecho exactamente EIOPA, y por qué el verbo importa

La forma correcta de describir el hito es esta: EIOPA publicó el paquete final de directrices y normas técnicas vinculado a su mandato en la revisión de Solvencia II y, con ello, cerró ese mandato técnico. No cerró el procedimiento legislativo de la Unión. Ese procedimiento corresponde al legislador europeo y a la maquinaria institucional de siempre, con Parlamento, Consejo y Comisión haciendo lo suyo, a su ritmo habitual: más lento que un comité y menos previsible que un consejo de administración en crisis.

La diferencia entre “proceso legislativo” y “mandato técnico” no es semántica. Si dices lo primero, sugieres que ya no queda nada por desarrollar o interpretar a nivel institucional. Si dices lo segundo, sitúas correctamente a EIOPA como autoridad que concreta, aterriza y operacionaliza. Y eso permite entender mejor la pregunta que debería hacerse cualquier aseguradora ahora mismo: ¿qué piezas de esta revisión me obligan a cambiar procesos, documentación, controles, reporting o gobernanza, y cuáles simplemente consolidan prácticas que ya tenía en marcha?

Ese ejercicio tiene otra ventaja. Evita el error clásico de tratar Solvencia II como si viviera aislada del resto del universo regulatorio. No vive aislada. Una incidencia operacional grave en una aseguradora puede activar, según los hechos, exigencias prudenciales, obligaciones de resiliencia digital, deberes de notificación de brechas de datos y, en algunos Estados miembros, requisitos derivados de ciberseguridad nacional. Si cada función revisa su norma favorita por separado, la entidad acabará con cuatro taxonomías para el mismo incidente y cinco plazos internos incompatibles. Luego llegan las prisas, el consejo pide una explicación y alguien descubre que el “marco integrado” era una diapositiva bonita.

El verdadero efecto de la revisión: menos debate abstracto, más fricción operativa

La revisión de Solvencia II lleva años discutiéndose en términos de capital, proporcionalidad, reporting y supervisión de grupo. Todo eso sigue siendo central. Pero cuando EIOPA emite directrices y estándares técnicos, el foco se desplaza. Ya no basta con entender el espíritu de la reforma. Hay que traducirlo a flujos de aprobación, inventarios, responsabilidades de segunda línea, evidencias para supervisión y controles repetibles. Ahí aparece la fricción.

La primera fricción es organizativa. Muchas aseguradoras siguen separando de forma casi ritual el riesgo prudencial, el riesgo operacional, la ciberseguridad y la privacidad. Sobre el organigrama funciona. En un incidente real, no tanto. Una caída prolongada de un proveedor tecnológico crítico puede afectar la prestación del servicio, alterar procesos relevantes para el cálculo o la gestión de riesgos, disparar obligaciones contractuales, generar un incidente de terceros bajo DORA y, si hay datos personales comprometidos, forzar la evaluación de notificación del GDPR art. 33 ante la autoridad de control y, en ciertos casos, la comunicación a interesados del art. 34. La norma no pregunta si tus equipos se llevan bien. Simplemente espera que respondas.

La segunda fricción es documental. Cada régimen exige su propia lógica probatoria. DORA pide un enfoque muy estructurado sobre gestión del riesgo de las TIC, incidentes, pruebas de resiliencia y terceros ICT; basta mirar su núcleo en los capítulos II, III, IV y V, y en particular el régimen de terceros del art. 28 y siguientes. El GDPR no te pide resiliencia operativa como tal, pero sí medidas técnicas y organizativas apropiadas en el art. 32 y una disciplina de notificación cuando exista violación de seguridad de los datos personales en el art. 33. Solvencia II, por su parte, opera desde la prudencia, la gobernanza y el control interno. La tentación de duplicar expedientes es enorme. El coste también.

La tercera fricción es de lenguaje. “Incidente mayor”, “incidente significativo”, “violación de seguridad de los datos personales”, “disrupción operacional”, “riesgo de terceros”, “materialidad”. Son etiquetas parecidas para hechos que a veces coinciden y a veces no. Si la entidad no define un diccionario interno común, cada área reportará con sus categorías, y el comité de crisis comparará peras con requerimientos de auditoría. No es una metáfora brillante, pero describe bien el problema.

Donde Solvencia II se cruza con DORA de forma menos teórica de lo que parece

Hay un error recurrente en el mercado: pensar que DORA es “la norma TIC” y Solvencia II “la prudencial”, como si la frontera fuese limpia. No lo es. DORA impone obligaciones directas a entidades financieras sobre gestión del riesgo de las TIC, notificación de incidentes graves, pruebas de resiliencia digital y gestión del riesgo de terceros proveedores de servicios TIC. Eso está en su arquitectura básica y, para terceros, el punto de anclaje evidente es el art. 28. Solvencia II, aunque no fue concebida como norma de ciberresiliencia, sí condiciona cómo la aseguradora organiza su sistema de gobernanza, su control interno y su gestión del riesgo global.

La consecuencia práctica es bastante simple: si una aseguradora trata DORA como un proyecto puramente tecnológico, va tarde y va mal. DORA no se agota en seguridad de la información. Exige gobernanza, roles, trazabilidad, gestión de dependencia frente a terceros y capacidad de demostrar que el riesgo digital está integrado en la gestión de la entidad. Eso conversa directamente con la lógica prudencial de Solvencia II. O debería. Si todavía tienes a tecnología negociando contratos cloud sin un mapa claro de criticidad, salida, sustitución y concentración, no tienes un problema de redacción contractual. Tienes un problema de gobierno.

Además, el cruce entre ambas normas es especialmente delicado en grupos. La supervisión prudencial de grupo y la dependencia tecnológica no siempre coinciden con el perímetro jurídico más cómodo. Un servicio TIC puede estar centralizado para varias filiales en distintas jurisdicciones, con subcontratación en cadena y soporte compartido. Desde el punto de vista operacional parece eficiente; desde el ángulo supervisor, esa eficiencia puede parecer concentración mal entendida si la entidad no sabe explicar qué proceso depende de qué proveedor, qué controles compensatorios existen y qué plan de salida es realista. “Tenemos redundancia” deja de impresionar en cuanto alguien pregunta si esa redundancia depende del mismo grupo de proveedores.

El punto ciego de muchas aseguradoras: terceros, cadena de suministro y dependencia real

Si hubiera que elegir un área donde más entidades sobreestiman su madurez, sería esta. Los registros de proveedores suelen existir. Los mapas de dependencia real, bastante menos. DORA art. 28 y siguientes obligan a un enfoque mucho más serio sobre el riesgo derivado de terceros proveedores de servicios TIC: estrategia, registro de información, evaluación previa a la contratación, elementos contractuales, supervisión continuada y, crucialmente, gestión de concentración y salida. Eso ya no encaja con la vieja costumbre de meter ciberseguridad en un anexo contractual y dar el asunto por resuelto.

Solvencia II añade presión por otro lado. Una externalización relevante o una dependencia operativa crítica no solo es un asunto de compras o tecnología; toca la capacidad de la entidad para mantener funciones y controles consistentes con una gestión sana y prudente. La revisión técnica de EIOPA no inventa esa preocupación desde cero, pero la vuelve más exigible porque la supervisión dispone de más detalle operativo para preguntar lo incómodo: qué proceso exacto depende del proveedor, qué escenario de fallo se ha modelizado, qué alternativa existe, cuánto tiempo tardaría la recuperación y quién decide la desconexión si el proveedor incumple.

Aquí aparece una ironía regulatoria bastante europea: durante años se habló del outsourcing como si el riesgo estuviera en el contrato; ahora el problema evidente es que el contrato suele ser la parte más ordenada de la casa. Lo difícil es saber si el negocio puede operar cuando el proveedor no responde, si los datos son recuperables en condiciones útiles, si el plan de salida no es una ficción y si la alta dirección entiende de verdad la concentración tecnológica que ha comprado.

Incidentes: cuándo un problema técnico se convierte en un rompecabezas regulatorio

Una incidencia seria rara vez llega con una etiqueta jurídica colgada del cuello. Llega como interrupción, sospecha de compromiso, caída de servicio, degradación del rendimiento o comportamiento anómalo de un tercero. A partir de ahí, la entidad tiene que clasificar rápido. Y clasificar mal cuesta.

Si el incidente afecta a las TIC de una entidad financiera, DORA activa su propio régimen de gestión, clasificación y notificación de incidentes. Si además hay datos personales comprometidos, entra el GDPR, en particular el art. 33 sobre notificación de violaciones de seguridad de los datos personales a la autoridad de control y el art. 34 sobre comunicación a los interesados cuando proceda. Si la entidad, o alguna entidad del grupo, está dentro del ámbito de NIS2 por su encaje sectorial y por cómo se haya producido la transposición nacional, aparecen obligaciones específicas de gestión del riesgo en el art. 21 y un régimen de notificación de incidentes significativos en el art. 23. Ese reparto importa porque citar “el art. 21 y siguientes” como si todo estuviera ahí es una forma elegante de no decir exactamente dónde está cada cosa.

La lección operativa es clara. No montes tu playbook de incidentes con una sola taxonomía legal y esperes que sirva para todo. Necesitas una capa común de hechos —qué ha pasado, qué sistemas afecta, qué datos implica, qué procesos interrumpe, qué tercero está involucrado, qué impacto temporal y de negocio existe— y, a partir de ahí, reglas de escalado por régimen. El error habitual consiste en pedir al equipo técnico que decida desde el minuto uno si aquello es un incidente DORA, una brecha GDPR o un incidente NIS2. No funciona así. Primero hechos. Luego calificación jurídica. En ese orden.

También conviene asumir algo incómodo: los plazos regulatorios no se llevan bien con la investigación perfecta. GDPR art. 33 ya obliga a notificar sin dilación indebida y, cuando sea posible, dentro de las setenta y dos horas desde que el responsable tiene constancia de la violación. DORA y NIS2 operan con sus propios marcos de notificación y escalado. Si la organización espera a tener una narrativa cerrada, probablemente llegará tarde a alguno de ellos. Si notifica sin mínima gobernanza, generará inconsistencias que luego habrá que explicar al supervisor, a la autoridad de protección de datos y quizá al mercado. El equilibrio no se improvisa durante una crisis.

NIS2 no es un comodín, pero tampoco un asunto ajeno al sector asegurador

Conviene limpiar otra confusión frecuente. NIS2 no se aplica por arte de magia a cualquier empresa con servidores, ni tampoco puede descartarse de un plumazo porque “ya tenemos DORA”. Son regímenes distintos, con lógicas que pueden coexistir según la entidad, la actividad y la transposición nacional. El anclaje material de NIS2 está en su ámbito subjetivo y sectorial, mientras que sus obligaciones nucleares para entidades esenciales e importantes se articulan, entre otros, en el art. 21 para medidas de gestión del riesgo de ciberseguridad y en el art. 23 para notificación de incidentes significativos.

Por eso la formulación prudente es esta: si la entidad o alguna sociedad del grupo queda dentro del ámbito de NIS2 por su posición en sectores cubiertos y por cómo cada Estado miembro haya configurado la transposición, tendrá que atender esas obligaciones específicas. No hace falta exagerarlo ni usar NIS2 como espantajo genérico. Basta con hacer el análisis de aplicabilidad correcto. Y hacerlo pronto. Porque el riesgo aquí no es solo incumplir una norma adicional; es diseñar controles aislados para DORA y descubrir más tarde que parte del grupo tenía otro régimen paralelo con exigencias de gobierno, reporting y supervisión parcialmente solapadas.

El matiz del grupo vuelve a ser decisivo. Una aseguradora puede no encajar directamente donde alguien esperaba, pero una filial tecnológica, un proveedor intra-grupo o una sociedad que presta servicios a infraestructuras críticas sí pueden arrastrar obligaciones o, al menos, exigencias contractuales y de coordinación que terminan afectando al conjunto. La visión puramente societaria sirve para aprobar organigramas. Para gestionar incidentes complejos, suele quedarse corta.

GDPR sigue entrando por la puerta de atrás de casi todos los incidentes relevantes

Hay organizaciones que todavía hablan de privacidad como si fuera una disciplina separada de la resiliencia operativa. Luego sufren una caída de servicio con exposición potencial de datos personales y descubren, a toda velocidad, que el delegado de protección de datos no aparecía en el comité de crisis. Mala idea.

El GDPR no regula la resiliencia financiera ni la continuidad de negocio de una aseguradora. Regula, entre otras cosas, la seguridad del tratamiento y la respuesta a violaciones de seguridad de datos personales. El art. 32 exige medidas técnicas y organizativas apropiadas al riesgo. El art. 33 establece la notificación a la autoridad de control cuando la violación de seguridad pueda entrañar un riesgo para los derechos y libertades de las personas físicas. El art. 34 añade la posible comunicación a los interesados cuando el riesgo sea alto. Eso convierte a privacidad en actor obligado en una parte muy relevante de los incidentes operativos modernos, especialmente cuando terceros, sistemas compartidos y procesos de atención al cliente están en juego.

Lo interesante —y bastante poco asumido en algunas entidades— es que la lógica probatoria del GDPR no coincide del todo con la de DORA o con la prudencial. Desde protección de datos importa mucho el tipo de datos, el volumen, la facilidad de identificación, la exposición efectiva, las medidas de mitigación y el riesgo para las personas. Desde DORA importa la afectación operacional y la resiliencia de las TIC. Desde la supervisión prudencial importa la continuidad, el control y la gestión sana del riesgo. El mismo hecho requiere tres conversaciones distintas. Si tu modelo de crisis no sabe sostenerlas de forma coherente, el problema no es el regulador; es tu gobernanza.

La capa de IA: prudencia sí, automatismos no

Otra afirmación que conviene afinar es la del AI Act. Decir de manera categórica que cualquier proceso de suscripción, fraude o atención al cliente que use modelos de IA “añade otra capa” regulatoria suena contundente, pero jurídicamente necesita más cuidado. La aplicabilidad del AI Act depende del tipo de sistema, del rol de la organización y, sobre todo, de la clasificación concreta del uso dentro del propio reglamento. No todo uso analítico o automatizado entra igual, y no todo sistema empleado por una aseguradora activará las mismas obligaciones.

La forma sensata de leerlo hoy es esta: si la entidad utiliza sistemas que entren en el ámbito del AI Act y queden sometidos a obligaciones específicas por su clasificación, entonces se abrirán exigencias adicionales de gobernanza, documentación, supervisión humana, gestión del riesgo o transparencia, según el caso. Lo que no conviene hacer es convertir el AI Act en un comodín retórico. Primero hay que mapear el sistema, el propósito, el rol de la entidad y el régimen aplicable. Luego se determina el control. No al revés.

Dicho eso, el cruce operativo con seguros merece atención aunque no todo caso quede automáticamente alcanzado. Si un proceso crítico de negocio depende de modelos complejos para priorización, detección o decisión, la entidad debería saber explicar —regulatoriamente y ante auditoría— qué hace el sistema, qué datos utiliza, cómo se supervisa, qué controles existen ante degradación o error y qué intervención humana cabe. Ese deber de explicación no nace solo del AI Act. También responde a gobernanza básica, control interno y gestión prudente del riesgo. A veces la mejor razón para ordenar una función no es una norma nueva; es evitar que la antigua quede en evidencia.

IRRD: menos eslogan, más lectura funcional

También merece corrección otra frase tentadora: decir que la IRRD “introduce la lógica de prepararse antes de que llegue la crisis irreversible” suena bien, pero es una caracterización interpretativa más que un hecho verificable en esos términos. Si se quiere ser preciso, lo correcto es describir el marco por lo que efectivamente articula: planificación, medidas de preparación, facultades de intervención y herramientas de resolución y crisis para aseguradoras y reaseguradoras dentro del diseño que adopte el texto aplicable. Es menos aforístico, pero bastante más sólido.

¿Pierde fuerza analítica esa reformulación? No necesariamente. Lo útil no es adornar la IRRD con una moraleja, sino entender por qué importa para el resto del mapa regulatorio. Importa porque empuja a las entidades a pensar en continuidad, separabilidad de funciones, gobernanza en escenarios de tensión y capacidad de respuesta cuando la situación se deteriora. Y ese tipo de disciplina conversa de forma natural con la resiliencia operativa, con la dependencia tecnológica y con la calidad de la información disponible durante una crisis. No hace falta atribuirle una épica preventiva para ver el punto.

De hecho, si uno mira cómo trabajan las organizaciones en momentos de estrés, la preparación útil rara vez consiste en un gran documento estratégico. Consiste en saber quién decide, con qué información, bajo qué umbrales, sobre qué activos, frente a qué dependencias y con qué alternativas reales. Esa clase de preparación puede nacer de distintos marcos regulatorios. La etiqueta importa menos que la ejecutabilidad.

Lo que deberían hacer ahora las aseguradoras, sin esperar a otra nota del supervisor

La reacción inteligente a este cierre del mandato técnico de EIOPA no es producir otro memo celebrando que “seguimos monitorizando la evolución regulatoria”. Esa frase debería cotizar como activo tóxico en el mercado del compliance. La reacción inteligente es revisar arquitectura de cumplimiento y operativa en cuatro frentes muy concretos.

Primero, cartografía regulatoria por proceso crítico. No por norma. Por proceso. Identifica qué procesos son esenciales para negocio, servicio, solvencia, atención al cliente y obligaciones legales; qué sistemas los soportan; qué terceros intervienen; qué datos personales tratan; y qué regímenes pueden activarse si fallan. Ese mapa debe permitir responder, por ejemplo, qué exige DORA si cae el proceso, cuándo entra GDPR art. 33 si hay datos afectados y si alguna entidad del grupo está además dentro de NIS2 con obligaciones del art. 21 y del art. 23. Sin ese mapa, toda discusión sobre gobernanza es ornamental.

Segundo, unificación de taxonomías de incidente. No hace falta borrar las categorías legales propias de cada norma. Hace falta una capa interna común de clasificación basada en hechos verificables. Sistema afectado, duración, alcance geográfico, proceso impactado, tercero involucrado, volumen estimado, afectación a datos personales, medidas de contención adoptadas, dependencia de servicios compartidos y estado de recuperación. Con esa base, cada equipo jurídico-regulatorio aplica después su calificación. Parece trabajo ingrato. Lo es. Pero evita contradicciones entre notificaciones y reduce uno de los fallos más caros en una inspección: no poder demostrar por qué la organización evaluó un hecho de una manera y no de otra.

Tercero, revisión seria de terceros ICT y concentración. DORA art. 28 y siguientes no dejan demasiado espacio para la autocomplacencia. El inventario de proveedores tiene que enlazarse con procesos críticos, criticidad del servicio, subcontratación posterior, localización operativa relevante, derechos de auditoría, salidas posibles y dependencia agregada. Si además el grupo combina servicios centralizados y contratos locales, la revisión debe hacerse con lógica de grupo y no solo por entidad jurídica. Lo contrario produce una ilusión de control: cada filial cree que conoce su proveedor, pero nadie ve la dependencia acumulada.

Cuarto, ejercicios de crisis con guion regulatorio cruzado. No basta un simulacro técnico donde el SOC detecta, aísla y recupera. Hay que probar qué pasa cuando el incidente obliga a discutir simultáneamente sobre continuidad de negocio, notificación DORA, análisis GDPR art. 33 y coordinación con entidades del grupo potencialmente sujetas a NIS2. ¿Quién convoca? ¿Quién decide si hay notificación? ¿Qué evidencia mínima se exige? ¿Cómo se evita que el área de privacidad diga una cosa, tecnología otra y compliance una tercera? Si no lo has ensayado, no lo tienes resuelto. Tienes una esperanza, que es un control regulatorio francamente pobre.

El error de fondo: seguir gestionando normas por silos

Hay un patrón que se repite. Cada nueva norma genera su proyecto, su comité, su repositorio documental y su pequeño reino. Al cabo de unos años, la entidad tiene varios programas de cumplimiento que hablan de incidentes, terceros, gobernanza, reporting y pruebas, todos ellos legítimos y todos parcialmente incompatibles entre sí. Luego llega la revisión supervisora o, peor, el incidente real, y se descubre que nadie diseñó la intersección.

La revisión técnica de Solvencia II y el cierre del mandato de EIOPA deberían leerse precisamente como una señal contra ese modelo. No porque EIOPA haya dicho algo revolucionario en un eslogan, sino porque el nivel de detalle técnico ya no permite esconder la fragmentación detrás de principios generales. La conversación ha pasado del “tenemos marco” al “enséñeme cómo funciona”. Es una pregunta mucho menos cómoda.

Y, siendo honestos, tampoco es una exigencia caprichosa. El mercado asegurador depende de cadenas tecnológicas extensas, servicios externalizados, datos sensibles y operaciones transfronterizas. Pretender que la resiliencia prudencial, la resiliencia digital, la privacidad y la ciberseguridad pueden gestionarse como compartimentos estancos no es conservador. Es ingenuo. A veces sale caro. Otras veces sale en prensa.

La lectura correcta del momento regulatorio

El mensaje más útil no es que “todo ha cambiado”, porque no sería cierto. Tampoco que “nada cambia”, porque sería peor. Lo que cambia ahora es el grado de concreción exigible. Con el paquete final de directrices y normas técnicas, EIOPA ha terminado su trabajo técnico dentro del mandato de revisión de Solvencia II. Ese cierre no clausura la historia normativa europea, pero sí eleva el listón de implementación para las entidades afectadas.

La pregunta relevante ya no es si la revisión de Solvencia II tendrá efectos. Los tendrá. La pregunta es si la aseguradora va a seguir respondiendo con programas separados o si por fin va a construir una gobernanza capaz de cruzar prudencia, operaciones, tecnología, privacidad y terceros sobre hechos comunes y decisiones trazables. Ese es el examen real.

Y aquí está el matiz que muchos preferirían esquivar: ningún regulador va a integrar por ti lo que tú sigues fragmentando internamente. EIOPA ha hecho su parte técnica. DORA ya tiene su propia lógica. GDPR lleva años diciendo lo que dice en sus arts. 32, 33 y 34. NIS2 fija medidas de gestión del riesgo en el art. 21 y notificación en el art. 23 para quienes entren en su ámbito. El problema, a estas alturas, no suele ser falta de texto. Suele ser exceso de compartimentos.

Si tu entidad todavía trata estos marcos como obligaciones paralelas que apenas se tocan, el cierre del mandato técnico de EIOPA no es una nota más en la cronología regulatoria. Es un aviso bastante claro de que el supervisor va a mirar menos tus declaraciones de intención y bastante más tu capacidad de ejecución.