Gestione del rischio dei fornitori di terze parti: cosa ci insegna il caso Danfoss?

Dall'illusione del perimetro alla vulnerabilità riflessa

Nell’ottobre 2026, il cosiddetto “caso Danfoss” ha mostrato con particolare evidenza come una vulnerabilità nella supply chain digitale possa produrre conseguenze immediate anche sulle infrastrutture fisiche. Nella notte tra l’11 e il 12 ottobre, un attacco informatico ha colpito i sistemi di controllo remoto utilizzati per gestire gli impianti di refrigerazione di centinaia di supermercati francesi. Gli aggressori avrebbero alterato i parametri dei controller associati a soluzioni Danfoss, intervenendo sui cicli automatici di sbrinamento e sulle temperature operative dei banchi frigoriferi.

Invece di limitarsi a interrompere il servizio, gli attaccanti avrebbero riprogrammato il funzionamento degli apparati: la temperatura limite di sbrinamento sarebbe stata innalzata fino a valori compresi tra 35 e 50 °C, la durata del ciclo estesa fino a otto ore e il riavvio dei compressori inibito. Il risultato è stato il deterioramento di carne, pesce, latticini e surgelati, con gravi perdite economiche e, in alcuni punti vendita, segnalazioni di surriscaldamento. Tra le catene coinvolte sarebbero figurate Intermarché, Netto, Carrefour, Carrefour Market, Coopérative U, E.Leclerc e Monoprix.

L’intrusione avrebbe interessato soprattutto controller esposti a Internet e dotati di versioni software obsolete o non aggiornate, incluse release precedenti alla versione 4; nelle ore successive sarebbero emerse segnalazioni analoghe relative anche a dispositivi di un altro produttore. L’episodio rende concreto il concetto di vulnerabilità riflessa: la debolezza di un componente o di un fornitore tecnologico si trasferisce direttamente alle organizzazioni che lo utilizzano, fino a compromettere continuità operativa, sicurezza fisica e disponibilità dei beni.

L’assenza di una richiesta di riscatto ha inoltre alimentato l’ipotesi di un’azione orientata al sabotaggio più che al profitto, ma attribuzioni e finalità restano da trattare con cautela finché non supportate da conclusioni ufficiali. Il caso conferma che inventario degli asset, aggiornamento tempestivo, segmentazione delle reti, controllo degli accessi remoti e monitoraggio continuo dei fornitori non sono più misure accessorie, ma requisiti essenziali di governance del rischio di terze parti.

Il cambio di paradigma normativo tra NIS2, DORA e ACN

L'evoluzione del quadro normativo dell'Unione Europea esprime chiaramente il principio per cui la sicurezza informatica di un'organizzazione non si esaurisce nei suoi sistemi interni. La Direttiva NIS2 (Direttiva UE 2022/2555), recepita in Italia con il Decreto Legislativo 4 settembre 2024, n. 138, include esplicitamente all'articolo 21 la sicurezza della catena di approvvigionamento tra le misure minime ed essenziali di gestione del rischio.

La norma impone ai soggetti essenziali e importanti di valutare le vulnerabilità specifiche di ciascun fornitore diretto, la qualità complessiva dei prodotti e le pratiche di cybersecurity adottate, con particolare attenzione alle procedure di sviluppo sicuro del software e alle valutazioni coordinate del rischio condotte a livello europeo ai sensi dell'articolo 22.

In modo complementare, il Regolamento DORA (Regolamento UE 2022/2554), applicabile dal 17 gennaio 2025 al settore finanziario, stabilisce all'articolo 28 che le entità finanziarie mantengono la piena responsabilità del rispetto degli obblighi di legge anche quando esternalizzano servizi TIC. DORA impone l'adozione di una strategia specifica di gestione del rischio TIC di terze parti, la tenuta di un registro delle informazioni per tutti i contratti attivi, la condotta di due diligence precontrattuali rigorose, la valutazione dei rischi di concentrazione e la predisposizione di strategie di uscita documentate e testate per le funzioni critiche o importanti.

L'articolo 30 di DORA fissa inoltre le clausole contrattuali minime obbligatorie, che vanno dalla descrizione dettagliata dei livelli di servizio (SLA) alla localizzazione esatta dei dati, fino ai diritti di ispezione on-site e alla partecipazione obbligatoria a test di resilienza operativa avanzati (Threat-Led Penetration Testing o TLPT).

