Linee guida Cyber Resilience Act: quali prodotti, quali obblighi, da quando

Il 27 luglio 2026 la Commissione europea ha approvato il contenuto delle linee guida Cyber Resilience Act, il documento interpretativo più dettagliato pubblicato finora sul Regolamento (UE) 2024/2847. Formalmente non è vincolante, ma esprime l’interpretazione che le autorità di vigilanza del mercato, le autorità di notifica e gli organismi notificati sono chiamati ad applicare in tutta l’Unione.

Due documenti meritano consultazione: la Comunicazione C(2026) 5252 e l’Allegato che contiene le linee guida vere e proprie, entrambi disponibili sulla pagina di annuncio della Commissione.

Lo schema che segue ripercorre ambito di applicazione, obblighi e tempistiche del CRA nell’ordine in cui le linee guida li affrontano.

1) A quali prodotti si applica il CRA?

Ai sensi dell’articolo 2, paragrafo 1, il Regolamento si applica ai prodotti con elementi digitali la cui finalità prevista o il cui uso ragionevolmente prevedibile comportino una connessione dati logica o fisica, diretta o indiretta, a un dispositivo o a una rete.

Due chiarimenti introdotti dalle linee guida hanno rilevanza pratica immediata:

1. La connessione dati presuppone la trasmissione di informazioni codificate digitalmente, generate intenzionalmente da un mittente secondo uno schema definito e decodificabili come informazioni a destinazione. La mera commutazione di un’uscita, quindi, non costituisce connessione dati.
2. L’immissione sul mercato presuppone la fornitura nel corso di un’attività commerciale, nozione che le linee guida sviluppano diffusamente in relazione al software open source.

Software e luogo di esecuzione

La distinzione pesa in modo particolare per i settori gaming e gambling, perché un client di gioco scaricabile costituisce prodotto con elementi digitali, mentre un titolo giocato esclusivamente attraverso browser non rientra nell’ambito del Regolamento per questa sola ragione.

Una regola ulteriore governa il momento dell’immissione sul mercato per il software standalone. Quando una determinata versione viene fornita per la prima volta per la distribuzione o l’uso sul mercato dell’Unione, tutte le copie di quella versione si considerano immesse sul mercato nel medesimo momento, a prescindere dalla data in cui ciascun utente la scarichi. Una versione fornita il 1° gennaio è immessa sul mercato in quella data, sia per il cliente che la acquisisce subito sia per quello che la acquisisce alcune settimane dopo.

Le varianti dello stesso software che differiscono per componenti inclusi, configurazioni o funzionalità abilitate, come le build per sistemi operativi diversi o i bundle con set di funzioni differenti, sono trattate invece come prodotti distinti.

Hardware e software possono costituire un unico prodotto

Il canale attraverso cui il software raggiunge l’utente non è determinante. Quando il software è necessario per far funzionare, configurare, controllare o utilizzare l’hardware conformemente alla sua finalità prevista, i due elementi costituiscono insieme un unico prodotto con elementi digitali, anche se il software viene ottenuto separatamente tramite un application store o un link di download dopo l’immissione sul mercato dell’hardware. I due elementi sono di conseguenza immessi sul mercato nello stesso momento.

Le linee guida illustrano il principio attraverso una stampante di rete che non può assolvere la propria finalità senza i driver, e attraverso un wearable per il fitness le cui misurazioni possono essere visualizzate e configurate solo tramite la companion app del fabbricante. Lo stesso ragionamento governa le periferiche per console, i visori di realtà virtuale e i dispositivi connessi forniti con utility di configurazione dedicate.

Servizi cloud: quando il remote processing fa parte del prodotto

Le soluzioni di elaborazione dati remota rientrano nel perimetro del prodotto con elementi digitali. La loro individuazione poggia su tre domande cumulative:

1. L’elaborazione dei dati avviene a distanza, su infrastruttura cloud pubblica, su cloud privato o su server collocati presso il fabbricante?
2. L’assenza di quella elaborazione impedirebbe al prodotto di svolgere una delle proprie funzioni, nozione più ampia sia della core functionality sia della finalità prevista?
3. Il software è stato progettato e sviluppato dal fabbricante, o sotto la sua responsabilità, ossia realizzato esclusivamente da esso o per suo conto sulla base di progetti e specifiche da esso fornite?

