Fornitori ICT e NIS2: la due diligence cyber non puo fermarsi al questionario

Per anni molte imprese hanno trattato la sicurezza dei fornitori digitali come una pratica amministrativa: un questionario da inviare prima del contratto, qualche dichiarazione su certificazioni e backup, una clausola generica sulla riservatezza, poi il tema finiva nel fascicolo acquisti. Questo approccio oggi non regge piu. Non regge sul piano tecnico, perche i servizi cloud, gli ERP, i software gestionali, le piattaforme documentali e gli strumenti di cybersecurity sono sempre piu interconnessi. Non regge sul piano organizzativo, perche un incidente su un fornitore puo bloccare processi critici anche quando l'infrastruttura interna e ben protetta. Non regge sul piano normativo, perche NIS2 ha portato la gestione del rischio e della catena di fornitura dentro le responsabilita di governo dell'impresa.

Il segnale piu recente arriva dagli Stati Uniti, ma e utile anche per le aziende europee. L'8 luglio 2026 il NIST ha pubblicato la versione finale della Special Publication 1326, una guida rapida dedicata alla due diligence cyber nella supply chain ICT. Il documento non introduce obblighi per le imprese italiane, ma chiarisce un metodo: la due diligence non e una raccolta passiva di risposte, e un processo investigativo per raccogliere informazioni pertinenti su fornitori e prodotti, in modo da prendere decisioni consapevoli su nuovi acquisti e sistemi gia in uso. Pochi giorni prima, il 30 giugno 2026, il NIST aveva pubblicato anche la versione finale della SP 800-18 Rev. 2 sui piani di sicurezza, privacy e cybersecurity supply chain risk management per i sistemi.

Letti insieme, questi documenti dicono una cosa molto concreta: non basta sapere chi e il fornitore. Bisogna sapere che cosa fornisce, da chi dipende, quali controlli applica, come reagisce agli incidenti, quali evidenze produce e come il suo servizio entra nei processi dell'impresa.

Perche il questionario non basta

Il questionario resta uno strumento utile, ma non puo essere il centro del modello di controllo. Il suo limite principale e che fotografa una dichiarazione, non necessariamente una capacita reale. Un fornitore puo dichiarare di avere procedure di sicurezza, piani di continuita, controlli sugli accessi e gestione delle vulnerabilita; la domanda successiva e: con quali prove? Con quale frequenza vengono aggiornate? Chi le approva? Quali sistemi sono coperti? Quali subfornitori restano fuori?

La SP 1326 del NIST propone di guardare alla due diligence come a una valutazione strutturata del fornitore ICT. Tra le componenti indicate ci sono elementi come proprieta, controllo o influenza estera, provenienza, resilienza, pratiche cyber di base e livelli della catena di fornitura. Tradotto in linguaggio aziendale: non devo limitarmi a chiedere se il fornitore "e sicuro"; devo capire se ci sono dipendenze critiche, se il prodotto ha una storia tecnica ricostruibile, se il servizio puo continuare in caso di incidente, se le pratiche minime sono davvero operative e se esistono livelli di subfornitura che aumentano il rischio.

Questo cambia anche il ruolo degli acquisti. La cybersecurity non puo arrivare solo alla fine, quando il prezzo e gia stato negoziato e il contratto e quasi pronto. Deve entrare prima: nella definizione dei requisiti, nella selezione dei fornitori, nella valutazione dei rischi, nelle clausole contrattuali e nel monitoraggio successivo.

NIS2 sposta il tema sul governo dell'impresa

In Italia, ACN ricorda che il decreto NIS prevede obblighi per gli organi di amministrazione e direttivi, per la gestione dei rischi e per l'adozione di misure di sicurezza informatica. Non tutte le aziende rientrano direttamente nel perimetro NIS2, e questo va verificato caso per caso. Ma il punto manageriale e piu ampio: anche un'impresa non soggetta puo diventare fornitore di un soggetto essenziale o importante, oppure dipendere da fornitori digitali che sostengono funzioni critiche.

La supply chain digitale non e piu una questione solo contrattuale. E una parte del sistema di controllo interno. Se un ERP in cloud gestisce ordini, produzione, magazzino e fatturazione, quel servizio non e "solo IT". Se una piattaforma di ticketing coordina assistenza clienti e manutenzione, non e "solo software". Se un provider esterno amministra backup, identita digitali o endpoint, il rischio passa direttamente nei processi aziendali.

Per questo la due diligence deve distinguere tra fornitori ordinari e fornitori critici. Non tutti meritano lo stesso livello di verifica. Ma per i fornitori che toccano dati sensibili, continuita operativa, identita, infrastrutture, produzione o servizi essenziali, la valutazione deve diventare piu rigorosa e documentata.

Cosa chiedere davvero a un fornitore ICT

Una valutazione seria parte da domande semplici, ma pretende risposte verificabili.

La prima riguarda il perimetro del servizio. Quali sistemi, dati, ambienti, sedi, API, account amministrativi e subfornitori sono coinvolti? Un contratto generico su "servizi cloud" non basta se poi il servizio include backup, monitoraggio, accesso remoto, gestione identita o integrazioni con l'ERP.

La seconda riguarda le pratiche cyber essenziali. Gestione delle vulnerabilita, patching, autenticazione multifattore, segregazione degli accessi, logging, backup, cifratura, hardening, change management e risposta agli incidenti devono essere descritti in modo operativo. Non serve trasformare ogni PMI in un ente di certificazione, ma serve capire se le misure esistono, sono applicate e sono controllate.

La terza riguarda la resilienza. Che cosa succede se il fornitore subisce un ransomware, perde un data center, cambia subfornitore, interrompe un servizio o blocca un account critico? Esistono tempi di ripristino, prove di continuita, procedure di comunicazione, export dei dati, alternative operative e responsabilita chiare?

