Il panorama normativo europeo sulla sicurezza informatica ha subito, nel triennio 2022-2025, una trasformazione strutturale di rilievo storico.

A distanza di pochi anni dalla prima Direttiva NIS – che aveva introdotto i prodromi di un quadro comune di sicurezza cibernetica -, il legislatore dell’Unione ha scelto di intervenire con strumenti di intensità crescente, abbandonando la logica della mera armonizzazione minima in favore di un’architettura regolatoria stratificata, capace di presidiare sia i processi organizzativi delle imprese, sia la sicurezza intrinseca dei prodotti digitali.

In questo quadro si collocano due atti normativi destinati a incidere profondamente sulla postura di sicurezza delle organizzazioni: la Direttiva (UE) 2022/2555 – nota come NIS2 – recepita in Italia con il D.lgs. 4 settembre 2024, n. 138, e il Regolamento (UE) 2024/2847, comunemente denominato Cyber Resilience Act (CRA), pubblicato nella Gazzetta Ufficiale dell’Unione europea il 20 novembre 2024 ed entrato in vigore il 10 dicembre 2024.

A una analisi prima facie, le due fonti appaiono distinte per oggetto, destinatari e strumento normativo.

Tuttavia, una lettura sistematica rivela una fitta rete di sovrapposizioni operative che rende inefficiente – e potenzialmente lacunosa – una gestione compartimentale della compliance cyber.

È su tale intersezione che intendo soffermarmi, con l’obiettivo di offrire una lettura combinata delle due norme, utile per le organizzazioni chiamate ad adeguarsi ad entrambe.

Due normative, obiettivi distinti: il quadro di riferimento

La Direttiva NIS2 si colloca in una logica di resilienza organizzativa. Il suo obiettivo è garantire che le reti e i sistemi informativi delle organizzazioni operanti in settori critici mantengano livelli adeguati di sicurezza e che, in caso di incidente, la continuità operativa sia preservata o rapidamente ripristinata.

Ambito e finalità della Direttiva NIS2

L’ambito soggettivo di applicazione è definito in funzione della rilevanza sistemica dell’organizzazione e si struttura attorno alla distinzione tra soggetti essenziali (art. 3, par. 1, Dir. NIS2) e soggetti importanti (art. 3, par. 2), una classificazione recepita pressoché integralmente dall’art. 6 del D.lgs. 138/2024.

I settori interessati spaziano dall’energia ai trasporti, dalla sanità alle infrastrutture digitali, dai servizi postali alla manifattura avanzata.

Con la piena operatività del decreto nazionale – avviata a partire dal gennaio 2025 con la fase di registrazione sulla piattaforma ACN – il perimetro dei soggetti obbligati si è significativamente esteso rispetto alla previgente disciplina.

L’approccio metodologico è basato sul rischio per le reti e i sistemi: le organizzazioni devono identificare, valutare e trattare i rischi di incidente di cyber security in modo proporzionato, documentando le misure adottate.

Al contempo, le stesse sono chiamate all’adozione delle specifiche misure previste dalla normativa loro applicabile (per esempio, misure di sicurezza di base definite nella determinazione ACN 379907/2025 ) in qualità di soggetto NIS essenziale o importante.

Ambito e finalità del Cyber Resilience Act

Il Cyber Resilience Act (Regolamento UE 2024/2847) introduce un approccio alla cyber security diverso: la sicurezza informatica come requisito intrinseco del prodotto digitale, integrata sin dalle fasi iniziali del ciclo di vita e garantita lungo tutta la durata di vita dello stesso.

L’ambito di applicazione del CRA copre i «prodotti con elementi digitali» (PED), definiti dall’art. 3, n. 1, CRA come «qualsiasi prodotto software o hardware e le sue soluzioni remote di trattamento dei dati, incluse le componenti software o hardware immesse separatamente sul mercato» la cui finalità prevista o il cui utilizzo ragionevolmente prevedibile include una connessione dati logica o fisica, diretta o indiretta, a un altro dispositivo o a una rete.

