Dall’11 settembre 2026 i fabbricanti di prodotti con elementi digitali dovranno notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza del prodotto.
Il CRA apre due percorsi distinti: preallarme entro 24 ore, notifica entro 72 ore e una relazione finale il cui termine cambia in base all’evento. Le comunicazioni passeranno attraverso la Single Reporting Platform gestita da ENISA e saranno indirizzate al CSIRT coordinatore.
La piattaforma semplifica il flusso europeo del CRA. Restano separati gli eventuali obblighi previsti dalla NIS2 e dal GDPR, fondati su soggetti, soglie e interessi protetti differenti. Per rispettare scadenze quasi sovrapposte serve un’unica ricostruzione tecnica dell’evento, accompagnata da decisioni giuridiche tracciate e da responsabilità assegnate prima dell’incidente.
Indice degli argomenti
Alle 18:47 arriva un log, e partono tre domande diverse
Venerdì, ore 18:47. Un cliente invia al fabbricante poche righe di log: qualcuno ha eseguito comandi non autorizzati attraverso una funzione del prodotto. Il componente interessato compare nella distinta software, un fornitore ha appena pubblicato un advisory e la patch è ancora in preparazione. Il SOC cerca tracce sui sistemi aziendali. Il team di prodotto deve capire quali versioni siano esposte. Il DPO chiede se l’attacco abbia coinvolto dati personali.
La stessa sequenza può aprire tre valutazioni. Per il CRA occorre stabilire se esista una vulnerabilità attivamente sfruttata nel prodotto oppure un incidente grave che incide sulla sua sicurezza. Se il fabbricante è anche un soggetto essenziale o importante, la compromissione può avere rilievo come incidente significativo NIS2. Quando l’evento comporta perdita, alterazione, indisponibilità o accesso non autorizzato a dati personali, entra in gioco il GDPR.
I termini sembrano familiari: 24 ore, 72 ore, un mese. Questa somiglianza rischia di confondere più di quanto aiuti. I presupposti cambiano, cambiano i soggetti obbligati e cambiano le informazioni da trasmettere. Anche i destinatari seguono percorsi propri. Un unico incidente tecnico può quindi produrre notifiche diverse, senza che l’invio attraverso un canale assorba automaticamente gli altri.
È questo il passaggio operativo che il mercato deve affrontare prima dell’11 settembre. La sicurezza di prodotto entra nel tempo corto dell’incident reporting mentre gran parte degli altri obblighi del CRA attende ancora l’11 dicembre 2027.
Il reporting arriva quindici mesi prima della conformità completa
L’articolo 14 del Regolamento (UE) 2024/2847 si applica dall’11 settembre 2026. Da quel giorno il fabbricante deve notificare le vulnerabilità attivamente sfruttate contenute nei propri prodotti con elementi digitali e gli incidenti gravi che incidono sulla sicurezza di tali prodotti. La valutazione di conformità, la documentazione tecnica, la marcatura CE e l’insieme dei requisiti essenziali troveranno piena applicazione dall’11 dicembre 2027.
Il regime transitorio rende la prima data particolarmente insidiosa. Gli obblighi di segnalazione riguardano anche i prodotti già immessi sul mercato prima della piena applicazione del Regolamento. Le linee guida della Commissione del 27 luglio 2026 chiariscono inoltre che il reporting può continuare oltre il periodo di supporto. Il fabbricante può avere cessato l’obbligo di fornire nuove correzioni per una versione fuori supporto e conservare, allo stesso tempo, il dovere di segnalare un’attiva compromissione di cui venga a conoscenza.
Ne deriva un calendario rovesciato rispetto a molti programmi di adeguamento. Le imprese che hanno pianificato SBOM, vulnerability handling e product security incident response per il 2027 devono anticiparne una parte. Dal settembre 2026 serve già la capacità di collegare una segnalazione a un prodotto, a una versione, a un componente e agli Stati membri nei quali quel prodotto è stato reso disponibile.
La distinta base torna qui con una funzione molto concreta. Nel precedente passaggio della compliance serviva a conoscere ciò che il fabbricante aveva integrato. Ora deve aiutare una decisione che scade in ore. Se la SBOM descrive una famiglia generica, non coincide con l’artefatto rilasciato o ignora le dipendenze transitive, il team consumerà buona parte delle prime 24 ore per capire se il componente vulnerabile sia davvero presente.
Vulnerabilità attivamente sfruttata e incidente grave seguono due trigger
Il CRA non impone di notificare ogni vulnerabilità conosciuta. L’articolo 3 definisce attivamente sfruttata la vulnerabilità per la quale esistono prove attendibili che un attore malevolo l’abbia utilizzata in un sistema senza il permesso del proprietario. La pubblicazione di un CVE, la presenza di un proof of concept o la semplice sfruttabilità tecnica aprono il triage. Da soli, questi elementi non dimostrano che il presupposto dell’articolo 14 sia stato raggiunto.
La verifica deve restare legata al prodotto. Una vulnerabilità proveniente da una libreria o da un componente di terzi può essere presente nel codice e risultare irraggiungibile nella configurazione effettivamente distribuita. Le linee guida della Commissione chiedono al fabbricante di accertare se la vulnerabilità sia sfruttabile o attivamente sfruttata nel proprio prodotto. La notizia che la stessa falla sia stata usata contro un’implementazione diversa non consente di saltare questa analisi.
Il secondo trigger riguarda l’incidente grave che ha un impatto sulla sicurezza del prodotto. La gravità ricorre quando l’evento incide, o è capace di incidere, sulla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati o funzioni sensibili o importanti. Rientra anche il caso in cui l’incidente abbia portato, o possa portare, all’introduzione o all’esecuzione di codice malevolo nel prodotto o nei sistemi dell’utilizzatore.
La compromissione di un server di aggiornamento, di una chiave di firma o della pipeline che genera un firmware offre esempi immediati. Il fabbricante potrebbe non subire un’interruzione rilevante dei propri servizi; il prodotto distribuito agli utenti ha comunque perso una parte essenziale della propria affidabilità. Il CRA guarda a quella relazione.
I due presupposti possono incontrarsi. Lo sfruttamento di una falla può causare un incidente grave nel prodotto o nei sistemi degli utenti. Il processo interno deve quindi esaminare entrambe le qualificazioni, registrando quale evidenza sorregga ciascuna conclusione. La scelta frettolosa di una sola etichetta può lasciare scoperta una seconda comunicazione dovuta.
Il momento della conoscenza va ricostruito, non intuito
Tutti i termini dell’articolo 14 decorrono da quando il fabbricante viene a conoscenza dell’evento. Un alert automatico, una mail di un ricercatore o la telefonata di un cliente possono contenere un sospetto ancora incompleto. Ignorarli sarebbe pericoloso; considerarli sempre come piena conoscenza renderebbe il sistema ingestibile.
Le linee guida C(2026) 5252 collocano in mezzo una valutazione iniziale da svolgere immediatamente. La conoscenza matura quando, dopo quell’esame, esiste un ragionevole grado di certezza che la vulnerabilità contenuta nel prodotto sia attivamente sfruttata oppure che si sia verificato un incidente grave capace di comprometterne la sicurezza. La Commissione ha raccordato questa lettura con l’approccio seguito per la NIS2 e con le linee guida dell’EDPB sulle violazioni di dati personali.
L’allineamento aiuta a fissare un momento comune. Le soglie giuridiche restano autonome. Un’organizzazione può raggiungere la ragionevole certezza sui fatti e concludere che il CRA si applica, che la NIS2 non raggiunge la soglia dell’incidente significativo e che il GDPR richiede soltanto la registrazione interna della violazione. Oppure può accadere il contrario.
Il fascicolo dovrebbe quindi riportare l’ora della prima segnalazione, le verifiche avviate, l’evidenza che ha trasformato il sospetto in conoscenza e chi ha assunto la decisione. Spostare informalmente in avanti il momento iniziale espone l’impresa a una contestazione facile da ricostruire. Anticiparlo senza criterio produce notifiche confuse e sottrae risorse alla risposta tecnica.
Il punto più delicato resta la velocità della valutazione. Le linee guida non concedono una zona franca di durata indefinita prima delle 24 ore. La ricerca della ragionevole certezza deve procedere con urgenza, soprattutto quando l’evento presenta un rischio elevato. Per questo le regole interne di escalation, i contatti dei fornitori e l’accesso ai log di prodotto fanno parte della compliance giuridica tanto quanto il modello di notifica.
Le prime 24 ore servono ad attivare la rete europea
Per una vulnerabilità attivamente sfruttata il fabbricante presenta, senza ingiustificato ritardo e comunque entro 24 ore, un preallarme. Indica, quando applicabile, gli Stati membri nei quali sa che il prodotto è stato messo a disposizione. La prima comunicazione nasce volutamente essenziale: a quell’ora l’indagine può essere ancora aperta e la misura correttiva può mancare.
Il preallarme relativo a un incidente grave deve aggiungere almeno l’indicazione sull’eventuale origine illecita o malevola. Anche qui vanno segnalati, se noti, gli Stati membri nei quali il prodotto è disponibile. Le FAQ pubblicate da ENISA mostrano che la piattaforma richiederà già in questa fase l’identificazione del fabbricante, del prodotto, del tipo di evento e del livello della comunicazione.
L’obiettivo delle 24 ore è permettere al CSIRT coordinatore e a ENISA di comprendere che esiste un evento potenzialmente rilevante per altri mercati e utilizzatori. Il fabbricante deve distinguere con cura i fatti confermati dalle ipotesi. Una frase precisa come “attiva compromissione confermata sulla versione 4.2; valutazione in corso sulle versioni precedenti” vale più di una ricostruzione estesa che mescola prodotti, varianti e deduzioni.
La notifica precoce non esaurisce gli altri obblighi informativi del CRA. Dopo la conoscenza dell’evento il fabbricante deve informare gli utenti coinvolti e, quando opportuno, tutti gli utenti, indicando le misure di mitigazione e correzione che possono adottare. Se l’informazione tarda e il rischio lo richiede, i CSIRT notificati possono intervenire verso gli utilizzatori. La comunicazione di prodotto deve quindi essere preparata insieme al preallarme, con attenzione agli eventuali rischi derivanti dalla divulgazione prematura di dettagli tecnici.
A 72 ore serve un quadro utilizzabile
Entro 72 ore dalla conoscenza, il fabbricante aggiorna la segnalazione. Nel caso della vulnerabilità descrive, per quanto disponibile, il prodotto interessato, la natura generale della falla e dell’exploit, le misure correttive o di mitigazione già adottate e quelle che gli utenti possono applicare. Può anche indicare il livello di sensibilità attribuito alle informazioni trasmesse.
Per l’incidente grave la notifica contiene la natura dell’evento, una prima valutazione della gravità e dell’impatto, le misure adottate e le azioni offerte agli utenti. Anche in questo percorso la sensibilità delle informazioni deve essere dichiarata. Il contenuto è ancora iniziale, però deve essere abbastanza solido da consentire al CSIRT di valutare diffusione, priorità e possibili conseguenze transfrontaliere.
Le istruzioni operative ENISA pubblicate ad agosto rendono visibile la sequenza: il rappresentante assegnato apre una nuova notifica, trasmette il preallarme e torna sullo stesso record per la comunicazione delle 72 ore. Le informazioni comuni vengono riprese e aggiornate. Dopo l’invio della relazione finale il record diventa non modificabile. Questa scelta impone un controllo di qualità prima della chiusura e una procedura per conservare nel fascicolo interno gli sviluppi successivi.
Il CSIRT coordinatore può chiedere una relazione intermedia. Conviene quindi mantenere il dossier aggiornato anche tra una scadenza e l’altra. Un processo costruito soltanto attorno ai tre pulsanti della piattaforma lascerebbe senza risposta le richieste che arrivano durante la gestione.
Le relazioni finali hanno calendari differenti
Per una vulnerabilità attivamente sfruttata la relazione finale va trasmessa entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione. Il termine non decorre dal preallarme. La data da registrare con precisione è quella in cui la patch, la configurazione sicura o l’altra misura diventa effettivamente disponibile.
Il rapporto finale descrive la vulnerabilità, la severità e l’impatto. Riporta, quando disponibili, informazioni sull’attore che l’ha sfruttata e dettaglia l’aggiornamento di sicurezza o le altre misure predisposte. Una correzione annunciata, ancora non distribuibile agli utenti interessati, difficilmente offre un riferimento affidabile per avviare questo termine.
Per l’incidente grave la relazione finale arriva entro un mese dalla notifica delle 72 ore. Deve contenere una descrizione dettagliata dell’incidente, della gravità e dell’impatto, la minaccia o la causa che probabilmente lo ha innescato e le misure di mitigazione applicate o ancora in corso. Il calendario coincide in larga parte con quello NIS2, mentre il contenuto conserva il punto di vista del prodotto.
La differenza tra i due termini obbliga a gestire più promemoria sullo stesso caso. Se l’exploit provoca anche un incidente grave, la disponibilità della patch può far partire il conto dei 14 giorni mentre resta aperto il mese previsto per la relazione sull’incidente. La piattaforma agevola l’aggiornamento dei record; la responsabilità sul rispetto delle scadenze rimane nel runbook del fabbricante.
La Single Reporting Platform concentra il flusso CRA
L’articolo 16 affida a ENISA l’istituzione e la gestione quotidiana della Single Reporting Platform. Il fabbricante invia la comunicazione una sola volta attraverso il punto elettronico del CSIRT designato come coordinatore. Il record è accessibile contemporaneamente a ENISA, salvo le circostanze eccezionali previste per le informazioni particolarmente sensibili.
Il CSIRT coordinatore dipende, di regola, dallo stabilimento principale del fabbricante nell’Unione. Il CRA individua questo luogo nello Stato membro in cui vengono assunte prevalentemente le decisioni sulla cybersicurezza dei prodotti. Quando il criterio non permette una risposta, rileva lo stabilimento con il maggior numero di dipendenti nell’Unione. Per i fabbricanti extra-UE il Regolamento usa una sequenza che considera rappresentante autorizzato, importatore, distributore e, in ultima istanza, localizzazione del maggior numero di utenti.
La determinazione ha conseguenze organizzative. Un gruppo multinazionale può avere sede legale in uno Stato, product security in un altro e sviluppo distribuito. Attendere il primo incidente per discutere dove siano prese le decisioni sulla sicurezza del prodotto significa spendere le ore più preziose su una questione di giurisdizione interna.
Nell’agosto 2026 ENISA ha pubblicato le FAQ, la matrice dei campi e le prime guide per i rappresentanti assegnati. L’accesso utilizzerà EU Login. Sono previsti un rappresentante primario e utenti secondari o di backup. La convalida del potere di agire per il fabbricante sarà svolta dal CSIRT anche dopo il primo accesso e non impedirà l’invio della notifica. Le indicazioni attuali consigliano di predisporre EU Login e ruoli interni, evitando una registrazione preventiva sulla piattaforma priva di una specifica segnalazione.
La prima versione non offrirà API. ENISA ammette comunque l’automazione dei flussi interni e ha già reso pubblici i campi richiesti. È quindi possibile preparare un record strutturato che raccolga prodotto, versione, Stati di distribuzione, natura dell’evento, mitigazioni, sensibilità e riferimenti tecnici, lasciando alla piattaforma l’ultimo passaggio manuale.
Il CSIRT coordina, valuta e può limitare la diffusione
Il CSIRT che riceve per primo la notifica la diffonde agli altri CSIRT degli Stati membri nei quali il prodotto è stato messo a disposizione. Trasmette inoltre alle autorità di vigilanza del mercato le informazioni necessarie per le loro funzioni. In caso di evento su larga scala, ENISA può coinvolgere EU-CyCLONe per il coordinamento operativo europeo.
Questa circolazione spiega perché la sensibilità delle informazioni merita una valutazione esplicita. Una vulnerabilità attivamente sfruttata può essere notificata quando la patch ancora manca. Diffondere troppo presto dettagli utili all’attacco aumenterebbe il rischio che il sistema vuole ridurre. Il CRA consente al CSIRT, in circostanze eccezionali e su basi di cybersicurezza giustificate, di ritardare la disseminazione per il tempo strettamente necessario. La Commissione ha specificato le condizioni con l’atto delegato C(2025) 8407.
La decisione appartiene al CSIRT. Il fabbricante deve segnalare la sensibilità e fornire elementi concreti: stato della correzione, facilità di riproduzione, ampiezza della superficie esposta, rischio di propagazione e coordinamento in corso con ricercatori o fornitori. La generica apposizione della parola “confidenziale” offre poco aiuto a chi deve bilanciare protezione dell’informazione e allerta degli altri Stati.
Anche il rapporto con il CSIRT va progettato prima dell’evento. Servono un referente capace di rispondere sul prodotto, un sostituto e un canale interno per ottenere in tempi brevi le decisioni di legal, product security e direzione. La piattaforma registra l’invio; il coordinamento continua nelle ore successive.
NIS2 osserva il servizio e l’organizzazione
Il CRA disciplina la sicurezza del prodotto con elementi digitali e attribuisce l’obbligo al fabbricante. La NIS2 guarda ai soggetti essenziali e importanti e agli incidenti significativi che incidono sulla fornitura dei loro servizi. Le due prospettive possono sovrapporsi senza coincidere.
Un fabbricante che rientra anche nel perimetro NIS2 può subire la compromissione della propria infrastruttura di aggiornamento. L’evento può rendere insicuri i prodotti distribuiti e causare, nello stesso tempo, una grave perturbazione del servizio aziendale o danni considerevoli a terzi. In quel caso la funzione di fabbricante alimenta la notifica CRA, mentre la qualità di soggetto NIS sostiene il percorso previsto dall’articolo 23 della Direttiva e, in Italia, dall’articolo 25 del decreto legislativo 138/2024.
Può verificarsi anche una distribuzione dei ruoli. Il fabbricante segnala ai sensi del CRA la vulnerabilità sfruttata nel prodotto. Il cliente che utilizza quel prodotto per erogare un servizio essenziale valuta l’incidente significativo NIS2. Le due organizzazioni hanno bisogno di scambiarsi rapidamente indicatori di compromissione, versioni coinvolte, mitigazioni e tempi della patch. Le clausole contrattuali devono sostenere questo passaggio senza pretendere che una parte decida al posto dell’altra la qualificazione regolatoria.
La NIS2 utilizza anch’essa una sequenza di 24 ore, 72 ore e un mese. Il preallarme indica, quando pertinente, la possibile origine illecita o malevola e l’impatto transfrontaliero. La notifica successiva aggiunge una prima valutazione di gravità e impatto e, ove disponibili, gli indicatori di compromissione. Il CSIRT può chiedere aggiornamenti intermedi. La relazione finale affronta causa, conseguenze, misure applicate e impatto transfrontaliero.
La cadenza comune favorisce il coordinamento. La Single Reporting Platform resta il punto unico delle comunicazioni CRA e non assorbe, allo stato, la notifica NIS2. Anche quando il destinatario appartiene allo stesso ecosistema nazionale di cybersicurezza, l’organizzazione deve verificare i canali previsti dalla disciplina applicabile e conservare la prova di ciascun invio.
Il GDPR segue i dati personali e i rischi per le persone
Il GDPR si attiva davanti a una violazione di dati personali: distruzione, perdita, modifica, divulgazione non autorizzata o accesso ai dati trasmessi, conservati o trattati. La riservatezza è soltanto uno dei possibili profili. Un ransomware che renda indisponibili dati personali può integrare una violazione anche quando non emergono prove di esfiltrazione.
Il titolare notifica la violazione all’autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza, salvo che sia improbabile un rischio per i diritti e le libertà delle persone. Se il rischio è elevato, deve comunicare la violazione agli interessati senza ingiustificato ritardo, fatte salve le eccezioni dell’articolo 34. Il responsabile del trattamento informa tempestivamente il titolare, perché la decisione sulla notifica resta in capo a quest’ultimo.
Una vulnerabilità attivamente sfruttata può quindi richiedere la segnalazione CRA e rimanere fuori dall’articolo 33 del GDPR quando nessun dato personale è stato compromesso. Un data breach può invece nascere da un errore operativo o da credenziali sottratte senza coinvolgere un prodotto del quale l’organizzazione sia fabbricante. Le aree si incontrano quando l’exploit sul prodotto espone dati degli utenti o compromette la soluzione di elaborazione remota che ne sostiene le funzioni.
Il ruolo privacy può inoltre appartenere a un soggetto diverso dal fabbricante. Il cliente è spesso titolare dei dati trattati attraverso il prodotto; il produttore o il gestore cloud può agire come responsabile. Le prime ore richiedono perciò anche la lettura degli accordi sul trattamento, dei contatti di data breach e delle informazioni che il responsabile deve fornire al titolare.
Le linee guida EDPB individuano la conoscenza quando l’organizzazione raggiunge un ragionevole grado di certezza che l’incidente di sicurezza abbia compromesso dati personali. Questo criterio dialoga bene con l’impostazione della Commissione sul CRA. Conviene adottare un’unica cronologia fattuale e motivare separatamente le conclusioni su prodotto, servizio e persone.
Un solo fascicolo tecnico, decisioni giuridiche separate
Tre procedure indipendenti non richiedono tre indagini scollegate. Il SOC, il PSIRT, lo sviluppo, il legale e il DPO dovrebbero lavorare sullo stesso nucleo di fatti: ora della prima evidenza, prodotto e versioni, componente coinvolto, modalità di sfruttamento, sistemi o installazioni colpite, effetti sui servizi, dati personali interessati, misure già applicate e comunicazioni inviate.
Su questa base comune si innestano decisioni diverse. Il registro CRA documenta la presenza nel prodotto, l’attiva exploitation e la gravità dell’incidente di prodotto. Il percorso NIS2 valuta l’impatto sulla fornitura dei servizi del soggetto. Il fascicolo GDPR misura il rischio per le persone e conserva anche le ragioni di un’eventuale mancata notifica.
La coerenza non coincide con il copia e incolla. Una comunicazione CRA può contenere dettagli tecnici estremamente sensibili su una falla ancora priva di patch. La notifica NIS2 può richiedere indicatori utili alla difesa della rete. Il Garante ha bisogno di categorie e volumi di dati, conseguenze per gli interessati e misure adottate. Ogni destinatario deve ricevere ciò che serve per il proprio compito, partendo dalla stessa timeline.
Le comunicazioni esterne meritano un coordinamento ulteriore. Il CRA impone di informare gli utenti coinvolti e può richiedere un messaggio a tutti gli utilizzatori. Il GDPR può imporre una comunicazione agli interessati. La NIS2 contempla, in determinate circostanze, informazioni ai destinatari dei servizi. Testi predisposti da funzioni diverse, pubblicati in momenti diversi, possono contraddirsi o rivelare dettagli che il CSIRT ha deciso di trattenere temporaneamente. Un piccolo comitato di crisi, con poteri di approvazione già definiti, riduce questo rischio.
Un runbook da provare prima dell’11 settembre
- Attivare un canale che riceva segnalazioni di clienti, ricercatori, fornitori e fonti di threat intelligence anche fuori dall’orario lavorativo.
- Svolgere subito la valutazione iniziale e registrare il momento in cui emerge un ragionevole grado di certezza sui fatti.
- Collegare l’evidenza al prodotto, alla build, alle versioni e ai componenti mediante SBOM, repository degli artefatti e dati di distribuzione.
- Eseguire in parallelo le tre verifiche: trigger CRA, significatività NIS2 e presenza di una violazione di dati personali con il relativo livello di rischio.
- Identificare il CSIRT coordinatore CRA, il rappresentante assegnato sulla SRP e il suo backup; mantenere separati i contatti NIS2 e privacy.
- Preparare il preallarme con fatti confermati, Stati membri interessati e prime misure, distinguendo chiaramente ciò che è ancora in valutazione.
- Aggiornare entro 72 ore il record tecnico e le notifiche applicabili, coordinando anche gli avvisi a utenti, clienti e interessati.
- Governare le scadenze finali: 14 giorni dalla disponibilità della correzione per la vulnerabilità CRA, un mese dalla notifica per l’incidente grave CRA e per il percorso NIS2, più gli aggiornamenti privacy necessari.
- Una simulazione rivela rapidamente dove il processo si ferma. Spesso il problema compare prima della compilazione: il team non conosce il Paese dello stabilimento principale, nessuno dispone dell’elenco aggiornato delle versioni in uso, il contratto concede al fornitore più tempo di quanto il fabbricante abbia per notificare, oppure l’approvazione del testo dipende da una persona irraggiungibile nel fine settimana.
La prova arriva prima della marcatura CE
L’11 settembre 2026 segna l’ingresso della sicurezza di prodotto nel ritmo dell’incident reporting europeo. La Single Reporting Platform riduce le comunicazioni CRA verso i diversi Stati a un solo ingresso e affida al CSIRT coordinatore la distribuzione delle informazioni. Fuori da quel perimetro continuano a vivere NIS2 e GDPR, con logiche proprie.
Il fabbricante preparato sa trasformare pochi log in una verifica tracciata, individua in fretta i prodotti coinvolti e comunica ciò che conosce senza nascondere le incertezze residue. Sa anche mantenere coerenti i messaggi diretti a ENISA, CSIRT, autorità NIS, Garante, clienti e utenti.
Una procedura lunga non garantisce questo risultato. Una table-top exercise svolta su una vulnerabilità reale della supply chain mostra molto di più: chi riceve l’allarme, chi fissa il momento della conoscenza, chi decide il trigger e chi preme il pulsante entro 24 ore. Dopo l’11 settembre, queste domande arriveranno insieme all’incidente.
Fonti essenziali
- Regolamento (UE) 2024/2847 – Cyber Resilience Act, testo ufficiale italiano
- Commissione europea, Cyber Resilience Act – Reporting obligations, aggiornamento 31 luglio 2026
- Commissione europea, C(2026) 5252 e linee guida sull’applicazione del CRA, 27 luglio 2026
- ENISA, Single Reporting Platform
- ENISA, FAQ sulla Single Reporting Platform, aggiornamento 3 agosto 2026
- ENISA, guida per la presentazione e l’aggiornamento delle notifiche, aggiornamento 3 agosto 2026
- Direttiva (UE) 2022/2555 – NIS2, testo ufficiale
- Decreto legislativo 4 settembre 2024, n. 138, Gazzetta Ufficiale
- Regolamento (UE) 2016/679, articoli 33 e 34
- EDPB, Linee guida 9/2022 sulla notifica delle violazioni di dati personali
- Garante per la protezione dei dati personali, Data breach
Partecipa alla community