El expediente técnico CRA: qué incluir en cada sección (desglose del Anexo VII)

El expediente técnico es tu paquete de evidencia para el cumplimiento del CRA. Las autoridades de vigilancia del mercado lo solicitarán. Los Organismos Notificados lo examinarán. Sin un expediente técnico completo, no puedes comercializar legalmente tu producto en el mercado de la UE.

Esta guía desglosa el Anexo VII sección por sección, explicando qué requiere cada una y cómo prepararla.

¿Qué es el expediente técnico?

El expediente técnico (también llamado "Documentación técnica") es el paquete completo de evidencia que demuestra que tu producto cumple los requisitos del CRA.

No es:

• documentación de marketing
• Solo manuales de usuario
• Un ejercicio de casillas de verificación

Es:

• Evidencia técnica comprehensiva
• documentación viva (actualizada durante la vida del producto)
• Tu defensa en investigaciones de vigilancia del mercado
• Requerido para la evaluación de conformidad

Estructura del Anexo VII

El Anexo VII del CRA especifica los requisitos de documentación técnica:

ESTRUCTURA DEL EXPEDIENTE TECNICO (Anexo VII)

1. DESCRIPCION GENERAL
   └── Identificación del producto y proposito previsto

2. DISENO Y DESARROLLO
   └── cómo se incorporo la seguridad

3. evaluación DE RIESGOS DE CIBERSEGURIDAD
   └── Riesgos identificados y abordados

4. REQUISITOS ESENCIALES
   └── cómo se cumplen los requisitos del Anexo I

5. ESTANDARES APLICADOS
   └── Estandares usados y desviaciones

6. LISTA DE MATERIALES DE SOFTWARE
   └── Componentes y dependencias

7. RESULTADOS DE PRUEBAS
   └── Evidencia de Verificación

8. Declaración DE CONFORMIDAD UE
   └── O copia de la misma

9. GESTIÓN DE VULNERABILIDADES
   └── Procesos de seguridad post-comercialización

Sección 1: descripción general

Propósito: establecer qué es el producto y para qué sirve.

Contenido requerido

LISTA DE verificación DESCRIPCION GENERAL

Identificación del Producto:
[ ] Nombre y número de modelo del producto
[ ] Version(es) de hardware
[ ] Version(es) de software/firmware
[ ] Formato o rango de número de serie
[ ] Identificador único del producto

Proposito Previsto:
[ ] Descripción de la función principal
[ ] Usuarios/entorno objetivo
[ ] Casos de uso previstos
[ ] Usos no previstos (exclusiones)

Categoria del Producto:
[ ] Clasificación CRA (Por Defecto/Importante/Crítico)
[ ] Justificacion de la Clasificación
[ ] Regulaciones de producto relacionadas (si las hay)

Información de Mercado:
[ ] Fecha de primera comercialización en la UE
[ ] Estados miembros objetivo
[ ] Canales de distribución

Ejemplo

DESCRIPCION GENERAL

Nombre del Producto: SmartSense Pro Sensor Industrial
número de Modelo: SSP-3000
Version de Hardware: Rev C (PCB v3.2)
Version de Firmware: 2.4.1

PROPOSITO PREVISTO:
El SmartSense Pro es un sensor ambiental industrial
disenado para monitorizacion de instalaciones de fabricación.
Mide temperatura, humedad y calidad del aire, transmitiendo
datos via WiFi a servidores en la nube o locales.

USUARIOS OBJETIVO:
- Gestores de instalaciones
- Integradores de automatización industrial
- Responsables de cumplimiento ambiental

ENTORNO PREVISTO:
- Instalaciones industriales interiores
- Temperatura de operación: -10°C a +60°C
- Red: WiFi 802.11 b/g/n

NO PREVISTO PARA:
- Aplicaciones medicas o de seguridad vital
- Instalación exterior
- Atmosferas explosivas
- Uso domestico/residencial

Clasificación CRA:
Producto por defecto. No listado en Anexo III o IV.
Justificacion: Sensor de proposito general sin funciones
de seguridad o aplicación de infraestructura crítica.

COMERCIALIZACION UE:
Primera comercialización: 15 de marzo de 2027
Mercados objetivo: Todos los estados miembros de la UE
Distribución: Ventas directas y distribuidores autorizados

Sección 2: diseño y desarrollo

Propósito: Documentar cómo se incorporó la seguridad en el diseño del producto.

Contenido requerido

LISTA DE verificación documentación DE DISENO

