Documentación técnica CRA: qué preparar y cómo mantenerla

La documentación técnica CRA no es un documento puntual preparado para auditar. El artículo 31 exige elaborarla antes de poner en el mercado el producto con elementos digitales y actualizarla cuando corresponda, al menos durante el período de soporte.

Si hay que reconstruir arquitectura, decisiones y pruebas desde correos, solicitudes y memoria del equipo, el problema no es falta de plantilla. Es ausencia de un modelo mantenido de producto y evidencias.

Qué cubre el anexo VII

El contenido exacto depende del producto, pero el anexo VII identifica al menos estos grupos de información.

1. Descripción general del producto

Incluye la finalidad prevista, las versiones de software que afectan a la conformidad con los requisitos esenciales de ciberseguridad y la información e instrucciones suministradas a los usuarios.

2. Diseño, desarrollo, producción y gestión de vulnerabilidades

La documentación debe contener suficiente información para comprender diseño, arquitectura, relaciones entre componentes y procesos de gestión de vulnerabilidades del fabricante.

CRA menciona expresamente la SBOM, la política de divulgación coordinada de vulnerabilidades, las evidencias de una dirección de contacto para comunicar vulnerabilidades y las soluciones técnicas utilizadas para distribuir actualizaciones de forma segura.

3. Evaluación del riesgo de ciberseguridad

El registro debe mostrar frente a qué riesgos se diseña, desarrolla, produce, entrega y mantiene el producto y cómo se aplican requisitos del anexo I.

4. Fundamento del período de soporte

Hace falta más que fecha final. Debe conservarse la información utilizada por el fabricante para determinar el período.

5. Normas y soluciones técnicas utilizadas

Si se usan normas armonizadas, especificaciones comunes o esquemas de certificación de ciberseguridad pertinentes, se identifican y se indica qué partes se aplican. Si no se usan, el fabricante documenta soluciones adoptadas para cumplir requisitos aplicables.

6. Informes de pruebas

Evidencias de pruebas para verificar producto y procesos de vulnerabilidades frente a requisitos aplicables.

7. Declaración UE de conformidad

Una copia de la declaración del producto.

8. SBOM solicitada por autoridad de vigilancia del mercado

El anexo VII prevé facilitar la SBOM pertinente tras una solicitud motivada cuando sea necesaria para comprobar conformidad.

Usa un índice, no un PDF gigante

Un modelo práctico es un índice de documentación ligado a versión del producto.

Área	Artefacto de origen	Responsable	Versión / fecha	Evidencia de revisión
finalidad prevista	registro de producto	Responsable de producto	v3.4	aprobación
arquitectura	diagrama + descripción	Ingeniería	v3.4	revisión
evaluación del riesgo	registro de riesgos	Seguridad/Producto	v3.4	decisiones
SBOM	artefacto de compilación/versión	Ingeniería	versión 3.4.2	hash / registro
pruebas	informes	Calidad/Seguridad	versión 3.4.2	resultado
CVD	política	Seguridad	rev. 5	aprobación
período de soporte	registro de decisión	Producto/Dirección	2026-09	fundamento

Puede haber muchos artefactos. Importa identificar cuál se aplica a cada versión y quién confirmó que estaba vigente.

Cuatro patrones que crean costes innecesarios

«Tenemos una política, está cubierto»

Una política describe cómo se pretende trabajar. No prueba que se evaluó y ensayó una versión concreta.

«La arquitectura está en el repositorio; todos saben dónde»

Tras un cambio de equipo o dieciocho meses, «todos saben» deja de ser una fuente de evidencia útil.

«La SBOM se genera en el pipeline»

Bien, pero aún hay que vincularla con producto, versión y proceso de vulnerabilidades.

«Exportaremos todo antes de auditar»

Si hay registros inconsistentes, exportar solo revela más rápido la inconsistencia.

Cómo organiza Pulsar el rastro documental

