Un tecnico riceve una segnalazione credibile su un prodotto. Il responsabile sicurezza raccoglie informazioni. L’ufficio legale chiede quali obblighi possano scattare. Nel frattempo qualcuno cerca la persona autorizzata a inviare la comunicazione. È uno scenario ipotetico, ma utile per una domanda concreta: la vostra procedura sa già chi deve decidere?
Al 12 ottobre 2026, non tutte le disposizioni del Cyber Resilience Act sono applicabili. Il calendario generale distingue l’applicazione principale dall’11 dicembre 2027 e le segnalazioni dell’articolo 14 dall’11 settembre 2026. Il CRA riguarda prodotti con elementi digitali nel proprio ambito: non rende ogni impresa informatica automaticamente soggetta a ogni obbligo. Sintesi della Commissione.
Per i fabbricanti interessati, vulnerabilità attivamente sfruttate e incidenti gravi che incidono sulla sicurezza del prodotto hanno un percorso di segnalazione: preallarme entro 24 ore dalla conoscenza, notifica entro 72 ore. Per la relazione finale, le vulnerabilità hanno il termine di 14 giorni dalla disponibilità di una misura correttiva; gli incidenti gravi quello di un mese dalla notifica delle 72 ore. La comunicazione passa dalla Single Reporting Platform. Commissione, obblighi di segnalazione.
Il punto operativo non è soltanto impostare un timer. È organizzare le informazioni che consentono di stabilire se ci troviamo davanti al fatto rilevante per quell’obbligo.
Propongo tre passaggi, come traccia di lavoro e non come elenco normativo esaustivo.
Prima: identificare il ruolo. Il dossier del prodotto dovrebbe spiegare chi lo immette sul mercato sotto il proprio nome, chi riceve le segnalazioni e chi può coinvolgere le funzioni competenti. La denominazione commerciale del rapporto non basta: occorre valutare il ruolo effettivo e il perimetro applicabile.
Poi: conservare la cronologia. Tenere traccia di cosa è arrivato, quando, attraverso quale canale e con quali verifiche. La registrazione aiuta a ricostruire il percorso; non decide da sola il momento giuridico della conoscenza. Una casella piena o una segnalazione parcheggiata non dovrebbero diventare il normale filtro delle informazioni importanti.
Infine: provare il percorso. Usare un caso simulato per verificare reperibilità, sostituzioni e accesso ai canali. Se serve il consenso di una sola persona che può essere assente, la procedura dovrebbe prevedere come affrontare quell’assenza. Il test non garantisce conformità: rende visibili alcuni ostacoli.
NIS2 guarda, invece, alla sicurezza di reti e sistemi dei soggetti nel proprio ambito e agli incidenti significativi. Il CRA e NIS2 possono incontrarsi nello stesso evento, ma hanno presupposti e destinatari distinti: una segnalazione effettuata per un regime non dimostra automaticamente di avere adempiuto all’altro. Commissione, NIS2.
Questa distinzione suggerisce una matrice interna: evento, prodotti o servizi coinvolti, ruolo dell’organizzazione, regime da valutare, responsabile della decisione e canale. È una proposta editoriale di organizzazione, da adattare al caso e alla disciplina nazionale pertinente.
C’è anche un collegamento con il tema umano discusso nell’altro articolo di oggi: una procedura non dovrebbe richiedere alla prima persona che nota qualcosa di fornire subito una ricostruzione perfetta. La segnalazione iniziale e l’analisi specialistica sono fasi diverse. Rendere la prima accessibile può essere una scelta sensata da sperimentare; non modifica i termini di legge.
Le prime 24 ore si preparano assegnando responsabilità e provando il percorso prima che serva. La domanda utile, oggi, è chi riceverebbe la prossima informazione importante e cosa farebbe subito dopo.
Contenuto divulgativo: l’applicabilità al caso concreto richiede una valutazione dei ruoli e delle norme pertinenti.