Arquitectura:
[ ] Diagrama de arquitectura del sistema
[ ] Diagrama de interacción de componentes
[ ] Diagrama de flujo de datos
[ ] Limites de confianza identificados

Diseno de Seguridad:
[ ] Descripción de arquitectura de seguridad
[ ] Implementaciones criptograficas
[ ] Mecanismos de autenticación
[ ] Modelo de autorización
[ ] Protocolos de comunicación seguros
[ ] Medidas de protección de datos

Proceso de Desarrollo:
[ ] Descripción del ciclo de vida de desarrollo seguro
[ ] Trazabilidad de requisitos de seguridad
[ ] Procedimientos de revision de código
[ ] Pruebas de seguridad en desarrollo
[ ] Gestión de Configuración

Gestión de Cambios:
[ ] Procedimientos de control de versiones
[ ] evaluación de impacto de cambios
[ ] Revision de seguridad para cambios

Cómo luce la documentación de "seguridad por diseño"

VISION GENERAL DE ARQUITECTURA DE SEGURIDAD

1. LIMITES DE CONFIANZA
   ┌─────────────────────────────────────────┐
   │            Backend en la Nube            │
   │  (Autenticacion, Almacenamiento)         │
   └───────────────┬─────────────────────────┘
                   │ TLS 1.3
   ┌───────────────┴─────────────────────────┐
   │         Firmware del Dispositivo         │
   │  ┌─────────────────────────────────┐    │
   │  │    Capa de Aplicación           │    │
   │  ├─────────────────────────────────┤    │
   │  │    Servicios de Seguridad       │    │
   │  │  (Crypto, Auth, Arranque Seguro)│    │
   │  ├─────────────────────────────────┤    │
   │  │    Seguridad de Hardware        │    │
   │  │  (Elemento Seguro, RNG)         │    │
   │  └─────────────────────────────────┘    │
   └─────────────────────────────────────────┘

2. AUTENTICACION
   - Dispositivo a nube: TLS mutuo con certificados de dispositivo
   - Usuario a dispositivo: API local requiere token de autenticación
   - Aprovisionamiento de certificados: Provisionado en fabrica, único por dispositivo

3. PROTECCION DE DATOS
   - Datos en reposo: Cifrado AES-256-GCM
   - Datos en transito: TLS 1.3 con anclaje de certificado
   - Datos sensibles: Almacenados en elemento seguro

4. MECANISMO DE ACTUALIZACION
   - Actualizaciones de firmware firmadas (ECDSA P-256)
   - verificación de firma antes de instalación
   - Protección contra retroceso via contador de version
   - Comprobaciones automaticas de actualización (configurable por usuario)

Sección 3: evaluación de riesgos de ciberseguridad

Propósito: Documentar los riesgos identificados y cómo se abordan.

Contenido requerido

LISTA DE verificación evaluación DE RIESGOS

Metodologia:
[ ] Metodologia de evaluación de riesgos descrita
[ ] Definicion del alcance
[ ] Identificación de activos
[ ] Enfoque de identificación de amenazas

Analisis de Riesgos:
[ ] Amenazas enumeradas
[ ] Vulnerabilidades consideradas
[ ] evaluación de impacto
[ ] evaluación de probabilidad
[ ] Calificaciones de riesgo

Tratamiento de Riesgos:
[ ] Decisiones de tratamiento para cada riesgo
[ ] Controles de seguridad mapeados a riesgos
[ ] evaluación de riesgo residual
[ ] Criterios de aceptacion de riesgo

Formato de evaluación de riesgos

Evaluación DE RIESGOS DE CIBERSEGURIDAD

Producto: SmartSense Pro (SSP-3000)
Version: 2.4.1
Fecha de Evaluación: Enero 2027
Evaluador: [Nombre, Equipo de Seguridad]

METODOLOGIA:
Basada en ISO 27005 adaptada para seguridad de producto.
Riesgo = Probabilidad × Impacto
Escala: Bajo (1-4), Medio (5-9), Alto (10-16), Crítico (17-25)

─────────────────────────────────────────────────────────────
ID RIESGO: R-001
AMENAZA: Modificacion no autorizada del firmware
VULNERABILIDAD: Firmware sin firmar podria instalarse
IMPACTO: Alto (5) - Compromiso del dispositivo, brecha de datos
PROBABILIDAD: Media (3) - Requiere acceso fisico
RIESGO INHERENTE: 15 (Alto)

CONTROL: verificación de firma del firmware
IMPLEMENTACION: Firma ECDSA P-256 verificada antes de instalar
RIESGO RESIDUAL: 3 (Bajo) - Ataque criptografico improbable

