La mayoría de los calendarios de cumplimiento recogen la Ley de Resiliencia Cibernética como una obligación que entrará en vigor en diciembre de 2027. Es entonces cuando se aplicará el contenido de la normativa: seguridad desde el diseño, documentación técnica, evaluación de la conformidad y marcado CE.
Sin embargo, las obligaciones de notificación entran en vigor bastante antes. A partir del 11 de septiembre de 2026, los fabricantes de productos con elementos digitales deberán notificar las vulnerabilidades explotadas activamente y los incidentes graves dentro de los plazos establecidos, y estas obligaciones se extienden a los productos ya comercializados en el mercado de la UE. Un producto que se comercializó por primera vez en 2018 y que todavía se vende hoy en día entra dentro del ámbito de aplicación desde el primer día.
Para los fabricantes, esto supone un plazo de notificación de 24 horas. Para el grupo mucho más amplio de organizaciones que compran y utilizan tecnología en lugar de comercializarla, la CRA introduce algo menos visible y para lo que están considerablemente menos preparadas: un nuevo flujo de notificaciones de seguridad procedentes de terceros, según su calendario y no el suyo.
A dos semanas de la fecha, muy pocas organizaciones han determinado quién las recibirá.
No hay que presentar ninguna notificación en la propia fecha. No hay que presentar ninguna declaración ni rellenar ningún formulario. El 11 de septiembre es el momento en el que entran en vigor las obligaciones desencadenadas por un evento, lo que hace que sea más difícil planificarlo que un plazo convencional. El desencadenante es un incidente, y los incidentes no se ajustan a los calendarios.
Para los fabricantes, el marco es claro. Una vez que una organización tiene conocimiento de que una vulnerabilidad en uno de sus productos está siendo explotada activamente, dispone de 24 horas para emitir una alerta temprana, de 72 horas para proporcionar una notificación más completa y de un plazo definido a partir de entonces para presentar un informe final. Las sanciones por incumplimiento de las obligaciones fundamentales de los fabricantes establecidas en el reglamento ascienden a 15 millones de euros o al 2,5 % de la facturación anual mundial, lo que sea mayor.
Más adelante se aborda si una organización entra en esa categoría. La observación más general, que hasta ahora ha suscitado poca atención, es que el efecto operativo más inmediato del CRA lo sufrirán las organizaciones que no regula directamente.
Merece la pena detenerse en la secuencia de lo que entrará en vigor en septiembre.
Está previsto que la plataforma de notificación gestionada por la ENISA esté operativa en esa fecha, y no antes. Las normas armonizadas que definirán en qué consiste el cumplimiento por parte de los fabricantes siguen en fase de consulta pública. Y el requisito de mantener una política coordinada de divulgación de vulnerabilidades —el mecanismo a través del cual los fabricantes suelen enterarse de que sus productos están siendo objeto de explotación— no será de aplicación general hasta diciembre de 2027.
Por lo tanto, la obligación de notificar precede a la obligación de establecer el canal a través del cual se originan la mayoría de las notificaciones.
No se trata de un descuido. Refleja un cambio deliberado en la secuencia de la regulación digital de la UE: las obligaciones se introducen por etapas y entran en vigor antes que la infraestructura de apoyo, partiendo de la idea de que esperar a que las herramientas estén completas retrasaría la reducción de riesgos en años. La Directiva NIS2 siguió este patrón. La Ley de IA lo siguió. La CRA lo está siguiendo ahora.
Para las funciones de GRC, la implicación es estructural más que táctica. Los programas de cumplimiento normativo tienen que operar cada vez más en el intervalo entre la entrada en vigor de una obligación y la maduración del ecosistema que la rodea. Planificar partiendo de la hipótesis de que la normativa llega ya completamente formada es planificar basándose en un modelo que ya no es válido.
Esto requiere una evaluación breve y meditada, ya que las excepciones salen caras.
Pocas organizaciones se describen a sí mismas como fabricantes. La normativa no se basa en la autodescripción. Tiene en cuenta lo que se comercializa en el mercado de la UE y bajo qué nombre o marca comercial. El hardware de marca propia, el firmware integrado, los dispositivos conectados revendidos bajo el logotipo de la propia empresa y el software integrado en un producto físico pueden hacer que una organización entre en el ámbito de aplicación. Los importadores y distribuidores que cambian la marca de un producto o lo modifican sustancialmente asumen con ello las obligaciones del fabricante.
Por lo tanto, la cuestión relevante no es si una organización desarrolla software. Es: ¿qué comercializa la organización en el mercado de la UE, bajo qué nombre y qué contiene ese producto?
Recomendamos documentar la respuesta esta semana. Para la mayoría de las organizaciones, se trata de una tarea breve. Para una minoría, supone la diferencia entre un programa gestionado y uno no planificado.
Además de sus obligaciones frente a las autoridades, la CRA exige que un fabricante que tenga conocimiento de una vulnerabilidad explotada activamente o de un incidente grave informe a los usuarios afectados y, cuando proceda, a todos los usuarios, indicando las medidas de mitigación que estos puedan adoptar. Si un fabricante no lo hace en un plazo razonable, el CSIRT nacional coordinador podrá comunicar la información directamente.
Desde el punto de vista del destinatario, esto genera un flujo entrante totalmente nuevo. A partir del 11 de septiembre, las organizaciones comenzarán a recibir notificaciones de seguridad relativas a productos de su propio entorno, emitidas por el fabricante de dichos productos, que a menudo no es la parte con la que mantienen la relación comercial.
De ello se derivan tres consecuencias.
La responsabilidad no está definida. Estas notificaciones suelen llegar a un gestor de cuentas, al departamento de compras o a un buzón compartido que se revisa en horario laboral. Según nuestra experiencia, los avisos de vulnerabilidad de los proveedores rara vez se canalizan de forma predeterminada hacia el proceso de clasificación de incidentes. Se escalan de manera informal, por quienquiera que reconozca su importancia.
La notificación da lugar a una evaluación, no a una notificación. Esta distinción se suele malinterpretar y conviene ser preciso al respecto. Un aviso del fabricante no constituye por sí mismo un incidente notificable. Que se convierta en uno según la NIS2 o la DORA depende de si los propios servicios de la organización se ven afectados de manera significativa, lo cual rara vez resulta evidente en la primera hora. Ese es precisamente el argumento a favor de estructurar la primera hora. Cuando posteriormente se alcance el umbral, se esperará que la organización demuestre el momento en que tuvo conocimiento del incidente.
Actualmente, los contratos no abordan esta cuestión. Pocos acuerdos con proveedores especifican el canal de notificación, el formato, el destinatario designado o el plazo previsto. En este sentido, la CRA ofrece al ámbito de la contratación pública algo de lo que carecía hasta ahora. Durante una década, la garantía de seguridad de los proveedores se ha basado en gran medida en cuestionarios con una fuerza contractual limitada. El reglamento establece ahora una base de referencia a partir de la cual se pueden negociar compromisos específicos: acceso a una lista de materiales de software (SBOM), una política de divulgación publicada, un período de soporte definido y mecanismos de notificación acordados. Cabe señalar que la CRA obliga a los fabricantes a elaborar una lista de materiales de software (SBOM), pero no les obliga a facilitarla a sus clientes. Esa distinción es para lo que sirven las renovaciones de los contratos, y la mayoría de las renovaciones tienen lugar mucho antes de diciembre de 2027.
Todos los plazos de este régimen comienzan a contar a partir del momento en que se tiene conocimiento.
La Comisión Europea ha abordado esta cuestión a nivel de los fabricantes, publicando en julio de 2026 unas directrices que explican cuándo se considera que un fabricante ha tenido conocimiento. Lo que ninguna directriz externa puede determinar es quién, dentro de una organización determinada, es capaz de tener conocimiento en su nombre.
En la práctica, la señal llega a través de un ingeniero de soporte a las 19:00, de un investigador que escribe a un buzón genérico o del equipo de operaciones de seguridad de un cliente que se pone en contacto con un gestor de cuentas que se encuentra de baja.
El paralelismo con el RGPD resulta instructivo. Las infracciones se han declarado con semanas de retraso, no por ocultación, sino por un fallo en la clasificación. El servicio de asistencia registró el problema como un defecto. El departamento de TI lo trató como una configuración errónea. Nadie había acordado qué constituía un suceso notificable, nunca se inició la evaluación y el departamento jurídico no se enteró hasta que un cliente planteó una pregunta.
Antes del 11 de septiembre deberían existir tres elementos documentados: los criterios que activan una evaluación inmediata, las personas autorizadas para escalar el asunto y tomar una decisión fuera del horario laboral, y el registro en el que se consigna ese momento.
Dos semanas no son suficientes para establecer un programa completo de CRA. Sí lo son para establecer los componentes que deben entrar en funcionamiento en primer lugar.
Para las organizaciones que comercializan productos en el mercado de la UE:
Para el resto de organizaciones:
El último punto es el único que demuestra si los demás funcionan.
Una organización puede utilizar todas las herramientas disponibles y, aun así, pasar por alto el momento decisivo.
No se puede presentar una alerta temprana basándose únicamente en un certificado. No se puede clasificar un producto mediante una política. Y no se puede llevar a cabo una evaluación de 24 horas siguiendo un proceso que solo existe como un documento que nadie ha ensayado.
Las organizaciones que gestionen bien el mes de septiembre serán aquellas en las que una persona designada, contactada a las 19:00 de un sábado, comprenda que está autorizada a actuar.
Sea cual sea la tecnología, todo comienza con la dosis adecuada de gobernanza.
Dos semanas no son suficientes para crear un programa de CRA, pero sí lo son para responder a las dos preguntas que plantea este artículo: si la normativa se aplica a su organización y quién recibe la notificación cuando llega.
Nuestros servicios de CRA abarcan el análisis del ámbito de aplicación, la preparación para la presentación de informes en virtud del artículo 14, el encaminamiento de las notificaciones de los proveedores y la integración de las obligaciones de CRA en los programas NIS2 y DORA ya en marcha.
Animamos a las organizaciones a mantener esa conversación antes del 11 de septiembre. A partir de esa fecha, la situación será diferente.