Gestire il rischio della supply chain: conformità a DORA e NIS2 nel 2026

La maggior parte dei consigli sul rischio della supply chain parte dal punto sbagliato. Parte da trasporti, carenze, lead time e concentrazione dei fornitori, come se il problema principale fosse ancora spostare scatole da un luogo all'altro.

Per le organizzazioni tecnologiche soggette a regolamentazione, questa visione è troppo ristretta per essere utile. La tua vera esposizione spesso si trova all'interno delle dipendenze software, delle piattaforme cloud, dei managed service provider, dei data sub-processor, degli aggiornamenti firmware, delle integrazioni di identità e dei punti di controllo operativo esternalizzati. Un fornitore può fallire senza perdere una spedizione. Può fallire distribuendo un aggiornamento difettoso, gestendo male l'accesso privilegiato, perdendo evidenze o diventando incapace di supportare un controllo regolamentato.

I revisori e i regolatori si preoccupano sempre meno del fatto che tu abbia una policy per i vendor e sempre più del fatto che tu possa dimostrare che il rischio dei fornitori è compreso, assegnato, monitorato e comprovato da evidenze. Questo cambia il lavoro. Il rischio della supply chain non è più un tema secondario della procurement. È un sistema di governance.

Oltre la logistica Ridefinire il rischio della supply chain

La versione più diffusa del rischio della supply chain è ancora dominata dal linguaggio della logistica. Ritardi, congestione, carenze, problemi doganali. Tutto questo conta, ma non descrive l'intera gamma dei rischi per le organizzazioni guidate dall'IT.

Una supply chain moderna include ogni terza parte che può influire sulla fornitura del servizio, sulla postura di sicurezza, sugli obblighi normativi o sugli esiti per il cliente. Questo significa host cloud, vendor software, provider di rilevamento gestito, piattaforme payroll, data processor, distributori hardware, partner di implementazione e subappaltatori di nicchia. Il rischio non è solo l'interruzione. È anche la perdita di controllo.

Le poste commerciali in gioco sono già elevate. NetSuite cita la stima di J.S. Held secondo cui le perdite aziendali annuali dovute alle interruzioni della supply chain sono di circa 184 miliardi di dollari nel 2025 (NetSuite on supply-chain risks). In pratica, le organizzazioni IT lo percepiscono attraverso la disponibilità ritardata dell'hardware, la dipendenza da fornitori di servizi multi-tier e guasti che si propagano attraverso relazioni software e di servizio anziché da un unico collo di bottiglia di magazzino.

Cosa manca alla visione ristretta

Se definisci ancora il rischio della supply chain come un tema di sourcing o di logistica, diversi fatti importanti spariscono dal campo visivo:

• Le dipendenze digitali contano quanto quelle fisiche: Un provider SaaS con controlli di accesso deboli può creare esposizione operativa e regolatoria senza influire su alcuna spedizione.
• I guasti si propagano tra i livelli: Il tuo fornitore diretto può sembrare stabile mentre un sub-processor nascosto, un componente software o una dipendenza infrastrutturale introducono fragilità.
• Le evidenze fanno parte della resilienza: Se un controllo esiste ma il tuo team non riesce a dimostrare ownership, cadenza di revisione o cronologia delle remediation, non hai un sistema di controllo verificabile.

Regola pratica: Se una terza parte può interrompere un servizio regolamentato, influenzare gli esiti di sicurezza o compromettere l'integrità dei tuoi record, deve rientrare nel tuo modello di rischio della supply chain.

Ecco perché la visibilità conta, ma non nel senso semplicistico di monitorare le merci in transito. I team devono ottenere visibilità end-to-end sulle dipendenze operative e digitali, incluso chi fornisce cosa, chi dipende da chi e quali evidenze esistono per il controllo. La stessa logica di governance si applica anche agli obblighi più ampi di trade risk management, soprattutto dove si sovrappongono aspetti contrattuali, giurisdizionali e di continuità del servizio.

Mappare la superficie di rischio della supply chain

