CUMPLIMIENTO Y DERECHO · TRATADO
Las vulnerabilidades en el software y los dispositivos en red no han sido durante mucho tiempo una mera cuestión de servicio al cliente. La Ley de ciberresiliencia, Reglamento (UE) 2024/2847, regula los requisitos de ciberseguridad para determinados productos con elementos digitales. Los fabricantes deben considerar conjuntamente el desarrollo de productos, la gestión de la vulnerabilidad y el diseño de contratos. Aclaramos el alcance jurídico y el apoyo en la asignación de funciones.
Qué productos y empresas están cubiertos
El punto de partida son los productos con elementos digitales cuyo uso previsto o razonablemente previsible incluya una conexión directa o indirecta de datos lógicos o físicos. Además del hardware, el software puede verse afectado. Una solución de procesamiento remoto requerida para funcionar puede ser parte del producto. Por otra parte, un servicio en la nube independiente no entra dentro de la CRA porque utiliza software.
Se examinarán los fabricantes, importadores y distribuidores, así como las funciones especiales en el software libre y de código abierto. Para algunos productos existen excepciones sectoriales. La delimitación del desarrollo de código abierto no comercial de una disposición dentro del ámbito de una actividad comercial también requiere una consideración concreta. El término "fuente abierta" por sí solo no responde a la pregunta.
Qué considerar desde Septiembre 2026
La mayoría de los requisitos materiales se aplican desde el 11 de diciembre de 2027. No obstante, los requisitos de información para los fabricantes a que se refiere el artículo 14 ya han sido aplicables desde la entrada en vigor del presente Reglamento. 11 de septiembre de 2026. Esto se refiere a vulnerabilidades explotadas activamente e incidentes graves de seguridad que afectan la seguridad de un producto capturado. No todas las vulnerabilidades encontradas desencadenan el mismo requisito de presentación de informes.
Para estas notificaciones, se aplican plazos graduales: en principio, una alerta temprana en un plazo de 24 horas y otra notificación en un plazo de 72 horas después de haber obtenido el conocimiento. Los requisitos para el informe final difieren. En el caso de una vulnerabilidad explotada activamente, los informes deberán notificarse a más tardar 14 días después de que se disponga de medidas correctivas; en el caso de un incidente grave, en principio, en el plazo de un mes a partir de la notificación de 72 horas. Por lo tanto, los hechos pertinentes deben determinarse en una fase temprana.
La notificación se efectuará a través de la plataforma europea prevista a tal efecto. También pueden existir otras obligaciones, por ejemplo en virtud de la legislación sobre protección de datos o de la BSIG. Un plan de alerta interno debe distinguir y coordinar estos procedimientos. Las obligaciones especiales de los administradores de software de código abierto tienen su propia fecha de aplicación; no deben equipararse con las obligaciones del fabricante.
Preparación de nuevas obligaciones en materia de productos
Se requiere un directorio de productos para la implementación: familia de productos, funciones, provisión, usuarios previstos, dependencias técnicas y personas responsables. La evaluación del riesgo de ciberseguridad, los requisitos de desarrollo, la documentación técnica y el procedimiento adecuado de evaluación de la conformidad se basan en ello. La clasificación de productos importantes o críticos influye en el proceso.
El período de apoyo y el suministro de actualizaciones de seguridad deben planificarse de manera legal y técnicamente sostenible. Esto también se aplica a los componentes adquiridos y a la cuestión de cómo se conocen los puntos débiles en las dependencias. Una lista de piezas de software puede ayudar con esto, pero no reemplaza la verificación de rol legal o el procesamiento de mensajes de seguridad concretos.
Lo que pertenece a los Tratados
Los contratos con desarrolladores y proveedores deben regular los requisitos de seguridad, la información sobre los componentes, las obligaciones de actualización y la cooperación en caso de incidentes. Es necesario determinar quién prepara la notificación y qué información debe facilitarse dentro del plazo interno. Las obligaciones de los productores de Derecho público no se transfieren al prestador de servicios en modo alguno mediante una cláusula contractual.
Los contratos con clientes también requieren una comparación con la descripción del producto, los compromisos de apoyo y el concepto de actualización. Las exclusiones a tanto alzado de la responsabilidad no resuelven una contradicción entre la vida útil prometida y la seguridad real.
Supervisión jurídica de un proyecto CRA
Podemos asumir la clasificación de productos individuales, la distribución de derechos en una cadena de suministro o la revisión de los contratos de desarrollo y distribución. Los organismos especializados competentes llevarán a cabo un ensayo de seguridad técnica o una evaluación de la conformidad necesaria. La documentación de los productos, el modelo de ventas, los componentes esenciales y las disposiciones de apoyo existentes deben compilarse para su entrada. Contacto con la empresa.
Base jurídica y decisiones: Ley de ciberresiliencia – Reglamento (UE) 2024/2847; Comisión Europea: requisitos de información de las agencias de calificación crediticia; Comisión Europea: Calendario de aplicación.
Situación al 2 de noviembre de 2026.
Más información: Seguridad de los productos, marcado CE y retiradas · Empresas de software · Protección de datos y seguridad informática
Cuatro ejemplos prácticos
Los siguientes casos ficticios ilustran preguntas típicas de examen. La solución concreta depende de las circunstancias del caso individual.
01 · vulnerabilidad explotada activamente
El fabricante se enterará de los ataques contra su producto y examinará sin demora el alcance, el tiempo de conocimiento y la obligación de notificación; Los canales de reparación y comunicación siguen funcionando de manera coordinada.
02 · Software con componentes de código abierto
Una aplicación comercial contiene bibliotecas extranjeras. Roles, vista general de componentes y proceso de vulnerabilidad se comprueban; la etiqueta de código abierto no libera todo el producto a una velocidad plana.
03 · Período de apoyo inadecuado
Ventas y desarrollo llaman a diferentes períodos de mantenimiento. Los compromisos, los requisitos jurídicos y la capacidad técnica de ejecución se coordinarán antes de la conclusión del contrato.
04 · Producto o servicio puro?
Un proveedor ofrece una aplicación con el procesamiento remoto necesario. La delimitación del producto se comprueba utilizando las funciones en lugar de excluir automáticamente cualquier componente de la nube.
Tu siguiente paso
¿Desea transferir los requisitos a su empresa o tener un proceso específico comprobado? Una breve descripción y una referencia a los plazos existentes son suficientes para el primer contacto. Votaremos sobre el alcance del examen y la compensación antes de la puesta en marcha.
