Cyber Resilience Act: obbligo di segnalazione dal 11 settembre 2026

Premessa

In premessa va detto che il regolamento (UE) 2024/2847 del Parlamento europeo e del Consiglio, relativo a requisiti orizzontali di cibersicurezza per i prodotti con elementi digitali — comunemente noto come “Cyber Resilience Act” o “CRA” — ha una struttura applicativa scaglionata, che colloca l’entrata in funzione degli obblighi di segnalazione in anticipo rispetto alla piena applicabilità dei requisiti sostanziali di prodotto. Trattasi di una scelta legislativa non neutrale: il legislatore europeo ha ritenuto prioritario attivare, prima di ogni altra cosa, il flusso informativo verso le autorità nazionali e verso l’Agenzia dell’Unione europea per la cibersicurezza (ENISA) in ordine alle vulnerabilità attivamente sfruttate e agli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali immessi sul mercato dell’Unione.

Il documento oggetto del presente approfondimento è un factsheet pubblicato da ENISA e dedicato alla “CRA Single Reporting Platform” (SRP), ossia alla piattaforma unica di segnalazione prevista dall’articolo 16 del CRA. Il factsheet — di natura divulgativa e non normativa — indica la data dell’11 settembre 2026 come momento a partire dal quale i fabbricanti sono tenuti a segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi, e a partire dal quale il medesimo obbligo grava sui gestori di software libero e open source nella misura in cui essi siano coinvolti nello sviluppo di prodotti con elementi digitali. Il documento descrive la piattaforma come “an online tool for manufacturers and open-source software stewards to meet the obligation to report actively exploited vulnerabilities and severe incidents”, precisando che si tratta di “an electronic system to report only once to communicate to all relevant authorities”.

Le disposizioni richiamate dal factsheet sono, in particolare, l’articolo 3, punto 42, del CRA per la definizione di vulnerabilità attivamente sfruttata; l’articolo 3, punto 44, per la nozione di incidente grave; l’articolo 14, paragrafo 5, per i criteri di gravità; l’articolo 14, paragrafo 7, per l’individuazione del CSIRT nazionale destinatario; l’articolo 16, paragrafo 2, per il differimento della diffusione delle informazioni in circostanze eccezionali, con l’ulteriore specificazione — sempre secondo quanto riportato dalla fonte — recata dal regolamento delegato (UE) 2026/881.

La rilevanza dell’atto per il pubblico dei DPO, dei giuristi d’impresa e dei responsabili compliance non è immediatamente intuitiva, poiché il CRA non è una normativa di protezione dei dati personali. Si ritiene, tuttavia, che il tema sia di stretto interesse per almeno tre ragioni. La prima è che un numero considerevole di imprese italiane — dall’industria manifatturiera con componenti connesse, ai produttori di software gestionale, agli sviluppatori di applicazioni e dispositivi IoT — rientra nella nozione di fabbricante di prodotti con elementi digitali, spesso senza averne piena consapevolezza. La seconda è che gli eventi da segnalare al CSIRT ai sensi del CRA si sovrappongono con frequenza a eventi qualificabili come violazione di dati personali ai sensi dell’articolo 4, punto 12, del GDPR, ovvero come incidente significativo ai sensi della direttiva (UE) 2022/2555 (NIS2) e del decreto legislativo 4 settembre 2024, n. 138. La terza è che la gestione dei termini brevissimi — ventiquattro ore per l’allerta precoce — richiede procedure interne, matrici di responsabilità e presidi documentali che intersecano inevitabilmente il perimetro di attività del DPO e delle funzioni di controllo.

Il documento ENISA e la sua collocazione nel sistema del Cyber Resilience Act

Il factsheet in esame è un documento di sintesi, strutturato per rispondere a domande elementari: che cos’è la piattaforma, a chi si rivolge, quali eventi vanno segnalati, entro quali termini, a quale CSIRT, cosa accade dopo la trasmissione. Non ha valore interpretativo vincolante e non si sostituisce né al testo del regolamento né alla guidance della Commissione europea, alla quale il documento stesso rinvia per gli aspetti di dettaglio, segnalando che la sezione 9.1 della guida della Commissione sul CRA contiene ulteriori chiarimenti in materia di obblighi di segnalazione. ENISA indica come punto di accesso informativo la pagina dedicata alle FAQ sulla SRP, raggiungibile all’indirizzo https://www.enisa.europa.eu/cra-srp, e un canale di assistenza dedicato all’indirizzo di posta elettronica cra-srp-helpdesk@enisa.europa.eu.

Appare chiaro allo scrivente che il valore pratico del documento risieda non tanto nel contenuto informativo — in larga parte ricavabile dalla lettura del regolamento — quanto nella conferma operativa di due elementi. Il primo è la conferma della data di decorrenza: l’11 settembre 2026 non è una scadenza ipotetica soggetta a rinvii tecnici, ma il termine attorno al quale l’Agenzia sta costruendo l’infrastruttura di raccolta. Il secondo è la conferma dell’architettura “single reporting”: una sola trasmissione, effettuata attraverso un sistema elettronico unico, con successiva diffusione automatica verso gli altri destinatari istituzionali. In termini più pragmatici, il fabbricante non deve moltiplicare le comunicazioni verso i ventisette CSIRT nazionali, ma deve individuare correttamente il CSIRT di riferimento e trasmettere una volta sola, lasciando che la piattaforma esegua la distribuzione.

Il flusso di utilizzo descritto dal factsheet è articolato in tre passaggi: accesso autenticato, selezione del CSIRT nazionale, compilazione e invio delle informazioni. Si tratta, in apparenza, di una sequenza banale. Nella prospettiva del practitioner, tuttavia, ciascuno dei tre passaggi presuppone attività preparatorie da svolgere prima dell’evento: la registrazione e la gestione delle credenziali, la determinazione a priori del CSIRT competente in base al criterio del luogo di stabilimento principale, la predisposizione di modelli informativi coerenti con i campi richiesti. Chi affronta la compilazione per la prima volta durante la gestione di un incidente in corso, con un termine di ventiquattro ore, si trova nella condizione meno favorevole possibile.

Il quadro normativo di riferimento

La disciplina europea: il regolamento (UE) 2024/2847

Il CRA è un regolamento di armonizzazione fondato sulla logica della legislazione di prodotto: introduce requisiti essenziali di cibersicurezza, obblighi degli operatori economici lungo la catena di distribuzione, procedure di valutazione della conformità, marcatura CE e vigilanza del mercato. L’ambito di applicazione ruota attorno alla nozione di “prodotto con elementi digitali”, che comprende i prodotti software e hardware e le loro soluzioni di elaborazione dati a distanza, connessi direttamente o indirettamente a un dispositivo o a una rete.