I team tecnologici hanno bisogno di una mappa più chiara di "operativo, finanziario, geopolitico". Queste categorie sono troppo ampie per agire. Una mappa utile mostra dove un fornitore può influire su riservatezza, integrità, disponibilità, obblighi legali e capacità di ripristino.

Un'analisi recente del settore evidenzia un cambiamento netto. Il rischio della supply chain ICT è sempre più legato alla cybersecurity e alla fiducia nelle terze parti, non solo al trasporto fisico, con maggiore attenzione alla postura di sicurezza del fornitore, alle evidenze condivise e all'esposizione alle dipendenze (Inbound Logistics on supply chain risk management).

Rischio cyber nell'ecosistema dei fornitori

Per la maggior parte dei CISO, la prima categoria è la più ovvia e spesso la meno mappata in modo completo.

Il software di terze parti introduce esposizione attraverso vulnerabilità, meccanismi di aggiornamento insicuri, modelli di autenticazione deboli, permessi eccessivi e scarsa separazione tra ambienti cliente. Il problema non è solo se il vendor ha una policy di sicurezza. È se la sua architettura, la disciplina operativa e la catena di dipendenze possono essere considerate affidabili per il ruolo che svolge nel tuo servizio.

Esempi comuni includono:

• Rischio di dipendenza software: Librerie, plug-in, connettori e agent che si trovano nel tuo ambiente o scambiano dati sensibili.
• Rischio di accesso privilegiato: Support engineer, amministratori o account di integrazione con ampio accesso ai sistemi di produzione.
• Deterioramento della postura di sicurezza: Fornitori che apparivano maturi all'onboarding ma smettono di conservare evidenze, ritardano le patch o modificano l'infrastruttura senza revisione.
• Esposizione ai sub-processor: Dati che passano a entità che il contratto nomina in modo generico, o non nomina chiaramente affatto.

Rischio operativo nelle supply chain digitali

Il rischio operativo nelle supply chain spesso sembra tecnico prima che commerciale. Una dipendenza da una regione cloud, un managed service con un solo percorso di escalation o un provider di backup con impegni di recovery poco chiari possono diventare tutti punti singoli di guasto.

Un modo utile per testarlo è porre una domanda scomoda. Se questo fornitore diventasse indisponibile domani, cosa si fermerebbe per prima?

Di solito questo rivela la dipendenza sottostante. Potrebbe essere la federazione dell'identità, non l'hosting. Potrebbe essere una piattaforma di billing, non l'applicazione core. Potrebbe essere l'unico contractor che conosce una integrazione fragile.

Rischio di conformità dove contratti e controlli divergono

I fallimenti di conformità emergono di solito dove il linguaggio legale, la realtà tecnica e la titolarità operativa divergono.

Un vendor può accettare in linea di principio impegni di sicurezza, ma il contratto potrebbe non definire i diritti sulle evidenze, le aspettative di notifica delle violazioni, l'approvazione dei sub-processing, gli obblighi di conservazione o il supporto all'uscita. Allo stesso modo, un'azienda può avere un contratto solido ma nessun processo interno per esaminare le attestazioni, tracciare le eccezioni o escalation le remediation scadute.

Una tassonomia pratica appare così:

Per un approccio di governance più dettagliato a queste esposizioni dei fornitori, molti team riconosceranno la sovrapposizione con un strutturato third-party risk management. Il punto non è creare un altro registro. È mappare dove le terze parti possono rompere i tuoi controlli.

Un risk register che elenca i vendor senza nominare la dipendenza dal controllo è per lo più amministrazione. Non aiuta i team a decidere cosa testare o cosa correggere per primo.

Come regolamenti come DORA e NIS2 impongono una visione sistemica

La regolamentazione ha cambiato il dibattito. Non devi più convincere i board che il rischio dei fornitori appartiene alla resilienza operativa. DORA e NIS2 lo fanno già trattando la dipendenza da terze parti come parte del perimetro di controllo dell'organizzazione stessa.