Se la risposta a tutte e tre le domande è affermativa, la componente remota fa parte del prodotto e deve essere considerata nel risk assessment, nella documentazione tecnica e nella valutazione della conformità. Il software distribuito dal fabbricante su offerte Infrastructure as a Service o Platform as a Service di terzi soddisferà di norma la terza condizione. Un’applicazione Software as a Service di terzi integrata nel prodotto non la soddisfa e va trattata come componente di terze parti, soggetta a due diligence e a misure di mitigazione a livello di prodotto.

Due confini limitano quel perimetro:

• Solo i moduli software responsabili della funzionalità del prodotto, insieme alle interfacce che tali moduli utilizzano verso servizi esterni, si qualificano come soluzioni di elaborazione dati remota. I sistemi di back-end con cui il prodotto non interagisce direttamente restano dipendenze esterne, da valutare e mitigare a livello di prodotto, senza costituirne componenti.
• L’infrastruttura di comunicazione, ossia reti cellulari, router, cablaggi ethernet e segnali wireless, costituisce un abilitatore della connettività e non elaborazione dati remota: nessun obbligo di due diligence sorge nei confronti del fornitore di rete.

Software libero e open source: due domande in sequenza

Il software si qualifica come free and open-source software solo quando ricorrono cumulativamente due condizioni:

1. Il software è reso disponibile in base a una licenza che concede l’insieme completo dei diritti richiamati dall’articolo 3, punto 48; e
2. Il codice sorgente è condiviso apertamente e pubblicamente.

Il software distribuito con licenza open source il cui codice sorgente sia divulgato soltanto ai clienti paganti o a un gruppo ristretto di utenti non si qualifica come FOSS ai fini del Regolamento.

La valutazione procede poi in due fasi.

Prima fase: il software è sotto la responsabilità di un determinato soggetto? La responsabilità ricade sulle persone fisiche o giuridiche che pubblicano il software ed esercitano il controllo primario su sviluppo, rilasci e decisioni di distribuzione, generalmente indicate come maintainer. Chi contribuisce con codice sorgente senza controllare rilasci, roadmap o governance è un contributor e resta fuori dall’ambito del Regolamento. L’esistenza di permessi tecnici come il commit access non basta a fondare la responsabilità.

Seconda fase: il software è monetizzato? Le linee guida affrontano gli scenari principali nei termini che seguono.

La Commissione neutralizza espressamente due circostanze spesso fraintese:

• Le modalità di finanziamento dello sviluppo non incidono sul carattere commerciale della fornitura, sicché grant, sponsorizzazioni e sviluppo di funzionalità a pagamento non trasformano un progetto in un prodotto immesso sul mercato.
• Un ente senza scopo di lucro, costituito in modo che tutti i proventi al netto dei costi siano destinati a finalità non lucrative, non immette sul mercato il proprio FOSS, anche quando il software è direttamente monetizzato.

Quando il FOSS è pubblicato senza essere immesso sul mercato, la persona giuridica che lo pubblica può qualificarsi come open-source software steward ai sensi dell’articolo 3, punto 14, ed è soggetta al più limitato insieme di obblighi previsto dall’articolo 24. Un unico soggetto può rivestire entrambi i ruoli contemporaneamente rispetto a progetti diversi, e chi pubblica sia una community edition gratuita sia una enterprise edition a pagamento dello stesso software sarà steward della prima e fabbricante della seconda. Gli obblighi di segnalazione degli steward sono calibrati sul supporto effettivamente prestato, ai sensi dell’articolo 24, paragrafo 3.

Categorie escluse dall’ambito del Regolamento

Tre categorie meritano attenzione:

1. I pezzi di ricambio destinati a sostituire componenti identici e fabbricati secondo le medesime specifiche sono esenti ai sensi dell’articolo 2, paragrafo 6. L’identità si valuta con riferimento al ruolo funzionale del componente e alle caratteristiche rilevanti per la cybersecurity, quali meccanismi crittografici, protocolli e funzioni di controllo degli accessi.
2. I componenti automotive progettati e costruiti esclusivamente per l’integrazione in veicoli coperti dal Regolamento (UE) 2019/2144 o dal Regolamento (UE) n. 168/2013 restano fuori dall’ambito, purché l’esclusività della destinazione sia oggettivamente verificabile.
3. I prodotti disciplinati dagli altri strumenti elencati all’articolo 2, paragrafo 2 sono parimenti esclusi.