In sostanza, il regolamento estende ai prodotti digitali la logica che il diritto dell’Unione applica da decenni alla sicurezza delle macchine, dei giocattoli o dei dispositivi elettrici: chi immette sul mercato deve garantire la conformità a requisiti essenziali, deve documentarla, deve mantenerla nel tempo. In termini più concreti, l’allegato I del CRA distingue tra requisiti relativi alle proprietà di cibersicurezza del prodotto — configurazione sicura di default, protezione dell’integrità e della riservatezza dei dati, minimizzazione delle superfici di attacco, aggiornamenti sicuri — e requisiti relativi alla gestione delle vulnerabilità, che includono l’identificazione e la documentazione dei componenti, con predisposizione di una distinta base del software (la cosiddetta “software bill of materials”), la messa a disposizione tempestiva di aggiornamenti di sicurezza e l’adozione di una politica di divulgazione coordinata delle vulnerabilità.

L’obbligo di segnalazione, collocato all’articolo 14, non è dunque un adempimento isolato, ma la proiezione esterna del processo interno di gestione delle vulnerabilità richiesto dall’allegato I. Si ritiene che questa lettura sistematica sia essenziale: un fabbricante che non abbia strutturato un processo di vulnerability management difficilmente sarà in condizione di rispettare i termini dell’articolo 14, perché non disporrà né delle informazioni tecniche né dei presidi organizzativi necessari a riconoscere e qualificare l’evento.

La decorrenza dell’11 settembre 2026 e l’applicazione scaglionata

Il regolamento è entrato in vigore nel dicembre 2024 e prevede un’applicazione differita e frazionata. Gli obblighi di segnalazione di cui all’articolo 14 si applicano a decorrere dall’11 settembre 2026, mentre il corpo principale delle disposizioni — requisiti essenziali, valutazione della conformità, marcatura — diviene applicabile a decorrere dall’11 dicembre 2027; le disposizioni relative alla notifica degli organismi di valutazione della conformità hanno una decorrenza anticipata rispetto a quest’ultima data.

Va detto che questa asimmetria produce, nel periodo intermedio, una situazione peculiare e non priva di attriti concettuali: dall’11 settembre 2026 il fabbricante è tenuto a segnalare vulnerabilità attivamente sfruttate e incidenti gravi relativi a prodotti che non sono ancora soggetti ai requisiti essenziali dell’allegato I e che, in molti casi, sono stati progettati e immessi sul mercato prima dell’entrata in vigore del regolamento. Secondo il parere di chi scrive, ne deriva che nel periodo compreso tra settembre 2026 e dicembre 2027 l’obbligo di segnalazione opera come obbligo autonomo, di natura essenzialmente informativa e di vigilanza, sganciato dal giudizio di conformità del prodotto. Ciò non attenua l’obbligo, ma ne circoscrive gli effetti: la segnalazione, in questa fase, non equivale a una confessione di non conformità ai requisiti essenziali, che non sono ancora applicabili.

Resta aperta — e non si ha evidenza di chiarimenti definitivi sul punto nei documenti richiamati dal factsheet — la questione del trattamento dei prodotti immessi sul mercato prima delle rispettive decorrenze e successivamente interessati da modifiche sostanziali. Si suggerisce, in via prudenziale, di considerare l’obbligo di segnalazione come riferito a tutti i prodotti con elementi digitali disponibili sul mercato dell’Unione al momento dell’evento, indipendentemente dalla data di prima immissione, salvo diversa e più circoscritta indicazione delle autorità competenti.

Il raccordo con la direttiva NIS2 e con il quadro nazionale

La struttura temporale della segnalazione CRA — allerta precoce entro ventiquattro ore, notifica entro settantadue ore, relazione finale — riproduce consapevolmente lo schema dell’articolo 23 della direttiva (UE) 2022/2555, recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138. La simmetria è funzionale: consente ai CSIRT nazionali di operare con procedure omogenee e consente ai soggetti obbligati di riutilizzare, almeno in parte, i medesimi processi interni.

Va però evidenziato che i due regimi hanno oggetto e presupposti diversi. La NIS2 impone obblighi a soggetti qualificati come essenziali o importanti in ragione del settore di attività e delle dimensioni, e riguarda incidenti significativi che incidono sulla fornitura dei servizi del soggetto notificante. Il CRA impone obblighi a fabbricanti in quanto tali, indipendentemente dal settore e dalla dimensione — con talune modulazioni per le microimprese e le piccole imprese quanto alla proporzionalità degli oneri documentali — e riguarda eventi che incidono sulla sicurezza del prodotto immesso sul mercato. In termini più pragmatici, un’impresa manifatturiera di medie dimensioni, non rientrante nel perimetro NIS2 come soggetto essenziale o importante, può essere pienamente soggetta agli obblighi di segnalazione del CRA per il software embedded nei propri prodotti.

Nel contesto italiano, il CSIRT Italia è collocato presso l’Agenzia per la cybersicurezza nazionale e opera come punto di contatto per le notifiche NIS2 e, in forza della legge 28 giugno 2024, n. 90, per le segnalazioni dei soggetti pubblici ivi indicati, con i noti termini di ventiquattro e settantadue ore. Ne consegue che, per un fabbricante italiano che sia anche soggetto NIS2, il medesimo interlocutore istituzionale riceverà segnalazioni fondate su titoli giuridici distinti, con perimetri di rilevanza differenti. Si ritiene che ciò renda opportuna la costruzione di un registro unico degli eventi con classificazione multipla del titolo di notifica, per evitare tanto la duplicazione inutile quanto l’omissione.

La Legge 17 marzo 2026 n. 36 ha individuato l’ACN in Italia come l’Autorità preposta alla vigilanza per l’applicazione del CRA, tramite il raccordo con il CSIRT Italia.

Il rapporto con il GDPR e con gli altri regimi settoriali

Per quanto di stretto interesse in questa sede, occorre chiarire che la segnalazione ai sensi dell’articolo 14 del CRA non assorbe né sostituisce la notificazione della violazione di dati personali ai sensi degli articoli 33 e 34 del GDPR. I due obblighi hanno presupposti oggettivi diversi: il CRA guarda alla sicurezza del prodotto e alla presenza di uno sfruttamento attivo di una vulnerabilità o di un incidente con impatto grave su disponibilità, autenticità, integrità o riservatezza; il GDPR guarda alla violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso a dati personali trasmessi, conservati o comunque trattati.

