El Reglamento de Ciberresiliencia convierte tu producto en un objeto regulado

Casi toda la regulación de seguridad aplica a cómo gestionas tu empresa. NIS2 pregunta por tu gestión de riesgos. El RGPD pregunta por tu tratamiento de datos personales. El Reglamento de Ciberresiliencia es distinto de una forma que pilla por sorpresa a los equipos de producto: aplica a lo que vendes.

Usa la maquinaria del derecho europeo de productos, la misma que hay detrás del marcado CE de los bienes físicos. Eso significa evaluación de la conformidad, documentación técnica, declaración de conformidad y autoridades de vigilancia del mercado que pueden ordenar la retirada de un producto. Para empresas de software sin historia en regulación de productos, es una forma desconocida.

Qué está en ámbito

Los productos con elementos digitales que se comercializan en el mercado de la Unión: software, hardware con software dentro, y sus soluciones de tratamiento remoto de datos cuando son parte integral de la función del producto.

La definición es amplia. Un dispositivo conectado, un sistema operativo, una librería vendida comercialmente, una aplicación de escritorio y una imagen de firmware califican todos. La prueba es si el producto se introduce en el mercado, lo que significa suministrado para distribución o uso en el marco de una actividad comercial.

Hay exclusiones. Los productos ya cubiertos por normas sectoriales equivalentes, como los productos sanitarios, los vehículos de motor y la aviación civil, se tratan bajo esos regímenes. El software como servicio puro queda en buena medida fuera, porque es un servicio y no un producto introducido en el mercado, pero la frontera no es tan limpia como los equipos esperan: un servicio con una aplicación cliente, un agente o un dispositivo asociado arrastra ese componente hacia dentro.

El software libre se trata con cuidado. El suministrado fuera de una actividad comercial queda por lo general fuera de ámbito, y el reglamento introduce un papel más ligero para los administradores que apoyan proyectos libres de forma comercial. Esto importa si mantienes un proyecto además de vender un producto, y el análisis de tu propio papel merece hacerse explícitamente en vez de darlo por supuesto.

Los productos se clasifican además por criticidad, con clases importantes y críticas que cubren cosas como gestores de contraseñas, sistemas de identidad, hipervisores, cortafuegos y similares. La clase determina cuánta evaluación de la conformidad puedes hacer tú y cuánta exige un organismo externo.

Las obligaciones, en términos de ingeniería

Quita el lenguaje regulatorio y hay cuatro grupos.

Seguro desde el diseño. Un producto introducido en el mercado debe entregarse sin vulnerabilidades explotables conocidas, con una configuración segura por defecto, con capacidad de actualizarse, con minimización y protección de datos para la confidencialidad y la integridad, y con la superficie de ataque limitada a lo que el producto necesita. El requisito de salir con un valor por defecto seguro en vez de cómodo es el que más a menudo obliga a cambiar productos existentes.

Gestión de vulnerabilidades. Un proceso documentado para recibir, triar y corregir vulnerabilidades, incluida una política de divulgación coordinada y un punto de contacto. Las actualizaciones de seguridad deben distribuirse sin demora y, cuando sea viable, separadas de las actualizaciones de funcionalidad, para que un usuario pueda tomar un arreglo sin tomar un cambio de comportamiento.

La lista de materiales de software. Tienes que identificar y documentar los componentes de tu producto, incluidas las dependencias de terceros y libres, en un formato legible por máquina, y mantenerla actualizada. Casi todos los equipos pueden generar una hoy; pocos pueden mantenerla exacta entre versiones y pocos pueden responder rápido a "qué versiones entregadas contienen este componente", que es la pregunta que de verdad importa. Las herramientas y la práctica están en OSV-Scanner, SBOM y la pregunta de la cadena de suministro.

Periodo de soporte. Tienes que declarar cuánto tiempo vas a proporcionar actualizaciones de seguridad, en función de cuánto se espera razonablemente que el producto esté en uso, con un suelo mínimo fijado por el reglamento para la mayoría de los productos. Esa declaración es un compromiso comercial con un coste asociado, y condiciona cómo retiras versiones.

Los relojes de notificación son el filo más afilado

Esta es la parte que exige un cambio operativo y no un ejercicio de documentación.