L'effetto pratico è semplice. Se un fornitore supporta una funzione critica o importante, la tua responsabilità non si ferma all'onboarding. Ci si aspetta che tu comprenda la dipendenza, definisca le aspettative di controllo, monitori le prestazioni e mantenga evidenze che dimostrino che la supervisione è attiva.

Cosa cambia in pratica

Una revisione annuale del fornitore basata su documenti non soddisferà questa aspettativa. Né lo farà un fascicolo di procurement con un questionario firmato e nessuna chiara ownership dopo l'aggiudicazione del contratto.

Sotto la moderna regolamentazione della resilienza, le organizzazioni hanno bisogno di un sistema che colleghi:

• Decisioni di criticità: Perché questo fornitore conta e quale servizio o controllo dipende da lui.
• Controlli contrattuali: Termini di sicurezza, incident, cooperazione, audit, notifica e uscita.
• Supervisione operativa: Cadenza di revisione, tracciamento delle issue, service assurance ed escalation.
• Responsabilità a livello di board: Responsabilità chiara per accettare, mitigare o terminare l'esposizione al fornitore.

Molte organizzazioni hanno difficoltà. Hanno policy, ma le policy non sono evidenza di esecuzione. Hanno audit, ma gli audit sono istantanee. Hanno strumenti, ma nessuno riesce a spiegare chi possiede un'eccezione del fornitore sei mesi dopo che il risk committee ne ha discusso.

Un confronto utile si trova fuori dal settore software. Lo stesso principio appare nella logistica operativa e nella supervisione doganale, dove la disciplina non è una conformità astratta ma evidenza ripetibile e responsabilità documentata. Ecco perché una guida su how freight forwarders master compliance è rilevante anche per i lettori tecnici. Il modello operativo è familiare. La responsabilità deve sopravvivere oltre moduli e approvazioni.

La vera domanda del regolatore

Le domande di audit più difficili non sono di solito tecniche. Sono domande di governance.

Chi ha deciso che questo vendor fosse critico. Quale evidenza supportava quella decisione. Con quale frequenza viene riesaminata la posizione di rischio. Cosa è successo quando le evidenze erano in ritardo, incomplete o contraddittorie. Chi ha approvato l'eccezione. Come è stata verificata la remediation.

Queste domande riflettono una visione sistemica del controllo, non una visione a checklist. Questa breve panoramica cattura bene la pressione normativa:

Se il tuo processo attuale non riesce a rispondere a queste domande senza cercare manualmente in email, cartelle SharePoint e archivi contrattuali, il problema non è la prontezza all'audit. Il problema è che il sistema di controllo non è ancora abbastanza maturo.

Un sistema continuo per la valutazione e la mitigazione del rischio

Le revisioni annuali dei fornitori creano una falsa sicurezza. Gli auditor non vogliono la prova che un questionario sia stato inviato la scorsa primavera. Vogliono vedere che le decisioni di rischio sono ancora attuali, che le azioni scadute attivano l'escalation e che i cambiamenti nelle dipendenze portano a nuovi controlli senza aspettare il ciclo successivo del comitato.

Esiste già un modello praticabile. NIST descrive il risk management della supply chain come un ciclo ripetibile di frame, assess, respond, and monitor, che si adatta allo standard di governance che i regolatori si aspettano sempre più nella pratica (NCSC and NIST supply chain guidance).

Definisci il rischio prima di valutarlo

Valutare un fornitore prima di definire la dipendenza di solito produce rumore. Il lavoro utile inizia prima. Imposta il perimetro, identifica quali servizi e asset il fornitore tocca e assegna owner responsabili per la relazione, il set di controlli e il percorso di escalation.

Quella definizione dovrebbe rispondere ad alcune domande di governance con sufficiente precisione da resistere al controllo dell'audit:

• Quale servizio è impattato: Identifica il processo di business, il sistema o l'attività regolamentata coinvolta.
• Che tipo di dipendenza esiste: Data processing, componente software, infrastruttura, servizio operativo, accesso privilegiato al supporto o un mix.
• Quale guasto sarebbe più rilevante: Interruzione, violazione della sicurezza, gap nelle evidenze, non conformità legale, concentrazione del rischio o uscita fallita.
• Chi è responsabile: Indica il business owner, l'owner operativo e il control owner, non solo il contatto commerciale.

