Il “bollino” europeo di cyber-resilienza e l’attuazione italiana del Cyber Resilience Act: ACN autorità di notifica e di vigilanza del mercato, sandbox normativa e sanzioni fino a 15 milioni

Abstract

Le Commissioni Affari costituzionali di Camera e Senato sono chiamate a esprimersi sullo schema di decreto legislativo che, in attuazione della legge di delegazione europea 2025, adegua l’ordinamento interno al Regolamento (UE) 2024/2847, il cosiddetto Cyber Resilience Act. Il regolamento introduce requisiti obbligatori di cybersicurezza per i “prodotti con elementi digitali” lungo l’intero ciclo di vita, assistiti da marcatura CE, e si applica anche ai prodotti qualificabili come sistemi di intelligenza artificiale ad alto rischio ai sensi del Regolamento (UE) 2024/1689. Lo schema nazionale individua l’Agenzia per la cybersicurezza nazionale quale autorità di notifica e autorità di vigilanza del mercato, in coordinamento con Banca d’Italia, Consob, IVASS e Garante per la protezione dei dati personali, istituisce una sandbox normativa e articola le sanzioni fino a 15 milioni di euro o al 2,5% del fatturato mondiale totale annuo, se superiore, per l’inosservanza dei requisiti essenziali di cybersicurezza e degli obblighi fondamentali del fabbricante. Si sostiene qui che il Cyber Resilience Act non è disciplina di prodotto confinata ai fabbricanti, ma incide direttamente sulla misura della diligenza esigibile dal titolare del trattamento ai sensi degli articoli 25 e 32 del Regolamento (UE) 2016/679, e deve perciò entrare oggi nelle procedure di acquisto e nelle valutazioni d’impatto.

Premessa

In premessa va detto che il Cyber Resilience Act appartiene a una famiglia normativa diversa da quella abituale per il lettore che si occupi di protezione dei dati. Non è disciplina del trattamento, non è disciplina dei soggetti essenziali e importanti, non è disciplina del mercato dei servizi digitali: trattasi, per l’appunto, di legislazione armonizzata di prodotto, costruita secondo lo schema del “nuovo quadro legislativo” inaugurato dal Regolamento (CE) n. 765/2008 e dalla Decisione n. 768/2008/CE. Lo schema è noto a chiunque abbia avuto a che fare con la direttiva macchine o con la disciplina dei dispositivi elettrici: il legislatore europeo fissa requisiti essenziali, rinvia alle norme armonizzate per la presunzione di conformità, impone al fabbricante una procedura di valutazione della conformità, una dichiarazione UE di conformità, una documentazione tecnica e l’apposizione della marcatura CE, e organizza un sistema di vigilanza del mercato con autorità nazionali, organismi notificati e poteri di ritiro e richiamo.

La novità consiste nell’oggetto. Fino al Regolamento (UE) 2024/2847 la sicurezza presidiata dalla legislazione di prodotto era essenzialmente la sicurezza fisica: incolumità delle persone, compatibilità elettromagnetica, assenza di rischi meccanici o chimici. Con il Cyber Resilience Act la cybersicurezza diventa requisito essenziale di prodotto in senso proprio, con la conseguenza che un router, un software gestionale, un oggetto connesso domestico o un componente industriale privo di aggiornamenti di sicurezza non è soltanto un prodotto scadente, ma un prodotto non conforme, suscettibile di provvedimenti di ritiro dal mercato dell’Unione.

Il perimetro di questa analisi è duplice. Da un lato si ricostruisce il contenuto del regolamento europeo nei profili rilevanti per il lettore professionale, con particolare attenzione al calendario applicativo, agli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e al rapporto con la disciplina dell’intelligenza artificiale. Dall’altro si esaminano le scelte dell’adeguamento nazionale quali risultano dalle informazioni disponibili, segnatamente l’individuazione dell’Agenzia per la cybersicurezza nazionale come autorità di notifica e di vigilanza del mercato, il coordinamento con le autorità di settore, la sandbox normativa e l’architettura sanzionatoria. Si dà conto, infine, delle ricadute sul lavoro quotidiano di chi presidia la conformità in azienda: non tanto perché il Cyber Resilience Act imponga obblighi ai titolari del trattamento in quanto tali — non lo fa — quanto perché modifica il parametro di adeguatezza delle misure tecniche e organizzative che il Regolamento (UE) 2016/679 impone.

Il Cyber Resilience Act nel sistema delle fonti europee

Oggetto, definizioni e ambito di applicazione

Il Regolamento (UE) 2024/2847 reca norme orizzontali di cybersicurezza per i prodotti con elementi digitali immessi sul mercato dell’Unione. La nozione centrale è quella di “prodotto con elementi digitali”, che il regolamento costruisce in termini volutamente ampi, comprendendo prodotti software o hardware e le relative soluzioni di elaborazione dati da remoto, purché il prodotto sia destinato a essere collegato, direttamente o indirettamente, a un dispositivo o a una rete.

In sostanza, l’elemento qualificante non è la natura del bene — tangibile o immateriale — ma la sua connettività, attuale o anche soltanto potenziale e indiretta. In termini più pragmatici: rientra nell’ambito tanto il firmware di una telecamera di videosorveglianza quanto l’applicativo installato sulla postazione di lavoro, tanto il sensore industriale che dialoga con un concentratore quanto il componente software di terze parti incorporato in un prodotto più complesso. Rientrano anche le “soluzioni di elaborazione dati da remoto”, vale a dire quelle componenti di backend la cui assenza impedirebbe al prodotto di svolgere le proprie funzioni: un elettrodomestico connesso che senza il proprio cloud diventa inerte porta con sé, ai fini della conformità, anche l’infrastruttura remota che lo serve.

