Documentazione tecnica CRA: guida

Il fascicolo tecnico è il pacchetto di prove per la conformità CRA. Le autorità di vigilanza del mercato possono richiederlo, e un organismo notificato lo esaminerà quando il percorso di conformità ne prevede uno. Senza un fascicolo tecnico completo, il prodotto non può essere immesso legalmente sul mercato dell'UE.

Questa guida percorre il fascicolo tecnico sezione per sezione, spiegando quali evidenze servono in ciascuna area e come prepararle.

Cos'è il fascicolo tecnico?

Il fascicolo tecnico (chiamato anche "documentazione tecnica") è il pacchetto completo di prove che dimostra la conformità del prodotto ai requisiti essenziali di cibersicurezza.

Non è:

• Documentazione di marketing
• Solo manuali utente
• Un esercizio di spunta caselle

È:

• Prove tecniche complete
• Documentazione viva (aggiornata per tutta la vita del prodotto)
• La tua difesa nelle indagini di vigilanza del mercato
• Necessario per la valutazione della conformità

Cosa deve contenere il fascicolo tecnico

Il fascicolo tecnico è più facile da verificare quando è organizzato intorno a otto aree di evidenza:

Sezione 1: Descrizione generale

Scopo: stabilire cos'è il prodotto e a cosa serve.

Contenuto richiesto

Esempio

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

Sezione 2: Progettazione, sviluppo e gestione delle vulnerabilità

Scopo: documentare come il prodotto è stato progettato e sviluppato, come le vulnerabilità sono gestite dopo il rilascio e come i processi di produzione e monitoraggio vengono validati. Trattarli come un unico blocco di evidenze: registri di progettazione e sviluppo, processi di gestione delle vulnerabilità e controlli di produzione e monitoraggio che dimostrano che i rilasci sono costruiti e sorvegliati in modo coerente.

Progettazione e sviluppo: contenuto richiesto

Come si presenta una documentazione "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)

Gestione delle vulnerabilità: contenuto richiesto

Documentazione della gestione delle vulnerabilità

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. REPORTING TO COORDINATING CSIRT AND ENISA
   Trigger: Active exploitation detected
   Timeline: 24h early warning to coordinating CSIRT and ENISA, 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

Produzione e monitoraggio: contenuto richiesto

Per i prodotti software non esiste una linea di fabbrica. Produzione e monitoraggio significa la pipeline di build e rilascio che produce gli artefatti consegnabili, la validazione che tali processi funzionino come previsto e il monitoraggio post-deployment che intercetta regressioni e nuove vulnerabilità. Documenta ciascun aspetto in modo che un auditor possa risalire da un rilascio a una build verificata e riproducibile.

Documentazione di produzione e monitoraggio

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

Sezione 3: Valutazione dei rischi di cibersicurezza

Scopo: conservare la valutazione del rischio approvata e mostrare dove si trovano le sue evidenze nel fascicolo.

Come svolgere la valutazione, la mappatura di applicabilità di tutti i 13 requisiti di sicurezza, un esempio pratico e uno scheletro di documento copiabile si trovano nella guida dedicata alla valutazione del rischio di cibersicurezza. Questa sezione del fascicolo tecnico conserva i suoi risultati. La valutazione e le sue decisioni di applicabilità sono l'obbligo di legge. I registri di approvazione e lo storico delle revisioni sono la prassi che dimostra che il documento è rimasto aggiornato.

Contenuto richiesto

Formato della valutazione dei rischi

Usare lo scheletro di documento della guida alla valutazione del rischio. Contiene il formato del registro, la scheda di applicabilità e un esempio pratico. Archiviare qui il documento risultante senza modifiche, così che la versione vista dalle autorità sia quella che il team mantiene.

Sezione 4: Informazioni sul periodo di supporto

Scopo: documentare il ragionamento alla base del periodo di supporto scelto. Il periodo di supporto è il tempo durante il quale il fabbricante si impegna a fornire aggiornamenti di sicurezza. Il fascicolo tecnico deve riportare le informazioni che hanno guidato tale decisione.

Contenuto richiesto

Come si presenta una buona documentazione

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

Errori frequenti