Se questi punti sono vaghi, anche il rating del rischio sarà vago.

Valuta con parametri che riflettano come si propagano i guasti

Un modello di valutazione utile fa più che assegnare alto, medio o basso. I ricercatori che hanno esaminato i metodi di supply chain risk hanno trovato valore ricorrente in fattori come propagation, detectability, likelihood, impact intensity e cause-effect relationships (state-of-the-art review on supply-chain risk assessment).

Questo conta negli ambienti regolamentati perché il fallimento di un fornitore raramente resta confinato a un solo contratto. Una debolezza in un vendor può influire su servizi di identità, operazioni cliente, conservazione dei record, risposta agli incident o sequenziamento del recovery.

Una valutazione pratica chiede:

• Propagation: Quali servizi, team o controlli sono impattati se questo fornitore fallisce.
• Detectability: Quanto rapidamente l'organizzazione identificherebbe il problema dal monitoraggio interno anziché dalla disclosure del fornitore.
• Likelihood: Il modo di guasto è credibile dato il modello operativo, la geografia, il subappalto o il livello di accesso del fornitore.
• Impact intensity: Quale esito di business si blocca, si degrada o diventa non conforme.
• Cause and effect: Quali dipendenze collegate renderebbero l'evento più difficile da isolare o da recuperare.

Un fornitore con spesa bassa può comunque trovarsi vicino alla cima del risk register se supporta autenticazione, reporting regolamentato o una dipendenza di recovery.

Rispondi assegnando azioni che possano essere comprovate

I piani di risposta falliscono quando restano a livello di intenzione. "Monitorare da vicino" non è un controllo. "Rivedere i report SOC trimestralmente, instradare le eccezioni al control owner entro cinque giorni lavorativi e bloccare il rinnovo finché non viene registrata l'evidenza di remediation" è un controllo.

Il modello di risposta dovrebbe corrispondere al tipo di rischio e alle evidenze disponibili. In pratica, ciò significa di solito scegliere da un insieme limitato di categorie di azione e assegnarne ciascuna a un owner con una scadenza:

• Contract actions: Rafforzare notifica incident, cooperazione agli audit, disclosure dei sub-processor, retention, assistenza all'uscita e diritti di ottenere evidenze.
• Technical actions: Ridurre l'accesso privilegiato, segmentare le integrazioni, aumentare il logging, rimuovere punti singoli di guasto nascosti o aggiungere controlli di validazione.
• Supplier actions: Richiedere piani di remediation, attestazioni più frequenti, riunioni di management o disclosure di cambiamenti materiali.
• Commercial actions: Rimandare l'onboarding, limitare il perimetro, evitare il rinnovo o aggiungere un fornitore alternativo dove la concentrazione non è giustificata.
• Continuity actions: Definire procedure di fallback, workaround manuali, step di recovery dei dati e il trigger per passare a tali misure.

Le supply chain fisiche offrono ancora una lezione utile qui. Il valore operativo deriva da percorsi di risposta predefiniti, non da dichiarazioni generiche sulla resilienza. I team che si occupano di trasporti, inventario o dipendenze di importazione possono vedere la stessa disciplina di pianificazione nelle AUSFF solutions for shipping disruptions.

Monitora il sistema di controllo, non solo il fornitore

Il monitoraggio continuo è il punto in cui i programmi basati sulla carta di solito si inceppano. Il rischio dei fornitori cambia tra un ciclo di revisione e l'altro, e la supervisione interna fallisce senza essere rilevata a meno che qualcuno non la stia misurando.

Traccia se le revisioni avvengono in tempo, se le evidenze sono scadute, se le eccezioni sono ancora approvate, se le azioni di remediation stanno superando la scadenza e se un cambiamento nella dipendenza del servizio ha aggiornato il record di rischio. Questi sono segnali di governance. Mostrano se l'organizzazione sta controllando il rischio dei fornitori o lo sta solo discutendo.

