Una entidad financiera puede describir con detalle a sus proveedores tecnológicos: quién firma el contrato, qué cláusulas de seguridad se aplican y cuándo se revisó por última vez. Sin embargo, esa misma entidad tiene más dificultades para responder a otra pregunta: si mañana se publica una vulnerabilidad explotada activamente en un componente concreto, ¿en cuántos servicios está desplegado, qué versiones se utilizan y hasta cuándo recibirán actualizaciones de seguridad?
La gestión de terceros permite conocer a la contraparte contractual, pero no necesariamente proporciona una visión completa del producto. A cubrir parte de ese espacio responde el Reglamento (UE) 2024/2847, conocido como Reglamento de Ciberresiliencia o Cyber Resilience Act (CRA).
La unidad de análisis del CRA no es la entidad ni el proveedor, sino el producto con elementos digitales: programas o equipos informáticos, incluidos los componentes comercializados por separado y las soluciones de procesamiento remoto, cuya finalidad prevista o cuyo uso razonablemente previsible implique una conexión de datos, directa o indirecta, con un dispositivo o una red (artículo 3.1). El CRA no convierte a las entidades financieras en fabricantes de tecnología, pero sí incorpora la seguridad del producto a su agenda de gobierno.
El impacto del CRA depende del papel que desempeñe cada sociedad respecto de los productos con elementos digitales que desarrolla, integra o pone a disposición del mercado. Una aplicación instalada por clientes, una solución de autenticación, un producto de pago o una solución desarrollada por una sociedad tecnológica del grupo pueden situar a la organización en escenarios distintos.
Delimitar cuestiones como cuándo una modificación es sustancial o cuándo un suministro intragrupo constituye una comercialización exige un análisis jurídico específico. Como punto de partida, la entidad debe identificar y documentar, producto a producto y sociedad a sociedad, qué rol asume en cada caso.
El CRA entró en vigor el 10 de diciembre de 2024, pero su aplicación es escalonada, y esa distinción es la clave de lectura. Desde el 11 de septiembre de 2026 son exigibles las obligaciones de notificación del artículo 14: el fabricante que tenga conocimiento de una vulnerabilidad aprovechada activamente o de un incidente grave debe notificarlo al CSIRT coordinador y a ENISA a través de la Plataforma Única de Notificación, con alerta temprana en veinticuatro horas, notificación detallada en setenta y dos e informe final posterior, además de informar a los usuarios afectados. No es una previsión de futuro: es el primer hito real del CRA y ya está vigente. Alcanza, además, a productos comercializados con anterioridad.
Lo demás todavía no es exigible. Los requisitos esenciales de ciberseguridad del anexo I, la documentación técnica, incluida la SBOM; el inventario legible por máquina de los componentes de software y de sus dependencias, al menos las de máximo nivel; los procedimientos de evaluación de la conformidad, el marcado CE y la declaración UE de conformidad (artículo 28 y anexo V) se aplican desde el 11 de diciembre de 2027. Leer todo el CRA como exigible hoy genera urgencias mal dirigidas; leerlo como algo lejano desaprovecha los quince meses que separan ambas fechas.
Una entidad financiera de tamaño medio, con varias sociedades en el grupo, identifica sin dificultad al proveedor que le suministra su solución de autenticación: hay contrato, evaluación de tercero y responsable asignado. Al preguntar qué versión está desplegada en cada entorno, quién es el fabricante real del componente que sostiene esa función y en qué fecha termina su periodo de soporte, la respuesta tarda días, llega repartida entre arquitectura, operaciones y compras, y no cubre todos los entornos. No es un fallo del control de terceros: es que el control de terceros no estaba diseñado para responder a eso.
El CRA cubre parte de ese espacio. Los productos sujetos deberán permitir identificar el producto y a su fabricante, indicar su finalidad y propiedades de seguridad, facilitar un punto de contacto para vulnerabilidades, informar del periodo de soporte y de su fecha de finalización e ir acompañados de una declaración UE de conformidad. Eso no implica que la entidad usuaria reciba la composición completa del producto ni su expediente técnico.
La profundidad cambia cuando una sociedad del grupo actúa como fabricante: entonces debe documentar el producto completo, con versiones, arquitectura, componentes integrados, dependencias de terceros, vulnerabilidades, mecanismos de actualización, periodo de soporte y SBOM.
El cambio para el gobierno tecnológico consiste en conectar ambos niveles: relacionar al proveedor con el producto y la versión desplegados, el fabricante real, las actualizaciones disponibles, el fin de soporte y los servicios TIC que dependen de ellos, extendiendo la trazabilidad hasta los procesos de negocio y las funciones financieras soportadas. No se trata de sustituir la gestión de proveedores, sino de complementarla con una gestión de dependencias basada en productos.
La prueba no es si existe un procedimiento, sino si la entidad podría responder hoy mismo, sin abrir un proyecto. Ante una vulnerabilidad publicada esta mañana, ¿cuánto tarda en saber qué versiones tiene instaladas y qué servicios dependen de ellas? Ante una actualización urgente, ¿quién decide la ventana de cambio cuando el producto está desplegado en tres sociedades con calendarios distintos?
Ante un fin de soporte anunciado con doce meses de antelación, ¿se entera por el fabricante, por el proveedor o cuando ya ha vencido? Un producto conforme aporta una base de seguridad, pero no garantiza por sí solo un servicio resiliente: la resiliencia depende también de su configuración e integración, de la operación, de las personas que la sostienen y de las alternativas disponibles.
El día en que una vulnerabilidad grave afecte a un producto del grupo, la pregunta práctica no será qué norma resulta aplicable, sino cuántos relojes empiezan a correr a la vez. Si una sociedad del grupo actúa como fabricante, el CRA obliga a notificar al CSIRT y a ENISA en 24 y 72 (artículo 14). DORA exige notificar al supervisor financiero los incidentes graves relacionados con las TIC, con sus propios umbrales y plazos. Y NIS2 puede activar obligaciones adicionales para determinadas entidades. Un mismo evento, destinatarios distintos, plazos que no coinciden y evidencias que no son intercambiables.
Detrás de esa coincidencia hay tres lógicas diferentes. El CRA regula el producto y se dirige a operadores económicos; DORA regula la resiliencia operativa digital de la entidad financiera; NIS2, la ciberseguridad de determinadas entidades. Para las entidades sujetas a DORA, esta opera como norma sectorial especial frente a obligaciones equivalentes de NIS2, pero esa relación se da entre normas dirigidas a entidades, mientras que el CRA tiene por objeto el producto. Cumplir DORA no acredita la conformidad CRA de un producto.
Las tres alimentan capacidades comunes, inventarios y dependencias, cadena de suministro, terceros, vulnerabilidades, incidentes, continuidad; pero reutilizar información no equivale a reutilizar evidencias. Conviene, además, apoyar las decisiones de hoy en criterios documentados y revisarlas: la interacción entre el CRA y DORA sigue siendo objeto de desarrollo interpretativo.
No se trata de levantar un programa CRA independiente, sino de conectar capacidades que ya existen, evitando que nazca un silo más. Esa conexión exige que las responsabilidades estén asignadas antes de tener que activarlas: quién asume la condición de fabricante respecto de cada producto, quién aprueba la declaración UE de conformidad, quién fija y comunica el periodo de soporte y quién actúa como interlocutor para la notificación de vulnerabilidades e incidentes.
Buena parte de la información necesaria ya está disponible en los registros de terceros TIC, los inventarios de activos y las cláusulas contractuales. La aportación del CRA consiste en incorporar atributos que rara vez se gestionan de manera sistemática: producto y versión, fabricante real, fecha de fin de soporte, punto de contacto para vulnerabilidades y documentación de conformidad; y trasladarlos a la compra, la arquitectura, el desarrollo seguro, la gestión de cambios y la planificación de la obsolescencia. Para una sociedad que suministra productos a terceros, la conformidad no es solo cumplimiento: a partir de diciembre de 2027 condiciona la propia posibilidad de seguir comercializándolos en la Unión.
El cambio de fondo es de unidad de análisis. Ya no basta con saber quién es el proveedor: hay que saber qué producto se utiliza, quién responde de él, cómo se mantiene y qué parte de la actividad depende de su funcionamiento. Y conviene decirlo sin matices: gestionar proveedores sin gestionar productos permite a una entidad exhibir un cumplimiento formal impecable de DORA y seguir siendo ciega frente al origen real de su exposición. El contrato identifica a quién reclamar, pero no dice qué versión está desplegada, qué contiene ni cuándo dejará de recibir actualizaciones. La próxima vulnerabilidad crítica no llegará por el contrato: llegará por el producto.
¿Conoce su organización qué productos digitales pueden quedar sujetos a la CRA, qué sociedades asumirían obligaciones y si dispone de la trazabilidad necesaria para gestionarlas? Un diagnóstico inicial puede ayudarle a delimitar el alcance, identificar brechas y definir una hoja de ruta integrada con DORA, NIS2 y el modelo de resiliencia existente.
Deja un comentario