Documentos, evidencias, riesgos, controles e informes conservan el contexto de evaluaciones. Permite documentación como registros vinculados, no solo una carpeta de archivos finales.

El registro debe responder:

a qué producto y versión pertenece el artefacto;
qué requisito o riesgo respalda;
quién lo creó y aprobó;
cuándo estaba vigente;
qué acción o decisión demuestra;
qué cambió desde la revisión anterior.

Pulsar no proporciona contenido protegido de normas ni sustituye documentación del fabricante. Ayuda a mantener estructura, responsabilidades y trazabilidad.

Consulta documentos y evidencias en Pulsar GRC

Orientaciones relacionadas

Método propuesto: un expediente por versión con índice y responsables

Imagina que un equipo publica una versión que modifica autenticación, añade una dependencia y cambia su canal de actualizaciones. La descripción general del producto apenas cambia, pero tres partes materiales de la documentación técnica necesitan revisión. Si el equipo actualiza solo un PDF principal, pueden quedar riesgos y pruebas describiendo el comportamiento anterior. Este escenario hipotético permite comprobar cómo se mantiene la coherencia entre artefactos.

Prepara un índice con identificador de producto y versión. Cada entrada señala el artefacto, su responsable, la fecha de revisión y el requisito o decisión que respalda. Una entrada puede apuntar a un documento, a un informe de ensayo o a un registro aprobado. La organización debe decidir qué referencias son suficientemente estables para conservar trazabilidad a lo largo del soporte.

No mezcles la versión del producto con la revisión de un documento. Un procedimiento de vulnerabilidades puede servir para varias versiones; un informe de ensayo suele corresponder a una ejecución concreta. Ambos deben poder vincularse al expediente sin aparentar que tienen el mismo ciclo de vida. Cuando el alcance sea parcial, exprésalo en la entrada.

Define qué hace aceptable cada evidencia

Para arquitectura, la revisión comprueba que el documento corresponde al producto y permite entender límites, componentes y relaciones relevantes. Para riesgo, comprueba que se explica el contexto, las decisiones y las medidas adoptadas. Para pruebas, exige identificar versión, entorno, escenario y resultado. Estos son criterios operativos propuestos; el contenido legal debe contrastarse con el CRA y el caso concreto.

Una evidencia no es válida solo porque tiene fecha reciente. Puede describir otra variante o cubrir una función distinta. Al adjuntarla, registra para qué se utiliza y quién verificó esa relación. Si el equipo reutiliza un ensayo anterior, explica por qué sigue aplicándose después del cambio. Esa explicación debe poder defenderse técnicamente.

Separa evidencias de actividades planificadas. «Ensayo programado para el próximo mes» no demuestra una protección. Un documento marcado como borrador no equivale a una política aprobada. Mantener los estados visibles permite identificar qué falta antes de publicar, sin convertir un índice completo en una falsa demostración de cumplimiento.

Gestiona referencias sin depender de enlaces frágiles

Un vínculo a una carpeta puede ser útil para encontrar material, pero no siempre identifica lo revisado. Decide cómo conservar versiones, identificadores o copias autorizadas pertinentes. Evita enlaces que apuntan exclusivamente a un archivo sobreescrito cada semana cuando necesitas reconstruir una entrega pasada. El método debe ajustarse a las herramientas de ingeniería y a obligaciones de conservación.

Revisa también permisos. Un índice aparentemente completo puede resultar inutilizable para quien debe evaluarlo si todos sus enlaces requieren acceso que nadie conserva. Utiliza una prueba con una persona autorizada que no creó el expediente. Debe localizar los artefactos sin que el autor tenga que enviarlos otra vez. Si falta acceso, resuelve el permiso adecuado; no abras toda la documentación a usuarios innecesarios.

Para material sensible, prepara una política de acceso y de comunicación externa. La revisión técnica puede necesitar detalles que no corresponden a una respuesta comercial. Conserva el original y distingue cualquier versión preparada para compartir. La eliminación de datos irrelevantes debe revisarse para no ocultar información requerida por una autoridad o por una obligación aplicable.