Il regolamento opera poi una gradazione del rischio che determina la procedura di valutazione della conformità applicabile. Per la generalità dei prodotti è ammesso il controllo interno di produzione, cioè l’autovalutazione del fabbricante; per i prodotti classificati come “importanti”, ripartiti in due classi, e per i prodotti “critici” il regolamento richiede procedure progressivamente più stringenti, che possono coinvolgere un organismo notificato o la certificazione nell’ambito di uno schema europeo adottato ai sensi del Regolamento (UE) 2019/881. La differenza non è formale: per un fabbricante di prodotti rientranti nelle categorie più sensibili — si pensi, a titolo esemplificativo, ai sistemi di gestione delle identità, agli strumenti di gestione della configurazione, ai firewall o agli ipervisori — la conformità passa attraverso un soggetto terzo accreditato e notificato, con tempi e costi che vanno pianificati con largo anticipo.

Il perimetro conosce esclusioni significative, dettate dall’esigenza di evitare sovrapposizioni con normative settoriali già dotate di requisiti di cybersicurezza: restano fuori, in particolare, i dispositivi medici disciplinati dal Regolamento (UE) 2017/745, i prodotti del settore automobilistico coperti dal Regolamento (UE) 2019/2144, i prodotti dell’aviazione civile soggetti al Regolamento (UE) 2018/1139, nonché i prodotti sviluppati esclusivamente per finalità di sicurezza nazionale o di difesa. Esclusi anche i servizi offerti in modalità puramente “software as a service” che non costituiscano soluzione di elaborazione dati da remoto funzionalmente integrata in un prodotto: la linea di confine, su questo punto, appare allo scrivente tra le più delicate dell’intera disciplina, e si tornerà oltre sul tema.

Un capitolo a sé riguarda il software libero e open source. Il regolamento non assoggetta agli obblighi del fabbricante chi sviluppa o mette a disposizione software open source al di fuori di un’attività commerciale, ma introduce la figura dello “steward” del software libero, cioè del soggetto — tipicamente una fondazione — che sostiene in modo continuativo lo sviluppo di software open source destinato a usi commerciali, assoggettandolo a obblighi attenuati in materia di politica di sicurezza e di cooperazione con le autorità. Si tratta di una soluzione di compromesso, la cui tenuta pratica dipenderà in larga misura dagli orientamenti interpretativi che la Commissione e le autorità nazionali adotteranno.

I requisiti essenziali e la logica del ciclo di vita

Il cuore sostanziale del regolamento risiede nei requisiti essenziali di cybersicurezza, articolati in due parti: i requisiti relativi alle proprietà del prodotto e quelli relativi alla gestione delle vulnerabilità.

Quanto ai primi, il principio generale è che il prodotto sia progettato, sviluppato e fabbricato in modo da garantire un livello adeguato di cybersicurezza in base ai rischi, e sia fornito senza vulnerabilità sfruttabili note. Seguono prescrizioni che il giurista della protezione dei dati riconoscerà immediatamente come trasposizione, sul piano del prodotto, di principi già noti: configurazione sicura per impostazione predefinita, con possibilità di ripristino allo stato di fabbrica; protezione dagli accessi non autorizzati mediante meccanismi di autenticazione e gestione delle identità; protezione della riservatezza dei dati, anche attraverso cifratura; protezione dell’integrità dei dati e dei comandi; minimizzazione dei dati trattati, limitandoli a quanto adeguato, pertinente e limitato a quanto necessario in relazione all’uso previsto; resilienza agli attacchi di tipo denial of service; riduzione della superficie d’attacco; registrazione e monitoraggio delle attività rilevanti per la sicurezza; possibilità per l’utente di rimuovere in modo sicuro e permanente dati e impostazioni.

La seconda parte dei requisiti attiene alla gestione delle vulnerabilità e costituisce, secondo il parere di chi scrive, l’elemento di maggiore impatto organizzativo per i fabbricanti. Il regolamento richiede di identificare e documentare le vulnerabilità e i componenti del prodotto, redigendo una distinta base del software — la cosiddetta SBOM, software bill of materials — almeno per le dipendenze di primo livello; di porre rimedio senza indugio alle vulnerabilità, anche mediante aggiornamenti di sicurezza; di applicare test e riesami periodici; di pubblicare informazioni sulle vulnerabilità corrette una volta reso disponibile il rimedio; di adottare e rendere pubblica una politica di divulgazione coordinata delle vulnerabilità; di agevolare la condivisione delle informazioni, anche fornendo un recapito per la segnalazione; di distribuire gli aggiornamenti in modo sicuro e tempestivo, di norma gratuitamente e separandoli, ove tecnicamente possibile, dagli aggiornamenti funzionali.

A questi obblighi si accompagna la definizione di un “periodo di supporto”, che il regolamento àncora alla vita utile attesa del prodotto e che, in linea generale, non deve essere inferiore a cinque anni, salvo che la vita utile attesa sia più breve. Il periodo di supporto va comunicato all’utilizzatore in modo chiaro e comprensibile all’atto dell’acquisto.

In termini più concreti: il Cyber Resilience Act impone di smettere di concepire il software come bene che si vende una volta e si abbandona. Impone un impegno contrattuale e pubblico sulla manutenzione di sicurezza, con una scadenza dichiarata. Per il DPO e per il giurista d’impresa questa informazione diventa un dato di qualificazione del fornitore: un prodotto il cui periodo di supporto è prossimo alla scadenza è, per definizione, un prodotto destinato a divenire inidoneo a sorreggere misure tecniche adeguate ai sensi dell’articolo 32 del Regolamento (UE) 2016/679.

Gli obblighi di segnalazione delle vulnerabilità e degli incidenti

Il regolamento introduce un regime di segnalazione che non ha precedenti nella legislazione di prodotto e che si colloca, per logica, accanto a quello della Direttiva (UE) 2022/2555 e dell’articolo 33 del Regolamento (UE) 2016/679, pur distinguendosene nettamente quanto a presupposti e destinatari.