La portata applicativa è dunque estremamente ampia, investendo decine di migliaia di tipologie di prodotto presenti sul mercato europeo.

NIS2 e Cyber Resilience Act, tre date cruciali

Sul piano del calendario normativo, occorre distinguere tre date cruciali:

• il Regolamento è entrato in vigore il 10 dicembre 2024;
• gli obblighi di notifica degli incidenti alle autorità competenti si applicano dal 11 settembre 2026;
• le disposizioni principali relative alla conformità dei prodotti si applicano integralmente dal 11 dicembre 2027.

Questa scansione temporale offre alle organizzazioni una finestra di adeguamento graduato, ma richiede pianificazione strategica immediata.

I produttori (ed in misura diversa anche gli importatori e distributori) sono chiamati a integrare i requisiti di sicurezza nelle fasi di progettazione e sviluppo e gestire le vulnerabilità lungo l’intero ciclo di vita del prodotto, assicurando anche aggiornamenti di sicurezza e canali di segnalazione.

Distinzione tipologica e approcci regolativi

La distinzione tra direttiva e regolamento non è meramente formale.

La NIS2, in quanto direttiva, ha richiesto recepimento nazionale e lascia agli Stati un margine di discrezionalità nell’attuazione; il D.lgs. 138/2024 ne è espressione.

Il CRA, in quanto regolamento, è direttamente applicabile in tutti gli Stati membri senza necessità di trasposizione, garantendo uniformità del regime obbligatorio a livello europeo.

I due strumenti adottano approcci complementari:

• gestione del rischio per i sistemi e le reti del soggetto in perimetro (NIS2);
• rischio per l’utilizzatore del prodotto e prevenzione by design (CRA).

Questa complementarità non è casuale: il legislatore europeo ha inteso presidiare l’ecosistema digitale su due livelli distinti ma interconnessi, nella consapevolezza che la sicurezza complessiva del sistema dipende tanto dalla resilienza delle organizzazioni quanto dalla robustezza dei prodotti che esse utilizzano e commercializzano.

Le 3 aree di convergenza normativa: un’analisi comparata

Le sovrapposizioni tra NIS2 e CRA emergono con evidenza quando si analizzano i processi operativi e le infrastrutture delle organizzazioni.

È in tali ambiti che la distinzione tra le due normative tende a sfumare, poiché gli stessi meccanismi operativi sono chiamati a soddisfare obblighi riconducibili a entrambi i framework.

Si individuano almeno tre grandi aree di convergenza.

Gestione delle vulnerabilità

La gestione delle vulnerabilità rappresenta il nucleo più evidente della sovrapposizione.

L’art. 21, par. 2, lett. e), della Dir. NIS2 richiede ai soggetti obbligati l’adozione di «politiche e procedure per valutare l’efficacia delle misure di gestione dei rischi di cybersicurezza», che includono processi strutturati di identificazione e trattamento delle vulnerabilità.

Il D.lgs. 138/2024 declina questo obbligo richiedendo l’implementazione di programmi di vulnerability management nell’ambito delle misure minime di sicurezza.

Parallelamente, gli artt. 13 e 14 del CRA impongono ai produttori obblighi dettagliati in materia di vulnerability management lungo l’intero ciclo di vita del prodotto:

• identificazione e documentazione delle vulnerabilità,
• applicazione tempestiva di patch di sicurezza,
• comunicazione agli utenti e – dal settembre 2026 – notifica alle autorità competenti per le vulnerabilità sfruttate attivamente.

L’art. 14, par. 2, CRA prevede in particolare l’obbligo di notifica «senza indebito ritardo e comunque entro 24 ore dalla conoscenza» di una vulnerabilità attivamente sfruttata.

Nelle organizzazioni che sono al contempo soggetti obbligati ai sensi della NIS2 e produttori di PED ai sensi del CRA – come frequentemente avviene nel settore della manifattura avanzata e in quello delle infrastrutture digitali -, abbiamo due processi di vulnerability management che presentano aree di sovrapposizione interessanti.

