La obligación de notificación del Reglamento de Ciberresiliencia, artículo 14 del Reglamento (UE) 2024/2847, suele explicarse por sus relojes: 24 horas, 72 horas y un informe final. Los relojes solo arrancan cuando ocurre una de dos cosas, y ambas están definidas en el Reglamento de forma más estrecha de lo que sugieren la mayoría de los resúmenes. Notificarlo todo es tan fallo como no notificar nada: inunda al CSIRT, no dice nada a los usuarios y entrena a la organización a ignorar su propio procedimiento.

Aquí están los dos desencadenantes tal como los define el texto, y la línea que traza cada uno.

Desencadenante uno: una vulnerabilidad explotada activamente

El artículo 14, apartado 1, exige al fabricante notificar «cualquier vulnerabilidad explotada activamente contenida en el producto con elementos digitales de la que tenga conocimiento».

El artículo 3, punto 42, define el término: una vulnerabilidad explotada activamente es «una vulnerabilidad respecto de la cual existen pruebas fiables de que un agente malicioso la ha explotado en un sistema sin permiso del propietario del sistema».

Tres palabras sostienen la definición.

«Pruebas fiables». No la puntuación de gravedad de un escáner, no una prueba de concepto en un blog de seguridad, no un CVE con un rumor de «explotado en la práctica» adjunto. Pruebas de que la explotación ha ocurrido, de una calidad sobre la que usted actuaría. Las directrices de la Comisión de 27 de julio de 2026 sitúan el conocimiento en un grado razonable de certeza: ni el primer rumor, ni el análisis forense concluido.

«Un agente malicioso». La explotación por sus propios probadores de intrusión, por un investigador que la notificó de forma responsable o por un cliente que prueba su propia instalación no es explotación por un agente malicioso. La vulnerabilidad puede ser grave; no es, solo con esa prueba, un desencadenante.

«En un sistema». Cualquier sistema, no solo el de su cliente. Basta con pruebas fiables de que la vulnerabilidad de su producto ha sido explotada por un atacante en cualquier parte; no espera a que uno de sus propios usuarios resulte afectado.

Lo que queda fuera: vulnerabilidades teóricas, pruebas de concepto no explotadas, vulnerabilidades halladas por sus propias pruebas y vulnerabilidades en componentes conocidas y en corrección para las que no hay pruebas de explotación. Eso es trabajo del anexo I, parte II, gestionado y divulgado según los requisitos de gestión de vulnerabilidades, no notificaciones del artículo 14.

Desencadenante dos: un incidente grave que afecta a la seguridad del producto

El artículo 14, apartado 3, exige notificar «cualquier incidente grave que afecte a la seguridad del producto con elementos digitales». El artículo 14, apartado 5, dice cuándo un incidente es grave:

a) afecta negativamente, o puede afectar negativamente, a la capacidad de un producto con elementos digitales de proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes; o b) ha dado lugar, o puede dar lugar, a la introducción o ejecución de código malicioso en un producto con elementos digitales o en las redes y sistemas de información de un usuario del producto.

Dos cosas que observar.

«Puede». Ambas letras cubren incidentes que podrían tener el efecto, no solo los que lo tuvieron. Un incidente contenido antes de que se perdieran datos sigue siendo grave si podía causar esa pérdida.

Se trata de la seguridad del producto, no de la de su empresa. Una intrusión en su correo corporativo es un incidente, y según NIS2 puede ser notificable, pero solo es un desencadenante del artículo 14 si afecta a la seguridad del producto que introduce en el mercado: su cadena de compilación, su servidor de actualizaciones, la clave de firma, el backend en la nube del que depende un producto. La prueba es si la capacidad del producto de proteger los datos o funciones de sus usuarios está afectada, o si el código malicioso podría llegar al producto o a los sistemas de sus usuarios a través de él.

El tercer deber que acompaña a ambos: informar a sus usuarios

Artículo 14, apartado 8: tras tener conocimiento de cualquiera de los dos desencadenantes, el fabricante «informará a los usuarios afectados del producto con elementos digitales y, cuando proceda, a todos los usuarios, de esa vulnerabilidad o incidente y, cuando sea necesario, de las medidas de mitigación de riesgos y correctoras que los usuarios pueden desplegar para mitigar el impacto», cuando proceda en un formato estructurado y legible por máquina. Si el fabricante no informa a los usuarios a tiempo, el CSIRT puede hacerlo en su lugar.

Es el deber que la mayoría de los procedimientos de notificación olvidan. El CSIRT y ENISA son un destinatario. Los usuarios son el otro, y el mecanismo para llegar a ellos, la redacción y el formato legible por máquina son cosas que decidir antes del día.

No notificable sigue siendo registrable

Una vulnerabilidad o un incidente que no cumple ninguna de las dos definiciones no se notifica según el artículo 14, pero la determinación de que no la cumple es un registro que conviene conservar: qué ocurrió, por qué se juzgó que no encaja en 3, punto 42, ni en 14, apartado 5, quién lo juzgó y cuándo. Si las pruebas cambian, el conocimiento en el sentido del artículo 14 empieza entonces, y el registro muestra que el reloj estaba vigilado. Esa es la diferencia entre una empresa que decidió no notificar y una que no se dio cuenta.

Qué hacer

Escriba las dos definiciones en el procedimiento de incidentes literalmente, con las tres preguntas para cada una: hay pruebas fiables, de explotación por un agente malicioso, en cualquier sistema; el incidente afecta o amenaza la protección por el producto de datos o funciones sensibles, o código malicioso en el producto o en los sistemas de un usuario. Nombre a quien decide, y registre cada decisión, incluido el «no». Después los relojes, hacia su CSIRT y ENISA, y el mensaje a los usuarios.

Fuentes

  • Reglamento (UE) 2024/2847, artículo 3, punto 42 (citado), artículo 14, apartados 1, 3, 5 (citado) y 8 (citado). Leído en el texto del Diario Oficial en EUR-Lex el 11 de septiembre de 2026.
  • Directrices de la Comisión Europea C(2026) 5252 de 27 de julio de 2026, sobre el significado del conocimiento.

Esto no es asesoramiento jurídico. Las dos definiciones son dos frases del Reglamento; deben estar en su procedimiento tal como están escritas, no como se recuerdan.