DORA os libró de NIS2. No os librará del CRA.

TL;DR. El 11 de septiembre el CRA activa un plazo de 24 horas. Recae sobre productos, así que la exención de DORA frente a NIS2 nunca lo alcanza.

Puntos clave

Qué empieza realmente el 11 de septiembre. El CRA entró en vigor el 10 de diciembre de 2024 con un calendario escalonado, y es el escalonamiento lo que se pierde por el camino.
Por qué la exención de DORA no lo alcanza. Esta es la parte que merece precisión, porque el razonamiento que produce la respuesta equivocada es un razonamiento genuinamente bueno llevado un reglamento demasiado lejos.
¿Es usted fabricante? Nadie lo ha resuelto por usted. Aquí la posición honesta es que la cuestión está abierta y no zanjada, y que un banco que espere a que se zanje esperará más allá de la fecha.
La colisión de relojes. Supongamos por un momento que el análisis concluya que al menos un artefacto está dentro.

En treinta y nueve días el Reglamento de Ciberresiliencia activa un plazo de notificación de veinticuatro horas, y la exención a la que todo banco recurre no lo detiene. Pregunte a una entidad financiera si le aplica NIS2 y la respuesta llega sin titubeos: DORA es lex specialis, el artículo 4 de NIS2 se aparta cuando un acto sectorial cubre el mismo terreno, y el banco notifica sus incidentes TIC a su autoridad competente y no a un CSIRT. Esa respuesta es correcta. También está a punto de darse, erróneamente, a una pregunta sobre otro reglamento. El CRA no regula entidades. Regula productos, e impone sus obligaciones a quien los fabrica. Su artículo de ámbito no contiene ninguna exclusión para los servicios financieros, porque una exclusión redactada para derecho de entidades no tiene a qué agarrarse en derecho de productos. Desde el 11 de septiembre de 2026, un banco que comercialice software debe a ENISA una alerta temprana en veinticuatro horas, y la debe además de DORA, no en su lugar.

Resumen ejecutivo

Una fecha viva, no un horizonte. El artículo 14 se aplica desde el 11 de septiembre de 2026. El resto del CRA espera al 11 de diciembre de 2027, y el error de planificación vive en la distancia entre ambos hechos.

El ámbito lo decide lo que entrega, no lo que usted es. Las exclusiones del CRA son otros regímenes de productos: sanitarios, vehículos, aviación, equipos marinos. La banca no figura, y nunca iba a figurar.

El disparador es la explotación, no la gravedad. Una vulnerabilidad explotada activamente arranca el reloj aunque ningún cliente se vea afectado y aunque nada constituyera un incidente grave bajo DORA.

Hoy nadie es su dueño. La notificación DORA vive en resiliencia operativa. La notificación CRA vive en quien se considere fabricante, un papel que la mayoría de los bancos nunca ha asignado.

Qué empieza realmente el 11 de septiembre

El CRA entró en vigor el 10 de diciembre de 2024 con un calendario escalonado, y es el escalonamiento lo que se pierde por el camino.

La aplicación plena —requisitos esenciales de ciberseguridad del anexo I, evaluación de la conformidad, marcado CE, documentación técnica— cae el 11 de diciembre de 2027. La notificación de los organismos de evaluación de la conformidad abrió el 11 de junio de 2026. Entre ambas se sitúa la fecha que importa este trimestre: el 11 de septiembre de 2026, cuando arrancan las obligaciones de notificación del artículo 14.

La estructura tiene tres fases y es más ajustada de lo que parece a primera vista.

Alerta temprana en 24 horas desde que el fabricante tiene conocimiento de una vulnerabilidad explotada activamente, o de un incidente grave con impacto en la seguridad del producto.
Notificación completa en 72 horas, con el detalle técnico y las medidas correctoras o de mitigación adoptadas.
Informe final en 14 días desde que existe una medida correctora para una vulnerabilidad explotada activamente, o en un mes desde la notificación para un incidente grave.