Un medesimo fatto storico può integrare entrambi i presupposti. Si pensi allo sfruttamento attivo di una vulnerabilità in un componente software di un dispositivo medico connesso, che consenta l’accesso non autorizzato a dati relativi alla salute: il fabbricante dovrà valutare la segnalazione al CSIRT ai sensi del CRA e, ove sia titolare del trattamento, dovrà valutare la notificazione al Garante per la protezione dei dati personali ai sensi dell’articolo 33 e l’eventuale comunicazione agli interessati ai sensi dell’articolo 34, ovvero, ove operi come responsabile ai sensi dell’articolo 28 del GDPR, dovrà assistere il titolare. Va aggiunto che il termine di settantadue ore del GDPR decorre dal momento in cui il titolare viene a conoscenza della violazione, mentre il termine di ventiquattro ore del CRA decorre dalla conoscenza dello sfruttamento attivo o dell’incidente grave: le due decorrenze possono non coincidere.

Analoga logica di coordinamento — e non di assorbimento — vale rispetto ad altri regimi: il regolamento (UE) 2022/2554 (DORA) per gli incidenti connessi alle tecnologie dell’informazione e della comunicazione nel settore finanziario; il regolamento (UE) 2017/745 e il regolamento (UE) 2017/746 quanto alla vigilanza sui dispositivi medici e diagnostici in vitro; le discipline settoriali in materia di aeronautica e autoveicoli. Il CRA contiene clausole di coordinamento e di esclusione per taluni settori regolati; la verifica dell’applicabilità va condotta caso per caso e non può essere risolta con formule generali.

Merita segnalazione, sul versante della gestione delle vulnerabilità, l’esistenza della banca dati europea delle vulnerabilità istituita in attuazione della direttiva NIS2 e gestita da ENISA, che si affianca ai repertori internazionali. Si ritiene che la coesistenza tra segnalazione riservata al CSIRT ai sensi del CRA e pubblicazione informativa in banche dati costituisca uno dei nodi di maggiore delicatezza pratica, sul quale si tornerà nella sezione dedicata ai profili critici.

I soggetti obbligati: fabbricanti e gestori di software libero e open source

Il factsheet individua due categorie di destinatari: i fabbricanti e i gestori di software libero e open source (open-source software stewards). La distinzione merita un chiarimento incrementale.

Il fabbricante è, nella logica della legislazione di prodotto, il soggetto che fabbrica un prodotto con elementi digitali, ovvero che lo fa progettare o fabbricare e lo commercializza con il proprio nome o marchio, a titolo oneroso o gratuito. In sostanza, non conta chi materialmente scrive il codice o assembla l’hardware, ma chi assume verso il mercato la paternità commerciale del prodotto. In termini più pragmatici, l’impresa italiana che commissiona a un fornitore terzo lo sviluppo di un’applicazione e la distribuisce con il proprio marchio è fabbricante ai fini del CRA, con tutti gli obblighi che ne derivano, ivi compresi quelli di segnalazione; il fornitore che ha sviluppato il software su specifica altrui non è, per ciò solo, fabbricante di quel prodotto.

Il gestore di software libero e open source è una figura di nuova introduzione, pensata dal legislatore per intercettare quei soggetti — tipicamente fondazioni e organizzazioni senza scopo di lucro — che forniscono in modo sistematico e continuativo supporto allo sviluppo di software libero destinato a essere utilizzato in attività commerciali, senza però immettere essi stessi il prodotto sul mercato. Il regime a loro applicabile è deliberatamente alleggerito e proporzionato: il CRA prevede per tali soggetti obblighi attenuati, incentrati sull’adozione di una politica di cibersicurezza e sulla cooperazione con le autorità di vigilanza. Il factsheet, coerentemente, precisa che il CRA richiede ai gestori di segnalare gli eventi “to the extent that they are involved in the development of products with digital elements”.

Va detto che il singolo sviluppatore che contribuisce a un progetto open source al di fuori di un’attività commerciale non è, in linea di principio, destinatario degli obblighi del CRA. Si suggerisce comunque alle imprese che utilizzano componenti open source nei propri prodotti di non confidare nella traslazione degli obblighi verso la comunità di sviluppo: il fabbricante che integra un componente di terzi nel proprio prodotto resta responsabile della sicurezza del prodotto nel suo complesso e, di conseguenza, resta il soggetto obbligato alla segnalazione quando la vulnerabilità attivamente sfruttata risieda nel componente integrato.

Occorre inoltre ricordare che il CRA, come tutta la legislazione di prodotto dell’Unione, opera con un criterio di collegamento fondato sulla disponibilità del prodotto sul mercato dell’Unione, e non sulla nazionalità o sulla sede del fabbricante. I fabbricanti stabiliti in Paesi terzi che rendono disponibili prodotti sul mercato europeo sono soggetti al regolamento e possono designare un rappresentante autorizzato con mandato scritto; importatori e distributori sono a loro volta gravati di obblighi di verifica e di informazione. Nella prospettiva di un’impresa italiana che importi e distribuisca prodotti con elementi digitali fabbricati altrove, si ritiene essenziale verificare contrattualmente l’esistenza di canali di comunicazione rapida con il fabbricante, poiché la conoscenza di una vulnerabilità sfruttata attivamente può maturare in capo al distributore prima che in capo al fabbricante.

L’oggetto della segnalazione: vulnerabilità attivamente sfruttate e incidenti gravi

Il factsheet identifica due tipologie di eventi soggetti a segnalazione, con ancoraggio definitorio preciso.

La prima tipologia è quella delle vulnerabilità attivamente sfruttate, descritte come “Vulnerabilities in products with digital elements that are known to be currently exploited by a malicious actor”, con richiamo all’articolo 3, punto 42, del CRA. In sostanza, non è la vulnerabilità in sé a generare l’obbligo, ma la circostanza — nota al fabbricante — che essa sia oggetto di sfruttamento attuale da parte di un attore malevolo. La distinzione è di rilievo pratico: un fabbricante che scopra, attraverso un’attività interna di ricerca o attraverso una segnalazione di un ricercatore indipendente, una vulnerabilità grave ma non sfruttata, non è tenuto alla segnalazione ai sensi dell’articolo 14, pur essendo tenuto — nel regime pieno applicabile dal dicembre 2027 — a porvi rimedio secondo il processo di gestione delle vulnerabilità di cui all’allegato I. In termini più concreti, l’elemento che innesca l’obbligo è l’evidenza dello sfruttamento: la presenza di indicatori di compromissione, la disponibilità pubblica di codice di exploit effettivamente impiegato, le segnalazioni di clienti compromessi, le informazioni ricevute da CSIRT o da fornitori di threat intelligence.

