La Ley de ciberresiliencia (CRA) introduce un conjunto unificado de requisitos de ciberseguridad que se aplican a todos los productos con elementos digitales (PDE) comercializados en la UE. Una de las obligaciones más exigentes para los fabricantes, equipos de software y proveedores de IoT es la creación y el mantenimiento continuo de la documentación técnica.
Esta guía explica en detalle lo que la CRA exige en virtud del Anexo II (documentación técnica para la conformidad) y el Anexo VII (documentación posterior a la comercialización y registros de gestión de vulnerabilidades). La mayoría de las empresas subestiman la magnitud y la profundidad de esta obligación. Este documento cubre todo lo que debe preparar antes de 2027 para evitar disrupciones en el mercado, sanciones por incumplimiento y retiradas de productos.
Para obtener plantillas y listas de verificación, consulte nuestra Lista de verificación de preparación para la CRA.
1. ¿Qué es la documentación técnica de la CRA?
Según la Ley de Ciberresiliencia, la Documentación Técnica es el paquete completo de evidencia, controles de seguridad, procesos del ciclo de vida e información del producto requerido para demostrar la conformidad con los Requisitos Esenciales de Ciberseguridad del Anexo I. Debe:
- Crearse antes de colocar el producto en el mercado
- Mantenerse actualizado durante todo el ciclo de vida del producto
- Estar disponible para las autoridades cuando se solicite
- Incluir evidencia de diseño, implementación, pruebas y manejo de vulnerabilidades
- Ser suficiente para que las autoridades u organismos notificados evalúen la conformidad
No producir esta documentación puede impedir que un producto se venda en la UE, incluso si cumple con todos los requisitos técnicos.
2. Por qué es importante la Documentación Técnica de la CRA
La CRA está diseñada para eliminar la documentación de ciberseguridad inconsistente e insuficiente en toda la UE. Históricamente, los fabricantes presentaban evidencia desigual, carecían de registros del ciclo de vida de seguridad o mantenían procesos sin documentar. Según la CRA, la documentación desempeña tres funciones fundamentales:
- Demuestra el cumplimiento de los requisitos del Anexo I
- Permite auditorías e investigaciones por parte de las autoridades de vigilancia del mercado
- Apoya la gestión de vulnerabilidades y la notificación de incidentes
Las autoridades consideran que la documentación es fundamental para garantizar la ciberseguridad. Una documentación inadecuada puede constituir en sí misma una infracción.
3. ¿Qué documentación se exige según el Anexo II?
Anexo II define la Documentación Técnica básica para la evaluación de la conformidad. Los fabricantes deben producir un conjunto completo de documentos que describan cómo el producto cumple con los Requisitos Esenciales de Ciberseguridad.
La documentación debe incluir:
3.1 Descripción del Producto y Uso Previsto
- Tipo de producto, modelo, versión
- Casos de uso previstos y entorno operativo
- Características de conectividad (cableada, inalámbrica, protocolos)
- Dependencias de servicios en la nube o sistemas externos
3.2 Arquitectura y Diseño del Sistema
- Arquitectura de software de alto nivel
- Desglose del módulo
- Arquitectura del firmware
- Diagramas de arquitectura de red
- Diagramas de flujo de datos (DFD)
- Componentes de terceros y bibliotecas de código abierto
3.3 Controles de Seguridad y Mapeo de Requisitos del Anexo I
Los fabricantes deben demostrar cómo se cumple cada requisito de ciberseguridad en el Anexo I, incluyendo:
- Mecanismos de integridad y arranque seguros
- Controles de autenticación y autorización
- Protección contra inyección, corrupción de memoria y explotación
- Medidas de seguridad de red
- Seguridad de los mecanismos de actualización
- Funciones criptográficas
- Almacenamiento seguro de datos sensibles
Se recomienda una matriz de requisitos completa: Ver Mapeo de Requisitos de CRA.
3.4 Documentación de gestión de actualizaciones y parches
- Arquitectura de actualización de software
- Mecanismos de actualización de firmware
- Validación segura de actualizaciones (firma, autenticidad, prevención de reversión)
- Política de soporte del ciclo de vida (durante cuánto tiempo se garantizan las actualizaciones)
3.5 Documentación de manejo de vulnerabilidades
- Proceso interno de admisión de vulnerabilidades
- Métodos de evaluación y priorización
- Flujos de trabajo y cronogramas de remediación
- Informe de incidentes a las autoridades (dentro de los plazos obligatorios)
3.6 Evidencia de prueba y validación
Los fabricantes deben proporcionar prueba de pruebas de seguridad:
- Resúmenes de pruebas de penetración
- Resultados de análisis de código estático y dinámico
- Resultados de fuzzing (si corresponde)
- Pruebas de terceros (si se utilizan)
3.7 SBOM (lista de materiales del software)
La SBOM es obligatoria para productos que contienen software. Debe incluir:
- Nombre del componente, versión, proveedor
- Vulnerabilidades conocidas
- Información de licencia
- Relaciones de dependencia
4. ¿Qué documentación se requiere según el Anexo VII?
El Anexo VII se centra en la supervisión posterior a la comercialización y la documentación de manejo de vulnerabilidades.
Esto cubre toda la evidencia que un fabricante acumula después de que el producto se coloca en el mercado, incluidas las actualizaciones de seguridad y los registros de informes de incidentes.
4.1 Plan de monitoreo posterior a la comercialización
- Estrategia de monitoreo de seguridad
- Fuentes de inteligencia de amenazas
- Herramientas de monitoreo automatizadas y procesos manuales
- Cómo se priorizan las alertas de seguridad
4.2 Base de datos/registro de vulnerabilidades
- Lista de vulnerabilidades descubiertas después del lanzamiento
- Fecha de descubrimiento, fecha de informe, fecha de remediación
- Evaluación de impacto
- Interacción con ENISA o CSIRT (si es necesario)
4.3 Documentación de informes de incidentes
Para vulnerabilidades explotadas o incidentes graves de ciberseguridad, los fabricantes deben mantener:
- Cronología del incidente
- Evidencia de explotación
- Acciones de mitigación realizadas
- Avisos enviados a las autoridades
- Notificaciones de usuario (si corresponde)
4.4 Historial de actualizaciones y parches
- Historial de versiones de firmware/software
- Parches de seguridad publicados
- Motivo de las actualizaciones
- Pasos de validación realizados
5. Lista de verificación de documentación técnica de la CRA
Esta lista de verificación resume el alcance completo:
- Descripción del producto y uso previsto
- Diagramas de arquitectura
- Documentos de diseño de seguridad
- Mapeo de requisitos del Anexo I
- Modelado de amenazas (recomendado)
- Plan de gestión de actualizaciones y parches
- Documentación del ciclo de vida del desarrollo seguro
- Procesos de manejo de vulnerabilidades
- Evidencia de pruebas de seguridad
- SBOM con mapeo de dependencia completo
- Informe de evaluación de riesgos
- Documentación de evaluación de conformidad
- Plan de monitoreo posterior a la comercialización (Anexo VII)
- Registros de informes de incidentes
- Historial de actualizaciones y registros de remediación
Descargue las plantillas completas aquí: Recursos de la Ley de Ciberresiliencia
6. ¿Quién debe producir documentación técnica?
Se requiere documentación técnica para todos los fabricantes de productos regulados por la CRA. Sin embargo, los importadores y distribuidores también tienen obligaciones:
6.1 Fabricantes
Deben crear y mantener la documentación completa.
6.2 Importadores
Debe verificar la existencia e integridad de la documentación antes de colocar el producto en el mercado de la UE.
6.3 Los distribuidores
deben asegurarse de que no exista ningún incumplimiento conocido y deben cooperar con las autoridades.
7. La diferencia entre la documentación de clase predeterminada y clase crítica
Ambas clases requieren documentación completa del Anexo II, pero los productos de clase crítica requieren un escrutinio adicional:
- Evaluación de conformidad más estricta
- Posible evaluación de terceros
- Evidencia más detallada para controles de seguridad
- Retención más prolongada de la documentación posterior a la comercialización
La clase crítica incluye:
- Productos de seguridad
- Enrutadores, puertas de enlace, infraestructura de conectividad
- Sistemas industriales que respaldan servicios esenciales
Para conocer las reglas de clasificación, consulte: Guía de aplicabilidad y clasificación de la CRA.
8. Cómo estructurar su documentación de la CRA (plantilla recomendada)
La siguiente estructura se utiliza comúnmente en la evaluación de la conformidad bajo otros marcos de la UE (por ejemplo, RED, MDR, Reglamento de maquinaria). Se adapta perfectamente a CRA:
Parte 1 — Descripción general del producto
Parte 2 — Documentación de ingeniería
Parte 3 — Mapeo de requisitos de ciberseguridad
Parte 4 — Ciclo de vida de desarrollo seguro
Parte 5 — Resumen de pruebas y validación
Parte 6 — Evidencia de evaluación de conformidad
Parte 7 — Plan de monitoreo posterior a la comercialización
Parte 8 — Anexos (SBOM, registros de pruebas, registros de vulnerabilidad)
9. Errores comunes que cometen las empresas al preparar la documentación
- Comenzar la documentación demasiado tarde
- No se corresponden explícitamente con los requisitos del Anexo I
- Sin SBOM o SBOM incompleto
- Falta de procedimientos de gestión de vulnerabilidades
- No hay evidencia de validación de actualización segura
- Pasar por alto los componentes de terceros y la seguridad de la cadena de suministro
- No existe una estrategia de seguimiento posterior a la comercialización
- No se registran los resultados de las pruebas de seguridad
Estas lagunas se encuentran entre las causas más comunes de hallazgos de incumplimiento.
10. ¿Debería automatizar la documentación técnica de la CRA?
La mayoría de los fabricantes tendrán dificultades para mantener la documentación manualmente. Las herramientas automatizadas de documentación de la CRA, como Regulus, solucionan tres problemas clave:
- Asignación correcta de los requisitos del Anexo I
- Mantener la documentación actualizada durante el ciclo de vida
- Vinculación de vulnerabilidades, actualizaciones y evidencia en un solo lugar
Pruebe una automatización inicial aquí: Comprobador de aplicabilidad de la CRA
11. Recursos externos
- Comisión Europea – Anuncio de la Agencia de Información Crediticia (CRA)
- ENISA – Agencia de Ciberseguridad de la UE
- Marco de desarrollo de software seguro del NIST
Conclusión
La Documentación Técnica es una de las obligaciones más importantes introducidas por la Ley de Ciberresiliencia (CRA). Requiere evidencia de seguridad continua, monitoreo del ciclo de vida, gestión de vulnerabilidades y un mapeo explícito de los requisitos de ciberseguridad.
Las empresas que comiencen a prepararse con anticipación estarán mejor posicionadas para el cumplimiento normativo, el acceso al mercado y la confiabilidad de sus productos en el período 2025-2027.
Explore las plantillas y listas de verificación aquí: Recursos de la Ley de Ciberresiliencia