L’esenzione per i pezzi di ricambio porta con sé una condizione probatoria che i fabbricanti farebbero bene ad anticipare. La finalità di manutenzione o riparazione deve risultare dal contesto della fornitura, attraverso l’identificazione del prodotto o della famiglia di prodotti nell’ordine o nell’offerta commerciale, oppure attraverso la fornitura tramite canali after-sales o di assistenza, e le evidenze a supporto devono essere conservate a disposizione delle autorità di vigilanza del mercato. Lo stesso articolo offerto tramite retail generalista o canali online aperti al pubblico non beneficia dell’esenzione.

2) Quali obblighi prevedono le linee guida Cyber Resilience Act?

Gli obblighi possono essere organizzati in sei blocchi, tutti applicabili cumulativamente.

2.1 Valutazione del rischio di cybersecurity

Il risk assessment richiesto dall’articolo 13, paragrafo 2 costituisce il fondamento dell’intera architettura di compliance, perché determina quali requisiti essenziali della Parte I dell’Allegato I si applichino al prodotto e come vadano attuati.

Tre principi ne governano l’esito:

1. La propensione al rischio interna del fabbricante, la sua strategia commerciale e le considerazioni di costo non hanno alcun peso nel determinare se i rischi individuati siano stati sufficientemente affrontati.
2. Il Regolamento non consente il trasferimento del rischio o della responsabilità di cybersecurity a utenti o terzi per compensare carenze nella progettazione del prodotto.
3. Quando la valutazione individua rischi non adeguatamente trattabili, la conformità può richiedere modifiche alla progettazione, alle funzionalità o alla finalità prevista del prodotto.

Il rischio residuo è riconosciuto come esito inerente a ogni processo di trattamento del rischio, dato che i rischi di cybersecurity non possono essere eliminati del tutto. Non può però essere accettato a discrezione del fabbricante: un prodotto può essere immesso sul mercato solo dove i rischi residui siano stati sufficientemente affrontati attraverso l’attuazione dei requisiti essenziali.

2.2 Requisiti essenziali, due diligence e vincoli tecnici

La Parte I dell’Allegato I disciplina la sicurezza del prodotto, la Parte II la gestione delle vulnerabilità. I componenti acquisiti da terzi attivano l’obbligo di due diligence dell’articolo 13, paragrafo 5, che impone al fabbricante di:

• determinare che cosa il prodotto necessiti da ciascun componente per raggiungere i propri obiettivi di cybersecurity; e
• verificare, secondo un approccio risk-based, che il componente soddisfi tali necessità, attraverso specifiche tecniche, documentazione di sicurezza, documentazione di conformità o assurance, oppure test.

Gli elementi esterni fuori dal controllo del fabbricante vanno comunque affrontati con misure a livello di prodotto. Le linee guida richiamano, fra le altre:

• l’autenticazione crittografica dei comandi remoti;
• la verifica dell’integrità delle modifiche di configurazione;
• la generazione di log rilevanti per la sicurezza; e
• la garanzia che l’indisponibilità di un servizio esterno non porti il prodotto in uno stato insicuro.

I sistemi complessi ricevono un trattamento proporzionato, che non equivale a un’esenzione. Quando un requisito essenziale non può essere soddisfatto perché la finalità prevista del prodotto richiede l’interoperabilità con dipendenze esistenti o il rispetto di requisiti di interoperabilità imposti, il fabbricante è tenuto a individuare e documentare il vincolo, a valutarne i rischi e ad attuare misure di mitigazione alternative o compensative. Quando il prodotto è tecnicamente in grado di supportare sia un protocollo sicuro sia un protocollo legacy, il protocollo sicuro va implementato e abilitato per impostazione predefinita. Il vincolo deve essere riesaminato periodicamente e il prodotto aggiornato una volta che il vincolo possa essere rimosso o ridotto.

2.3 Valutazione della conformità e nozione di core functionality

Ai fini della determinazione del regime di valutazione della conformità applicabile, un prodotto può avere una sola core functionality, corrispondente alle caratteristiche e capacità tecniche principali senza le quali il prodotto non sarebbe in grado di assolvere la propria finalità prevista.

