Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- El registro de información de DORA recoge los contratos de servicios tecnológicos prestados de forma continuada, por lo que una biblioteca que se descargue sin contrato normalmente no figura en él.
- Las normas técnicas vinculantes exigen el seguimiento de las bibliotecas de código abierto utilizadas por los servicios que prestan funciones críticas o importantes.
- El software integrado en los sistemas de una entidad financiera está sujeto a las normas de gestión de riesgos, independientemente de que exista o no un contrato con el proveedor.
Los requisitos de cumplimiento de la DORA se aplican a las bibliotecas de código abierto incluso cuando no figuran en tu registro de información. La Ley de Resiliencia Operativa Digital (DORA) de la UE las menciona en sus normas técnicas sobre la gestión de riesgos de las tecnologías de la información y la comunicación (TIC), que son independientes de las normas relativas a los contratos con los proveedores.
El registro de información es la lista que mantiene una entidad financiera de sus contratos de servicios de TIC en curso. Que una biblioteca figure en él depende de si existe un contrato subyacente, como uno de asistencia técnica de pago. Las normas de gestión de riesgos se aplican a la biblioteca en cualquier caso, siempre que se ejecute en tus sistemas. Por lo tanto, debe figurar en el inventario del software que utilizas, incluso cuando el registro no la incluya. La ausencia de una biblioteca en dicho inventario constituye una laguna en el registro exigido por el DORA. Los supervisores pueden ordenarle que la subsane, y cada Estado miembro establece sanciones por el incumplimiento del DORA. Las autoridades publican las resoluciones definitivas sobre las sanciones.
¿A qué organizaciones se aplican los requisitos de cumplimiento de la DORA?
La DORA se aplica a veinte categorías de entidades financieras, entre las que se incluyen las entidades de crédito, las entidades de pago y de dinero electrónico, las empresas de inversión, las aseguradoras, los proveedores de servicios de criptoactivos, las contrapartes centrales y los centros de negociación. Los proveedores de servicios de TIC externos, es decir, las empresas que prestan servicios tecnológicos a dichas entidades, figuran en una lista aparte y solo están sujetos a la supervisión directa de la UE si se les designa como críticos.
Algunas entidades quedan fuera del ámbito de aplicación, entre ellas determinados gestores de fondos de inversión alternativos de menor tamaño y aseguradoras, entidades de pensiones con hasta 15 afiliados y entidades de giro postal (bancos postales que gestionan cuentas de pago). Los Estados miembros también pueden excluir a determinadas entidades que la Directiva bancaria de la UE exime de sus propias normas.
Las empresas de inversión pequeñas y no interconectadas, las entidades de pago y de dinero electrónico exentas, las pequeñas entidades de pensiones (con menos de 100 afiliados) y las entidades exentas de la Directiva bancaria que los Estados miembros mantengan dentro de su ámbito de aplicación cuentan con un marco simplificado de gestión de riesgos de las TIC, con normas específicas recogidas en las normas técnicas. Si este es tu caso, empieza por ahí. El resto debe seguir el marco completo, adaptado al tamaño y al perfil de riesgo, y así se aplica también el resto de este artículo.
El registro se basa en contratos
El texto principal de la DORA es el Reglamento (UE) 2022/2554, al que en lo sucesivo se hará referencia como «el Reglamento». El artículo 3 del Reglamento define a un proveedor de servicios de TIC de terceros como una empresa que presta servicios de TIC, y a los servicios de TIC como servicios digitales y de datos prestados de forma continuada a través de sistemas de TIC. El registro, las condiciones contractuales y las normas de salida se aplican a los proveedores que prestan este tipo de servicios.
De conformidad con el artículo 28, apartado 3, deberá llevar un registro con información sobre todos los acuerdos contractuales relativos a dichos servicios, diferenciando aquellos que dan soporte a funciones críticas o importantes del resto. Se consideran funciones críticas o importantes aquellas cuya interrupción perjudicaría de manera significativa las finanzas de la entidad, sus servicios o su capacidad para cumplir las condiciones de su autorización. Al menos una vez al año, deberá comunicar sus nuevos contratos a la autoridad competente, indicando quién los presta y qué servicios y funciones abarcan. Asimismo, deberá facilitar el registro completo cuando se le solicite. Las plantillas estándar del registro se derivan del Reglamento de Ejecución (UE) n.º 2024/2956 de la Comisión.
El artículo 30 establece las condiciones mínimas de los contratos, y el artículo 28, apartado 8, exige estrategias de salida para los servicios que prestan apoyo a funciones críticas o importantes. Cuando un contrato para un servicio de este tipo permita la subcontratación, el artículo 29 exige que se evalúen los riesgos, incluidos los derivados de cadenas largas o complejas. Una norma técnica de regulación (NTR), el Reglamento Delegado (UE) n.º 2025/532 de la Comisión, especifica los elementos que debe determinar y evaluar cuando se subcontraten dichos servicios. Las plantillas del registro también recogen a cada subcontratista que respalda efectivamente dicho servicio.
Nota: Las Autoridades Europeas de Supervisión (AES) publican una sección de preguntas frecuentes elaborada por su personal sobre la presentación de informes al registro, disponible en la página web de la Autoridad Bancaria Europea (ABE). En ella se indica que la adquisición puntual de una solución estática, sin mantenimiento, asistencia técnica ni actualizaciones continuadas, no constituye un servicio de TIC. Se trata de una orientación del personal, no de la posición oficial de las AES.
Los proveedores críticos están sujetos a un régimen de supervisión independiente gestionado por las Autoridades Europeas de Supervisión (ESA): la Autoridad Bancaria Europea (EBA), la Autoridad Europea de Seguros y Pensiones de Jubilación y la Autoridad Europea de Valores y Mercados. Estas autoridades publicaron la primera lista de proveedores de servicios de TIC de terceros designados como críticos el 18 de noviembre de 2025 y deben actualizarla anualmente. La designación se aplica a las empresas que prestan servicios de TIC, por lo que una biblioteca de código abierto en sí misma no entra dentro de esta categoría. Una biblioteca que se descarga sin contrato queda fuera del registro, de las normas contractuales y de la supervisión de los proveedores críticos, ya que ningún proveedor te la presta como un servicio continuo. No obstante, sigue estando sujeta a las normas de gestión de riesgos de TIC de la DORA, que la tratan como software que utiliza la entidad.
Dónde aparecen las bibliotecas de código abierto en el reglamento
Los requisitos de cumplimiento del Reglamento DORA que se refieren al software de código abierto se recogen en las normas de gestión de riesgos de las TIC. El Reglamento define un activo de TIC como un activo de software o hardware de los sistemas de red e información utilizados por la entidad. El artículo 6 exige la protección de los activos de TIC, incluido el software informático, y el artículo 8 exige identificarlos, clasificarlos y documentarlos, mapear sus interdependencias y mantener inventarios.
En la tabla se enumeran los requisitos vinculantes que tienen una repercusión más directa en las bibliotecas. En ella, «RTS 2024/1774» hace referencia al Reglamento Delegado (UE) 2024/1774 de la Comisión, las normas técnicas de regulación (RTS) sobre la gestión de riesgos en las TIC.
| Tema | Qué se necesita | Fuente |
|---|---|---|
| Inventario de activos de TIC | Identificar, clasificar y documentar los activos de software y sus interdependencias, y mantener actualizados los inventarios | Reglamento, artículo 8 |
| Seguimiento de la biblioteca | Realizar un seguimiento de las bibliotecas de terceros y de código abierto utilizadas por los servicios que prestan funciones críticas o importantes, y supervisar sus versiones y actualizaciones, en colaboración con el proveedor cuando proceda. | RTS 2024/1774, artículo 10 |
| Pruebas previas a la producción | Analizar y probar el código abierto, siempre que sea posible, antes de que pase a producción, y someter a pruebas de seguridad los paquetes de software a más tardar en la fase de integración. | RTS 2024/1774, artículo 16 |
| Código malicioso | Establece medidas de seguridad contra el código malicioso y asegúrate de que solo se instale software autorizado. | RTS 2024/1774, artículo 11 |
| Políticas de parches | Mantén políticas documentadas sobre parches y actualizaciones, con plazos y procedimientos de escalado en caso de incumplimiento. | Reglamento, artículo 9; RTS 2024/1774, artículo 10 |
| Sistemas heredados | Realizar una evaluación de riesgos específica de los sistemas de TIC heredados al menos una vez al año | Reglamento, artículos 3 y 8 |
Según el Reglamento: el artículo 25, apartado 1, incluye los «análisis de código abierto» como un ejemplo de pruebas adecuadas en el programa de pruebas de resiliencia de una entidad financiera, junto con los análisis de vulnerabilidad, las revisiones del código fuente —cuando sea posible— y las pruebas de penetración.
En el caso de los componentes comerciales utilizados en servicios que no soportan funciones críticas o importantes, el artículo 10 de la norma RTS 2024/1774 sigue exigiendo que se realice un seguimiento de las bibliotecas de terceros y de código abierto que utilizan, en la medida de lo posible.
El Reglamento define un sistema de TIC heredado como aquel que sigue en uso y da soporte a las funciones de la entidad, pero que ha llegado al final de su vida útil, no es apto para actualizaciones o correcciones por motivos tecnológicos o comerciales, o ya no cuenta con el soporte de su proveedor o de un proveedor externo de servicios de TIC. Esa definición abarca sistemas de TIC completos. Cada entidad debe decidir y dejar constancia de si una biblioteca sin soporte convierte al sistema que la ejecuta en un sistema heredado. Las microempresas, es decir, las entidades financieras más pequeñas con menos de 10 empleados y una cifra de negocios o un balance total de hasta 2 millones de euros, están exentas de la revisión anual de los sistemas heredados.
Que una biblioteca figure en el registro depende de cómo te llegue la información
Cada biblioteca que se ejecute en tus sistemas se considera software utilizado por la entidad, por lo que se le aplican las normas de gestión de riesgos. Que también se apliquen las normas relativas a terceros y el registro depende de si la biblioteca te llega a través de un servicio de TIC.
Lo que se considera un servicio de TIC es una decisión que corresponde a la entidad. La pregunta y respuesta n.º 2999, una respuesta de la Comisión Europea publicada a través de las Autoridades Europeas de Supervisión (ESAs), califica la definición de «intencionadamente amplia» y deja la valoración en manos de la entidad financiera. En el caso de una biblioteca, esto significa que es usted quien decide si un acuerdo de soporte o de distribución se considera un servicio de TIC y debe figurar en el registro.
| Cómo llega la biblioteca | Activo de TIC | En el registro de información | Fundamentos |
|---|---|---|---|
| Descarga del registro público, sin acuerdo de asistencia técnica | Sí, como software, la entidad utiliza | Normalmente no, ya que no existe ningún contrato para un servicio continuo | Reglamento, artículos 3 y 28; preguntas frecuentes del personal (orientación) |
| Acuerdo de distribución comercial o de asistencia técnica | Sí | Sí, si la entidad lo considera un servicio de TIC de carácter continuo | Reglamento, artículos 3 y 28; Preguntas y respuestas n.º 2999 (orientaciones) |
| Integrado en el producto o servicio alojado de un proveedor | Sí, si se ejecuta en la red y en los sistemas de información que utiliza la entidad financiera. | La estructura del proveedor, junto con los subcontratistas que, en la práctica, sustentan los servicios que dan soporte a funciones críticas o importantes | Reglamento, artículos 28 y 29; Reglamento de aplicación 2024/2956, artículo 3 |
Cuando una biblioteca está integrada en el producto o servicio alojado de un proveedor, este suele cumplir los criterios que definen a una empresa prestadora de servicios de TIC, mientras que el responsable del mantenimiento de la biblioteca rara vez los cumple. En ese caso, las normas contractuales se aplican al proveedor, pero una biblioteca que se ejecuta en los sistemas que tú utilizas sigue estando sujeta a tus normas de gestión de riesgos.
Una breve lista de comprobación para las bibliotecas que forman parte de tus funciones críticas
Cada punto de esta lista de verificación de cumplimiento de la DORA hace referencia al texto normativo en el que se basa y da por hecho que estás sujeto a la normativa en su totalidad.
- Inventario. El inventario incluye el software que da soporte a funciones críticas o importantes y la forma en que se interconecta (Reglamento, artículo 8).
- Seguimiento. Se debe realizar un seguimiento de las bibliotecas de terceros y de código abierto utilizadas por los servicios que admiten dichas funciones, y supervisar sus versiones y actualizaciones, en colaboración con el proveedor cuando proceda (RTS 2024/1774, artículo 10).
- Pruebas. El código abierto se analiza y se somete a pruebas antes de su puesta en producción, siempre que sea posible, y los paquetes de software se someten a pruebas de seguridad a más tardar en la fase de integración (RTS 2024/1774, artículo 16).
- Código malicioso. Sus procedimientos de seguridad incluyen medidas contra el código malicioso y solo permiten el acceso a sus sistemas de software autorizado (RTS 2024/1774, artículo 11).
- Aplicación de parches. Una política documentada de parches y actualizaciones establece plazos y pasos de escalación (Reglamento, artículo 9; RTS 2024/1774, artículo 10). Cuando la única solución es una versión más reciente, la actualización puede traer consigo cambios que provoquen fallos de compatibilidad, tal y como explicamos en el artículo sobre por qué «simplemente actualízalo» es un mal consejo de seguridad.
- Sistemas heredados. Los sistemas de TIC heredados deben someterse a una evaluación de riesgos específica al menos una vez al año, salvo que se trate de una microempresa (Reglamento, artículo 8).
- Registro. En su registro de información figuran todos los acuerdos contractuales relativos a servicios de TIC, incluidos los acuerdos de software que se consideren servicios continuados, y puede explicar por qué una biblioteca concreta no figura en él (Reglamento, artículo 28).
- Funciones. El órgano de dirección establece funciones claras para las áreas relacionadas con las TIC y la forma en que se coordinan (Reglamento, artículo 5). Salvo que se trate de una microempresa, una función de control gestiona y supervisa los riesgos relacionados con las TIC, incluidos los riesgos relacionados con la biblioteca (Reglamento, artículo 6). La normativa no especifica qué equipo es responsable del seguimiento de la biblioteca, por lo que debes decidir si se encarga de ello tu equipo de riesgos de TIC o el equipo de riesgos de terceros.
Empieza por una función clave
Tu registro no mostrará las bibliotecas que hayas descargado sin contrato, así que búscalas en tus propios sistemas. Elige una función crítica o importante y enumera las bibliotecas que la componen, incluidas las que se incorporan de forma indirecta. Marca cualquier biblioteca que no cuente con un mantenedor activo en el proyecto original o que no tenga una corrección oficial para tu versión. A continuación, elige una estrategia para cada una: ya sea sustituirla, actualizarla a una versión corregida si existe, o aplicar un parche a la versión que utilizas. Una sola función es suficiente para elaborar una lista concreta de hallazgos y una forma de evaluar el resto de tu software.
Si optas por la vía de los parches, SecureChain es una opción a tener en cuenta. Analiza el código fuente de cada paquete de código abierto en busca de malware conocido y patrones de código sospechosos antes de que el paquete llegue a tus manos y, a continuación, vuelve a compilar el paquete a partir de ese mismo código fuente. Corrige las vulnerabilidades CVE recién publicadas en esos paquetes en el marco del SLA. Cada paquete incluye una SBOM para su inventario y datos VEX que indican qué CVE afectan a su versión. Su procedencia de nivel 3 según el SLSA demuestra que se ha recompilado a partir del código fuente analizado. Cuando los mantenedores originales dejan de publicar correcciones de seguridad, Endless Lifecycle Support (ELS) se hace cargo automáticamente de esos paquetes. SecureChain y ELS están disponibles para los ecosistemas de JavaScript, Python, Java, Go y PHP.
PREGUNTAS FRECUENTES
¿Qué es el cumplimiento de la ley DORA?
El cumplimiento de la DORA significa que una entidad financiera cumple con la Ley de Resiliencia Operativa Digital (DORA) de la UE, el Reglamento (UE) 2022/2554 y sus normas técnicas. El objetivo es garantizar la continuidad de los servicios ante interrupciones tecnológicas. La normativa está en vigor desde el 17 de enero de 2025.
¿Cuáles son los requisitos de cumplimiento de la ley DORA?
La Ley de Resiliencia Operativa Digital (DORA) de la UE abarca cinco ámbitos. Estos son: la gestión de riesgos de las tecnologías de la información y la comunicación (TIC), la notificación de incidentes graves relacionados con las TIC, las pruebas de resiliencia, la gestión de riesgos de terceros en el ámbito de las TIC y el intercambio de información sobre amenazas cibernéticas. Las normas técnicas aportan más detalles sobre muchos de ellos.
¿Quién debe cumplir los requisitos de conformidad con la DORA?
La Ley de Resiliencia Operativa Digital (DORA) abarca veinte categorías de entidades financieras, entre las que se incluyen entidades de crédito, entidades de pago, empresas de inversión, aseguradoras y mercados de negociación. Algunas entidades quedan excluidas, y ciertas entidades de pequeño tamaño se rigen por un marco simplificado de gestión de riesgos. Los proveedores de servicios tecnológicos están sujetos a supervisión directa únicamente si se les designa como críticos.
¿Figuran las bibliotecas de código abierto en el Registro de Información de DORA?
El registro de información de la Ley de Resiliencia Operativa Digital (DORA) recoge los contratos de servicios de tecnologías de la información y la comunicación (TIC) prestados de forma continuada. Una biblioteca que figura en un registro público no suele tener un contrato de este tipo, por lo que no aparece en la lista. El servicio de asistencia técnica de pago puede cambiar esta situación. En cualquier caso, las normas de gestión de riesgos siguen siendo aplicables a la biblioteca, ya que el software es utilizado por la entidad.
¿Se menciona el software de código abierto en la DORA?
Sí. Una norma técnica en el marco de la Ley de Resiliencia Operativa Digital (DORA), el Reglamento Delegado (UE) 2024/1774 de la Comisión, exige a las entidades financieras que realicen un seguimiento de las bibliotecas de código abierto utilizadas por los servicios de tecnologías de la información y la comunicación (TIC) que dan soporte a funciones críticas o importantes. Asimismo, exige que se realicen pruebas del código abierto antes de su puesta en producción, siempre que sea factible.
¿Cuáles son las sanciones por incumplir la ley DORA?
La Ley de Resiliencia Operativa Digital (DORA) deja en manos de cada Estado miembro la fijación de los niveles de las sanciones aplicables a las entidades financieras, que deben ser efectivas, proporcionadas y disuasorias. Las autoridades competentes pueden ordenar a una entidad que ponga fin a una infracción y adopte medidas correctoras, y publican las resoluciones definitivas sobre las sanciones. Los proveedores de tecnología crítica se enfrentan a una sanción específica a nivel de la UE de hasta el 1 % de su volumen de negocio medio diario a escala mundial, que se aplica diariamente durante un máximo de seis meses.
¿Quién asume el riesgo de dependencia en el marco de la DORA?
La Ley de Resiliencia Operativa Digital (DORA) exige que todas las entidades financieras, salvo las microempresas, asignen a una función de control la responsabilidad de gestionar y supervisar los riesgos relacionados con las tecnologías de la información y la comunicación (TIC). No especifica qué equipo se encarga del seguimiento de las bibliotecas. Es el órgano de dirección el que establece esa función, por lo que cada entidad decide si el seguimiento lo lleva a cabo su equipo de riesgos de TIC o el de riesgos de terceros.