ESTADO: Mitigado
─────────────────────────────────────────────────────────────
ID RIESGO: R-002
AMENAZA: Ataque man-in-the-middle en comunicación con la nube
VULNERABILIDAD: Interceptacion de trafico de red
IMPACTO: Alto (4) - Exposicion de datos, inyeccion de comandos
PROBABILIDAD: Media (3) - Redes publicas posibles
RIESGO INHERENTE: 12 (Alto)

CONTROL: TLS 1.3 con anclaje de certificado
IMPLEMENTACION: Certificado CA codificado, sin respaldo
RIESGO RESIDUAL: 2 (Bajo) - Compromiso de certificado improbable

ESTADO: Mitigado
─────────────────────────────────────────────────────────────
[Continuar para todos los riesgos identificados...]

RESUMEN DE RIESGOS:
Total riesgos identificados: 23
Criticos: 0
Altos: 3 (todos mitigados a Bajo/Medio)
Medios: 8 (todos mitigados a Bajo)
Bajos: 12 (aceptados o mitigados)

ACEPTACION DE RIESGO RESIDUAL:
Todos los riesgos residuales estan dentro de la tolerancia aceptable.
Firmado: [Responsable de Seguridad], [Fecha]

Sección 4: mapeo de requisitos esenciales

Propósito: Demostrar cómo se cumple cada requisito del Anexo I.

Requisitos del Anexo I, parte I

Mapea cada requisito a tu implementación:

MATRIZ DE CUMPLIMIENTO DE REQUISITOS ESENCIALES

ANEXO I, PARTE I - REQUISITOS DE SEGURIDAD
═══════════════════════════════════════════════════════════

1. DISENADO SIN VULNERABILIDADES EXPLOTABLES CONOCIDAS
   Estado: CONFORME
   Evidencia:
   - Informe de escaneo de vulnerabilidades (Trivy): 0 criticas/altas
   - Analisis de dependencias: Todos los componentes en versiones seguras
   - Informe de pruebas de penetracion: Sin vulnerabilidades explotables
   Referencia: Informe de Pruebas TR-2027-001, paginas 15-23

2. configuración SEGURA POR DEFECTO
   Estado: CONFORME
   Evidencia:
   - Documento de revision de configuración por defecto
   - Sin contrasenas por defecto (credenciales unicas requeridas en Configuración)
   - Servicios innecesarios deshabilitados por defecto
   - Protocolos seguros habilitados por defecto (TLS, no HTTP)
   Referencia: Documento de Diseno DD-004, sección 3.2

3. PROTECCION CONTRA ACCESO NO AUTORIZADO
   Estado: CONFORME
   Evidencia:
   - Documento de arquitectura de autenticación
   - implementación de control de acceso
   - Diseno de gestión de sesiones
   - Mecanismo de bloqueo por intentos fallidos
   Referencia: Arquitectura de Seguridad SA-001, Capítulo 4

[Continuar para todos los requisitos del Anexo I...]

Sección 5: estándares aplicados

Propósito: Documentar qué estándares se usaron y cómo.

Contenido requerido

LISTA DE verificación APLICACION DE ESTANDARES

Lista de Estandares:
[ ] Todos los estandares aplicados listados con numeros de version
[ ] Estandares armonizados identificados por separado
[ ] Referencia a publicación en Diario Oficial (si armonizado)

Evidencia de Aplicación:
[ ] cómo se aplico cada estandar
[ ] qué clausulas/secciones aplican
[ ] Cualquier desviacion o aplicación parcial

Gestión de desviaciones:
[ ] Desviaciones documentadas con justificacion
[ ] Medidas alternativas para requisitos desviados
[ ] evaluación de riesgos para desviaciones

Sección 6: lista de materiales de software

Propósito: Proporcionar transparencia de componentes para seguimiento de vulnerabilidades.

Contenido requerido

LISTA DE verificación REQUISITOS SBOM

Formato:
[ ] Formato legible por maquina (CycloneDX o SPDX)
[ ] Resumen legible por humanos

Contenido:
[ ] Todos los componentes de software listados
[ ] Versiones de componentes especificadas
[ ] información del proveedor incluida
[ ] información de licencia incluida
[ ] Vulnerabilidades conocidas en el momento de la Evaluación

Alcance:
[ ] Dependencias directas
[ ] Dependencias transitivas
[ ] Componentes del sistema operativo (si aplica)
[ ] Bibliotecas de terceros

Documentación del SBOM

LISTA DE MATERIALES DE SOFTWARE