La differente natura dei due testi riflette un approccio bilanciato: NIS2 ragiona in termini di proporzionalità e responsabilità basata sul rischio, mentre DORA fissa regole altamente prescrittive e uniformi, introducendo altresì un potere di vigilanza diretta delle autorità europee sui fornitori TIC considerati 'critici'. In Italia, l'Agenzia per la Cybersicurezza Nazionale (ACN) ha ulteriormente concretizzato tali principi stabilendo che i soggetti NIS censiscano e dichiarino annualmente tramite la piattaforma ACN i propri 'fornitori rilevanti', indicandone codice fiscale, sede legale e classificazione degli acquisti.

La novità più rilevante risiede nel regime sanzionatorio e di governance. La conformità non può più essere delegata alle sole funzioni IT o alla sicurezza informatica. Sotto la Direttiva NIS2, le sanzioni pecuniarie per le entità essenziali possono raggiungere i 10 milioni di euro o il 2% del fatturato globale. Inoltre, sia NIS2 sia DORA stabiliscono la responsabilità diretta e personale degli organi di gestione e dei consigli di amministrazione, prevedendo per i dirigenti la possibilità di sanzioni amministrative dirette e la sospensione temporanea dalle funzioni dirigenziali in caso di inosservanza degli obblighi della catena di fornitura.

Mappatura e due diligence tecnica: metodologia e valutazione

Il primo ostacolo operativo nell'implementazione di un programma TPRM (Third-Party Risk Management ) consiste nell'assenza di una visione unificata dei fornitori. Spesso i registri del procurement, i fogli di calcolo del team di sicurezza, gli archivi dei responsabili di business unit e i registri dei trattamenti GDPR non coincidono tra loro. Il punto di partenza imprescindibile è la costruzione di un inventario unico e dinamico, capace di collegare ogni fornitore al servizio erogato, ai sistemi e ai dati toccati, al livello di privilegio concesso, alla criticità del processo aziendale e ai tempi effettivi di sostituzione.

Una volta mappato, il portafoglio dei fornitori deve essere sottoposto a un processo di triage e categorizzazione. Un fornitore di servizi di pulizia solleva interrogativi legati alla sicurezza fisica, mentre un cloud provider che ospita database aziendali o una software house che sviluppa codice integrato nei sistemi di autenticazione richiedono un livello di scrutinio rigoroso.

La classificazione deve basarsi su parametri oggettivi: sensibilità dei dati trattati, profondità degli accessi logici, presenza di subfornitori, localizzazione geografica e rischio di concentrazione derivante dalla dipendenza da un unico provider.

Per i fornitori collocati nei livelli di criticità più elevati, l'approccio puramente documentale basato su questionari autocompilati mostra evidenti limiti. I questionari restano utili per comprendere le linee di governance, ma devono essere integrati da verifiche empiriche e multi-sorgente:

• Strumenti di Cybersecurity Rating: analisi della superficie di attacco esterna attraverso la valutazione di configurazioni DNS, certificati SSL, vulnerabilità visibili, credenziali esposte e menzioni nel dark web

• Standard e certificazioni internazionali: verifica della conformità ISO/IEC 27001 e soprattutto esame dei report SOC 2 Type II, indispensabili per attestare non solo la progettazione dei controlli, ma la loro effettiva efficacia operativa lungo un periodo prolungato

• Penetration test e sviluppo sicuro: esame dei report di Penetration Test recenti condotti da terze parti indipendenti, analisi delle procedure di sviluppo sicuro del codice (Secure Software Development Lifecycle) e valutazione dei piani di continuità operativa e disaster recovery

• Audit tecnici dedicati: esecuzione di audit approfonditi o verifiche ispettive on-site nei casi caratterizzati da massimo impatto operativo e strategico.

Infine, le valutazioni devono integrare l'analisi del rischio geopolitico e di sovranità. L'elaborazione o la conservazione di dati in Paesi soggetti a legislazioni invasive, ingerenze governative o restrizioni all'esportazione tecnologica introduce vulnerabilità strategiche che NIS2 e DORA impongono di considerare formalmente nei processi di valutazione.

L'architettura contrattuale: tradurre la sicurezza in clausole vincolanti

La valutazione del rischio definisce la postura del fornitore, ma è il contratto lo strumento giuridico che trasforma i requisiti tecnici e normativi in vincoli operativi azionabili. Le clausole generiche di 'adeguata diligenza' o di 'conformità alle best practice' non offrono alcuna tutela reale. L'architettura contrattuale moderna si articola attraverso Cybersecurity Addendum o Data Protection and Security Agreement (DPSA) allegati al contratto principale.