Il fabbricante è tenuto a notificare le vulnerabilità attivamente sfruttate contenute nel prodotto, nonché gli incidenti gravi che abbiano un impatto sulla sicurezza del prodotto. La notifica segue una scansione in tre tempi: una segnalazione di preallarme entro ventiquattro ore dalla conoscenza del fatto, una notifica più strutturata entro settantadue ore e una relazione finale — entro quattordici giorni dalla disponibilità di una misura correttiva, nel caso della vulnerabilità attivamente sfruttata, ed entro un mese dalla notifica, nel caso dell’incidente grave. Le segnalazioni confluiscono su una piattaforma unica di notifica gestita a livello europeo dall’ENISA, con instradamento verso il CSIRT designato come coordinatore e verso l’ENISA stessa. È previsto inoltre, a valle, un obbligo di informare senza indebito ritardo gli utilizzatori interessati e, ove opportuno, di indicare le misure correttive adottabili.

Appare chiaro allo scrivente che questa architettura genererà, per molte organizzazioni, una pluralità di canali di segnalazione concorrenti e non perfettamente allineati nei tempi: ventiquattro ore per il preallarme del Cyber Resilience Act, ventiquattro ore per il preallarme NIS2, settantadue ore per la notifica al Garante ai sensi dell’articolo 33 del Regolamento (UE) 2016/679, con termini ulteriori per le entità finanziarie soggette al Regolamento (UE) 2022/2554. La gestione di questa concorrenza non è un problema teorico: è un problema di procedura interna, di responsabilità assegnate e di prontezza decisionale nelle prime ore di una crisi.

Il calendario applicativo e la finestra di adeguamento

Il Regolamento (UE) 2024/2847 è entrato in vigore nel dicembre 2024 ma la sua applicazione è scaglionata. Le disposizioni relative alla notifica degli organismi di valutazione della conformità trovano applicazione anticipata, a partire da giugno 2026, per consentire la costruzione dell’infrastruttura di certificazione prima che gli obblighi sostanziali divengano esigibili. Gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi a carico dei fabbricanti si applicano a partire da settembre 2026. Il grosso degli obblighi — requisiti essenziali, valutazione della conformità, marcatura CE, documentazione tecnica, obblighi degli importatori e dei distributori — diviene pienamente applicabile a dicembre 2027.

Va detto che la distanza temporale è ingannevole. Per un fabbricante che debba ridisegnare i processi di sviluppo sicuro, introdurre la generazione automatizzata della distinta base del software, costruire un processo di divulgazione coordinata delle vulnerabilità e, nei casi più complessi, affidarsi a un organismo notificato la cui disponibilità sul mercato è oggi limitata, l’orizzonte di dicembre 2027 è già stretto. Per l’acquirente professionale, poi, la finestra è ancora più breve: i contratti di fornitura pluriennali che si firmano oggi avranno effetto quando il regolamento sarà pienamente applicabile, e dovrebbero perciò già contenere le clausole di allineamento di cui si dirà nella sezione operativa.

L’adeguamento nazionale: l’Agenzia per la cybersicurezza nazionale al centro del sistema

Perché serve un decreto legislativo se il regolamento è direttamente applicabile

Una precisazione metodologica è opportuna, perché la domanda ricorre spesso. Il regolamento europeo è obbligatorio in tutti i suoi elementi e direttamente applicabile in ciascuno degli Stati membri ai sensi dell’articolo 288 del Trattato sul funzionamento dell’Unione europea: non richiede, né in linea di principio consente, un recepimento. Tuttavia, i regolamenti di nuova generazione contengono sistematicamente rinvii al diritto nazionale per profili che l’Unione non può o non vuole disciplinare direttamente: la designazione delle autorità competenti, l’organizzazione dei poteri ispettivi, il procedimento sanzionatorio, le tariffe per i servizi resi, il raccordo con l’ordinamento processuale interno.

È esattamente ciò che fa lo schema di decreto legislativo in esame, adottato sulla base della delega contenuta nella legge di delegazione europea 2025. Non si tratta, dunque, di “recepire” il Cyber Resilience Act, ma di dotarlo dell’apparato istituzionale e procedimentale interno senza il quale resterebbe inapplicato. La distinzione non è accademica: comporta che il margine di manovra del legislatore nazionale sia limitato e che ogni disposizione interna vada letta in funzione servente rispetto al regolamento.

ACN autorità di notifica e autorità di vigilanza del mercato

Lo schema individua l’Agenzia per la cybersicurezza nazionale quale autorità di notifica, cioè quale soggetto responsabile dell’istituzione e dell’esecuzione delle procedure necessarie per la valutazione, la designazione e la notifica alla Commissione degli organismi di valutazione della conformità, nonché del loro successivo monitoraggio. La stessa Agenzia è individuata come autorità di vigilanza del mercato ai sensi del Regolamento (UE) 2019/1020, con i poteri ispettivi, prescrittivi e interdittivi che quel regolamento attribuisce.

La scelta appare coerente con l’assetto istituzionale costruito dal decreto-legge 82/2021, convertito con modificazioni dalla legge 109/2021, che ha istituito l’Agenzia, e consolidato dal decreto legislativo 138/2024 di recepimento della Direttiva (UE) 2022/2555, che ha assegnato all’Agenzia il ruolo di autorità nazionale competente NIS e di CSIRT Italia. Concentrare in capo al medesimo soggetto la vigilanza sulla sicurezza dei prodotti e la vigilanza sulla sicurezza delle entità che quei prodotti utilizzano presenta un indubbio vantaggio di coerenza informativa: l’Agenzia che riceve le notifiche di incidente dai soggetti essenziali e importanti è la stessa che riceve le notifiche di vulnerabilità attivamente sfruttate dai fabbricanti, e può quindi correlare i due flussi.