Producto: SmartSense Pro (SSP-3000)
Version de Firmware: 2.4.1
Formato SBOM: CycloneDX 1.5
Generado: 2027-01-15
Herramienta: Trivy + syft

ARCHIVO SBOM:
sbom-ssp3000-v2.4.1.json (adjunto)

RESUMEN DE COMPONENTES:
─────────────────────────────────────────────────────────────
Total Componentes: 127
  Dependencias Directas: 23
  Dependencias Transitivas: 104

Por Tipo:
  Bibliotecas: 98
  Frameworks: 12
  Sistema Operativo: 1 (FreeRTOS)
  Modulos de Firmware: 16

Por Licencia:
  MIT: 45
  Apache 2.0: 38
  BSD: 15
  LGPL: 8
  Propietario: 21 (componentes internos)
─────────────────────────────────────────────────────────────

ESTADO DE VULNERABILIDADES EN LA Evaluación:
─────────────────────────────────────────────────────────────
Fecha de Escaneo: 2027-01-15
Escaner: Trivy v0.48.0

Criticas: 0
Altas: 0
Medias: 2 (aceptadas - ver abajo)
Bajas: 5 (aceptadas)

VULNERABILIDADES ACEPTADAS:
CVE-2026-XXXXX (Media): Componente xyz v1.2.3
  Estado: No explotable en nuestra Configuración
  Justificacion: función no habilitada, ruta de código no alcanzable
  Fecha de Revision: 2027-04-15
─────────────────────────────────────────────────────────────

Sección 7: resultados de pruebas

Propósito: Proporcionar evidencia de que los requisitos realmente se cumplen.

Contenido requerido

LISTA DE verificación documentación DE PRUEBAS

Planificación de Pruebas:
[ ] Plan de pruebas con alcance y objetivos
[ ] Casos de prueba mapeados a requisitos
[ ] Descripción del entorno de pruebas
[ ] Criterios de paso/fallo

Ejecucion de Pruebas:
[ ] Registros de ejecucion de pruebas
[ ] Resumen de resultados de pruebas
[ ] Pruebas fallidas y resolución
[ ] Evidencia de re-pruebas

Tipos de Pruebas:
[ ] Pruebas funcionales de seguridad
[ ] Escaneo de vulnerabilidades
[ ] Pruebas de penetracion (si aplica)
[ ] Pruebas de fuzzing (si aplica)
[ ] Revision de Configuración

Sección 8: declaración de conformidad UE

Propósito: Incluir la Declaración formal o referencia a ella.

El expediente técnico debe incluir una copia de la Declaración de Conformidad UE o referencia a donde puede obtenerse.

Declaración DE CONFORMIDAD UE

(Ver documento DoC separado o incluir copia en expediente técnico)

Referencia: DoC-SSP3000-2027-001
Fecha: 1 de marzo de 2027
Ubicacion: Expediente Técnico, Apendice A

La Declaración de Conformidad UE acompana a cada producto
y esta disponible para descarga en:
https://company.com/support/ssp3000/doc

Sección 9: procedimientos de gestión de vulnerabilidades

Propósito: Documentar los procesos de seguridad post-comercialización.

Contenido requerido

LISTA DE verificación GESTIÓN DE VULNERABILIDADES

Recepcion:
[ ] Metodos de contacto documentados (email, formulario web, security.txt)
[ ] Política CVD publicada
[ ] Procedimientos de comunicación con investigadores

Proceso:
[ ] Procedimientos de triaje
[ ] Metodologia de evaluación de severidad
[ ] Rutas de escalacion
[ ] Flujo de trabajo de desarrollo de parches
[ ] Procedimientos de prueba para parches

Comunicación:
[ ] Procedimientos de Notificación a clientes
[ ] Proceso de publicación de avisos
[ ] Integración de informes a ENISA (para explotación activa)

Monitorizacion:
[ ] Monitorizacion de vulnerabilidades en dependencias
[ ] Monitorizacion de bases de datos CVE
[ ] Fuentes de inteligencia de amenazas

¿Cuándo hay que actualizar el expediente técnico?

Documentación viva

El expediente técnico no es estático:

DISPARADORES DE ACTUALIZACION DEL EXPEDIENTE TECNICO

ACTUALIZACIONES OBLIGATORIAS:
- Nueva version de firmware/software
- Lanzamiento de parche de seguridad
- Vulnerabilidad descubierta y abordada
- Cambio de diseno qué afecta la seguridad
- Actualización de estandares (si cambian los estandares aplicados)
- Cambios en SBOM (componentes nuevos/actualizados)

