Documentación técnica CRA: guía

El expediente técnico es tu paquete de evidencia para el cumplimiento del Reglamento (UE) 2024/2847. Las autoridades de vigilancia del mercado pueden solicitarlo, y un organismo notificado lo examinará cuando tu ruta de conformidad utilice uno. Sin un expediente técnico completo, no puedes comercializar legalmente tu producto en el mercado de la UE.

Esta guía recorre el expediente técnico sección por sección, explicando qué necesita cada área de evidencia 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 esenciales de ciberseguridad.

No es:

• documentación de marketing
• solo manuales de usuario
• un ejercicio de marcar casillas

Es:

• evidencia técnica integral
• documentación viva (actualizada durante la vida del producto)
• tu defensa en investigaciones de vigilancia del mercado
• obligatorio para la evaluación de la conformidad

Qué debe contener el expediente técnico

El expediente técnico es más fácil de revisar cuando se organiza en ocho áreas de evidencia:

Sección 1: descripción general

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

Contenido obligatorio

Ejemplo

GENERAL DESCRIPTION

Product Name: SmartSense Pro Industrial Sensor
Model Number: SSP-3000
Hardware Version: Rev C (PCB v3.2)
Firmware Version: 2.4.1

INTENDED PURPOSE:
The SmartSense Pro is an industrial environmental sensor
designed for manufacturing facility monitoring. It measures
temperature, humidity, and air quality, transmitting data
via WiFi to cloud or local servers.

TARGET USERS:
- Facility managers
- Industrial automation integrators
- Environmental compliance officers

INTENDED ENVIRONMENT:
- Indoor industrial facilities
- Operating temperature: -10°C to +60°C
- Network: WiFi 802.11 b/g/n

NOT INTENDED FOR:
- Medical or life-safety applications
- Outdoor installation
- Explosive atmospheres
- Consumer/residential use

CRA CLASSIFICATION:
Default product. Not classified as important or critical.
Justification: General-purpose sensor without security
functions or critical infrastructure application.

EU MARKET PLACEMENT:
First placed on market: March 15, 2027
Target markets: All EU member states
Distribution: Direct sales and authorized distributors

Sección 2: diseño, desarrollo y gestión de vulnerabilidades

Propósito: documentar cómo se diseñó y construyó el producto, cómo se gestionan las vulnerabilidades tras el lanzamiento y cómo se validan los procesos de producción y supervisión. Trátalo como un único bloque de evidencia: registros de diseño y desarrollo, procesos de gestión de vulnerabilidades y controles de producción y supervisión que demuestren que las publicaciones se construyen y se vigilan de forma coherente.

Diseño y desarrollo: contenido obligatorio

Cómo se ve una documentación "Secure by Design"

SECURITY ARCHITECTURE OVERVIEW

1. TRUST BOUNDARIES
   +-----------------------------------------+
   |            Cloud Backend                 |
   |  (Authentication, Data Storage)          |
   \---------------+-------------------------+
                   | TLS 1.3
   +---------------+-------------------------+
   |         Device Firmware                  |
   |  +---------------------------------+    |
   |  |    Application Layer            |    |
   |  +---------------------------------+    |
   |  |    Security Services            |    |
   |  |  (Crypto, Auth, Secure Boot)    |    |
   |  +---------------------------------+    |
   |  |    Hardware Security            |    |
   |  |  (Secure Element, RNG)          |    |
   |  \---------------------------------+    |
   \-----------------------------------------+

2. AUTHENTICATION
   - Device-to-cloud: Mutual TLS with device certificates
   - User-to-device: Local API requires authentication token
   - Certificate provisioning: Factory-provisioned, unique per device

3. DATA PROTECTION
   - Data at rest: AES-256-GCM encryption
   - Data in transit: TLS 1.3 with certificate pinning
   - Sensitive data: Stored in secure element

4. UPDATE MECHANISM
   - Signed firmware updates (ECDSA P-256)
   - Signature verification before installation
   - Rollback protection via version counter
   - Automatic update checks (user-configurable)

Gestión de vulnerabilidades: contenido obligatorio

Documentación de la gestión de vulnerabilidades

