Cyber Resilience Act: todas las herramientas y artículos
Reglamento (UE) 2024/2847, anexo I · ISO/IEC 27001:2022, anexo A
Los requisitos esenciales del CRA, en correspondencia con ISO 27001
Un fabricante con un SGSI certificado hace primero una pregunta: ¿cuánta documentación técnica tengo ya? La respuesta tiene tres partes. Para los 14 requisitos de la parte I, las propiedades del producto, el SGSI ejecuta el proceso y el producto aporta la evidencia. Para 3 de los 8 requisitos de gestión de vulnerabilidades de la parte II, el registro del SGSI es la evidencia. Y para 4 de los 22, nada del anexo A produce lo que pide el Reglamento.
Un sistema de gestión no es un producto
ISO 27001 certifica cómo una organización gestiona la seguridad de la información. El Cyber Resilience Act regula un producto: qué hace, cómo se construye y cómo se gestionan sus vulnerabilidades durante su período de soporte. Los dos se encuentran en los controles de desarrollo del anexo A, que rigen cómo se construye el producto, y en los controles de gestión de vulnerabilidades, que rigen lo que ocurre después de la publicación. No se encuentran en las propiedades del propio producto: ningún registro del SGSI muestra que un producto se entrega con una configuración segura por defecto. Lo muestran la documentación y las pruebas del producto.
Tres respuestas, no una puntuación
- El registro del SGSI es la evidencia
- 3
- El registro que produce el control es lo que cita la documentación técnica: el registro de vulnerabilidades, el diario de correcciones, los informes de pruebas.
- El SGSI ejecuta el proceso, el producto aporta la evidencia
- 15
- El control fija el requisito, el principio, la regla de codificación o la prueba; la evidencia de que el producto lo cumple es la del producto, por versión.
- No lo produce el anexo A
- 4
- Nada del anexo A publica nada, elabora una lista de materiales de un producto ni se compromete a actualizaciones gratuitas. Eso se escribe para el Reglamento.
Parte I: las propiedades del producto
El punto 1 es el deber general, basado en la evaluación de riesgos. El punto 2 enumera trece propiedades, cada una aplicable sobre la base de esa evaluación, de modo que una propiedad considerada no aplicable se excluye con una justificación en la documentación. Para todas, el SGSI aporta el proceso: los requisitos de seguridad que el producto debe cumplir, los principios con los que se diseña, las reglas de codificación, las pruebas antes de la publicación. La evidencia de cada propiedad es la del producto.
I.1 Nivel adecuado de ciberseguridad desde el diseño
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- Cláusula 6.1.2
- A.5.8
- A.8.25
Lo que la documentación aún necesita: Una evaluación de riesgos de ciberseguridad del propio producto (artículo 13, apartados 2 y 3), conservada en la documentación técnica según el anexo VII, punto 3. El SGSI evalúa los riesgos de la organización; los del producto son un registro aparte.
En el paquete de documentación técnica: Cybersecurity risk assessment
I.2.a Sin vulnerabilidades explotables conocidas en la publicación
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.8
- A.8.29
Lo que la documentación aún necesita: La comprobación se hace por versión y por componente entregado, y su resultado queda con esa versión. Un análisis de los propios sistemas de la organización es otro registro.
En el paquete de documentación técnica: Standards applied and test evidence
I.2.b Configuración segura por defecto
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.9
- A.8.26
Lo que la documentación aún necesita: La configuración segura por defecto y el restablecimiento a ella son propiedades del producto, demostradas por su documentación y sus pruebas, no por una configuración de referencia de los sistemas de la organización.
En el paquete de documentación técnica: Standards applied and test evidence
I.2.c Actualizaciones de seguridad
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.8
- A.8.32
Lo que la documentación aún necesita: Un mecanismo de actualización en el producto, automático por defecto con una opción de renuncia para el usuario, y una notificación a los usuarios cuando hay una actualización disponible: una función, no un proceso.
En el paquete de documentación técnica: Standards applied and test evidence
I.2.d Protección frente al acceso no autorizado
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.26
- A.8.5
- A.5.15
- A.5.16
- A.5.17
En el paquete de documentación técnica: Standards applied and test evidence
I.2.e Confidencialidad de los datos
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.26
- A.8.24
En el paquete de documentación técnica: Standards applied and test evidence
I.2.f Integridad de datos, órdenes y configuración
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.26
- A.8.24
- A.8.9
En el paquete de documentación técnica: Standards applied and test evidence
I.2.g Minimización de datos
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.26
- A.5.34
En el paquete de documentación técnica: Standards applied and test evidence
I.2.h Disponibilidad de las funciones esenciales y básicas
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.26
- A.8.6
- A.8.14
En el paquete de documentación técnica: Standards applied and test evidence
I.2.i Sin efectos negativos en otros dispositivos y redes
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.27
- A.8.20
En el paquete de documentación técnica: Standards applied and test evidence
I.2.j Superficie de ataque limitada
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.27
- A.8.9
En el paquete de documentación técnica: Standards applied and test evidence
I.2.k Efectos reducidos de los incidentes
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.27
- A.8.28
En el paquete de documentación técnica: Standards applied and test evidence
I.2.l Registro y supervisión de seguridad
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.26
- A.8.15
- A.8.16
En el paquete de documentación técnica: Standards applied and test evidence
I.2.m Eliminación segura y sencilla de datos y ajustes
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.26
- A.8.10
En el paquete de documentación técnica: Standards applied and test evidence
Parte II: la gestión de vulnerabilidades durante el período de soporte
Ocho requisitos para el fabricante, ninguno de los cuales puede excluirse. Aquí es donde un SGSI está más cerca del Reglamento, y donde están las carencias concretas: la lista de materiales, la divulgación pública, la política, la dirección de contacto y las actualizaciones gratuitas.
II.1 Identificar y documentar vulnerabilidades y componentes, con una SBOM
El registro del SGSI es la evidencia
El proceso, en el anexo A
- A.8.8
- A.5.9
Lo que la documentación aún necesita: Una lista de materiales de software en un formato de uso común y legible por máquina, que cubra al menos las dependencias de primer nivel del producto. Ningún control del anexo A pide una lista de materiales de un producto.
En el paquete de documentación técnica: Software bill of materials procedure
II.2 Corregir las vulnerabilidades sin demora
El registro del SGSI es la evidencia
El proceso, en el anexo A
- A.8.8
- A.8.32
Lo que la documentación aún necesita: Actualizaciones de seguridad entregadas por separado de las actualizaciones de funcionalidad cuando sea técnicamente viable: una práctica de publicación que el anexo A no nombra.
En el paquete de documentación técnica: Security updates and support statement
II.3 Pruebas y revisiones periódicas
El registro del SGSI es la evidencia
El proceso, en el anexo A
- A.8.29
- A.8.8
- A.5.35
En el paquete de documentación técnica: Vulnerability handling process
II.4 Divulgar las vulnerabilidades corregidas
No lo produce el anexo A
Lo que la documentación aún necesita: La divulgación pública de cada vulnerabilidad corregida una vez disponible la actualización: descripción, productos afectados, efectos, gravedad y cómo la corrigen los usuarios. El anexo A no tiene ningún control que publique nada.
En el paquete de documentación técnica: Vulnerability handling process
II.5 Política de divulgación coordinada de vulnerabilidades
No lo produce el anexo A
Lo que la documentación aún necesita: Una política de divulgación coordinada de vulnerabilidades, establecida y aplicada. El anexo A exige un proceso de incidentes, no una política publicada para quienes notifican desde fuera.
En el paquete de documentación técnica: Coordinated vulnerability disclosure policy
II.6 Un contacto para notificar vulnerabilidades
No lo produce el anexo A
Lo que la documentación aún necesita: Una dirección de contacto publicada para notificaciones de vulnerabilidades en el producto y en sus componentes de terceros, y un medio para recibirlas.
En el paquete de documentación técnica: Coordinated vulnerability disclosure policy
II.7 Distribución segura y oportuna de las actualizaciones
El SGSI ejecuta el proceso, el producto aporta la evidencia
El proceso, en el anexo A
- A.8.24
- A.8.32
Lo que la documentación aún necesita: El mecanismo de distribución es el del producto: actualizaciones firmadas, entregadas de forma segura y a tiempo, automáticamente cuando proceda.
En el paquete de documentación técnica: Security updates and support statement
II.8 Parches de seguridad gratuitos con avisos
No lo produce el anexo A
Lo que la documentación aún necesita: Actualizaciones de seguridad gratuitas durante el período de soporte, sin demora, con un aviso a los usuarios. Un compromiso comercial y una publicación, y el anexo A no nombra ninguno de los dos.
En el paquete de documentación técnica: Security updates and support statement
4 cosas que el anexo A no produce
Escritas una a una, para que un fabricante certificado sepa qué redactar, no solo qué citar. Cada una de las 4 acaba en uno de los 3 documentos del paquete de documentación técnica, y esos documentos se redactan a partir de la ficha del producto, no del SGSI.
II.4 Divulgar las vulnerabilidades corregidas
La divulgación pública de cada vulnerabilidad corregida una vez disponible la actualización: descripción, productos afectados, efectos, gravedad y cómo la corrigen los usuarios. El anexo A no tiene ningún control que publique nada.
II.5 Política de divulgación coordinada de vulnerabilidades
Una política de divulgación coordinada de vulnerabilidades, establecida y aplicada. El anexo A exige un proceso de incidentes, no una política publicada para quienes notifican desde fuera.
II.6 Un contacto para notificar vulnerabilidades
Una dirección de contacto publicada para notificaciones de vulnerabilidades en el producto y en sus componentes de terceros, y un medio para recibirlas.
II.8 Parches de seguridad gratuitos con avisos
Actualizaciones de seguridad gratuitas durante el período de soporte, sin demora, con un aviso a los usuarios. Un compromiso comercial y una publicación, y el anexo A no nombra ninguno de los dos.
Lo que esta página no es
No es una puntuación de cobertura. Aquí no se calcula ningún porcentaje y no debería calcularse. Un requisito cuyo proceso está en el SGSI y cuya evidencia aún no está en la documentación no es una fracción cubierta; es un documento que hay que escribir.
No es una presunción de conformidad. Solo una norma armonizada citada en el Diario Oficial la da (artículo 27), e ISO 27001 no es, ni será, esa norma. Dónde están las normas armonizadas, y qué significa su ausencia para cada nivel
No es la correspondencia NIS2. NIS2 regula la organización y sus medidas están escritas a partir de ISO 27001, por lo que esa correspondencia es más cercana. El Reglamento de Ejecución NIS2 en correspondencia con ISO 27001
Leer a continuación
CRA anexo I: los 22 requisitos esenciales, como lista de verificación
El anexo I del Reglamento de Ciberresiliencia es lo que su producto debe cumplir desde el 11 de diciembre de 2027 y lo que la documentación técnica debe demostrar. La parte I son 14 requisitos del producto, 13 de ellos «cuando proceda» sobre la base de su evaluación de riesgos; la parte II son 8 requisitos de gestión de vulnerabilidades que se aplican siempre. Aquí están en una sola tabla, con lo que pide cada uno y si puede excluirlo.
Qué contiene la documentación técnica del CRA: el anexo VII, punto por punto
Desde el 11 de diciembre de 2027, todo producto con elementos digitales introducido en el mercado de la UE necesita documentación técnica antes de introducirse, conservada diez años o durante el período de soporte, lo que sea más largo. El anexo VII dice qué contiene en ocho puntos. Aquí están, lo que cada uno pide realmente, los cuatro documentos que presupone la parte II del anexo I, y cuánto tiempo la conserva.
Normas armonizadas para el CRA: qué pide la solicitud de normalización M/606, para cuándo, y qué tiene hoy un fabricante
El artículo 27 da una presunción de conformidad a los productos que siguen normas armonizadas citadas en el Diario Oficial. El 3 de febrero de 2025 la Comisión pidió 41 de ellas a CEN, CENELEC y ETSI, con plazos del 30 de agosto de 2026 al 30 de octubre de 2027; los tres aceptaron el 3 de abril de 2025. A 12 de septiembre de 2026, el índice de normas armonizadas de la Comisión sigue sin entrada para el Reglamento, lo que para un producto de clase I significa que no hay vía de autoevaluación con arreglo al artículo 32(2). Qué se pidió, las fechas, y contra qué construir mientras tanto.
La autoevaluación según el CRA: lo que el módulo A exige realmente, según el anexo VIII y las FAQ de la Comisión
La mayoría de los productos de software nunca verán un organismo notificado. Usan el módulo A, el procedimiento de control interno del anexo VIII, y «autoevaluación» es la palabra que todo el mundo emplea sin decir qué contiene. El anexo VIII, parte I, son cinco puntos; las FAQ de la Comisión añaden la lista de actividades, el hecho de que no se impone ninguna metodología de ensayo, dónde lleva un producto de software su marcado CE, las dos formas de la declaración de conformidad, y el calendario de las normas armonizadas que decide cuándo la autoevaluación deja de significar «directamente contra el anexo I».
La evaluación de riesgos de ciberseguridad del CRA: lo que el artículo 13 exige realmente, y el único resultado que debe producir
El artículo 13, apartados 2 a 4, del Reglamento de Ciberresiliencia convierte la evaluación de riesgos en el documento del que cuelga cualquier otra obligación del CRA. Debe analizar los riesgos a partir de la finalidad prevista, el uso previsible y las condiciones de uso durante el tiempo de uso esperado; decir si y cómo se aplica cada requisito del punto 2 de la parte I; decir cómo se aplican el punto 1 de la parte I y la parte II; estar documentada, mantenida al día durante el período de soporte e incluida en la documentación técnica, con una justificación clara de cada requisito excluido. Los cuatro apartados, y una estructura de una página que los satisface.
¿Exige el CRA una SBOM? Sí, y esto es exactamente lo que dice
El anexo I, parte II, punto 1 del Reglamento de Ciberresiliencia exige una lista de materiales de software en un formato de uso común y legible por máquina que cubra al menos las dependencias de primer nivel. Va en la documentación técnica, no se publica, y una autoridad de vigilancia del mercado puede pedirla previa solicitud motivada. Las tres frases que lo deciden, y lo que dejan abierto.
La política de divulgación coordinada de vulnerabilidades que exige el CRA: tres disposiciones, y una política de una página que las cumple
El anexo I, parte II, punto 5, del Reglamento de Ciberresiliencia exige a todo fabricante en el ámbito establecer y aplicar una política de divulgación coordinada de vulnerabilidades. El artículo 13, apartado 17, exige un punto de contacto único para las notificaciones, fácil de encontrar y no limitado a herramientas automatizadas; el anexo II, punto 2, exige el contacto y la ubicación de la política en la información al usuario; el anexo VII, punto 2, letra b), pone ambos en la documentación técnica. Qué pide cada disposición, qué debe decir una política y qué no debe prometer.
El Reglamento de Ciberresiliencia para un pequeño fabricante de software, en doce pasos
Todo lo que una empresa de diez personas que entrega software instalado o un dispositivo tiene que hacer según el CRA, en el orden en que hacerlo: la determinación del ámbito, el nivel, el CSIRT y la autoridad de aplicación, el procedimiento de notificación que se aplica desde el 11 de septiembre de 2026, y después la documentación técnica, los 22 requisitos, la SBOM, el período de soporte, el marcado CE y la declaración, con plazo el 11 de diciembre de 2027. Cada paso con su artículo y el texto que lo explica.
Las 4 carencias son 3 de los 11 documentos de la documentación
StandardOS mantiene los registros del SGSI que producen los 23 controles en correspondencia, y el paquete de documentación técnica redacta los 11 documentos del anexo VII a partir de la ficha del producto, entre ellos la política de divulgación, la declaración de actualizaciones y el procedimiento SBOM. La correspondencia de esta página es la unión entre ambos.
El anexo I se aplica desde el 11 de diciembre de 2027. Los controles son los 93 del anexo A de ISO/IEC 27001:2022, citados por referencia; la correspondencia es nuestra y no de ISO ni de la Comisión. Esto no es asesoramiento jurídico, y el Reglamento es el texto que hay que leer: Reglamento (UE) 2024/2847.