El Expediente Tecnico CRA: Qué Incluir en Cada sección (Desglose del Anexo VII)

El expediente tecnico es tu paquete de evidencia para el cumplimiento del CRA. Las autoridades de vigilancia del mercado lo solicitaran. Los Organismos Notificados lo examinaran. Sin un expediente tecnico 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 Tecnico?

El expediente tecnico (tambien llamado "Documentación tecnica") es el paquete completo de evidencia Qué demuestra Qué 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 tecnica 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 tecnica:

ESTRUCTURA DEL EXPEDIENTE TECNICO (Anexo VII)

1. DESCRIPCION GENERAL
   └── Identificacion 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. MANEJO DE VULNERABILIDADES
   └── Procesos de seguridad post-comercializacion

sección 1: Descripcion General

Proposito: Establecer Qué es el producto y para Qué sirve.

Contenido Requerido

LISTA DE Verificación DESCRIPCION GENERAL

Identificacion 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 unico del producto

Proposito Previsto:
[ ] Descripcion 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/Critico)
[ ] Justificacion de la Clasificación
[ ] Regulaciones de producto relacionadas (si las hay)

Informacion de Mercado:
[ ] Fecha de primera comercializacion en la UE
[ ] Estados miembros objetivo
[ ] Canales de distribucion

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 fabricacion.
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 automatizacion industrial
- Responsables de cumplimiento ambiental

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

NO PREVISTO PARA:
- Aplicaciones medicas o de seguridad vital
- Instalacion 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 aplicacion de infraestructura critica.

COMERCIALIZACION UE:
Primera comercializacion: 15 de marzo de 2027
Mercados objetivo: Todos los estados miembros de la UE
Distribucion: Ventas directas y distribuidores autorizados

sección 2: Diseno y Desarrollo

Proposito: Documentar Cómo se incorporo la seguridad en el diseno del producto.

Contenido Requerido

LISTA DE Verificación Documentación DE DISENO

Arquitectura:
[ ] Diagrama de arquitectura del sistema
[ ] Diagrama de interaccion de componentes
[ ] Diagrama de flujo de datos
[ ] Limites de confianza identificados

Diseno de Seguridad:
[ ] Descripcion de arquitectura de seguridad
[ ] Implementaciones criptograficas
[ ] Mecanismos de autenticacion
[ ] Modelo de autorizacion
[ ] Protocolos de comunicacion seguros
[ ] Medidas de proteccion de datos

Proceso de Desarrollo:
[ ] Descripcion del ciclo de vida de desarrollo seguro
[ ] Trazabilidad de requisitos de seguridad
[ ] Procedimientos de revision de codigo
[ ] Pruebas de seguridad en desarrollo
[ ] Gestion de Configuración

Gestion 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 Diseno"

VISION GENERAL DE ARQUITECTURA DE SEGURIDAD

1. LIMITES DE CONFIANZA
   ┌─────────────────────────────────────────┐
   │            Backend en la Nube            │
   │  (Autenticacion, Almacenamiento)         │
   └───────────────┬─────────────────────────┘
                   │ TLS 1.3
   ┌───────────────┴─────────────────────────┐
   │         Firmware del Dispositivo         │
   │  ┌─────────────────────────────────┐    │
   │  │    Capa de Aplicacion           │    │
   │  ├─────────────────────────────────┤    │
   │  │    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 autenticacion
   - Aprovisionamiento de certificados: Provisionado en fabrica, unico 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 instalacion
   - Proteccion contra retroceso via contador de version
   - Comprobaciones automaticas de actualizacion (configurable por usuario)

sección 3: Evaluación de Riesgos de Ciberseguridad

Proposito: 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
[ ] Identificacion de activos
[ ] Enfoque de identificacion 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), Critico (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 comunicacion 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

Proposito: Demostrar Cómo se cumple cada requisito del Anexo I.

Requisitos del Anexo I, Parte I

Mapea cada requisito a tu implementacion:

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 autenticacion
   - Implementacion de control de acceso
   - Diseno de gestion de sesiones
   - Mecanismo de bloqueo por intentos fallidos
   Referencia: Arquitectura de Seguridad SA-001, Capitulo 4

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

sección 5: Estandares Aplicados

Proposito: Documentar Qué estandares 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 publicacion en Diario Oficial (si armonizado)

Evidencia de Aplicacion:
[ ] Cómo se aplico cada estandar
[ ] Qué clausulas/secciones aplican
[ ] Cualquier desviacion o aplicacion parcial

Manejo 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

Proposito: 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
[ ] Informacion del proveedor incluida
[ ] Informacion 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 codigo no alcanzable
  Fecha de Revision: 2027-04-15
─────────────────────────────────────────────────────────────

sección 7: Resultados de Pruebas

Proposito: Proporcionar evidencia de Qué 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
[ ] Descripcion del entorno de pruebas
[ ] Criterios de paso/fallo

Ejecucion de Pruebas:
[ ] Registros de ejecucion de pruebas
[ ] Resumen de resultados de pruebas
[ ] Pruebas fallidas y resolucion
[ ] 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

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

El expediente tecnico 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 tecnico)

Referencia: DoC-SSP3000-2027-001
Fecha: 1 de marzo de 2027
Ubicacion: Expediente Tecnico, 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 Manejo de Vulnerabilidades

Proposito: Documentar los procesos de seguridad post-comercializacion.

Contenido Requerido

LISTA DE Verificación MANEJO DE VULNERABILIDADES

Recepcion:
[ ] Metodos de contacto documentados (email, formulario web, security.txt)
[ ] Política CVD publicada
[ ] Procedimientos de comunicacion 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

Comunicacion:
[ ] Procedimientos de Notificación a clientes
[ ] Proceso de publicacion de avisos
[ ] Integración de informes a ENISA (para explotacion activa)

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

Mantenimiento del Expediente Tecnico

Documentación Viva

El expediente tecnico no es estatico:

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
- Actualizacion 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 tecnico
- Antes del fin del periodo 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 Retencion

RETENCION DE Documentación

Periodo de Retencion: 10 años desde la ultima unidad comercializada

Ejemplo de Cronograma:
- Producto comercializado por primera vez: Marzo 2027
- Ultima unidad comercializada: Diciembre 2030
- Retencion de Documentación hasta: Diciembre 2040

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

Errores Comunes

Evaluación de Riesgos Incompleta

Problema: Evaluación de riesgos Qué no cubre todas las amenazas o carece de detalles de tratamiento.

Solucion: Usa metodologia estructurada. Mapea cada riesgo identificado a un control o Decisión de aceptacion.

SBOM Faltante

Problema: Sin SBOM o SBOM Qué no incluye dependencias transitivas.

Solucion: Genera SBOM usando herramientas adecuadas. Incluye arbol completo de dependencias.

Documentación Desactualizada

Problema: Expediente tecnico describe version 1.0 pero el producto esta en version 2.3.

Solucion: Actualiza Documentación con cada lanzamiento. Rastrea versiones explicitamente.

Sin Trazabilidad de Requisitos

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

Solucion: Crea mapeo explicito de cada requisito del Anexo I a evidencia.

Pruebas Sin Evidencia

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

Solucion: Conserva todos los informes de pruebas. Incluye en expediente tecnico o referencia claramente.

Lista de Verificación del Expediente Tecnico

LISTA DE Verificación DE COMPLETITUD DEL EXPEDIENTE TECNICO

sección 1 - DESCRIPCION GENERAL:
[ ] Identificacion del producto completa
[ ] Proposito previsto documentado
[ ] Clasificación CRA indicada con justificacion
[ ] Informacion de comercializacion

sección 2 - DISENO:
[ ] Diagramas de arquitectura
[ ] Documentación de diseno de seguridad
[ ] Descripcion del proceso de desarrollo
[ ] Procedimientos de gestion 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 aplicacion 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 - MANEJO DE VULNERABILIDADES:
[ ] Metodos de contacto documentados
[ ] Proceso documentado
[ ] Procedimientos ENISA implementados

MANTENIMIENTO:
[ ] Control de versiones establecido
[ ] Procedimientos de actualizacion documentados
[ ] Plan de retencion implementado

Cómo Ayuda CRA Evidence

CRA Evidence agiliza la creacion del expediente tecnico:

• Plantillas estructuradas: Constructor de expediente tecnico sección por sección
• Mapeo de requisitos: Rastrea evidencia de cumplimiento del Anexo I
• Gestion de SBOM: Almacena, analiza y actualiza SBOMs
• Repositorio de documentos: Almacenamiento centralizado para toda la evidencia
• Seguimiento de versiones: Mantiene Documentación entre versiones del producto
• Capacidad de exportacion: Genera paquetes completos del expediente tecnico

Construye tu expediente tecnico en app.craevidence.com.

Guias Relacionadas

SBOM: Profundiza en los requisitos de SBOM en nuestra guia de SBOM.

Evaluación: Elige tu ruta de Evaluación de conformidad con nuestra guia de decisión de modulos.

Declaración: Aprende a preparar tu Declaración de Conformidad UE.

Este articulo es solo para fines informativos y no constituye asesoramiento legal. Para orientacion especifica sobre cumplimiento, consulta con asesores legales cualificados.