VULNERABILITY HANDLING PROCEDURES

1. CONTACT METHODS
   Primary: security@company.com
   Web Form: https://company.com/security/report
   security.txt: https://company.com/.well-known/security.txt
   CVD Policy: https://company.com/security/disclosure-policy

2. RESPONSE COMMITMENTS
   Acknowledgment: Within 3 business days
   Initial Assessment: Within 10 business days
   Status Updates: Every 14 days
   Resolution Target: 90 days (critical: 7 days)

3. INTERNAL PROCESS
   [Flowchart or process description]
   See: Process Document PD-VULN-003

4. PATCH DISTRIBUTION
   Mechanism: OTA updates via cloud infrastructure
   Notification: In-app notification + email to registered users
   Verification: Signed updates with rollback capability

5. ENISA REPORTING
   Trigger: Active exploitation detected
   Timeline: 24h early warning, 72h detailed report
   Responsible: Security Team Lead
   Process: See PD-ENISA-001

6. HISTORICAL RECORD
   Vulnerabilities handled (past 24 months): 3
   Average resolution time: 45 days
   ENISA reports filed: 0

Producción y supervisión: contenido obligatorio

Para los productos de software no hay línea de fábrica. Producción y supervisión significa la canalización de compilación y publicación que produce los artefactos enviables, la validación de que esos procesos funcionan según lo previsto y la supervisión posterior al despliegue que detecta regresiones y nuevas vulnerabilidades. Documenta cada elemento para que un auditor pueda trazar una publicación hasta una compilación verificada y reproducible.

Documentación de producción y supervisión

PRODUCTION AND MONITORING PROCESSES

Product: Industrial Gateway IG-200
Build platform: GitHub Actions on ubuntu-22.04 runners
Provenance: SLSA Level 3 (signed in-toto attestations)
Signing: Cosign + Sigstore, offline KMS-backed root key

BUILD PIPELINE:
1. Source: github.com/example/ig200-firmware (main branch protected,
   2-of-N review gate, signed commits required)
2. Build: reproducible cross-compile (rustc 1.78, locked Cargo.lock)
3. SAST: cargo-audit + clippy security lints (gate: 0 high+ findings)
4. SCA: trivy scan against built binary (gate: 0 known-exploitable CVEs)
5. Test: regression suite (1247 tests) + essential requirements conformance suite (89 tests)
6. Sign: cosign sign-blob + attest --predicate slsa-provenance.json
7. Release: artifact + SBOM (CycloneDX 1.5) + DoC excerpt published

VALIDATION OF PROCESSES:
- Pipeline definition reviewed quarterly (Security Lead + Release Manager)
- Essential requirements conformance test suite reviewed when standards or risks change
- Annual reproducibility audit (independent rebuild from tagged source)
- Failure mode: any gate fails -> release blocked, incident logged

POST-DEPLOYMENT MONITORING:
- Dependency CVE feed: Trivy + Renovate, daily scan against current SBOM
- Threshold: Critical or High with KEV match -> patch within 7 days
- Threshold: Medium without KEV -> patch in next monthly release
- Customer notification: signed RSS feed + email for advisories
- Internal telemetry: failed update events, signature verification failures
- Review cadence: weekly triage, monthly trend review

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

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

Contenido obligatorio

Formato de evaluación de riesgos

CYBERSECURITY RISK ASSESSMENT

Product: SmartSense Pro (SSP-3000)
Version: 2.4.1
Assessment Date: January 2027
Assessor: [Name, Security Team]

METHODOLOGY:
Based on ISO 27005 adapted for product security.
Risk = Likelihood × Impact
Scale: Low (1-4), Medium (5-9), High (10-16), Critical (17-25)

-------------------------------------------------------------
RISK ID: R-001
THREAT: Unauthorized firmware modification
VULNERABILITY: Unsigned firmware could be installed
IMPACT: High (5) - Device compromise, data breach
LIKELIHOOD: Medium (3) - Requires physical access
INHERENT RISK: 15 (High)

CONTROL: Firmware signature verification
IMPLEMENTATION: ECDSA P-256 signature checked before install
RESIDUAL RISK: 3 (Low) - Cryptographic attack unlikely