Los informes circulan por la plataforma única de notificación del CRA operada por ENISA. El fabricante presenta una sola vez, ante el CSIRT designado como coordinador en el Estado miembro de su establecimiento principal; la plataforma pone la notificación a disposición de ENISA simultáneamente, y el CSIRT receptor la propaga a los CSIRT de otros territorios donde se distribuya el producto. Ese diseño de envío único elimina una excusa administrativa, pero no ablanda el reloj.

Fíjese en el disparador. Ni la gravedad ni el impacto en el cliente: la explotación. Una vulnerabilidad explotada activamente abre una obligación de 24 horas, haya o no perjudicados, y con independencia de que los mismos hechos se clasifiquen como incidente grave en cualquier otro sitio.

Por qué la exención de DORA no lo alcanza

Esta es la parte que merece precisión, porque el razonamiento que produce la respuesta equivocada es un razonamiento genuinamente bueno llevado un reglamento demasiado lejos.

El artículo 4 de NIS2 contiene un mecanismo de remisión: cuando un acto sectorial de la Unión exige a las entidades adoptar medidas de gestión de riesgos de ciberseguridad o notificar incidentes significativos, y esos requisitos son al menos equivalentes en efecto, las disposiciones correspondientes de NIS2 no se aplican. DORA es exactamente uno de esos actos. Así, una entidad de crédito gestiona el riesgo TIC y notifica incidentes graves bajo DORA, y los deberes paralelos de NIS2 se apartan. Cualquier función de asuntos regulatorios sabe recitarlo.

Tres cosas rompen la analogía al trasladarla al CRA.

El mecanismo vive dentro de NIS2. El artículo 4 es una disposición de la Directiva (UE) 2022/2555 que inaplica disposiciones de la Directiva (UE) 2022/2555. No es un principio general según el cual el régimen sectorial de una entidad financiera desplace todo lo demás. No puede entrar en el Reglamento (UE) 2024/2847 ni desactivar nada allí, porque nada del CRA está sujeto a él.

El CRA regula productos, no entidades. DORA y NIS2 preguntan ambos qué clase de organización es usted. El CRA pregunta qué introdujo en el mercado. Son preguntas distintas, y los argumentos de equivalencia entre ellas no funcionan: en ningún sentido el régimen de notificación de DORA es «equivalente en efecto» al deber de un fabricante de avisar a un CSIRT de que un artefacto entregado está siendo explotado, porque protegen poblaciones distintas. DORA protege el sistema financiero a través del supervisor. El artículo 14 protege a todo el que ejecuta el producto, a través de la red de CSIRT.

Las exclusiones tienen otra forma. El artículo de ámbito del CRA excluye los productos cubiertos por otra legislación sectorial de productos: sanitarios bajo los Reglamentos (UE) 2017/745 y 2017/746, vehículos bajo el Reglamento (UE) 2019/2144, aviación civil bajo el Reglamento (UE) 2018/1139, equipos marinos bajo la Directiva 2014/90/UE, además de piezas de recambio fabricadas con especificaciones idénticas y productos desarrollados exclusivamente para seguridad nacional o defensa. No hay exclusión para servicios financieros, ni para productos fabricados por entidades reguladas bajo DORA. No es un descuido que unas directrices vayan a corregir. Es lo que ocurre cuando un legislador escribe derecho de productos: no excluye industrias, excluye otros regímenes de productos.

Tabla 1: tres regímenes, y cuál se aparta

	DORA	NIS2	CRA
Regula	Entidades financieras	Entidades esenciales e importantes	Productos con elementos digitales
El deber recae en	La entidad	La entidad	El fabricante
Disparador de notificación	Incidente clasificado como grave	Incidente significativo	Vulnerabilidad explotada activamente o incidente grave
Destinatario	Autoridad competente	CSIRT o autoridad competente	CSIRT del establecimiento principal, y ENISA
¿Se aparta para bancos?	No: es la lex specialis	Sí, vía artículo 4 de NIS2	No: nada lo desplaza

¿Es usted fabricante? Nadie lo ha resuelto por usted

Aquí la posición honesta es que la cuestión está abierta y no zanjada, y que un banco que espere a que se zanje esperará más allá de la fecha.

