Per decenni, il procurement IT è stato prevalentemente una funzione di ottimizzazione economica: negoziare le migliori condizioni contrattuali, consolidare i vendor per ottenere economie di scala, standardizzare le forniture per ridurre la complessità gestionale.
La sicurezza, quando veniva considerata, era spesso un requisito secondario o un capitolo da affrontare dopo la firma del contratto, delegato al team tecnico che avrebbe poi dovuto “mettere in sicurezza” ciò che il procurement aveva acquistato.
Indice degli argomenti
Il procurement IT è cambiato: dalla gestione dei costi alla gestione del rischio
Questo modello è strutturalmente inadeguato rispetto al panorama attuale.
Le organizzazioni che acquistano soluzioni IT senza integrare la sicurezza nel processo decisionale si trovano sistematicamente ad affrontare tre categorie di problemi:
- costi di remediation elevati (modificare un sistema per renderlo sicuro dopo il deployment costa in media sei volte di più che progettarlo sicuro fin dall’inizio);
- esposizione a rischi normativi (NIS2, DORA e GDPR impongono requisiti che devono essere garantiti anche attraverso i vendor);
- difficoltà di sostituzione (un fornitore con scarsa postura di sicurezza ma profondamente integrato nei sistemi aziendali è difficile e costoso da sostituire).
L’evoluzione in atto, accelerata dalla pressione normativa e dalla crescita degli attacchi alla supply chain, sta ridefinendo il ruolo del procurement IT come funzione di gestione del rischio, non solo dei costi.
In questa visione, il CISO e il responsabile degli acquisti non sono controparti in una negoziazione interna, ma alleati in un processo comune: identificare i vendor che offrono il miglior equilibrio tra valore economico e postura di sicurezza, e strutturare contratti che proteggano l’organizzazione lungo l’intero ciclo di vita della fornitura.
La security by design nel processo d’acquisto
Il principio di security by design – nato nell’ambito dello sviluppo software – si applica con piena pertinenza al processo di procurement IT. L’idea di fondo è semplice: i requisiti di sicurezza devono essere definiti prima che il processo di selezione inizi, inseriti nella documentazione di gara e utilizzati come criteri di valutazione vincolanti, non come elementi auspicabili ma rinunciabili in presenza di un’offerta economicamente vantaggiosa.
In pratica, questo significa che ogni RFP (Request for Proposal) o capitolato tecnico per forniture IT di rilevanza significativa dovrebbe includere una sezione dedicata ai requisiti di sicurezza, strutturata su tre livelli:
- requisiti minimi obbligatori (la cui mancanza è causa di esclusione);
- requisiti preferenziali (che concorrono al punteggio tecnico);
- requisiti dimostrativi (certificazioni, audit di terza parte, referenze documentate).
Questo approccio non è solo una buona pratica: per i soggetti NIS2 e per le pubbliche amministrazioni soggette al Codice degli Appalti, è sempre più una necessità normativa.
Requisiti di sicurezza minimi nel capitolato tecnico
La definizione dei requisiti di sicurezza minimi dipende dal tipo di fornitura, dal contesto normativo e dal livello di accesso che il vendor avrà ai sistemi e ai dati dell’organizzazione.
Tuttavia, esistono requisiti trasversali che dovrebbero essere presenti in qualsiasi capitolato IT di rilevanza non banale: la conformità a standard di sicurezza riconosciuti (ISO 27001 come baseline, con estensioni specifiche per cloud, sviluppo software o gestione dei dati personali), la capacità di gestione delle vulnerabilità e delle patch con SLA documentati, le procedure di notifica degli incidenti di sicurezza con tempi allineati agli obblighi normativi dell’organizzazione acquirente e le modalità di cessazione del servizio con restituzione o cancellazione sicura dei dati.
Per le forniture che coinvolgono dati personali, è necessario aggiungere i requisiti GDPR per i responsabili del trattamento: misure tecniche e organizzative adeguate, localizzazione del trattamento, sub-processor autorizzati, diritto di audit.
Per le forniture nei settori critici NIS2 (energia, trasporti, sanità, infrastrutture digitali, acque, finanza) si aggiungono i requisiti specifici della direttiva: gestione del rischio, sicurezza della supply chain, continuità operativa e cifratura dei dati.
Alla luce di ciò, le aziende potrebbero pensare di stilare un capitolato tecnico con requisiti di sicurezza:
- definire un template di requisiti di sicurezza per categoria di fornitura (SaaS, IaaS, hardware, servizi professionali);
- includere nel capitolato: standard richiesti, SLA di sicurezza, obblighi di notifica, diritti di audit, condizioni di offboarding;
- distinguere requisiti obbligatori (escludenti) da preferenziali (a punteggio);
- richiedere documentazione probatoria: certificazioni, report di audit, penetration test recenti;
- aggiornare i template almeno annualmente per allinearli all’evoluzione normativa.
Criteri di valutazione oltre il prezzo: la sicurezza nel vendor scoring
L’integrazione della sicurezza nei criteri di valutazione è il punto in cui la teoria del security by design si scontra più frequentemente con la realtà operativa del procurement.
Il prezzo rimane un fattore determinante in qualsiasi processo di selezione, e la tentazione di sacrificare requisiti di sicurezza sull’altare del risparmio è concreta. La risposta a questa tensione non è ideologica – pretendere che la sicurezza prevalga sempre sul costo è irrealistico – ma metodologica: costruire un sistema di scoring che renda visibile e quantificabile il valore della sicurezza come componente del valore complessivo dell’offerta.
Un modello di vendor scoring per IT procurement dovrebbe assegnare un peso esplicito alla postura di sicurezza del vendor, tipicamente tra il 20% e il 35% del punteggio tecnico complessivo per forniture ad alto impatto.
I sotto-criteri più rilevanti includono: l’esistenza e il livello di certificazioni di sicurezza, i risultati di assessment di terza parte recenti, la trasparenza nella comunicazione degli incidenti pregressi, la qualità del programma di vulnerability disclosure, e la solidità dei piani di business continuity e disaster recovery.
Il quadro normativo dell’IT procurement: settore privato, regolamentato e pubblico
Ecco, quindi, un’analisi del framework normativo dell’IT procurement a cui sono soggette le organizzazioni.
NIS2 e DORA: obblighi per il settore privato regolamentato
Per i soggetti essenziali e importanti identificati dalla direttiva NIS2 (operatori di energia, trasporti, acque, infrastrutture digitali, sanità, finanza e altri settori critici) il procurement IT non è un processo interno discrezionale: è un’area soggetta a requisiti normativi espliciti.
L’articolo 21 della direttiva impone la gestione della sicurezza nella catena di approvvigionamento come misura obbligatoria, con la conseguenza che ogni acquisto IT rilevante deve essere condotto secondo criteri che tengano conto dei rischi di sicurezza associati al fornitore.
DORA va oltre, introducendo per le entità finanziarie l’obbligo di mantenere un registro aggiornato di tutti i contratti con provider ICT terzi, con classificazione per criticità e documentazione delle dipendenze funzionali.
Prima di stipulare un contratto con un provider ICT che supporta funzioni critiche o importanti, le entità finanziarie devono condurre una valutazione approfondita del rischio che include l’analisi della concentrazione, ovvero il rischio sistemico derivante dall’eccessiva dipendenza da un singolo provider o da un ristretto numero di vendor per funzioni non sostituibili in tempi brevi.
Il Codice degli Appalti e la cybersecurity nel procurement pubblico
Il D.lgs. 36/2023 (Codice degli Appalti) ha introdotto una serie di innovazioni rilevanti per l’integrazione della sicurezza nel procurement IT delle pubbliche amministrazioni.
Il principio del risultato, nuovo cardine del codice, implica che le stazioni appaltanti debbano valutare le offerte in una prospettiva di valore complessivo, non solo economico, aprendo formalmente spazio all’inclusione di criteri di sicurezza informatica nei capitolati tecnici e nelle griglie di valutazione.
Il perimetro di sicurezza nazionale cibernetico (D.L. 105/2019 e successivi decreti attuativi) introduce obblighi specifici per le PA che acquistano beni, sistemi e servizi ICT destinati a funzioni comprese nel perimetro: notifica preventiva ad ACN, utilizzo del Centro di Valutazione e Certificazione Nazionale (CVCN) per la verifica dei prodotti, e restrizioni sui vendor considerati ad alto rischio per la sicurezza nazionale.
Questi obblighi si applicano indipendentemente dal valore economico dell’acquisto, il che rende la sicurezza un criterio di qualificazione preventiva del vendor, non un requisito secondario.
Le linee guida AgID sul procurement ICT per le PA (aggiornate per allinearsi al nuovo Codice) raccomandano l’adozione di modelli contrattuali standardizzati che includano clausole di sicurezza, l’utilizzo del MePA (Mercato Elettronico della PA) per forniture sottosoglia con vendor già qualificati, e la conduzione di assessment di sicurezza preacquisto per le forniture di maggiore impatto.
Per le PA soggette a NIS2, questi adempimenti si sovrappongono agli obblighi della direttiva, creando un quadro di compliance complesso ma coerente nella sua logica di fondo.
Dalla selezione alla contrattualizzazione: i presidi obbligatori
Di seguito, invece, analizziamo quelli che sono i presidi obbligatori per un corretto processo di IT procurement.
Clausole di sicurezza nei contratti IT: cosa non può mancare
Il contratto è il confine legale della relazione con il vendor: tutto ciò che non è scritto non è esigibile. Questa considerazione, ovvia nella sua semplicità, è spesso dimenticata nelle fasi concitate di finalizzazione di un accordo commerciale, dove la pressione a chiudere rapidamente porta a contratti con lacune significative proprio sugli aspetti di sicurezza.
Un contratto IT privo di clausole di sicurezza adeguate non è solo una debolezza negoziale: è un rischio operativo e normativo concreto.
Le clausole irrinunciabili per qualsiasi contratto IT di rilevanza significativa riguardano almeno sei aree:
- la gestione degli incidenti di sicurezza (tempi di notifica, procedure di escalation, responsabilità di comunicazione verso le autorità);
- la gestione delle vulnerabilità e delle patch (SLA differenziati per severità, finestre di manutenzione, comunicazione proattiva);
- il diritto di audit e ispezione (frequenza, preavviso, perimetro, costi);
- la protezione dei dati (misure tecniche, localizzazione, sub-processor, cancellazione a fine contratto);
- la business continuity (RTO e RPO garantiti, test periodici, documentazione dei piani);
- le condizioni di cessazione (modalità di trasferimento dei dati, supporto alla migrazione, periodi di transizione).
Audit rights e diritto di ispezione: esercitarli davvero
Il diritto di audit è una delle clausole più frequentemente incluse nei contratti IT e più raramente esercitata nella pratica.
Le ragioni sono comprensibili: gli audit sono costosi, richiedono competenze specialistiche, disturbano il rapporto commerciale con il vendor. Ma un diritto di audit mai esercitato è, di fatto, una clausola priva di valore deterrente e i vendor lo sanno.
Per i soggetti NIS2 e DORA, l’esercizio effettivo dei diritti di audit non è solo una buona pratica: è parte integrante del programma di gestione del rischio fornitore che l’organizzazione è tenuta a mantenere.
Un approccio pragmatico prevede di differenziare la modalità di audit per livello di criticità del vendor: audit documentale annuale (review di certificazioni, report di terza parte, questionari) per i vendor a medio rischio; audit tecnico periodico con accesso diretto ai sistemi per i vendor critici; verifica continua attraverso strumenti di security rating per tutti i vendor significativi.
L’inserimento di requisiti di sicurezza nelle prime fasi d’acquisto previene l’esposizione a minacce informatiche strutturali. I processi decisionali devono basarsi su un quadro di
I processi di acquisto IT più maturi prevedono che la selezione del vendor non sia mai disgiunta da una rigorosa valutazione dei fornitori terzi: solo integrando il Vendor Risk Management nel ciclo di procurement è possibile isolare i partner non allineati prima che diventino un vettore di rischio operativo.
Gestione del ciclo di vita del vendor: onboarding, operatività e offboarding sicuro
Il processo di procurement non si conclude con la firma del contratto: inizia.
La gestione del ciclo di vita del vendor, dall’onboarding iniziale alla cessazione del rapporto, è la fase in cui la qualità del processo di selezione si traduce (o non si traduce) in sicurezza operativa reale. Un vendor selezionato con criteri rigorosi ma poi integrato nei sistemi senza un processo di onboarding sicuro può diventare rapidamente un rischio.
L’onboarding sicuro di un nuovo vendor IT prevede la definizione precisa dei perimetri di accesso (quali sistemi, quali dati, con quale livello di privilegio) e la loro implementazione tecnica attraverso segmentazione di rete, identità federate, accessi privilegiati mediati da soluzioni PAM.
Il principio del minimo privilegio deve essere applicato fin dal primo giorno: un vendor che richiede accesso amministrativo completo a un sistema per erogare un servizio di manutenzione parziale è un segnale di allarme, non una richiesta da accettare per ragioni di convenienza operativa.
L’offboarding, ossia la cessazione del rapporto con un vendor, è la fase più frequentemente trascurata e potenzialmente la più rischiosa.
Credenziali non revocate, accessi non chiusi, dati non recuperati o non cancellati: questi sono i residui di una relazione commerciale terminata che possono diventare vettori di compromissione.
Per i vendor che avevano accesso a sistemi critici o a dati sensibili, l’offboarding deve essere un processo formale con checklist, responsabilità assegnate, verifica tecnica e documentazione.
Il termine del contratto non coincide automaticamente con la cessazione degli accessi: questo è un errore operativo che le organizzazioni più mature hanno imparato a eliminare con procedure strutturate.
Il ruolo del CISO nel procurement IT: da consulente a decision-maker
Il cambiamento più significativo nell’evoluzione del procurement IT non è tecnologico né normativo: è organizzativo. Riguarda il ruolo del CISO e, più in generale, della funzione di sicurezza informatica nel processo decisionale di acquisto.
Il modello tradizionale, in cui il CISO viene coinvolto a posteriori per “validare” scelte già fatte, è incompatibile con un approccio maturo al rischio IT.
Le organizzazioni più avanzate nella gestione del rischio supply chain hanno strutturato un modello in cui il CISO ha potere di veto formale sugli acquisti IT che superano determinate soglie di criticità, e in cui i requisiti di sicurezza sono parte integrante del processo di RFP e non un supplemento aggiunto in fase di negoziazione.
Questo non significa che la sicurezza debba prevalere sempre su ogni altra considerazione: significa che il rischio di sicurezza deve essere visibile, quantificato e consapevolmente accettato (o mitigato) prima della firma del contratto, non scoperto dopo il deployment.
Il CISO che aspira a questo ruolo strategico nel procurement deve sviluppare competenze che vanno oltre la sicurezza tecnica: deve saper parlare il linguaggio del business, tradurre i rischi tecnici in impatti economici e reputazionali comprensibili al management, e costruire relazioni collaborative con il procurement, il legal e le business unit.
La sicurezza nel procurement non si impone per decreto interno: si guadagna dimostrando che il contributo della funzione di sicurezza migliora la qualità delle decisioni, non solo la loro conformità formale.
Partecipa alla community