STATUS: Mitigated
-------------------------------------------------------------
RISK ID: R-002
THREAT: Man-in-the-middle attack on cloud communication
VULNERABILITY: Network traffic interception
IMPACT: High (4) - Data exposure, command injection
LIKELIHOOD: Medium (3) - Public networks possible
INHERENT RISK: 12 (High)

CONTROL: TLS 1.3 with certificate pinning
IMPLEMENTATION: Hardcoded CA certificate, no fallback
RESIDUAL RISK: 2 (Low) - Certificate compromise unlikely

STATUS: Mitigated
-------------------------------------------------------------
[Continue for all identified risks...]

RISK SUMMARY:
Total risks identified: 23
Critical: 0
High: 3 (all mitigated to Low/Medium)
Medium: 8 (all mitigated to Low)
Low: 12 (accepted or mitigated)

RESIDUAL RISK ACCEPTANCE:
All residual risks are within acceptable tolerance.
Signed: [Security Lead], [Date]

Sección 4: información sobre el periodo de soporte

Propósito: documentar el razonamiento detrás del periodo de soporte elegido. El periodo de soporte es el tiempo durante el cual el fabricante se compromete a proporcionar actualizaciones de seguridad. El expediente técnico debe recoger la información que motivó esa decisión.

Contenido obligatorio

Cómo se ve una buena documentación

SUPPORT PERIOD DETERMINATION
Product: Industrial Gateway IG-200
Market placement: 2026-09-01
Declared support period: 2026-09-01 to 2034-09-01 (8 years)

Rationale:
1. Expected operational lifetime: 8-10 years (field deployment data,
   comparable to predecessor IG-150 still active in 2024 at 9 years).
2. Component support: Linux LTS kernel covers 6 years; we backport
   security patches for 2 additional years using vendor commitments.
3. Customer contracts: top 3 customers have 7-year service agreements;
   remainder typically renew on 5-year cycles.
4. Sector guidance: NIS2 covers operators of essential services using
   this gateway; assume update requirements through asset lifetime.
5. End-of-support communication: documented in user manual and EOL
   policy at https://example.com/security/eol.

Decision approved by: [Product Owner], [Security Lead], [Legal]
Date: 2026-08-15
Review trigger: any material change to component support timelines

Errores comunes

• Fijar el periodo al mínimo de 5 años sin justificación. Los 5 años de la regla del periodo de soporte son un suelo, no un valor por defecto. Los productos con vidas útiles esperadas más largas necesitan un periodo más amplio.
• Olvidar que el suelo es "o la vida útil del producto, si es más corta". Un dispositivo de consumo vendido durante 18 meses sigue debiendo soporte de actualización mientras se espere razonablemente que el producto siga en uso.
• No registrar las entradas. Las autoridades de vigilancia pueden preguntar cómo se determinó el periodo. "Elegimos 5 años" no es una respuesta.
• Tratarlo como inmutable. Si los cronogramas de soporte de componentes cambian (por ejemplo, el SO upstream alcanza su EOL antes de lo previsto), el registro de la decisión debe actualizarse y el compromiso de soporte debe comunicarse.

Mapeo de requisitos esenciales

Propósito: demostrar cómo se cumple cada requisito esencial de ciberseguridad.

Requisitos de la parte I

Mapea cada requisito de seguridad desde el diseño con tu implementación:

ESSENTIAL REQUIREMENTS COMPLIANCE MATRIX

ANNEX I, PART I - SECURITY REQUIREMENTS
═══════════════════════════════════════════════════════════

1. DESIGNED WITHOUT KNOWN EXPLOITABLE VULNERABILITIES
   Status: COMPLIANT
   Evidence:
   - Vulnerability scan report (Trivy): 0 critical/high
   - Dependency analysis: All components at latest secure versions
   - Penetration test report: No exploitable vulnerabilities found
   Reference: Test Report TR-2027-001, pages 15-23

2. SECURE BY DEFAULT CONFIGURATION
   Status: COMPLIANT
   Evidence:
   - Default configuration review document
   - No default passwords (unique credentials required at setup)
   - Unnecessary services disabled by default
   - Secure protocols enabled by default (TLS, not HTTP)
   Reference: Design Document DD-004, Section 3.2