Si ritiene, tuttavia, che la concentrazione ponga anche un tema di carico amministrativo e di competenze. La vigilanza del mercato è attività tecnica e giuridica distinta dalla gestione degli incidenti: presuppone capacità di campionamento, laboratori o convenzioni con laboratori, conoscenza della prassi del nuovo quadro legislativo, gestione del sistema di scambio rapido di informazioni fra Stati membri. Non si ha evidenza, allo stato, del dimensionamento di risorse previsto per questa funzione, al di là della previsione — riportata dalla fonte — secondo cui i proventi delle sanzioni andranno a “incrementare la dotazione del bilancio dell’Acn”.

Quest’ultima previsione merita una riflessione sobria. Il meccanismo che destina all’autorità vigilante gli introiti delle sanzioni che essa stessa irroga non è inedito nell’ordinamento italiano, e risponde a un’esigenza pratica di autofinanziamento di funzioni nuove e onerose. Secondo il parere di chi scrive, esso richiede però particolare cura nella costruzione delle garanzie procedimentali e nella separazione interna fra funzioni istruttorie e funzioni decisorie, affinché non possa essere messa in discussione l’imparzialità dell’azione amministrativa. Si tratta di un rilievo di tecnica legislativa, non di un’obiezione al merito della scelta.

Il coordinamento con Banca d’Italia, Consob, IVASS e Garante privacy

La fonte riferisce che l’Agenzia opererà in coordinamento con le altre autorità di vigilanza, segnatamente Banca d’Italia, Consob, IVASS e il Garante per la protezione dei dati personali, e che le autorità di vigilanza potranno adottare atti di indirizzo nella forma di linee guida, raccomandazioni e buone pratiche.

La previsione non è casuale e risponde a due distinte esigenze poste dal regolamento. Da un lato, il Cyber Resilience Act riconosce che per i prodotti con elementi digitali sviluppati o utilizzati da entità finanziarie soggette al Regolamento (UE) 2022/2554 — il regolamento DORA — la vigilanza del mercato debba raccordarsi con le autorità competenti in materia finanziaria, onde evitare duplicazioni di controllo sulla medesima catena di fornitura ICT. Dall’altro, il regolamento fa salve le competenze delle autorità di controllo in materia di protezione dei dati personali, le quali conservano i poteri loro attribuiti dal Regolamento (UE) 2016/679 quando il prodotto tratti dati personali.

Il punto merita di essere esplicitato, perché è qui che il Cyber Resilience Act interseca il lavoro quotidiano del lettore. La non conformità di un prodotto ai requisiti essenziali di cybersicurezza non determina, di per sé, una violazione del Regolamento (UE) 2016/679; ma l’utilizzo consapevole, da parte di un titolare, di un prodotto non conforme per trattare dati personali può ben integrare una violazione degli articoli 25 e 32, perché il titolare non avrebbe adottato misure tecniche adeguate al rischio. In termini più pragmatici: dal dicembre 2027 la marcatura CE di cyber-resilienza diventerà un indicatore immediatamente verificabile nella scelta del fornitore, e la sua assenza — su prodotti che ne dovrebbero essere dotati — sarà difficilmente giustificabile in sede di accertamento.

La possibilità per le autorità di adottare atti di indirizzo, infine, apre uno spazio interpretativo che si auspica venga presidiato in modo coordinato. L’esperienza applicativa dei sistemi di gestione insegna che la moltiplicazione di linee guida settoriali non allineate produce incertezza anziché ridurla; si suggerisce pertanto che gli indirizzi vengano, per quanto possibile, elaborati congiuntamente o quantomeno sottoposti a consultazione incrociata fra le autorità coinvolte.

L’accreditamento, le tariffe e un dubbio terminologico

Per attestare la conformità a chi ne farà apposita domanda all’Acn sarà rilasciato un ‘certificato di accreditamento’, a fronte del pagamento anche di una apposita tariffa che copra i costi effettivi del servizio.

Su questo punto una precisazione tecnica appare necessaria, formulata in termini dubitativi in assenza del testo definitivo. Nel sistema del nuovo quadro legislativo, l’accreditamento degli organismi di valutazione della conformità è attività riservata all’unico organismo nazionale di accreditamento designato ai sensi del Regolamento (CE) n. 765/2008 — in Italia Accredia — mentre la notifica alla Commissione europea e agli altri Stati membri spetta all’autorità di notifica. Si tratta di due atti distinti: l’accreditamento attesta la competenza tecnica, la notifica abilita l’organismo a svolgere le procedure di valutazione della conformità previste dalla normativa armonizzata di riferimento. Qualora lo schema utilizzasse il termine “certificato di accreditamento” per designare l’atto con cui l’Agenzia riconosce un organismo ai fini del Cyber Resilience Act, si porrebbe una questione di coerenza lessicale con il quadro europeo, che potrebbe generare incertezze applicative. Sebbene la questione possa risolversi in un mero problema redazionale; resta il rilievo che, in materia di conformità di prodotto, la precisione terminologica ha conseguenze pratiche rilevanti, perché da essa dipende il riconoscimento transfrontaliero degli atti.

Quanto alle tariffe, la previsione di una copertura dei costi effettivi del servizio è coerente con la prassi amministrativa consolidata e con l’esigenza di non gravare la fiscalità generale di oneri connessi a servizi resi a singoli operatori economici. Si ritiene opportuno che il decreto ministeriale o il provvedimento attuativo che fisserà gli importi sia accompagnato da una valutazione dell’impatto sulle imprese di minori dimensioni, poiché il costo della conformità rischia altrimenti di costituire una barriera all’ingresso.

La sandbox normativa per la cyber-resilienza

Fra le previsioni più interessanti dello schema vi è l’istituzione di uno spazio di sperimentazione normativa sotto la supervisione dell’Agenzia, denominato “Sandbox-CRA”: ambienti di prova controllati nei quali i prodotti innovativi possono essere sviluppati e testati, ai fini della verifica della loro conformità, per un periodo limitato precedente all’immissione sul mercato.