La seconda tipologia è quella degli incidenti gravi, descritti come incidenti che hanno un impatto severo sulla sicurezza del prodotto con elementi digitali, con esemplificazione riferita alla compromissione di disponibilità, autenticità, integrità o riservatezza, e con richiamo all’articolo 3, punto 44, del CRA per la definizione e all’articolo 14, paragrafo 5, per i criteri di gravità. Si ritiene che la lettura combinata delle due disposizioni sia indispensabile: la definizione fissa il tipo di evento, i criteri di gravità ne delimitano la soglia di rilevanza. In assenza di un’analisi preventiva di tali criteri, calibrata sulle caratteristiche del prodotto e sulla base installata, la valutazione dovrebbe essere condotta sotto pressione temporale, con esito facilmente incoerente.

E’ opinione dello scrivente che il punto di maggiore difficoltà applicativa consista nella qualificazione dell’evento come incidente “che ha un impatto grave sulla sicurezza del prodotto”. La formulazione impone una valutazione tecnica che non coincide con la valutazione di impatto sull’organizzazione del fabbricante: un incidente che comprometta gravemente la sicurezza del prodotto presso gli utilizzatori può avere effetti trascurabili sull’infrastruttura del fabbricante, e viceversa. Si suggerisce pertanto di costruire una matrice di valutazione dedicata, distinta da quella utilizzata per la classificazione degli incidenti di sicurezza aziendali e da quella impiegata per la valutazione del rischio per i diritti e le libertà degli interessati ai sensi del GDPR.

Le scansioni temporali: allerta precoce, notifica, relazione finale

Il factsheet chiarisce che il processo di segnalazione inizia nel momento in cui il fabbricante o il gestore OSS acquisisce conoscenza dello sfruttamento attivo di una vulnerabilità o dell’incidente grave, e articola tre adempimenti successivi.

Il primo è l’allerta precoce (early warning), da trasmettere entro ventiquattro ore dalla conoscenza dell’evento. In sostanza, si tratta di una comunicazione minimale, destinata ad attivare il sistema di allerta europeo, il cui contenuto non presuppone un’analisi compiuta. La ratio è quella già nota nel sistema NIS2: privilegiare la tempestività dell’informazione grezza rispetto alla completezza dell’informazione elaborata.

Il secondo adempimento è la notifica della vulnerabilità attivamente sfruttata o dell’incidente grave, da trasmettere entro settantadue ore dalla conoscenza, con indicazione — secondo il factsheet — di informazioni generali e di una valutazione iniziale. In termini più pragmatici, questa è la comunicazione che consente alle autorità di comprendere la natura dell’evento, la sua portata, i prodotti e le versioni interessati, le eventuali misure di mitigazione già disponibili.

Il terzo adempimento è la relazione finale (final report), il cui termine varia secondo la tipologia di evento. Per le vulnerabilità, la relazione va trasmessa non oltre quattordici giorni dalla disponibilità di una misura correttiva, ad esempio una patch. Per gli incidenti gravi, la relazione va trasmessa entro un mese dalla trasmissione della notifica delle settantadue ore.

Va rilevata la differenza strutturale tra i due termini. Per gli incidenti gravi il termine è ancorato a un evento certo e già verificatosi — la trasmissione della notifica intermedia — e ha dunque natura fissa. Per le vulnerabilità, invece, il termine è ancorato alla disponibilità della misura correttiva, evento futuro e non necessariamente prossimo: la conseguenza è che il termine per la relazione finale può collocarsi a mesi di distanza dalla segnalazione iniziale, se lo sviluppo della patch richiede tempi lunghi. Secondo il parere di chi scrive, questa asimmetria è coerente con la logica della disclosure coordinata — non si chiede al fabbricante di chiudere il procedimento informativo prima di avere una soluzione — ma introduce un’esigenza di tracciamento prolungato: occorre mantenere aperto un fascicolo per ciascuna vulnerabilità segnalata, con un presidio che colleghi il rilascio della patch alla decorrenza del termine di quattordici giorni. Nella prassi dei sistemi di gestione, un termine agganciato a un evento tecnico interno è tra i più frequentemente disattesi, non per volontà elusiva ma per assenza di un collegamento automatico tra il processo di rilascio e il processo di compliance.

Occorre aggiungere che il regolamento prevede altresì, accanto agli obblighi verso le autorità, l’informazione degli utenti del prodotto interessato in ordine all’evento e, ove necessario, alle misure correttive o di mitigazione che l’utente può adottare. Trattasi di un obbligo distinto e ulteriore, che nella pratica pone problemi di sequenza e di contenuto: informare gli utenti prima della disponibilità di una correzione può ampliare la platea dei potenziali attaccanti; informarli tardivamente li espone a un rischio per un periodo prolungato. Si ritiene che la scelta debba essere documentata come decisione motivata, in modo da poterne dare conto in sede di vigilanza.

L’individuazione del CSIRT destinatario e il flusso di diffusione

Il factsheet indica che il CSIRT nazionale al quale segnalare attraverso la SRP è determinato in via principale dal luogo di stabilimento principale del soggetto obbligato, con rinvio all’articolo 14, paragrafo 7, del CRA per i dettagli che consentono l’identificazione. In termini più concreti, per un fabbricante con stabilimento principale in Italia il destinatario sarà il CSIRT Italia; per un fabbricante stabilito in un Paese terzo, l’individuazione seguirà criteri sussidiari specificati nel regolamento.

La determinazione del CSIRT competente è un adempimento preparatorio, non una scelta da compiere nell’emergenza. Si suggerisce di formalizzarla in un documento interno, con motivazione sintetica del criterio applicato, aggiornato in caso di riorganizzazioni societarie, trasferimenti di sede o modifiche della struttura del gruppo. Nei gruppi multinazionali con più entità produttive in diversi Stati membri, la questione si complica: il criterio del luogo di stabilimento principale va riferito al soggetto che riveste la qualifica di fabbricante del prodotto interessato, e non genericamente alla capogruppo. Non si ha evidenza di indicazioni specifiche, nei documenti richiamati dal factsheet, in ordine alla gestione dei casi in cui più entità dello stesso gruppo siano fabbricanti di prodotti diversi con stabilimenti in Stati membri differenti; si ritiene che la soluzione più prudente consista nel mappare preventivamente la corrispondenza tra prodotti, entità fabbricante e CSIRT competente.

