Valutazione del rischio di cibersicurezza CRA: guida

Ogni fabbricante di un prodotto con elementi digitali che rientra nell’ambito CRA deve svolgere una valutazione del rischio di cibersicurezza e conservarla per iscritto. È il documento che decide quali requisiti di sicurezza del CRA vincolano il suo specifico prodotto, e come li soddisfa. Le autorità di vigilanza del mercato possono richiederla. Senza di essa, il fascicolo tecnico è incompleto e la dichiarazione di conformità non ha fondamento.

Questa guida spiega come svolgere la valutazione, come documentarla e come mantenerla aggiornata. Include una mappatura completa dei requisiti di sicurezza, un esempio pratico e uno scheletro di documento copiabile.

Cos’è la valutazione del rischio di cibersicurezza CRA?

La valutazione del rischio di cibersicurezza è un’analisi documentata dei rischi a cui è esposto il suo prodotto, basata sulla sua destinazione d’uso e sui modi in cui è ragionevole attendersi che le persone lo utilizzino. Copre le condizioni d’uso, come l’ambiente operativo e gli asset che il prodotto deve proteggere, e tiene conto di quanto a lungo il prodotto dovrebbe restare in uso.

La valutazione ha un unico risultato da cui dipende tutto il resto. Dichiara, per ciascun requisito di sicurezza del prodotto previsto dal CRA, se quel requisito si applica al suo prodotto e, in caso affermativo, come la progettazione e i processi lo implementano. Registra inoltre come soddisfa la base di sicurezza fin dalla progettazione e come i suoi processi di gestione delle vulnerabilità coprono il prodotto.

Tre proprietà la distinguono da un generico registro dei rischi aziendale:

• È specifica per il prodotto. Fondata sull’architettura, sulle interfacce e sugli utenti di quel prodotto. Un registro dei rischi di un SGSI aziendale non la soddisfa. Il nostro confronto con la ISO 27001 tratta questa differenza in dettaglio.
• È un documento che vive con il ciclo di vita del prodotto. La usa durante la pianificazione e la progettazione, non solo al rilascio. E la aggiorna per tutto il periodo di supporto.
• È un’evidenza. La valutazione documentata entra nel suo fascicolo tecnico, dove le autorità possono richiederla.

Chi ne ha bisogno, e quando

Ogni fabbricante che immette sul mercato UE un prodotto con elementi digitali ne ha bisogno, a meno che il prodotto non sia del tutto fuori dall’ambito CRA. Nell’ambito: hardware con firmware, software autonomo e prodotti il cui trattamento remoto dei dati fa parte dell’offerta. Si applica a un’azienda software di una sola persona allo stesso modo di una multinazionale. I prodotti esclusi dal CRA, come i dispositivi medici coperti, alcuni veicoli e le apparecchiature aeronautiche certificate, seguono invece le proprie norme settoriali. Se non è certo che il CRA copra affatto il suo prodotto, inizi dalla guida sull’ambito di applicazione.

La tempistica conta più di quanto la maggior parte dei team si aspetti:

• Inizi durante la pianificazione. La valutazione serve a orientare le decisioni di progettazione. Svolga una prima analisi quando l’architettura è ancora poco costosa da modificare.
• La completi e la documenti prima dell’immissione sul mercato. La valutazione scritta deve essere nel fascicolo tecnico quando il prodotto viene immesso sul mercato.
• La mantenga per tutto il periodo di supporto. La valutazione non è mai definitiva. Segue il prodotto per tutto il tempo in cui lei deve fornire aggiornamenti di sicurezza.

Esiste una sola semplificazione, di ambito ristretto. Copre solo i prodotti che il CRA tratta come sistemi di IA ad alto rischio e che sono anche soggetti ad altre norme UE che richiedono una valutazione del rischio. Per questi, la valutazione di cibersicurezza può diventare parte di quell’altra valutazione del rischio invece di essere un documento separato. Gli obblighi di contenuto restano gli stessi. Consulti la guida sulla sovrapposizione con il regolamento IA per come funziona in pratica.

Cosa deve contenere la valutazione

Il CRA fissa un contenuto minimo. La sua valutazione deve coprire tre elementi:

• Il prodotto nel suo contesto. A cosa serve il prodotto, come è ragionevole attendersi che le persone lo utilizzino, l’ambiente in cui opera, gli asset che deve proteggere e per quanto tempo ci si attende che resti in uso.
• Le decisioni di applicabilità. Per ciascuno dei 13 requisiti di sicurezza del prodotto: se si applica a questo prodotto e come viene implementato. Dove uno non si applica, una giustificazione scritta chiara.
• La copertura dei processi. Come viene soddisfatta la base di sicurezza fin dalla progettazione e come i suoi processi di gestione delle vulnerabilità coprono il prodotto.

L’obbligo di giustificazione non è negoziabile. Un «non applicabile» senza motivazione è un difetto. Indichi i fatti relativi al prodotto che escludono il requisito, e li metta per iscritto. La giustificazione scritta entra nel fascicolo tecnico insieme al resto della valutazione.

Oltre a questo minimo di legge, aggiunga i controlli che rendono il documento difendibile: decisioni di trattamento con il relativo rischio residuo, criteri di accettazione, un’approvazione nominativa con data e uno storico delle revisioni. Il CRA non ne impone nessuno. Sono il modo in cui dimostra che la valutazione è rimasta aggiornata, e che una persona responsabile ha accettato il rischio residuo.

Scelta del metodo

Il CRA non impone alcuna metodologia di valutazione, scala di punteggio o modello. Ciò che richiede è un risultato documentato che sostenga le decisioni di applicabilità. Scelga un metodo che il suo team possa ripetere, e lo descriva all’interno della valutazione così che un revisore possa seguire il suo ragionamento.

Una regola vale a prescindere dalla scelta. Esprima ogni rischio come combinazione della sua probabilità e dell’entità della perdita o della perturbazione che potrebbe causare. Il CRA inquadra il rischio di cibersicurezza esattamente in queste due dimensioni, quindi un elenco di minacce che non valuta nessuna delle due non è ancora una valutazione.

Scelte praticabili comuni:

Metodo	Cosa offre	Si adatta meglio a
Matrice probabilità per impatto	Valutazioni numeriche semplici del rischio e un registro ordinato	Piccoli team, prime valutazioni
Modellazione delle minacce in stile STRIDE	Identificazione sistematica delle minacce per componente e flusso di dati	Prodotti a forte componente software con diagrammi di architettura chiari
Processo in stile ISO/IEC 27005	Un ciclo completo di gestione del rischio con contesto, analisi, trattamento	Organizzazioni che gestiscono già un SGSI
Approccio minaccia-rischio IEC 62443	Analisi per zone e condotti nei contesti industriali	Prodotti industriali e OT, si veda la guida all’automazione industriale

Le prossime norme armonizzate non cambieranno la libertà di scelta del metodo. La norma quadro europea in bozza per la gestione del rischio del CRA è essa stessa neutrale rispetto al metodo, e si basa sul processo di gestione del rischio ISO 31000 senza imporre un modello di punteggio. Il nostro tracker delle norme armonizzate ne segue i progressi. E le norme non sostituiscono mai la valutazione: anche un prodotto che applica pienamente le norme armonizzate necessita di una propria valutazione documentata, e deve verificare che le norme coprano i rischi che ha effettivamente identificato.

Qualunque scelga, mantenga due regole:

1. Il metodo deve produrre risposte di applicabilità. Un elenco di rischi valutati non basta. Il risultato deve mappare sui 13 requisiti di sicurezza sottostanti.
2. Metta per iscritto il metodo. Definizioni della scala, formula, soglie di accettazione. Un punteggio «12 (Alto)» non significa nulla se la scala non è documentata. La documentazione dovrebbe permettere a un’autorità di vigilanza del mercato di verificare come ciascun rischio è stato individuato, valutato e trattato.

La valutazione, passo dopo passo

Un processo praticabile in sette passi. Adatti la profondità alla complessità e al rischio del suo prodotto.

Passo 1: definire ambito e contesto

Registri il nome e la versione del prodotto, la sua destinazione d’uso, gli ambienti in cui verrà usato e i suoi utenti. Dichiari cosa rientra nell’ambito, comprese le app companion, i backend cloud che fanno parte dell’offerta e i componenti in bundle. Dichiari cosa resta fuori e perché.

Passo 2: identificare gli asset