Lo strumento è mutuato, con ogni evidenza, dall’esperienza degli spazi di sperimentazione normativa previsti dal Regolamento (UE) 2024/1689 in materia di intelligenza artificiale, nonché dalle sandbox regolamentari già sperimentate nel settore finanziario. La ratio è duplice: consentire all’operatore economico di confrontarsi anticipatamente con l’autorità sull’interpretazione dei requisiti applicabili, riducendo il rischio di investimenti su soluzioni che si rivelino poi non conformi; e consentire all’autorità di acquisire conoscenza tecnica su tecnologie emergenti prima che esse raggiungano il mercato di massa.

Si ritiene che l’utilità effettiva dello strumento dipenderà da tre variabili, nessuna delle quali è ancora definita. La prima è la selettività dell’accesso: una sandbox aperta a tutti si trasforma in uno sportello di consulenza gratuita che l’autorità non ha le risorse per gestire, una sandbox troppo selettiva diventa irrilevante. La seconda è il valore giuridico degli esiti: se la partecipazione alla sperimentazione non produce alcun effetto di affidamento tutelabile in sede di successiva vigilanza, l’incentivo a parteciparvi è modesto. La terza è l’articolazione con il Cyber Resilience Act, che non prevede espressamente sandbox e che fonda la conformità sulla responsabilità del fabbricante: lo spazio di sperimentazione nazionale non può, evidentemente, derogare ai requisiti essenziali né surrogare la procedura di valutazione della conformità, e dovrà perciò collocarsi in una fase rigorosamente antecedente all’immissione sul mercato.

Le misure per microimprese, PMI e start-up

Lo schema prevede misure specifiche per microimprese, piccole e medie imprese e start-up. Anche il regolamento europeo contiene, del resto, disposizioni di alleggerimento, fra cui forme semplificate di documentazione tecnica per le microimprese e le piccole imprese e la previsione di orientamenti e sostegno da parte degli Stati membri.

Va detto che l’alleggerimento riguarda le modalità di dimostrazione della conformità, non i requisiti sostanziali. Un prodotto fabbricato da una microimpresa deve soddisfare gli stessi requisiti essenziali di cybersicurezza di un prodotto fabbricato da una multinazionale: ciò che cambia è il grado di formalizzazione della documentazione e il supporto messo a disposizione dalle autorità. Questa precisazione è rilevante perché nell’esperienza applicativa si riscontra spesso la convinzione, infondata, che le soglie dimensionali esonerino dal merito degli obblighi. Non è così né nel Cyber Resilience Act né, per quanto di stretto interesse in questa sede, nel Regolamento (UE) 2016/679.

Il regime sanzionatorio

Il quadro sanzionatorio riproduce la gradazione prevista dal regolamento europeo. Le violazioni più gravi — segnatamente l’inosservanza dei requisiti essenziali di cybersicurezza e degli obblighi fondamentali del fabbricante — sono punite fino a 15 milioni di euro o fino al 2,5% del fatturato mondiale totale annuo, se superiore. Le violazioni di altri obblighi previsti dal regolamento sono punite fino a 10 milioni di euro o fino al 2% del fatturato mondiale totale annuo. La comunicazione di informazioni inesatte, incomplete o fuorvianti agli organismi notificati o alle autorità di vigilanza del mercato è punita fino a 5 milioni di euro o fino all’1% del fatturato.

L’architettura ricalca, nella struttura e nella tecnica del “massimo alternativo”, quella del Regolamento (UE) 2016/679, con soglie collocate fra quelle dell’articolo 83, paragrafo 4, e quelle dell’articolo 83, paragrafo 5. Il parametro del fatturato mondiale totale annuo conferma la scelta europea di ancorare la deterrenza alla capacità economica del gruppo e non della singola entità giuridica.

Due osservazioni paiono opportune. La prima riguarda il cumulo: un medesimo fatto — l’immissione sul mercato di un prodotto con una vulnerabilità nota non corretta, poi sfruttata per esfiltrare dati personali — può astrattamente rilevare sotto il profilo del Cyber Resilience Act nei confronti del fabbricante, sotto il profilo del Regolamento (UE) 2016/679 nei confronti del titolare utilizzatore e, eventualmente, sotto il profilo del decreto legislativo 138/2024 se l’utilizzatore è soggetto essenziale o importante. I presupposti sono diversi e diversi sono i soggetti responsabili, sicché non si pone in senso proprio un problema di ne bis in idem; si pone, piuttosto, un problema di coordinamento istruttorio fra autorità, che l’articolazione di raccordo prevista dallo schema dovrà saper governare.

La seconda osservazione riguarda la responsabilità civile. Il Cyber Resilience Act non introduce un titolo autonomo di risarcimento, ma la qualificazione della cybersicurezza come requisito essenziale di prodotto incide inevitabilmente sulla disciplina della responsabilità per danno da prodotto difettoso, che la Direttiva (UE) 2024/2853 ha nel frattempo riformato includendo espressamente il software fra i prodotti e considerando la mancata fornitura di aggiornamenti di sicurezza fra le circostanze rilevanti per la valutazione del difetto. La convergenza fra le due discipline è, secondo il parere di chi scrive, uno degli sviluppi più significativi da monitorare nel medio periodo.

Il rapporto con l’AI Act: una conformità che ne presume un’altra

Merita attenzione specifica il rilievo secondo cui il regolamento “si applica anche ai prodotti classificati come sistemi di IA ad alto rischio”.

Il Regolamento (UE) 2024/2847 contiene infatti una disposizione di raccordo con il Regolamento (UE) 2024/1689 costruita secondo la tecnica della presunzione di conformità: i prodotti con elementi digitali che siano al tempo stesso sistemi di intelligenza artificiale ad alto rischio e che siano conformi ai requisiti essenziali di cybersicurezza del Cyber Resilience Act si presumono conformi ai requisiti di cybersicurezza posti dall’articolo 15 dell’AI Act, nella misura in cui tali requisiti siano coperti dalla dichiarazione UE di conformità rilasciata ai sensi del Cyber Resilience Act.