Per soddisfare le prescrizioni di NIS2 e DORA, la struttura contrattuale deve contemplare specifici pilastri inderogabili:

• Diritti di audit e ispezione: la facoltà per il committente e per le autorità competenti di svolgere verifiche documentali, ispezioni on-site e scansioni tecniche, con il contestuale obbligo di cooperazione a carico del fornitore

• Gestione e notifica degli incidenti: l'obbligo di comunicare qualsiasi incidente informatico, anche solo potenziale, entro finestre temporali estremamente stringenti (allineate alle 24 o 72 ore previste dai quadri normativi e dall'ACN), fornendo dettagli sulla natura dell'evento e sulle contromisure adottate

• Gestione della catena di sub-fornitura (Quarte Parti): l'obbligo di ribaltare a cascata (flow-down) i medesimi requisiti di sicurezza lungo tutta la catena dei subfornitori, associato al divieto di ricorrere al subappalto di funzioni critiche senza la preventiva autorizzazione scritta del committente

• Strategie di uscita (Exit Strategy): clausole strutturate che garantiscano la restituzione o la distruzione certificata dei dati aziendali, prevedendo un periodo di transizione ordinato durante il quale il fornitore uscente continua ad erogare il servizio per evitare interruzioni dell'operatività (lock-in)

• Meccanismi dinamici e di rimedio: l'inserimento di clausole di aggiornamento automatico dei controlli a fronte dell'evoluzione delle minacce, diritti di revisione periodica e la facoltà di sospensione o risoluzione immediata del contratto in caso di grave degrado della postura di sicurezza del fornitore.

Durante le trattative commerciali, i grandi provider di servizi cloud o software gestiti oppongono spesso resistenza rispetto a diritti di audit on-site illimitati o tempistiche di notifica personalizzate. Il superamento di tali stalli richiede l'adozione di soluzioni calibrate: l'accettazione di report di audit indipendenti di terza parte, il ricorso a framework contrattuali di settore e l'adozione di piattaforme collaborative di TPRM per lo scambio standardizzato delle evidenze di sicurezza.

Monitoraggio continuo, cultura aziendale e sfide aperte

La firma del contratto non esaurisce la gestione del rischio. Poiché la postura di sicurezza di un fornitore varia nel tempo, il monitoraggio continuo rappresenta la fase operativa fondamentale.

Non essendo sostenibile effettuare audit continui su ogni partner, le organizzazioni devono adottare scorecard periodiche alimentate da indicatori esterni (nuove vulnerabilità zero-day, data breach pubblici, mutamenti negli assetti societari) e procedere alla revisione costante dei diritti di accesso aziendali, con un focus specifico sulle identità non umane quali chiavi API, token e account di servizio.

Nonostante i progressi metodologici, il TPRM presenta complessità aperte che la governance aziendale deve gestire con equilibrio:

• Bilanciamento dei diritti: armonizzare il diritto di audit del committente con la tutela del segreto industriale e della riservatezza del fornitore

• Giurisdizioni extra-UE: gestire i fornitori con sede fuori dall'Unione Europea operanti in contesti normativi privi di accesso diretto per le autorità di vigilanza europee

• Sostenibilità per le PMI: prevenire l'affaticamento da audit per le piccole e medie imprese fornitrici, evitando il paralizzante sovraccarico burocratico causato dalla moltiplicazione di questionari

• Qualità del software: misurare in modo oggettivo la reale qualità dello sviluppo sicuro del software senza gravare eccessivamente sui costi e sui tempi di rilascio.

Affrontare queste sfide richiede un cambio culturale. La gestione del rischio di terze parti ha superato la dimensione del mero adempimento di conformità per integrarsi direttamente nel cruscotto di governance del consiglio di amministrazione.

Le organizzazioni capaci di strutturare un programma TPRM solido riducono l'esposizione agli attacchi, accelerano i tempi di risposta in caso di crisi e trasformano il rispetto delle norme in un distintivo di affidabilità e in un concreto vantaggio competitivo sul mercato.

Quadro comparativo delle strategie di gestione del rischio di terze parti

La seguente tabella riassume e confronta le principali fasi del ciclo di vita del TPRM, sintetizzando gli aspetti tecnici, i riferimenti normativi europei e gli strumenti contrattuali correlati:

Luca Bonora Cybersecurity Evangelist, Cyberoo

Cybersecurity Evangelist, CYBEROO

LinkedIn