Elenchi ciò che il prodotto deve proteggere. Gli asset tipici sono i dati utente, le credenziali e le chiavi, l’integrità del firmware e della configurazione, la disponibilità della funzione del prodotto e la rete circostante. Annoti dove risiede ciascun asset e come si muove.

Passo 3: identificare le minacce

Percorra la superficie della sua architettura, un’interfaccia alla volta. Prima le interfacce esterne, perché è da lì che partono gli attaccanti. Per ciascuna interfaccia e flusso di dati, si chieda cosa potrebbe fare un attaccante: intercettare, falsificare, alterare, sommergere, estrarre. Includa l’uso improprio ragionevolmente prevedibile del prodotto, non solo l’attacco deliberato. Registri ogni minaccia credibile con la vulnerabilità che sfrutterebbe.

Passo 4: valutare i rischi

Valuti probabilità e impatto per ciascuna minaccia usando la sua scala documentata. Se un incidente potrebbe causare un danno fisico, includa l’effetto sulla salute e sulla sicurezza degli utenti nella valutazione dell’impatto. Classifichi i risultati. Lo scopo della valutazione è la definizione delle priorità, non la precisione. Una classificazione difendibile che guida le decisioni di progettazione vale più di una tabella dall’aspetto preciso che nessuno usa.

Passo 5: decidere l’applicabilità dei requisiti di sicurezza

Esamini i 13 requisiti di sicurezza del prodotto uno per uno. Per ciascuno, dichiari se si applica a questo prodotto, quali dei rischi identificati affronta e come lo implementa. Dove uno realmente non si applica, scriva la giustificazione. La tabella di mappatura completa più avanti è il suo strumento di lavoro.

Passo 6: trattare i rischi e registrare i residui

Per ciascun rischio rilevante, registri il controllo scelto, dove è implementato e il rischio residuo dopo il controllo. Definisca criteri di accettazione e registri chi ha accettato il rischio residuo. I rischi privi di un controllo richiedono una decisione di accettazione esplicita e attribuita.

Passo 7: approvare e stabilire i fattori di aggiornamento

Faccia approvare la valutazione da un proprietario nominativo, con data. Poi definisca gli eventi che la riaprono: nuove informazioni sulle vulnerabilità, nuove funzionalità, modifiche ai componenti o ai fornitori, risultati di incidenti. Aggiunga una tabella di storico delle revisioni così che le autorità possano vedere che il documento è vissuto.

Mappatura dei 13 requisiti di sicurezza

È il cuore della valutazione. Il CRA elenca 13 requisiti di sicurezza del prodotto, e il suo documento deve rispondere a due domande per ciascuno: si applica, e come lo implementa. La tabella sottostante traduce ogni requisito in domande di verifica ed evidenze tipiche.

La colonna del requisito resta vicina al testo di legge. La colonna dei controlli non fa parte della norma: elenca le misure e le evidenze che i team usano tipicamente per dimostrare che il requisito è soddisfatto.

Due note pratiche sull’uso della tabella:

• «Ove applicabile» è una decisione specifica del prodotto, ed è lei a doverla difendere. I requisiti si applicano sulla base della sua valutazione del rischio. Uno strumento software autonomo che non conserva dati né impostazioni può giustificare l’esclusione del requisito di rimozione dei dati. Nessun prodotto può escludere la capacità di aggiornamento solo perché gli aggiornamenti sono scomodi.
• La mappatura funge anche da indice delle evidenze di conformità. La colonna dei controlli di ciascuna riga indica cosa appartiene al fascicolo tecnico, ed è il materiale che una valutazione della conformità esaminerà.

Copertura dei processi di gestione delle vulnerabilità

La valutazione deve anche dichiarare come i suoi processi continuativi coprono il prodotto. I requisiti di processo del CRA sono il lato operativo della stessa medaglia. La sua valutazione dovrebbe confermare, brevemente e con riferimenti ai documenti proprietari, che per questo prodotto lei:

• identifica e documenta vulnerabilità e componenti, compreso uno SBOM che copra almeno le dipendenze di primo livello
• affronta e pone rimedio alle vulnerabilità senza ritardo, con aggiornamenti di sicurezza distribuiti separatamente dagli aggiornamenti di funzionalità ove tecnicamente fattibile
• applica test e revisioni efficaci e regolari della sicurezza del prodotto
• una volta rilasciato un aggiornamento, divulga pubblicamente la vulnerabilità corretta con una descrizione, i prodotti interessati, gli impatti, la gravità e le indicazioni di rimedio. Un rinvio giustificato è ammesso quando i rischi di sicurezza della divulgazione superano i benefici, e solo finché gli utenti non abbiano avuto la possibilità di applicare la patch
• gestisce una policy di divulgazione coordinata delle vulnerabilità
• fornisce un indirizzo di contatto per le segnalazioni di vulnerabilità e aiuta la circolazione di informazioni sulle potenziali vulnerabilità, anche per i componenti di terze parti
• distribuisce gli aggiornamenti tramite meccanismi sicuri così che le correzioni arrivino tempestivamente, automaticamente ove applicabile agli aggiornamenti di sicurezza
• diffonde gli aggiornamenti di sicurezza senza ritardo e a titolo gratuito, con messaggi di advisory che indicano agli utenti cosa fare. Per un prodotto su misura, un cliente aziendale può concordare diversamente solo sul punto della gratuità

Questi punti sono riassunti di lavoro, non il testo di legge completo. Mantenga questa sezione breve nella sua valutazione, colleghi ai documenti di processo proprietari e verifichi i requisiti completi nella nostra guida alla gestione delle vulnerabilità.

Esempio pratico

Gli estratti sottostanti mostrano il livello di dettaglio che funziona nella pratica. Il prodotto è un sensore ambientale connesso fittizio, con un’app companion e una dashboard cloud.

Estratto del registro dei rischi

VALUTAZIONE DEL RISCHIO DI CIBERSICUREZZA

Prodotto: SmartSense Pro (SSP-3000)
Versione: 2.4.1
Data della valutazione: gennaio 2027
Proprietario: [Nome, Team Sicurezza]

METODO:
Probabilità per impatto, scale definite nella sezione 1.
Rischio = Probabilità (1-5) x Impatto (1-5)
Fasce: Basso (1-4), Medio (5-9), Alto (10-16), Critico (17-25)

-------------------------------------------------------------
ID RISCHIO: R-001
MINACCIA: Modifica non autorizzata del firmware
VULNERABILITÀ: Potrebbe essere installato firmware non firmato
IMPATTO: 5 - Compromissione del dispositivo, violazione dei dati
PROBABILITÀ: 3 - Richiede accesso fisico o alla rete locale
RISCHIO INERENTE: 15 (Alto)

CONTROLLO: Verifica della firma del firmware
IMPLEMENTAZIONE: Firma ECDSA P-256 verificata prima dell’installazione
RISCHIO RESIDUO: 3 (Basso) - Attacco crittografico improbabile
STATO: Mitigato
-------------------------------------------------------------
ID RISCHIO: R-002
MINACCIA: Intercettazione della comunicazione cloud
VULNERABILITÀ: Traffico di rete leggibile in transito
IMPATTO: 4 - Esposizione dei dati, iniezione di comandi
PROBABILITÀ: 3 - Reti condivise e pubbliche previste
RISCHIO INERENTE: 12 (Alto)

CONTROLLO: TLS 1.3 con certificate pinning
IMPLEMENTAZIONE: Certificato CA fissato, nessun fallback
RISCHIO RESIDUO: 2 (Basso) - Compromissione del certificato improbabile
STATO: Mitigato
-------------------------------------------------------------
[Continua per tutti i rischi identificati...]

RIEPILOGO DEI RISCHI:
Rischi totali identificati: 23
Critici: 0
Alti: 3 (tutti mitigati a Basso o Medio)
Medi: 8 (tutti mitigati a Basso)
Bassi: 12 (accettati o mitigati)

ACCETTAZIONE DEL RISCHIO RESIDUO:
Tutti i rischi residui rientrano nella tolleranza definita nella sezione 1.
Accettato da: [Responsabile Sicurezza], [Data]

Estratto della scheda di applicabilità

APPLICABILITÀ DEI REQUISITI DI SICUREZZA

REQ 3 - AGGIORNAMENTI DI SICUREZZA
Si applica: SÌ
Rischi affrontati: R-004, R-011
Implementazione: Aggiornamenti OTA firmati. Aggiornamenti di sicurezza
automatici attivi per impostazione predefinita, opt-out e rinvio
nelle impostazioni dell’app. Utenti notificati nell’app e via email.
Evidenza: Progettazione del meccanismo di aggiornamento UMD-002