Le funzioni accessorie rispetto alla core functionality non incidono sulla classificazione, sicché uno smartphone che integra un sistema operativo non acquisisce per ciò solo la core functionality di un sistema operativo, e un software di security orchestration, automation and response le cui capacità eccedano sostanzialmente quelle di un sistema SIEM non è di norma classificato come tale. Le linee guida affermano espressamente che il fabbricante non può rappresentare in modo scorretto la core functionality del proprio prodotto per sottrarsi a un regime più stringente, e indicano nelle incoerenze fra materiali promozionali, istruzioni per l’uso e documentazione tecnica l’indicatore che le autorità andranno a esaminare.

Tre ulteriori profili rilevano:

1. L’applicazione di una norma armonizzata che copra la core functionality consente il ricorso alla procedura di controllo interno, ma la presunzione di conformità si estende ai soli rischi effettivamente coperti da quella norma. Le funzionalità accessorie che ne esulano non beneficiano di alcuna presunzione, e le misure aggiuntive adottate rispetto ad esse richiedono documentazione separata.
2. I moduli resi disponibili sul mercato anche separatamente, tramite acquisto, licenza o abbonamento distinti, costituiscono prodotti autonomi, classificati sulla base della rispettiva core functionality.
3. Quando varianti di un prodotto condividono architettura, progettazione rilevante per la sicurezza e finalità prevista, e affrontano i medesimi rischi di cybersecurity, un unico risk assessment, un’unica documentazione tecnica, un’unica valutazione della conformità e un’unica dichiarazione di conformità UE possono coprire l’intera famiglia, purché la dichiarazione identifichi chiaramente le varianti interessate.

2.4 Periodo di supporto

Il periodo minimo di cinque anni opera come garanzia e non come regola di default, perché l’articolo 13, paragrafo 8 richiede che il periodo di supporto rifletta il tempo per cui il prodotto è destinato ad essere utilizzato. Ai prodotti che ragionevolmente resteranno in uso per più di cinque anni vanno quindi riconosciuti periodi di supporto corrispondentemente più lunghi. La data di scadenza del periodo di supporto deve essere indicata all’acquirente al momento dell’acquisto, specificando almeno mese e anno.

L’articolo 13, paragrafo 10 introduce un margine di flessibilità per il software sviluppato in modo iterativo, permettendo al fabbricante di affrontare e correggere le vulnerabilità nella sola versione da ultimo immessa sul mercato, purché gli utenti delle versioni precedenti possano effettuare l’upgrade gratuitamente e senza costi aggiuntivi. Le linee guida interpretano restrittivamente la nozione di costi aggiuntivi. Tempo del personale, test di routine, aggiustamenti di configurazione e aggiornamento delle dipendenze sottostanti costituiscono sforzo operativo ragionevole, inerente alla manutenzione del software. Acquisti obbligatori di nuovo hardware, sostituzione dell’infrastruttura e modifiche sostanziali dell’ambiente operativo rientrano invece nella nozione e precludono il ricorso alla previsione.

2.5 Gestione delle vulnerabilità e obblighi verso l’upstream

Gli obblighi della Parte II dell’Allegato I comprendono policy e procedure per la gestione delle vulnerabilità segnalate da fonti interne o esterne, la fornitura di security update, una policy di coordinated vulnerability disclosure e l’applicazione di test e revisioni efficaci e regolari lungo tutto il periodo di supporto. Il requisito della regolarità non comporta la ripetizione meccanica di una campagna di test immutata a intervalli fissi. Richiede il riesame periodico della necessità di aggiornare i test esistenti alla luce di nuove minacce o di nuove vulnerabilità, seguito dall’esecuzione dei test così individuati.

I prodotti devono essere messi a disposizione sul mercato senza vulnerabilità note sfruttabili. Una vulnerabilità si considera nota quando è elencata nella banca dati europea delle vulnerabilità o in altre banche dati di rilievo, quando è stata comunicata al fabbricante tramite disclosure coordinata da parte di un ricercatore di sicurezza, quando è emersa dai test e dalle analisi interne del fabbricante, oppure quando è stata riportata pubblicamente e in modo prominente da fonti di informazione affidabili. Una vulnerabilità è sfruttabile quando può essere effettivamente utilizzata da un attaccante in condizioni operative pratiche, e non soltanto teoriche o di laboratorio.

