Un attacco informatico è riuscito a far salire fino a 50 °C la temperatura degli impianti di refrigerazione di centinaia di supermercati francesi, causando perdite per milioni. Non è stato necessario attaccare i loro sistemi finanziari né bloccare i loro server aziendali. È bastato manipolare un sistema tecnico collegato.
Questo episodio dimostra perché la sicurezza informatica non può più limitarsi a proteggere dati e computer. Deve proteggere anche i processi che permettono a un’azienda di funzionare. Ed è proprio qui che la direttiva NIS2 assume tutto il suo significato.
Cosa è successo nei supermercati francesi
Nella notte tra l’11 e il 12 ottobre 2026, un attacco informatico ha colpito i sistemi di refrigerazione di numerosi supermercati in Francia, tra cui punti vendita di Intermarché, Netto, Coopérative U ed E.Leclerc.
Gli hacker sono riusciti a manipolare da remoto i sistemi di regolazione della refrigerazione, attivando i processi di sbrinamento e facendo salire le temperature fino a 50 °C. Le conseguenze sono state immediate: alimenti freschi e surgelati resi inutilizzabili, interruzioni operative, danni agli impianti e perdite economiche che potrebbero ammontare a diversi milioni di euro.
Secondo le prime notizie, l’incidente ha colpito centinaia di locali. Le autorità francesi hanno avviato un’indagine per stabilire la portata dell’attacco, identificare i responsabili e chiarire come sia avvenuto l’accesso.
Le informazioni pubblicate indicano i sistemi di controllo della refrigerazione del produttore Danfoss e possibili vulnerabilità nelle vecchie versioni del software, ancora da confermare. Tuttavia, le indagini continuano e i dettagli tecnici e le responsabilità concrete devono ancora essere chiariti.
Nel frattempo, sono stati segnalati incidenti informatici presso le catene Albert Heijn, nei Paesi Bassi, e Delhaize, in Belgio, che fanno parte del gruppo Ahold Delhaize. Per ora non c’è alcun collegamento confermato tra questi incidenti e l’attacco in Francia.
La cosa più importante per qualsiasi azienda è che l’attacco non ha dovuto compromettere l’ERP, la contabilità o i database dei clienti. L’obiettivo erano i sistemi tecnologici che controllavano un processo fisico essenziale per l’attività.
E questo cambia il modo di concepire la sicurezza informatica.
Un esempio del perché esiste la NIS2
Quando si parla di attacchi informatici, di solito pensiamo al ransomware, al furto di informazioni, alle fughe di dati personali o ai malfunzionamenti dei siti web. Ma cosa succede quando un attacco informatico impedisce la conservazione degli alimenti, blocca una linea di produzione, mette fuori uso un impianto di climatizzazione ospedaliero o paralizza un magazzino automatizzato?
In questi casi, il problema non è più solo tecnologico. Diventa una questione di continuità operativa, sicurezza e perdite economiche.
La direttiva (UE) 2022/2555, nota come NIS2, mira proprio a rafforzare la capacità delle organizzazioni di prevenire, resistere e reagire agli incidenti che compromettono la sicurezza delle loro reti e dei loro sistemi informativi, nonché la continuità dei loro servizi.
Non sostituisce il Regolamento generale sulla protezione dei dati (RGPD), ma affronta rischi diversi e complementari. L’RGPD tutela i dati personali. La direttiva NIS2 stabilisce obblighi in materia di gestione dei rischi di sicurezza informatica e di segnalazione degli incidenti per determinati soggetti, anche in assenza di una fuga di dati personali.
Il caso francese permette di individuare tre aspetti particolarmente importanti.
1. Anche la tecnologia industriale fa parte della sicurezza informatica
I sistemi di refrigerazione, climatizzazione, controllo degli accessi, allarmi o automazione industriale fanno parte di quella che chiamiamo tecnologia operativa (OT). Sempre più spesso, queste apparecchiature sono collegate a reti informatiche e possono essere gestite da remoto.
Questo semplifica la manutenzione e permette di ottimizzare i costi, ma introduce anche nuovi punti vulnerabili.
Un’azienda può avere i propri server protetti, i dipendenti che usano l’autenticazione a più fattori e i computer aggiornati, pur mantenendo un sistema industriale accessibile da Internet con un software obsoleto.
La sicurezza dell’ambiente aziendale non garantisce automaticamente la sicurezza dei suoi sistemi operativi.
2. Anche i fornitori fanno parte del perimetro di sicurezza
Molte aziende affidano a terzi la manutenzione dei propri impianti tecnici. Il fornitore di sistemi di refrigerazione, climatizzazione o automazione può avere accesso remoto per monitorare le apparecchiature, modificare i parametri o risolvere i problemi. Questo accesso può diventare una via d’ingresso se non è adeguatamente protetto.
Non è ancora stata resa pubblica l’intera catena di accesso utilizzata nell’attacco francese. Ma l’incidente mette in luce un rischio ben noto: l’esposizione dei sistemi operativi collegati e la dipendenza da tecnologie e servizi di terze parti.
L’articolo 21, paragrafo 2, lettera d) della NIS2 impone ai soggetti soggetti alla direttiva di adottare misure relative alla sicurezza della catena di approvvigionamento, compresi gli aspetti di sicurezza dei rapporti con i propri fornitori diretti e prestatori di servizi.
Questo significa che affidarsi a una terza parte non elimina la necessità di gestire i rischi legati alla sua attività.
3. Un incidente informatico può avere conseguenze fisiche
La cosa più sorprendente di questo attacco è che un comando informatico abbia finito per distruggere la merce. Un sistema di refrigerazione deve avere dei controlli che impediscano il funzionamento al di fuori delle condizioni di sicurezza, anche quando riceve comandi errati o dannosi.
La protezione non dovrebbe dipendere esclusivamente dal software. A seconda del sistema, potrebbero essere necessarie limitazioni indipendenti, allarmi, monitoraggio della temperatura, meccanismi di disconnessione e procedure di intervento manuale.
La sicurezza informatica e la sicurezza operativa devono lavorare insieme.
La domanda non è più solo se qualcuno possa entrare nei nostri sistemi, ma cosa possa succedere concretamente se ci riesca.
Un supermercato spagnolo sarebbe obbligato a rispettare la direttiva NIS2?
A questo punto è bene fare una precisazione importante. La direttiva NIS2 include tra i suoi settori la produzione, la trasformazione e la distribuzione di alimenti, come indicato nell’Allegato II della direttiva.
Tuttavia, il suo ambito di applicazione non comprende automaticamente qualsiasi esercizio che venda prodotti alimentari. Il testo europeo si riferisce specificatamente alle aziende alimentari che si occupano di distribuzione all’ingrosso e di produzione e trasformazione industriale.
Quindi, un supermercato che si occupa esclusivamente di vendita al dettaglio non rientra in questa categoria solo per quella attività.
La situazione può essere diversa per una grande catena che svolga anche attività di distribuzione all’ingrosso, produzione o trasformazione industriale attraverso la propria struttura aziendale. In questi casi, bisognerà analizzare le attività effettive, le persone giuridiche coinvolte, le loro dimensioni e i criteri di applicazione previsti dalla normativa.
Non basta dire che un’organizzazione è grande o che ha dei centri logistici per concludere automaticamente che sia soggetta all’obbligo.
Ma c’è un altro aspetto ancora più rilevante.
La direttiva NIS2 riguarda indirettamente anche le aziende che non sono soggette a tali obblighi
Immaginiamo un’azienda con 150 dipendenti specializzata nella manutenzione dei sistemi di refrigerazione industriale. I suoi clienti sono grandi operatori logistici, industrie alimentari e catene di distribuzione. Anche se questa azienda non rientra direttamente nell’ambito di applicazione della direttiva NIS2, alcuni dei suoi clienti potrebbero invece esserne soggetti.
E questi clienti dovranno gestire i rischi di sicurezza informatica della loro catena di approvvigionamento. In pratica, potranno imporre contrattualmente requisiti come:
- Autenticazione a più fattori per gli accessi da remoto.
- Identificazione e autorizzazione dei tecnici che intervengono.
- Gestione delle vulnerabilità e degli aggiornamenti.
- Registrazione degli accessi e delle operazioni.
- Procedure di segnalazione degli incidenti.
- Valutazioni periodiche della sicurezza.
- Documentazione delle misure adottate.
Il risultato è che NIS2 si estende, dal punto di vista commerciale, anche alle organizzazioni che non sono direttamente soggette alla direttiva.
Non perché tutte si assumano automaticamente gli stessi obblighi legali, ma perché i loro clienti hanno bisogno di garanzie per adempiere ai propri. Questa è una delle trasformazioni più importanti che la NIS2 introduce nei rapporti tra aziende.
NIS2 in Spagna: aspettare che la legge entri in vigore non elimina il rischio
Il termine europeo per il recepimento della direttiva NIS2 è scaduto il 17 ottobre 2024.
L’8 luglio 2026, la Commissione Europea ha annunciato la decisione di portare Spagna, Francia, Irlanda e Paesi Bassi davanti alla Corte di giustizia dell’Unione Europea per non aver notificato il completo recepimento della direttiva.
In Spagna, a gennaio 2025 il governo ha approvato il progetto di legge sul coordinamento e la governance della sicurezza informatica, volto a integrare la NIS2 nell’ordinamento giuridico nazionale.
Alla data di questo articolo, il recepimento non è ancora stato completato.
Questo non significa che la NIS2 possa essere applicata integralmente a qualsiasi azienda privata spagnola come se ci fosse già una legge di recepimento in vigore. Gli obblighi direttamente esigibili vanno analizzati in base al quadro giuridico applicabile, comprese le norme sulla sicurezza informatica già in vigore e gli impegni contrattuali.
Ma questo non vuol dire che le aziende debbano stare con le mani in mano. Ci sono tre motivi per iniziare a prepararsi.
Primo: i clienti stanno già imponendo requisiti di sicurezza ai propri fornitori.
Un’organizzazione che deve gestire la propria catena di fornitura deve conoscere i rischi legati ai servizi che acquista.
Secondo: adattarsi richiede tempo.
Fare l’inventario delle risorse, valutare i fornitori, controllare gli accessi remoti, implementare controlli, definire procedure e formare il personale sono attività che non si risolvono in poche settimane.
Aspettare la pubblicazione definitiva della legge può trasformare un adeguamento pianificato in un progetto urgente e costoso.
Terzo: gli attacchi informatici non aspettano la pubblicazione nella Gazzetta Ufficiale.
I rischi che la NIS2 mira a ridurre esistono già. L’attacco ai supermercati francesi ne è un esempio delle conseguenze.
La mancanza di un recepimento completo non impedisce a un’azienda di subire domani un incidente simile.
Tre lezioni pratiche per qualsiasi azienda
Dal caso francese si possono trarre tre insegnamenti validi sia per le organizzazioni soggette alla normativa NIS2 sia per quelle che vogliono migliorare la propria capacità di prevenzione e risposta.
Lezione 1. Anche i tuoi fornitori con accesso remoto fanno parte del tuo perimetro
Un’azienda può avere una politica di sicurezza dei fornitori redatta alla perfezione e, allo stesso tempo, non sapere quante aziende esterne possano connettersi alle sue infrastrutture.
Pensiamo a una fabbrica. Il fornitore dei macchinari accede da remoto per effettuare delle regolazioni. Il tecnico della climatizzazione controlla gli impianti. Il tecnico addetto agli allarmi può modificare le impostazioni e un altro fornitore gestisce i sistemi di controllo degli accessi.
Ognuna di queste connessioni rappresenta una dipendenza e un potenziale rischio.
L’organizzazione dovrebbe essere in grado di rispondere, per ogni fornitore, a cinque domande:
- Chi ha l’autorizzazione per accedervi?
- A quali sistemi puoi collegarti?
- Che tipo di autenticazione usa?
- Quando ha effettuato l’ultimo accesso e cosa ha fatto?
- Chi può sospendere o revocare quell’accesso?
Non basta avere un elenco di fornitori approvati.
Bisogna identificare gli accessi, valutarne la criticità, stabilire le condizioni di sicurezza e rivedere periodicamente le autorizzazioni.
Per gli accessi a più alto rischio, è consigliabile integrare l’autenticazione a più fattori, i privilegi minimi, i registri delle attività, gli accessi temporanei e i meccanismi di revoca immediata.
Una politica sui fornitori descrive come dovrebbe funzionare il controllo. Le prove relative agli accessi dimostrano se funziona davvero.
Lezione 2. Se non è nell’inventario, difficilmente sarà protetto
Molte organizzazioni tengono un inventario di computer, server, applicazioni e licenze. Ma includono anche le loro celle frigorifere connesse, i sistemi di climatizzazione, i controllori industriali, i sensori, i dispositivi di accesso o le apparecchiature per la manutenzione remota?
Spesso queste risorse dipendono da reparti diversi dall’informatica: manutenzione, operazioni, produzione o servizi generali.
Il risultato potrebbe essere una visione incompleta della superficie di attacco. Il primo passo è identificare le risorse tecnologiche coinvolte nei processi critici dell’azienda.
Poi bisogna analizzare:
- Che funzione svolgono e che impatto avrebbe la loro indisponibilità.
- Quali connessioni hanno con altre reti e sistemi.
- Quali fornitori possono gestirli.
- Quali vulnerabilità e dipendenze presentano.
- Quali controlli esistono per limitarne le conseguenze.
Nei sistemi OT, inoltre, è particolarmente importante valutare la segmentazione delle reti e i meccanismi di protezione indipendenti.
Non tutte le apparecchiature possono essere aggiornate o protette allo stesso modo di un computer tradizionale. Per questo le misure devono adattarsi alle loro caratteristiche tecniche e operative.
Nel caso di una cella frigorifera, ad esempio, dovrebbero esserci meccanismi che permettano di rilevare temperature anomale, generare allarmi e limitare le situazioni pericolose, senza dipendere esclusivamente dal controller che potrebbe essere compromesso.
L’inventario delle risorse non è una semplice formalità burocratica. È il punto di partenza per capire cosa ha bisogno di protezione e perché.
Lezione 3. Quando si verifica un incidente, il tempo stringe
Una delle novità più note della NIS2 è il suo sistema di segnalazione degli incidenti significativi.
L’articolo 23 stabilisce, per i soggetti obbligati e gli incidenti che soddisfano i criteri di notifica, una procedura a più livelli.
| Scadenza | Intervento |
|---|---|
| 24 ore | Allerta tempestiva non appena si viene a conoscenza dell’incidente rilevante. |
| 72 ore | Notifica con una valutazione iniziale, gravità, impatto e indicatori disponibili. |
| 1 mese | Rapporto finale, con la descrizione dell’incidente, le cause probabili, le misure adottate e l’impatto. |
Il termine per la presentazione della relazione finale viene calcolato, in linea di massima, a partire dalla presentazione della notifica entro 72 ore. La direttiva prevede anche relazioni intermedie e casi in cui l’indagine rimane aperta.
Non tutti gli incidenti devono essere segnalati secondo questa procedura. Bisogna verificare se soddisfano i criteri di incidente significativo e attenersi alle norme applicabili.
Ma il problema operativo principale si presenta prima ancora di inviare qualsiasi notifica. Chi individua l’incidente? Chi ne valuta la gravità? Chi decide se va segnalato? Chi raccoglie le informazioni? Chi conserva le prove?
Se queste responsabilità non sono state definite in anticipo, le prime ore potrebbero andare perse nel tentativo di organizzare la risposta.
L’organizzazione ha bisogno di una procedura che permetta di registrare l’incidente, classificarlo, assegnare i responsabili, controllare le scadenze, documentare le decisioni e conservare le prove.
E la responsabilità non ricade esclusivamente sul reparto informatico.
L’articolo 20 della NIS2 richiede che gli organi direttivi delle entità soggette approvino le misure di gestione dei rischi di sicurezza informatica, ne supervisionino l’attuazione e ricevano una formazione adeguata.
La sicurezza informatica non è più solo una questione tecnica, ma diventa anche una responsabilità di governance aziendale.
Checklist: la tua azienda sarebbe pronta per un incidente simile?
Queste sei domande ti permettono di fare una prima valutazione del livello di preparazione di un’organizzazione.
- Fornitori: sappiamo quali fornitori hanno accesso remoto ai nostri sistemi e quali autorizzazioni ha ciascuno di loro?
- Valutazione: Abbiamo valutato i rischi di sicurezza informatica dei nostri fornitori critici negli ultimi 12 mesi?
- Risorse: il nostro inventario include sistemi OT e IoT, oltre a server, applicazioni e computer?
- Incidenti: Abbiamo una procedura che preveda scadenze di 24 ore, 72 ore e un mese, quando applicabili?
- Direzione: La direzione ha approvato le misure di gestione dei rischi e ne supervisiona l’applicazione?
- Continuità: sappiamo come mantenere o ripristinare i nostri processi fisici critici se uno dei nostri sistemi tecnologici dovesse smettere di funzionare?
Non si tratta di ottenere sei risposte affermative in un questionario. L’importante è riuscire a dimostrare ogni risposta con informazioni aggiornate, responsabili identificati e prove verificabili.
Perché un’azienda può dire di controllare gli accessi dei propri fornitori, ma non avere un registro che permetta di sapere chi si è collegato a un sistema nelle prime ore del mattino.
E questa differenza può rivelarsi decisiva quando si verifica un incidente.
Dalla conformità documentale alla conformità operativa
L’attacco ai supermercati francesi dimostra che i rischi legati alla sicurezza informatica possono concretizzarsi ben lontano dai tradizionali sistemi informatici. Una cella frigorifera, un controllore industriale o un accesso remoto per la manutenzione possono diventare il punto di partenza di un incidente con gravi conseguenze economiche e operative.
La direttiva NIS2 stabilisce un quadro per gestire questi rischi, ma il solo fatto di avere politiche e procedure non garantisce che funzionino davvero. La differenza sta nell’attuazione.
Non è la stessa cosa avere una politica di valutazione dei fornitori e sapere quali sono stati valutati, quando, con quale risultato e quali misure correttive sono ancora in sospeso. Non è la stessa cosa avere un inventario delle risorse e sapere quali sistemi critici dipendono da un fornitore esterno e quali controlli sono stati implementati.
E non è la stessa cosa avere una procedura per gli incidenti e riuscire a dimostrare quando ne è stato individuato uno, chi ha preso ogni decisione e se sono state rispettate le scadenze previste.
La differenza tra la conformità documentale e quella operativa sta nel passare dal dire che siamo conformi al poter dimostrare come lo siamo.
Come può aiutarti Ithikios
Noi di Ithikios lavoriamo per aiutare le organizzazioni a gestire i propri obblighi di compliance attraverso processi ben definiti, responsabili identificati e prove verificabili.
Il nostro approccio permette di collegare diverse attività che tradizionalmente vengono gestite in modo isolato:
- Third Party Manager: certificazione, valutazione e monitoraggio dei fornitori, compresi i rischi legati ai fornitori critici.
- Responsabile dei rischi: identificazione e valutazione dei rischi, mettendoli in relazione con le risorse, le minacce e le misure di trattamento.
- Responsabile dei controlli: gestione dei controlli, dei responsabili, delle attività e delle prove, con riferimenti a standard come NIS2, ISO 27001 ed ENS.
- Responsabile degli incidenti: registrazione, classificazione e monitoraggio degli incidenti, con assegnazione dei responsabili, delle scadenze e della tracciabilità degli interventi.
Queste funzionalità aiutano a organizzare e dimostrare la gestione della conformità, anche se non sostituiscono le soluzioni tecniche di sicurezza informatica né i meccanismi specifici per la continuità operativa. L’obiettivo è che le misure di sicurezza non rimangano solo sulla carta, ma diventino parte integrante del funzionamento quotidiano dell’organizzazione.
Perché, dopo un incidente, la domanda importante non sarà solo se ci fosse una politica di sicurezza. Sarà piuttosto se qualcuno sapeva chi poteva accedere al sistema, quali controlli erano stati applicati e cosa è successo esattamente alle tre del mattino.
Ecco cos’è la conformità operativa: persone responsabili, processi ben definiti e prove concrete di ciò che viene effettivamente fatto.
Scopri come gestire la conformità a NIS2, ISO 27001 ed ENS con Ithikios: https://ithikios.com/compliance/
* Articolo migliorato con l’IA