Quanto al flusso successivo alla trasmissione, il factsheet descrive un meccanismo di diffusione automatica: il CSIRT che riceve inizialmente la notifica la diffonde senza indugio agli altri CSIRT degli Stati membri nei quali il prodotto è disponibile, e la notifica è contestualmente messa a disposizione di ENISA. I CSIRT nazionali condividono inoltre determinate informazioni con le rispettive autorità di vigilanza del mercato, per consentire a queste ultime di adempiere ai propri obblighi di applicazione della normativa.

Quest’ultimo passaggio merita attenzione particolare nella prospettiva del giurista d’impresa. La segnalazione al CSIRT, pur avendo finalità primariamente cooperative e di sicurezza, alimenta un flusso informativo verso l’autorità che esercita poteri di vigilanza e sanzionatori. In sostanza, l’informazione trasmessa in adempimento di un obbligo di sicurezza può divenire elemento di conoscenza per l’autorità competente a valutare la conformità del prodotto. Secondo il parere di chi scrive, ciò non giustifica alcuna reticenza — l’omessa segnalazione è essa stessa violazione, e per di più agevolmente accertabile ex post — ma impone accuratezza redazionale: la segnalazione deve essere veritiera, completa rispetto a quanto noto al momento, e priva di qualificazioni giuridiche non necessarie. Si suggerisce di descrivere fatti e dati tecnici, evitando formule valutative che possano essere lette come ammissioni di non conformità, e di far precedere la trasmissione da una revisione della funzione legale, compatibilmente con i tempi.

Il factsheet precisa altresì che la piattaforma incorpora misure di sicurezza destinate a proteggere la riservatezza delle informazioni trasmesse. Va detto che la questione della riservatezza dei dati di vulnerabilità è centrale: la concentrazione, in un unico sistema europeo, di informazioni su vulnerabilità attivamente sfruttate in prodotti diffusi sul mercato dell’Unione crea, per definizione, un obiettivo di elevato valore per attori malevoli. Non si ha evidenza, nel documento in esame, di dettagli tecnici sull’architettura di sicurezza della piattaforma; si ritiene che tali informazioni, allorché rese disponibili, meriteranno attenta valutazione, anche perché la fiducia dei fabbricanti nel sistema di segnalazione dipende in misura decisiva dalla percezione della sua sicurezza.

Il differimento della diffusione e il regolamento delegato

Il factsheet conferma che, in circostanze eccezionali, la diffusione delle informazioni può essere differita ai sensi dell’articolo 16, paragrafo 2, del CRA, e che il regolamento delegato richiamato dal factsheet specifica ulteriormente le condizioni alle quali la diffusione delle notifiche può essere differita.

La ratio dell’istituto è comprensibile. Nella logica della disclosure coordinata, la circolazione di informazioni su una vulnerabilità attivamente sfruttata prima della disponibilità di una correzione può aggravare il rischio anziché ridurlo, ampliando la platea di soggetti in grado di replicare l’attacco. Il differimento serve, dunque, a conciliare l’esigenza informativa delle autorità con l’esigenza di contenimento del rischio.

Va rilevato che il differimento riguarda la diffusione da parte del CSIRT ricevente, non la trasmissione da parte del soggetto obbligato: l’obbligo di segnalare entro ventiquattro e settantadue ore non è sospendibile. In termini più pragmatici, il fabbricante deve segnalare nei termini e può — nei casi previsti — rappresentare l’esigenza di differire la diffusione, con argomentazione fondata sui criteri stabiliti dalla normativa delegata. Si suggerisce di predisporre, già in fase preparatoria, uno schema di motivazione della richiesta di differimento, che consenta di articolare in modo sintetico e documentato le ragioni tecniche per le quali la diffusione anticipata aumenterebbe il rischio.

i criteri e le condizioni fissate dai cinque articoli del regolamento delegato 881/2026, alla cui lettura di dettaglio si rinvia è pertanto passaggio necessario per chiunque debba costruire una procedura interna completa.

Profili critici e questioni interpretative

La nozione di conoscenza e la decorrenza delle ventiquattro ore

Il presupposto di ogni termine è la conoscenza dell’evento. Il factsheet colloca l’inizio del processo nel momento in cui il soggetto obbligato “become aware” dello sfruttamento attivo o dell’incidente grave. La formula riecheggia l’articolo 33 del GDPR e, come per quest’ultimo, solleva la questione di individuare il momento e il soggetto rilevanti.

Nell’esperienza applicativa maturata sul GDPR — e recepita nelle linee guida dell’EDPB in materia di notifica delle violazioni dei dati personali — la conoscenza si radica nel momento in cui l’organizzazione ha un ragionevole grado di certezza che un evento di sicurezza si è verificato, e non nel momento in cui ne ha piena e definitiva contezza tecnica; si ammette un breve periodo di verifica iniziale, che non può però trasformarsi in una dilazione strumentale. Si ritiene che un’impostazione analoga possa essere ragionevolmente adottata ai fini del CRA, con l’avvertenza che il termine, ridotto a un terzo rispetto a quello del GDPR, riduce drasticamente lo spazio per la verifica preliminare.

La questione più delicata riguarda l’imputazione della conoscenza all’interno dell’organizzazione. Un’informazione che raggiunga un tecnico di secondo livello dell’assistenza clienti, o che pervenga a un indirizzo di posta elettronica generico di sicurezza non monitorato nei giorni festivi, integra la conoscenza del fabbricante? Secondo il parere di chi scrive, la risposta tende ad essere affermativa: l’organizzazione che si dota di canali di ricezione ha l’onere di presidiarli, e l’inefficienza interna del flusso di escalation non è opponibile all’autorità. Ne consegue, sul piano operativo, che il presidio dei canali di ricezione delle segnalazioni di sicurezza — inclusi i canali della politica di divulgazione coordinata delle vulnerabilità — deve essere continuativo e documentato, con reperibilità definita anche al di fuori dell’orario ordinario. Si osserva incidentalmente che un termine di ventiquattro ore comprensivo di fine settimana e giorni festivi ha, come conseguenza pratica inevitabile, la necessità di un presidio di turno o di una procedura di allerta automatica.

Il rischio di divulgazione prematura e la tensione con la disclosure coordinata

Il secondo profilo critico riguarda l’ampliamento del numero di soggetti che, in tempi brevissimi, vengono a conoscenza di una vulnerabilità attivamente sfruttata e non ancora corretta. Il flusso descritto dal factsheet prevede la trasmissione al CSIRT del luogo di stabilimento, la diffusione ai CSIRT degli Stati membri in cui il prodotto è disponibile, la messa a disposizione di ENISA e la condivisione di informazioni con le autorità di vigilanza del mercato. Anche assumendo la piena affidabilità di ciascun destinatario istituzionale, l’aumento del numero di soggetti informati incrementa statisticamente la probabilità di fuoriuscita non voluta dell’informazione.