Qui diventa necessaria anche una chiara audit trail for supplier risk decisions and follow-up actions. Sotto DORA e NIS2, riuscire a mostrare lo stato corrente è solo una parte del lavoro. Devi anche mostrare come si è arrivati a quello stato, chi ha approvato le deviazioni e se la mitigazione promessa è effettivamente avvenuta.

Il test pratico è semplice. Se un fornitore critico cambia architettura, perde una certificazione, manca una data di remediation o segnala un incidente, il tuo sistema dovrebbe aggiornare la posizione di rischio, attivare il workflow del responsabile corretto e preservare le evidenze senza che nessuno debba ricostruire la storia dalle email in un secondo momento.

Raccogliere evidenze che soddisfino gli auditor

Gli audit raramente falliscono perché un'organizzazione non ha fatto nulla. Falliscono perché nessuno può provare cosa è stato fatto, chi l'ha approvato, se il controllo è ancora applicabile e come sono state contenute le eccezioni.

Sotto DORA e NIS2, quel gap conta. Gli auditor non cercano un fascicolo del fornitore rifinito la notte prima del fieldwork. Vogliono evidenze tratte dal processo operativo stesso. Se un fornitore supporta un servizio critico, il record dovrebbe mostrare la dipendenza, la revisione, la decisione, il follow-up e lo stato corrente senza che nessuno debba ricostruire la storia da email.

Una richiesta di audit pratica di solito inizia con un fornitore e un servizio. Da lì, l'auditor verifica se la governance è reale o solo documentata.

Cosa chiede per primo un auditor

Il primo test è di solito semplice. Riesci a mostrare una linea chiara dalla dipendenza di business alla supervisione attuale?

Questo significa evidenza di:

• Perché questo fornitore conta: Un record della criticità del servizio, della dipendenza operativa o della rilevanza regolatoria.
• Chi è responsabile: Un business owner, un control owner e un percorso di escalation nominati.
• Quali controlli si applicano: Clausole contrattuali, requisiti di due diligence, cadenza di revisione, obblighi sugli incident e qualsiasi controllo compensativo.
• Cosa è successo dopo l'approvazione: Valutazioni completate, issue registrate, decisioni documentate, remediation tracciate e stato aggiornato.


Se queste evidenze sono sparse tra inbox, drive condivisi, repository contrattuali e appunti di riunione, il problema non è la documentazione mancante. Il problema è la tracciabilità interrotta.

Un evidence pack credibile

Un buon evidence pack è chiaro, aggiornato e collegato. Gli auditor dovrebbero poterlo seguire senza indovinare quale documento sia venuto prima o se un control owner abbia esaminato il materiale del fornitore.

In pratica, questo significa di solito:

• Approved contract records: Termini di sicurezza, clausole di notifica degli incident, diritti di audit, obblighi di cooperazione, trigger di terminazione e eccezioni documentate.
• Risk assessment outputs: L'ultimo risultato di due diligence, la logica dietro la decisione sul rischio residuo e l'approvatore.
• Current assurance material: Certificazioni, attestazioni, report di controllo, questionari o dichiarazioni del fornitore, più l'evidenza che qualcuno competente li abbia esaminati.
• Issue and remediation history: Findings, scadenze, owner, rischi accettati, azioni scadute ed evidenza di chiusura.
• Operational oversight records: Note di revisione, problemi di servizio, incident record, eccezioni di performance e azioni intraprese di conseguenza.
• Testing evidence where relevant: Partecipazione del fornitore a esercitazioni di risposta, test di failover, revisioni degli accessi o convalida dei controlli.

La tracciabilità conta più del volume. L'Agenzia dell'Unione europea per la cybersicurezza ha sottolineato l'importanza della tracciabilità della supply chain e dell'assurance nella supervisione del rischio di terze parti, soprattutto quando le organizzazioni dipendono da fornitori ICT e di servizi esterni (ENISA guidance on supply chain security and assurance). Questo si allinea con ciò che gli auditor di solito chiedono nella pratica. Sanno che la visibilità completa delle fourth party è spesso incompleta. Si aspettano comunque un record difendibile che mostri come l'organizzazione abbia identificato le dipendenze materiali, definito i requisiti di revisione e mantenuto aggiornata la supervisione.