La segnalazione di una vulnerabilità non equivale alla sua conferma. Il fabbricante è tenuto a investigare la segnalazione, a verificarne la veridicità e l’applicabilità allo specifico prodotto e, quindi, a determinare sulla base del risk assessment se il prodotto possa essere immesso sul mercato in sicurezza o se la vulnerabilità debba prima essere corretta. Le linee guida riconoscono che posticipare un rilascio comporta rischi propri, in particolare quando il rilascio corregge anche altre vulnerabilità sfruttabili o è necessario alla continuità operativa di sistemi critici.

Le vulnerabilità individuate nei componenti integrati devono essere segnalate al soggetto che produce o mantiene il componente, con riferimento alla versione integrata e secondo i canali di disclosure eventualmente stabiliti. Ogni correzione di sicurezza sviluppata dal fabbricante va condivisa verso l’upstream in formato leggibile da dispositivo automatico e verificabile, compatibile con la licenza del componente. I fabbricanti sono incoraggiati a consultare banche dati pubbliche, advisory di progetto e issue tracker prima di segnalare, così da evitare duplicazioni, e sono liberati dall’obbligo quando il maintainer è già a conoscenza della vulnerabilità o quando il componente non ha più un maintainer.

2.6 Segnalazione a ENISA e al CSIRT

Le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza del prodotto devono essere notificati simultaneamente a ENISA e al CSIRT designato come coordinatore, secondo la sequenza che segue.

Una vulnerabilità che colpisce un componente di terze parti integrato è soggetta a notifica obbligatoria solo se effettivamente sfruttata nel prodotto del fabbricante. Quando il codice vulnerabile non è raggiungibile, o quando la vulnerabilità non è stata sfruttata in quel prodotto, l’obbligo di segnalazione non sorge, ferma restando la segnalazione volontaria ai sensi dell’articolo 15 e la piena applicazione degli obblighi di gestione delle vulnerabilità.

Il momento da cui decorrono i termini è definito per riferimento alla conoscenza. Il fabbricante si considera venuto a conoscenza quando, all’esito di una valutazione iniziale condotta prontamente dopo il rilevamento di un evento sospetto o la ricezione di una segnalazione di terzi, dispone di un ragionevole grado di certezza che una vulnerabilità presente nel proprio prodotto sia attivamente sfruttata o che un incidente grave ne abbia compromesso la sicurezza. Gli utenti impattati devono essere informati anche ai sensi dell’articolo 14, paragrafo 8, su base risk-based e proporzionata. Le linee guida confermano che la comunicazione può essere limitata agli utenti o clienti interessati quando il prodotto è impiegato in ambienti sensibili o essenziali e quando la divulgazione pubblica dei dettagli tecnici potrebbe essa stessa agevolare ulteriori sfruttamenti.

3) Da quando si applicano gli obblighi?

Quattro profili relativi all’applicazione temporale del Regolamento meritano attenzione.

L’obbligo di segnalazione non opera retroattivamente. Lo sfruttamento attivo di cui il fabbricante fosse già a conoscenza prima dell’11 settembre 2026 resta fuori dall’obbligo. Se il fabbricante conosceva la vulnerabilità prima di quella data senza essere a conoscenza di alcuno sfruttamento attivo, e lo sfruttamento si verifica o emerge successivamente, la vulnerabilità diventa soggetta all’obbligo. L’obbligo copre i prodotti immessi sul mercato prima dell’11 dicembre 2027 e continua ad applicarsi anche dopo la scadenza del periodo di supporto.

I prodotti progettati prima della data di applicazione non richiedono riprogettazione. Le unità fabbricate secondo un tipo o modello progettato prima di dicembre 2027 possono essere immesse sul mercato successivamente, purché un risk assessment aggiornato dimostri che le misure di sicurezza esistenti affrontano i rischi individuati. Il fabbricante non è tenuto a ricostruire la documentazione storica di progettazione o di test, perché ciò non contribuirebbe alla sicurezza del prodotto, ma resta soggetto alla procedura di valutazione della conformità, alla redazione della dichiarazione di conformità UE, all’apposizione della marcatura CE e agli obblighi di gestione delle vulnerabilità.