Va riconosciuto che il legislatore europeo ha considerato il problema, prevedendo l’istituto del differimento della diffusione e imponendo alla piattaforma misure di protezione della riservatezza. Si ritiene tuttavia che il tema resti aperto e che la sua gestione dipenderà in larga misura dalla prassi: dalla rapidità con cui le richieste di differimento verranno valutate, dalla granularità delle informazioni effettivamente condivise con le autorità di vigilanza, dalla robustezza operativa dei presidi tecnici. Nella prospettiva del fabbricante, si suggerisce di modulare il contenuto delle segnalazioni secondo il principio di necessità: fornire le informazioni richieste, senza allegare spontaneamente dettagli tecnici di riproducibilità dell’attacco che non siano indispensabili alla comprensione dell’evento da parte dell’autorità.

Le sovrapposizioni con gli altri obblighi di notifica

Il terzo profilo critico è quello della moltiplicazione degli obblighi. La piattaforma unica risolve — apprezzabilmente — la moltiplicazione interna al CRA, consentendo una sola trasmissione verso tutti i destinatari del sistema CRA. Non risolve, però, la moltiplicazione esterna: un medesimo evento può richiedere la segnalazione al CSIRT ai sensi del CRA, la notifica al CSIRT ai sensi della NIS2 e del decreto legislativo n. 138 del 2024 se il soggetto è anche soggetto essenziale o importante, la notificazione al Garante ai sensi dell’articolo 33 del GDPR se vi è violazione di dati personali, la comunicazione agli interessati ai sensi dell’articolo 34, le segnalazioni settoriali eventualmente applicabili, la comunicazione agli utenti del prodotto prevista dal CRA, nonché — per le società quotate — le valutazioni in materia di informazione privilegiata.

Appare chiaro allo scrivente che l’unico presidio efficace consista in una procedura unica di gestione degli eventi di sicurezza, che a monte della qualificazione giuridica raccolga i fatti in modo standardizzato e, a valle, attivi in parallelo i diversi canali di notifica secondo una matrice predefinita. La frammentazione dei processi — un flusso per la privacy, un flusso per la NIS2, un flusso per la conformità di prodotto — è, nell’esperienza dei sistemi di gestione, la principale causa di segnalazioni tardive o incoerenti tra loro. L’incoerenza tra segnalazioni relative al medesimo evento presentate ad autorità diverse è, di per sé, un fattore di rischio: espone a contestazioni di inesattezza e mina la credibilità complessiva della rappresentazione dei fatti.

Riservatezza, segreti commerciali e dati personali nelle notifiche

Il quarto profilo attiene al contenuto informativo delle segnalazioni. Le informazioni relative a vulnerabilità di prodotto e ad architetture software costituiscono, in molti casi, informazioni commerciali riservate ai sensi della direttiva (UE) 2016/943 e del decreto legislativo 10 febbraio 2005, n. 30, come modificato. La trasmissione ad autorità pubbliche in adempimento di un obbligo di legge non fa perdere alle informazioni il carattere di riservatezza, ma è opportuno che le segnalazioni rechino l’espressa qualificazione delle parti riservate, quando la piattaforma lo consenta.

Sul versante della protezione dei dati personali, va considerato che le segnalazioni possono contenere dati personali: nominativi e contatti dei referenti del fabbricante, informazioni relative ai ricercatori che hanno individuato la vulnerabilità, in taluni casi dati riferiti a utenti interessati dall’incidente. Il trattamento connesso alla segnalazione trova base giuridica nell’adempimento di un obbligo legale ai sensi dell’articolo 6, paragrafo 1, lettera c), del GDPR. Si suggerisce, comunque, l’applicazione rigorosa del principio di minimizzazione di cui all’articolo 5, paragrafo 1, lettera c): la segnalazione deve contenere i dati personali strettamente necessari, e in particolare va evitata la trasmissione di dati relativi a singoli utenti quando la descrizione dell’evento possa essere resa in forma aggregata o anonima. Il registro dei trattamenti di cui all’articolo 30 del GDPR dovrebbe essere integrato con il trattamento connesso agli obblighi di segnalazione, e l’informativa ai sensi degli articoli 13 e 14 dovrebbe menzionare la comunicazione dei dati alle autorità competenti quando ciò sia prevedibile.

La catena di fornitura e i rapporti contrattuali

Il quinto profilo riguarda la catena di fornitura. Il fabbricante è tenuto a segnalare eventi che possono avere origine in componenti di terzi: librerie open source, moduli hardware, servizi di elaborazione a distanza integrati nel prodotto. Il rispetto del termine di ventiquattro ore presuppone dunque che il fabbricante venga a conoscenza dell’evento tempestivamente, il che dipende dalla qualità dei flussi informativi con i fornitori.

Si ritiene pertanto necessario un intervento sulla contrattualistica di fornitura, con l’introduzione di obblighi di comunicazione tempestiva delle vulnerabilità e degli incidenti, con termini interni più stretti di quelli di legge — poiché il fabbricante deve disporre di un margine per la valutazione — e con obblighi di cooperazione nella predisposizione delle informazioni da trasmettere. Nella prassi contrattuale, clausole di questo tipo sono già diffuse in attuazione dell’articolo 28 del GDPR per i rapporti di responsabile del trattamento e in attuazione delle previsioni NIS2 in materia di sicurezza della catena di approvvigionamento; si suggerisce di estenderne l’ambito agli aspetti di sicurezza di prodotto, evitando però la mera duplicazione di clausole concepite per finalità diverse.

Va aggiunto un profilo di allocazione del rischio: la responsabilità per l’omessa segnalazione grava sul fabbricante, non sul fornitore inadempiente all’obbligo contrattuale di informazione. Le clausole di manleva possono riequilibrare il danno economico, ma non escludono l’imputazione della violazione. Ne consegue che il presidio contrattuale deve essere accompagnato da un presidio di verifica: monitoraggio autonomo delle vulnerabilità dei componenti utilizzati, gestione aggiornata della distinta base del software, sottoscrizione di flussi di threat intelligence pertinenti alle tecnologie impiegate.

I gestori di software libero e open source e la proporzionalità degli oneri

Il sesto profilo riguarda la sostenibilità degli adempimenti per i gestori OSS. Trattasi, in molti casi, di organizzazioni con risorse limitate, prive di funzioni legali strutturate e operanti su base volontaria. L’estensione a tali soggetti di obblighi di segnalazione con termini di ventiquattro ore solleva, secondo il parere di chi scrive, un tema di effettività: un obbligo che l’organizzazione destinataria non è strutturalmente in grado di adempiere rischia di produrre, come effetto principale, la disapplicazione di fatto oppure la contrazione dell’offerta di componenti open source verso il mercato europeo.