Come si presenta una cattiva evidenza

Le evidenze deboli hanno un pattern familiare. I documenti esistono, ma la storia del controllo no.

Il contratto è firmato, ma l'allegato di sicurezza manca. Il fornitore ha inviato un'attestazione, ma nessuno ha registrato una revisione. Un rischio è stato accettato, ma l'accettazione non ha data di scadenza. Un incidente è stato discusso, ma non ha mai aggiornato il record del fornitore. Un'azione di remediation è stata assegnata, ma non c'è una nota di chiusura né prova che l'owner abbia controllato il risultato.

Gli auditor possono lavorare con l'imperfezione. Hanno difficoltà con decisioni mancanti, ownership poco chiara ed evidenze che non possono essere collegate a un controllo in esercizio.

Ecco perché un audit trail for approvals, changes, and follow-up actions documentato è importante. Trasforma la supervisione dei fornitori da una raccolta di file in evidenza di governance che può essere testata, contestata e difesa.

Costruire resilienza attraverso una governance tracciabile

Il rischio della supply chain diventa gestibile quando le organizzazioni smettono di trattarlo come una raccolta di controlli puntuali sui vendor. Il modello praticabile è una governance con tracciabilità. Qualcuno definisce il perimetro. Qualcuno valuta la dipendenza. Qualcuno decide il trattamento. Qualcuno monitora se il controllo continua a operare. E tutto questo lascia evidenze.

Sembra procedurale perché lo è. La resilienza deriva da decisioni ripetibili sotto una chiara ownership, non da un linguaggio di policy impressionante. DORA e NIS2 rafforzano questo punto, ma la verità operativa resta valida anche senza di esse. Se un fornitore supporta un servizio critico, la supervisione di quel fornitore deve essere integrata nel modello di governance del servizio.

Come appare il buon funzionamento nel tempo

Le organizzazioni mature tendono a condividere alcune caratteristiche:

• Responsibilities are explicit: La ownership commerciale, la ownership tecnica e la ownership dei controlli non sono confuse tra loro.
• Evidence is attached to decisions: Revisioni, eccezioni e remediation lasciano tutte una traccia visibile.
• Monitoring uses a baseline: I team non si affidano solo ad aneddoti o rassicurazioni del vendor.
• Audits verify the system: Verificano se il processo di controllo funziona, invece di costringere a una ricostruzione dell'ultimo minuto.

Un segnale macro utile per il contesto continuo è il Global Supply Chain Pressure Index della New York Fed, un indicatore mensile multivariabile che le organizzazioni possono usare come baseline standardizzata per lo stress esterno invece di affidarsi a segnalazioni aneddotiche di disruption (New York Fed GSCPI methodology and updates). Non è un controllo a livello di fornitore, e non dovrebbe essere trattato come tale. È un input disciplinato per la revisione periodica del rischio.

La governance funziona quando puoi passare da una dichiarazione del board sulla resilienza a un record specifico del fornitore, un owner nominato, un controllo aggiornato e l'evidenza che sia stato verificato.

Questo è il cambiamento che le normative moderne stanno davvero imponendo. Non più carta. Migliore disciplina operativa. Una volta che i team lo capiscono, il rischio della supply chain smette di essere un tema astratto di conformità e diventa ciò che avrebbe sempre dovuto essere: una parte controllata della fornitura del servizio.

Se stai costruendo questo tipo di modello operativo basato su evidenze, AuditReady è progettato per questo. Aiuta i team regolamentati a organizzare controlli, responsabilità, evidenze dei fornitori e output di audit in un unico sistema tracciabile, così la readiness all'audit diventa un sottoprodotto della governance quotidiana invece che una corsa dell'ultimo minuto prima della revisione.