Valutazione del rischio dei fornitori: certificazioni, dipendenze e continuità operativa

Quanto conosciamo davvero i nostri fornitori? Certificazioni, dipendenze, subfornitori e continuità operativa: cosa considerare nella valutazione del rischio di terze parti.

Un’azienda utilizza da anni un software sviluppato quasi interamente su misura. Il fornitore è affidabile, conosce processi e integrazioni, dispone di procedure di sicurezza strutturate e il rapporto non ha mai prodotto criticità significative.

Poi, durante una verifica della supply chain, emerge una domanda: se domani quel fornitore non fosse più in grado di erogare il servizio, quanto tempo servirebbe per sostituirlo?

Tre mesi, sei, forse un anno.

Parte del software è proprietaria. Alcune configurazioni sono conosciute soltanto dal fornitore. Sul mercato non esiste un’alternativa immediatamente utilizzabile.

Il suo livello di sicurezza non è cambiato. È diventato visibile un rischio che fino a quel momento non era stato misurato: la dipendenza.

È un buon punto di partenza per ragionare sulla valutazione dei fornitori, perché mostra anche il limite di un approccio basato esclusivamente sulla verifica delle misure di cybersecurity. Un partner può essere maturo, certificato e ben organizzato e rappresentare comunque una criticità elevata per chi utilizza i suoi servizi.

Prima del questionario viene il servizio

Non tutti i fornitori richiedono lo stesso livello di approfondimento.

Una software house con accessi amministrativi ai sistemi aziendali presenta un profilo diverso da quello di un fornitore che non accede né a dati né a infrastrutture. Una piattaforma dalla quale dipende un processo essenziale merita un’attenzione diversa da un’applicazione utilizzata per un’attività marginale.

Prima del questionario viene quindi la classificazione.

Quanto sarebbe grave un’interruzione? Quali sistemi e dati sono coinvolti? Il fornitore dispone di accessi privilegiati? Il servizio è integrato con altre piattaforme? Esistono alternative realistiche? Quanto sarebbe complesso sostituirlo?

Sono domande che permettono di decidere anche quanto debba essere profonda la successiva verifica.

La Direttiva (UE) 2022/2555 colloca espressamente la sicurezza della supply chain tra le misure di gestione dei rischi di cybersicurezza. Nel quadro italiano, il D.Lgs. 138/2024 e i provvedimenti dell’Agenzia per la Cybersicurezza Nazionale inseriscono i rapporti di fornitura nella gestione complessiva del rischio cyber. La famiglia ISO/IEC 27036 affronta lo stesso tema lungo il ciclo di vita della relazione tra cliente e fornitore.

La logica che ne deriva non consiste nell’accumulare controlli. Consiste nel concentrare le verifiche dove le conseguenze di un problema sarebbero maggiori.

Il cliente non è un organismo di certificazione

Tra le prime informazioni richieste a un fornitore compare quasi sempre la certificazione ISO/IEC 27001.

È una richiesta corretta. Un certificato valido, rilasciato nell’ambito di un sistema di certificazione accreditato, costituisce un’attestazione di parte terza indipendente sulla conformità del sistema di gestione della sicurezza delle informazioni ai requisiti dello standard.

Proprio perché si tratta di un’attestazione di parte terza, però, occorre evitare un equivoco: il cliente non è un organismo di certificazione.

Non gli compete ripetere l’audit, sostituirsi al giudizio di chi ha condotto la verifica o pretendere automaticamente l’intera documentazione del sistema di gestione come se dovesse certificare nuovamente il fornitore.

Al cliente compete altro.

Prima di tutto può verificare la consistenza del certificato: autenticità e validità, organismo che lo ha emesso e relativo accreditamento, eventuali sospensioni o revoche.

Poi deve leggerne il perimetro.

Un certificato ISO/IEC 27001 si riferisce infatti a uno scope definito, che può comprendere determinate attività, servizi, sedi, processi o infrastrutture. Il servizio che stiamo acquistando rientra effettivamente in quel perimetro?

La domanda è meno banale di quanto sembri. Un’impresa può essere certificata e offrire anche servizi che non ricadono nello scope della certificazione. In quel caso non sarebbe corretto estendere automaticamente a questi ultimi il valore dell’attestazione.

Neppure uno scope perfettamente coerente, però, conclude la valutazione.

La certificazione riguarda un sistema di gestione e la sua conformità ai requisiti dello standard. Non misura quanto il cliente dipenda dal fornitore, quanto sia difficile sostituirlo, quali conseguenze avrebbe l’interruzione del servizio o quali dipendenze ulteriori siano presenti nella catena di erogazione. Non determina neppure livelli di servizio, condizioni contrattuali o solidità economica dell’impresa.

La certificazione serve proprio perché evita al cliente di rifare verifiche già affidate a un processo indipendente. Il suo valore non diminuisce per questo; cambia la domanda successiva.

Una volta verificato ciò che il certificato copre, bisogna occuparsi di ciò che non copre.

