Arriva un’e-mail dal vostro cliente più importante.
In allegato un foglio di calcolo di qualche decina di righe, nell’oggetto le parole valutazione dei fornitori, nel corpo del messaggio una data: due settimane, a volte dieci giorni. Nessuno in azienda ha mai visto un documento del genere e la prima sensazione è che serva un consulente solo per capire le domande.
La notizia meno scoraggiante è che questi file sono più standardizzati di quanto sembri e che buona parte delle risposte è già in azienda, distribuita tra contratti, procedure e configurazioni dei sistemi. Quello che manca, quando manca, è sempre lo stesso tipo di informazione: le domande che non chiedono se una misura esiste, ma quando l’avete verificata e con quale esito.
Qui trovate come è costruito un questionario di questo tipo, quali domande contiene, in quale ordine conviene affrontarlo e come si gestiscono le voci a cui oggi non potete rispondere con un sì documentato.

Che cos’è un questionario di sicurezza fornitori
Un questionario di sicurezza fornitori è un documento di autovalutazione che un’azienda invia a chi le fornisce prodotti o servizi, per raccogliere in forma comparabile le misure di sicurezza adottate. Non prevede la visita di un verificatore: le risposte le scrivete voi e diventano un impegno contrattuale a tutti gli effetti.
La richiesta nasce dagli obblighi del vostro cliente sulla catena di approvvigionamento. La direttiva NIS2 chiede ai soggetti che vi rientrano di gestire il rischio derivante dai rapporti con i fornitori, e la ISO/IEC 27001 nella revisione del 2022 mantiene controlli dedicati alla sicurezza nelle relazioni con l’esterno. L’effetto è a cascata: voi potreste non avere alcun obbligo diretto, ma erogate un servizio a chi ce l’ha, e nei settori regolati la verifica documentata sui fornitori è diventata prassi, dalla sanità all’energia ai trasporti. Non siete sotto osservazione: state alimentando un adempimento che riguarda lui.
Come è fatto: aree, codici e domande tipiche
I questionari che circolano in Italia derivano quasi tutti dalle stesse fonti, e il riferimento più diffuso è il modello elaborato dal Clusit: quarantotto temi distribuiti su tre aree, ciascuna con un proprio codice identificativo. La prima riguarda la gestione della sicurezza, quindi politiche, responsabilità, gestione degli incidenti e rapporti con i sub-fornitori. La seconda copre la sicurezza informatica in senso stretto: sistemi, reti, applicazioni, dati, gestione degli accessi. La terza si occupa della sicurezza fisica di sedi e locali tecnici. Ogni domanda è mappata sui requisiti della ISO/IEC 27001 e del Framework Nazionale di Cyber Security, le risposte sono chiuse e il punteggio finale si calcola attribuendo pesi distinti ai temi e alle singole voci.
| Codice | Domanda | Risposta | Note / remediation / azioni in corso |
|---|---|---|---|
| GES.04 | È stata designata una figura con responsabilità formale sulla sicurezza delle informazioni? | Sì | Nomina interna, allegato 3 |
| SIT.11 | Con quale periodicità vengono eseguite analisi delle vulnerabilità sui sistemi in perimetro? | Sì, semestrale | Ultima verifica conclusa nel semestre in corso, perimetro concordato con il committente |
| SIT.18 | Le applicazioni raggiungibili da internet sono sottoposte a test di sicurezza prima del rilascio? | No | Test applicativo sul portale clienti pianificato entro il trimestre successivo, perimetro e fornitore già individuati |
| SIT.24 | Le copie di sicurezza sono sottoposte a test di ripristino documentati? | Sì | Verbale dell’ultimo ripristino riuscito disponibile su richiesta |
Le domande dell’area organizzativa chiedono l’esistenza di qualcosa e il suo perimetro. Vi verrà chiesto se è stata designata una figura con responsabilità formale sulla sicurezza delle informazioni, indicando ruolo e riporto; se esiste una procedura documentata di gestione degli incidenti con una finestra di notifica al committente; se i sub-fornitori che accedono ai dati del cliente sono a loro volta sottoposti a valutazione e con quale periodicità.
Le domande dell’area tecnica sono formulate diversamente, e la differenza è sostanziale: chiedono una data, una metrica o una configurazione, non una dichiarazione di intenti. Ricorrono la periodicità delle analisi delle vulnerabilità con la data dell’ultima svolta, la classificazione delle criticità secondo una metrica di gravità con i tempi massimi di correzione per ciascuna classe, la presenza di autenticazione a più fattori sugli accessi amministrativi, l’assenza di utenze condivise, la conservazione dei registri di accesso privilegiato e la sua durata, la cifratura dei dati a riposo e in transito con la gestione delle chiavi, la segmentazione delle reti che trattano dati del committente, la verifica delle copie di sicurezza tramite test di ripristino documentati. Su quest’ultimo punto vale una nota: la domanda non chiede se eseguite i backup, chiede quando avete provato a ripristinarli. Anche le voci sulla cifratura in transito vanno oltre la presenza di un certificato valido, e sul perché un certificato digitale non basti a dimostrare la sicurezza di un servizio esposto abbiamo scritto in modo esteso.
Il modello Clusit è pubblico e scaricabile gratuitamente con licenza Creative Commons, e nella versione più recente copre anche i requisiti richiamati in ambito NIS2. Se il file che avete ricevuto è un Excel con codici a tre lettere e risposte a tendina, molto probabilmente è partito da lì: leggere l’originale permette di conoscere le domande prima di riceverle.
In quale ordine conviene compilarlo
L’errore più comune è aprire il file e partire dalla prima riga. I temi sono raggruppati per ambito, non per difficoltà, e questo porta a impantanarsi su una voce tecnica dopo dieci minuti di lavoro.
- Chiedete al cliente qual è il perimetro. Il questionario va compilato rispetto al servizio che erogate a lui, non rispetto all’intera azienda. Se fornite un applicativo gestito, contano i sistemi su cui gira quell’applicativo e le utenze che vi accedono; le postazioni dell’ufficio commerciale sono un altro ambito. È una mail di due righe che evita giorni di lavoro inutile.
- Individuate chi possiede materialmente le risposte. Una parte sta in amministrazione, tra contratti e nomine; una parte in chi amministra i sistemi, che spesso è un fornitore esterno; una parte in chi gestisce il personale, per le attività formative. Riunire le tre parti una volta è più rapido che rimbalzare il file per posta.
- Separate le voci documentali da quelle tecniche. Le prime si chiudono consultando un documento esistente, le seconde richiedono di guardare i sistemi e vanno avviate subito perché hanno tempi propri: incidono il numero di indirizzi in perimetro, la presenza di applicazioni personalizzate e il livello di approfondimento richiesto, come abbiamo dettagliato parlando degli elementi che incidono sul costo di un vulnerability assessment.
- Compilate il gruppo documentale annotando accanto a ogni risposta il riferimento preciso al documento che la sostiene. Vi servirà quando il cliente chiederà l’allegato, e vi servirà l’anno prossimo alla richiesta successiva.
- Affrontate il gruppo tecnico verificando la configurazione attuale, non ricordando come era impostata al momento della messa in produzione. Le differenze tra i due approcci emergono sempre, e non nel momento più comodo.
- Rileggete prima di firmare. Chi firma si assume la responsabilità di quanto dichiarato, quindi è opportuno che sia anche chi ha visto le evidenze.
Le domande che richiedono un’evidenza tecnica
Il gruppo tecnico è quello che blocca la compilazione, e riconoscerlo in anticipo è metà del lavoro. Qui sotto alcune formulazioni ricorrenti, con l’indicazione di che cosa il committente sta effettivamente verificando.
| Esempio di domanda | Che cosa verifica il committente | Da dove arriva la risposta |
|---|---|---|
| Con quale periodicità eseguite analisi delle vulnerabilità sui sistemi che erogano il servizio? Data dell’ultima. | Che il controllo sia ricorrente e non episodico | Report di vulnerability assessment con data e perimetro |
| Le vulnerabilità rilevate sono classificate per gravità? Quali tempi massimi di correzione per ciascuna classe? | Che esista un processo con criteri e tempi dichiarati | Registro delle criticità e procedura di gestione |
| Come dimostrate che le criticità segnalate nell’ultima verifica sono state risolte? | Che le correzioni siano state applicate e riscontrate | Riverifica svolta dopo gli interventi |
| Le applicazioni raggiungibili da internet sono sottoposte a test di sicurezza prima del rilascio? | Che il codice esposto sia verificato, non solo l’infrastruttura | Test applicativo sui portali pubblici |
| L’accesso amministrativo richiede autenticazione a più fattori? Esistono utenze condivise? | Che i privilegi siano nominali e protetti | Configurazione verificata sui sistemi in uso |
| Le copie di sicurezza sono sottoposte a test di ripristino? Data dell’ultimo test riuscito. | Che il backup sia utilizzabile, non solo presente | Verbale del test di ripristino |
Leggendo la colonna di destra si vede il punto: quattro voci su sei si compilano solo con un’analisi tecnica datata alle spalle. Chi ha svolto un vulnerability assessment nei mesi precedenti apre il report e trascrive date, perimetro ed esiti; chi non l’ha mai fatto si trova davanti a un bivio tra una risposta che non può sostenere e una risposta negativa. Sulla voce relativa agli accessi amministrativi il ragionamento è lo stesso, e se dovete irrobustire quel fronte prima di dichiararlo abbiamo raccolto il quadro nella guida all’autenticazione a più fattori.
Se il questionario chiede la data dell’ultima verifica e non avete una risposta, il punto di partenza è un’analisi delle vulnerabilità sui sistemi che erogano il servizio al cliente: produce l’evidenza tecnica da cui si compilano tutte le voci del gruppo.
Il campo note e le scadenze troppo strette
Nei questionari costruiti bene, accanto a ogni domanda esiste un campo libero destinato alle note, agli interventi di correzione e alle attività in corso. Serve soprattutto quando la risposta è negativa, e viene sistematicamente ignorato da chi compila di fretta.
È un errore, perché quello è l’unico punto del foglio in cui potete argomentare invece di selezionare un valore da una tendina. Un fornitore che risponde no alla voce sui test applicativi e nelle note dichiara che l’attività è pianificata entro un trimestre, con perimetro e tipologia di verifica, comunica al valutatore che conosce la propria situazione e la sta governando. Un fornitore che risponde sì e lascia il campo vuoto comunica il contrario nel momento in cui gli viene chiesta la documentazione.
Questo risolve anche il problema più frequente, cioè la scadenza incompatibile con i tempi di una verifica seria. Se il cliente concede dieci giorni e l’analisi richiede tre settimane, la risposta corretta non è un sì di comodo: è una risposta negativa accompagnata da un piano con date. Nel calcolo le voci negative pesano, ma il punteggio non decide da solo, perché chi legge deve comunque redigere una valutazione del rischio e giustificarla. Un piano credibile gli semplifica il lavoro più di una casella verde priva di riscontri, che regge fino al primo approfondimento e poi diventa una contestazione contrattuale.
Nel frattempo esistono interventi che si avviano in tempi brevi e sono immediatamente documentabili. La formazione del personale è il caso tipico: molte aziende scoprono compilando il questionario che il punto più debole non è l’infrastruttura ma le persone, e colmano il divario con percorsi formativi tracciati per i dipendenti, citabili già alla richiesta successiva.
A chi rivolgersi per le risposte tecniche
Arrivati alle voci tecniche, la reazione più comune è inoltrare il file a chi amministra i sistemi. È il passaggio giusto per metà delle informazioni e insufficiente per l’altra metà, e la distinzione vale la pena di essere chiarita.
Chi gestisce la vostra infrastruttura, interno o esterno, sa dirvi come è configurata: quali aggiornamenti risultano applicati, come sono impostati i privilegi, dove finiscono le copie di sicurezza. Non è la stessa informazione che serve per rispondere se quei sistemi sono attaccabili, perché la seconda si ottiene solo provando ad attaccarli in condizioni controllate. Sono due mestieri distinti, e chiedere il secondo a chi svolge il primo produce risposte fragili proprio sulle voci che il committente approfondirà.
Per le domande su vulnerabilità, correzioni applicate e applicazioni esposte serve quindi chi svolge verifiche di sicurezza offensive: un test di sicurezza sulle applicazioni web per i portali raggiungibili da internet, un penetration test con perimetro concordato per l’infrastruttura nel suo insieme. Il risultato è un documento con date, esiti, classificazione delle criticità e interventi consigliati, che è esattamente il materiale da cui si compilano quelle righe.
Le aziende che seguiamo non affrontano questi file da sole, e non perché offriamo un servizio di compilazione: quando le verifiche sono già state svolte, le risposte esistono prima della domanda. Il lavoro consiste nel mettere in relazione due documenti, il questionario del committente da una parte e gli esiti delle analisi dall’altra, sapendo a quale controllo normativo si riferisce ciascuna voce. Le domande ancora aperte diventano un piano con tempi dichiarati, che è ciò che rende accettabile un non ancora.
Se i vostri clienti hanno iniziato a chiedervi garanzie documentate sulla sicurezza, conviene impostare un percorso di verifica prima della prossima richiesta invece di rincorrere ogni questionario alla scadenza.