Ante una vulnerabilidad explotada activamente en tu producto, y ante un incidente grave que afecte a la seguridad del producto, tienes que notificar a la autoridad correspondiente y a la agencia europea de ciberseguridad a través de una plataforma única de notificación, con un calendario escalonado: un aviso temprano en el plazo de un día desde que lo sabes, una notificación más completa a los pocos días, y un informe final después. Hay que informar además a los usuarios del producto y, cuando proceda, indicarles las medidas correctoras.

De ahí se siguen dos cosas. Primera, alguien tiene que ser dueño de la evaluación de "¿sabemos que hay explotación activa?", lo que significa que tu recepción de vulnerabilidades, tu canal de soporte y tu inteligencia de amenazas tienen que llegar a una sola mesa. Segunda, el plazo arranca con el conocimiento, así que puede empezar un viernes por la tarde a partir de un aviso enviado por un formulario que nadie vigila en fin de semana.

Cabléalo en el proceso de incidentes con una persona decisora nombrada, exactamente igual que con los otros regímenes de notificación, como se explica en el runbook que usas a las tres de la madrugada.

Evaluación de la conformidad y el marcado

Para la mayoría de los productos el fabricante realiza la evaluación por sí mismo, la documenta, redacta una declaración de conformidad de la Unión y coloca el marcado CE. Para las clases de mayor criticidad interviene un organismo notificado, o bien aplicas una norma armonizada que permita la autoevaluación.

Igual que con el Reglamento de IA, las normas armonizadas son el mecanismo que convierte unos requisitos esenciales amplios en algo contra lo que un equipo pueda implementar, y el trabajo de normalización sigue en curso. La conformidad con una norma armonizada da presunción de conformidad, que es por lo que todo el mundo las quiere. Hasta que estén, implementas contra los requisitos esenciales del texto y mantienes tu documentación estructurada para poder recortarla de otra forma.

Necesitas además conservar la documentación técnica durante un periodo definido tras la introducción del producto en el mercado y producirla cuando se solicite.

El calendario y la trampa de la fecha intermedia

La aplicación es por fases. Las obligaciones no empiezan todas a la vez: los deberes de notificación de vulnerabilidades e incidentes aplican antes que el grueso de las obligaciones, que es lo contrario de lo que la mayoría de los equipos supone al planificar.

La consecuencia práctica es que la capacidad de notificar es lo primero que hay que construir, aunque parezca el punto más pequeño de la lista. Consulta las fechas vigentes de cada obligación en vez de trabajar con una única fecha de titular, porque el escalonamiento es el detalle que determina qué necesitas este año.

Dónde se solapa con lo que ya haces

Si tienes ISO 27001, tu sistema de gestión, la gestión de proveedores y el proceso de incidentes se aprovechan. Las diferencias son específicas de producto: la disciplina de la lista de materiales, el periodo de soporte declarado, la configuración segura por defecto y la separación de las actualizaciones de seguridad de las de funcionalidad.

Si además estás en ámbito de NIS2, ten en cuenta que responden a preguntas distintas. NIS2 regula la resiliencia operativa de tu organización; el Reglamento de Ciberresiliencia regula tu producto. Una empresa puede estar en ámbito de los dos, y la evidencia se solapa pero las obligaciones no se sustituyen, que es el mismo problema de modelado que se describe en un conjunto de controles para cuatro marcos y merece tratarse igual. El lado organizativo está en el ámbito y las obligaciones de NIS2.

Lo que se olvida

• Los importadores y distribuidores también tienen deberes. Si revendes el producto de otro en la Unión, no eres un simple canal.
• Una modificación sustancial te convierte en fabricante. Cambiar la marca o alterar significativamente un producto te trae encima el paquete completo de obligaciones.
• La lista de materiales hay que mantenerla, no generarla una vez. Una foto de la entrega de hace dos años no responde a la pregunta que crea una divulgación.
• El fin de vida está ahora regulado. Dejar de dar soporte a una versión antes del periodo declarado tiene consecuencias más allá del enfado del cliente.
• Tus propias dependencias heredan la presión. Espera que a tus proveedores les hagan las mismas preguntas, y espera que te las hagan a ti tus clientes.

Qué hacer esta semana

Responde por escrito a una pregunta: para tu producto principal, cuánto tiempo te comprometes a dar actualizaciones de seguridad, y ¿puedes listar hoy todos los componentes de terceros de la versión que un cliente instaló el mes pasado? Si la segunda respuesta exige un proyecto de investigación, ese es el hallazgo, y construir el pipeline de la lista de materiales es el primer trabajo. Lo acotamos en la fase de producto de un proyecto de seguridad.