Prima di tutto, le “soluzioni di trattamento remote dei dati”, che possono per esempio essere un servizio cloud reso disponibile per gestire il prodotto, spesso rientrano a tutti gli effetti fra i componenti del sistema informativo aziendale.

Poi, in entrambi i casi, è necessario partire da un inventario dei componenti e delle loro caratteristiche (marca, modello, versione ecc.) per monitorare la pubblicazione di vulnerabilità e la disponibilità di aggiornamenti: anche qui, sia come processo che come soluzioni di mercato è possibile fare sinergia.

Cosa richiedono i processi

Di qui in poi i processi sono più autonomi: da una parte chi gestisce i sistemi informativi si occupa di aggiornarli, dall’altra i team di sviluppo dei prodotti si occupano di aggiornare questi ultimi, rendendo però anche disponibili gli aggiornamenti ai clienti.

Entrambi i processi richiederanno poi il tracciamento di versioni e aggiornamenti, e l’esecuzione di attività di test per verificare, prima della messa in produzione, l’efficacia delle soluzioni adottate.

Gestione degli incidenti e obblighi di notifica

La disciplina degli incidenti è un secondo punto critico di intersezione.

La NIS2 prevede un sistema articolato di notifiche alle autorità competenti (art. 23 Dir. NIS2; art. 26 D.lgs. 138/2024): preallarme entro 24 ore, notifica iniziale entro 72 ore e relazione finale entro un mese.

Il regime sanzionatorio per i soggetti essenziali prevede sanzioni sino al 2% del fatturato mondiale annuo per le violazioni più gravi (art. 34 Dir. NIS2).

Il CRA introduce, dal settembre 2026, un parallelo obbligo di notifica per i produttori: in caso di incidente di sicurezza che incide sulla sicurezza del PED, per esempio compromettendo l’ambiente di sviluppo, le soluzioni di trattamento remote dei dati, o i servizi di pubblicazione degli aggiornamenti, il produttore deve notificare l’ENISA «senza indebito ritardo e comunque entro 24 ore dalla conoscenza» dell’incidente.

Nei casi in cui un attacco informatico colpisca sia l’infrastruttura del soggetto obbligato NIS2 sia i suoi prodotti digitali, si determinerà una duplice catena di notifica – verso lo CSIRT per NIS2 e verso ENISA per il CRA – che richiede coordinamento procedurale e prontezza organizzativa.

La duplice catena di notifica – verso ACN per NIS2 e verso ENISA per il CRA – impone alle organizzazioni un coordinamento procedurale che non può essere improvvisato al momento dell’incidente.

Sicurezza della supply chain

La supply chain rappresenta forse l’area di convergenza più complessa. L’art. 21, par. 2, lett. d), della Dir. NIS2 richiede alle organizzazioni di presidiare la «sicurezza della catena di approvvigionamento, compresi gli aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi».

Il D.lgs. 138/2024 specifica che le valutazioni devono tenere conto delle vulnerabilità specifiche per ciascun fornitore e fornitore di servizi e della qualità complessiva dei prodotti e delle pratiche di cybersicurezza dei loro fornitoriIl CRA affronta la sicurezza della supply chain dal lato del prodotto: l’art. 13, par. 5, CRA impone ai produttori di identificare e documentare le vulnerabilità e i componenti contenuti nel prodotto, anche mediante la redazione di una Software Bill of Materials (SBOM).

L’art. 13, par. 6, richiede ai produttori di adottare politiche volte a incoraggiare la divulgazione responsabile delle vulnerabilità da parte di terzi. Queste disposizioni impattano direttamente sui processi di acquisto e sui contratti con i fornitori di componenti hardware e software.