3. PROTECTION AGAINST UNAUTHORIZED ACCESS
   Status: COMPLIANT
   Evidence:
   - Authentication architecture document
   - Access control implementation
   - Session management design
   - Failed login lockout mechanism
   Reference: Security Architecture SA-001, Chapter 4

4. CONFIDENTIALITY OF DATA
   Status: COMPLIANT
   Evidence:
   - Encryption specifications (AES-256-GCM)
   - Key management procedures
   - Data classification and handling
   Reference: Design Document DD-005

5. INTEGRITY OF DATA AND COMMANDS
   Status: COMPLIANT
   Evidence:
   - Message authentication (HMAC)
   - Command validation logic
   - Input validation procedures
   Reference: Security Architecture SA-001, Chapter 5

6. DATA MINIMIZATION
   Status: COMPLIANT
   Evidence:
   - Data inventory document
   - Justification for each data type collected
   - Retention policy (automatic purge after 90 days)
   Reference: Privacy Impact Assessment PIA-001

[Continue for all essential requirements...]

Requisitos de la parte II

Mapea cada requisito de gestión de vulnerabilidades con tu implementación:

ANNEX I, PART II - VULNERABILITY HANDLING
═══════════════════════════════════════════════════════════

1. IDENTIFY AND DOCUMENT VULNERABILITIES
   Status: COMPLIANT
   Evidence:
   - Vulnerability tracking system (JIRA project VULN)
   - CVE monitoring process document
   - SBOM-based dependency tracking
   Reference: Process Document PD-VULN-001

2. ADDRESS VULNERABILITIES WITHOUT DELAY
   Status: COMPLIANT
   Evidence:
   - Vulnerability response SLA document
   - Historical response time metrics
   - Patch development process
   Reference: Process Document PD-VULN-002

3. APPLY EFFECTIVE REGULAR TESTING
   Status: COMPLIANT
   Evidence:
   - Security testing schedule
   - Automated scan reports (weekly)
   - Annual penetration test reports
   Reference: Test Plan TP-SEC-001

[Continue for all Part II requirements...]

Sección 5: normas aplicadas

Propósito: documentar qué normas se utilizaron y cómo.

Contenido obligatorio

Formato de documentación de normas

APPLIED STANDARDS

HARMONIZED STANDARDS (presumption of conformity):
-------------------------------------------------------------
Standard: EN 303 645 (when harmonized for CRA)
Title: Cybersecurity for Consumer IoT
Status: Applied in full
Publication: OJEU [reference when published]
Evidence: Standards Compliance Report SCR-001
-------------------------------------------------------------

