Todo fabricante de un producto con elementos digitales dentro del ámbito del CRA debe realizar una evaluación de riesgos de ciberseguridad y conservarla por escrito. Es el documento que decide qué requisitos de seguridad del CRA vinculan a tu producto concreto, y cómo los cumples. Las autoridades de vigilancia del mercado pueden solicitarla. Sin ella, tu expediente técnico está incompleto y tu declaración de conformidad carece de base.
Esta guía explica cómo realizar la evaluación, cómo documentarla y cómo mantenerla actualizada. Incluye un mapeo completo de los requisitos de seguridad, un ejemplo resuelto y un esqueleto de documento copiable.
Resumen
- La evaluación de riesgos de ciberseguridad es obligatoria para todo producto con elementos digitales dentro del ámbito del CRA. Debe existir por escrito antes de la introducción en el mercado y mantenerse actualizada durante todo el período de soporte.
- Es un insumo de ingeniería, no papeleo. El CRA espera que la evaluación oriente la planificación, el diseño, el desarrollo, la producción, la entrega y el mantenimiento.
- Su función central es una decisión de aplicabilidad. Para cada uno de los 13 requisitos de seguridad del producto, indicas si se aplica a tu producto y cómo lo implementas. Cuando uno no se aplique, registras una justificación clara.
- El CRA no impone ningún método. Una matriz de probabilidad por impacto, un modelado de amenazas al estilo STRIDE o un proceso al estilo ISO/IEC 27005 funcionan todos, siempre que el resultado esté documentado y sea repetible.
- La evaluación forma parte de tu expediente técnico. Para un grupo reducido, los productos que el CRA trata como sistemas de IA de alto riesgo, puede integrarse en la evaluación de riesgos que exigen esas otras normas de la UE.
- Actualízala cuando aparezca información nueva relevante. Nuevas vulnerabilidades, nuevas funciones, cambios de componentes e incidentes son todos disparadores.
- Más abajo encontrarás un ejemplo resuelto y un esqueleto de documento. Adáptalos a tu producto.
Importante: la evaluación debe existir antes de completar la evaluación de la conformidad y firmar la Declaración de Conformidad. Una evaluación retroactiva no puede demostrar que su resultado orientó la planificación, el diseño y el desarrollo, que es precisamente lo que el CRA le pide que demuestre.
¿Qué es la evaluación de riesgos de ciberseguridad del CRA?
La evaluación de riesgos de ciberseguridad es un análisis documentado de los riesgos a los que se enfrenta tu producto, basado en su finalidad prevista y en los usos que razonablemente cabe esperar. Cubre las condiciones de uso, como el entorno operativo y los activos que el producto debe proteger, y tiene en cuenta durante cuánto tiempo se espera que el producto esté en uso.
La evaluación tiene un único resultado del que depende todo lo demás. Indica, para cada requisito de seguridad del producto del CRA, si ese requisito se aplica a tu producto y, si es así, cómo lo implementan tu diseño y tus procesos. También registra cómo cumples la base de diseño seguro y cómo tus procesos de gestión de vulnerabilidades cubren el producto.
Qué entra
- Para qué sirve el producto
- Cómo se usará previsiblemente
- El entorno en el que opera
- Los activos que debe proteger
- Cuánto tiempo seguirá en uso
La evaluación
- Identificar las amenazas creíbles
- Valorar los riesgos
- Decidir el tratamiento
Se mantiene actualizada durante todo el período de soporte
Qué sale
- Aplica o no, para cada uno de los 13 requisitos de seguridad
- Cómo se implementa cada requisito aplicable
- Una justificación escrita para cada exclusión
Se archiva en la documentación técnica. Informa el período de soporte.
Tres propiedades la distinguen de un registro de riesgos corporativo genérico:
- Es específica del producto. Se basa en la arquitectura, las interfaces y los usuarios de ese producto concreto. Un registro de riesgos del SGSI a nivel de empresa no la satisface. Nuestra comparación con ISO 27001 cubre esa diferencia en detalle.
- Es un documento de ciclo de vida. Se usa durante la planificación y el diseño, no solo en el lanzamiento. Y se actualiza durante todo el período de soporte.
- Es evidencia. La evaluación documentada forma parte de tu expediente técnico, donde las autoridades pueden solicitarla.
Quién la necesita, y cuándo
Todo fabricante que introduzca un producto con elementos digitales en el mercado de la UE la necesita, salvo que el producto quede completamente fuera del ámbito del CRA. Dentro del ámbito: hardware con firmware, software independiente y productos cuyo tratamiento de datos a distancia forma parte de la oferta. Se aplica igual a una empresa de software de una sola persona que a una multinacional. Los productos que el CRA excluye, como los dispositivos médicos cubiertos, ciertos vehículos y los equipos de aviación certificados, siguen en su lugar sus propias normas sectoriales. Si no estás seguro de que el CRA cubra tu producto, empieza por la guía de ámbito de aplicación.
El calendario importa más de lo que la mayoría de los equipos espera:
- Empieza durante la planificación. La evaluación está pensada para orientar las decisiones de diseño. Haz una primera pasada cuando la arquitectura todavía sea barata de cambiar.
- Complétala y documéntala antes de la introducción en el mercado. La evaluación escrita debe estar en el expediente técnico cuando el producto se lanza.
- Mantenla durante todo el período de soporte. La evaluación nunca es definitiva. Sigue al producto mientras debas actualizaciones de seguridad.
Existe una simplificación acotada. Cubre solo los productos que el CRA trata como sistemas de IA de alto riesgo y que además están sujetos a otras normas de la UE que exigen una evaluación de riesgos. Para esos productos, la evaluación de ciberseguridad puede integrarse en esa otra evaluación de riesgos en lugar de constituir un documento separado. Las obligaciones de contenido siguen siendo las mismas. Consulta la guía de solapamiento con el Reglamento de IA para ver cómo funciona en la práctica.
Qué debe contener la evaluación
El CRA fija un contenido mínimo. Tu evaluación debe cubrir tres cosas:
- El producto en contexto. Para qué sirve el producto, cómo cabe esperar razonablemente que se use, el entorno en el que opera, los activos que debe proteger y durante cuánto tiempo se espera que siga en uso.
- Decisiones de aplicabilidad. Para cada uno de los 13 requisitos de seguridad del producto: si se aplica a este producto y cómo se implementa. Cuando uno no se aplique, una justificación escrita clara.
- Cobertura de procesos. Cómo se cumple la base de diseño seguro y cómo tus procesos de gestión de vulnerabilidades cubren el producto.
El deber de justificar merece énfasis. Un «no aplica» sin motivo es un defecto. Identifica los hechos concretos del producto que eliminan el requisito, y escríbelos. La justificación escrita entra en el expediente técnico junto con el resto de la evaluación.
Más allá de ese mínimo legal, añade los controles que hacen el documento defendible: decisiones de tratamiento con su riesgo residual, criterios de aceptación, una aprobación nominal con fecha y un historial de revisiones. El CRA no exige ninguno de ellos. Son la forma de demostrar que la evaluación se mantuvo actualizada, y que alguien responsable aceptó el riesgo restante.
Elige un método
El CRA no impone ninguna metodología de evaluación, escala de puntuación ni plantilla. Lo que exige es un resultado documentado que respalde las decisiones de aplicabilidad. Elige un método que tu equipo pueda repetir, y descríbelo dentro de la evaluación para que quien la revise pueda seguir tu razonamiento.
Una regla se mantiene sea cual sea el método. Expresa cada riesgo como una combinación de su probabilidad y la magnitud de la pérdida o la interrupción que podría causar. El CRA plantea el riesgo de ciberseguridad exactamente en esas dos dimensiones, así que una lista de amenazas que no valora ninguna de las dos todavía no es una evaluación.
Opciones habituales que funcionan:
| Método | Qué te aporta | Mejor encaje |
|---|---|---|
| Matriz de probabilidad por impacto | Valoraciones numéricas sencillas de riesgo y un registro clasificado | Equipos pequeños, primeras evaluaciones |
| Modelado de amenazas al estilo STRIDE | Identificación sistemática de amenazas por componente y flujo de datos | Productos con mucho software y diagramas de arquitectura claros |
| Proceso al estilo ISO/IEC 27005 | Un ciclo completo de gestión de riesgos con contexto, análisis y tratamiento | Organizaciones que ya operan un SGSI |
| Enfoque de riesgo-amenaza de IEC 62443 | Análisis de zonas y conductos para contextos industriales | Productos industriales y OT, consulta la guía de automatización industrial |
Las próximas normas armonizadas no van a cambiar la libertad de elegir método. El borrador de norma marco europea para la gestión de riesgos del CRA es en sí mismo neutral respecto al método, y se apoya en el proceso de gestión de riesgos de ISO 31000 sin imponer un modelo de puntuación. Nuestra página de estado de las normas armonizadas sigue su avance. Y las normas nunca sustituyen la evaluación. Incluso un producto que aplica normas armonizadas en su totalidad necesita su propia evaluación documentada, y debes comprobar que las normas cubren los riesgos que de verdad identificaste.
Elijas lo que elijas, mantén dos reglas:
- El método debe producir respuestas de aplicabilidad. Un montón de riesgos valorados no basta. El resultado debe mapearse con los 13 requisitos de seguridad de más abajo.
- Escribe el método. Definiciones de la escala, fórmula, umbrales de aceptación. Una valoración de «12 (Alto)» no significa nada si la escala no está documentada. El registro debería permitir que una autoridad de vigilancia del mercado compruebe cómo se identificó, valoró y trató cada riesgo.
La evaluación, paso a paso
Un proceso funcional en siete pasos. Ajusta la profundidad a la complejidad y el riesgo de tu producto.
Paso 1: define el alcance y el contexto
Registra el nombre y la versión del producto, su finalidad prevista, los entornos en los que funcionará y sus usuarios. Indica qué está dentro del alcance, incluidas las aplicaciones complementarias, los backends en la nube que forman parte de la oferta y los componentes incluidos. Indica qué queda fuera del alcance y por qué.
Paso 2: identifica los activos
Enumera lo que el producto debe proteger. Los activos típicos son los datos de usuario, las credenciales y claves, la integridad del firmware y la configuración, la disponibilidad de la función del producto y la red circundante. Anota dónde vive cada activo y cómo se mueve.
Paso 3: identifica las amenazas
Recorre tu arquitectura superficie por superficie. Primero las interfaces externas, porque los atacantes empiezan ahí. Para cada interfaz y flujo de datos, pregúntate qué podría hacer un atacante: interceptar, suplantar, manipular, saturar, extraer. Incluye el mal uso previsible del producto, no solo el ataque deliberado. Registra cada amenaza creíble junto con la vulnerabilidad que explotaría.
Paso 4: valora los riesgos
Valora la probabilidad y el impacto de cada amenaza con tu escala documentada. Cuando un incidente pudiera causar daño físico, incluye el efecto en la salud y la seguridad de los usuarios dentro de la valoración de impacto. Clasifica los resultados. El objetivo de valorar es priorizar, no lograr precisión. Una clasificación defendible que impulsa decisiones de diseño vale más que una tabla que parece precisa pero que nadie usa.
Paso 5: decide la aplicabilidad de los requisitos de seguridad
Repasa uno a uno los 13 requisitos de seguridad del producto. Para cada uno, indica si se aplica a este producto, qué riesgos identificados aborda y cómo lo implementas. Cuando uno realmente no se aplique, escribe la justificación. La tabla de mapeo completa de más abajo es tu hoja de trabajo.
Paso 6: trata los riesgos y registra los residuales
Para cada riesgo relevante, registra el control elegido, dónde está implementado y el riesgo residual tras aplicar el control. Define criterios de aceptación y registra quién aceptó el riesgo restante. Los riesgos sin control necesitan una decisión de aceptación explícita y con responsable asignado.
Paso 7: aprueba y define los disparadores de mantenimiento
Haz que un responsable identificado apruebe la evaluación, con fecha. Después define los eventos que la reabren: nueva información sobre vulnerabilidades, nuevas funciones, cambios de componentes o proveedores, hallazgos de incidentes. Añade una tabla de historial de revisiones para que las autoridades puedan ver que el documento ha vivido.
Mapeo de los 13 requisitos de seguridad
Este es el centro de la evaluación. El CRA enumera 13 requisitos de seguridad del producto, y tu documento debe responder dos preguntas para cada uno: si se aplica, y cómo lo implementas. La tabla siguiente traduce cada requisito a preguntas de revisión y evidencia típica.
La columna del requisito se mantiene cercana al texto legal. La columna de controles no forma parte de la ley: enumera las medidas y la evidencia que los equipos suelen usar para demostrar que el requisito se cumple.
| # | Requisito | Controles y evidencia típicos |
|---|---|---|
| 1 | Comercializado sin vulnerabilidades explotables conocidas | Análisis de dependencias y firmware, prueba de penetración, registros de triaje que muestran hallazgos resueltos antes del lanzamiento |
| 2 | Configuración segura por defecto, con opción de restablecer el producto a su estado original. El fabricante y el usuario profesional pueden acordar otra cosa para un producto a medida | Revisión de la configuración por defecto, sin contraseñas por defecto, servicios innecesarios desactivados, protocolos seguros activados |
| 3 | Vulnerabilidades subsanables mediante actualizaciones de seguridad. Cuando proceda, actualizaciones de seguridad automáticas instaladas en un plazo adecuado por defecto, con opción de exclusión sencilla, notificación al usuario y posibilidad de aplazamiento | Diseño del mecanismo de actualización, política de actualizaciones |
| 4 | Protección frente al acceso no autorizado mediante mecanismos de control adecuados, como autenticación o gestión de identidades y accesos, con notificación de posibles accesos no autorizados | Arquitectura de autenticación, pruebas de control de acceso, diseño de bloqueo por intentos fallidos |
| 5 | Confidencialidad de los datos almacenados, transmitidos o tratados de otro modo, por ejemplo cifrando los datos pertinentes en reposo o en tránsito con mecanismos del estado de la técnica | Especificaciones de cifrado, procedimiento de gestión de claves |
| 6 | Integridad de datos, órdenes, programas y configuración frente a manipulaciones no autorizadas por el usuario, con notificación de corrupciones | Firma del firmware y la configuración, resultados de pruebas de integridad |
| 7 | Tratar únicamente datos adecuados, pertinentes y limitados a la finalidad prevista del producto (minimización de datos) | Inventario de datos con justificación por cada elemento |
| 8 | Disponibilidad de las funciones esenciales y básicas, también tras un incidente, incluida la resiliencia y la mitigación frente a ataques de denegación de servicio | Diseño de resiliencia, pruebas de carga y de abuso |
| 9 | Minimizar el impacto negativo del propio producto o de sus dispositivos conectados en la disponibilidad de los servicios prestados por otros dispositivos o redes | Análisis del comportamiento de red, limitación de tasa |
| 10 | Diseñado, desarrollado y producido para limitar las superficies de ataque, incluidas las interfaces externas | Inventario de interfaces, checklist de hardening, puertos de depuración cerrados |
| 11 | Diseñado, desarrollado y producido para reducir el impacto de un incidente, mediante mecanismos y técnicas de mitigación de la explotación adecuados | Flags de compilación, protecciones de memoria, sandboxing, separación de privilegios |
| 12 | Información relevante para la seguridad registrada y supervisada, cubriendo el acceso a datos, servicios o funciones o su modificación, con opción de exclusión para el usuario | Diseño de registro (logging), catálogo de eventos |
| 13 | Los usuarios pueden eliminar de forma segura y sencilla todos los datos y configuraciones de manera permanente, y cuando los datos puedan transferirse a otro producto o sistema, la transferencia se realiza de forma segura | Diseño de restablecimiento y borrado, flujo de transferencia segura |
Dos notas prácticas sobre el uso de la tabla:
- «Cuando proceda» es una decisión por producto, y te corresponde a ti defenderla. Los requisitos se aplican según tu evaluación de riesgos. Una herramienta de software independiente que no almacena datos ni configuraciones puede justificar la exclusión del requisito de eliminación de datos. Ningún producto puede excluir la capacidad de actualización solo porque las actualizaciones resulten incómodas.
- El mapeo funciona también como índice de evidencia de conformidad. La columna de controles de cada fila te indica qué debe ir en el expediente técnico, y es el material que examinará una evaluación de la conformidad.
Cobertura de los procesos de gestión de vulnerabilidades
La evaluación también debe indicar cómo tus procesos continuos cubren el producto. Los requisitos de proceso del CRA son la cara operativa de la misma moneda. Tu evaluación debe confirmar, de forma breve y con referencias a los documentos que los gestionan, que para este producto:
- identificas y documentas vulnerabilidades y componentes, incluido un SBOM que cubre al menos las dependencias de primer nivel
- abordas y remedias las vulnerabilidades sin demora, con actualizaciones de seguridad entregadas por separado de las actualizaciones de funcionalidad cuando sea técnicamente viable
- aplicas pruebas y revisiones eficaces y periódicas de la seguridad del producto
- una vez publicada una actualización, divulgas públicamente la vulnerabilidad corregida con una descripción, los productos afectados, los impactos, la gravedad y orientación de remediación. Se permite una demora justificada cuando los riesgos de seguridad de la publicación superan los beneficios, y solo hasta que los usuarios hayan tenido la posibilidad de aplicar el parche
- aplicas una política de divulgación coordinada de vulnerabilidades
- facilitas una dirección de contacto para la notificación de vulnerabilidades y ayudas a que fluya la información sobre vulnerabilidades potenciales, incluidas las de componentes de terceros
- distribuyes las actualizaciones mediante mecanismos seguros para que las correcciones lleguen a tiempo, de forma automática cuando corresponda a actualizaciones de seguridad
- difundes las actualizaciones de seguridad sin demora y de forma gratuita, con mensajes informativos que indican a los usuarios qué hacer. Para un producto a medida, un cliente profesional puede acordar otra cosa únicamente respecto al punto de gratuidad
Estos puntos son resúmenes de trabajo, no el texto legal completo. Mantén esta sección breve en tu evaluación, enlaza a los documentos de proceso que los gestionan, y comprueba los requisitos completos en nuestra guía de gestión de vulnerabilidades.
Ejemplo resuelto
Los extractos siguientes muestran el nivel de detalle que funciona en la práctica. El producto es un sensor ambiental conectado ficticio, con una aplicación complementaria y un panel en la nube.
Extracto del registro de riesgos
EVALUACIÓN DE RIESGOS DE CIBERSEGURIDAD
Producto: SmartSense Pro (SSP-3000)
Versión: 2.4.1
Fecha de evaluación: enero de 2027
Responsable: [Nombre, Equipo de Seguridad]
MÉTODO:
Probabilidad x impacto, escalas definidas en la sección 1.
Riesgo = Probabilidad (1-5) x Impacto (1-5)
Bandas: Bajo (1-4), Medio (5-9), Alto (10-16), Crítico (17-25)
-------------------------------------------------------------
ID DE RIESGO: R-001
AMENAZA: Modificación no autorizada de firmware
VULNERABILIDAD: Podría instalarse firmware sin firmar
IMPACTO: 5 - Compromiso del dispositivo, brecha de datos
PROBABILIDAD: 3 - Requiere acceso físico o a la red local
RIESGO INHERENTE: 15 (Alto)
CONTROL: Verificación de la firma del firmware
IMPLEMENTACIÓN: Firma ECDSA P-256 comprobada antes de instalar
RIESGO RESIDUAL: 3 (Bajo) - Ataque criptográfico improbable
ESTADO: Mitigado
-------------------------------------------------------------
ID DE RIESGO: R-002
AMENAZA: Interceptación de la comunicación con la nube
VULNERABILIDAD: Tráfico de red legible en tránsito
IMPACTO: 4 - Exposición de datos, inyección de comandos
PROBABILIDAD: 3 - Se esperan redes compartidas y públicas
RIESGO INHERENTE: 12 (Alto)
CONTROL: TLS 1.3 con fijación de certificado (certificate pinning)
IMPLEMENTACIÓN: Certificado de CA fijado, sin alternativa de reserva
RIESGO RESIDUAL: 2 (Bajo) - Compromiso del certificado improbable
ESTADO: Mitigado
-------------------------------------------------------------
[Continúa para todos los riesgos identificados...]
RESUMEN DE RIESGOS:
Riesgos identificados en total: 23
Crítico: 0
Alto: 3 (todos mitigados a Bajo o Medio)
Medio: 8 (todos mitigados a Bajo)
Bajo: 12 (aceptados o mitigados)
ACEPTACIÓN DEL RIESGO RESIDUAL:
Todos los riesgos residuales están dentro de la tolerancia definida en la sección 1.
Aceptado por: [Responsable de Seguridad], [Fecha]
Extracto del registro de aplicabilidad
APLICABILIDAD DE LOS REQUISITOS DE SEGURIDAD
REQ 3 - ACTUALIZACIONES DE SEGURIDAD
Se aplica: SÍ
Riesgos abordados: R-004, R-011
Implementación: Actualizaciones OTA firmadas. Actualizaciones de
seguridad automáticas activadas por defecto, con opción de exclusión
y aplazamiento en los ajustes de la aplicación.
Los usuarios reciben notificación en la aplicación y por correo electrónico.
Evidencia: Diseño del mecanismo de actualización UMD-002
REQ 12 - REGISTRO Y SUPERVISIÓN
Se aplica: SÍ
Riesgos abordados: R-009
Implementación: Los eventos de seguridad (fallos de autenticación,
cambios de configuración, eventos de actualización) se registran en
el dispositivo y se envían a la nube.
Opción de exclusión del registro disponible en los ajustes de privacidad.
Evidencia: Diseño de registro LD-001, catálogo de eventos
REQ 13 - ELIMINACIÓN SEGURA DE DATOS
Se aplica: SÍ
Riesgos abordados: R-015
Implementación: El restablecimiento de fábrica borra de forma
permanente todos los datos y configuraciones almacenados, incluidas
las credenciales de red. El dispositivo no almacena datos de usuario
transferibles, por lo que no existe ninguna vía de transferencia.
Evidencia: Diseño de restablecimiento y borrado RD-001
[Continúa para los 13 requisitos...]
Observa la entrada de eliminación de datos: el requisito cubre todos los datos y configuraciones, y las credenciales de red almacenadas cuentan. Cuando un requisito realmente no se aplique, la entrada mantiene la misma forma pero nombra los hechos del producto que lo eliminan. Una herramienta de software independiente sin datos ni configuraciones almacenados podría registrar: «No aplica. El producto no almacena datos ni configuraciones. No hay nada que eliminar.» Esa frase factual es lo que una autoridad puede evaluar.
Esqueleto del documento
Una estructura que puedes copiar para la evaluación escrita:
EVALUACIÓN DE RIESGOS DE CIBERSEGURIDAD - [Producto, versión]
1. MÉTODO
Escalas, fórmula, bandas de riesgo, umbrales de aceptación
2. CONTEXTO DEL PRODUCTO
Finalidad prevista / Uso y mal uso previsibles
Entorno operativo / Usuarios
Activos que deben protegerse
Tiempo de uso previsto
Alcance: componentes incluidos, exclusiones con motivos
3. ARQUITECTURA Y SUPERFICIE DE ATAQUE
Interfaces, flujos de datos, límites de confianza
(referencia al diagrama)
4. REGISTRO DE RIESGOS
Una entrada por cada amenaza creíble, valorada, con control,
riesgo residual y estado
5. APLICABILIDAD DE LOS REQUISITOS DE SEGURIDAD
Una entrada por requisito (los 13), se aplica sí/no,
implementación, referencia a la evidencia, justificación cuando
no se aplique
6. BASE DE DISEÑO SEGURO Y COBERTURA DE PROCESOS
Cómo el nivel de seguridad global del producto se ajusta a sus
riesgos, referencias a los procesos de gestión de vulnerabilidades
7. RIESGO RESIDUAL Y ACEPTACIÓN
Resumen, criterios de aceptación, aceptación nominal
8. APROBACIÓN Y MANTENIMIENTO
Responsable, fecha de aprobación
Disparadores de actualización
Tabla de historial de revisiones
Mantenla actualizada
La evaluación es un documento vivo durante todo el período de soporte. Reábrela cuando:
- llegue información nueva sobre vulnerabilidades del producto o de sus componentes, procedente de tu propia supervisión, informes de investigadores o avisos de proveedores
- el producto cambie, y siempre que un cambio sea lo bastante sustancial como para exigir una nueva evaluación de la conformidad
- los componentes cambien, incluidos nuevos proveedores y versiones de componentes de terceros o de código abierto
- un incidente te enseñe algo que tus valoraciones no anticiparon
Registra cada revisión en la tabla de historial, con qué cambió y por qué. Una evaluación fechada una sola vez, hace tres años, le indica a un inspector de vigilancia del mercado que el documento es decorativo.
Hay un deber de coherencia que es fácil pasar por alto. Tu evaluación considera durante cuánto tiempo se espera que el producto esté en uso. El período de soporte que declares debe reflejar ese tiempo de uso previsto, ponderado frente a sus propios factores legales. Así que los dos registros deben coincidir. Si tu evaluación prevé ocho años en el campo y tu período de soporte declarado es de cinco, revisa la determinación a la luz de esos factores. El resultado habitual es un período de soporte más largo, no una nota a pie de página que explique la diferencia.
Quién es responsable, y dónde encaja en tu flujo de trabajo
El CRA hace responsable al fabricante. No asigna roles internos ni impone una metodología de evaluación de riesgos ni un flujo de trabajo de equipo. Pero una evaluación que nadie posee se queda obsoleta, así que los equipos que funcionan bien la reparten aproximadamente así:
- El responsable de producto. Es dueño del contexto: finalidad prevista, uso previsible, tiempo de uso esperado. Decide qué promete el producto, así que aprueba cuando esa promesa cambia.
- Los desarrolladores y arquitectos. Son dueños del panorama de amenazas: interfaces, flujos de datos, los controles que tratan cada riesgo y la evidencia de que esos controles existen.
- El responsable de seguridad, o quien asuma ese papel. Es dueño del método, el registro, el registro de aplicabilidad y la aprobación. En un equipo pequeño es una sola persona con tres sombreros, y eso funciona.
Después, conecta los disparadores de actualización a los momentos donde el trabajo ya ocurre, para que la evaluación nunca dependa de que alguien se acuerde de ella:
Dónde vive la evaluación de riesgos en tu ciclo de entrega
Cuatro momentos donde el trabajo ya ocurre. Después del paso 4 el ciclo vuelve a empezar, durante todo el período de soporte.
1Arranque de la funcionalidad
Revisión rápida cuando una funcionalidad toca una interfaz, almacena datos nuevos o cruza un límite de confianza. La mayoría de las funcionalidades no cambian nada.
Obtienes: una nota de «sin cambios», o entradas actualizadas del registro
2Ejecución de CI/CD
La generación del SBOM más los análisis de dependencias y firmware siguen produciendo la evidencia del registro en cada compilación.
Obtienes: artefactos del pipeline a los que apunta el registro
3Lanzamiento
Confirma que la evaluación sigue coincidiendo con el producto antes de que se lance.
Obtienes: una entrada de revisión fechada. «Revisado, sin cambios» cuenta
4Cambio o incidente
Una actualización de componente o un hallazgo de un incidente reabre las entradas afectadas del registro.
Obtienes: una evaluación actualizada, de vuelta al siguiente arranque
La evidencia del pipeline procede de las herramientas que ya usas: la generación de SBOM en CI/CD alimenta el registro de componentes, y tu proceso de gestión de vulnerabilidades es lo que reabre las entradas en el paso 4. El CRA exige el resultado, una evaluación documentada y actualizada, no el ciclo en sí. El ciclo es lo que hace que ese deber sea sostenible frente a la presión real de la entrega.
Componentes de terceros
El riesgo de tu producto incluye los componentes que contiene. Cuando integras componentes de terceros, incluidos los de código abierto, debes ejercer diligencia debida para que no comprometan la seguridad del producto. En la evaluación, eso significa:
- los riesgos de los componentes aparecen en el registro cuando son relevantes, con el SBOM como columna vertebral del inventario
- se indica tu enfoque de selección y supervisión de componentes, con referencias a la evidencia de los proveedores
- las vías de actualización de los componentes forman parte del análisis de la capacidad de actualización
La mecánica práctica, incluido un cuestionario para proveedores, está en la guía de diligencia debida de proveedores.
Dónde vive la evaluación
La evaluación escrita forma parte de tu expediente técnico, junto a la documentación de diseño, la evidencia de pruebas y el registro de la decisión del período de soporte. Mantén recuperables la versión aprobada, su historial de revisiones y la evidencia a la que apunta durante todo el tiempo que deba conservarse el expediente. La guía de documentación técnica muestra la estructura del expediente y dónde va cada artefacto.
Errores comunes
- Escrita a posteriori. Una evaluación producida la semana antes del lanzamiento no puede haber informado el diseño. Quien la revisa se da cuenta.
- Sin decisiones de aplicabilidad. Un registro de riesgos por sí solo no responde a la pregunta que hace el CRA. Cada uno de los 13 requisitos necesita una respuesta explícita.
- «No aplica» sin justificación. Cada exclusión necesita un razonamiento escrito en el expediente.
- Método sin documentar. Valoraciones sin escalas, fórmulas sin definiciones.
- A nivel corporativo en vez de a nivel de producto. Un registro de riesgos del SGSI cubre tu organización. El CRA quiere este producto.
- Congelada en el lanzamiento. Sin historial de revisiones, sin disparadores de actualización, sin conexión con la supervisión de vulnerabilidades.
- Incoherente con el período de soporte. Supuestos de uso esperado que contradicen la ventana de soporte declarada.
- Sin responsable identificado. Nadie la aprobó, nadie acepta el riesgo residual, nadie es dueño de las actualizaciones.
Preguntas frecuentes
¿Es obligatoria la evaluación de riesgos de ciberseguridad para todo producto?
Sí, para todo producto dentro del ámbito del CRA, con independencia del tamaño de la empresa o la categoría del producto. Los niveles de clasificación cambian la ruta de conformidad, no el deber de evaluar. Incluso el producto más ligero dentro del ámbito necesita la evaluación documentada y las decisiones de aplicabilidad. Los productos que el CRA excluye, como los dispositivos médicos cubiertos y los equipos de aviación certificados, siguen en su lugar sus propias normas sectoriales.
¿Necesitan los administradores de código abierto esta evaluación de riesgos?
No. El deber de evaluación recae en los fabricantes. Un administrador que cumple los requisitos del CRA sigue un régimen más ligero con sus propios deberes. En el momento en que comercializas el producto como tuyo, eres el fabricante y se aplica el deber de evaluación completo. La guía de roles muestra en qué lado estás.
¿Existe una plantilla o metodología obligatoria?
No. El CRA exige una evaluación documentada con un contenido mínimo específico, y te deja el método a ti. Cualquier enfoque repetible funciona si produce las decisiones de aplicabilidad que pide el CRA. El esqueleto de esta guía cubre ese contenido exigido y añade los controles documentales recomendados.
Ya hacemos evaluaciones de riesgos ISO 27001. ¿Cuenta como evaluación CRA?
No por sí sola. Las evaluaciones ISO 27001 cubren la seguridad de la información de tu organización. La evaluación del CRA cubre un producto, su arquitectura y sus usuarios, y debe responder a la pregunta de aplicabilidad por cada requisito. Puedes reutilizar el método y las escalas. No puedes reutilizar el alcance.
¿Puede la evaluación formar parte de otra evaluación de riesgos que ya debamos por otra norma de la UE?
Solo en un caso acotado. Los productos que el CRA trata como sistemas de IA de alto riesgo, y que además están sujetos a otras normas de la UE que exigen una evaluación de riesgos, pueden integrar la evaluación de ciberseguridad en esa otra evaluación. Para todo lo demás, se mantiene independiente. En cualquier caso, los requisitos de contenido siguen siendo los mismos y el documento debe seguir mostrando el análisis de ciberseguridad y las decisiones de aplicabilidad.
¿Con qué frecuencia hay que actualizarla?
No hay un intervalo fijo. El deber está impulsado por eventos: actualiza la evaluación cuando proceda durante el período de soporte, y siempre que aparezca información nueva relevante. En la práctica, los equipos la vinculan a su supervisión de vulnerabilidades, a las actualizaciones de componentes y a cada lanzamiento del producto, además de una revisión periódica de sanidad.
¿Qué ocurre si marcamos un requisito como no aplicable y una autoridad no está de acuerdo?
La calidad de tu justificación escrita decide la conversación. Una justificación factual ligada a las propiedades del producto le da a la autoridad algo que evaluar. Un «no aplica» sin más se lee como una laguna en el expediente técnico e invita a un hallazgo de incumplimiento. Si los hechos cambian, por ejemplo si una nueva función empieza a almacenar datos de usuario, la exclusión debe revisarse.