Revisión de consistencia tras una publicación

Utiliza el registro de cambios para identificar áreas afectadas. En el ejemplo, autenticación obliga a revisar riesgos y pruebas de acceso; la dependencia obliga a revisar inventario y vulnerabilidades; el canal de actualización afecta distribución y verificación. Asigna cada revisión a una persona y conserva el resultado. No hace falta repetir pruebas ajenas al cambio sin motivo, pero sí justificar la cobertura de lo que cambió.

Una reunión de cierre comprueba que el índice corresponde a la entrega real. Las cuestiones abiertas se registran con sus consecuencias. Si se autoriza una entrega, el alcance de la decisión identifica versión y condiciones pertinentes. La aprobación no debe aparecer después como una certificación de toda la empresa ni cubrir automáticamente publicaciones futuras.

Cuando un artefacto se actualiza por una corrección documental, señala si cambia el fundamento técnico. Corregir una errata no equivale a ejecutar un nuevo ensayo. Cambiar una conclusión de riesgo tampoco es una simple actualización editorial. Esta distinción ayuda a elegir el nivel de revisión y a mantener un historial comprensible.

Ejercicio de reconstrucción del expediente

Selecciona una versión anterior y pide a una persona autorizada explicar el recorrido de una medida de seguridad. Debe encontrar el riesgo que motivó la medida, el requisito relacionado, la decisión de diseño, la prueba y el resultado. Después, comprueba si la documentación de usuarios y el soporte corresponden a esa misma versión. El ejercicio detecta carencias que un control de campos vacíos no ve.

Clasifica los fallos observados. Un enlace roto es un problema de conservación. Un informe sin versión es un problema de identificación. Una prueba que no demuestra el control es un problema técnico. Una aprobación ausente es un problema de responsabilidad. Cada uno necesita una corrección propia; añadir un nuevo procedimiento general no los resuelve automáticamente.

Asistencia de IA con control de fuentes

La IA puede ayudar a preparar un índice o resumir documentos suministrados. La persona que revisa comprueba nombres, versiones, resultados y referencias. No permitas que complete ausencias inventando ensayos, cláusulas o conclusiones. Cuando no encuentra una fuente, el borrador debe señalar la carencia y proponer una acción para obtenerla.

Pulsar organiza documentos, riesgos, acciones y decisiones aportadas por la organización. Ingeniería conserva la ejecución de ensayos y generación de artefactos. El fabricante mantiene responsabilidad por documentación, interpretación y evaluación de conformidad. Un expediente útil permite demostrar qué se hizo y con qué resultado; una colección extensa de documentos sin relaciones solo desplaza la búsqueda a otra herramienta.

Comprueba también la estabilidad de los artefactos después de una corrección urgente. Imagina que ingeniería reemplaza un informe en una carpeta compartida manteniendo el mismo nombre. El índice puede seguir abriendo un archivo, pero ya no demuestra qué resultado apoyó la aprobación original. Conserva un identificador o una versión que permita distinguir ambos informes y explica si el cambio afecta a la conclusión técnica. La disponibilidad de un enlace no equivale a integridad del expediente histórico.

Para verificar ese control, selecciona una evidencia que haya cambiado y reconstruye dos momentos: antes y después de la modificación. La persona que revisa debe localizar qué versión se utilizó, quién aprobó cada conclusión y por qué fue necesario actualizarla. Si falta el original, registra la limitación y determina qué fuente autorizada permite aclarar el contexto. No reconstruyas retrospectivamente un resultado de ensayo a partir de una descripción actual. El ejercicio debe terminar con una decisión sobre conservación y responsabilidades, además de un índice que siga funcionando.

Fuentes

Fuentes comprobadas: 12 de septiembre de 2026.

Pulsar GRC — acceso, aislamiento de datos y exportación (polaco)