Ed è qui che la valutazione diventa third-party risk assessment.

Certificazioni, questionari, dichiarazioni ed evidenze sono input. L’oggetto dell’assessment è invece lo specifico rapporto di fornitura: il servizio acquistato, il suo peso sui processi aziendali e il rischio che quella relazione introduce.

Per un fornitore marginale l’analisi può fermarsi a poche verifiche documentali. Per un fornitore critico occorre andare più a fondo.

Anche le procedure, in questo contesto, vanno lette con proporzione. Sapere che esistono processi di incident management, business continuity o vulnerability management è utile. Quando il rischio lo giustifica, può diventare rilevante capire se siano aggiornati, testati e utilizzati: un’esercitazione recente, responsabilità ed escalation definite, le azioni correttive successive a un incidente sono informazioni più significative della sola presenza di un documento.

Questo non autorizza il cliente a trasformarsi in auditor del sistema di gestione. Possono essere sufficienti evidenze mirate e coerenti con la criticità del servizio, nel rispetto della riservatezza del fornitore.

La NIS2 Technical Implementation Guidance di ENISA dedica attenzione proprio alle evidenze utilizzabili per verificare l’attuazione delle misure. Il principio è utile anche qui: chiedere ciò che serve per assumere una decisione sul rischio, non documenti per il solo fatto che esistano.

Il rischio può essere fuori dal perimetro del fornitore

Torniamo all’esempio iniziale.

Il fornitore può superare positivamente la valutazione di sicurezza e rimanere comunque difficile da sostituire. In un servizio SaaS, per esempio, occorre capire se i dati siano esportabili in un formato realmente utilizzabile, se le configurazioni possano essere trasferite, quali alternative esistano e quanto tempo richiederebbe una migrazione.

A volte la criticità risiede nelle competenze. Il servizio può essere documentato, ma una parte sostanziale della conoscenza operativa appartiene a poche persone del fornitore. Altrove il problema è tecnologico: formati proprietari, integrazioni sviluppate ad hoc, componenti difficili da migrare.

La possibilità di uscire da una relazione dice quindi qualcosa sulla sua rischiosità già quando quella relazione comincia.

C’è poi ciò che accade dietro il fornitore.

Due applicazioni acquistate da società differenti possono utilizzare lo stesso cloud provider. Servizi contrattualmente indipendenti possono dipendere dalla stessa infrastruttura o dalla medesima componente tecnologica. In caso di incidente, la separazione che appare nell’anagrafica dei fornitori potrebbe non esistere sul piano operativo.

Da qui l’utilità, per i servizi più critici, di conoscere almeno i subfornitori e le dipendenze realmente essenziali all’erogazione.

Non occorre ricostruire all’infinito ogni anello della supply chain. Sarebbe spesso impraticabile e produrrebbe una quantità di informazioni difficilmente utilizzabile. Interessa piuttosto individuare quei soggetti, infrastrutture o tecnologie la cui indisponibilità avrebbe conseguenze concrete sul servizio acquistato.

È in questo spazio che si collocano concetti come fourth-party risk e concentration risk. Ma il problema può essere espresso senza terminologia specialistica: quanti dei nostri fornitori, apparentemente indipendenti, dipendono in realtà dalla stessa cosa?

Una mappa essenziale delle dipendenze può, in alcuni casi, rispondere meglio di una lunga lista di vendor.

La qualifica deve produrre una decisione

Il third-party risk assessment ha senso se conduce a un esito.

Il fornitore può essere idoneo per il servizio considerato, idoneo a determinate condizioni oppure presentare un rischio che l’organizzazione non intende accettare. Possono emergere misure compensative, richieste contrattuali o la necessità di mantenere un’alternativa.

È questo passaggio che trasforma la raccolta di documenti in una qualifica.

E richiede competenze diverse. Il CISO valuta le misure di sicurezza; l’IT conosce integrazioni e dipendenze tecnologiche; il procurement sa quanto sia realmente ampio il mercato delle alternative; Legal interviene su responsabilità, subfornitura, audit e condizioni di uscita; Compliance sugli obblighi applicabili. Il business conosce l’impatto che avrebbe l’indisponibilità.

Quando il fornitore tratta dati personali si aggiunge il GDPR. L’articolo 28 richiede al titolare di ricorrere a responsabili che presentino garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate. Anche qui la selezione del soggetto esterno deve quindi trovare posto nel sistema di accountability del titolare.

La decisione finale dovrebbe essere riconoscibile e documentata.

Altrimenti l’accettazione del rischio rimane dispersa tra una valutazione tecnica, uno scambio di e-mail, una decisione commerciale e il contratto. Ricostruirla successivamente, soprattutto dopo un incidente o durante una verifica, diventa molto più difficile.

Lo stesso assessment dovrebbe arrivare alla negoziazione.