La quarta riguarda la provenienza e la manutenzione del prodotto. Nel software moderno la catena di fornitura include librerie, componenti open source, ambienti cloud, strumenti di sviluppo, repository, pipeline di rilascio e dipendenze di terze parti. Quando il servizio e critico, l'impresa dovrebbe chiedere almeno come il fornitore gestisce vulnerabilita, componenti, aggiornamenti e comunicazioni di sicurezza.

La quinta riguarda le evidenze. Policy, audit, certificazioni, report di test, attestazioni, piani di sicurezza, procedure di incident response e risultati di verifiche non hanno tutti lo stesso valore. L'obiettivo non e accumulare documenti, ma costruire una base ragionevole per decidere, accettare o mitigare il rischio.

Dal vendor risk assessment al piano di sistema

La SP 800-18 Rev. 2 del NIST e utile per un motivo: collega sicurezza, privacy e supply chain in piani di sistema. Un sistema non e solo una tecnologia; e un insieme di scopi, confini, controlli, responsabilita e comportamenti attesi da chi lo gestisce, lo supporta e lo usa. Questa impostazione aiuta anche fuori dal contesto federale americano, perche spinge le aziende a documentare il servizio digitale come parte di un processo, non come oggetto isolato.

Per un'impresa, il passaggio pratico e questo: per i fornitori ICT critici non basta avere una scheda anagrafica. Serve una scheda di sistema. Dentro dovrebbero esserci almeno il processo supportato, il proprietario interno, il livello di criticita, i dati trattati, le integrazioni, i controlli attesi, i rischi principali, le mitigazioni, le responsabilita del fornitore, le responsabilita dell'impresa e il piano di revisione periodica.

Questa documentazione non deve diventare burocrazia sterile. Deve servire a rispondere velocemente a domande operative: se domani il fornitore segnala un incidente, chi decide? Quali processi sono impattati? Quali dati possono essere coinvolti? Quali alternative abbiamo? Quali obblighi di notifica o comunicazione vanno valutati? Quali evidenze avevamo raccolto prima dell'incidente?

Il contributo ENISA: criticita e maturita non viaggiano sempre insieme

Nel report NIS360 2026, ENISA osserva la maturita e la criticita dei settori NIS2 ad alta criticita. Il messaggio piu utile per le imprese e che la maturita cyber migliora, ma resta disomogenea tra settori e dentro gli stessi ecosistemi. Inoltre, alcuni settori e servizi digitali sono cruciali proprio perche molte altre attivita dipendono da loro.

Questo vale anche su scala aziendale. Un fornitore puo sembrare piccolo per valore contrattuale, ma essere enorme per impatto operativo. Un servizio poco costoso puo bloccare produzione, logistica, fatturazione o assistenza clienti. Una piattaforma verticale di nicchia puo avere accessi molto estesi o dati difficili da ricostruire. La criticita non coincide sempre con il budget.

Una buona due diligence deve quindi combinare due letture: quanto e maturo il fornitore e quanto e critico per noi. Se il fornitore e poco maturo ma poco critico, il rischio puo essere accettabile o gestibile con misure leggere. Se e poco maturo e molto critico, serve una decisione: rafforzare i controlli, cambiare architettura, chiedere garanzie ulteriori, prevedere alternative o valutare un altro fornitore.

Una checklist pragmatica per partire

Il lavoro puo iniziare senza grandi progetti. Bastano quattro passi.

• Mappare i fornitori ICT che hanno accesso a sistemi, dati, identita digitali, produzione, amministrazione, clienti o continuita operativa.
• Classificarli per criticita, non solo per spesa: impatto su processi, dati, tempi di fermo, obblighi normativi e dipendenze da subfornitori.
• Chiedere evidenze proporzionate: controlli minimi, gestione vulnerabilita, continuita, incident response, subfornitura, localizzazione e uscita dal servizio.
• Inserire nel contratto e nel monitoraggio clausole verificabili: notifiche di incidente, tempi di risposta, audit, diritto di ricevere evidenze, export dei dati, supporto alla migrazione e revisione periodica.

Il risultato atteso non e eliminare il rischio. Sarebbe impossibile. L'obiettivo e sapere quale rischio si sta accettando, chi lo governa e quali contromisure sono gia pronte.

La conclusione per direzione, IT e compliance

La sicurezza della supply chain digitale e diventata una disciplina di governo. Non puo restare schiacciata tra ufficio acquisti, IT e legale, con ciascuno che vede solo una parte del problema. Serve un linguaggio comune: criticita del processo, rischio del fornitore, evidenze disponibili, responsabilita interne, clausole contrattuali e piano di monitoraggio.

La domanda da portare in direzione non e "abbiamo mandato il questionario?". La domanda corretta e: "per i fornitori ICT che possono fermare l'azienda o esporre dati critici, sappiamo dimostrare perche li consideriamo affidabili?".

Se la risposta non e chiara, il prossimo passo non e comprare un altro tool. E costruire un processo di due diligence cyber che produca decisioni verificabili, non solo documenti archiviati.

Fonti

• [NIST – SP 1326 Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide](https://csrc.nist.gov/pubs/sp/1326/final)
• [NIST – SP 800-18 Rev. 2 Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems](https://csrc.nist.gov/pubs/sp/800/18/r2/final)
• [NIST – Cybersecurity Supply Chain Risk Management publications](https://csrc.nist.gov/Projects/cyber-supply-chain-risk-management/publications)
• [ENISA – NIS360 2026](https://www.enisa.europa.eu/sites/default/files/2026-05/ENISA%20NIS360%202026.pdf)
• [ACN – Obblighi NIS](https://www.acn.gov.it/portale/nis/obblighi)