Le organizzazioni che si trovano contemporaneamente nella posizione di soggetti obbligati NIS2 e di produttori CRA devono quindi gestire la supply chain security su due piani: come acquirenti, presidiando i rischi introdotti dai propri fornitori, requisito posto sia in ambito NIS2 che CRA-NIS2); come produttori, garantendo la tracciabilità e la sicurezza dei componenti integrati nei propri prodotti (CRA) e rispondendo nel contempo alle richieste che possono arrivare da propri clienti.

Tre impatti organizzativi e di governance aziendale

Le sovrapposizioni tra NIS2 e CRA assumono particolare intensità nelle organizzazioni che operano secondo il modello prodotto-servizio, in cui hardware o software commercializzati sono supportati da infrastrutture operative continuative.

Questo modello è diffusissimo nel settore dell’elettronica di consumo connessa, nell’automazione industriale o nei dispositivi IOT.

Un esempio paradigmatico è rappresentato dalle imprese operanti nella fabbricazione di macchinari e apparecchiature, che rientrano tra i soggetti importanti ai sensi della NIS2 (allegato II, sez. 6).

Tali organizzazioni, oltre a dover garantire la sicurezza dei propri sistemi informativi e della catena di fornitura, sono frequentemente anche produttori di PED soggetti al CRA.

La stessa organizzazione si trova quindi a dover gestire simultaneamente obblighi relativi alla sicurezza operativa (NIS2) e alla sicurezza del prodotto (CRA), con evidenti implicazioni in termini di coordinamento dei processi e di allocazione delle responsabilità interne.

Governance e responsabilità degli organi apicali

Sul piano della governance, entrambe le normative convergono nell’affermare la responsabilità degli organi di vertice in materia di cyber security.

L’art. 20 della Dir. NIS2 è esplicito: «i membri degli organi di gestione dei soggetti essenziali e importanti sono tenuti ad approvare le misure di gestione dei rischi di cybersicurezza e possono essere ritenuti responsabili delle violazioni».

Il D.Lgs. 138/2024 recepisce questo principio con un’articolazione che contempla sia la responsabilità degli organi collegiali sia quella degli amministratori delegati.

Il CRA, pur non contenendo disposizioni altrettanto esplicite sulla responsabilità degli organi di gestione, attribuisce ai «produttori» – incluse le persone giuridiche e i loro rappresentanti legali – la responsabilità dell’osservanza degli obblighi regolamentari (art. 16 CRA).

Il regime sanzionatorio previsto dall’art. 64 CRA è particolarmente severo: sanzioni amministrative fino a 15 milioni di euro o al 2,5% del fatturato mondiale per le violazioni più gravi, senza contare il rischio di dover ritirare il proprio prodotto dal mercato, con gli impatti anche di immagine che questo comporta.

La logica compartimentale di Nis2 e Cyber Resilience Act

In questo quadro, le organizzazioni sono chiamate a ridisegnare i propri modelli di governance della cyber security, superando la logica compartimentale in cui la compliance NIS2 è gestita dal Chief Information Security Officer (CISO) e la conformità CRA è demandata al Chief Product Officer o al team di ingegneria.

La coesistenza di obblighi trasversali impone l’adozione di modelli di collaborazione formalizzati, con meccanismi strutturati di condivisione delle informazioni e di escalation verso il livello di board.

Un’opzione organizzativa che si sta affermando nella prassi è la costituzione di un Cybersecurity Steering Committee di livello C-suite, con mandato trasversale rispetto alle due normative e responsabilità di supervisione sia sull’implementazione delle misure NIS2 sia sull’avanzamento del programma di conformità CRA.

Tale soluzione risponde anche all’esigenza di disporre di un interlocutore unitario nei confronti delle autorità di vigilanza, semplificando la gestione delle verifiche ispettive.

Strategia di adeguamento integrato: profili operativi e giuridici

Una strategia di adeguamento integrato richiede, in primo luogo, un’analisi comparata dei requisiti normativi dei due framework e dello stato di conformità dell’organizzazione – la gap analysis – che superi un approccio sequenziale e individui le aree in cui gli obblighi insistono su processi comuni.