Il legislatore ha mitigato il regime, prevedendo per i gestori obblighi attenuati e proporzionati e limitando l’obbligo di segnalazione all’ambito del loro coinvolgimento nello sviluppo di prodotti con elementi digitali. Si ritiene che la prassi delle autorità nazionali sarà determinante: un approccio orientato al supporto e alla gradualità, piuttosto che alla sanzione immediata, appare più coerente con la finalità del regolamento. Non si ha evidenza, nel documento in esame, di indicazioni specifiche in ordine a modalità semplificate di accesso alla piattaforma per tali soggetti; si osserva che la predisposizione di percorsi guidati e di modelli precompilati potrebbe contribuire in misura significativa all’effettività dell’obbligo.

Il regime sanzionatorio come fattore di priorità

Va infine considerato il profilo sanzionatorio, che nell’economia delle decisioni aziendali incide sulla priorità assegnata al progetto di adeguamento. Il CRA prevede, per le violazioni dei requisiti essenziali di cui all’allegato I e degli obblighi di cui agli articoli 13 e 14, sanzioni amministrative pecuniarie fino a 15.000.000 di euro o, se superiore, fino al 2,5 per cento del fatturato mondiale totale annuo dell’esercizio precedente; per le violazioni degli altri obblighi del regolamento il massimale è fissato a 10.000.000 di euro o al 2 per cento del fatturato mondiale; per la comunicazione di informazioni inesatte, incomplete o fuorvianti agli organismi notificati e alle autorità di vigilanza del mercato, a 5.000.000 di euro o all’1 per cento del fatturato. Il regolamento prevede altresì una modulazione per le microimprese e le piccole imprese.

Si osserva che l’obbligo di segnalazione di cui all’articolo 14 rientra nella fascia sanzionatoria più elevata. Ciò conferma la centralità sistematica che il legislatore attribuisce al flusso informativo. Va rilevato, inoltre, che la fascia sanzionatoria relativa alla comunicazione di informazioni inesatte o fuorvianti alle autorità costituisce un ulteriore argomento in favore dell’accuratezza redazionale delle segnalazioni: la fretta imposta dai termini brevi non attenua l’onere di veridicità, e la segnalazione approssimativa può esporre a un rischio autonomo.

Adempimenti operativi per DPO, funzioni compliance e imprese

Quanto segue è concepito come traccia di lavoro per la costruzione o la revisione dei presidi interni in vista della decorrenza dell’11 settembre 2026. Le indicazioni presuppongono la verifica preliminare dell’applicabilità del CRA all’impresa e ai suoi prodotti e vanno intese a titolo meramente esemplificativo e non esaustivo. Chi scrive, ritiene che debba concentrarsi l’attenzione sulle seguenti attività di massima:

La verifica di applicabilità e qualificazione soggettiva: occorre accertare, in via preliminare, se l’impresa rivesta la qualifica di fabbricante di prodotti con elementi digitali resi disponibili sul mercato dell’Unione, ovvero di gestore di software libero e open source, ovvero ancora di importatore, distributore o rappresentante autorizzato. Si suggerisce di condurre la verifica prodotto per prodotto e non a livello di entità giuridica, poiché la stessa impresa può essere fabbricante di alcuni prodotti e mero distributore di altri, con obblighi differenti; l’esito va formalizzato in un documento di qualificazione, sottoscritto dalle funzioni tecniche e legali e sottoposto a riesame periodico.

Il censimento dei prodotti e dei mercati di disponibilità: la diffusione della segnalazione ai CSIRT degli Stati membri in cui il prodotto è disponibile presuppone che il fabbricante sappia indicare tali Stati. Si ritiene pertanto necessario mantenere un inventario dei prodotti con elementi digitali che riporti, per ciascuno, le versioni supportate, i mercati di commercializzazione, i canali distributivi e i componenti di terzi integrati, con collegamento alla distinta base del software.

La determinazione preventiva del CSIRT competente: l’individuazione del CSIRT destinatario ai sensi dell’articolo 14, paragrafo 7, del CRA va effettuata prima del verificarsi di qualunque evento, sulla base del criterio del luogo di stabilimento principale del soggetto obbligato e dei criteri sussidiari applicabili ai fabbricanti di Paesi terzi. Nei gruppi con più entità fabbricanti in Stati membri diversi, si suggerisce di predisporre una tabella di corrispondenza tra prodotto, entità fabbricante e CSIRT competente.

La registrazione e gestione degli accessi alla piattaforma: poiché il flusso descritto da ENISA prevede accesso autenticato, occorre completare tempestivamente la registrazione, individuare i soggetti abilitati, definire deleghe e supplenze, verificare periodicamente la funzionalità delle credenziali e documentare la procedura di accesso in modo che essa sia utilizzabile anche da personale reperibile fuori orario.

La procedura interna di rilevazione, escalation e qualificazione: si suggerisce di formalizzare una procedura che definisca i canali di ricezione delle informazioni su vulnerabilità e incidenti — assistenza clienti, casella dedicata prevista dalla politica di divulgazione coordinata, monitoraggio tecnico, flussi di threat intelligence, comunicazioni di fornitori e CSIRT —, i tempi massimi di inoltro al gruppo di valutazione e i criteri di qualificazione dell’evento come vulnerabilità attivamente sfruttata o incidente grave. Il momento della prima ricezione va registrato con orario, poiché è da esso che, in caso di verifica, si tenderà a far decorrere la conoscenza.

La creazione di una matrice di gravità calibrata sui criteri dell’articolo 14, paragrafo 5: la valutazione della gravità dell’incidente va condotta sulla base dei criteri normativi, tradotti in una matrice applicabile alle specificità dei prodotti dell’impresa. Si ritiene opportuno che la matrice sia distinta da quella utilizzata per la classificazione degli incidenti aziendali e da quella impiegata per la valutazione del rischio ai sensi degli articoli 33 e 34 del GDPR, ferma la necessità di un raccordo procedurale tra le tre valutazioni.

La predisposizione anticipata di modelli di segnalazione : occorre predisporre bozze di allerta precoce, di notifica delle settantadue ore e di relazione finale, coerenti con i campi informativi della piattaforma, in lingua inglese e nella lingua eventualmente richiesta dal CSIRT competente. La predisposizione anticipata riduce il rischio di omissioni e di formulazioni improprie redatte sotto pressione.

