Un incidente tecnico, tre domande diverse
Un cliente segnala al fabbricante l’esecuzione di comandi non autorizzati attraverso una funzione di un prodotto connesso. Il componente coinvolto compare nella distinta base del software, un fornitore terzo ha appena pubblicato un avviso di sicurezza e la patch correttiva è ancora in preparazione. Da questo singolo evento tecnico possono scaturire tre valutazioni giuridiche indipendenti. Per il Cyber Resilience Act occorre stabilire se esista una vulnerabilità attivamente sfruttata nel prodotto, oppure un incidente grave che ne comprometta la sicurezza. Se il fabbricante rientra anche nel perimetro NIS2 come soggetto essenziale o importante, la compromissione può integrare un incidente significativo per la resilienza dei suoi servizi. Se l’evento comporta accesso non autorizzato a dati personali, si attiva la disciplina del GDPR. Inviare una segnalazione su uno di questi canali non assorbe automaticamente gli obblighi verso gli altri due.
Un calendario rovesciato rispetto alla piena conformità
L’art. 14 del Regolamento (UE) 2024/2847 (Cyber Resilience Act) diventa applicabile l’11 settembre 2026, da quella data il fabbricante di prodotti con elementi digitali deve notificare le vulnerabilità attivamente sfruttate nei propri prodotti e gli incidenti gravi che ne compromettono la sicurezza. La valutazione di conformità, la documentazione tecnica e la marcatura CE, cioè il nucleo dei requisiti essenziali del CRA, troveranno invece piena applicazione solo dall’11 dicembre 2027. Il risultato è un calendario rovesciato rispetto a molti programmi aziendali di adeguamento: quindici mesi prima di dover dimostrare la conformità dei propri prodotti, le imprese devono già avere la capacità organizzativa di gestire una segnalazione che scade in ore. Le linee guida della Commissione del 27 luglio 2026 chiariscono peraltro che l’obbligo di segnalazione riguarda anche prodotti già immessi sul mercato prima dell’entrata in applicazione del Regolamento, e può permanere anche oltre la fine del supporto commerciale di una versione.
Due presupposti distinti, che possono sovrapporsi
Il CRA non impone di segnalare ogni vulnerabilità nota, ma distingue due presupposti autonomi. La vulnerabilità attivamente sfruttata è quella per cui esistono prove attendibili che un attore malevolo l’abbia utilizzata senza autorizzazione: la pubblicazione di un CVE o l’esistenza di un proof of concept aprono il triage interno, ma non dimostrano da soli che la soglia normativa sia stata raggiunta, perché la verifica deve restare ancorata al prodotto specifico e alla sua configurazione effettiva. L’incidente grave, invece, ricorre quando l’evento incide sulla capacità del prodotto di proteggere disponibilità, integrità, autenticità o riservatezza di dati o funzioni sensibili — pensiamo alla compromissione di un server di aggiornamento o di una chiave di firma del firmware. I due presupposti possono coesistere nello stesso evento, ed è un errore frequente esaminarne uno solo, lasciando scoperta una seconda comunicazione dovuta.
Il momento della conoscenza va ricostruito
Tutti i termini decorrono dalla conoscenza dell’evento da parte del fabbricante, ma un allarme automatico o la segnalazione di un ricercatore non equivalgono automaticamente a conoscenza piena. Le linee guida della Commissione collocano nel mezzo una valutazione iniziale, da svolgere con urgenza. La conoscenza matura quando si raggiunge un ragionevole grado di certezza sui fatti, un criterio esplicitamente raccordato con l’approccio seguito per NIS2 e con le linee guida dell’EDPB sulle violazioni di dati personali. Il fascicolo interno dovrebbe documentare con precisione l’ora della prima segnalazione, le verifiche compiute e il momento in cui tale certezza è stata raggiunta, una ricostruzione informale espone l’impresa a contestazioni difficilmente difendibili.
Le scadenze: 24 ore, 72 ore, e termini finali differenziati
Per la vulnerabilità attivamente sfruttata, il fabbricante trasmette un preallarme essenziale entro 24 ore, una notifica più completa entro 72 ore e una relazione finale entro 14 giorni dalla disponibilità di una misura correttiva non dal preallarme iniziale. Per l’incidente grave, la relazione finale è dovuta entro un mese dalla notifica delle 72 ore. Tutte le comunicazioni transitano attraverso la Single Reporting Platform gestita da ENISA, che le indirizza al CSIRT designato come coordinatore – di norma quello dello Stato membro in cui il fabbricante assume prevalentemente le proprie decisioni di cybersicurezza di prodotto – il quale le diffonde automaticamente agli altri CSIRT nazionali coinvolti. Va segnalato, con la dovuta cautela, che alla data di questo contributo permangono incertezze operative sulla piena disponibilità tecnica della piattaforma proprio a ridosso della scadenza del’11 settembre, circostanza che le imprese dovrebbero monitorare nelle prossime settimane.
NIS2 e GDPR restano percorsi autonomi
La Single Reporting Platform semplifica esclusivamente il flusso previsto dal CRA. Gli eventuali obblighi NIS2 – in Italia disciplinati dall’art. 25 del d.lgs. 138/2024, con analoga sequenza di 24 ore, 72 ore e un mese, ma soglie di “incidente significativo” riferite alla resilienza del servizio, non del prodotto – restano un percorso separato, verso il CSIRT Italia. Allo stesso modo, la violazione di dati personali resta disciplinata dagli artt. 33 e 34 del GDPR, con notifica al Garante entro 72 ore salvo rischio improbabile, e comunicazione agli interessati quando il rischio per i loro diritti sia elevato. Un’unica ricostruzione fattuale dell’incidente – orario, prodotto e versioni coinvolte, dati toccati, misure adottate – dovrebbe alimentare tre valutazioni giuridiche distinte, condotte da SOC, PSIRT, ufficio legale e DPO in stretto coordinamento, ma senza che la conclusione raggiunta su un fronte determini automaticamente quella sugli altri due.
Un runbook da testare prima della scadenza
La raccomandazione operativa più concreta, per qualunque fabbricante rientri nel perimetro del CRA, è di non attendere il primo incidente reale per scoprire dove il processo si inceppa. Una simulazione condotta su un caso realistico di compromissione della supply chain software rivela in poche ore i punti deboli che una procedura scritta non intercetta: spesso il problema emerge prima ancora della compilazione della notifica, quando il team scopre di non conoscere con certezza lo Stato membro dello stabilimento principale rilevante ai fini dell’individuazione del CSIRT coordinatore, oppure che nessuno dispone di un elenco aggiornato delle versioni del prodotto effettivamente in uso presso i clienti.
Conviene quindi identificare fin da ora il rappresentante che gestirà l’accesso alla Single Reporting Platform tramite EU Login, individuare un sostituto per le assenze, e mantenere separati – pur collegati sullo stesso nucleo di fatti – i contatti dedicati alle notifiche NIS2 e a quelle privacy. Le clausole contrattuali con fornitori e distributori dovrebbero inoltre garantire che le informazioni necessarie a rispettare il termine di 24 ore non dipendano da un fornitore che, per contratto, ha tempi di risposta più lunghi di quelli che il fabbricante deve rispettare a valle.
Una prova di maturità organizzativa, prima che tecnica
L’11 settembre 2026 segna l’ingresso della sicurezza di prodotto nel ritmo proprio dell’incident reporting europeo, quindici mesi prima che la gran parte degli altri obblighi del CRA diventi pienamente applicabile. Le imprese che avranno già chiarito, al proprio interno, chi decide il trigger normativo, chi cura il fascicolo tecnico comune e chi autorizza le comunicazioni esterne, affronteranno questa scadenza come un adempimento gestibile. Chi rinvia queste decisioni al momento dell’emergenza scoprirà, con ogni probabilità, che le ore più preziose della gestione di un incidente reale si consumano proprio nel dirimere una questione di governance interna che avrebbe potuto essere risolta a tavolino.