Una modifica sostanziale determina una nuova immissione sul mercato. Una modifica è sostanziale quando altera il livello di rischio di cybersecurity in un modo che il fabbricante non aveva considerato nel proprio risk assessment, oppure quando modifica la finalità prevista per la quale il prodotto è stato valutato. La portata dell’intervento non è determinante: l’introduzione di una funzione di login persistente che memorizza localmente i token di autenticazione è stata qualificata come modifica sostanziale, mentre l’attivazione di funzionalità già previste e valutate nel progetto originario non lo è. I security update restano di norma fuori dalla nozione, perché finalizzati a ridurre il rischio, salvo che modifichino la finalità prevista o introducano nuove dipendenze, come accade quando una funzionalità di cifratura locale viene sostituita da un servizio di cifratura remoto gestito dal fabbricante.

La valutazione può essere utilmente strutturata intorno a quattro domande tratte dalle linee guida:

1. L’aggiornamento introduce nuovi vettori di minaccia?
2. Abilita nuovi scenari di attacco?
3. Modifica la probabilità di scenari di attacco già individuati?
4. Ne modifica l’impatto potenziale?

Una risposta negativa a tutte e quattro indica che la modifica difficilmente sarà sostanziale, purché restino valide le assunzioni e le misure di mitigazione su cui poggia il risk assessment.

Le conseguenze dipendono da chi esegue la modifica. L’importatore, il distributore o qualsiasi altra persona fisica o giuridica che modifichi sostanzialmente un prodotto già immesso sul mercato e lo metta a disposizione ne diventa il fabbricante: limitatamente alla parte modificata, se la modifica non incide sulla cybersecurity del prodotto nel suo complesso, e rispetto all’intero prodotto se invece vi incide. L’assemblaggio di componenti in un nuovo prodotto non costituisce affatto una modifica, perché l’integratore immette sul mercato un prodotto nuovo e ne è il fabbricante a ogni effetto. Quando è il fabbricante originario a eseguire la modifica, documentazione e risultati dei test relativi alle parti non interessate possono essere riutilizzati, e l’eventuale valutazione di terza parte si concentra sulle parti effettivamente modificate.

Una conseguenza ulteriore viene spesso data per scontata nel senso opposto. Una modifica sostanziale non azzera né estende automaticamente il periodo di supporto. La domanda rilevante è se la modifica incida sui fattori che originariamente hanno determinato il tempo di utilizzo atteso del prodotto. Un aggiornamento software che aggiunge nuove modalità operative a un robot aspirapolvere lascia intatta la durabilità fisica dell’hardware, sicché il periodo di supporto originario continua a decorrere. La sostituzione della piattaforma di calcolo integrata di un PLC con componenti progettati per una vita operativa significativamente più lunga incide invece su quei fattori e impone di ricalcolare il periodo di supporto.

I certificati esistenti offrono un beneficio transitorio di portata limitata. Un certificato di esame UE del tipo rilasciato ai sensi dell’atto delegato che integra la Direttiva sulle apparecchiature radio o del Regolamento macchine dispensa il fabbricante dal rivalutare o ridimostrare la conformità, ma soltanto rispetto ai rischi di cybersecurity effettivamente coperti da quel certificato e soltanto fino all’11 giugno 2028, anche laddove la validità del certificato si estenda oltre tale data secondo la normativa in base alla quale è stato rilasciato. I rischi individuati attraverso il risk assessment CRA al di fuori di quel perimetro, compresi quelli relativi ai processi di gestione delle vulnerabilità, alla minimizzazione dei dati e alla riduzione della superficie di attacco, restano responsabilità del fabbricante.

Restano pochi giorni fino alla prima scadenza cogente dell’11 settembre 2026. La parte maggiore del lavoro richiesto è documentale e riguarda la mappatura del portafoglio prodotti, la classificazione di ciascun prodotto, la predisposizione della documentazione tecnica e dei risk assessment, e la costruzione di un processo di segnalazione capace di operare entro il termine delle ventiquattro ore a qualsiasi ora del giorno.

Il team technology e cybersecurity di DLA Piper assiste sviluppatori software, operatori di gioco e fabbricanti di prodotti connessi in readiness assessment CRA, classificazione dei prodotti, documentazione tecnica e procedure di gestione delle vulnerabilità.

Su un tema analogo può essere di interesse l’articolo «NIS 2: la responsabilità personale degli amministratori per mancanza di conformità è un messaggio di avvertimento».