Guida alla preparazione per la segnalazione delle vulnerabilità prevista dal CRA UE 2026
Sono le 08:17 di un lunedì mattina di settembre 2026. Anna, CISO di una società SaaS europea in forte crescita, sta ancora ripensando alla riunione del consiglio di amministrazione della settimana precedente. Il CEO aveva posto la domanda che oggi ogni responsabile della sicurezza si sente fare: “Se ci siamo già preparati per NIS2 e i nostri clienti fintech continuano a chiederci evidenze DORA, che cosa cambia il Cyber Resilience Act?”
Poi la risposta arriva nella sua casella di posta.
Un ricercatore indipendente segnala una vulnerabilità sfruttabile da remoto in un componente di aggiornamento firmware usato da uno dei prodotti connessi dell’azienda. Il messaggio include un proof of concept, il nome di una dipendenza e l’avvertenza che sfruttamenti simili sono stati osservati in the wild.
Nel giro di pochi minuti, tutti chiedono una risposta diversa. Il CTO vuole sapere se la vulnerabilità è reale. La funzione legale chiede se sia stata attivata la segnalazione prevista dal Regolamento UE sulla ciberresilienza. Il gruppo di prodotto chiede quali versioni siano interessate. Il CISO chiede se la dipendenza compaia in qualche SBOM. La funzione vendite chiede se i clienti del settore finanziario abbiano bisogno di evidenze DORA. Il Responsabile della conformità apre il registro dei rischi ISO 27001 e trova un processo di gestione delle vulnerabilità, ma nessun percorso decisionale chiaro per la segnalazione di prodotto.
Questo è il vero problema della preparazione al CRA. La maggior parte delle organizzazioni non parte da zero. Dispone già di politiche di risposta agli incidenti, routine di gestione delle patch, pratiche di sviluppo sicuro, riesami dei fornitori, scanner di vulnerabilità ed evidenze ISO 27001. Ma il CRA non premia i documenti isolati. Richiede un flusso di lavoro rapido e difendibile, in grado di rispondere contemporaneamente a cinque domande:
- Si tratta di una vulnerabilità attivamente sfruttata o di un incidente grave che incide sulla sicurezza del prodotto?
- Quali prodotti, versioni, clienti, dipendenze e fornitori sono interessati?
- Quale autorità, cliente o destinatario contrattuale deve essere notificato, e quando?
- Quali evidenze dimostrano che triage, mitigazione e divulgazione sono stati governati?
- In che modo tutto questo è allineato a ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF e alle aspettative di audit?
La risposta non è una “cartella CRA” separata. La risposta è integrare la segnalazione delle vulnerabilità CRA nel SGSI, nel processo di divulgazione coordinata delle vulnerabilità, nella disciplina SBOM, nella governance dei fornitori e nella catena di evidenze della risposta agli incidenti che sono già necessari per una governance matura della cibersicurezza.
Perché il Regolamento UE sulla ciberresilienza cambia il modello di segnalazione
Il Regolamento UE sulla ciberresilienza, Regolamento (UE) 2024/2847, porta la sicurezza dei prodotti nel perimetro ordinario della conformità. Si applica ai prodotti con elementi digitali immessi sul mercato dell’UE, che possono includere dispositivi connessi, software, firmware, sistemi embedded e prodotti software enterprise.
Il cambiamento operativo più rilevante per CISO, responsabili della sicurezza di prodotto e funzioni di conformità decorre dall’11 settembre 2026. Il CRA Article 14 richiede segnalazioni per fasi per le vulnerabilità attivamente sfruttate e per gli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali. In termini pratici, i fabbricanti devono essere pronti per:
| Evento di segnalazione CRA | Tempistica attesa | Evidenze pratiche necessarie |
|---|---|---|
| Allerta precoce per vulnerabilità attivamente sfruttata | Entro 24 ore dal momento della conoscenza | Marcatura temporale della conoscenza, valutazione dello sfruttamento, ipotesi di prodotto interessato |
| Notifica più completa della vulnerabilità | Entro 72 ore dal momento della conoscenza | Gravità, prodotti interessati, stato della mitigazione, evidenze SBOM, piano correttivo iniziale |
| Relazione finale sulla vulnerabilità | Dopo che la misura correttiva o di mitigazione diventa disponibile | Causa radice, impatto, remediation, dettagli dell’aggiornamento di sicurezza, indicazioni per gli utenti |
| Allerta precoce per incidente grave che incide sulla sicurezza del prodotto | Entro 24 ore dal momento della conoscenza | Cronologia dell’incidente, impatto sul prodotto, impatto operativo, contenimento iniziale |
| Notifica più completa dell’incidente grave | Entro 72 ore dal momento della conoscenza | Analisi dell’impatto, utenti interessati, azioni correttive, registrazioni del coordinamento |
| Relazione finale sull’incidente grave | Entro un mese dalla notifica iniziale dell’incidente | Cronologia completa, causa, mitigazione, lezioni apprese, rischio residuo |
La valutazione giuridica puntuale deve sempre essere svolta da un consulente qualificato, ma la lezione operativa è chiara. Le prime 24-72 ore valgono solo quanto la preparazione completata nei mesi precedenti.
Se gli SBOM sono incompleti, se la casella CVD è monitorata in modo informale, se i contratti con i fornitori non richiedono la notifica delle vulnerabilità, o se la politica di risposta agli incidenti non distingue la segnalazione delle vulnerabilità di prodotto dagli incidenti privacy o operativi, l’orologio normativo correrà più veloce del processo di raccolta delle evidenze.
Usa ISO/IEC 27001:2022 come struttura portante per la preparazione al CRA
ISO/IEC 27001:2022 non sostituisce la conformità legale al CRA, ma è la migliore struttura di sistema di gestione per integrare gli obblighi CRA nella governance quotidiana.
Le clausole 4.1-4.4 richiedono all’organizzazione di comprendere contesto interno ed esterno, parti interessate, requisiti, interfacce con altre organizzazioni e campo di applicazione del SGSI ISO/IEC 27001:2022. Per la preparazione al CRA, ciò significa che il campo di applicazione del SGSI deve identificare prodotti con elementi digitali, responsabilità del ciclo di vita del prodotto, componenti ospitati, pipeline di build, dipendenze open source, fornitori, utenti, importatori, distributori, clienti regolamentati e autorità pertinenti.
Le clausole 6.1.1-6.1.3 richiedono valutazione del rischio e trattamento del rischio, inclusi proprietari del rischio, conseguenze, probabilità, decisioni di trattamento, Dichiarazione di Applicabilità e accettazione del rischio residuo. La segnalazione CRA deve essere trattata come uno scenario di rischio per la sicurezza di prodotto all’interno di tale processo, non come un esercizio emergenziale di interpretazione legale.
ISO/IEC 27002:2022 ISO/IEC 27002:2022 fornisce quindi la struttura pratica dei controlli. I controlli più importanti per la segnalazione delle vulnerabilità CRA sono:
| Controllo ISO/IEC 27002:2022 | Nome corretto del controllo | Ruolo nella preparazione al CRA |
|---|---|---|
| 8.8 | Gestione delle vulnerabilità tecniche | Identifica, valuta, prioritizza, tratta e traccia le vulnerabilità |
| 8.25 | Ciclo di vita dello sviluppo sicuro | Integra sicurezza di prodotto, riesame delle dipendenze e ingegneria sicura nello sviluppo |
| 5.21 | Gestione della sicurezza delle informazioni nella catena di fornitura ICT | Collega componenti dei fornitori, input SBOM e avvisi upstream al rischio di prodotto |
| 5.20 | Trattamento della sicurezza delle informazioni negli accordi con i fornitori | Trasforma gli obblighi dei fornitori in clausole contrattuali esigibili |
| 5.24 | Pianificazione e preparazione per la gestione degli incidenti di sicurezza delle informazioni | Definisce ruoli di gestione degli incidenti, playbook, escalation, segnalazione e gestione delle evidenze |
| 5.26 | Risposta agli incidenti di sicurezza delle informazioni | Supporta contenimento, eradicazione, ripristino e comunicazioni in modo controllato |
| 8.15 | Logging | Conserva le evidenze per la valutazione dello sfruttamento e la ricostruzione dell’incidente |
| 8.16 | Attività di monitoraggio | Rileva segnali di sfruttamento e supporta le decisioni sull’attivo sfruttamento |
In Zenith Controls: la guida alla conformità trasversale, Clarysec mappa il controllo ISO/IEC 27002:2022 8.8, Gestione delle vulnerabilità tecniche, come controllo preventivo a supporto di Riservatezza, Integrità e Disponibilità. I suoi attributi si allineano ai concetti di cibersicurezza Identify e Protect, con la gestione di minacce e vulnerabilità come capacità operativa.
Questa impostazione è importante. La segnalazione CRA non riguarda solo la notifica alle autorità. Riguarda la capacità di dimostrare che una capacità preventiva di gestione delle vulnerabilità esisteva prima dell’arrivo della segnalazione.
Costruire il modello operativo attorno a CVD, SBOM e all’orologio della segnalazione
Un flusso di lavoro credibile per le vulnerabilità CRA inizia prima che un ricercatore contatti l’organizzazione. Inizia dalla capacità di ricevere segnalazioni di vulnerabilità, convalidarle, identificare i componenti interessati, valutare lo sfruttamento, coordinare la mitigazione, comunicare con gli utenti e conservare le evidenze.
Il primo elemento è un canale pubblico di segnalazione delle vulnerabilità. La Politica di divulgazione coordinata delle vulnerabilità di Clarysec, clausola 6.1 dei Requisiti di applicazione, stabilisce:
Canali pubblici di divulgazione: l’organizzazione deve mantenere un canale chiaro per la segnalazione delle vulnerabilità, ad esempio un indirizzo e-mail dedicato per i contatti di sicurezza (per esempio, security@company.com) o un modulo web. Questa informazione deve essere pubblicata nella pagina di sicurezza del sito web aziendale insieme alla chiave pubblica PGP dell’organizzazione, per consentire invii cifrati.
Questo risolve un errore comune in sede di audit. Molte aziende dichiarano di accettare segnalazioni di vulnerabilità, ma il percorso di segnalazione è nascosto, non gestito o instradato attraverso una coda di supporto generica. In condizioni CRA, il canale di segnalazione diventa il punto di attivazione della conoscenza giuridicamente rilevante, della valutazione di gravità e dell’acquisizione delle evidenze.
Il secondo elemento è il triage. La Politica di divulgazione coordinata delle vulnerabilità, clausola 6.4 dei Requisiti di applicazione, stabilisce:
Triage e conferma di ricezione: al ricevimento di una segnalazione, il VRT deve registrarla e inviare una conferma di ricezione al segnalante entro 2 giorni lavorativi, assegnando un riferimento di tracciamento. Il VRT deve eseguire una valutazione preliminare della gravità, ad esempio utilizzando il punteggio CVSS, e convalidare la problematica, anche con il supporto dei team IT e di sviluppo ove necessario, entro un termine obiettivo di 5 giorni lavorativi. Le vulnerabilità critiche, ad esempio quelle che consentono l’esecuzione di codice da remoto o una grave violazione dei dati, devono essere accelerate.
Per la preparazione al CRA, tale registrazione di triage deve essere estesa con campi che supportino la decisione giuridica di segnalazione:
| Campo di triage CRA | Perché è importante | Titolare delle evidenze |
|---|---|---|
| Stato di sfruttamento attivo | Determina se possa applicarsi la segnalazione delle vulnerabilità CRA | Team di risposta alle vulnerabilità (VRT) |
| Prodotto e versione interessati | Collega la problematica ai prodotti con elementi digitali e all’impatto sui clienti | Sicurezza di prodotto |
| Corrispondenza della dipendenza SBOM | Conferma se i componenti interessati esistono nelle build rilasciate | Engineering o DevSecOps |
| Indicatore di incidente grave di prodotto | Separa il trattamento della vulnerabilità dalla segnalazione dell’incidente di sicurezza di prodotto | Operazioni di sicurezza |
| Decisione di notifica normativa | Registra se si applica un avviso CRA, NIS2, DORA, GDPR o contrattuale | Legale, CISO e Conformità |
Il terzo elemento è la disciplina SBOM. La Politica di sviluppo sicuro di Clarysec, clausola 5.4 dei Requisiti di governance, stabilisce:
L’utilizzo di codice open source o di terze parti deve essere approvato, tracciato e convalidato tramite: 5.4.1 Software Composition Analysis (SCA) 5.4.2 riesame delle licenze (GPL, MIT, BSD, ecc.) 5.4.3 scansione delle vulnerabilità note (CVE, OSS Index, ecc.)
Per le organizzazioni più piccole, la Politica sui requisiti di sicurezza delle applicazioni - PMI di Clarysec, clausola 6.4.2 dei Requisiti di applicazione della politica, stabilisce la stessa aspettativa in forma pratica:
Lo sviluppatore o il fornitore IT deve mantenere una registrazione di ciascun componente esterno utilizzato, includendo:
Tale registrazione dei componenti diventa il set minimo di evidenze per una risposta alle vulnerabilità guidata dagli SBOM. Deve collegare nome del componente, versione, fonte, fornitore o repository, licenza, versione del prodotto, data di build e stato della scansione delle vulnerabilità. Quando arriva una CVE, una segnalazione di un ricercatore o un avviso del fornitore, il gruppo deve poter rispondere entro poche ore: “Quali prodotti rilasciati contengono questo componente?”
Mappare CRA, NIS2, DORA e GDPR in un’unica matrice decisionale di notifica
Il Cyber Resilience Act non opererà in isolamento. Una singola vulnerabilità di prodotto può attivare la segnalazione CRA, la valutazione di incidente NIS2, obblighi di evidenza verso i clienti DORA, una valutazione di violazione dei dati personali ai sensi del GDPR e obblighi contrattuali di notifica.
Il NIS2 Article 21 richiede ai soggetti essenziali e importanti di attuare misure tecniche, operative e organizzative adeguate. Tali misure includono analisi dei rischi, trattamento degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione, sviluppo e manutenzione sicuri, trattamento e divulgazione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, crittografia, sicurezza del personale, controllo degli accessi, gestione degli asset, MFA e comunicazioni sicure.
Il NIS2 Article 23 definisce un modello di segnalazione degli incidenti per fasi: allerta precoce entro 24 ore dal momento in cui si viene a conoscenza dell’incidente, notifica dell’incidente entro 72 ore, aggiornamenti intermedi se richiesti e una relazione finale non oltre un mese dalla notifica dell’incidente. Il NIS2 Article 20 introduce inoltre la responsabilità dell’organo di gestione per l’approvazione e la supervisione delle misure di gestione dei rischi di cibersicurezza.
DORA si applica dal 17 gennaio 2025 e istituisce un quadro uniforme dell’UE per la resilienza operativa digitale delle entità finanziarie. Per fornitori SaaS, vendor software e fornitori ICT, DORA si manifesta spesso attraverso i contratti con i clienti. Il cliente del settore finanziario può essere l’entità regolamentata DORA, ma il trattamento delle vulnerabilità, le evidenze SBOM, il supporto agli incidenti, i diritti di audit e gli impegni di notifica del fornitore possono essere necessari affinché il cliente soddisfi i propri obblighi.
Il GDPR aggiunge un ulteriore ramo. Se la vulnerabilità o l’incidente provoca distruzione, perdita, alterazione, divulgazione non autorizzata o accesso non autorizzato a dati personali, in modo accidentale o illecito, è richiesta una valutazione della violazione dei dati personali. Il GDPR Article 5 include inoltre integrità, riservatezza e responsabilizzazione, il che significa che l’organizzazione deve poter dimostrare il proprio processo decisionale.
La Politica di risposta agli incidenti di Clarysec, clausola 6.4.1 dei Requisiti di applicazione della politica, supporta già questa valutazione multi-regime:
Se un incidente determina un’esposizione confermata o probabile di dati personali o di altri dati regolamentati, la funzione legale e il DPO devono valutare l’applicabilità di: 6.4.1.1 GDPR Article 33 (notifica entro 72 ore all’autorità di controllo) 6.4.1.2 GDPR Article 34 (notifica agli interessati, ove si applichi un rischio elevato) 6.4.1.3 NIS2 Article 23 (notifica entro 24 ore dal momento in cui si viene a conoscenza dell’incidente) 6.4.1.4 DORA Article 17 (segnalazione degli incidenti gravi connessi alle ICT)
Per la preparazione al CRA, estendere questo playbook includendo la valutazione della segnalazione ai sensi del CRA Article 14 per vulnerabilità attivamente sfruttate e incidenti gravi che incidono sulla sicurezza del prodotto.
Una matrice decisionale unificata evita che i gruppi eseguano playbook di segnalazione separati e incoerenti:
| Domanda di attivazione | CRA | NIS2 | DORA | GDPR | Evidenze |
|---|---|---|---|---|---|
| La vulnerabilità è attivamente sfruttata in un prodotto con elementi digitali? | Valutare la segnalazione ai sensi del CRA Article 14 | Può supportare la valutazione di incidente significativo | Può supportare la classificazione di incidente ICT o minaccia | Valutare se sono interessati dati personali | Registrazione di triage, threat intelligence, log |
| La sicurezza del prodotto o l’erogazione del servizio è stata gravemente compromessa? | Valutare la segnalazione di incidente grave | Valutare l’incidente significativo | Valutare l’impatto di incidente grave connesso alle ICT | Di norma solo se si è verificata una violazione dei dati personali | Cronologia dell’incidente, analisi dell’impatto |
| Sono interessati clienti del settore finanziario? | La segnalazione di prodotto può comunque applicarsi | Dipende dal campo di applicazione dell’entità | Il cliente può richiedere evidenze DORA | Dipende dai ruoli sui dati | Elenco clienti, contratti, allegato DORA |
| I dati personali sono stati esposti o consultati? | Può incidere su gravità e avviso agli utenti | Può incidere sulla valutazione dell’impatto | Può incidere sull’impatto sul cliente | Valutazione della violazione richiesta | Valutazione DPO, evidenze forensi |
| È coinvolto un componente di un fornitore? | Il fabbricante deve comunque avere visibilità sull’impatto sul prodotto | Evidenze del rischio della catena di fornitura | Possono essere necessarie evidenze di terze parti ICT | Analisi del responsabile o del titolare del trattamento | SBOM, avviso del fornitore, clausola contrattuale |
Per le PMI, la Politica di risposta agli incidenti - PMI di Clarysec, clausola 5.3.2 dei Requisiti di governance, esprime lo stesso principio in forma più semplice:
Le tempistiche di risposta, inclusi il ripristino dei dati e gli obblighi di notifica, devono essere documentate e allineate ai requisiti legali, come il requisito GDPR di notifica della violazione dei dati personali entro 72 ore.
La preparazione al CRA estende semplicemente tale principio dalla notifica delle violazioni dei dati personali alla segnalazione delle vulnerabilità di prodotto e degli incidenti di sicurezza di prodotto.
Le evidenze dei fornitori sono ora evidenze di sicurezza di prodotto
Molte vulnerabilità rilevanti ai fini CRA avranno origine al di fuori della codebase dell’organizzazione. Possono provenire da pacchetti open source, moduli firmware, SDK, API ospitate, strumenti di build, servizi cloud, componenti subappaltati o librerie upstream. Questo rende la governance dei fornitori centrale per la preparazione al CRA.
La clausola 8.1 di ISO 27001:2022 richiede alle organizzazioni di controllare processi, prodotti o servizi forniti dall’esterno rilevanti per il SGSI. Il controllo ISO/IEC 27002:2022 5.21, Gestione della sicurezza delle informazioni nella catena di fornitura ICT, fornisce l’ancoraggio di controllo.
In Zenith Controls, Clarysec mappa il controllo 5.21 come controllo preventivo a supporto di Riservatezza, Integrità e Disponibilità. La sua capacità operativa è la sicurezza delle relazioni con i fornitori, e i suoi domini includono governance, ecosistema e protezione. Il punto è semplice: i controlli sui fornitori non sono modulistica di approvvigionamento. Sono controlli di protezione dell’ecosistema.
La Politica di sicurezza delle terze parti e dei fornitori - PMI di Clarysec, clausola 5.3 dei Requisiti di governance, stabilisce la base contrattuale:
I contratti devono includere clausole obbligatorie che coprano:
Per i programmi enterprise, Zenith Blueprint: una roadmap in 30 passi per auditor, fase Controlli in azione, Step 23, controlli organizzativi da 5.19 a 5.37, spiega il controllo ISO/IEC 27002:2022 5.20, Trattamento della sicurezza delle informazioni negli accordi con i fornitori:
La fiducia, quando riguarda i fornitori, non può basarsi su presupposti. Deve essere codificata.
Per la preparazione al CRA, gli accordi con i fornitori devono includere clausole di sicurezza di prodotto che supportino una risposta rapida alle vulnerabilità:
| Clausola del fornitore | Rilevanza per il CRA | Evidenze da richiedere |
|---|---|---|
| Notifica delle vulnerabilità | Assicura che i fornitori upstream avvisino rapidamente quando un loro componente è interessato | Registrazioni degli avvisi di vulnerabilità del fornitore e SLA |
| SBOM o inventario dei componenti | Supporta la valutazione dell’impatto tra versioni di prodotto | SBOM, elenco componenti o attestazione |
| Supporto agli aggiornamenti sicuri | Abilita misure correttive e indicazioni per i clienti | Note di rilascio della patch e piano di rimedio |
| Coordinamento della divulgazione | Evita messaggi pubblici incoerenti e divulgazione prematura | Log di coordinamento CVD |
| Assistenza agli incidenti | Supporta analisi forense, valutazione dell’impatto sugli utenti e segnalazione | Registrazioni di supporto e note d’indagine |
| Diritti di audit e assurance | Aiuta a soddisfare clienti, autorità di regolamentazione e Internal Audit | Rapporti di audit e attestazioni di conformità dei controlli |
DORA rafforza la stessa direzione. Le entità finanziarie devono gestire il rischio ICT di terze parti, mantenere registri dei contratti di servizi ICT, valutare la criticità, svolgere due diligence, gestire il rischio di concentrazione, definire misure contrattuali di protezione, garantire diritti di audit e pianificare l’uscita. Se vendi software o servizi ICT a entità finanziarie, aspettati che i clienti chiedano se il tuo processo di segnalazione delle vulnerabilità e SBOM può supportare le loro esigenze DORA in materia di incidenti, resilienza ed evidenze di terze parti.
Il flusso di lavoro Clarysec per la preparazione al CRA
Clarysec aiuta i clienti a rendere operativa la segnalazione CRA all’interno di un SGSI allineato a ISO 27001:2022 tramite un flusso di lavoro pratico.
1. Aggiungere gli obblighi CRA al registro dei requisiti del SGSI
Partire dalle clausole 4.1-4.4 di ISO 27001:2022. Aggiornare contesto organizzativo, parti interessate e campo di applicazione per includere prodotti con elementi digitali, esposizione al mercato dell’UE, utenti, importatori, distributori, autorità di regolamentazione, CSIRT, fornitori e clienti regolamentati.
Creare voci nel registro dei requisiti per segnalazione delle vulnerabilità CRA, segnalazione CRA degli incidenti gravi di sicurezza di prodotto, notifica degli incidenti NIS2, obblighi di supporto ai clienti DORA, valutazione GDPR delle violazioni dei dati personali, avviso contrattuale di incidente, impegni CVD e comunicazioni con i ricercatori.
Questo fornisce agli auditor un percorso tracciabile dall’obbligo esterno al controllo interno.
2. Creare un modulo di intake per le vulnerabilità di prodotto
Basare il modulo di intake sulla Politica di divulgazione coordinata delle vulnerabilità. Deve acquisire identità del segnalante, recapiti sicuri, versione del prodotto, modulo, ambiente, proof of concept, passaggi di riproduzione, stato di sfruttamento, potenziale esposizione dei dati, impatto sul servizio, corrispondenza del componente SBOM, gravità CVSS o equivalente, proprietario, riferimento di tracciamento e checkpoint normativo.
Il modulo deve creare automaticamente un ticket nella coda di risposta alle vulnerabilità. Deve inoltre avviare un timer per la decisione di notifica, anche se la risposta finale è “non soggetto a segnalazione”.
3. Collegare i dati SBOM ai rilasci
Per ogni versione di prodotto rilasciata, mantenere un SBOM o un inventario equivalente dei componenti. Le evidenze minime utili includono nome del componente, versione, fonte, licenza, fornitore o repository, versione del prodotto, data di build e stato della scansione delle vulnerabilità.
La Politica di sviluppo sicuro e la Politica sui requisiti di sicurezza delle applicazioni - PMI forniscono la base di policy per SCA, riesame dei componenti e registrazioni dei componenti esterni.
4. Conservare le evidenze dal primo giorno
Ogni ticket di vulnerabilità rilevante per CRA deve conservare:
- Segnalazione originale
- Marcatura temporale della conferma di ricezione
- Note di triage
- Motivazione della gravità CVSS o equivalente
- Risultati della corrispondenza SBOM
- Valutazione dello sfruttamento
- Log, indicatori e snapshot forensi
- Comunicazioni con i fornitori
- Accettazione del rischio, se la mitigazione è ritardata
- Piano di patch, note di rilascio ed evidenze di test
- Decisioni di notifica a clienti e autorità
- Input per la relazione finale e lezioni apprese
Questo è allineato alla clausola 8.1 di ISO 27001:2022, che richiede informazioni documentate sufficienti a dimostrare che i processi abbiano operato come pianificato, e alle clausole 8.2 e 8.3, che richiedono risultati documentati di valutazione del rischio e trattamento del rischio.
5. Testare con uno scenario realistico su una dipendenza
Eseguire un’esercitazione tabletop utilizzando una vulnerabilità simulata, attivamente sfruttata, relativa a una dipendenza. Coinvolgere sviluppo, sicurezza, legale, privacy, prodotto, comunicazione, gestione dei fornitori e funzioni a contatto con i clienti. Il test deve dimostrare che l’organizzazione può identificare le versioni interessate, valutare lo sfruttamento, prendere una decisione di notifica, contattare i fornitori, predisporre indicazioni per gli utenti e conservare le evidenze.
Come gli auditor testeranno la preparazione alla segnalazione delle vulnerabilità CRA
Un riesame della preparazione al CRA raramente si limita a una checklist CRA. Auditor diversi testeranno le stesse evidenze attraverso quadri di riferimento diversi.
In Zenith Controls, Clarysec mappa il controllo ISO/IEC 27002:2022 5.24, Pianificazione e preparazione per la gestione degli incidenti di sicurezza delle informazioni, come controllo correttivo a supporto di Riservatezza, Integrità e Disponibilità. È allineato a Respond e Recover, con governance e gestione degli eventi di sicurezza delle informazioni come capacità operative.
Quel controllo è il ponte tra scoperta della vulnerabilità e segnalazione normativa.
| Profilo dell’auditor | Che cosa chiederà | Evidenze che soddisfano la domanda |
|---|---|---|
| Auditor ISO 27001:2022 | La segnalazione delle vulnerabilità è integrata in valutazione del rischio, trattamento, controlli dell’Annex A e processi SGSI documentati? | Campo di applicazione del SGSI, registro dei rischi, SoA, procedura sulle vulnerabilità, politica CVD, registrazioni degli incidenti, riesame della direzione |
| Valutatore dei controlli ISO/IEC 27002:2022 | I controlli 8.8, 8.25, 5.21, 5.24, 5.20 e i controlli correlati sono applicati in modo coerente? | Log delle patch, SBOM, gate SDLC sicuri, clausole dei fornitori, playbook degli incidenti, registrazioni delle evidenze |
| Autorità o valutatore NIS2 | Le procedure relative a governance dell’Article 20, misure dell’Article 21 e segnalazioni dell’Article 23 sono operative? | Verbali del consiglio di amministrazione, misure di rischio, procedure di incidente, registrazioni di notifica, evidenze della catena di fornitura |
| Auditor orientato a DORA | Incidenti ICT, vulnerabilità, dipendenze da terze parti, test e comunicazioni ai clienti possono supportare gli obblighi di resilienza del settore finanziario? | Inventario delle dipendenze ICT, classificazioni degli incidenti, registrazioni di test, registro dei fornitori, evidenze contrattuali |
| Revisore GDPR | L’organizzazione ha valutato se la vulnerabilità abbia creato una violazione dei dati personali e documentato la responsabilizzazione? | Valutazione della violazione, note del DPO, registrazione della decisione su Article 33 e 34, mappa dei flussi di dati, risultanze forensi |
| Valutatore NIST CSF 2.0 | L’organizzazione è in grado di governare, identificare, proteggere, rilevare, rispondere e ripristinare attraverso un unico modello basato sul rischio? | Current e Target Profiles, programma di rischio dei fornitori, metriche di rilevazione, evidenze di risposta e ripristino |
NIST CSF 2.0 è particolarmente utile come livello di comunicazione verso il consiglio di amministrazione. Le sue funzioni GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER aiutano a spiegare come la segnalazione delle vulnerabilità di prodotto rientri nella governance aziendale della cibersicurezza, anziché restare un’eccezione ingegneristica.
Errori comuni di preparazione al CRA da correggere prima del 2026
Clarysec osserva ripetutamente le stesse lacune.
La prima è CVD senza segnalazione. Un’azienda ha un indirizzo e-mail di sicurezza o un file security.txt, ma nessun percorso interno dalla segnalazione del ricercatore alla valutazione legale di notifica.
La seconda è SBOM senza titolarità. Lo sviluppo può generare un SBOM durante la build, ma nessuno è responsabile della sua accuratezza per i prodotti rilasciati o spiega come le risultanze SBOM alimentino la risposta alle vulnerabilità.
La terza è un certificato ISO senza campo di applicazione di prodotto. Il SGSI copre IT aziendale e operazioni SaaS, ma non software embedded, firmware, infrastruttura di aggiornamento dei prodotti, pipeline di build o divulgazione delle vulnerabilità.
La quarta sono contratti con i fornitori privi di clausole sulle vulnerabilità. L’approvvigionamento richiede riservatezza e protezione dei dati, ma non notifica delle vulnerabilità, trasparenza sui componenti, assistenza agli incidenti, divulgazione coordinata o evidenze di audit.
La quinta è risposta agli incidenti senza logica di vulnerabilità di prodotto. Il piano di incidente copre ransomware, phishing e violazioni dei dati personali, ma non vulnerabilità di prodotto attivamente sfruttate in cui i sistemi dei clienti possono essere a rischio prima che l’ambiente del fabbricante sia compromesso.
La sesta è la gestione manuale delle evidenze DORA verso i clienti. Vendite o gestione clienti rispondono caso per caso ai questionari del settore finanziario, mentre la sicurezza non dispone di un pacchetto standard di evidenze che mostri trattamento delle vulnerabilità, governance SBOM, supporto agli incidenti e controlli sui fornitori.
Ogni lacuna è risolvibile. Ognuna diventa costosa se viene scoperta durante una vulnerabilità reale.
Checklist di 90 giorni per la preparazione alla segnalazione delle vulnerabilità CRA
Utilizzare i prossimi 90 giorni per stabilire una base difendibile:
- Identificare i prodotti con elementi digitali immessi o resi disponibili sul mercato dell’UE.
- Aggiornare campo di applicazione del SGSI e analisi delle parti interessate per includere gli stakeholder CRA.
- Aggiungere la valutazione di segnalazione ai sensi del CRA Article 14 al registro dei requisiti legali e normativi.
- Pubblicare e monitorare un canale sicuro di segnalazione delle vulnerabilità.
- Creare un team di risposta alle vulnerabilità con ruoli legali, di prodotto, sviluppo, sicurezza e comunicazione.
- Mantenere SBOM o inventari dei componenti per le versioni di prodotto rilasciate.
- Collegare i risultati SCA ai ticket di vulnerabilità e ai rilasci di prodotto.
- Aggiungere criteri di sfruttamento attivo e di incidente grave di prodotto ai moduli di triage.
- Creare una matrice decisionale combinata per notifiche CRA, NIS2, DORA, GDPR e contrattuali.
- Aggiornare i contratti con i fornitori con clausole su notifica delle vulnerabilità, SBOM, assistenza agli incidenti e coordinamento della divulgazione.
- Mantenere log delle patch ed evidenze di remediation.
- Testare il flusso di lavoro con una vulnerabilità simulata, attivamente sfruttata, relativa a una dipendenza.
- Presentare i risultati alla direzione con lacune, rischi residui e responsabili della remediation.
- Aggiungere il pacchetto di evidenze ad Audit interno e riesame della direzione.
La Politica di gestione delle vulnerabilità e delle patch - PMI di Clarysec, clausola 6.2.1 dei Requisiti di applicazione della politica, supporta la base di monitoraggio:
La funzione IT deve monitorare le vulnerabilità utilizzando:
La stessa politica, clausola 5.4.1 dei Requisiti di governance, aggiunge la traccia di audit:
Deve essere mantenuto un registro delle patch e riesaminato durante gli audit e le attività di risposta agli incidenti
Quel registro delle patch può diventare uno degli artifact più importanti in una relazione finale CRA. Dimostra scoperta, prioritizzazione, remediation, test e chiusura.
Rendere settembre 2026 ordinario
Il miglior evento di segnalazione CRA non è facile perché la vulnerabilità è semplice. È facile perché l’organizzazione ha già provato il flusso di lavoro.
Prima di settembre 2026, Clarysec può aiutarti a trasformare la segnalazione delle vulnerabilità in un sistema pronto per audit, mappando il tuo attuale SGSI ISO 27001:2022, processo CVD, capacità SBOM, clausole dei fornitori e playbook di risposta agli incidenti rispetto alle aspettative di CRA, NIS2, DORA, GDPR e NIST CSF.
Inizia con una valutazione mirata della preparazione alla segnalazione delle vulnerabilità CRA. Clarysec riesaminerà le tue politiche, evidenze SBOM, contratti con i fornitori, ticket di vulnerabilità, playbook degli incidenti e traccia di audit. Poi useremo Zenith Blueprint e Zenith Controls per costruire una roadmap di remediation pratica, non un raccoglitore teorico di conformità.
Se utilizzi già le politiche Clarysec, le adatteremo alla segnalazione CRA. Se non le utilizzi, possiamo aiutarti ad applicare il set di politiche appropriato, includendo, ove opportuno, Politica di divulgazione coordinata delle vulnerabilità, Politica di sviluppo sicuro, Politica di risposta agli incidenti, Politica di gestione delle vulnerabilità e delle patch - PMI, Politica sui requisiti di sicurezza delle applicazioni - PMI e Politica di sicurezza delle terze parti e dei fornitori - PMI.
Settembre 2026 è abbastanza vicino da richiedere pianificazione e abbastanza lontano da consentire una preparazione disciplinata. Le organizzazioni che agiscono ora non si chiederanno “Chi è responsabile di questa vulnerabilità?” durante le prime 24 ore. Avranno già la risposta, le evidenze e il percorso di segnalazione.
Contatta Clarysec per pianificare una valutazione della preparazione alla segnalazione delle vulnerabilità CRA e trasformare la complessità normativa in un vantaggio difendibile per la sicurezza di prodotto.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