In sostanza, il legislatore europeo ha inteso evitare che il medesimo fornitore debba dimostrare due volte, con due procedure distinte e davanti a due interlocutori diversi, la stessa cosa. In termini più pragmatici: chi fornisce un sistema di IA ad alto rischio incorporato in un prodotto con elementi digitali potrà valorizzare la conformità al Cyber Resilience Act come elemento della propria conformità all’AI Act limitatamente al profilo della robustezza e della sicurezza informatica, fermi restando tutti gli altri requisiti — gestione del rischio, governance dei dati, documentazione, trasparenza, sorveglianza umana, accuratezza — che restano integralmente a carico del fornitore ai sensi dell’AI Act.

Va detto che la presunzione non è un esonero. Le autorità di vigilanza del mercato designate ai sensi dell’AI Act conservano i propri poteri, e la presunzione opera nei limiti della sovrapposizione oggettiva fra i due corpi di requisiti. Non si ha evidenza, allo stato, di orientamenti interpretativi consolidati sul perimetro esatto di tale sovrapposizione, e si ritiene che questo costituisca uno dei terreni su cui gli atti di indirizzo delle autorità nazionali potranno fornire un contributo utile.

Un’ulteriore implicazione riguarda il coordinamento istituzionale interno. L’Italia ha individuato, con la legge 132/2025 recante disposizioni in materia di intelligenza artificiale, le autorità nazionali per l’intelligenza artificiale, assegnando all’Agenzia per la cybersicurezza nazionale e all’Agenzia per l’Italia digitale ruoli distinti. La sovrapposizione fra il ruolo dell’Agenzia come autorità di vigilanza del mercato per il Cyber Resilience Act e il suo ruolo nell’architettura nazionale dell’intelligenza artificiale richiederà, verosimilmente, un affinamento delle procedure interne, che allo stato non risulta ancora definito.

Profili critici e questioni interpretative aperte

Il confine del software as a service

Si è accennato alla delicatezza del confine fra prodotto con elementi digitali e servizio. Il regolamento include le soluzioni di elaborazione dati da remoto funzionalmente integrate nel prodotto, ma esclude i servizi cloud in quanto tali, che restano presidiati dalla Direttiva (UE) 2022/2555 e, per il settore finanziario, dal Regolamento (UE) 2022/2554.

Il problema pratico è che l’architettura applicativa contemporanea rende sempre più sfumata questa distinzione. Un applicativo distribuito in modalità ibrida, con un client locale sottile e la gran parte della logica eseguita su infrastruttura del fornitore, può essere qualificato in un senso o nell’altro a seconda di come si legge il criterio della funzionalità integrata. Si ritiene che la qualificazione debba essere condotta caso per caso, verificando se la componente remota sia progettata e sviluppata dal fabbricante o sotto la sua responsabilità e se la sua assenza impedisca al prodotto di svolgere una delle proprie funzioni. Non si ha evidenza di orientamenti ufficiali che risolvano in modo definitivo le ipotesi di confine, e si suggerisce prudenza nella redazione delle clausole contrattuali, evitando qualificazioni unilaterali che potrebbero rivelarsi errate.

La disponibilità degli organismi notificati

Un secondo profilo di attenzione riguarda la capacità del sistema di certificazione. Per i prodotti rientranti nelle categorie importanti e critiche, l’intervento di un organismo notificato o la certificazione nell’ambito di uno schema europeo è condizione per l’immissione sul mercato. Il numero di organismi disponibili a livello europeo, allo stato, non risulta ancora commisurato alla domanda attesa per dicembre 2027, e il processo di accreditamento e notifica richiede tempi non comprimibili.

Si tratta di un rischio sistemico già osservato in occasione dell’entrata in applicazione del Regolamento (UE) 2017/745 sui dispositivi medici, quando la carenza di organismi notificati determinò difficoltà significative per gli operatori. Appare chiaro allo scrivente che l’individuazione dell’Agenzia come autorità di notifica assume, in questa prospettiva, un rilievo strategico: la rapidità con cui il sistema nazionale saprà designare e notificare organismi competenti inciderà direttamente sulla competitività dei fabbricanti stabiliti in Italia.

Le norme armonizzate e la presunzione di conformità

Il meccanismo del nuovo quadro legislativo funziona compiutamente solo quando esistono norme armonizzate, i cui riferimenti siano pubblicati nella Gazzetta ufficiale dell’Unione europea, la cui applicazione conferisce presunzione di conformità ai requisiti essenziali. In assenza di tali norme, il fabbricante deve dimostrare la conformità con mezzi propri, con un significativo aumento dell’onere probatorio e dell’incertezza.

La Commissione ha conferito mandato agli organismi europei di normazione per l’elaborazione delle norme armonizzate a supporto del Cyber Resilience Act. Non si ha evidenza, alla data in cui si scrive, della pubblicazione dell’intero corpus. La tempistica della normazione tecnica costituisce dunque una variabile critica: una pubblicazione tardiva comprimerebbe ulteriormente la finestra di adeguamento dei fabbricanti.

Il raccordo fra segnalazione di vulnerabilità e notifica di data breach

Un ultimo profilo, di diretto interesse per il lettore, concerne il rapporto fra l’obbligo del fabbricante di segnalare la vulnerabilità attivamente sfruttata e l’obbligo del titolare di notificare la violazione di dati personali ai sensi dell’articolo 33 del Regolamento (UE) 2016/679.

I due obblighi hanno presupposti distinti. Il primo scatta alla conoscenza dello sfruttamento attivo della vulnerabilità, indipendentemente da qualsiasi coinvolgimento di dati personali; il secondo scatta alla conoscenza della violazione di sicurezza che comporti distruzione, perdita, modifica, divulgazione non autorizzata o accesso ai dati personali. Può accadere che il fabbricante segnali e non vi sia alcun data breach; può accadere, specularmente, che vi sia un data breach senza che la vulnerabilità sia nota al fabbricante.