OTHER STANDARDS APPLIED:
-------------------------------------------------------------
Standard: IEC 62443-4-1:2018
Title: Security for Industrial Automation - Secure Development
Status: Applied (selected requirements)
Clauses Applied: 5, 6, 7, 8, 10
Evidence: SDL Documentation SLD-001
-------------------------------------------------------------
Standard: ISO/IEC 27001:2022
Title: Information Security Management
Status: Organization certified (Certificate #12345)
Relevance: ISMS covers product development processes
-------------------------------------------------------------
Standard: NIST Cybersecurity Framework 2.0
Title: Framework for Improving Critical Infrastructure Cybersecurity
Status: Reference framework for risk assessment
Evidence: Risk Assessment methodology document
-------------------------------------------------------------

DEVIATIONS:
-------------------------------------------------------------
Standard: EN 303 645
Clause: 5.3-2 (Unique per device credentials)
Deviation: Credentials unique per device but not pre-provisioned
Justification: Device requires user setup; credentials created
              during first-time configuration
Alternative Measure: Strong password requirements enforced,
                    account lockout after failed attempts
Risk Assessment: Residual risk acceptable (see R-015)
-------------------------------------------------------------

Sección 6: resultados de las pruebas

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

Contenido obligatorio

Formato de resultados de pruebas

TEST RESULTS SUMMARY

Product: SmartSense Pro (SSP-3000) v2.4.1
Test Period: December 2026 - January 2027
Test Lead: [Name]

═══════════════════════════════════════════════════════════
TEST CAMPAIGN: TC-2027-001
═══════════════════════════════════════════════════════════

1. SECURITY FUNCTIONAL TESTING
   Scope: Authentication, authorization, encryption, secure boot
   Test Cases: 85
   Passed: 85
   Failed: 0
   Reference: Test Report TR-FUNC-001

2. VULNERABILITY SCANNING
   Tool: Trivy v0.48.0 + Nessus Professional
   Scope: Firmware, network services, web interface
   Findings:
     Critical: 0
     High: 0
     Medium: 2 (accepted with justification)
     Low: 5 (accepted)
   Reference: Scan Report SR-VULN-001

3. PENETRATION TESTING
   Provider: [Third-party firm name]
   Scope: Black-box testing of deployed device
   Duration: 5 days
   Findings:
     Critical: 0
     High: 0
     Medium: 1 (remediated before release)
     Low: 3 (accepted)
   Reference: Pentest Report PT-2027-001

4. FIRMWARE ANALYSIS
   Tool: EMBA v1.3
   Scope: Binary analysis, hardcoded credentials, crypto issues
   Findings:
     Critical: 0
     High: 0
     Informational: 4
   Reference: Firmware Analysis Report FA-001

5. CONFIGURATION REVIEW
   Scope: Default configuration security
   Findings: All defaults meet security requirements
   Reference: Configuration Review CR-001

═══════════════════════════════════════════════════════════
OVERALL ASSESSMENT: PASS
All critical and high findings remediated.
Medium/Low findings accepted with documented justification.
═══════════════════════════════════════════════════════════

Sección 7: declaración UE de conformidad

Propósito: incluir la declaración formal o una referencia a ella.

Contenido obligatorio

El expediente técnico debe incluir una copia de la declaración UE de conformidad o una referencia al lugar donde puede obtenerse.

Sección 8: lista de materiales de software

Propósito: ofrecer transparencia de componentes para el seguimiento de vulnerabilidades. El SBOM forma parte del expediente técnico previa solicitud motivada de una autoridad de vigilancia del mercado. En la práctica, los fabricantes lo preparan y lo mantienen junto con el resto del expediente.

Guías relacionadas: para productos de hardware, conserva la evidencia de componentes hardware cuando respalde la evaluación de riesgos, la información para el usuario o el análisis de vulnerabilidades. BSI TR-03183 puede ayudar con la calidad del SBOM, y VEX puede comunicar el estado de vulnerabilidad de los componentes. Consulta la guía de requisitos del SBOM para elegir formato, niveles de calidad de BSI TR-03183, alcance del HBOM y uso de VEX; y la guía de notificación de vulnerabilidades para cómo VEX respalda la obligación de "sin vulnerabilidades explotables conocidas".

Contenido obligatorio

Documentación del SBOM

¿Cuándo debe actualizarse el expediente técnico?

Documentación viva

El expediente técnico no es estático:

Requisitos de conservación

DOCUMENTATION RETENTION

Retention Period: at least 10 years from market placement, or the support period, whichever is longer

Example Timeline:
- Product first placed on market: March 2027
- Last unit placed on market: December 2030
- Documentation retention until: December 2040

Storage Requirements:
- Secure, accessible storage
- Backup procedures
- Integrity protection
- Available within [48 hours] of authority request

Errores comunes

Evaluación de riesgos incompleta

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

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

SBOM ausente

Problema: sin SBOM o con un SBOM que no incluye las dependencias transitivas.

Solución: genera el SBOM con herramientas adecuadas. Incluye el árbol completo de dependencias.

Documentación desactualizada

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

Solución: actualiza la documentación con cada versión. Registra las versiones de forma explícita.

Sin trazabilidad de requisitos

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

Solución: crea un mapeo explícito desde cada requisito esencial hasta la evidencia.

Pruebas sin evidencia

Problema: se afirma haber hecho pruebas pero no hay informes disponibles.

Solución: conserva todos los informes de pruebas. Inclúyelos en el expediente técnico o haz una referencia clara.

Lista de comprobación del expediente técnico