Chi ha iniziato a lavorare sul CRA ha messo a fuoco un oggetto preciso: il prodotto. Requisiti essenziali, gestione delle vulnerabilità, SBOM, periodo di assistenza. Tutto ruota intorno al dispositivo che immetti sul mercato. Ma c’è una seconda norma che guarda un oggetto diverso, la tua azienda, e per buona parte dei produttori di dispositivi si applica in parallelo al CRA: la NIS2. Sono due obblighi distinti, con destinatari e canali diversi, e chi ha in testa solo il primo si accorge del secondo tardi.
Il CRA (Regolamento UE 2024/2847) è una legge di sicurezza del prodotto. La NIS2 (Direttiva UE 2022/2555, in Italia recepita dal D.Lgs. 138/2024) è una legge sulla sicurezza dei sistemi dell’organizzazione. Non sono due versioni della stessa cosa: il quadro completo, con oggetto, forma giuridica e destinatari a confronto, è nella guida NIS2, DORA e CRA a confronto. Qui parto da una domanda sola: se fabbrichi dispositivi e sei già dentro il CRA, la NIS2 ti riguarda anche come azienda?
Quando NIS2 ti riguarda come azienda
Per molti produttori di dispositivi la risposta è sì, e il motivo sta in due criteri combinati previsti dall’art. 3 della NIS2: il settore e la dimensione.
Sul settore: l’Allegato II della NIS2 include la fabbricazione, e tra i comparti elenca la fabbricazione di dispositivi medici, di computer e prodotti di elettronica e ottica, di apparecchiature elettriche, di macchinari e apparecchiature. Chi costruisce centraline, sensori, gateway, quadri, macchine connesse ricade con ogni probabilità in uno di questi comparti.
Sulla dimensione: la soglia di riferimento è quella della media impresa, a partire da 50 dipendenti oppure oltre 10 milioni di euro di fatturato o di totale di bilancio (Raccomandazione 2003/361/CE). Un fabbricante di quei settori che supera la soglia rientra, di norma, tra i “soggetti importanti”.
In concreto: lo stesso prodotto che ti rende soggetto al CRA come fabbricante può rendere la tua azienda soggetto NIS2 in quanto impresa manifatturiera di un settore dell’Allegato II. Sono due qualifiche che nascono da due criteri diversi, il prodotto per il CRA, il settore più la dimensione per la NIS2, e non è detto che chi presidia la prima si sia accorto della seconda.
Cosa chiede la NIS2, e quanta parte hai già fatto
La NIS2 non chiede documentazione sul prodotto. Chiede misure di gestione del rischio in capo all’azienda, elencate all’art. 21, par. 2: dalle politiche di analisi del rischio alla gestione degli incidenti, dalla continuità operativa alla sicurezza della catena di approvvigionamento, dall’igiene informatica al controllo degli accessi.
Due di queste misure toccano esattamente il lavoro che il CRA ti impone già sul prodotto:
- la sicurezza della catena di approvvigionamento, compresi gli aspetti relativi ai rapporti con i fornitori diretti (art. 21, par. 2, lett. d);
- la sicurezza dell’acquisizione, sviluppo e manutenzione dei sistemi, compresa la gestione e la divulgazione delle vulnerabilità (art. 21, par. 2, lett. e).
Sono gli stessi processi che il CRA chiede per il prodotto: il ciclo di sviluppo sicuro, la SBOM (Software Bill of Materials, l’inventario dei componenti software), la gestione coordinata delle vulnerabilità (Allegato I, parte II, del CRA). L’impianto che costruisci per marcare CE produce evidenza spendibile anche per l’art. 21 della NIS2. Chi possiede questi processi e sa generarne evidenza documentata si trova una parte del lavoro NIS2 già in cascina.
Quello che il CRA non copre, e che la NIS2 aggiunge, è tutto ciò che riguarda l’azienda e non il prodotto: la continuità operativa e il ripristino (lett. c), l’igiene informatica e la formazione del personale (lett. g), il controllo degli accessi e la gestione degli asset interni (lett. i), l’autenticazione a più fattori sui tuoi sistemi (lett. j). Sono i sistemi con cui progetti, produci e gestisci l’azienda, non quelli che vendi. Il CRA non li tocca.
Due notifiche per due oggetti diversi
Il punto in cui i due obblighi non si fondono, e dove sbagliare costa, è la notifica.
Il CRA impone di notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi che riguardano la sicurezza del prodotto, al CSIRT coordinatore e ad ENISA, con preallarme entro 24 ore (art. 14). La NIS2 impone al soggetto di notificare gli incidenti significativi che impattano l’erogazione dei suoi servizi, al CSIRT nazionale, anch’essa con preallarme entro 24 ore e notifica entro 72 (art. 23).
Trigger diverso, destinatario in parte diverso. Il canale CRA si attiva su un problema del prodotto; il canale NIS2 su un incidente che colpisce l’operatività dell’azienda. Un ransomware che ferma la tua produzione è un caso NIS2, non CRA. Una vulnerabilità sfruttata nel firmware che hai spedito ai clienti è un caso CRA. Un incidente può, in teoria, far scattare entrambi. Le scadenze e il funzionamento del canale CRA sono nella guida alla Single Reporting Platform; quando una segnalazione diventa notifica, in Da segnalazione a notifica.
Nota operativa (mia lettura, non testo di legge). La cosa efficiente è un solo processo interno di gestione degli incidenti e delle vulnerabilità, con un ramo che sa quando instradare al canale CRA (problema del prodotto) e quando al canale NIS2 (servizio dell’azienda). Un solo team, due destinazioni. Tenere separati i due processi porta a duplicare il lavoro e, peggio, a mancare uno dei due orologi quando l’evento li fa scattare entrambi.
E DORA?
DORA (Regolamento UE 2022/2554) quasi mai ti riguarda come soggetto diretto: si applica alle entità finanziarie, non a un produttore di dispositivi. Ti raggiunge se vendi al settore finanziario, e per via contrattuale: il cliente banca o assicurazione deve trasferirti per contratto i requisiti del Capo V di DORA (art. 30). Qui la conformità al CRA gioca a tuo favore, come base per superare la due diligence del cliente. È un capitolo a sé, che tratto in un articolo dedicato.
Un solo sistema, due mappe da tenere distinte
Il modo di guardarlo che consiglio ai produttori è questo: un unico sistema di gestione della sicurezza, che genera evidenza riusabile su più fronti. Il ciclo di sviluppo sicuro e la gestione delle vulnerabilità che costruisci per il CRA coprono parte dell’art. 21 della NIS2; l’evidenza documentata che tieni per la vigilanza del mercato serve anche verso l’autorità NIS2.
Ciò che non si unifica, e va tenuto esplicito, sono due mappe. La mappa degli obblighi: il CRA finisce al prodotto, la NIS2 arriva ai tuoi sistemi interni, e la parte aziendale non la copre nessun lavoro fatto sul dispositivo. E la mappa delle notifiche e delle autorità: canali diversi, trigger diversi, destinatari in parte diversi. Il primo passo concreto è verificare se la tua azienda supera la soglia NIS2 nel suo comparto dell’Allegato II. Se la risposta è sì, il CRA è metà del lavoro, non tutto.
Riferimenti: Regolamento (UE) 2024/2847 (CRA), articoli 3 e 14 e Allegato I, parte II; Direttiva (UE) 2022/2555 (NIS2), articoli 3, 21 e 23 e Allegato II; Decreto legislativo 4 settembre 2024, n. 138; Regolamento (UE) 2022/2554 (DORA), articoli 2 e 30; Raccomandazione 2003/361/CE. Le note segnalate come operative sono mie interpretazioni, non testo normativo. Numeri di articolo verificati sui testi ufficiali.