Per anni la cybersecurity in molte aziende ha seguito una logica a progetto: un assessment, un piano di interventi, una certificazione, una data di chiusura. NIS2 e Cyber Resilience Act (CRA) rendono questo modello insufficiente. Presi singolarmente sono due adempimenti in più. Letti insieme dicono una cosa più radicale: la sicurezza è un processo continuo, misurabile e soggetto a verifica esterna. Non siamo di fronte a una semplice evoluzione burocratica, ma a un vero e proprio cambio di paradigma operativo che ridefinisce le responsabilità legali, industriali e reputazionali del mondo produttivo.
Il tempismo non è casuale: dall’11 settembre 2026 i fabbricanti sono tenuti a rispettare gli obblighi di segnalazione del CRA, anche per i prodotti già in commercio, mentre la piena applicazione del regolamento scatterà l’11 dicembre 2027. In Italia, intanto, il D.Lgs. 138/2024 di recepimento della NIS2 è entrato nella sua fase operativa sotto la supervisione dell’Agenzia per la Cybersicurezza Nazionale (ACN).
Indice degli argomenti
NIS2 e Cyber Resilience Act: due sguardi sullo stesso problema
La NIS2 guarda all’organizzazione e ai servizi che eroga; il CRA guarda ai prodotti con elementi digitali che vengono immessi sul mercato. Il punto in cui si incontrano è la filiera: chi è soggetto a NIS2 deve governare il rischio dei propri fornitori, e il CRA impone a chi fabbrica hardware e software requisiti di sicurezza verificabili.
Non è la prima volta che la sicurezza di ciò che si acquista entra nel diritto: il GDPR chiedeva già garanzie ai responsabili del trattamento, e dall’agosto 2025 gli apparecchi radio devono rispettare requisiti di cybersecurity per la marcatura CE. Ma è la prima volta che la domanda “quanto è sicuro ciò che compro?” trova una risposta giuridica sistematica, estesa a quasi tutti i prodotti digitali.
Le due norme condividono anche una logica: tempi di notifica stretti, responsabilità chiare, evidenze documentate. È da qui che nascono i cambi di approccio che contano davvero, trasformando l’ICT security da presidio puramente informatico a colonna portante della resilienza operativa.
I cinque cambi d’impresa imposti da NIS2 e Cyber Resilience Act
Il primo riguarda la governance. La NIS2 chiede agli organi di amministrazione di approvare le misure di gestione del rischio, di sovrintendere l’attuazione e di risponderne in caso di violazione. La sicurezza esce così dal perimetro del reparto IT ed entra nell’agenda del consiglio come rischio d’impresa di primario livello.
Gli amministratori delegati e i membri del CDA non possono più limitarsi ad ratificare le spese: sono tenuti a frequentare corsi di formazione specifica e, nei casi più gravi, per i soggetti essenziali la normativa prevede persino la sospensione temporanea dalle funzioni dirigenziali. Servono una reportistica comprensibile per chi non è tecnico, un monitoraggio costante degli indicatori di rischio e un legame esplicito tra rischio cyber, continuità operativa e strategia industriale.
La filiera e la due diligence sui fornitori
Il secondo è il passaggio dal perimetro alla filiera. La due diligence sui fornitori cambia natura: dichiarazioni di conformità CRA, periodo di supporto garantito, distinta dei componenti software e processi di gestione delle vulnerabilità diventano requisiti ordinari nei capitolati d’acquisto. La distinta dei componenti software (SBOM), che il CRA impone ai fabbricanti di redigere e mettere a disposizione delle autorità, entrerà sempre più spesso nelle richieste contrattuali dei clienti.
Per i fornitori di servizi, che il CRA non copre, la leva resta quella contrattuale che la NIS2 impone ai propri clienti di esercitare. L’effetto si propaga a cascata anche alle piccole e medie imprese che non rientrano direttamente nei criteri dimensionali della NIS2. I loro clienti soggetti agli obblighi chiederanno garanzie formali e verificabili: chi non sa fornirle rischia di essere estromesso dai contratti di fornitura, trasformando la resilienza in un fattore bloccante per il fatturato.
Sicurezza per l’intero ciclo di vita del prodotto
Il terzo è la sicurezza per tutto il ciclo di vita. Il CRA supera definitivamente l’idea del prodotto “sicuro al rilascio”: impone di progettare la sicurezza fin dalla fase ideativa (security by design e by default), conoscere meticolosamente i componenti di terze parti e open source e garantire aggiornamenti tempestivi per l’intero periodo di supporto dichiarato.
Gli obblighi di segnalazione si estendono anche ai prodotti già in commercio da anni. Per chi sviluppa software e hardware connesso significa integrare davvero le pratiche DevSecOps nelle catene di montaggio digitali, mantenere una SBOM (Software Bill of Materials) costantemente aggiornata e dotarsi di un processo strutturato di gestione delle vulnerabilità, con una politica di divulgazione coordinata e un punto di contatto per le segnalazioni esterne.
Nelle aziende più grandi questo prende la forma di un PSIRT (Product Security Incident Response Team), una funzione finora diffusa soprattutto tra i grandi vendor; nelle PMI può essere un processo più snello, purché reale. Quello che non è più tollerabile è il silenzio: una vulnerabilità attivamente sfruttata va segnalata alle autorità nei tempi previsti e corretta, anche quando la sua divulgazione pubblica viene legittimamente coordinata e posticipata fino alla disponibilità della patch.
Tempi e canali della risposta agli incidenti
Il quarto riguarda la risposta agli incidenti, che diventa un processo rigorosamente regolato e cronometrato. Entrambe le norme prevedono una prima segnalazione d’allerta (early warning) entro 24 ore dall’individuazione dell’evento e una notifica più completa con analisi di impatto entro 72 ore, ma su oggetti e canali diversi.
La NIS2 riguarda gli incidenti significativi che colpiscono i servizi dell’organizzazione, da notificare al CSIRT nazionale (in Italia CSIRT Italia, presso l’ACN) con una relazione finale entro un mese. Il CRA riguarda le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza di un prodotto, da notificare tramite la piattaforma unica gestita dall’ENISA, con relazione finale entro 14 giorni dalla disponibilità della correzione per le vulnerabilità ed entro un mese per gli incidenti.
Chi riceve l’allarme, chi lo valuta, chi ha l’autorità legale per notificare alle autorità nazionali competenti: domande banali in astratto, ma decisive quando un attacco si palesa il venerdì sera. Un fabbricante che è anche soggetto NIS2 può doversi trovare a gestire più regimi di notifica paralleli per lo stesso evento, a cui si somma il GDPR, con la notifica al Garante entro 72 ore in caso di violazione di dati personali.
A livello europeo si discute di un punto di accesso unico per ridurre le duplicazioni, ma anche in quello scenario soglie, contenuti e scadenze resterebbero distinti. I processi interni vanno quindi disegnati per reggere la pressione di più canali, non per sperare che il legislatore semplifichi le cose.
Dalla compliance documentale alla dimostrabilità
Il quinto cambio è il più profondo: dalla compliance documentale alla dimostrabilità. Nessuna delle due norme si accontenta di policy ben scritte o di manuali riposti nei cassetti. Contano le evidenze oggettive: log di sistema immutabili, registri delle vulnerabilità censite, test d’impatto e di ripristino (disaster recovery), verbali delle decisioni del vertice. Un processo di notifica o un piano di continuità mai esercitato tramite simulazioni sul campo è un processo che semplicemente non esiste. È un cambio culturale prima ancora che tecnologico.
Un sistema integrato per NIS2, CRA e gli altri framework
Per chi opera su più fronti, il rischio concreto è la moltiplicazione paralizzante dei framework: NIS2, CRA, DORA per il settore finanziario, GDPR, fino al più recente AI Act. Affrontarli uno alla volta produce inevitabilmente duplicazioni di costi, inefficienze operative e pericolose contraddizioni. La risposta più intelligente ed efficiente è la creazione di un unico sistema integrato di controlli, mappato una volta sola sui diversi requisiti normativi. Ne derivano una sola catena di responsabilità aziendale e un solo processo di gestione degli incidenti, capace di alimentare tempestivamente più canali di notifica.
In pratica si parte da un inventario affidabile e dinamico di asset, servizi, prodotti e fornitori. Poi si assegnano ruoli chiari, con un referente per la sicurezza e un responsabile delle notifiche con delega esplicita di potere. Infine si esercita periodicamente la catena decisionale con simulazioni realistiche di attacco (red teaming e tabletop exercise). Nulla di concettualmente nuovo per chi segue da anni gli standard ISO/IEC; la differenza sostanziale è che ora queste pratiche sono vincolanti e sanzionabili da un’autorità di vigilanza.
NIS2 e CRA come leva competitiva per le imprese
C’è una dimensione di mercato che va ben oltre il timore delle sanzioni pecuniarie. Con la piena applicazione del CRA, la conformità alla sicurezza diventa condizione imprescindibile per la marcatura CE dei prodotti con elementi digitali: senza questo requisito, un dispositivo semplicemente non può essere venduto all’interno dell’Unione Europea. Parallelamente, nelle filiere guidate dalla NIS2, la capacità di dimostrare un livello di sicurezza maturo diventa il principale criterio di selezione dei partner commerciali.
Chi arriva preparato non rispetta soltanto una norma di legge: blinda il proprio valore di mercato ed entra di diritto in una lista corta di fornitori affidabili. Il messaggio che arriva con chiarezza dal regolatore europeo è univoco: la sicurezza non è una fotografia che si scatta una volta all’anno, ma un muscolo aziendale che si esercita ogni giorno. Le imprese che lo hanno compreso smettono di chiedersi quanto costa adeguarsi e iniziano a valutare quanto vale, sul mercato globale, essere davvero pronte.
Partecipa alla community