REQ 12 - REGISTRAZIONE E MONITORAGGIO
Si applica: SÌ
Rischi affrontati: R-009
Implementazione: Eventi di sicurezza (errori di autenticazione, modifiche
di configurazione, eventi di aggiornamento) registrati sul dispositivo
e inoltrati al cloud. Opt-out della registrazione disponibile nelle
impostazioni sulla privacy.
Evidenza: Progettazione della registrazione LD-001, catalogo degli eventi

REQ 13 - RIMOZIONE SICURA DEI DATI
Si applica: SÌ
Rischi affrontati: R-015
Implementazione: Il ripristino alle impostazioni di fabbrica cancella
in modo permanente tutti i dati e le impostazioni memorizzati,
comprese le credenziali di rete. Il dispositivo non conserva dati
utente trasferibili, quindi non esiste un percorso di trasferimento.
Evidenza: Progettazione di ripristino e cancellazione RD-001

[Continua per tutti i 13 requisiti...]

Noti la voce sulla rimozione dei dati: il requisito copre tutti i dati e le impostazioni, e le credenziali di rete memorizzate rientrano. Dove un requisito realmente non si applica, la voce mantiene la stessa struttura ma indica i fatti relativi al prodotto che lo escludono. Uno strumento software autonomo senza dati né impostazioni memorizzati potrebbe registrare: «Non applicabile. Il prodotto non conserva dati né impostazioni. Non c’è nulla da rimuovere.» Quella frase fattuale è ciò che un’autorità può valutare.

Scheletro del documento

Una struttura che può copiare per la valutazione scritta:

VALUTAZIONE DEL RISCHIO DI CIBERSICUREZZA - [Prodotto, versione]

1. METODO
   Scale, formula, fasce di rischio, soglie di accettazione

2. CONTESTO DEL PRODOTTO
   Destinazione d’uso / Uso previsto e uso improprio prevedibile
   Ambiente operativo / Utenti
   Asset da proteggere
   Tempo di uso previsto
   Ambito: componenti inclusi, esclusioni con motivazione

3. ARCHITETTURA E SUPERFICIE DI ATTACCO
   Interfacce, flussi di dati, confini di fiducia
   (riferimento al diagramma)

4. REGISTRO DEI RISCHI
   Una voce per ogni minaccia credibile, valutata, con controllo,
   rischio residuo e stato

5. APPLICABILITÀ DEI REQUISITI DI SICUREZZA
   Una voce per requisito (tutti i 13), si applica sì/no,
   implementazione, riferimento all’evidenza, giustificazione dove
   non applicabile

6. BASE DI SICUREZZA FIN DALLA PROGETTAZIONE E COPERTURA DEI PROCESSI
   Come il livello di sicurezza complessivo del prodotto corrisponde
   ai suoi rischi, riferimenti ai processi di gestione delle vulnerabilità

7. RISCHIO RESIDUO E ACCETTAZIONE
   Riepilogo, criteri di accettazione, accettazione nominativa

8. APPROVAZIONE E MANUTENZIONE
   Proprietario, data di approvazione
   Fattori di aggiornamento
   Tabella dello storico delle revisioni

Aggiornamento della valutazione

La valutazione è un documento vivo per tutto il periodo di supporto. La riapra quando:

• arrivano nuove informazioni sulle vulnerabilità per il prodotto o i suoi componenti, dal suo monitoraggio, da segnalazioni di ricercatori o da avvisi dei fornitori
• il prodotto cambia, e sempre quando una modifica è abbastanza rilevante da richiedere una nuova valutazione della conformità
• i componenti cambiano, compresi nuovi fornitori e nuove versioni di componenti di terze parti o open source
• un incidente insegna qualcosa che le sue valutazioni non avevano previsto

Registri ogni revisione nella tabella dello storico, con cosa è cambiato e perché. Una valutazione datata una sola volta, tre anni fa, dice a un funzionario della vigilanza del mercato che il documento è decorativo.