Il punto operativo è però un altro. L’informazione che il fabbricante, in adempimento del Cyber Resilience Act, deve trasmettere agli utilizzatori sulla vulnerabilità attivamente sfruttata costituisce, per il titolare del trattamento che utilizzi quel prodotto, il momento in cui viene “a conoscenza” di una circostanza che impone una valutazione immediata. Se il prodotto tratta dati personali e la vulnerabilità è sfruttata attivamente, il titolare deve verificare senza indugio se vi sia stata una violazione nella propria installazione e, in caso affermativo, attivare il termine di settantadue ore. Si ritiene pertanto che le procedure interne di gestione delle violazioni debbano essere aggiornate per includere, fra gli eventi innescanti, la ricezione di un avviso di vulnerabilità dal fornitore.

Gli adempimenti per DPO, giuristi d’impresa e funzioni di conformità

Chiarito il quadro, conviene esporre in termini concreti le azioni che si suggerisce di avviare, distinguendo la posizione di chi fabbrica o distribuisce prodotti con elementi digitali da quella, più diffusa, di chi li acquista e li utilizza per trattare dati personali.

Per l’impresa che fabbrica, sviluppa o distribuisce, il primo passaggio è la qualificazione del portafoglio: occorre censire tutti i prodotti, hardware e software, immessi o destinati a essere immessi sul mercato dell’Unione, verificare per ciascuno se ricada nell’ambito di applicazione del Regolamento (UE) 2024/2847 e, in caso affermativo, se rientri nella categoria generale ovvero fra i prodotti importanti o critici, poiché da tale classificazione discende la procedura di valutazione della conformità applicabile. Va detto che questa attività non è meramente tecnica: richiede una lettura giuridica delle definizioni e delle esclusioni, e andrebbe condotta congiuntamente dalla funzione legale e dalla funzione di sviluppo prodotto. Strettamente collegata è la verifica del ruolo rivestito nella catena di fornitura, perché il regolamento distingue le posizioni del fabbricante, dell’importatore e del distributore, e assoggetta a obblighi di fabbricante anche chi immetta un prodotto sul mercato con il proprio nome o marchio o chi apporti a un prodotto già immesso una modifica sostanziale: la prassi diffusa del cosiddetto “private label” comporta, in questa prospettiva, un trasferimento di responsabilità che molte organizzazioni non hanno ancora metabolizzato.

Segue la mappatura delle dipendenze software, cioè la costruzione sistematica della distinta base dei componenti di terze parti e open source incorporati nei propri prodotti, con la relativa tracciatura delle versioni e delle licenze. L’esperienza applicativa dei sistemi di gestione insegna che questa è l’attività che genera le maggiori sorprese, perché il numero effettivo delle dipendenze transitive eccede quasi sempre la percezione interna. Alla mappatura deve accompagnarsi la definizione del periodo di supporto per ciascuna linea di prodotto, decisione che non è tecnica ma di modello di business, poiché impegna l’impresa a erogare aggiornamenti di sicurezza, di norma gratuiti, per un arco temporale dichiarato e non inferiore, in linea generale, a cinque anni salvo vita utile attesa più breve.

Sul piano dei processi, occorre istituire una politica di divulgazione coordinata delle vulnerabilità, resa pubblica e corredata di un recapito funzionante per le segnalazioni provenienti da ricercatori e terzi, e un processo di gestione delle segnalazioni obbligatorie calibrato sulla scansione delle ventiquattro e delle settantadue ore e della relazione finale, con individuazione nominativa dei soggetti abilitati a decidere e a trasmettere, poiché nessun termine di ventiquattro ore è rispettabile se la decisione deve risalire una catena gerarchica non predisposta. Si suggerisce di testare tale processo mediante esercitazioni documentate, con la stessa logica con cui si testano i piani di continuità operativa: l’adeguatezza di una procedura di notifica si misura sulla sua esecuzione simulata, non sulla sua redazione.

Per l’impresa che acquista e utilizza, il baricentro si sposta sulla revisione della contrattualistica di fornitura. Si suggerisce di introdurre nei contratti in corso di negoziazione clausole che impegnino il fornitore a garantire, entro la piena applicabilità del regolamento, la conformità del prodotto ai requisiti essenziali e la disponibilità della dichiarazione UE di conformità e della documentazione di accompagnamento; a dichiarare il periodo di supporto e a comunicarne tempestivamente la scadenza; a fornire, su richiesta, la distinta base del software; a notificare al cliente, entro termini contrattualmente definiti e compatibili con l’articolo 33 del Regolamento (UE) 2016/679, le vulnerabilità attivamente sfruttate e gli incidenti che riguardino il prodotto. Tali clausole, ove il fornitore sia anche responsabile del trattamento, si integrano naturalmente con il contenuto obbligatorio dell’atto giuridico ai sensi dell’articolo 28 del medesimo regolamento, e in particolare con l’obbligo di assistenza al titolare previsto dal paragrafo 3, lettera f).

Collegata è la revisione dei criteri di qualificazione dei fornitori, nella quale la conformità al Cyber Resilience Act andrebbe inserita come requisito di ammissibilità progressivo, con una fase transitoria in cui costituisce elemento premiante e una fase, a regime, in cui diviene condizione necessaria per i prodotti che ne siano soggetti. Nel settore pubblico l’innesto avverrà naturalmente attraverso le specifiche tecniche dei documenti di gara, con le cautele imposte dal decreto legislativo 36/2023 in materia di proporzionalità e non discriminazione dei requisiti.

