Oltre il questionario: guida per il Responsabile della sicurezza delle informazioni agli audit dei fornitori ad alto rischio per NIS2 e DORA

Il rapporto arrivò sulla scrivania di Maria Valen, Responsabile della sicurezza delle informazioni, con un tonfo ovattato che suonò più come una sirena. Era la valutazione pre-audit per il prossimo riesame di conformità a DORA, e una riga era evidenziata con un tratto netto di inchiostro rosso: “Assurance insufficiente per il fornitore terzo critico, CloudSphere.”
CloudSphere non era un fornitore qualunque. Era la dorsale della nuova piattaforma di digital banking dell’azienda, responsabile dell’elaborazione quotidiana di milioni di transazioni. Maria aveva in archivio il loro certificato ISO/IEC 27001:2022. Aveva anche il questionario di sicurezza compilato, un documento corposo da 200 domande. Ma il team di pre-audit stava segnalando che, per un fornitore critico e ad alto rischio, la conformità basata su caselle da spuntare non era più sufficiente. Le regole erano cambiate.
Con la Direttiva NIS2 e il Digital Operational Resilience Act (DORA) ormai pienamente applicabili, le autorità di regolamentazione guardano oltre la documentazione formale. Richiedono prove concrete di due diligence, monitoraggio continuo e governance solida sull’intera catena di fornitura. La sfida di Maria è la stessa che affrontano i Responsabili della sicurezza delle informazioni ovunque: come superare il questionario per sottoporre davvero ad audit e mettere in sicurezza i fornitori più critici? Serve un cambio di passo strategico: dalla validazione passiva all’assurance attiva e basata su evidenze.
Il limite del questionario statico in un contesto dinamico
Per anni il questionario di sicurezza è stato il pilastro della gestione del rischio di terze parti. Ma è una fotografia statica in un panorama delle minacce dinamico. Il profilo di rischio di un fornitore non è immutabile: evolve con ogni nuova minaccia, modifica di sistema o subappaltatore inserito nella catena. Affidarsi esclusivamente all’autodichiarazione per un fornitore critico come CloudSphere equivale a navigare in una tempesta con la mappa meteo dell’anno precedente.
La Direttiva NIS2 richiede esplicitamente un approccio basato sul rischio e impone che le misure di sicurezza siano proporzionate ai rischi effettivi. Ciò significa che un questionario uguale per tutti è strutturalmente disallineato rispetto alle aspettative normative moderne. Sono finiti i tempi in cui un certificato o una checklist compilata potevano sostituire le evidenze. Il rischio reale si trova oltre la traccia documentale.
È qui che diventa essenziale un approccio strutturato e basato sul ciclo di vita. Non si tratta di abbandonare i questionari, ma di integrarli con verifiche più approfondite e incisive per i fornitori realmente rilevanti. Questo è il principio centrale incorporato nella Politica di sicurezza delle terze parti e dei fornitori di Clarysec. Uno dei suoi obiettivi fondamentali è:
“Richiedere una due diligence formale e valutazioni del rischio documentate prima dell’ingaggio di nuovi fornitori o del rinnovo di accordi di servizio ad alto rischio.”
- Dalla sezione ‘Obiettivi’, clausola di policy 3.3
Questa clausola sposta l’impostazione da un semplice controllo a un’indagine formale, primo passaggio essenziale per costruire un programma difendibile e in grado di reggere al vaglio regolamentare.
Rischio dei fornitori in NIS2 e DORA: le nuove aspettative
Sia NIS2 sia DORA richiedono alle organizzazioni di identificare, valutare e monitorare sistematicamente e in modo continuo i rischi nel proprio ecosistema di fornitori. Trasformano la gestione dei fornitori da funzione di approvvigionamento a pilastro centrale della resilienza operativa e della sicurezza delle informazioni.
Il nuovo contesto regolamentare richiede quadri di riferimento chiari, strettamente mappati su standard consolidati come ISO/IEC 27001:2022. Di seguito una sintesi di alto livello di ciò che questi quadri di riferimento si aspettano dal programma di governance dei fornitori:
| Requisito | NIS2 | DORA | Controlli ISO/IEC 27001:2022 |
|---|---|---|---|
| Valutazione del rischio dei fornitori | Article 21(2)(d) | Articles 28–30 | 5.19, 5.21 |
| Clausole contrattuali di sicurezza | Article 21(3), Article 22 | Article 30 | 5.20 |
| Monitoraggio continuo | Article 21, Article 22 | Articles 30, 31 | 5.22 |
| Gestione delle vulnerabilità e risposta agli incidenti | Article 23 | Article 9, 11 | 5.29, 8.8 |
Un programma solido di audit dei fornitori non deve essere inventato da zero. Il quadro di riferimento ISO/IEC 27001:2022, in particolare i controlli dell’Annex A, offre un modello efficace. In Clarysec guidiamo i clienti a costruire il programma intorno a tre controlli interconnessi che formano un ciclo di vita completo della governance dei fornitori.
Costruire un quadro di audit difendibile: il ciclo di vita ISO 27001:2022
Per costruire un programma che soddisfi le autorità di regolamentazione serve un approccio strutturato, fondato su uno standard riconosciuto a livello globale. I controlli di sicurezza dei fornitori in ISO/IEC 27001:2022 forniscono un ciclo di vita per gestire il rischio di terze parti dall’avvio del rapporto fino alla cessazione. Vediamo come Maria può utilizzare questo ciclo di vita per costruire un piano di audit difendibile per CloudSphere.
Passaggio 1: la base - Sicurezza delle informazioni nei rapporti con i fornitori (5.19)
Il controllo 5.19 è il punto di partenza strategico. Richiede di istituire processi formali per identificare, valutare e gestire i rischi per la sicurezza delle informazioni associati all’intero ecosistema dei fornitori. È qui che l’organizzazione definisce che cosa significa “alto rischio” e stabilisce le regole del gioco.
Zenith Controls: The Cross-Compliance Guide di Clarysec fornisce un’analisi dettagliata del controllo 5.19, illustrandone il ruolo di snodo centrale per la governance dei fornitori. Questo controllo è intrinsecamente collegato a controlli correlati, come 5.21 (Sicurezza delle informazioni nella catena di fornitura ICT), che copre componenti hardware e software, e 5.14 (Trasferimento delle informazioni), che disciplina lo scambio sicuro dei dati. Non è possibile gestire efficacemente un rapporto con un fornitore senza controllare anche la tecnologia che fornisce e i dati che vengono condivisi.
Per Maria, questo significa che l’audit di CloudSphere deve andare oltre il livello di sicurezza aziendale generale e approfondire la sicurezza della piattaforma effettivamente fornita. La guida Zenith Controls evidenzia che una solida attuazione del controllo 5.19 supporta direttamente la conformità alle principali normative:
- NIS2 (Article 21(2)(d)): obbliga le organizzazioni a gestire il rischio della catena di fornitura come parte centrale del proprio quadro di sicurezza.
- DORA (Articles 28–30): impone un solido quadro di riferimento per la gestione del rischio ICT di terze parti, inclusa la classificazione della criticità e la due diligence precontrattuale.
- GDPR (Article 28): richiede ai titolari del trattamento di avvalersi solo di responsabili del trattamento che offrano garanzie sufficienti per la protezione dei dati.
Questo controllo impone la classificazione dei fornitori per livello di rischio, il monitoraggio continuativo e la revoca tempestiva degli accessi. La sua finalità è assicurare che la sicurezza sia integrata nel ciclo di vita del fornitore, e non aggiunta successivamente come elemento accessorio.
Passaggio 2: l’applicazione - Gestire la sicurezza delle informazioni negli accordi con i fornitori (5.20)
Un requisito di sicurezza che non è previsto nel contratto è solo una raccomandazione. Il controllo 5.20 è il punto in cui la governance diventa giuridicamente vincolante. Per un fornitore ad alto rischio, il contratto è lo strumento di audit più potente.
Come sottolinea Zenith Controls, questi accordi devono essere espliciti. Promesse vaghe di “sicurezza secondo le migliori pratiche del settore” non hanno valore operativo. Per un fornitore come CloudSphere, Maria deve verificare che il contratto includa clausole specifiche e misurabili che attribuiscano alla sua organizzazione una vigilanza concreta:
- Diritto di audit: una clausola che attribuisca esplicitamente all’organizzazione il diritto di svolgere valutazioni tecniche, riesaminare evidenze o incaricare una terza parte di effettuare audit per suo conto.
- Tempistiche di notifica delle violazioni: tempistiche specifiche e stringenti, ad esempio entro 24 ore dalla rilevazione, per notificare all’azienda un incidente di sicurezza, non una generica formula “senza indebito ritardo”.
- Gestione dei subappaltatori, o quarte parti: una clausola che imponga al fornitore di applicare gli stessi standard di sicurezza ai propri subappaltatori critici e di notificare eventuali modifiche. È un requisito essenziale per gestire il rischio a valle.
- Strategia di uscita sicura: obblighi chiari per la restituzione o la distruzione certificata dei dati alla cessazione del contratto.
DORA è particolarmente prescrittivo su questo punto. Article 30 elenca le previsioni contrattuali obbligatorie, incluso l’accesso senza ostacoli per auditor e autorità di regolamentazione, dettagli specifici sulle sedi di erogazione dei servizi e strategie di uscita complete. Gli auditor campioneranno i contratti dei fornitori ad alto rischio e verificheranno direttamente la presenza di tali clausole.
Passaggio 3: il ciclo continuo - Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori (5.22)
L’ultimo elemento del ciclo di vita è il controllo 5.22, che trasforma la vigilanza sui fornitori da verifica puntuale a processo continuo. Un audit non dovrebbe essere un evento inatteso, ma un punto di validazione all’interno di un rapporto continuativo basato sulla trasparenza.
È qui che molte organizzazioni mostrano le maggiori carenze. Ottengono la firma del contratto e lo archiviano. Ma per i fornitori ad alto rischio il lavoro reale inizia dopo l’onboarding. La guida Zenith Controls collega il controllo 5.22 a processi operativi critici come 8.8 (Gestione delle vulnerabilità tecniche) e 5.29 (Sicurezza delle informazioni durante le interruzioni). Ciò significa che un monitoraggio efficace va ben oltre una riunione annuale di riesame. Include:
- Riesame delle evidenze di terze parti: ottenere e analizzare attivamente i report SOC 2 Type II, i risultati degli audit di sorveglianza ISO 27001 o le sintesi dei test di penetrazione. L’aspetto decisivo è riesaminare le eccezioni e monitorarne la remediation.
- Monitoraggio degli incidenti: tracciare violazioni o incidenti di sicurezza divulgati pubblicamente che coinvolgono il fornitore e valutarne formalmente il potenziale impatto sull’organizzazione.
- Gestione delle modifiche: applicare un processo in cui qualsiasi modifica significativa del servizio del fornitore, come una nuova sede di data center o un nuovo subappaltatore critico, attivi automaticamente una nuova valutazione del rischio.
Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec fornisce indicazioni operative su questo aspetto, in particolare nel passaggio 24, dedicato al rischio dei subappaltatori. La guida raccomanda:
“Per ogni fornitore critico, identificare se utilizza subappaltatori o sub-responsabili che possono accedere ai dati o ai sistemi dell’organizzazione. Documentare in che modo i requisiti di sicurezza delle informazioni vengono trasferiti a tali soggetti… Ove possibile, richiedere un elenco dei principali subappaltatori e assicurare che il diritto di audit o di ottenere assurance si applichi anche a loro.”
Questo è un punto cruciale per Maria. CloudSphere utilizza una società terza di analisi dei dati? La sua infrastruttura è ospitata su un grande cloud pubblico? Queste dipendenze a valle rappresentano un rischio significativo, spesso non visibile, che l’audit deve portare alla luce.
Dalla teoria all’azione: il piano di audit pratico di Maria per CloudSphere
Sulla base di questo ciclo di vita ISO 27001:2022, il team di Maria redige un nuovo piano di audit per CloudSphere che va ben oltre il questionario e dimostra la governance matura e basata sul rischio richiesta dalle autorità di regolamentazione.
Riesame contrattuale: il team inizia mappando il contratto CloudSphere esistente rispetto a DORA Article 30 e alle migliori pratiche per il controllo 5.20. Predispone un report sulle lacune per orientare il successivo ciclo di rinnovo e dare priorità alle aree dell’audit in corso.
Richiesta mirata di evidenze: invece di un questionario generico, invia una richiesta formale di evidenze specifiche, tra cui:
- il più recente report SOC 2 Type II e una sintesi delle modalità con cui sono state corrette tutte le eccezioni rilevate;
- la sintesi esecutiva del più recente test di penetrazione esterno;
- un elenco completo di tutti i subappaltatori, o quarte parti, che tratteranno o accederanno ai dati dell’organizzazione;
- evidenza che i requisiti di sicurezza siano trasferiti contrattualmente a tali subappaltatori;
- log o report che dimostrino l’applicazione tempestiva delle patch per vulnerabilità critiche, ad esempio Log4j e MOVEit, negli ultimi sei mesi.
Validazione tecnica: il team attiva la clausola sul “diritto di audit” per pianificare una sessione tecnica di approfondimento con il team di sicurezza di CloudSphere. L’agenda si concentra sui playbook di risposta agli incidenti, sugli strumenti di gestione della postura di sicurezza cloud e sui controlli di prevenzione della perdita di dati.
Gestione formale delle eccezioni: se CloudSphere si oppone alla fornitura di determinate evidenze, Maria è preparata. Il processo di governance dell’organizzazione, definito nella Politica di sicurezza delle terze parti e dei fornitori, è chiaro:
“Le eccezioni ad alto rischio, ad esempio fornitori che trattano dati regolamentati o supportano sistemi critici, devono essere approvate dal Responsabile della sicurezza delle informazioni, dalla funzione Legale e dalla Direzione Acquisti, e registrate nel Registro delle eccezioni del SGSI.”
- Dalla sezione ‘Trattamento del rischio ed eccezioni’, clausola di policy 7.3
Ciò assicura che qualsiasi rifiuto di fornire evidenze non venga semplicemente ignorato, ma sia oggetto di accettazione del rischio formale ai massimi livelli dell’organizzazione, secondo un processo che gli auditor riconoscono come solido.
La prospettiva dell’auditor: cosa richiederanno auditor diversi
Per costruire un programma realmente resiliente è necessario ragionare come un auditor. Quadri di audit diversi adottano prospettive diverse, e anticiparne le domande è decisivo. Di seguito una vista consolidata di ciò che diversi auditor richiederebbero nel riesaminare il programma di governance dei fornitori:
| Profilo dell’auditor | Area di attenzione e controlli principali | Evidenze che richiederà |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | 5.19, 5.20, 5.22 | Inventario dei fornitori con classificazioni di rischio; campione di contratti di fornitori ad alto rischio per verificare le clausole di sicurezza; registrazioni della due diligence e delle riunioni di riesame continuativo. |
| Auditor COBIT 2019 | APO10 (Manage Suppliers), DSS04 (Manage Continuity) | Evidenza del monitoraggio continuativo delle prestazioni rispetto agli SLA; documentazione su come vengono gestiti gli incidenti relativi ai fornitori; registrazioni dei riesami del rischio dei fornitori e della gestione delle modifiche. |
| DORA / Autorità di regolamentazione finanziaria | Articles 28-30 | Contratto con il fornitore ICT critico, mappato sulle clausole obbligatorie di DORA; valutazione del rischio di concentrazione; evidenza del test o del riesame della strategia di uscita. |
| Auditor NIST SP 800-53 | SA-9 (External System Services), famiglia SR (Supply Chain) | Evidenza del piano di gestione del rischio della catena di fornitura; registrazioni delle evidenze di conformità dei fornitori, ad esempio FedRAMP e SOC 2; documentazione della visibilità sul rischio di quarta parte. |
| Auditor ISACA / IT | ITAF Performance Standard 2402 | Log che dimostrino la revoca tempestiva degli accessi del personale del fornitore cessato; evidenza di account univoci protetti da MFA per l’accesso di terze parti; registrazioni di risposta agli incidenti. |
Questa prospettiva multi-lente dimostra che un programma solido non mira a soddisfare un solo standard, ma a costruire un quadro di governance olistico che generi le evidenze necessarie per rispondere a tutti.
Errori critici: dove falliscono gli audit dei fornitori
Molti programmi di vigilanza sui fornitori non raggiungono l’obiettivo a causa di errori comuni ed evitabili. Occorre prestare particolare attenzione a questi punti critici:
- Audit come evento isolato: affidarsi ad audit una tantum in fase di onboarding o rinnovo, invece di applicare un monitoraggio continuo.
- Eccessiva fiducia nelle certificazioni: accettare un certificato ISO o SOC 2 al valore nominale senza riesaminare dettagli del report, campo di applicazione ed eccezioni.
- Contratti vaghi: non includere clausole esplicite e azionabili per il diritto di audit, la notifica delle violazioni e la gestione dei dati.
- Gestione insufficiente dell’inventario: non essere in grado di produrre un inventario completo e classificato per livello di rischio di tutti i fornitori e dei dati a cui accedono.
- Rischio a valle ignorato: non identificare e non gestire i rischi posti dai subappaltatori critici del fornitore, ossia il rischio di quarta parte.
- Gestione delle vulnerabilità non verificata: confidare che il fornitore applichi le patch alle vulnerabilità critiche senza richiedere evidenze.
Checklist operativa per gli audit dei fornitori ad alto rischio
Utilizza questa checklist, adattata dal Zenith Blueprint, per assicurare che il processo di audit per ogni fornitore ad alto rischio sia completo e difendibile.
| Passaggio | Azione | Evidenze da raccogliere e conservare |
|---|---|---|
| Due diligence | Effettuare e documentare una valutazione formale del rischio prima dell’onboarding o del rinnovo. | Scheda di valutazione del rischio del fornitore completata; registrazione della classificazione; report di due diligence. |
| Riesame del contratto | Verificare che le clausole di sicurezza, privacy e audit siano presenti e azionabili. | Contratto firmato con clausole evidenziate; approvazione formale del riesame legale; accordo di trattamento dei dati. |
| Monitoraggio continuativo | Pianificare e svolgere riesami trimestrali o annuali in base al livello di rischio. | Verbali di riunione; report SOC 2 / ISO 27001 riesaminati; sintesi delle scansioni di vulnerabilità. |
| Vigilanza sui subappaltatori | Identificare e documentare tutti i fornitori critici a valle, o quarte parti. | Elenco dei sub-responsabili fornito dal fornitore; evidenza delle clausole di trasferimento dei requisiti di sicurezza. |
| Gestione delle vulnerabilità | Richiedere evidenze di un programma maturo di gestione delle vulnerabilità. | Sintesi esecutiva di un recente test di penetrazione; esempi di report di scansione delle vulnerabilità; tempistiche di applicazione delle patch. |
| Segnalazione degli incidenti | Testare e convalidare il processo di notifica degli incidenti del fornitore. | Registrazioni delle notifiche di incidenti precedenti; SLA documentati per la notifica delle violazioni. |
| Gestione delle modifiche | Riesaminare tutte le modifiche tecniche o organizzative significative presso il fornitore. | Registri delle modifiche del fornitore; report di nuova valutazione del rischio attivati dalle modifiche. |
| Mappatura normativa | Mappare i controlli attuati direttamente sui requisiti NIS2, DORA e GDPR. | Tabella interna di mappatura della conformità; registro delle evidenze per le autorità di regolamentazione. |
Conclusione: costruire una catena di fornitura resiliente e difendibile
L’era della conformità a caselle da spuntare per i fornitori critici è finita. Il livello di scrutinio imposto da normative come NIS2 e DORA richiede un cambiamento fondamentale verso un modello di assurance continua e basata su evidenze. I Responsabili della sicurezza delle informazioni come Maria devono guidare il passaggio delle organizzazioni oltre il questionario statico.
Costruendo un programma sul ciclo di vita comprovato dei controlli ISO/IEC 27001:2022, si crea un quadro di riferimento non solo conforme, ma realmente efficace nel ridurre il rischio. Ciò richiede di trattare la sicurezza dei fornitori come una disciplina strategica, incorporare requisiti azionabili nei contratti e mantenere una vigilanza attenta lungo tutto il rapporto.
La sicurezza dell’organizzazione è forte quanto il suo anello più debole e, nell’ecosistema interconnesso di oggi, quell’anello si trova spesso presso una terza parte. È il momento di riprendere il controllo.
Pronto a superare il questionario?
I toolkit integrati di Clarysec offrono le basi necessarie per costruire un programma di gestione del rischio dei fornitori di livello elevato, in grado di reggere qualsiasi audit.
- Scarica i nostri template di policy: applica un solido quadro di governance con la nostra Politica di sicurezza delle terze parti e dei fornitori di livello enterprise e con la sua controparte per le PMI.
- Segui il Zenith Blueprint: utilizza Zenith Blueprint: An Auditor’s 30-Step Roadmap per implementare e sottoporre ad audit un SGSI conforme, con passaggi dedicati alla gestione del rischio dei fornitori.
- Sfrutta Zenith Controls: richiedi una demo di Zenith Controls: The Cross-Compliance Guide per mappare i controlli sui fornitori rispetto a NIS2, DORA, GDPR, NIST e altri quadri, assicurando che il piano di audit sia completo e difendibile.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