• Ancorarsi al minimo di 5 anni senza giustificazione. I 5 anni della regola sul periodo di supporto sono una soglia minima, non un valore predefinito. Prodotti con vita utile attesa più lunga richiedono un periodo più lungo.
• Dimenticare che la soglia è "o vita del prodotto, se inferiore". Un dispositivo consumer venduto per 18 mesi deve comunque ricevere supporto agli aggiornamenti per il periodo durante il quale ci si aspetta ragionevolmente che il prodotto sia in uso.
• Non registrare gli elementi considerati. Le autorità di vigilanza possono chiedere come è stato determinato il periodo. "Abbiamo scelto 5 anni" non è una risposta.
• Considerarlo immutabile. Se le tempistiche di supporto dei componenti cambiano (ad esempio, un OS upstream raggiunge l'EOL prima del previsto), il registro della decisione deve essere aggiornato e l'impegno di supporto comunicato.

Mappatura dei requisiti essenziali

Scopo: dimostrare come ogni requisito essenziale di cibersicurezza sia soddisfatto.

L'analisi per requisito vive nella valutazione del rischio. La sua scheda di applicabilità risponde, per ciascuno dei 13 requisiti di sicurezza, se si applica e come viene implementato, con una giustificazione scritta per ogni esclusione. La guida alla valutazione del rischio contiene la tabella di mappatura completa, le domande di verifica e le evidenze tipiche per ciascun requisito.

Requisiti della parte I

Conservare nel fascicolo tecnico:

• La scheda di applicabilità corrente della valutazione del rischio approvata, una voce per requisito.
• Un riferimento alle evidenze per ciascun requisito (rapporti di prova, documenti di progettazione, revisioni della configurazione) così che un'autorità possa risalire da ogni decisione alla sua prova.

Requisiti della parte II

I requisiti di gestione delle vulnerabilità sono soddisfatti da processi, non da funzionalità di prodotto. Conservare nel fascicolo tecnico i riferimenti ai documenti di processo che li governano: identificazione delle vulnerabilità e SBOM, rimedio e distribuzione degli aggiornamenti, calendario dei test, prassi di divulgazione, policy CVD e contatto per le segnalazioni. La guida alla gestione delle vulnerabilità illustra cosa deve fare ciascun processo.

Sezione 5: Norme applicate

Scopo: documentare quali norme sono state utilizzate e in che modo.

Contenuto richiesto

Formato di documentazione delle norme

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)
-------------------------------------------------------------

Sezione 6: Risultati dei test

Scopo: fornire prove che i requisiti siano effettivamente soddisfatti.

Contenuto richiesto

Formato dei risultati dei test

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.
═══════════════════════════════════════════════════════════

Sezione 7: Dichiarazione UE di conformità

Scopo: includere la dichiarazione formale o un riferimento alla stessa.

Contenuto richiesto

Il fascicolo tecnico deve includere una copia della dichiarazione UE di conformità o un riferimento al luogo in cui può essere ottenuta.

Sezione 8: Distinta dei materiali software

Scopo: fornire trasparenza sui componenti per il tracciamento delle vulnerabilità. L'SBOM fa parte del fascicolo tecnico: i fabbricanti lo preparano e lo mantengono insieme al resto del fascicolo, e lo producono per le autorità di vigilanza del mercato su richiesta motivata.

Guide correlate: Per i prodotti hardware, conserva le evidenze sui componenti fisici quando supportano la valutazione dei rischi, le informazioni per l'utente o l'analisi delle vulnerabilità. BSI TR-03183 può aiutare sulla qualità dell'SBOM, e VEX può comunicare lo stato di vulnerabilità dei componenti. Vedi la guida ai requisiti SBOM per le scelte di formato, i livelli di qualità BSI TR-03183, l'ambito HBOM e l'uso di VEX; e la guida alla segnalazione delle vulnerabilità per come VEX supporta l'obbligo di "nessuna vulnerabilità sfruttabile nota".

Contenuto richiesto

Documentazione SBOM

Quando va aggiornato il fascicolo tecnico?

Documentazione viva

Il fascicolo tecnico non è statico:

Requisiti di conservazione

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

Errori comuni

Avviso: Un fascicolo tecnico che descrive solo la versione 1.0 quando il prodotto è alla versione 2.3 è considerato non conforme. Aggiorna la documentazione a ogni rilascio.

Valutazione dei rischi incompleta

Problema: valutazione dei rischi che non copre tutte le minacce o priva di dettagli sul trattamento.

Correzione: usa una metodologia strutturata. Mappa ogni rischio identificato a un controllo o a una decisione di accettazione.

SBOM mancante

Problema: nessun SBOM, o uno SBOM che omette le dipendenze di primo livello obbligatorie.

Correzione: genera uno SBOM con strumenti adeguati, coprendo almeno le dipendenze di primo livello richieste dal CRA (Allegato I Parte II(1)). Estendere all'albero completo delle dipendenze è una prassi più solida per l'abbinamento delle vulnerabilità, non il minimo legale.

Documentazione obsoleta

Problema: il fascicolo tecnico descrive la versione 1.0 ma il prodotto è alla versione 2.3.

Correzione: aggiorna la documentazione a ogni rilascio. Traccia le versioni in modo esplicito.

Nessuna tracciabilità dei requisiti

Problema: si dichiara conformità ma non si mostra come ogni requisito sia soddisfatto.

Correzione: crea una mappatura esplicita da ogni requisito essenziale alle evidenze.

Test senza evidenze

Problema: si dichiara di aver eseguito test ma non si dispone dei rapporti.

Correzione: conserva tutti i rapporti di test. Includili nel fascicolo tecnico o referenziali chiaramente.

Lista di controllo del fascicolo tecnico