Sul piano della documentazione privacy, si suggerisce l’aggiornamento delle valutazioni d’impatto già condotte e dei relativi modelli, affinché nella sezione dedicata alle misure di sicurezza sia dato conto, ove pertinente, della conformità del prodotto utilizzato ai requisiti del Cyber Resilience Act e del periodo di supporto residuo. Allo stesso modo, il registro delle attività di trattamento di cui all’articolo 30 del Regolamento (UE) 2016/679 può utilmente essere correlato, sul piano organizzativo interno, all’inventario degli asset applicativi, così da rendere immediatamente verificabile quali trattamenti risultino sorretti da prodotti prossimi alla fine del supporto. Si tratta di un raccordo che la norma non impone espressamente ma che, secondo il parere di chi scrive, costituisce buona prassi di accountability e rende dimostrabile la diligenza del titolare.

Occorre poi intervenire sulla procedura di gestione delle violazioni di dati personali, includendo espressamente fra gli eventi che attivano la valutazione preliminare la ricezione di un avviso di vulnerabilità attivamente sfruttata proveniente da un fornitore, con assegnazione della responsabilità di tale valutazione e definizione dei tempi massimi entro cui essa deve concludersi. Nelle organizzazioni soggette anche al decreto legislativo 138/2024, la medesima procedura deve governare la concorrenza fra il canale di notifica verso il Garante e quello verso il CSIRT Italia, evitando che la gestione di un canale ritardi l’altro.

Resta, infine, il tema della formazione mirata. Si suggerisce di destinare interventi formativi distinti alle funzioni di acquisto e di sviluppo prodotto, poiché il contenuto rilevante è differente: per le prime si tratta di saper leggere una dichiarazione UE di conformità e di riconoscere le informazioni sul periodo di supporto, per le seconde di comprendere le implicazioni dei requisiti essenziali sulle scelte di architettura. Per il DPO, la vigilanza sull’evoluzione normativa comprenderà il monitoraggio della pubblicazione delle norme armonizzate, degli atti di esecuzione della Commissione sulle specifiche tecniche e sulle categorie di prodotti, nonché degli atti di indirizzo che le autorità nazionali adotteranno; si ritiene opportuno, su questo, predisporre un presidio documentato, perché la frammentazione delle fonti è tale da rendere il monitoraggio occasionale strutturalmente insufficiente.

Conclusioni

L’adeguamento italiano al Cyber Resilience Act si inserisce in un disegno istituzionale ormai riconoscibile, che fa dell’Agenzia per la cybersicurezza nazionale il punto di convergenza delle competenze in materia di sicurezza informatica, dalla gestione degli incidenti alla vigilanza sui soggetti essenziali e importanti, fino, ora, alla vigilanza sulla sicurezza dei prodotti. La coerenza del disegno è apprezzabile; la sua sostenibilità dipenderà da variabili che allo stato non sono verificabili, in primo luogo il dimensionamento delle risorse dedicate a una funzione — la vigilanza del mercato secondo il modello del nuovo quadro legislativo — che richiede competenze e strumenti in parte diversi da quelli finora impiegati.

Restano aperte alcune questioni specifiche che meriteranno attenzione nei prossimi mesi. La prima riguarda la terminologia e la sostanza dell’atto con cui l’Agenzia riconoscerà gli organismi di valutazione della conformità, e il suo raccordo con il sistema di accreditamento previsto dal Regolamento (CE) n. 765/2008. La seconda concerne l’effettiva operatività della sandbox normativa, il cui valore dipenderà dalla definizione dei criteri di accesso e, soprattutto, dagli effetti giuridici che la partecipazione produrrà in sede di successiva vigilanza. La terza attiene al coordinamento procedimentale fra l’Agenzia e il Garante per la protezione dei dati personali nei casi — destinati a non essere infrequenti — in cui la non conformità di un prodotto si traduca in una violazione di dati personali presso l’utilizzatore: la contiguità materiale delle fattispecie e la diversità dei soggetti responsabili richiedono forme di cooperazione istruttoria che vadano oltre la mera clausola di coordinamento.

Vi è poi una questione di sistema, che trascende l’atto in commento. Il Cyber Resilience Act porta a compimento uno spostamento del baricentro della responsabilità per la sicurezza informatica: dall’utilizzatore, su cui il Regolamento (UE) 2016/679 e la Direttiva (UE) 2022/2555 hanno finora concentrato gli obblighi, verso chi immette sul mercato il prodotto insicuro. Si ritiene che questo riequilibrio sia nel complesso coerente con il principio secondo cui il rischio va allocato presso chi è nella condizione migliore per controllarlo. Ne deriva, però, una conseguenza che non va sottovalutata: man mano che il mercato si popolerà di prodotti conformi e marcati, la scelta di utilizzare un prodotto non conforme diverrà progressivamente meno difendibile per il titolare del trattamento, e il parametro dell’articolo 32 del Regolamento (UE) 2016/679 — adeguatezza delle misure “tenendo conto dello stato dell’arte” — si innalzerà di conseguenza. Non è un effetto automatico né immediato, ma è un effetto strutturale, e conviene iniziare a tenerne conto oggi, quando le decisioni di acquisto producono ancora effetti rivedibili.

Riferimenti normativi

• Regolamento (UE) 2016/679 (GDPR)
• Regolamento (CE) n. 765/2008
• Decisione n. 768/2008/CE
• Regolamento (UE) 2017/745
• Regolamento (UE) 2018/1139
• Regolamento (UE) 2019/881 (Cybersecurity Act)
• Regolamento (UE) 2019/1020
• Regolamento (UE) 2019/2144
• Regolamento (UE) 2022/2554 (DORA)
• Direttiva (UE) 2022/2555 (NIS2)
• Regolamento (UE) 2024/1689 (AI Act)
• Regolamento (UE) 2024/2847 (Cyber Resilience Act)
• Direttiva (UE) 2024/2853
• Trattato sul funzionamento dell’Unione europea
• decreto-legge 82/2021, convertito con modificazioni dalla legge 109/2021
• decreto legislativo 36/2023
• decreto legislativo 138/2024
• legge 132/2025
• legge di delegazione europea 2025