Per anni il procurement software è stato governato da una logica prevalentemente funzionale: performance, costi, interoperabilità, livello di servizio. La sicurezza, salvo nei contesti più maturi, è rimasta spesso confinata a check di secondo livello, demandati al CISO o a valutazioni successive all’acquisto.
Il Cyber Resilience Act ribalta questo schema. E lo fa con una discontinuità che molti stanno ancora sottovalutando.
Il regolamento europeo introduce, infatti, un principio destinato a incidere profondamente sulle supply chain digitali: la cyber security non è più solo una caratteristica auspicabile del prodotto, ma un requisito di conformità. E il marchio CE, storicamente associato alla sicurezza fisica dei prodotti, si estende al dominio digitale diventando un indicatore – non simbolico, ma regolatorio – della conformità cyber.
Questo cambia radicalmente anche il procurement. Perché acquistare software, piattaforme SaaS, componenti open source integrati in prodotti commerciali o dispositivi connessi non sarà più solo una scelta tecnica o economica, ma anche un atto di gestione del rischio normativo e operativo.
Per le aziende significa ripensare a processi, capitolati, contratti, ruoli e controlli non più solo come un semplice adempimento, ma come una vera e propria trasformazione strutturale.
Indice degli argomenti
Cosa prevede il Cyber Resilience Act e come introduce il marchio CE per i prodotti digitali
Il Cyber Resilience Act (Regolamento UE 2024/2847) è entrato in vigore il 10 dicembre 2024 ed è destinato a diventare, entro il 2027, uno dei pilastri della regolamentazione europea in materia di sicurezza informatica.
Per la prima volta nella storia normativa dell’Unione, il legislatore introduce l’obbligo di marcatura CE per i prodotti con elementi digitali: non più solo per lavatrice o un giocattolo, ma per qualsiasi dispositivo connesso, componente software e sistema IoT immesso sul mercato europeo.
Il principio ispiratore è chiaro: la sicurezza non può essere un’opzione, né un accessorio aggiunto a posteriori. Il Cyber Resilience Act impone che i prodotti digitali vengano progettati secondo il principio del security by design e del security by default, con obblighi precisi per produttori, importatori e distributori lungo tutta la catena di fornitura.
Per le aziende che acquistano software, e quindi per chi si occupa di procurement IT, questo cambia radicalmente le regole del gioco.
Ambito applicativo del regolamento: software, dispositivi e componenti digitali
Il Cyber Resilience Act si applica a un perimetro molto ampio: tutti i prodotti con elementi digitali immessi sul mercato dell’UE che hanno una connessione a una rete o a un altro dispositivo.
Rientrano nell’ambito router, firewall, switch, telecamere IP, sistemi operativi, applicativi software, PLC industriali, dispositivi medici connessi, sistemi di building automation e molto altro.
La norma esclude esplicitamente il software open source non commerciale (con alcune sfumature rilevanti), i servizi cloud non integrati con un prodotto hardware, e i settori già coperti da normative verticali specifiche come il Regolamento MDR per i dispositivi medici.
Ai fini della compliance, il regolamento distingue tre categorie di prodotti: prodotti standard (la maggioranza, soggetti ad autovalutazione), prodotti critici di classe I (ad esempio, sistemi di gestione delle identità, browser e password manager soggetti a standard armonizzati o audit di terza parte) e prodotti critici di classe II (sistemi operativi, hypervisor, firewall industriali e PKI, obbligatoriamente soggetti a certificazione da parte di organismi notificati).
Per il procurement aziendale, capire in quale categoria ricade il software acquistato è il primo passo operativo indispensabile.
Requisiti essenziali di cyber security nei prodotti con marcatura CE
L’Allegato I del CRA elenca i requisiti essenziali che i prodotti digitali devono soddisfare per ottenere la marcatura CE.
Sul piano tecnico, i produttori devono garantire che il prodotto:
- sia privo di vulnerabilità note al momento dell’immissione sul mercato;
- che implementi configurazioni sicure per default;
- che limiti la superficie di attacco;
- che garantisca integrità dei dati e autenticazione robusta;
- che protegga i dati in transito e a riposo;
- che limiti i privilegi al minimo necessario (least privilege).
Sul piano del ciclo di vita, il Cyber Resilience Act introduce obblighi altrettanto stringenti: i produttori devono garantire aggiornamenti di sicurezza per tutta la durata del supporto dichiarata (con un minimo di cinque anni), devono segnalare all’ENISA le vulnerabilità attivamente sfruttate entro 24 ore dalla scoperta, e devono gestire un processo strutturato di vulnerability disclosure.
La disponibilità di una Software Bill of Materials (SBOM) completa e aggiornata è requisito esplicito.
Questi obblighi si traducono, per chi acquista software, in criteri di valutazione che vanno ben oltre le tradizionali specifiche funzionali.
Come il Cyber Resilience Act trasforma la selezione e il procurement del software in azienda
Il Cyber Resilience Act non è una norma che riguarda solo i produttori di software. Sebbene gli obblighi formali di conformità gravino principalmente su chi produce e immette il prodotto sul mercato, chi acquista software – sia nella pubblica amministrazione sia nel settore privato – è chiamato ad assumersi responsabilità dirette nel verificare che i prodotti acquisiti soddisfino i requisiti regolamentari.
In termini pratici, questo significa che il procurement IT deve evolvere: da semplice funzione di acquisto a presidio attivo di conformità normativa e gestione del rischio cyber.
Le organizzazioni che non si adeguano per tempo rischiano di trovarsi con un portafoglio software non conforme, di incorrere in sanzioni per aver immesso in uso prodotti non certificati (in alcuni contesti specifici), o semplicemente di subire i danni reputazionali e operativi derivanti dall’uso di prodotti privi delle garanzie di sicurezza richieste dal legislatore europeo.
Requisiti di conformità CE come criterio di selezione nelle gare acquisti
Il primo cambiamento concreto riguarda i criteri di valutazione nelle gare di acquisto. A partire dall’11 dicembre 2027, data di applicazione piena del CRA, la presenza della marcatura CE per i prodotti digitali soggetti al regolamento deve diventare un requisito minimo e non un semplice criterio premiante nelle procedure di selezione dei fornitori software.
In fase transitoria (2025-2027), è già opportuno introdurre nei capitolati tecnici la richiesta esplicita di documentazione sulla roadmap di conformità al CRA, della dichiarazione di conformità EU (DoC) e del fascicolo tecnico.
Nelle gare più strutturate, è utile articolare la valutazione su più livelli:
- verifica della categoria CRA applicabile al prodotto (standard, classe I o classe II);
- accertamento del percorso di valutazione della conformità adottato (autovalutazione, standard armonizzati, audit di terza parte o certificazione da organismo notificato);
- analisi della politica di vulnerability disclosure del fornitore;
- verifica della durata del supporto dichiarata in rapporto alla vita attesa del contratto.
Per i software critici, è raccomandabile richiedere la certificazione sotto il framework EUCC (European Cybersecurity Certification Scheme for Common Criteria), laddove disponibile e applicabile.
Software Bill of Materials (SBOM) e requisiti di trasparenza per i fornitori software
Uno degli elementi più innovativi introdotti dal CRA – e al tempo stesso uno dei più praticamente rilevanti per il procurement – è l’obbligo di Software Bill of Materials.
La SBOM è essenzialmente un inventario strutturato di tutti i componenti software inclusi in un prodotto: librerie di terze parti, dipendenze, componenti open source, versioni e relative licenze. Formati standard come SPDX o CycloneDX ne consentono la gestione automatizzata e l’integrazione nei processi di vulnerability management.
Per chi acquista software, la SBOM diventa uno strumento di trasparenza e controllo senza precedenti.
Consente di sapere esattamente cosa si sta acquistando, incluse le dipendenze nascoste che spesso sono all’origine delle vulnerabilità più gravi (basti pensare all’impatto di Log4Shell).
Nei processi di procurement, è oggi opportuno richiedere contrattualmente la fornitura di SBOM aggiornate ad ogni rilascio significativo, in formato machine-readable, con l’impegno del fornitore a notificare l’acquirente in caso di identificazione di vulnerabilità critiche nei componenti dichiarati.
Quali clausole inserire nei contratti di licenza software per garantire conformità al Cyber Resilience Act
La conformità al CRA non si garantisce in fase di selezione del fornitore: deve essere presidiata lungo tutta la durata contrattuale. I contratti di licenza software – spesso standardizzati e poco negoziati – vanno oggi revisionati in profondità per includere obblighi espliciti di conformità al CRA.
Questo vale in particolare per i contratti pluriennali, per gli accordi Enterprise e per i contratti che coprono software critici per la continuità operativa dell’organizzazione.
Non si tratta di aggiungere clausole boilerplate di stile: si tratta di definire con precisione obblighi, tempi, metriche e responsabilità. Di seguito le aree più critiche su cui intervenire.
Obblighi di aggiornamento e gestione delle vulnerabilità nei contratti
Il CRA impone ai produttori di garantire aggiornamenti di sicurezza per almeno cinque anni (o per la durata del supporto dichiarata, se superiore). Questa previsione normativa deve trovare riscontro esplicito nel contratto commerciale.
Le clausole da inserire devono coprire: l’impegno del fornitore a rilasciare patch critiche entro tempi definiti (ad esempio, entro 72 ore per vulnerabilità con CVSS score superiore a 9.0, entro 14 giorni per vulnerabilità di livello alto), l’obbligo di notifica proattiva all’acquirente in caso di vulnerabilità identificate nel prodotto – anche quando l’acquirente non ha ancora segnalato il problema – e la durata minima garantita del supporto di sicurezza.
È altresì opportuno includere clausole che disciplinino la gestione delle vulnerabilità zero-day: in questi casi, il fornitore deve impegnarsi a comunicare all’acquirente workaround o misure compensative nel minor tempo possibile, anche in assenza di patch disponibili.
Infine, il contratto dovrebbe prevedere l’obbligo per il fornitore di aggiornare la SBOM a ogni rilascio e di comunicare eventuali modifiche rilevanti nella supply chain del software (ad esempio, la sostituzione di un componente critico di terze parti).
Indicazioni sulle penalità e responsabilità per mancata conformità nei contratti
Il tema delle penalità e delle responsabilità è politicamente sensibile nella negoziazione con i fornitori, ma non può essere eluso. Il CRA prevede sanzioni amministrative pecuniarie fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo per i produttori non conformi.
Questo non si trasferisce automaticamente in responsabilità contrattuale verso l’acquirente, ma crea le basi per richiedere tutele specifiche.
Le clausole contrattuali dovrebbero prevedere:
- una dichiarazione esplicita del fornitore circa la conformità del prodotto al CRA (o, nella fase transitoria, circa il percorso di adeguamento in corso e la data prevista di conformità piena);
- l’obbligo di informare l’acquirente qualora il prodotto dovesse essere ritirato dal mercato per mancata conformità normativa;
- penali progressive in caso di mancato rispetto dei tempi di rilascio delle patch critiche;
- il diritto dell’acquirente di risolvere il contratto senza penali nel caso in cui il fornitore non consegua la conformità CRA entro la scadenza normativa.
In alcuni contesti, può essere utile prevedere clausole di indennizzo a favore dell’acquirente per i danni diretti derivanti da vulnerabilità non patchate in violazione degli SLA contrattuali.
Come organizzare ruoli e responsabilità interne per gestire il CRA nel processo di acquisto software
L’adeguamento al CRA non è una questione che può essere delegata al solo team legale o al solo team IT. Richiede un approccio interfunzionale che coinvolga procurement, sicurezza informatica, legal, compliance e – nei contesti più strutturati – il risk management.
La sfida organizzativa è quella di creare processi strutturati e ripetibili che non rallentino eccessivamente i tempi di acquisto, ma garantiscano al contempo il presidio dei requisiti normativi.
Integrazione dei criteri di conformità nei processi di vendor risk management
Il punto di partenza è l’integrazione dei criteri di conformità CRA nel framework di vendor risk management (VRM) già esistente o, dove non esiste, la sua creazione.
Il VRM deve essere arricchito con una sezione specifica dedicata alla valutazione della cybersecurity dei prodotti software, che comprenda:
un questionario strutturato da somministrare ai fornitori in fase di qualifica (con domande specifiche su politiche di vulnerability disclosure, processo di gestione delle patch, disponibilità di SBOM, percorso di certificazione CRA);
una procedura di onboarding che preveda la verifica documentale della dichiarazione di conformità EU o della roadmap di adeguamento;
una procedura di monitoraggio continuo durante la vita contrattuale.
È utile definire una matrice di criticità che classifichi i fornitori software su tre livelli (critico, rilevante, standard) in funzione del tipo di prodotto acquistato e del suo utilizzo nell’organizzazione.
Per i fornitori critici, il monitoraggio deve essere periodico (almeno annuale) e prevedere audit documentali o anche visite ispettive. Per i fornitori standard, può essere sufficiente un’autodichiarazione aggiornata ad ogni rinnovo contrattuale.
Formazione del personale procurement sulle regole di sicurezza digitali europee
Un aspetto spesso sottovalutato è la formazione del personale che si occupa di acquisti IT.
I buyer tradizionali sono abituati a valutare prodotti su base funzionale, economica e di affidabilità del fornitore: raramente hanno nel proprio bagaglio culturale gli strumenti per valutare la maturità di sicurezza di un software o interpretare una SBOM.
Questo gap deve essere colmato con programmi di upskilling mirati.
I contenuti formativi minimi per il personale procurement che gestisce acquisti di software e prodotti digitali dovrebbero includere: una panoramica del quadro normativo europeo in materia di cybersecurity (CRA, NIS2, DORA per i settori applicabili), i concetti fondamentali di sicurezza del software (vulnerability management, CVSS scoring, supply chain security), la lettura e interpretazione di una SBOM, i criteri di valutazione della conformità CRA e le differenze tra le categorie di prodotto, e le principali clausole contrattuali da negoziare.
Non è necessario formare esperti di sicurezza: è necessario formare procurement officer capaci di fare le domande giuste e di interpretare correttamente le risposte dei fornitori.
Roadmap per adeguare i processi di procurement software al Cyber Resilience Act entro il 2027
Con l’applicazione piena del CRA fissata all’11 dicembre 2027, e con il periodo di applicazione degli obblighi di segnalazione delle vulnerabilità già attivo dall’11 settembre 2026, il tempo per organizzarsi è meno di quanto sembri.
Una roadmap strutturata su tre orizzonti temporali consente di distribuire il carico di lavoro e di procedere con priorità chiare.
Audit delle licenze software in portafoglio rispetto ai requisiti CRA
Il primo passo – da avviare immediatamente – è un audit completo del portafoglio licenze software in uso nell’organizzazione. L’obiettivo è mappare ogni prodotto software rispetto all’ambito di applicazione del CRA: il prodotto è soggetto al regolamento? In quale categoria rientra? Il fornitore ha già avviato un percorso di conformità? Quali sono i gap rispetto ai requisiti essenziali?
Per ciascun prodotto classificato come soggetto al CRA, è opportuno raccogliere: la dichiarazione di conformità del fornitore (o la roadmap di adeguamento), la SBOM disponibile (o l’impegno alla fornitura), la politica di vulnerability disclosure, la durata dichiarata del supporto di sicurezza e la data di scadenza del contratto in essere.
Il risultato dell’audit è una matrice di rischio che permette di identificare le priorità di intervento: i prodotti critici senza roadmap di conformità credibile vanno affrontati immediatamente, valutando se avviare una rinegoziazione contrattuale o pianificare la sostituzione.
Timeline e scadenze normative da considerare (2026/2027)
La struttura temporale del CRA prevede una serie di scadenze progressive che le aziende devono tenere sotto controllo.
Il 10 dicembre 2024 ha segnato l’entrata in vigore del regolamento. L’11 settembre 2026 è la prima scadenza operativa critica: da questa data, i produttori sono obbligati a notificare le vulnerabilità attivamente sfruttate all’ENISA entro 24 ore dalla scoperta.
Questo significa che già da metà 2026 i contratti con i fornitori devono prevedere obblighi di notifica adeguati verso l’acquirente.
L’11 dicembre 2027 è la scadenza finale: da questa data, tutti i prodotti con elementi digitali immessi sul mercato europeo devono rispettare i requisiti del CRA e recare la marcatura CE.
I prodotti già sul mercato prima di questa data possono continuare a essere venduti fino all’esaurimento delle scorte, ma ogni nuovo rilascio o aggiornamento significativo del prodotto deve essere conforme.
Per il procurement, questo significa che tutti i contratti di acquisto software stipulati o rinnovati da fine 2027 in poi devono includere clausole di conformità CRA come requisito vincolante.
La roadmap pratica per un’organizzazione di medie dimensioni si articola così:
- nel primo semestre del 2026, aggiornare i template contrattuali e formare il personale procurement;
- nel secondo semestre del 2026, verificare la conformità dei fornitori critici rispetto agli obblighi di notifica delle vulnerabilità;
- nel 2027, completare la rinegoziazione o sostituzione dei contratti non conformi e implementare il monitoring continuo.
Chi parte oggi ha ancora il tempo per farlo con metodo. Chi rimanda rischia di trovarsi a rincorrere le scadenze in emergenza, che è esattamente il contrario di quello che il CRA vuole promuovere.