El CRA alcanza a los productos con elementos digitales comercializados —suministrados para su distribución o uso en el marco de una actividad comercial—. De esa formulación se derivan dos consecuencias inmediatas.

El precio no es el criterio. El software suministrado gratuitamente entra en el ámbito si se suministra en el marco de una actividad comercial. El planteamiento de la Comisión sobre el código abierto gira en torno a la actividad comercial y no al pago, y un banco que distribuye una aplicación para captar y atender a clientes de pago no actúa fuera del marco de una actividad comercial. La intuición de que «regalamos la aplicación, luego no vendemos un producto» es la razón más habitual por la que este expediente sigue sin abrirse, y es el más débil de los argumentos disponibles.

El software estrictamente interno queda fuera de verdad. Los productos no comercializados —la plataforma de core bancario, el utillaje interno, todo lo que nunca se suministra más allá de la entidad— no están alcanzados. Es una exclusión real y sustancial, y por eso la exposición es más estrecha de lo que sugiere la versión alarmista de este análisis.

La pregunta, por tanto, no es si un banco entra en el ámbito como entidad. Es qué artefactos concretos suministra. Cuatro categorías merecen inventario antes de llegar a conclusión alguna:

La aplicación de banca móvil, distribuida al público general por las tiendas de aplicaciones. Si una aplicación de cara al cliente es un producto suministrado para uso, o meramente la interfaz de un servicio que presta el banco, es la cuestión genuinamente controvertida, y está controvertida, no resuelta a favor del banco.
Artefactos para desarrolladores: SDK, bibliotecas cliente, utillaje de API e implementaciones de referencia publicadas para clientes corporativos o socios. Estos se parecen mucho más a productos suministrados y mucho menos a una interfaz de servicio.
Proyectos de código abierto que la entidad publica y mantiene como parte de su actividad comercial, donde además pueden entrar en juego las disposiciones sobre el administrador.
Software de marca blanca o embebido que el banco reentrega a socios bajo su propio nombre, la vía más rápida para pasar de implantador a fabricante en cualquier régimen de productos de la UE.

La postura honesta de planificación no es afirmar una conclusión. Es inventariar los artefactos, fijar por escrito una posición razonada sobre cada uno y poder mostrar el razonamiento si un CSIRT pregunta por qué no llegó ninguna notificación.

La colisión de relojes

Supongamos por un momento que el análisis concluya que al menos un artefacto está dentro. Lo que cambia operativamente no es la existencia de un proceso de incidentes —los bancos lo tienen— sino que ahora corren dos procesos sobre el mismo suceso con parámetros distintos.

Una vulnerabilidad en un SDK publicado por un banco pasa a explotación activa. DORA pregunta si se trata de un incidente grave relacionado con las TIC que afecta a la entidad y, en caso afirmativo, la notificación inicial va a la autoridad competente en las cuatro horas siguientes a esa clasificación y, en todo caso, en las 24 horas siguientes al conocimiento, con un informe intermedio y uno final detrás. El artículo 14 pregunta algo por completo distinto —si se está explotando un producto que esta entidad fabricó— y lanza su propia alerta temprana de 24 horas a un CSIRT y a ENISA.

Ambos pueden divergir en las dos direcciones, y eso es lo que hace inseguro cualquier proceso fusionado.

Una vulnerabilidad explotada en un SDK entregado que no cause ninguna interrupción de los servicios propios del banco puede no ser incidente grave alguno bajo DORA y encajar de lleno en el artículo 14. Y una caída severa de una plataforma construida internamente es una notificación DORA sin dimensión CRA alguna, porque nada se introdujo en el mercado. Construir un único flujo que presuponga que ambos se disparan siempre juntos produce a la vez falsos negativos y ruido regulatorio innecesario.

Tabla 2: qué establecer antes del 11 de septiembre