Se è emersa una dipendenza da un determinato subfornitore, il contratto può disciplinarne il cambiamento. Se la tempestività della comunicazione di un incidente è essenziale, deve essere trattata come tale. Tempi di ripristino, gestione degli accessi, restituzione dei dati, audit e supporto alla migrazione possono assumere un peso diverso a seconda di ciò che la valutazione ha fatto emergere.

Il contratto può governare molti di questi rischi. Non può però creare un’alternativa che non esiste o rendere immediatamente sostituibile una tecnologia proprietaria.

Ciò che resta è rischio residuo. E qualcuno deve decidere se accettarlo.

Un fornitore qualificato oggi potrebbe non esserlo domani

La qualifica non riguarda un fornitore in astratto. Riguarda quel fornitore, per quel servizio, nelle condizioni esistenti al momento della valutazione.

Le condizioni cambiano.

Il provider può modificare l’infrastruttura, introdurre un nuovo subfornitore, essere acquisito o subire un incidente. Può cambiare anche il peso del servizio per il cliente: una piattaforma nata come applicazione marginale può diventare essenziale dopo che altri processi sono stati costruiti intorno ad essa.

Per questo il riesame deve seguire la criticità del rapporto e gli eventi che ne modificano significativamente il profilo.

Il NIS Investments 2025 di ENISA offre una fotografia interessante. Tra le organizzazioni intervistate, il 63% richiede ai fornitori il rispetto di standard di sicurezza o il mantenimento di certificazioni, il 54% conduce valutazioni del rischio o audit sui fornitori e il 48% inserisce requisiti di cybersecurity nei contratti. Nello stesso studio, gli attacchi alla supply chain e alle terze parti rimangono tra le principali preoccupazioni indicate per il futuro.

È un dato che ridimensiona l’idea secondo cui il problema possa essere risolto semplicemente aumentando il numero dei controlli.

Il punto è sapere che cosa quei controlli ci hanno permesso di capire.

Quanto è importante il servizio. Quali garanzie abbiamo verificato. Dove si trovano le dipendenze. Quanto sarebbe difficile sostituire il fornitore. Quale rischio rimane e chi ha deciso di accettarlo.

A quel punto il questionario ha svolto il suo compito.

La valutazione, invece, ha prodotto una decisione.

FAQ

La certificazione ISO/IEC 27001 è sufficiente per qualificare un fornitore?

No. È un’attestazione indipendente importante e deve essere valutata verificandone validità e scope. Non copre però tutti gli elementi dello specifico rapporto di fornitura, come criticità del servizio, sostituibilità, dipendenze, condizioni contrattuali e rischio residuo.

Che cos’è un third-party risk assessment?

È la valutazione del rischio associato allo specifico rapporto con una terza parte. Considera, in misura proporzionata alla criticità, il servizio affidato, sistemi e dati coinvolti, accessi, evidenze di sicurezza, dipendenze, subfornitori rilevanti e possibilità di sostituzione. Si inserisce nel più ampio processo di Third Party Risk Management (TPRM).

Come si individua un fornitore critico?

La criticità dipende soprattutto dall’impatto che un problema del fornitore potrebbe produrre sull’organizzazione. Continuità dei processi, accesso a sistemi e dati, privilegi concessi, difficoltà di sostituzione e dipendenze tecnologiche sono alcuni degli elementi da considerare.

Quando deve essere rivalutato un fornitore?

La frequenza dipende dalla criticità del rapporto. Una nuova valutazione può inoltre rendersi opportuna quando cambiano significativamente servizio, infrastruttura, subfornitori o modalità operative oppure dopo eventi che modificano il profilo di rischio.

Fonti

Normativa europea e italiana

Direttiva (UE) 2022/2555 del Parlamento europeo e del Consiglio del 14 dicembre 2022 (Direttiva NIS2), in particolare artt. 21 e 22.

Decreto legislativo 4 settembre 2024, n. 138, recepimento della Direttiva (UE) 2022/2555.

Agenzia per la Cybersicurezza Nazionale (ACN), provvedimenti e documentazione attuativa della disciplina NIS2.

Regolamento (UE) 2016/679 (GDPR), in particolare artt. 28 e 32.

Garante per la protezione dei dati personali, documentazione istituzionale sulla sicurezza del trattamento e sulla selezione e vigilanza dei responsabili del trattamento.

Standard e fonti europee

ENISA, NIS2 Technical Implementation Guidance, 2025.

ENISA, NIS Investments 2025.

ISO/IEC 27001, Information security management systems — Requirements.

ISO/IEC 27036-1:2021, Cybersecurity — Supplier relationships — Overview and concepts.

ISO/IEC 27036-2:2022, Cybersecurity — Supplier relationships — Requirements.

ISO/IEC 27036-3:2023, Cybersecurity — Supplier relationships — Guidelines for hardware, software and services supply chain security.

Approfondimenti internazionali

UK National Cyber Security Centre (NCSC), documentazione sulla supply chain security, gestione del rischio dei fornitori, dipendenze, concentration risk e condizioni di uscita.