Le risposte al Cyber Resilience Act ora citano l'articolo

Il 11 settembre 2026 è entrato in vigore l'obbligo di segnalazione previsto dall'articolo 14 del Cyber Resilience Act. Da quella data, un produttore di un prodotto con elementi digitali che viene a conoscenza di una vulnerabilità attivamente sfruttata in quel prodotto è tenuto a inviare un preavviso entro 24 ore, una notifica più completa entro 72 ore e una relazione finale entro: 14 giorni per una vulnerabilità una volta disponibile una misura correttiva, un mese per un incidente grave (Regolamento (UE) 2024/2847, articoli 14 e 71).

Un obbligo con una scadenza di 24 ore trasforma una risposta approssimativamente corretta in una responsabilità. Le domande che arrivano una volta attiva la scadenza sono specifiche, non tematiche. Il prodotto conta come un prodotto con elementi digitali? In quale classe rientra e quale percorso di conformità ne deriva? Qual è il CSIRT di riferimento e dove inviare la segnalazione? Una risposta plausibile ma errata in merito alla disposizione è peggiore di nessuna risposta, perché si agisce in base ad essa.

Il CRA è anche il contesto in cui un assistente generico mostra i suoi limiti. Il regolamento è entrato in vigore il 10 dicembre 2024, abbastanza recente da rendere scarsa la memoria del modello sul suo testo, e la sua applicazione è sfalsata secondo l'articolo 71 in modo da cogliere anche gli addetti ai lavori che si basano sulla data sbagliata: la data principale di applicazione del 11 dicembre 2027, quando entrano in vigore i requisiti essenziali, la valutazione della conformità e la marcatura CE, è quella più spesso citata nei roadmap, e cade oltre un anno dopo l'obbligo di segnalazione che già vincola i produttori.

Prima, e ora

Fino a questa release, il CRA non era uno dei pacchetti di framework curati dall'assistente. Una domanda sul CRA veniva risposta seguendo lo stesso percorso generale di qualsiasi altra domanda: conoscenza del modello, senza citazioni a livello di articolo su cui basarsi. Per GDPR, DORA, UK GDPR e CCPA/CPRA avevamo già risolto il problema con pacchetti che citano il paragrafo e il punto. Il CRA rappresentava il gap, e il gap si trovava esattamente sulla scadenza che era già attiva.

Quello che è stato distribuito a settembre 2026 è un pacchetto di conoscenza curato per il Regolamento (UE) 2024/2847, verificato rispetto al testo ufficiale, che copre tutti i 71 articoli a livello di articolo, con suddivisione a livello di punto dove il consiglio dipende da esso:

• Articolo 13, gli obblighi del produttore: periodo di supporto e impegni relativi agli aggiornamenti di sicurezza, un unico punto di contatto, una politica di disclosure coordinata delle vulnerabilità.
• Articolo 14, la cascata di segnalazione e le sue scadenze, inclusa la definizione di incidente grave.
• Articoli 15 a 17, segnalazione volontaria e la piattaforma unica di segnalazione ENISA.
• Articoli 18 a 26, importatori, distributori, modifiche sostanziali e responsabili del software open source.
• Articoli 27 a 34, i percorsi di conformità e la suddivisione tra prodotti di classe I, classe II e prodotti critici.
• Articolo 64, le fasce di sanzioni, che arrivano fino a 15 milioni di euro o il 2,5% del fatturato annuo mondiale totale per le violazioni più gravi.
• La copertura degli allegati: Allegato I requisiti essenziali e obblighi di gestione delle vulnerabilità, Allegato II informazioni per l'utente, Allegato III classi di prodotti e Allegato IV elenchi dei prodotti critici, e Allegato VII documentazione tecnica.

Ogni riga riporta l'attore a cui si applica, seguendo la tassonomia del regolamento: produttore, importatore, distributore, responsabile del software open source, rappresentante autorizzato, organismo notificato, autorità di sorveglianza del mercato, CSIRT, ENISA. Un importatore che chiede se un obbligo lo riguardi riceve una risposta che cita l'articolo e specifica di chi sia l'obbligo, piuttosto che un riassunto scritto dal punto di vista del produttore.

Cosa non attiva "CRA"

Un dettaglio della stessa settimana mostra come si comporta il pacchetto nella pratica. CRA non è un acronimo sicuro: può significare anche credit rating agency, il Community Reinvestment Act statunitense e l'Canada Revenue Agency. L'assistente non carica il pacchetto europeo su una semplice menzione di CRA; la domanda stessa deve contenere un chiaro riferimento a un prodotto UE, quindi una banca che chiede informazioni sui suoi coefficienti patrimoniali o una domanda fiscale sull'Agenzia delle Entrate canadese non riceve un pacchetto di sicurezza dei prodotti europei iniettato nella risposta. Questo controllo di collisione è stato distribuito come fix nella stessa settimana del pacchetto stesso.

A chi è rivolto

Produttori di prodotti con elementi digitali venduti nell'UE, importatori e distributori che commercializzano tali prodotti e responsabili del software open source che devono decidere se il regolamento li riguardi. Inoltre, i responsabili GRC e i consulenti che rispondono alle loro domande, incluse le squadre il cui ambito ISO 27001 non ha mai toccato la normativa sui prodotti e che ora si trovano con un obbligo di segnalazione in calendario. Il pacchetto è disponibile nel registro condiviso dei framework, quindi gli stessi riferimenti vengono restituiti tramite API ed embed, e heyGRC risponde alle domande sul CRA con essi.

Rimangono due limiti. Si tratta di conoscenza di riferimento per orientamento, non di un parere legale, e le risposte citano la disposizione su cui si basano. E questo post non è il riferimento stesso: l'argomento strategico, il motivo per cui la scadenza del 2026 prevale su quella del 2027 nella pianificazione, è disponibile in Il CRA è un problema del 2026, non del 2027. Gli obblighi completi e la tempistica, inclusa la scadenza dell'articolo 71 e la tabella di segnalazione dell'articolo 14, sono disponibili nella guida agli obblighi e alla tempistica del Cyber Resilience Act, e la domanda "si applica anche a noi" trova risposta nel CRA applicability checker.