Il Cyber Resilience Act introduce obblighi che coinvolgono numerosi ambiti dell’organizzazione: classificazione dei prodotti, valutazione dei rischi, gestione delle vulnerabilità, supply chain, documentazione, azioni correttive, responsabilità e monitoraggio.
Per una software house o per un produttore di dispositivi digitali la difficoltà consiste quindi anche nel trasformare requisiti regolatori e attività tecniche in un processo di governance strutturato.
Compet-e sta sviluppando un modulo C*RA dedicato specificamente al Cyber Resilience Act, con l’obiettivo di guidare in maniera ancora più verticale l’intero percorso di adeguamento.
Già oggi, tuttavia, numerose funzionalità presenti nella piattaforma permettono di gestire una parte significativa degli elementi organizzativi e documentali richiesti dal CRA.
Dalla mappatura dei prodotti alla valutazione dell’applicabilità
Il primo passaggio del percorso CRA consiste nel comprendere quali prodotti rientrino effettivamente nel perimetro del Regolamento.
Per le organizzazioni che commercializzano più prodotti questo richiede una mappatura strutturata.
Nome del prodotto, versione, caratteristiche, componenti, modalità di distribuzione, connessioni, servizi remoti associati e responsabilità devono poter essere mantenuti sotto controllo.
Le funzionalità anagrafiche e di mappatura già presenti in C*RA permettono di organizzare queste informazioni e collegarle ai processi aziendali, agli owner e alla documentazione pertinente.
Questo crea una base informativa utile per le successive attività di classificazione e gap analysis.
Il modulo CRA attualmente in sviluppo permetterà di rendere questo percorso ancora più specifico rispetto ai criteri previsti dal Regolamento.
Il risk assessment come elemento centrale
Il CRA richiede che il fabbricante effettui e documenti una valutazione dei rischi di cybersecurity del prodotto e che tale valutazione venga utilizzata durante tutto il suo ciclo di vita.
Questo principio è molto vicino alla logica con cui C*RA gestisce già il Risk Management.
La piattaforma consente di strutturare valutazioni del rischio, associare minacce, vulnerabilità, asset e processi, definire misure di trattamento e mantenere monitorato nel tempo il livello di esposizione.
In un percorso CRA queste funzionalità possono quindi supportare la costruzione e la gestione della componente di governance del cybersecurity risk assessment.
La valutazione tecnica del prodotto continuerà naturalmente a richiedere strumenti e competenze specifiche di secure development, vulnerability assessment e testing. C*RA interviene come livello di governo: raccoglie le risultanze, le collega ai rischi, assegna le azioni e ne monitora l’evoluzione.
Requisiti CRA, controlli ed evidenze
Uno dei problemi tipici dei percorsi di conformità è dimostrare come ogni requisito venga effettivamente soddisfatto.
Il CRA richiede una quantità rilevante di documentazione tecnica e organizzativa.
Attraverso C*RA è possibile associare requisiti, controlli, procedure ed evidenze, creando un collegamento diretto tra ciò che la normativa richiede e ciò che l’organizzazione ha implementato.
Un requisito relativo alla gestione delle vulnerabilità, ad esempio, può essere collegato alla procedura applicabile, al responsabile, alle attività periodiche svolte e alle evidenze raccolte.
Eventuali carenze possono essere trasformate in azioni di adeguamento, assegnate a un owner e monitorate attraverso scadenze e workflow.
Questo approccio rende la gap analysis un processo dinamico, evitando che rimanga confinata in un documento prodotto una sola volta.
Secure-by-design: governare anche ciò che avviene nello sviluppo
Molti requisiti del CRA hanno natura profondamente tecnica.
Secure coding, gestione delle dipendenze, test di sicurezza, hardening e verifica delle vulnerabilità richiedono strumenti e processi propri del ciclo di sviluppo software.
Una piattaforma GRC non sostituisce queste attività.
Può però svolgere un ruolo fondamentale nel documentarne l’esistenza e verificarne la continuità.
In C*RA è possibile censire controlli e procedure adottate, assegnare responsabilità, raccogliere evidenze e collegare eventuali anomalie ai rischi e ai piani di trattamento.
Il risultato è una maggiore tracciabilità tra il requisito CRA e il processo tecnico attraverso cui viene effettivamente soddisfatto.
Vulnerability management: dal problema tecnico alla decisione
Uno dei pilastri del Cyber Resilience Act è la gestione delle vulnerabilità durante il periodo di supporto del prodotto.
Il processo comprende identificazione, valutazione, remediation, aggiornamento e, nei casi previsti, segnalazione.
C*RA può fungere da punto di raccordo tra questi elementi.
Una vulnerabilità individuata attraverso strumenti tecnici o attività di VAPT può essere collegata all’asset o al prodotto interessato, al rischio, alle misure correttive e ai responsabili.
La remediation può quindi essere gestita tramite azioni, scadenze e workflow, mantenendo traccia dell’intero percorso.
Questa impostazione acquista particolare importanza con le tempistiche di segnalazione previste dal CRA, che dal settembre 2026 impongono alle organizzazioni di essere in grado di reagire rapidamente alle vulnerabilità attivamente sfruttate e agli incidenti gravi.
Componenti software e supply chain
Un prodotto digitale raramente nasce interamente all’interno dell’organizzazione.
Librerie, componenti open source, servizi di terze parti e fornitori tecnologici contribuiscono alla sua costruzione e possono diventare una fonte di rischio.
Il CRA attribuisce grande importanza proprio alla gestione delle componenti e delle vulnerabilità che possono derivarne.
Le funzionalità di Third Party Evaluation già disponibili in C*RA possono supportare la valutazione dei fornitori e la raccolta strutturata di evidenze attraverso questionari personalizzabili.
Le informazioni provenienti dalla supply chain possono così essere collegate alla valutazione del rischio e alle eventuali azioni di adeguamento.
Anche lo SBOM – Software Bill of Materials assume un ruolo importante nella gestione della composizione del prodotto. C*RA può supportare la governance e la verifica delle evidenze relative allo SBOM; la sua generazione tecnica resta invece affidata agli strumenti utilizzati nel ciclo di sviluppo.
Incidenti, vulnerabilità e obblighi di reporting
Il CRA rende particolarmente importante la capacità di ricostruire rapidamente cosa sia accaduto, quale prodotto sia coinvolto, chi debba intervenire e quali azioni siano state intraprese.
Le funzionalità di workflow e gestione delle attività di C*RA consentono di assegnare responsabilità, monitorare le azioni e mantenere le evidenze relative agli eventi.
Questo aiuta l’organizzazione a costruire un processo di escalation coerente con le tempistiche previste dal Regolamento.
La piattaforma non sostituisce i canali ufficiali di notifica verso CSIRT ed ENISA, ma può supportare la raccolta e il governo delle informazioni necessarie alla segnalazione.
Documentazione e fascicolo tecnico
Il percorso CRA produce nel tempo una quantità significativa di documentazione.
Risk assessment, descrizione del prodotto, processi di sviluppo, evidenze di test, vulnerability management, informazioni sui componenti, procedure, istruzioni e documentazione relativa alla conformità devono rimanere coerenti e aggiornati.
C*RA può diventare il punto di raccolta e organizzazione di queste informazioni, collegando i documenti agli elementi della governance a cui fanno riferimento.
La costruzione del fascicolo tecnico diventa quindi più semplice perché le evidenze non vengono raccolte soltanto alla fine del percorso, ma vengono prodotte e storicizzate durante l’attività ordinaria.
Un approccio multi-compliance
Il CRA presenta numerosi punti di contatto con altri framework già gestiti dalle organizzazioni.
Una valutazione del rischio svolta ai fini CRA può utilizzare elementi già presenti nel sistema ISO 27001.
La valutazione di un fornitore può essere significativa anche ai fini NIS2.
Un incidente può interessare contemporaneamente più framework.
Un prodotto basato sull’intelligenza artificiale può entrare sia nel perimetro CRA sia in quello AI Act.
La struttura multi-compliance di C*RA permette di riutilizzare processi, rischi, controlli, fornitori ed evidenze nei diversi ambiti, riducendo le duplicazioni e mantenendo maggiore coerenza tra i sistemi di gestione.
È proprio su questa logica che si sta sviluppando il nuovo modulo dedicato al Cyber Resilience Act.
Dal supporto attuale al futuro modulo CRA
Oggi C*RA offre già gli strumenti necessari per governare una parte importante del percorso: risk assessment, processi, controlli, documentazione, supply chain, azioni, workflow, evidenze, reporting e storicizzazione.
Il futuro modulo CRA aggiungerà una struttura specificamente costruita sul Regolamento (UE) 2024/2847, permettendo di guidare in maniera ancora più puntuale la classificazione dei prodotti, la gap analysis e il monitoraggio della conformità.
L’obiettivo rimane lo stesso che caratterizza l’intera suite: trasformare un nuovo obbligo normativo in un processo governabile, collegato agli altri sistemi di compliance e capace di evolvere insieme al prodotto.
👉 Il modulo CRA di C*RA è in fase di sviluppo. Nel frattempo, molte delle attività necessarie per prepararsi al Regolamento possono già essere organizzate e monitorate attraverso le funzionalità presenti nella piattaforma.
Partecipa al nostro prossimo webinar dedicato al CRA – https://meet.zoho.eu/nmgu-ilm-ygm