Un obbligo di coerenza è facile da trascurare. La sua valutazione considera per quanto tempo ci si attende che il prodotto resti in uso. Il periodo di supporto che dichiara deve riflettere quel tempo d’uso atteso, ponderato rispetto ai propri fattori di legge. I due registri devono quindi coincidere. Se la sua valutazione prevede otto anni sul campo e il periodo di supporto dichiarato è cinque, riconsideri la determinazione alla luce di quei fattori. L’esito abituale è un periodo di supporto più lungo, non una nota a piè di pagina che spiega la discrepanza.

Chi la possiede, e come si inserisce nel suo flusso di lavoro

Il CRA rende responsabile il fabbricante. Non assegna ruoli interni né impone una metodologia di valutazione del rischio o un flusso di lavoro di team. Ma una valutazione che nessuno possiede invecchia, quindi i team che funzionano la suddividono all’incirca così:

• Proprietario del prodotto. Possiede il contesto: destinazione d’uso, uso prevedibile, tempo d’uso atteso. Decide cosa promette il prodotto, quindi firma quando la promessa cambia.
• Sviluppatori e architetti. Possiedono il quadro delle minacce: interfacce, flussi di dati, i controlli che trattano ciascun rischio e le evidenze che i controlli esistono.
• Responsabile della sicurezza, o chi ne ricopre il ruolo. Possiede il metodo, il registro, la scheda di applicabilità e l’approvazione. In un piccolo team può essere una sola persona con tre cappelli, e funziona lo stesso.

Poi colleghi i fattori di aggiornamento ai momenti in cui il lavoro avviene già, così che la valutazione non dipenda mai dal fatto che qualcuno se ne ricordi:

Le evidenze della pipeline provengono dagli strumenti che usa già: la generazione dello SBOM in CI/CD alimenta il registro dei componenti, e il suo processo di gestione delle vulnerabilità è ciò che riapre le voci al passo 4. Il CRA prescrive il risultato, una valutazione documentata mantenuta aggiornata, non il ciclo. Il ciclo è ciò che rende quell’obbligo sostenibile a fronte della pressione reale della consegna.

Componenti di terze parti

Il rischio del suo prodotto include i componenti al suo interno. Quando integra componenti di terze parti, compresi i componenti open source, deve esercitare la dovuta diligenza affinché non compromettano la sicurezza del prodotto. Nella valutazione, questo significa:

• i rischi dei componenti compaiono nel registro dove rilevanti, con lo SBOM come inventario di base
• il suo approccio di selezione e monitoraggio dei componenti è dichiarato, con riferimenti alle evidenze dei fornitori
• i percorsi di aggiornamento dei componenti fanno parte dell’analisi della capacità di aggiornamento

I meccanismi pratici, compreso un questionario per i fornitori, si trovano nella guida alla due diligence dei fornitori.

Dove vive la valutazione

La valutazione scritta fa parte del suo fascicolo tecnico, accanto alla documentazione di progettazione, alle evidenze di test e al registro della decisione sul periodo di supporto. Mantenga recuperabili la versione approvata, il suo storico delle revisioni e le evidenze a cui rimanda, per tutto il tempo in cui il fascicolo deve essere conservato. La guida alla documentazione tecnica mostra la struttura del fascicolo e dove si colloca ciascun artefatto.

Errori comuni

• Scritta a posteriori. Una valutazione prodotta nella settimana prima del rilascio non può aver orientato la progettazione. I revisori se ne accorgono.
• Nessuna decisione di applicabilità. Un registro dei rischi da solo non risponde alla domanda che pone il CRA. Ciascuno dei 13 requisiti richiede una risposta esplicita.
• «Non applicabile» senza giustificazione. Ogni esclusione richiede una motivazione scritta nel fascicolo.
• Metodo non documentato. Valutazioni senza scale, formule senza definizioni.
• Livello aziendale invece che di prodotto. Un registro dei rischi di un SGSI copre la sua organizzazione. Il CRA vuole questo prodotto.
• Congelata al rilascio. Nessuno storico delle revisioni, nessun fattore di aggiornamento, nessun collegamento al monitoraggio delle vulnerabilità.
• Incoerente con il periodo di supporto. Ipotesi di uso atteso che contraddicono la finestra di supporto dichiarata.
• Nessuna responsabilità nominativa. Nessuno l’ha approvata, nessuno accetta il rischio residuo, nessuno possiede gli aggiornamenti.