Pregunta	Qué determina en su exposición
¿Qué artefactos suministramos fuera de la entidad?	El ámbito es por producto; no hay respuesta a nivel de entidad
Para cada uno, ¿hay una posición documentada sobre el estatus de fabricante?	Una asunción sin documentar no es una defensa
¿Dónde está nuestro establecimiento principal a efectos de CSIRT?	Determina qué CSIRT nacional recibe la presentación
¿Estamos registrados en la plataforma única de notificación de ENISA?	24 horas no bastan para descubrir un trámite de alta
¿«Explotada activamente» tiene dueño en el triaje?	El disparador difiere de toda escala de gravedad ya en uso
¿Quién presenta a las 03:00 de un domingo?	Ambos relojes corren en tiempo real, no en horario de oficina

La cifra que fija la prioridad

El incumplimiento de los requisitos esenciales del anexo I y de las obligaciones de los artículos 13 y 14 conlleva multas administrativas de hasta 15 millones de euros o el 2,5 % del volumen de negocios anual mundial total, la cuantía que sea mayor. Otras obligaciones de fabricantes, importadores y distribuidores quedan un escalón por debajo, en 10 millones o el 2 %, y facilitar información incorrecta o engañosa a las autoridades, en 5 millones o el 1 %.

Lea el escalón superior frente al trabajo al que se ata. Determinar si cuatro categorías de artefactos están dentro del ámbito, registrarse en una plataforma de notificación y añadir una rama a un manual de triaje existente es una tarea modesta, con dueño designado y cinco semanas por delante. No es comparable al programa de evaluación de la conformidad y documentación técnica que aguarda en diciembre de 2027. La asimetría entre la exposición y el coste de remediación es todo el argumento, y es el raro argumento de cumplimiento que sobrevive al contacto con una reunión de priorización.

El manual operativo

Cinco movimientos, y el primero no es un dictamen jurídico.

Inventaríe lo que sale del edificio. No sistemas: artefactos. Todo lo que la entidad suministra a alguien de fuera, incluidas aplicaciones gratuitas, bibliotecas publicadas y repositorios de código abierto. La mayoría de bancos no tiene esa lista, porque ninguna norma anterior la pidió.
Fije una posición por artefacto, por escrito. Fabricante o no, y por qué. El valor no está en acertar en cada línea; está en tener un razonamiento anterior al incidente en lugar de construido después.
Dese de alta ya en la plataforma única de notificación. Registro, credenciales y presentador designado son justo el tipo de requisito previo que resulta invisible hasta que un reloj de 24 horas ya corre.
Desdoble el disparador en el triaje. Añada una pregunta explícita —¿se está explotando activamente un producto que fabricamos?— evaluada con independencia de la clasificación de incidente grave de DORA. La independencia es el punto: un control anidado hereda el umbral equivocado.
Arranque el trabajo de SBOM contra la fecha de diciembre de 2027. El anexo I exige una lista de materiales de software en formato común legible por máquina que cubra al menos las dependencias de primer nivel. Ese deber está a dieciséis meses, y es el mismo problema de enumeración que las entidades ya están fallando en el lado criptográfico.

El patrón no es nuevo. Se redacta un régimen pensando en una industria concreta, las entidades financieras leen el nombre de la industria y concluyen que el expediente es de otro. El CRA se escribió para fabricantes de dispositivos y proveedores de software. Alcanza al banco igualmente, en el hueco estrecho en el que el banco resulta ser uno de ellos, y la exención a la que todos recurrirán primero se escribió en otra ley, para otro fin, y no aplica.

Preguntas frecuentes

Notificamos bajo DORA. ¿No basta con eso?
No. DORA desplaza las obligaciones paralelas de NIS2 mediante el mecanismo de remisión del propio artículo 4 de NIS2. Ese mecanismo es interno a NIS2 y no surte efecto sobre el Reglamento (UE) 2024/2847. El CRA impone deberes a los fabricantes de productos, no a las entidades financieras, así que no hay nada que un argumento de lex specialis pueda desplazar.

¿Entra nuestra aplicación de banca móvil en el ámbito?
Esa es la cuestión genuinamente abierta, y debe responderse de forma deliberada y no darse por supuesta. La aplicación es software con conexión de datos, suministrado al público en el marco de una actividad comercial, que es la formulación legal. El argumento contrario es que constituye la interfaz de un servicio regulado y no un producto suministrado para uso. Documente una posición; no se apoye en que sea gratuita, porque el precio no es el criterio.

