11 de septiembre de 2026: las tres cosas que nadie tiene listas

El día siguiente, no el día mismo

El calendario del Reglamento está escalonado y lo hemos ordenado en la página de las fechas; aquí importa una sola cosa. La obligación de notificar no produce nada el 11 de septiembre. Produce desde el 12, cuando llega el primer aviso real y tu proceso o existe o no existe.

Y es un tipo de plazo distinto de los que acostumbra la conformidad de producto. No hay un documento que entregar antes de una fecha, no hay un inspector que pase. Hay un hecho que llega cuando llega y te encuentra como estás.

La parte contraintuitiva

La consecuencia práctica pilla a muchos por sorpresa. Puede estar muy lejos de la conformidad del producto — sin marcado CE, sin documentación técnica completa, sin proceso de desarrollo seguro terminado — y aun así ser sancionable, hoy, por una notificación no presentada. Las dos cosas están desacopladas. La conformidad del objeto y el deber de notificar corren en relojes separados, y el reloj de la notificación arranca primero.

Y un producto comercializado hace años no está exento. Si sigue soportado y una vulnerabilidad suya se está explotando activamente, la obligación de notificar se le aplica exactamente igual que a un producto enviado mañana. La fecha en que salió de fábrica no entra en el cálculo; el momento en que la empresa tiene conocimiento de la explotación, sí. Vea la definición de vulnerabilidad explotada activamente en el glosario.

Las horas corren desde un hecho que no controlas

Desde el 12 de septiembre de 2026 — el día después de que la obligación surta efecto — un fabricante que tenga conocimiento de una vulnerabilidad explotada activamente en su producto tiene veinticuatro horas para presentar la alerta temprana al CSIRT designado y a ENISA. No veinticuatro horas laborables. No veinticuatro horas desde que alguien lee el correo. Veinticuatro horas desde que la empresa, como entidad, tiene conocimiento del hecho.

Esa distinción lo es todo. «La empresa tuvo conocimiento» se juzga desde fuera, con la marca temporal del mensaje que llegó, no con la historia interna de quién lo reenvió a quién. Por eso el problema es organizativo antes que técnico: el plazo lo dispara un suceso que usted no controla y empieza a correr mientras, muy probablemente, nadie mira.

23:40 de un sábado

Hagámoslo concreto. Un investigador de seguridad escribe a su buzón público a las 23:40 de un sábado: su firmware lleva un fallo y hay prueba de que se está explotando sobre el terreno. Sus veinticuatro horas terminan el domingo a las 23:40. No hay nadie en la oficina. El ingeniero que entiende ese firmware está en una boda. El buzón se vigila, en la práctica, el lunes a las nueve.

El lunes a las nueve ya lleva treinta y tres horas y nueve de retraso, y el retraso no tiene nada de técnico. No le faltó la competencia para escribir la alerta temprana — se hace en minutos. Le faltó alguien asignado a ver el mensaje, una regla escrita para decidir si califica y una vía para localizar a la persona que podía confirmar la explotación. Cada empresa que hemos visto en apuros tenía una competencia en la que apoyarse y una disponibilidad en la que no.

Tres cosas que casi nadie tiene listas hoy

Reduzca el escenario del sábado por la noche a las tres cosas que lo habrían convertido en un no-evento. Un canal de entrada atendido: una sola dirección pública para las notificaciones, de la que alguien sea responsable fuera del horario de oficina, no un buzón que se llena hasta el lunes. Una regla de calificación escrita: quién decide si una notificación entrante describe una vulnerabilidad explotada activamente, con qué criterios, y cómo se registra el «no» motivado — porque un «no» implícito no es una defensa. Una cadena de guardia: personas con nombre, umbrales horarios y suplentes, para que a las 23:40 siempre haya alguien localizable que pueda confirmar y presentar.

Estas tres son el mínimo, no todo el conjunto de obligaciones. El texto completo del art. 14 añade la notificación de las 72 horas, el informe final, el aviso a los usuarios y la notificación aguas arriba a los mantenedores de componentes — cada una con su plazo. Pero sin el canal de entrada, la regla de calificación y la cadena de guardia, nada del resto tiene ocasión de funcionar, porque la primera notificación real ya habrá quedado sin respuesta.

Añada dos requisitos administrativos con tiempos ajenos: las credenciales EU Login para llegar a la plataforma de notificación y la designación del punto de contacto ante el CSIRT nacional. Solicitarlos la noche de la emergencia significa llegar tarde por una razón que, de nuevo, no es técnica.

Qué pasa después de la primera presentación

La alerta temprana no cierra nada: abre. Quedan la notificación de las 72 horas y el informe final, cada uno con su contenido, y mientras tanto el suceso sigue evolucionando. Aquí es donde los procesos improvisados se rompen por segunda vez: la primera presentación la logra casi todo el mundo; la segunda vence cuando la empresa ya ha vuelto a lo suyo.

Y el plazo final no es uno solo. Para una vulnerabilidad explotada se ancla a la medida correctora más catorce días; para un incidente grave, a la notificación del incidente más un mes. Aplicar el primero a un caso del segundo tipo hace perder el plazo por semanas, y el error solo se ve al final.

Por eso lo que hay que preparar no es la alerta temprana, que es breve. Es el calendario que arranca con ella, y la persona que lo lleva hasta el final.