REVISIONES PERIODICAS:
- Trimestral: SBOM y estado de vulnerabilidades
- Anual: Revision completa del expediente técnico
- Antes del fin del período de soporte: Congelacion final de Documentación

CONTROL DE VERSIONES:
- Todos los documentos con control de versiones
- Historial de cambios mantenido
- Versiones anteriores archivadas

Requisitos de retención

RETENCION DE Documentación

Periodo de Retención: 10 años desde la última unidad comercializada

Ejemplo de Cronograma:
- Producto comercializado por primera vez: Marzo 2027
- Última unidad comercializada: Diciembre 2030
- Retención de documentación hasta: Diciembre 2040

Requisitos de Almacenamiento:
- Almacenamiento seguro y accesible
- Procedimientos de respaldo
- Protección de integridad
- Disponible dentro de [48 horas] de solicitud de autoridad

Errores comunes

Evaluación de riesgos incompleta

Problema: evaluación de riesgos que no cubre todas las amenazas o carece de detalles de tratamiento.

Solución: Usa metodología estructurada. Mapea cada riesgo identificado a un control o decisión de aceptación.

SBOM faltante

Problema: Sin SBOM o SBOM que no incluye dependencias transitivas.

Solución: Genera SBOM usando herramientas adecuadas. Incluye árbol completo de dependencias.

Documentación desactualizada

Problema: Expediente técnico describe versión 1.0 pero el producto está en versión 2.3.

Solución: Actualiza documentación con cada lanzamiento. Rastrea versiones explícitamente.

Sin trazabilidad de requisitos

Problema: Reclama cumplimiento pero no muestra cómo se cumple cada requisito.

Solución: Crea mapeo explícito de cada requisito del Anexo I a evidencia.

Pruebas sin evidencia

Problema: Reclama que se hicieron pruebas pero no hay informes disponibles.

Solución: Conserva todos los informes de pruebas. Incluye en expediente técnico o referencia claramente.

Lista de verificación del expediente técnico

LISTA DE verificación DE COMPLETITUD DEL EXPEDIENTE TECNICO

sección 1 - DESCRIPCION GENERAL:
[ ] Identificación del producto completa
[ ] Proposito previsto documentado
[ ] Clasificación CRA indicada con justificacion
[ ] información de comercialización

sección 2 - DISENO:
[ ] Diagramas de arquitectura
[ ] documentación de diseno de seguridad
[ ] Descripción del proceso de desarrollo
[ ] Procedimientos de gestión de cambios

sección 3 - evaluación DE RIESGOS:
[ ] Metodologia documentada
[ ] Todos los riesgos identificados
[ ] Decisiones de tratamiento para cada riesgo
[ ] evaluación de riesgo residual

sección 4 - REQUISITOS ESENCIALES:
[ ] Mapeo del Anexo I Parte I completo
[ ] Mapeo del Anexo I Parte II completo
[ ] Evidencia referenciada para cada requisito

sección 5 - ESTANDARES:
[ ] Todos los estandares aplicados listados
[ ] Evidencia de aplicación proporcionada
[ ] Desviaciones documentadas y justificadas

sección 6 - SBOM:
[ ] SBOM legible por maquina adjunto
[ ] Todos los componentes incluidos
[ ] Estado de vulnerabilidades documentado

sección 7 - RESULTADOS DE PRUEBAS:
[ ] Plan de pruebas documentado
[ ] Informes de pruebas adjuntos
[ ] Todos los hallazgos abordados

sección 8 - DoC:
[ ] Declaración de Conformidad incluida/referenciada

sección 9 - GESTIÓN DE VULNERABILIDADES:
[ ] Metodos de contacto documentados
[ ] Proceso documentado
[ ] Procedimientos ENISA implementados

MANTENIMIENTO:
[ ] Control de versiones establecido
[ ] Procedimientos de actualización documentados
[ ] Plan de retención implementado

Próximos pasos

¿Gestionas la conformidad CRA para varios productos? CRA Evidence rastrea las evidencias de tu expediente técnico, las actualizaciones del SBOM y el mapeo de requisitos del Anexo I para cada versión de producto.

Una vez que tengas la evaluación de riesgos y los documentos de diseño, completa la Sección 6 con nuestra guía de requisitos SBOM. Consulta la guía de evaluación de conformidad para confirmar qué módulo aplica antes de finalizar tu Declaración de conformidad.

Este artículo es solo para fines informativos y no constituye asesoramiento legal. Para orientación específica sobre cumplimiento, consulta con asesores legales cualificados.