La regolazione europea della sicurezza digitale sta attraversando una trasformazione profonda, destinata a incidere non soltanto sulle imprese tecnologiche, sui produttori di software e sui fornitori di servizi digitali, ma sull’intero modo in cui le organizzazioni progettano, acquistano, gestiscono e governano tecnologie connesse.
Per molti anni la cybersecurity è stata collocata in una posizione prevalentemente funzionale rispetto ad altri ambiti regolatori: costituiva una misura tecnica nell’ambito della protezione dei dati personali, un requisito contrattuale nei rapporti con i fornitori, un presidio organizzativo nelle infrastrutture critiche o un elemento di diligenza professionale nei servizi digitali.
Oggi, invece, l’Unione europea sembra aver compiuto un salto di qualità, costruendo progressivamente un sistema normativo nel quale la sicurezza non è più un requisito settoriale, ma una condizione generale di affidabilità del mercato digitale.
In questa prospettiva, il Regolamento (UE) 2024/2847, comunemente noto come Cyber Resilience Act, rappresenta un passaggio decisivo. Il CRA introduce requisiti orizzontali di cybersicurezza per i prodotti con elementi digitali, imponendo obblighi lungo l’intero ciclo di vita del prodotto, dalla progettazione alla messa a disposizione sul mercato, dalla gestione delle vulnerabilità agli aggiornamenti di sicurezza, dalla documentazione tecnica alla sorveglianza post-commercializzazione. L’importanza del regolamento non risiede soltanto nella sua portata applicativa, che intercetta una vasta pluralità di software, hardware e prodotti connessi, ma nella sua funzione sistemica: spostare la cybersecurity a monte, nel momento in cui il prodotto viene concepito, sviluppato, valutato e immesso nel mercato europeo.
Il rapporto tra Cyber Resilience Act, GDPR e NIS2 deve essere letto precisamente entro tale scenario. Non si tratta di tre normative parallele, destinate a convivere senza interazioni significative, né di tre discipline che si sovrappongono casualmente generando un aggravio di compliance. Al contrario, esse delineano i tre livelli di un medesimo sistema integrato di sicurezza digitale. Il GDPR presidia la sicurezza del trattamento dei dati personali, imponendo al titolare e al responsabile del trattamento di adottare misure tecniche e organizzative adeguate al rischio. La NIS2 presidia la sicurezza e la resilienza dell’organizzazione, imponendo ai soggetti essenziali e importanti obblighi di gestione del rischio cyber, governance, continuità operativa, sicurezza della supply chain e notifica degli incidenti. Il Cyber Resilience Act presidia invece la sicurezza del prodotto digitale, intervenendo sul software e sull’hardware prima che essi diventino componenti dell’infrastruttura organizzativa o strumenti attraverso i quali vengono trattati dati personali.
La tesi è dunque chiara: il CRA non si limita ad aggiungere un ulteriore adempimento al quadro europeo della cybersecurity, ma completa una triangolazione normativa che collega prodotto, trattamento e organizzazione. Se il GDPR impone di proteggere i dati personali nel contesto dei trattamenti, e se la NIS2 impone di rendere resilienti le organizzazioni che erogano servizi essenziali o importanti, il Cyber Resilience Act interviene sul presupposto tecnologico di entrambi: la sicurezza dei prodotti digitali che tali organizzazioni acquistano, integrano, sviluppano, distribuiscono o utilizzano.
Indice degli argomenti
Dal trattamento al prodotto: il limite storico del GDPR
Il GDPR ha rappresentato, sin dalla sua entrata in applicazione, il principale strumento europeo di responsabilizzazione delle organizzazioni rispetto alla protezione dei dati personali. La sua forza innovativa non si è limitata all’inasprimento del regime sanzionatorio o all’ampliamento dei diritti degli interessati, ma si è manifestata soprattutto nell’introduzione del principio di accountability, che impone al titolare del trattamento non solo di rispettare i principi applicabili, ma anche di essere in grado di comprovarne il rispetto.
In materia di sicurezza, il riferimento centrale è l’articolo 32, che richiede l’adozione di misure tecniche e organizzative adeguate al rischio, tenendo conto dello stato dell’arte, dei costi di attuazione, della natura, dell’oggetto, del contesto e delle finalità del trattamento, nonché del rischio per i diritti e le libertà delle persone fisiche. A tale disposizione si affianca l’articolo 25, dedicato alla protezione dei dati fin dalla progettazione e per impostazione predefinita, che impone di incorporare garanzie adeguate nel trattamento sin dalla fase progettuale.
Tali disposizioni hanno avuto il merito di introdurre nel diritto europeo una logica fortemente anticipatoria. La sicurezza non deve essere applicata soltanto dopo che il trattamento è stato avviato, né può essere ridotta a un rimedio successivo alla violazione. Essa deve essere integrata nella progettazione dei processi, dei sistemi e delle misure organizzative. Tuttavia, il GDPR presenta un limite strutturale: il suo oggetto non è il prodotto digitale in quanto tale, bensì il trattamento di dati personali. Quando un software, un dispositivo connesso o una piattaforma digitale non trattano dati personali, oppure quando il problema di sicurezza riguarda il prodotto prima ancora che esso venga utilizzato in uno specifico trattamento, il GDPR non offre un presidio generale e orizzontale di cybersicurezza.
Anche nei casi in cui il prodotto digitale venga utilizzato per trattare dati personali, il GDPR agisce prevalentemente sul titolare e sul responsabile del trattamento, non necessariamente sul produttore del software o del dispositivo. L’articolo 28 consente certamente di vincolare contrattualmente il responsabile del trattamento, e gli obblighi di sicurezza possono essere trasferiti e specificati nei rapporti tra titolare, responsabile e sub-responsabili. Tuttavia, il produttore di un componente digitale immesso sul mercato non coincide sempre con un responsabile del trattamento ai sensi del GDPR. Può trattarsi di un fabbricante, di uno sviluppatore, di un importatore o di un distributore che non partecipa direttamente al trattamento di dati personali svolto dall’utilizzatore finale.
È proprio in questo spazio che si colloca il Cyber Resilience Act. Il CRA interviene là dove il GDPR non poteva arrivare in modo strutturale, ossia sulla sicurezza intrinseca del prodotto con elementi digitali, indipendentemente dal fatto che esso sia utilizzato, in concreto, per trattare dati personali. In tal senso, il regolamento sulla ciberresilienza non sostituisce il GDPR e non ne attenua la portata; piuttosto, ne rafforza l’effettività, poiché contribuisce a rendere più sicuri i prodotti digitali attraverso i quali, molto spesso, i dati personali vengono raccolti, conservati, trasmessi, elaborati o resi accessibili.
La sicurezza del trattamento, senza sicurezza del prodotto, rischia infatti di restare incompleta. Un titolare può adottare policy, procedure, controlli di accesso, misure di cifratura e valutazioni del rischio, ma se il software impiegato presenta vulnerabilità strutturali, credenziali predefinite insicure, assenza di aggiornamenti, debolezze architetturali o processi di gestione delle vulnerabilità inadeguati, l’intero impianto di accountability può risultare compromesso. Il CRA consente dunque di anticipare il presidio di sicurezza al livello della progettazione e della commercializzazione del prodotto, rafforzando indirettamente anche la capacità dei titolari del trattamento di conformarsi agli articoli 25 e 32 del GDPR.
La NIS2 e la sicurezza dell’organizzazione
Se il GDPR presidia la sicurezza del trattamento, la NIS2 presidia la sicurezza dell’organizzazione. La Direttiva (UE) 2022/2555, recepita nell’ordinamento italiano dal D.Lgs. 138/2024, ha ampliato significativamente il perimetro europeo della cybersecurity, sostituendo la precedente direttiva NIS e introducendo un modello più maturo di gestione del rischio, responsabilità degli organi amministrativi, sicurezza della catena di fornitura e notifica degli incidenti.
L’articolo 21 della NIS2 costituisce il baricentro della disciplina, poiché impone ai soggetti essenziali e importanti di adottare misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi posti alla sicurezza dei sistemi informativi e di rete utilizzati per le loro attività o per la fornitura dei loro servizi, nonché per prevenire o minimizzare l’impatto degli incidenti sui destinatari dei servizi e su altri servizi. La disposizione elenca una serie di ambiti che includono, tra gli altri, le politiche di analisi dei rischi e sicurezza dei sistemi informativi, la gestione degli incidenti, la continuità operativa, la sicurezza della supply chain, la sicurezza nell’acquisizione, sviluppo e manutenzione dei sistemi, la valutazione dell’efficacia delle misure di gestione del rischio, le pratiche di igiene informatica, la crittografia, la sicurezza delle risorse umane, il controllo degli accessi e l’autenticazione.
La NIS2 opera quindi su un piano diverso rispetto al GDPR. Non tutela una specifica categoria di dati, né si concentra soltanto sui diritti e sulle libertà delle persone fisiche. Essa mira a garantire un livello elevato e comune di cybersicurezza nell’Unione, assumendo come oggetto la resilienza delle organizzazioni e dei servizi rilevanti per il funzionamento dell’economia e della società. L’organizzazione soggetta alla NIS2 deve dimostrare di saper governare il rischio cyber in modo sistemico, integrando misure tecniche, processi decisionali, responsabilità direzionali, contratti con i fornitori, continuità operativa e capacità di risposta agli incidenti.
Tuttavia, anche la NIS2 presenta un punto di dipendenza tecnologica. Gli obblighi di gestione del rischio, per quanto avanzati, devono essere applicati a sistemi, prodotti, applicazioni, dispositivi e componenti software che l’organizzazione spesso non produce direttamente. Una società soggetta alla NIS2 può essere tenuta a garantire la sicurezza dei propri sistemi informativi, ma tali sistemi sono composti da una pluralità di prodotti con elementi digitali acquistati, integrati, configurati o ricevuti da terzi. Il rischio cyber dell’organizzazione è dunque influenzato in modo decisivo dalla sicurezza dei prodotti immessi sul mercato e dalla capacità dei relativi fabbricanti di gestire vulnerabilità, aggiornamenti e documentazione.
Il Cyber Resilience Act interviene precisamente su questo livello. Esso non disciplina l’organizzazione utilizzatrice in quanto tale, come fa la NIS2, ma i prodotti con elementi digitali che entrano nell’ecosistema tecnologico delle organizzazioni. La sua funzione è complementare: rendere il mercato dei prodotti digitali più sicuro, affinché gli operatori soggetti alla NIS2 possano costruire la propria resilienza su componenti progettati, sviluppati e mantenuti secondo requisiti minimi di cybersicurezza.
Da tale angolo visuale, il CRA rappresenta una misura di sicurezza della supply chain su scala europea. La NIS2 chiede agli operatori di governare i rischi derivanti dai propri fornitori e dalla qualità dei prodotti e servizi acquistati; il CRA impone ai fabbricanti di prodotti con elementi digitali obblighi che riducono, almeno in linea di principio, l’insicurezza strutturale della catena di fornitura. La combinazione tra le due normative mostra il passaggio da una cybersecurity centrata sull’utilizzatore a una cybersecurity distribuita lungo l’intero ciclo economico della tecnologia.
Il Cyber Resilience Act come sicurezza by design del mercato digitale
Il Cyber Resilience Act introduce una disciplina orizzontale dei prodotti con elementi digitali messi a disposizione sul mercato europeo. La nozione di prodotto con elementi digitali è ampia e comprende prodotti software o hardware e le relative soluzioni di trattamento remoto dei dati, nella misura in cui siano essenziali al funzionamento del prodotto. L’ambizione del regolamento è superare la frammentazione degli obblighi di sicurezza applicabili ai prodotti digitali, stabilendo requisiti comuni che accompagnino il prodotto lungo tutto il suo ciclo di vita.
Il principio di fondo è semplice, ma dirompente: i prodotti digitali non devono essere immessi sul mercato europeo con vulnerabilità note sfruttabili, con configurazioni insicure, con meccanismi insufficienti di protezione dei dati e dei sistemi, o senza un adeguato processo di gestione delle vulnerabilità. La cybersecurity diventa una caratteristica regolatoria del prodotto, non un elemento opzionale rimesso alla maturità del singolo produttore o alla capacità contrattuale dell’acquirente.
Il CRA impone ai fabbricanti obblighi che riguardano la progettazione, lo sviluppo, la produzione, la valutazione della conformità, la documentazione tecnica, la gestione delle vulnerabilità, gli aggiornamenti di sicurezza e la comunicazione agli utenti. L’Allegato I del regolamento contiene i requisiti essenziali di cybersicurezza, distinguendo tra requisiti relativi alle proprietà dei prodotti con elementi digitali e requisiti relativi ai processi di gestione delle vulnerabilità. Tale struttura è particolarmente rilevante, poiché mostra come il legislatore europeo non si limiti a chiedere che il prodotto sia sicuro al momento dell’immissione sul mercato, ma pretenda che esista un processo idoneo a mantenerne la sicurezza nel tempo.
La sicurezza non è più una fotografia statica, ma una condizione dinamica. Un prodotto digitale può essere sicuro al momento della commercializzazione e diventare vulnerabile a distanza di pochi mesi a seguito della scoperta di nuove tecniche di attacco, della pubblicazione di exploit, dell’evoluzione delle dipendenze software o dell’emersione di vulnerabilità nella supply chain. Per tale ragione il CRA attribuisce rilievo alla gestione del ciclo di vita, alla disponibilità degli aggiornamenti, alla comunicazione delle informazioni di sicurezza e alla gestione delle vulnerabilità attivamente sfruttate.
Questa impostazione determina una trasformazione significativa anche per gli utilizzatori professionali. Le organizzazioni non potranno più limitarsi a chiedere genericamente ai fornitori che i prodotti siano “sicuri”, né potranno considerare la sicurezza del prodotto come un mero tema tecnico da valutare in fase di configurazione. La conformità al CRA diventerà progressivamente un parametro di selezione, qualificazione e controllo dei fornitori. Nei processi di procurement, vendor management, gestione degli asset, risk assessment e due diligence, la domanda non sarà più soltanto se un prodotto sia funzionalmente adeguato, ma se sia stato progettato, documentato e mantenuto secondo i requisiti di ciberresilienza previsti dal regolamento.
Tre livelli della medesima sicurezza: prodotto, trattamento, organizzazione
Il rapporto tra CRA, GDPR e NIS2 può essere rappresentato come una sequenza logica composta da tre livelli. Il primo livello è il prodotto digitale, ossia il software, il dispositivo, il componente hardware o la soluzione connessa immessa sul mercato. Il secondo livello è il trattamento, ossia l’insieme delle operazioni compiute sui dati personali attraverso quel prodotto o mediante sistemi che lo incorporano. Il terzo livello è l’organizzazione, ossia il soggetto che utilizza prodotti e trattamenti per erogare servizi, svolgere attività economiche o garantire funzioni essenziali e importanti.
Il Cyber Resilience Act disciplina il primo livello, imponendo che il prodotto sia concepito e mantenuto secondo requisiti di cybersicurezza. Il GDPR disciplina il secondo livello, imponendo che il trattamento dei dati personali sia progettato e gestito secondo principi di liceità, correttezza, trasparenza, minimizzazione, integrità, riservatezza e accountability. La NIS2 disciplina il terzo livello, imponendo che l’organizzazione sia in grado di governare il rischio cyber e garantire la continuità e sicurezza dei servizi rilevanti.
La distinzione è concettualmente utile, ma nella pratica i tre livelli sono inseparabili. Un prodotto insicuro può generare una violazione dei dati personali ai sensi del GDPR e, al tempo stesso, un incidente rilevante ai fini della NIS2. Un’organizzazione soggetta alla NIS2 che utilizzi prodotti digitali vulnerabili potrebbe non essere in grado di dimostrare l’adeguatezza delle proprie misure di gestione del rischio, soprattutto se non ha valutato la sicurezza del prodotto nella fase di acquisizione e manutenzione. Un titolare del trattamento che adotti software privo di adeguate garanzie di aggiornamento o gestione delle vulnerabilità potrebbe trovarsi in difficoltà nel dimostrare la conformità agli articoli 25 e 32 del GDPR.
La sicurezza digitale, dunque, non può più essere analizzata attraverso compartimenti stagni. Il prodotto non è separabile dal trattamento che abilita; il trattamento non è separabile dall’organizzazione che lo governa; l’organizzazione non è separabile dalla supply chain tecnologica su cui fonda le proprie attività. CRA, GDPR e NIS2 danno forma normativa a questa interdipendenza.
La conseguenza più importante è il superamento della distinzione tradizionale tra sicurezza tecnica e compliance giuridica. Nel nuovo assetto europeo, la sicurezza del prodotto è un requisito giuridico, la sicurezza del trattamento è un obbligo organizzativo e la resilienza dell’organizzazione dipende dalla qualità tecnica e contrattuale dei prodotti e dei fornitori. La compliance non consiste più nella produzione di documentazione separata per ciascuna normativa, ma nella capacità di costruire un sistema integrato di governo della sicurezza digitale.
Il CRA come rafforzamento operativo dell’articolo 32 GDPR
Una delle interazioni più rilevanti tra CRA e GDPR riguarda l’articolo 32 del Regolamento (UE) 2016/679. Tale disposizione impone di adottare misure tecniche e organizzative adeguate al rischio, includendo, ove opportuno, la pseudonimizzazione e la cifratura dei dati personali, la capacità di assicurare su base permanente riservatezza, integrità, disponibilità e resilienza dei sistemi e dei servizi di trattamento, la capacità di ripristinare tempestivamente la disponibilità e l’accesso ai dati personali in caso di incidente fisico o tecnico, nonché una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure adottate.
Il CRA non modifica l’articolo 32, ma ne rafforza il presupposto tecnologico. Quando il trattamento di dati personali si fonda su prodotti con elementi digitali conformi ai requisiti del CRA, il titolare dispone di un ambiente tecnologico più coerente con le esigenze di sicurezza previste dal GDPR. Ciò non significa che l’utilizzo di un prodotto conforme al CRA sia di per sé sufficiente a dimostrare la conformità al GDPR, poiché la sicurezza del trattamento dipende anche dal contesto, dalla configurazione, dalle finalità, dalle categorie di dati, dagli accessi, dai processi organizzativi e dai rischi specifici per gli interessati. Tuttavia, sarebbe difficile negare che la conformità del prodotto ai requisiti di ciberresilienza rappresenti un elemento rilevante nella valutazione dell’adeguatezza delle misure tecniche.
In questa prospettiva, il CRA potrà incidere sulle DPIA, sulle valutazioni ex articolo 32, sui processi di vendor assessment e sulle istruzioni impartite ai responsabili del trattamento. Quando un’organizzazione seleziona un software destinato a trattare dati personali, la verifica della conformità del prodotto ai requisiti del CRA potrà diventare un elemento della valutazione preventiva del rischio. Analogamente, nei contratti con i responsabili del trattamento, la conformità dei prodotti utilizzati, la gestione degli aggiornamenti, la comunicazione delle vulnerabilità, la disponibilità di documentazione tecnica e la tempestività nella remediation potranno assumere una rilevanza crescente.
Il punto non è trasformare ogni valutazione GDPR in una verifica di conformità al CRA, bensì riconoscere che la sicurezza del trattamento non può prescindere dalla sicurezza del prodotto. Il titolare resta responsabile della valutazione del rischio e dell’adozione di misure adeguate, ma tale responsabilità dovrà confrontarsi sempre più spesso con un mercato nel quale la sicurezza dei prodotti digitali sarà regolata in modo specifico e documentabile. La domanda “il software è sicuro?” non potrà più ricevere risposte generiche; dovrà essere collegata a requisiti, evidenze, processi di aggiornamento e obblighi di gestione delle vulnerabilità.
Il CRA come tassello della supply chain NIS2
L’interazione con la NIS2 è ancora più evidente sul terreno della supply chain. L’articolo 21 della direttiva attribuisce espressamente rilievo alla sicurezza della catena di approvvigionamento, includendo gli aspetti di sicurezza relativi ai rapporti tra ciascun soggetto e i suoi fornitori o prestatori di servizi. Si tratta di una delle innovazioni più significative della NIS2 rispetto alla precedente direttiva, poiché riconosce che il rischio cyber non si arresta ai confini giuridici dell’organizzazione, ma si propaga attraverso fornitori, prodotti, piattaforme, servizi cloud, software di terze parti e dipendenze tecnologiche.
Il CRA offre una risposta complementare a tale problema. Se la NIS2 impone agli operatori di valutare e governare il rischio derivante dalla propria supply chain, il CRA interviene su una parte essenziale di quella supply chain: i prodotti con elementi digitali. Ciò significa che, nel tempo, gli operatori soggetti alla NIS2 potranno integrare nei propri processi di procurement e gestione dei fornitori parametri direttamente connessi alla conformità dei prodotti al CRA. La marcatura, la documentazione tecnica, le dichiarazioni di conformità, le informazioni sugli aggiornamenti di sicurezza e le procedure di gestione delle vulnerabilità potranno diventare strumenti di due diligence e di controllo.
Il D.Lgs. 138/2024, nel recepire la NIS2 in Italia, rafforza ulteriormente questa prospettiva, poiché colloca gli obblighi di cybersicurezza all’interno di un sistema che richiede ai soggetti essenziali e importanti di identificare, classificare e governare i propri servizi, le proprie attività e i relativi rischi. In tale quadro, la scelta dei prodotti digitali non è più un atto meramente tecnico o commerciale, ma una componente del sistema di gestione del rischio. L’acquisto di un software vulnerabile, la mancata verifica degli aggiornamenti, l’assenza di clausole contrattuali sulla gestione delle vulnerabilità o l’utilizzo di componenti non supportati possono incidere direttamente sulla capacità dell’organizzazione di dimostrare l’adeguatezza delle proprie misure NIS2.
Il CRA consente dunque di spostare parte della responsabilità di sicurezza verso chi immette prodotti digitali nel mercato, ma non libera gli operatori NIS2 dall’obbligo di governare le proprie scelte tecnologiche. Al contrario, rende più esigente il processo di valutazione. Un soggetto essenziale o importante non potrà limitarsi a invocare la conformità formale del prodotto, ma dovrà verificare se quel prodotto sia adeguato al proprio contesto operativo, se sia correttamente configurato, se venga aggiornato, se le vulnerabilità siano gestite tempestivamente e se l’integrazione con gli altri sistemi non introduca rischi ulteriori.
Incident reporting: tre prospettive sul medesimo evento
Un ulteriore punto di convergenza riguarda la gestione e la notifica degli incidenti. GDPR, NIS2 e CRA prevedono obblighi di comunicazione che rispondono a finalità diverse, ma possono essere attivati dal medesimo evento di sicurezza.
Nel GDPR, la notifica del data breach è collegata alla violazione dei dati personali. L’articolo 33 impone al titolare di notificare la violazione all’autorità di controllo competente senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza, salvo che sia improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone fisiche. L’articolo 34 disciplina invece la comunicazione agli interessati quando la violazione è suscettibile di presentare un rischio elevato.
Nella NIS2, la notifica riguarda gli incidenti significativi che impattano sulla prestazione dei servizi dei soggetti essenziali e importanti. La logica non è centrata sulla persona fisica, ma sulla continuità, sulla sicurezza dei servizi e sugli effetti sistemici dell’incidente. Il D.Lgs. 138/2024 recepisce questa impostazione nel sistema italiano, raccordando gli obblighi di notifica al ruolo dell’Agenzia per la Cybersicurezza Nazionale e alle procedure previste per i soggetti rientranti nel perimetro.
Nel CRA, gli obblighi di reporting riguardano, in particolare, le vulnerabilità attivamente sfruttate e gli incidenti gravi che hanno un impatto sulla sicurezza dei prodotti con elementi digitali. La prospettiva è ancora diversa: non si guarda primariamente al trattamento dei dati personali, né alla continuità del servizio dell’organizzazione utilizzatrice, ma alla sicurezza del prodotto e alla necessità di informare le autorità competenti rispetto a vulnerabilità o incidenti che possono incidere sul mercato e sugli utilizzatori.
Il medesimo evento può quindi assumere tre qualificazioni giuridiche diverse. Una vulnerabilità attivamente sfruttata in un software utilizzato da un ospedale, da un fornitore di servizi cloud o da un’impresa energetica potrebbe costituire un evento rilevante ai fini del CRA per il fabbricante, un incidente significativo ai fini NIS2 per l’organizzazione utilizzatrice e una violazione dei dati personali ai fini GDPR qualora siano compromessi dati personali. La gestione dell’incidente non può quindi essere frammentata in silos regolatori. Occorre un modello integrato che consenta di qualificare l’evento, identificare i soggetti obbligati, rispettare le tempistiche applicabili, coordinare le comunicazioni e mantenere coerenza tra le informazioni trasmesse alle diverse autorità.
Questo aspetto sarà particolarmente delicato nella prassi. Le organizzazioni dovranno costruire procedure di incident response capaci di distinguere le diverse dimensioni dell’evento senza duplicazioni incoerenti. La funzione legale, la funzione privacy, la funzione cybersecurity, il procurement, il vendor management e il top management dovranno operare all’interno di un processo unitario, poiché la stessa vulnerabilità può generare obblighi su piani normativi differenti. In mancanza di tale coordinamento, il rischio non è soltanto quello di omettere una notifica, ma di produrre comunicazioni disallineate, incomplete o contraddittorie.
Sicurezza by design, privacy by design e resilience by design
Il rapporto tra CRA, GDPR e NIS2 può essere letto anche attraverso tre formule ormai centrali nel lessico regolatorio europeo: security by design, privacy by design e resilience by design. Il GDPR ha reso esplicita la protezione dei dati fin dalla progettazione e per impostazione predefinita; il CRA porta questa logica nel mondo dei prodotti con elementi digitali, imponendo che la sicurezza sia incorporata nella progettazione e nel ciclo di vita del prodotto; la NIS2, pur non utilizzando necessariamente la medesima formula, impone alle organizzazioni un approccio strutturale alla resilienza, nel quale la sicurezza deve essere integrata nei processi decisionali, nella governance, nella continuità operativa e nella gestione della supply chain.
Queste tre prospettive non dovrebbero essere considerate autonome. La privacy by design non è effettiva se i prodotti digitali utilizzati sono progettati senza adeguate misure di sicurezza. La security by design del prodotto non garantisce, da sola, la conformità al GDPR se il trattamento è eccessivo, non trasparente o privo di una base giuridica adeguata. La resilience by design dell’organizzazione non può realizzarsi se la supply chain tecnologica è composta da prodotti non aggiornati, non documentati o privi di processi di vulnerability management.
La vera sfida per le imprese consisterà quindi nel tradurre queste tre logiche in un unico modello operativo. Nei processi di sviluppo software, ciò significa integrare requisiti CRA, principi GDPR e requisiti NIS2 sin dalla fase di analisi. Nei processi di acquisto, significa valutare non soltanto prezzo e funzionalità, ma sicurezza del prodotto, impatti privacy, criticità del servizio e dipendenze operative. Nei processi di gestione degli asset, significa mantenere un inventario capace di collegare prodotti digitali, trattamenti di dati personali, servizi NIS2, fornitori e vulnerabilità. Nei processi di audit, significa verificare la coerenza tra documentazione tecnica, misure di sicurezza, contratti, procedure di incident response e accountability.
In assenza di tale integrazione, il rischio è la moltiplicazione di compliance parallele. Un registro dei trattamenti GDPR separato dall’inventario degli asset, una valutazione NIS2 separata dalla gestione dei fornitori, una verifica CRA separata dal procurement e una procedura di incident response separata dalla gestione dei data breach produrrebbero un modello inefficiente e fragile. La direzione verso cui si muove il diritto europeo è invece quella di una sicurezza digitale unitaria, nella quale le diverse normative conservano finalità autonome ma vengono attuate attraverso processi coordinati.
Il ruolo dei fabbricanti, degli importatori e dei distributori
Un ulteriore profilo innovativo del Cyber Resilience Act riguarda la distribuzione degli obblighi lungo la catena economica del prodotto. Il regolamento non si limita a disciplinare l’utilizzatore finale o l’organizzazione che incorpora il prodotto nei propri sistemi, ma attribuisce specifiche responsabilità a fabbricanti, importatori e distributori. Questa impostazione è coerente con la logica del mercato interno europeo e con la tradizione normativa applicabile ai prodotti, ma assume un significato particolare nel campo della cybersecurity.
Il fabbricante è il soggetto chiamato a garantire che il prodotto sia progettato, sviluppato e prodotto conformemente ai requisiti essenziali di cybersicurezza, a svolgere o far svolgere la valutazione della conformità, a predisporre la documentazione tecnica, a fornire informazioni agli utenti e a gestire le vulnerabilità. L’importatore e il distributore svolgono ruoli differenti, ma comunque rilevanti nel garantire che i prodotti messi a disposizione sul mercato rispettino il quadro regolatorio applicabile.
La conseguenza sistemica è rilevante: la sicurezza non viene più concentrata esclusivamente sull’organizzazione utilizzatrice, ma distribuita tra gli operatori economici che contribuiscono alla circolazione del prodotto. Ciò produce un effetto di riequilibrio rispetto al passato, quando molte organizzazioni utilizzatrici si trovavano a dover compensare, tramite configurazioni, controlli compensativi e clausole contrattuali, carenze di sicurezza radicate nella progettazione del prodotto.
Naturalmente, ciò non significa che la responsabilità dell’utilizzatore venga meno. Un prodotto conforme può essere configurato male, integrato in modo improprio, non aggiornato o utilizzato in un contesto più critico di quello originariamente previsto. Tuttavia, il CRA introduce una base comune di aspettative, destinata a influenzare anche i rapporti contrattuali. Le imprese acquirenti potranno chiedere garanzie più puntuali; i fornitori dovranno produrre evidenze più strutturate; le clausole sulla sicurezza non potranno limitarsi a formule generiche; le responsabilità in caso di vulnerabilità, incidenti, ritardi negli aggiornamenti o mancata comunicazione dovranno essere disciplinate con maggiore precisione.
Le ricadute sui contratti ICT
Il sistema integrato CRA-GDPR-NIS2 avrà effetti profondi sulla contrattualistica ICT. I contratti per l’acquisto, la licenza, lo sviluppo, la manutenzione o l’integrazione di prodotti digitali dovranno progressivamente incorporare obblighi più specifici in materia di sicurezza del prodotto, protezione dei dati personali, resilienza operativa e gestione degli incidenti. Non sarà più sufficiente prevedere che il fornitore “adotti misure di sicurezza adeguate” o “rispetti la normativa applicabile”. Occorrerà declinare tali obblighi in modo coerente con la funzione del prodotto, la criticità del servizio, la presenza di dati personali, l’eventuale rilevanza NIS2 dell’organizzazione utilizzatrice e il ruolo del fornitore nella catena del valore.
Nei contratti rilevanti ai fini GDPR, sarà necessario coordinare le istruzioni al responsabile del trattamento con gli obblighi di sicurezza del prodotto, soprattutto quando il fornitore mette a disposizione software, piattaforme o dispositivi attraverso cui vengono trattati dati personali. Nei contratti rilevanti ai fini NIS2, dovranno essere disciplinati gli obblighi di cooperazione in caso di incidente, le tempistiche di comunicazione, la gestione delle vulnerabilità, la continuità del servizio, l’accesso alle evidenze, gli audit, la subcontracting chain e le misure di exit. Nei contratti relativi a prodotti con elementi digitali, assumeranno rilievo le dichiarazioni di conformità, la documentazione tecnica, gli aggiornamenti di sicurezza, la durata del supporto, la comunicazione delle vulnerabilità e le responsabilità in caso di mancato rispetto degli obblighi del CRA.
La contrattualistica diventerà quindi il luogo nel quale le tre normative si incontrano operativamente. Il GDPR richiederà garanzie sul trattamento; la NIS2 richiederà garanzie sulla resilienza e sulla supply chain; il CRA richiederà garanzie sul prodotto e sul ciclo di vita della sicurezza. La capacità di integrare tali dimensioni in un unico modello contrattuale sarà uno degli elementi decisivi della futura governance digitale delle imprese.
L’impatto sulla governance aziendale
L’integrazione tra CRA, GDPR e NIS2 incide anche sulla governance aziendale. Per molto tempo la sicurezza informatica è stata considerata un tema prevalentemente tecnico, affidato alle funzioni IT o security. Il GDPR ha contribuito a spostare il tema verso la compliance e la protezione dei diritti fondamentali; la NIS2 ha ulteriormente rafforzato il ruolo degli organi di gestione, imponendo una responsabilità direzionale sulla gestione del rischio cyber; il CRA aggiunge una dimensione ulteriore, coinvolgendo funzioni di prodotto, ricerca e sviluppo, procurement, legale, qualità, compliance, marketing e post-vendita.
Per i fabbricanti di prodotti digitali, la cybersicurezza diventa parte integrante del processo di product governance. Non può essere confinata al momento del test finale o alla gestione emergenziale delle vulnerabilità. Deve essere incorporata nelle decisioni di progettazione, nella scelta delle componenti, nella gestione delle dipendenze open source, nella documentazione tecnica, nella valutazione della conformità, nelle procedure di aggiornamento e nella comunicazione agli utenti. Per gli utilizzatori professionali, invece, la sicurezza del prodotto diventa parte della governance degli asset e della supply chain, con impatti sui processi di selezione, approvazione, monitoraggio e dismissione delle tecnologie.
La governance integrata richiederà quindi ruoli e responsabilità più chiari. Il DPO non potrà farsi carico della sicurezza del prodotto in quanto tale, ma dovrà essere coinvolto quando il prodotto incide sui trattamenti di dati personali. Il CISO dovrà presidiare la coerenza tecnica delle misure e la gestione del rischio cyber, ma dovrà interagire con procurement, legal e business owner. Il responsabile compliance dovrà assicurare il raccordo tra normative diverse. Gli organi amministrativi dovranno comprendere che la sicurezza digitale non è più un tema di mera protezione tecnica, ma un requisito di continuità, conformità, responsabilità e accesso al mercato.
Dalla compliance documentale alla prova dell’effettività
Uno degli effetti più rilevanti del sistema CRA-GDPR-NIS2 sarà il progressivo superamento della compliance meramente documentale. Le tre normative, seppur con strumenti diversi, richiedono tutte la capacità di dimostrare l’effettività delle misure adottate. Nel GDPR, l’accountability impone di documentare e comprovare la conformità. Nella NIS2, la gestione del rischio cyber richiede misure effettive, proporzionate e soggette a valutazione. Nel CRA, la conformità del prodotto deve essere sostenuta da documentazione tecnica, valutazione della conformità e processi di gestione delle vulnerabilità.
La sicurezza digitale diventa così un oggetto probatorio. Non basta affermare che un prodotto è sicuro, che un trattamento è protetto o che un’organizzazione è resiliente. Occorre poterlo dimostrare attraverso evidenze coerenti: analisi dei rischi, scelte architetturali, test, procedure, registri, audit, contratti, vulnerability management, incident report, piani di continuità, valutazioni dei fornitori, istruzioni operative e decisioni degli organi di gestione.
Questa dimensione probatoria è particolarmente importante perché il rischio cyber evolve continuamente. Una misura adeguata oggi può diventare insufficiente domani; un prodotto sicuro può diventare vulnerabile; una configurazione corretta può essere alterata; un fornitore affidabile può subire una compromissione; una libreria software può rivelare una vulnerabilità critica. La conformità deve quindi essere intesa come processo dinamico, non come stato acquisito una volta per tutte.
Conclusioni: la sicurezza digitale come sistema
Il Cyber Resilience Act, il GDPR e la NIS2 segnano tre passaggi complementari dell’evoluzione europea della sicurezza digitale. Il GDPR ha introdotto il principio secondo cui la protezione dei dati personali richiede misure tecniche e organizzative adeguate al rischio e incorporate sin dalla progettazione del trattamento. La NIS2 ha esteso la prospettiva alla resilienza delle organizzazioni e dei servizi rilevanti, attribuendo centralità alla governance, alla supply chain, alla continuità operativa e alla responsabilità degli organi amministrativi. Il Cyber Resilience Act completa il quadro intervenendo sui prodotti con elementi digitali, ossia sulle componenti tecnologiche che rendono possibili i trattamenti, i servizi e le infrastrutture dell’economia digitale.
La relazione tra le tre normative non deve essere letta come una sovrapposizione, ma come una stratificazione funzionale. Il prodotto deve essere sicuro perché diventerà parte di sistemi e servizi; il trattamento deve essere sicuro perché incide sui diritti e sulle libertà delle persone fisiche; l’organizzazione deve essere resiliente perché la sua compromissione può produrre effetti economici, sociali e sistemici. Prodotto, trattamento e organizzazione costituiscono tre dimensioni della medesima realtà digitale.
La conseguenza è che la cybersecurity europea non può più essere governata attraverso modelli separati. Le imprese dovranno costruire sistemi integrati nei quali product security, data protection, supply chain security, incident response, business continuity, vulnerability management e governance del rischio siano parte di un unico processo decisionale. In tale contesto, il CRA non rappresenta soltanto una nuova normativa da applicare ai prodotti digitali, ma il tassello che consente di collegare la sicurezza del mercato tecnologico alla sicurezza dei trattamenti e alla resilienza delle organizzazioni.
La vera innovazione del Cyber Resilience Act consiste dunque nel portare la cybersecurity nel luogo in cui il rischio nasce: il prodotto. Il GDPR la colloca nel trattamento, la NIS2 nell’organizzazione, il CRA nella progettazione e nel ciclo di vita della tecnologia. Letti insieme, questi tre strumenti delineano un sistema europeo nel quale la sicurezza digitale non è più un obbligo accessorio, ma una qualità strutturale dei prodotti, dei processi e delle organizzazioni. È questo il passaggio decisivo: la cybersecurity cessa di essere una reazione all’incidente e diventa una condizione regolatoria di accesso, permanenza e affidabilità nel mercato unico digitale.