L’implementazione di una procedura per la richiesta di differimento della diffusione: alla luce dell’articolo 16, paragrafo 2, del CRA e delle condizioni specificate dal regolamento delegato 881/2026, si suggerisce di predisporre uno schema di motivazione della richiesta di differimento, con individuazione dei presupposti tecnici e delle evidenze a supporto, e di definire chi, all’interno dell’organizzazione, è competente a decidere se avanzarla.

La predisposizione di un presidio continuativo e di sistemi di reperibilità: il termine di ventiquattro ore impone una copertura che comprenda fine settimana e periodi di chiusura aziendale. Si ritiene necessario definire turni di reperibilità, meccanismi di allerta automatica sui canali di ricezione e procedure di attivazione rapida del gruppo di valutazione, con evidenza documentale del funzionamento del presidio.

Il tracciamento dei termini agganciati al rilascio delle correzioni: poiché per le vulnerabilità la relazione finale è dovuta entro quattordici giorni dalla disponibilità della misura correttiva, occorre collegare il processo di rilascio delle patch al processo di compliance, mediante un flusso di lavoro che generi automaticamente l’adempimento al momento della pubblicazione della correzione.

Il coordinamento con la notificazione di data breach: il DPO dovrebbe essere inserito nel flusso informativo relativo agli eventi CRA, con il compito di valutare in parallelo la sussistenza di una violazione di dati personali e i conseguenti obblighi di cui agli articoli 33 e 34 del GDPR. Si suggerisce di integrare il registro delle violazioni previsto dall’articolo 33, paragrafo 5, con l’indicazione dell’eventuale segnalazione effettuata ai sensi del CRA, per garantire coerenza tra le rappresentazioni fornite alle diverse autorità.

La revisione della contrattualistica di fornitura: occorre introdurre nei contratti con fornitori di componenti software e hardware obblighi di comunicazione tempestiva di vulnerabilità e incidenti, con termini interni compatibili con quelli di legge, obblighi di cooperazione informativa e presidi di riservatezza, valutando le clausole di manleva senza confidare in esse quale sostituto del presidio organizzativo.

L’informazione agli utenti del prodotto: va definita una procedura per la comunicazione agli utenti interessati, con criteri di scelta del momento e del contenuto, coordinati con la strategia di disclosure coordinata e con l’eventuale differimento della diffusione istituzionale; la decisione va motivata e documentata.

La formazione e le simulazioni: si ritiene opportuno sottoporre il processo a esercitazioni periodiche, anche in forma di simulazione documentale, verificando in particolare il rispetto del termine di ventiquattro ore in scenari di ricezione dell’informazione in orario non lavorativo. L’esito delle esercitazioni va verbalizzato e utilizzato per la revisione delle procedure.

L’integrazione nel sistema di gestione e di audit interno: gli adempimenti CRA vanno inseriti nel sistema di gestione della sicurezza delle informazioni eventualmente adottato, con indicatori, responsabilità formalizzate e inclusione nel piano di audit interno; la mancanza di evidenze documentali del funzionamento del presidio è, nella prassi di audit, la carenza rilevata con maggiore frequenza.

Conclusioni

Il factsheet di ENISA sulla Single Reporting Platform non introduce obblighi nuovi rispetto a quanto già stabilito dal regolamento (UE) 2024/2847, ma segnala con chiarezza che l’infrastruttura destinata a ricevere le segnalazioni è in costruzione e che la data dell’11 settembre 2026 costituisce il riferimento operativo attorno al quale organizzare l’adeguamento. Si ritiene che il documento, per la sua natura sintetica, vada letto come conferma di un cronoprogramma più che come fonte di chiarimenti interpretativi, i quali continuano a dipendere dal testo del regolamento, dalla guidance della Commissione europea e dagli atti delegati.

Restano aperte alcune questioni specifiche, sulle quali si ritiene utile mantenere attenzione. La prima riguarda il contenuto informativo esatto dei campi della piattaforma: la definizione dei modelli interni di segnalazione richiede di conoscere quali informazioni saranno effettivamente richieste nelle tre fasi, e la pubblicazione di specifiche tecniche e di schemi dei campi costituirebbe un contributo significativo alla preparazione dei soggetti obbligati. La seconda riguarda i criteri di valutazione delle richieste di differimento della diffusione: il regolamento delegato richiamato dal factsheet ne specifica le condizioni, ma l’effettività dell’istituto dipenderà dalla tempestività con cui i CSIRT saranno in grado di deliberare, in un contesto nel quale ogni ora incide sul rischio. La terza riguarda il coordinamento pratico tra segnalazione CRA e notificazione NIS2 verso il medesimo interlocutore nazionale: non si ha evidenza, alla data di redazione, di indicazioni operative italiane che chiariscano se e in quale misura le due comunicazioni possano essere presentate in modo coordinato, e un chiarimento in tal senso sarebbe apprezzabile per ridurre la duplicazione degli adempimenti.

Una quarta questione, di natura più sistematica, riguarda l’esatta perimetrazione della nozione di incidente grave rispetto alla nozione di violazione dei dati personali. Le due categorie, pur distinte per presupposti e finalità, condividono un’area di sovrapposizione ampia, e l’esperienza applicativa del GDPR suggerisce che la qualificazione dei fatti sotto pressione temporale produce esiti disomogenei. Secondo il parere di chi scrive, la costruzione anticipata di criteri di qualificazione coerenti tra i diversi regimi — non identici, ma reciprocamente consapevoli — è la principale attività preparatoria che le imprese possono utilmente compiere nei mesi che precedono la decorrenza.

Una quinta questione riguarda l’assetto istituzionale nazionale. La designazione delle autorità di vigilanza del mercato competenti per il CRA, la definizione dei loro poteri istruttori e la disciplina interna delle sanzioni sono passaggi necessari per rendere pienamente operativo il sistema; la loro tempistica inciderà sull’effettività della vigilanza e, indirettamente, sulla percezione di priorità del tema presso le imprese.

Va infine osservato che il CRA introduce, nel diritto dell’Unione, un obbligo di segnalazione riferito alla sicurezza dei prodotti immessi sul mercato e non alla sicurezza dell’organizzazione che li produce. Trattasi di uno spostamento concettuale rilevante: la responsabilità informativa segue il prodotto lungo il suo ciclo di vita, presso una platea di utilizzatori spesso non identificabili individualmente. Le implicazioni di questo spostamento — sul piano della responsabilità civile da prodotto, del coordinamento con la nuova disciplina europea in materia di responsabilità per danno da prodotti difettosi, e della gestione documentale di lungo periodo — meriteranno approfondimenti autonomi, che il presente contributo si limita a segnalare come prospettive evolutive da monitorare.