Lo stesso incidente, tre notifiche e tre orologi diversi

Il Cyber Resilience Act — regolamento (UE) 2024/2847 del Parlamento europeo e del Consiglio, in vigore dal 10 dicembre 2024 — viene raccontato quasi sempre come una scadenza del 2027. Per la marcatura CE, i requisiti essenziali di sicurezza e la documentazione tecnica è esatto: si applicano dall’11 dicembre 2027. Ma il regolamento non entra in funzione tutto insieme, e il primo blocco che tocca davvero le aziende arriva adesso: dall’11 settembre 2026 valgono gli obblighi di segnalazione dell’articolo 14 del regolamento. Non riguardano i prodotti futuri. Riguardano quelli che avete già venduto.

Che cosa scatta l’11 settembre, e su quali prodotti

L’obbligo è del fabbricante di prodotti con elementi digitali, e la categoria è più larga di quanto suggerisca la parola: comprende il software venduto come tale, non solo l’oggetto fisico che lo contiene. Comprende anche chi immette un prodotto sul mercato sotto il proprio nome o il proprio marchio, che il regolamento tratta come fabbricante a tutti gli effetti. Se rivendete a marchio vostro un componente costruito da altri, l’obbligo di segnalare è vostro, non del costruttore.

Gli eventi da segnalare sono due, e vanno tenuti distinti perché hanno presupposti diversi: la vulnerabilità attivamente sfruttata contenuta nel prodotto, e l’incidente grave che incide sulla sicurezza del prodotto stesso. La segnalazione si fa una volta sola, attraverso la piattaforma unica gestita dall’ENISA, indirizzandola al CSIRT dello Stato in cui si trova lo stabilimento principale; da lì l’informazione raggiunge l’ENISA e gli altri CSIRT interessati.

I tempi sono tre e si contano dal momento in cui l’evento è noto, non da quando è stato compreso:

• Allerta precoce, entro 24 ore. Basta segnalare che qualcosa è successo. Non serve avere capito che cosa.
• Notifica, entro 72 ore. La descrizione dell’evento, per quanto se ne sa a quel punto.
• Relazione finale. Quattordici giorni per la vulnerabilità attivamente sfruttata, un mese per l’incidente grave.

Il punto che cambia il calcolo è l’ambito di applicazione: gli obblighi di segnalazione valgono anche per i prodotti immessi sul mercato prima dell’11 dicembre 2027. Non c’è, quindi, la divisione che molte aziende hanno in mente fra un parco vecchio da lasciar finire e una linea nuova da mettere a norma. Se un prodotto che avete venduto nel 2022 è ancora in circolazione e qualcuno ne sfrutta una vulnerabilità, l’orologio parte lo stesso.

Un evento solo, tre orologi che partono insieme

Quasi tutte le aziende che incontro hanno una procedura di gestione degli incidenti. Quasi tutte l’hanno scritta sul GDPR, perché il GDPR è arrivato per primo. Il risultato è una procedura che si attiva quando ci sono di mezzo dati personali e che dà per scontato un termine di settantadue ore. Il Cyber Resilience Act non chiede né l’una né l’altra cosa.

Le tre discipline non si escludono: si sommano sullo stesso fatto. Un firmware difettoso in un dispositivo che non tratta dati personali fa scattare il solo Cyber Resilience Act. Lo stesso firmware in un dispositivo che raccoglie dati dei clienti può farne scattare tre insieme, con tre destinatari diversi e la prima scadenza a ventiquattro ore. Chi ha una procedura sola, e tarata sulle settantadue, in quel caso è già in ritardo di due giorni al momento in cui la apre.

Chi decide che la vulnerabilità è «attivamente sfruttata»

C’è un presupposto silenzioso in tutto questo: per segnalare entro ventiquattro ore bisogna sapere entro ventiquattro ore. L’obbligo di segnalazione presuppone quindi qualcosa che molte aziende non hanno: un canale per ricevere le segnalazioni dall’esterno — dai clienti, dai ricercatori, dai fornitori dei componenti — e qualcuno che le legga in tempo utile.

La qualificazione è il passaggio delicato. Stabilire che una vulnerabilità è attivamente sfruttata, e non soltanto nota, non è una valutazione puramente tecnica: fa partire un termine di legge e apre una responsabilità. Dove la decisione è lasciata al singolo tecnico che riceve la mail, senza un criterio scritto e senza qualcuno a cui passarla, non c’è una scelta prudente: c’è il caso.

Va detto che il perimetro di «attivamente sfruttata» ha un margine di apprezzamento reale, e che una prassi applicativa non esiste ancora: su questo punto il regolamento si applica dall’11 settembre. In questa fase la scelta difendibile non è quella più restrittiva o più estensiva, ma quella documentata: chi ha deciso, quando, sulla base di quali elementi.

Che cosa serve avere in piedi

Quattro cose, in ordine di urgenza, e nessuna delle quattro richiede mesi.

1. Una procedura unica di gestione dell’evento, tarata sull’orologio più corto — le ventiquattro ore — con la triplice diramazione verso CSIRT, Garante e clienti decisa a monte e non nel momento in cui serve.
2. L’elenco dei prodotti che avete immesso sul mercato e sono ancora in circolazione, con le versioni che sostenete e quelle che non sostenete più. Senza questo elenco non sapete su che cosa si estende l’obbligo.
3. Le clausole a monte, verso chi vi fornisce i componenti software di terzi: chi avvisa chi, entro quante ore, e con quali conseguenze se non avvisa. Il vostro termine di ventiquattro ore non si allunga perché il fornitore vi ha avvisati tardi. È lo stesso ordine di problema di cui ho scritto a proposito dei documenti che i clienti iniziano a chiedere.
4. Un registro delle decisioni: ogni qualificazione, con data, autore e motivo. È la sola cosa che, a distanza di un anno, dimostra che una valutazione c’è stata.

Nessuno di questi quattro punti è un progetto: sono un documento, un elenco, una clausola e un foglio. Il costo di farli adesso è una settimana di lavoro. Il costo di farli il giorno in cui arriva la prima segnalazione è di un altro ordine, e si paga davanti a un’autorità che nel frattempo ha già contato le ore.