Gap Analysis come punto di partenza

Questa analisi non può essere demandata esclusivamente alla funzione legal o IT: richiede il coinvolgimento di figure tecniche (CISO, product security engineer, responsabile qualità) e di risk management, con un coordinamento che la funzione legale è chiamata a garantire dal punto di vista metodologico.

Dal punto di vista giuridico, la gap analysis deve mappare, per ciascun processo aziendale rilevante, i requisiti normativi applicabili ai sensi di entrambe le fonti, evidenziando le sovrapposizioni e le peculiarità di ciascun regime.

Il risultato di questa mappatura costituirà il presupposto per la progettazione di controlli e procedure trasversali.

La finestra strategica da sfruttare

La diversa tempistica di applicabilità dei due framework offre alle organizzazioni una finestra strategica che deve essere sfruttata consapevolmente.

Con la NIS2 già pienamente operativa e il CRA destinato a dispiegare i propri effetti principali entro il 2027, gli interventi di adeguamento possono essere pianificati in modo progressivo, utilizzando le misure già implementate per NIS2 come base per gli adeguamenti CRA.

L’identificazione delle aree di convergenza consente di progettare processi e controlli che soddisfino contestualmente i requisiti di entrambi i framework, evitando duplicazioni e garantendo coerenza documentale.

Tra i processi candidati a una gestione integrata vi sono:

• Il vulnerability management process, che almeno in parte può essere progettato per soddisfare simultaneamente gli obblighi NIS2 (gestione del rischio sui sistemi informativi) e CRA (gestione delle vulnerabilità del prodotto), con flussi di escalation e notifica differenziati in funzione della fonte normativa applicabile.
• Il processo di gestione degli incidenti e le procedure di notifica, che devono prevedere percorsi decisionali chiari per distinguere gli incidenti che attivano obblighi NIS2 (impatto sui sistemi informativi) da quelli che attivano obblighi CRA (impatto sulla sicurezza del prodotto), nonché quelli che attivano entrambi.
• L’analisi ed il monitoraggio della sicurezza della supply chain, che può essere strutturato come un unico framework di valutazione dei fornitori, capace di presidiare sia il rischio introdotto dai fornitori di servizi e prodotti nell’infrastruttura dell’organizzazione (NIS2) sia la tracciabilità e sicurezza dei componenti integrati nei prodotti commercializzati (CRA).

Le sovrapposizioni tra i due framework

La coesistenza di NIS2 e Cyber Resilience Act nel panorama normativo europeo pone alle organizzazioni una sfida che non può essere affrontata con gli strumenti tradizionali della compliance sequenziale.

La natura strutturalmente trasversale delle sovrapposizioni tra i due framework – che investono processi fondamentali quali la gestione delle vulnerabilità, la risposta agli incidenti e la sicurezza della supply chain – impone un approccio integrato, in cui la dimensione giuridica e quella tecnica si fondono in una strategia unitaria.

Sul piano del diritto positivo, la situazione, nel momento in cui stiamo scrivendo, vede la NIS2 pienamente operativa in Italia attraverso il D.lgs. 138/2024, con ACN che ha avviato le prime attività di supervisione e ispezione, e il CRA in fase di progressiva entrata in vigore, con gli obblighi di notifica ormai imminenti (settembre 2026) e il regime pieno di conformità dei prodotti previsto per dicembre 2027.

La finestra temporale disponibile è ancora significativa, ma la pianificazione deve iniziare ora per poter sfruttare le sinergie tra i due regimi.

La prospettiva della multicompliance non deve essere letta come un aggravio burocratico, ma come un’opportunità: le organizzazioni che sapranno progettare processi trasversali, costruire una governance integrata e investire sistematicamente nella sicurezza – sia dei propri sistemi sia dei propri prodotti – si troveranno in una posizione competitiva avvantaggiata, non solo rispetto ai requisiti normativi, ma anche rispetto alla fiducia del mercato e alla resilienza operativa nel lungo periodo.