¿Qué dispara exactamente el plazo de 24 horas?
Tener conocimiento de una vulnerabilidad de su producto que esté siendo explotada activamente, o de un incidente grave con impacto en la seguridad del producto. El disparador es la explotación, no la gravedad ni el impacto en el cliente, y por eso no se superpone a la clasificación de incidente grave de DORA.

¿Ante quién presentamos en la práctica?
A través de la plataforma única de notificación del CRA de ENISA, dirigida al CSIRT designado como coordinador en el Estado miembro de su establecimiento principal. ENISA la recibe simultáneamente, y el CSIRT receptor la comparte con los CSIRT de otros territorios donde se distribuya el producto. Una presentación, no varias.

¿Empieza algo más en septiembre?
No. Solo las obligaciones de notificación del artículo 14. Los requisitos esenciales de ciberseguridad, el deber de SBOM, la evaluación de la conformidad, la documentación técnica y el marcado CE se aplican todos desde el 11 de diciembre de 2027. Tratar septiembre como el expediente entero es la imagen invertida de ignorarlo.

¿Cuál es el coste si erramos el alcance?
Los incumplimientos de los artículos 13 y 14 y de los requisitos esenciales del anexo I conllevan multas de hasta 15 millones de euros o el 2,5 % del volumen de negocios anual mundial total, la cuantía que sea mayor. El coste más inmediato es procedimental: una alerta temprana omitida no se subsana con efecto retroactivo, y el momento en que una entidad descubre que era fabricante no debería ser aquel en que un CSIRT pregunta por qué no llegó ninguna notificación.

Referencias

Parlamento Europeo y Consejo de la Unión Europea, 2024. Reglamento (UE) 2024/2847 relativo a los requisitos horizontales de ciberseguridad para los productos con elementos digitales (Reglamento de Ciberresiliencia). Bruselas: Diario Oficial de la Unión Europea. Disponible en: Parlamento Europeo y Consejo de la Unión Europea, 2024..
Comisión Europea, 2026. Reglamento de Ciberresiliencia — Obligaciones de notificación. Bruselas: Dirección General de Redes de Comunicación, Contenido y Tecnologías. Disponible en: Comisión Europea, 2026..
Comisión Europea, 2026. El Reglamento de Ciberresiliencia — Resumen del texto legislativo. Bruselas: Dirección General de Redes de Comunicación, Contenido y Tecnologías. Disponible en: Comisión Europea, 2026..
Parlamento Europeo y Consejo de la Unión Europea, 2022. Directiva (UE) 2022/2555 relativa a las medidas destinadas a garantizar un elevado nivel común de ciberseguridad en toda la Unión (Directiva NIS 2). Bruselas: Diario Oficial de la Unión Europea. Disponible en: Parlamento Europeo y Consejo de la Unión Europea, 2022..
Parlamento Europeo y Consejo de la Unión Europea, 2022. Reglamento (UE) 2022/2554 sobre la resiliencia operativa digital del sector financiero (DORA). Bruselas: Diario Oficial de la Unión Europea. Disponible en: Parlamento Europeo y Consejo de la Unión Europea, 2022..

Última revisión 2026-08-16.

Volver a publicar este artículo

DORA os libró de NIS2. No os librará del CRA. — Sebastien Rousseau

El 11 de septiembre el CRA activa un plazo de 24 horas. Recae sobre productos, así que la exención de DORA frente a NIS2 nunca lo alcanza.

Este artículo se publica bajo Creative Commons Attribution 4.0 International. La republicación requiere atribución a la URL canónica.

DORA os libró de NIS2. No os librará del CRA. — Sebastien Rousseau

El 11 de septiembre el CRA activa un plazo de 24 horas. Recae sobre productos, así que la exención de DORA frente a NIS2 nunca lo alcanza.

Originally published at https://sebastienrousseau.com/es/2026-08-03-cyber-resilience-act-article-14-reporting-banks-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER