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.
Resumen ejecutivo
- El expediente técnico documenta cómo tu producto cumple los requisitos esenciales del CRA
- Debe prepararse antes de la comercialización y conservarse 10 años después
- Contiene: descripción del producto, evaluación de riesgos, documentación de diseño, SBOM, resultados de pruebas, evidencia de conformidad
- Las autoridades pueden solicitarlo en cualquier momento, expedientes incompletos significan incumplimiento
- Empieza temprano: construir un expediente técnico adecuado lleva meses, no semanas
¿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
Importante: El expediente técnico debe prepararse ANTES de la comercialización y conservarse durante 10 años después de la última unidad comercializada. Las autoridades pueden solicitarlo en cualquier momento.
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. DISEÑO, DESARROLLO, GESTIÓN DE VULNERABILIDADES Y PRODUCCIÓN
└── Seguridad incorporada, vulnerabilidades gestionadas, producción y supervisión validadas
3. evaluación DE RIESGOS DE CIBERSEGURIDAD
└── Riesgos identificados y abordados
4. INFORMACIÓN SOBRE EL PERIODO DE SOPORTE
└── Información utilizada para determinar el periodo de soporte (artículo 13, apartado 8)
5. ESTANDARES APLICADOS
└── Estandares usados y desviaciones
6. RESULTADOS DE PRUEBAS
└── Evidencia de Verificación
7. Declaración DE CONFORMIDAD UE
└── O copia de la misma
8. LISTA DE MATERIALES DE SOFTWARE
└── Componentes y dependencias (a solicitud justificada)
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
diseñado para monitorización 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, desarrollo y gestión de vulnerabilidades
Propósito: Documentar cómo se diseñó y desarrolló el producto, cómo se gestionan las vulnerabilidades tras el lanzamiento y cómo se validan los procesos de producción y supervisión. El Anexo VII §2 los trata como un bloque único: diseño y desarrollo en §2(a), procesos de gestión de vulnerabilidades en §2(b), procesos de producción y supervisión en §2(c).
Diseño y desarrollo: contenido obligatorio
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
Diseño 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 revisión 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
[ ] Revisión 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 automáticas de actualización (configurable por usuario)
Gestión de vulnerabilidades: contenido obligatorio
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
Producción y supervisión: contenido obligatorio
En el software no hay línea de fábrica. El Anexo VII, apartado 2(c), se corresponde con la cadena de compilación y publicación que produce los artefactos entregables, con la validación de que esos procesos funcionan como deben y con la supervisión posterior al despliegue que detecta regresiones y nuevas vulnerabilidades. Documenta cada parte para que un auditor pueda trazar una versión hasta una compilación verificada y reproducible.
LISTA DE VERIFICACIÓN DE PRODUCCIÓN Y SUPERVISIÓN
Cadena de compilación y publicación:
[ ] Fuente de verdad identificada (repositorio, protección de ramas)
[ ] Compilación reproducible documentada (versiones de toolchain fijadas)
[ ] Procedencia de la compilación capturada (nivel SLSA, atestaciones in-toto)
[ ] Claves de firma y gestión de claves documentadas
[ ] Integridad del artefacto de publicación (binarios firmados, SBOM en la publicación)
Validación de los procesos de producción:
[ ] Puertas de seguridad en CI documentadas (criterios de aprobación de SAST, DAST, SCA)
[ ] La suite de regresión cubre los requisitos etiquetados por el Anexo I
[ ] Flujo de aprobación de publicaciones documentado
[ ] Plan de reversión para publicaciones fallidas
[ ] Cadencia de auditoría de reproducibilidad
Supervisión posterior al despliegue:
[ ] Cadencia de monitorización de vulnerabilidades en dependencias (diaria/semanal)
[ ] Proceso de diferencia de SBOM en cada publicación
[ ] Integración con fuentes CVE (NVD, GHSA, avisos del proveedor)
[ ] Cruce con KEV para detectar explotación activa
[ ] Telemetría de eventos relevantes para la seguridad (actualizaciones fallidas, fallos de firma)
[ ] Disparadores de notificación al cliente documentados
Documentación de producción y supervisión
PROCESOS DE PRODUCCIÓN Y SUPERVISIÓN
Producto: Industrial Gateway IG-200
Plataforma de compilación: GitHub Actions sobre runners ubuntu-22.04
Procedencia: SLSA Nivel 3 (atestaciones in-toto firmadas)
Firma: Cosign + Sigstore, clave raíz offline respaldada por KMS
CADENA DE COMPILACIÓN:
1. Fuente: github.com/example/ig200-firmware (rama main protegida,
puerta de revisión 2-de-N, commits firmados obligatorios)
2. Compilación: cross-compile reproducible (rustc 1.78, Cargo.lock bloqueado)
3. SAST: cargo-audit + lints de seguridad de clippy (puerta: 0 hallazgos altos o superiores)
4. SCA: escaneo de Trivy contra el binario compilado (puerta: 0 CVE explotables conocidas)
5. Pruebas: suite de regresión (1247 tests) + suite de conformidad con el Anexo I (89 tests)
6. Firma: cosign sign-blob + attest --predicate slsa-provenance.json
7. Publicación: artefacto + SBOM (CycloneDX 1.5) + extracto de la DoC publicado
VALIDACIÓN DE LOS PROCESOS:
- Definición del pipeline revisada trimestralmente (Responsable de Seguridad + Release Manager)
- Suite de conformidad con el Anexo I revisada cuando cambian las normas o los riesgos
- Auditoría anual de reproducibilidad (recompilación independiente desde el código etiquetado)
- Modo de fallo: si falla cualquier puerta -> publicación bloqueada, incidente registrado
SUPERVISIÓN POSTERIOR AL DESPLIEGUE:
- Fuente CVE de dependencias: Trivy + Renovate, escaneo diario contra el SBOM actual
- Umbral: Crítica o Alta con coincidencia en KEV -> parche en 7 días
- Umbral: Media sin KEV -> parche en la siguiente publicación mensual
- Notificación al cliente: feed RSS firmado + correo electrónico para avisos
- Telemetría interna: eventos de actualización fallida, fallos de verificación de firma
- Cadencia de revisión: triaje semanal, revisión mensual de tendencias
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: información sobre el periodo de soporte
Propósito: Documentar el razonamiento detrás del periodo de soporte elegido, conforme al artículo 13, apartado 8. El periodo de soporte es el tiempo durante el cual el fabricante se compromete a proporcionar actualizaciones de seguridad. El Anexo VII, apartado 4, exige que el expediente técnico recoja la información que motivó esa decisión.
Contenido obligatorio
REGISTRO DE DECISIÓN DEL PERIODO DE SOPORTE
Periodo de soporte declarado: [fecha de inicio] a [fecha de fin]
Mínimo: 5 años desde la comercialización (o vida útil del producto, si es menor)
Datos considerados (artículo 13, apartado 8):
[ ] Duración prevista de uso del producto
[ ] Expectativas de usuarios y clientes
[ ] Naturaleza y finalidad prevista del producto
[ ] Derecho de la Unión aplicable (mínimos sectoriales)
[ ] Orientaciones publicadas por la Comisión
[ ] Expectativas razonables de consumidores y otros usuarios finales
Justificación documentada:
[ ] Vida útil de productos comparables en el mercado
[ ] Plazos de soporte de proveedores de componentes (OS, runtime, bibliotecas)
[ ] Contratos o SLA de clientes que impliquen ventanas de actualización
[ ] Calendarios de fin de vida del hardware (si aplica)
Cómo es una buena documentación
DETERMINACIÓN DEL PERIODO DE SOPORTE
Producto: Industrial Gateway IG-200
Comercialización: 2026-09-01
Periodo de soporte declarado: 2026-09-01 a 2034-09-01 (8 años)
Justificación:
1. Vida operativa prevista: 8-10 años (datos de despliegue en campo,
comparable con el predecesor IG-150 aún activo en 2024 a los 9 años).
2. Soporte de componentes: el kernel Linux LTS cubre 6 años; aplicamos
parches de seguridad por backport durante 2 años adicionales con
compromisos de proveedor.
3. Contratos de cliente: los 3 mayores clientes tienen acuerdos de servicio
de 7 años; el resto suele renovar en ciclos de 5 años.
4. Orientación sectorial: NIS2 cubre operadores de servicios esenciales que
utilizan esta pasarela; se asumen requisitos de actualización durante
toda la vida del activo.
5. Comunicación de fin de soporte: documentada en el manual de usuario y en
la política de EOL en https://example.com/security/eol.
Decisión aprobada por: [Product Owner], [Responsable de Seguridad], [Jurídico]
Fecha: 2026-08-15
Disparador de revisión: cualquier cambio relevante en los plazos de soporte de componentes
Errores comunes
- Anclarse al mínimo de 5 años sin justificación. Los 5 años del artículo 13, apartado 8, son un suelo, no un valor por defecto. Los productos con vida útil prevista más larga necesitan un periodo más largo.
- Olvidar que el suelo es "o la vida útil del producto, si es menor". Un dispositivo de consumo vendido durante 18 meses sigue teniendo obligación de soporte de actualizaciones durante el periodo en que razonablemente se espera que el producto esté en uso.
- No registrar los datos considerados. Las autoridades de vigilancia pueden preguntar cómo se determinó el periodo. "Elegimos 5 años" no es una respuesta.
- Tratarlo como inamovible. Si los plazos de soporte de componentes cambian (por ejemplo, el OS upstream alcanza el EOL antes de lo previsto), el registro de decisión debe actualizarse y el compromiso de soporte debe comunicarse.
Mapeo de requisitos esenciales (Anexo I)
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 revisión 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 Diseño 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
- Diseño 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
Consejo: Automatiza la generación de tu SBOM en CI/CD. La creación manual de SBOM es propensa a errores y no escala entre versiones de producto.
Sección 6: 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)
[ ] Revisión de Configuración
Sección 7: 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 8: lista de materiales de software
Propósito: Proporcionar transparencia de componentes para el seguimiento de vulnerabilidades. El Anexo VII, apartado 8, hace que la SBOM forme parte del expediente técnico a solicitud justificada de una autoridad de vigilancia del mercado. En la práctica, los fabricantes la preparan y mantienen junto con el resto del expediente.
Guías hermanas: Los productos de hardware requieren además un HBOM, y la calidad de la SBOM se rige por BSI TR-03183. El estado de vulnerabilidad de los componentes de la SBOM se comunica mediante VEX. Consulte la guía de requisitos de SBOM para CycloneDX frente a SPDX, los niveles de calidad de BSI TR-03183, el alcance del HBOM y el uso de VEX; y la guía de notificación de vulnerabilidades para ver cómo VEX respalda la obligación de "no tener vulnerabilidades explotables conocidas".
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)
Módulos 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 Revisión: 2027-04-15
─────────────────────────────────────────────────────────────
¿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 diseño 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: Revisión 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
Nota: "10 años desde la última unidad comercializada" significa que si vendes productos hasta 2030, la retención se extiende hasta 2040. Planifica tu almacenamiento de documentos en consecuencia.
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
Advertencia: Un expediente técnico que solo describe la versión 1.0 cuando tu producto está en la versión 2.3 se considera no conforme. Actualiza la documentación con cada lanzamiento.
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 - DISEÑO, DESARROLLO Y GESTIÓN DE VULNERABILIDADES:
[ ] Diagramas de arquitectura
[ ] documentación de diseño de seguridad
[ ] Descripción del proceso de desarrollo
[ ] Procedimientos de gestión de cambios
[ ] Métodos de contacto para vulnerabilidades documentados
[ ] Política de divulgación coordinada (CVD) publicada
[ ] Proceso de gestión de vulnerabilidades documentado
[ ] Procedimientos de notificación a ENISA implementados
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 - INFORMACIÓN DEL PERIODO DE SOPORTE:
[ ] Periodo de soporte declarado (fechas de inicio y fin)
[ ] Datos del artículo 13, apartado 8, documentados (duración de uso, expectativas, normativa sectorial)
[ ] Justificación registrada (soporte de componentes, contratos, EOL de hardware)
[ ] Aprobación de decisión registrada (producto, seguridad, jurídico)
MAPEO DEL ANEXO I (apoya las secciones 5-7):
[ ] 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 - RESULTADOS DE PRUEBAS:
[ ] Plan de pruebas documentado
[ ] Informes de pruebas adjuntos
[ ] Todos los hallazgos abordados
sección 7 - DoC:
[ ] Declaración de Conformidad incluida/referenciada
sección 8 - SBOM (a solicitud justificada):
[ ] SBOM legible por maquina preparada (CycloneDX o SPDX)
[ ] Todos los componentes incluidos (directos + transitivos)
[ ] Estado de vulnerabilidades documentado
[ ] Disponible a solicitud de la autoridad de vigilancia
MANTENIMIENTO:
[ ] Control de versiones establecido
[ ] Procedimientos de actualización documentados
[ ] Plan de retención implementado
Preguntas frecuentes
¿Qué documentos son obligatorios en el expediente técnico CRA según el Anexo VII?
El Anexo VII exige ocho secciones: (1) una descripción general del producto, que incluye la finalidad prevista, las versiones de software que afectan al cumplimiento, fotografías para los productos de hardware e información destinada al usuario; (2) una descripción del diseño, desarrollo y producción del producto junto con los procedimientos de gestión de vulnerabilidades; (3) una evaluación de riesgos de ciberseguridad conforme al artículo 13; (4) la información utilizada para determinar el periodo de soporte conforme al artículo 13, apartado 8; (5) la lista de las normas armonizadas aplicadas en todo o en parte; (6) los informes de las pruebas realizadas para verificar la conformidad; (7) una copia de la Declaración UE de Conformidad; y (8) cuando proceda, la Lista de Materiales de Software (SBOM), facilitada previa solicitud motivada de una autoridad de vigilancia del mercado.
¿Cada versión de firmware necesita su propio expediente técnico?
El expediente técnico debe reflejar la versión actual del producto. Cada lanzamiento de firmware que modifique el comportamiento relevante para la seguridad requiere documentación actualizada: como mínimo el SBOM, la evaluación de riesgos y los resultados de pruebas. No es necesario reconstruir el expediente desde cero, pero debe mantenerse preciso y específico para cada versión.
¿Cuánto tiempo debe conservarse el expediente técnico tras retirar el producto del mercado?
El CRA exige una conservación de 10 años desde la fecha en que se comercializa la última unidad. Si vendes unidades hasta 2030, toda la documentación debe mantenerse hasta 2040.
¿Hay que presentar el expediente técnico a las autoridades de forma proactiva?
No. El fabricante conserva el expediente técnico y lo pone a disposición cuando lo solicitan las autoridades de vigilancia del mercado. Las autoridades pueden reclamar el acceso en cualquier momento, pero no existe obligación de presentarlo en el momento de la comercialización.
¿Puede el expediente técnico referenciar documentos externos o todo debe estar en un único lugar?
Las referencias externas son aceptables siempre que los documentos sean accesibles y trazables. El expediente puede señalar informes de pruebas, documentos de diseño o certificados de estándares almacenados en otros lugares, siempre que las referencias sean precisas y los documentos estén disponibles cuando se soliciten.
¿Cuál es la diferencia entre el expediente técnico y la declaración de conformidad?
La Declaración de Conformidad es un documento público breve que indica que el producto cumple los requisitos del CRA. El expediente técnico es el paquete completo de evidencias que lo demuestra, con toda la documentación, los resultados de pruebas y las evaluaciones que respaldan esa declaración. La Declaración hace referencia al expediente técnico; el expediente es la base que la sustenta.