Quando un attacco informatico provoca danni fisici, chi paga? Il quadro normativo europeo definisce obblighi e sanzioni amministrative, ma lascia irrisolta la domanda più importante.
Indice degli argomenti
Cosa dicono i dati
Le infrastrutture critiche europee corrono su architetture fragili. Il report Dragos 2026, pubblicato a febbraio, documenta un passaggio di fase che merita attenzione: gli attaccanti non si limitano più a pre-posizionarsi nelle reti OT, stanno mappando attivamente i loop di controllo, comprendendo come i comandi si originano, si propagano e dove possono essere indotti effetti fisici. Nel 2025 Dragos ha tracciato 119 gruppi ransomware che hanno colpito 3.300 organizzazioni industriali, con un aumento del 49% rispetto all’anno precedente. Il manifatturiero rappresenta oltre due terzi delle vittime. Solo il 46% delle valutazioni ha riscontrato un monitoraggio della rete OT adeguato. Il tempo medio di permanenza in ambienti OT è di 42 giorni.
L’ENISA Threat Landscape 2025, basato sull’analisi di quasi 4.900 incidenti, conferma la tendenza: per la prima volta le minacce alla tecnologia operativa rappresentano il 18,2% di tutte le categorie di minaccia identificate. L’Italia è lo Stato membro più frequentemente attaccato in ambito OT, seguita da Repubblica Ceca, Francia e Spagna. A giugno 2025 un gruppo denominato Infrastructure Destruction Squad ha compromesso con successo un’azienda italiana di automazione per edifici intelligenti, dimostrando la viabilità operativa di malware ICS specifico come VoltRuptor. L’ENISA NIS360 2026, pubblicato a maggio, segnala che molti sistemi OT sono sistemi legacy non progettati con la cybersecurity in mente, spesso vincolati a contratti di manutenzione pluridecennali che ne impediscono l’adeguamento completo agli standard di sicurezza evolutivi.
Il nodo dei sistemi
Il paradosso è strutturale, i sistemi di controllo industriale utilizzano protocolli come Modbus/TCP e DNP3 progettati per disponibilità e determinismo, non per autenticazione o crittografia. Un DCS in esecuzione su un sistema operativo proprietario di vent’anni fa non può essere patchato su base trimestrale. Un Safety Instrumented System che controlla un reattore ad alta pressione non può ospitare un agente di endpoint detection e molti di questi sistemi richiedono contratti di manutenzione decennali, rendendo la compliance evolutiva un problema ingegneristico prima ancora che regolatorio.
Un dato Dragos particolarmente rilevante per il ragionamento che segue: il 25% delle vulnerabilità ICS-CERT e NVD aveva punteggi CVSS errati nel 2025, e il 26% degli advisory non conteneva patch o mitigazione da parte dei vendor. Gli operatori ricevono guidance incompleta o sbagliata, il che pone un problema enorme non solo sul piano della sicurezza, ma su quello della diligenza e della responsabilità.
Il quadro normativo tra NIS2 e recepimento italiano
Con il D.Lgs. 4 settembre 2024 n. 138, l’Italia ha recepito la Direttiva NIS2, sostituendo il precedente impianto del 2018. L’elenco nazionale ha individuato oltre 20.000 organizzazioni, di cui più di 5.000 classificate come essenziali. I controlli ispettivi iniziano a ottobre 2026.
La novità più significativa è la responsabilizzazione del vertice. L’articolo 23 del decreto stabilisce che gli organi di amministrazione e gli organi direttivi approvino le modalità di implementazione delle misure di gestione del rischio, ne vigilino l’attuazione e rispondano delle violazioni. La cybersicurezza cessa di essere una questione delegabile alla sola funzione IT e diventa materia di responsabilità personale e non delegabile dei vertici aziendali. La formazione dei componenti degli organi di governo è un obbligo di legge verificabile in sede ispettiva.
Le sanzioni sono severe: per i soggetti essenziali, fino a 10 milioni di euro o al 2% del fatturato annuo mondiale, con la possibilità di interdizione dalle funzioni dirigenziali. Per i soggetti importanti, fino a 7 milioni di euro o all’1,4% del fatturato.
Sul piano dell’architettura istituzionale italiana, l’art. 33 del D.Lgs. 138/2024 coordina il regime NIS2 con il Perimetro di Sicurezza Nazionale Cibernetica (PSNC). Per i soggetti inclusi in entrambi i regimi, gli obblighi di gestione del rischio del PSNC sono considerati almeno equivalenti a quelli della NIS2, e una notifica incidente ai sensi del Perimetro può assolvere gli obblighi NIS2. Il PSNC tutela la sicurezza nazionale, la NIS2 la resilienza cyber del mercato; le due discipline producono impatti su settori di attività affini e in alcuni casi identici.
Tutto questo, governance, obblighi, sanzioni, riguarda però il rapporto tra l’organizzazione e l’autorità di vigilanza. Il quadro è amministrativo. Ed è qui che si apre il buco nero.
Vulnerabilità OT e NIS2: cosa succede quando il danno è fisico
Immaginiamo uno scenario che non è più teorico, un attacco compromette il sistema SCADA di un impianto chimico, altera i parametri di processo, causa un rilascio di sostanze tossiche o un’esplosione. Persone ferite, ambiente contaminato, comunità evacuata.
Chi paga i danni?
La NIS2 e il D.Lgs. 138/2024 prevedono sanzioni amministrative per l’operatore inadempiente. Ma le sanzioni amministrative non risarciscono le vittime. Per il risarcimento bisogna guardare altrove, alla responsabilità civile, e qui il quadro diventa opaco.
Il primo problema è la molteplicità dei soggetti potenzialmente responsabili lungo la supply chain OT. L’operatore è il soggetto NIS2, ma la vulnerabilità sfruttata potrebbe risiedere nel firmware di un PLC prodotto da un vendor, nell’architettura di rete progettata da un system integrator, nella mancata rilevazione di un Managed Security Service Provider, o nel mancato rilascio di una patch. Chi ha causato il danno?
Nel diritto civile italiano, la responsabilità extracontrattuale è disciplinata dall’art. 2043 c.c. e richiede tre presupposti: un danno ingiusto, la colpa o il dolo dell’agente e un nesso di causalità tra fatto e danno. In un attacco OT multi-stadio, dove un initial access broker sfrutta una vulnerabilità Ivanti, consegna il foothold a un secondo gruppo che si muove lateralmente, e un terzo gruppo manipola i comandi del processo fisico, la dimostrazione del nesso causale è un esercizio di notevole complessità.
L’attaccante è quasi sempre non identificabile o non raggiungibile giurisdizionalmente. La catena causale coinvolge più soggetti con omissioni diverse e potenzialmente concorrenti. La colpa specifica potrebbe configurarsi per la violazione degli obblighi NIS2, ma la NIS2 non è stata progettata come fonte di obblighi civilistici, è una normativa di sicurezza pubblica, non un regime di responsabilità.
Tutto ciò non è una ipotesi accademica, lo dimostra l’incidente Jaguar Land Rover dell’agosto 2025: quello che è iniziato come una compromissione IT ha portato a uno shutdown precauzionale dei sistemi produttivi, fermando gli stabilimenti UK per circa sei settimane, con un impatto finanziario stimato in 1,9 miliardi di sterline e oltre 5.000 organizzazioni colpite nella supply chain. La domanda su chi debba assorbire il costo è ancora aperta.
Su questo terreno incerto si inserisce un elemento normativo che potrebbe cambiare radicalmente la geometria della responsabilità.
La Direttiva prodotti difettosi e il software come prodotto
La Direttiva (UE) 2024/2853, adottata il 23 ottobre 2024, sostituisce la storica direttiva del 1985 e deve essere recepita dagli Stati membri entro il 9 dicembre 2026, la stessa finestra temporale in cui diventano pienamente operative le ispezioni NIS2. La sovrapposizione delle scadenze amplifica l’urgenza operativa.
Il cambiamento fondamentale è nell’estensione della definizione di prodotto: il software, embedded, stand-alone, o fornito come servizio, è ora esplicitamente incluso e soggetto allo stesso regime di responsabilità oggettiva (senza colpa) dei beni fisici tradizionali. I sistemi di intelligenza artificiale, i file di produzione digitale, il firmware rientrano tutti nel perimetro.
I tre profili di importanza
Per il contesto OT questo è dirompente sotto almeno tre profili.
Primo, i produttori possono essere responsabili per danni derivanti da aggiornamenti software mancanti o insufficienti, o da protezione cybersecurity debole dei prodotti. Il software può rimanere sotto il controllo del fabbricante anche dopo l’immissione sul mercato: finché il produttore ha la capacità di assicurare che il software sia privo di difetti e cybersicuro mediante aggiornamenti, ha l’obbligo di farlo.
Secondo, la direttiva alleggerisce l’onere della prova per l’attore, stabilendo una presunzione di difettosità e di nesso causale quando la prova è eccessivamente difficile a causa della complessità tecnica o scientifica del prodotto. Un sistema SCADA compromesso attraverso una vulnerabilità nota e non patchata rientra pienamente in questa fattispecie.
Terzo, i giudici possono obbligare i convenuti a divulgare prove rilevanti in loro possesso, documentazione tecnica, log, codice sorgente, invertendo l’asimmetria informativa che oggi rende quasi impossibili le azioni risarcitorie contro i vendor OT. Su questo fronte la Direttiva è concepita come complementare al Cyber Resilience Act (Regolamento 2024/2847), che impone obblighi di sicurezza by design, richiede ai produttori di fornire Software Bill of Materials (SBOM) e di gestire le vulnerabilità durante l’intero ciclo di vita del prodotto. Un prodotto può essere considerato difettoso quando non soddisfa i requisiti di cybersecurity rilevanti per la sicurezza: la mancata conformità al CRA potrebbe quindi costituire, nella logica della nuova Direttiva Prodotti Difettosi, un indicatore di difettosità, creando un effetto a cascata tra i due regimi.
C’è poi un’assenza significativa: la Commissione europea ha ritirato nel febbraio 2025 la proposta di Direttiva AI Liability, che avrebbe armonizzato le regole di responsabilità civile per i danni causati dall’intelligenza artificiale. Il ritiro, divenuto formale con la pubblicazione in Gazzetta Ufficiale dell’UE il 6 ottobre 2025, lascia un vuoto: l’Europa ha regole rigorose per lo sviluppo e l’uso dell’AI, l’AI Act, ma nessuna regola armonizzata per quando questi sistemi causano danni. Le richieste di risarcimento fondate sulla colpa ricadono sul diritto nazionale di ciascuno Stato membro, con la frammentazione che ne consegue.
I nodi giuridici ancora aperti sulla responsabilità civile cyber
Il risultato è un quadro normativo in cui coesistono tre regimi con logiche diverse, nessuno dei quali copre interamente lo scenario del danno fisico da attacco OT.
Il primo nodo è lo standard di diligenza. IEC 62443 è il framework internazionale per la cybersecurity dei sistemi di automazione e controllo industriale, esplicitamente indicato da ENISA come meccanismo appropriato per dimostrare la compliance all’art. 21 della NIS2 in ambienti OT. Ma non c’è ancora un’indicazione chiara nel diritto civile italiano su cosa costituisca la diligenza adeguata dell’operatore di infrastruttura critica rispetto al rischio cyber-fisico. La violazione della NIS2 potrebbe essere utilizzata come indicatore di colpa in un giudizio civile, è probabile, ma non è certo.
Il secondo nodo è il concorso di responsabilità. In uno scenario con operatore, integratore e vendor, l’art. 2055 c.c. prevede la responsabilità solidale quando il fatto dannoso è imputabile a più persone. Ma l’allocazione interna delle responsabilità, chi ha causato cosa, in quale misura, diventa un contenzioso nel contenzioso, con perizie tecniche estremamente complesse e costose.
Il terzo nodo è il ponte tra responsabilità amministrativa e civile. L’art. 23 del D.Lgs. 138/2024 e l’art. 2086 c.c., che impone ai vertici delle organizzazioni di dotare l’impresa di assetti adeguati, creano un collegamento: in presenza di un incidente cyber con danni patrimoniali rilevanti, soci e creditori sociali potrebbero agire in responsabilità nei confronti degli amministratori che non hanno adottato le misure richieste dalla normativa. La sanzione NIS2 diventa, in questo scenario, non solo una multa, ma la prova della colpa.
Cinque raccomandazioni operative per la supply chain OT
Mappare la supply chain OT
La prima raccomandazione riguarda la mappatura della supply chain OT. Identificare tutti gli attori, vendor di PLC e SCADA, system integrator, MSSP, cloud provider, fornitori di manutenzione remota, documentare formalmente i flussi di responsabilità per la sicurezza di ciascun componente.
Rafforzare le clausole contrattuali
La seconda riguarda le clausole contrattuali. I contratti con integratori e MSSP contengono spesso cap di responsabilità molto bassi rispetto ai danni potenziali di un incidente OT. È necessario inserire obblighi di sicurezza verificabili, con riferimento esplicito a IEC 62443, clausole di notifica incidenti, diritti di audit, e un’allocazione delle responsabilità coerente con il profilo di rischio effettivo.
Verificare la copertura assicurativa
La terza è la copertura assicurativa. Le polizze cyber tradizionali non coprono danni materiali da attacco informatico; le polizze property escludono i rischi cyber tramite le clausole LMA 5400/5401. Se un attacco OT causa danni fisici può non essere coperto da nessuna delle due. Esistono prodotti assicurativi specifici, polizze di tipo cyber gap o estensioni di property damage, che colmano questo spazio, ma richiedono una quantificazione del rischio basata su scenari specifici, non su questionari generici. Il problema non è astratto: Munich Re ha documentato come le polizze cyber tradizionali non coprano normalmente danni materiali da cyberattacchi, mentre le polizze property escludono esplicitamente i rischi cyber. Il risultato è che un incidente OT con danni fisici può ricadere in una terra di nessuno assicurativa.
Documentare la diligenza prima dell’incidente
La quarta è la documentazione della diligenza. La miglior difesa in un giudizio civile è un audit trail che dimostri l’adozione di misure adeguate prima dell’incidente: risk assessment documentati secondo framework riconosciuti, segmentazione IT/OT implementata e verificata, monitoraggio continuo con telemetria OT, piani di incident response testati attraverso esercitazioni. Questa documentazione è cruciale sia per la compliance NIS2 sia per la difesa civile.
Integrare la governance dei regimi normativi
La quinta è la governance integrata. I regimi normativi applicabili a un operatore di infrastruttura critica, PSNC, NIS2, CRA, Direttiva Prodotti Difettosi, hanno logiche e perimetri diversi ma convergono sugli stessi sistemi fisici. L’approccio più solido è un registro unico degli obblighi, con mappatura dei sistemi per regime e obbligo, un unico workflow di classificazione incidenti e un reporting direzionale che alimenti l’accountability sia amministrativa sia civilistica.
Il tema della responsabilità civile per danno fisico da attacco OT non è un esercizio accademico, è la domanda che nessuno dei soggetti nella supply chain, operatore, integratore, vendor, assicuratore, vuole porsi per primo, ma alla quale un giudice, prima o poi, dovrà rispondere. Meglio arrivarci con le carte in ordine.
Partecipa alla community