Ransomware e fornitori IT: esternalizzare i sistemi non significa esternalizzare la responsabilità

Se un attacco informatico colpisce l’azienda, fino a che punto il titolare può attribuire al fornitore la responsabilità delle carenze nella gestione della sicurezza?

A questa domanda ha risposto il Tribunale di Varese con la sentenza n. 545 del 29 settembre 2026, relativa a un attacco ransomware. Il giudice ha riconosciuto l’inadempimento del fornitore, ma ha escluso che dovesse rispondere di tutte le conseguenze dell’attacco. La quota maggiore di responsabilità, pari al 50%, spetta infatti all’azienda, che non aveva nominato né controllato chi gestiva i suoi sistemi.

Il caso: un AdS mai nominato

Dalla fine del 2017 Euro 2000 S.p.A. si era affidata a una società di servizi informatici, con la quale aveva stipulato nel tempo diversi contratti. Si trattava della fornitura della rete wi-fi e della configurazione del firewall, dell’assistenza tecnico-sistemistica, dell’installazione di un nuovo server, di un servizio cloud e di un nuovo sistema di posta elettronica. Il fornitore non era mai stato formalmente designato amministratore di sistema. Non era, peraltro, l’unico ad avere accessi privilegiati ai sistemi: ne disponevano anche altri soggetti esterni, tra cui la società che gestiva il software gestionale aziendale.

Il 5 e 6 settembre 2023 l’azienda ha subito un attacco ransomware, cioè l’introduzione nei sistemi di un software malevolo che cifra i dati e li rende inutilizzabili fino all’eventuale pagamento di un riscatto. Parte dei dati è andata perduta, in particolare quelli del CRM e alcuni file del gestionale, per i quali il backup non era mai stato configurato.

Il 27 ottobre 2023 l’azienda ha comunicato via PEC la risoluzione del contratto per inadempimento e ha poi agito in giudizio. Secondo Euro 2000 S.p.A., i singoli contratti componevano un unico rapporto di outsourcing delle attività informatiche, nel quale il fornitore aveva svolto di fatto le funzioni di amministratore di sistema. Gli venivano contestate scelte errate prima dell’attacco, dalla configurazione del firewall alla gestione dei backup, fino all’assenza di segmentazione della rete e alla mancata formazione del personale, oltre a una gestione inadeguata dell’emergenza. La richiesta risarcitoria ammontava a 242.310,22 euro, tra fermo dell’attività, costo del personale impegnato nel ripristino, spese tecniche e legali e danno all’immagine.

Il fornitore ha replicato di aver prestato una semplice assistenza tecnica su chiamata, senza alcun ruolo di amministrazione dei sistemi.

La decisione: responsabilità divise tra titolare e fornitore

Il Tribunale ha accertato l’inadempimento del fornitore e ha dichiarato risolto il contratto di assistenza tecnica ai sensi degli artt. 1453 e 1455 c.c., ritenendo legittima la comunicazione del 27 ottobre 2023.

Aderendo alle conclusioni della CTU, il giudice ha ricostruito la gestione dei sistemi secondo un “modello a tre pilastri“:

• l’azienda come titolare del trattamento;
• il fornitore con accessi equivalenti a quelli di un amministratore di sistema esterno, ma privo di incarico formale;
• altri soggetti terzi con accessi analoghi.

Non è stato possibile individuare con certezza il punto di ingresso dell’attacco. La responsabilità è stata quindi ricondotta a un concorso di colpa ex art. 1227 c.c., richiamando la ripartizione indicata dal consulente: 50% all’azienda, 30% al fornitore, 20% agli altri soggetti dotati di credenziali amministrative.

Il danno è stato ritenuto provato nella sua esistenza ma non nel suo ammontare. Per questo è stato liquidato in via equitativa ex art. 1226 c.c. in 20.000 euro, oltre interessi legali dalla pubblicazione della sentenza.

Titolare e amministratore di sistema “di fatto”: cosa insegna la sentenza

La pronuncia porta in sede civile una questione che di solito emerge davanti al Garante: chi risponde quando un’infrastruttura informatica gestita da più soggetti viene violata.

Il Tribunale muove dal provvedimento del Garante del 27 novembre 2008, tuttora applicabile in quanto compatibile con il GDPR. Il provvedimento richiede:

• la designazione individuale e per iscritto degli amministratori;
• una verifica almeno annuale del loro operato;
• la registrazione degli accessi in log completi e inalterabili.

Nel caso deciso mancava tutto questo. La mancata nomina non mette al riparo il fornitore, che, gestendo di fatto i sistemi, risponde secondo la diligenza qualificata dell’art. 1176, comma 2, c.c. La stessa lacuna pesa però soprattutto sul titolare, al quale spetta scegliere a chi affidare il ruolo, definirne i compiti e controllarne l’operato.

[Vedi anche: Amministratori di sistema: non basta la nomina, servono controlli effettivi]

Secondo il consulente, i contratti erano normali accordi di fornitura di beni e servizi. Disciplinavano in modo superficiale la gestione e la sicurezza dei sistemi e non contenevano clausole sulla perdita dei dati. Un’analoga carenza ha pesato sul piano del danno: senza una documentazione dei costi raccolta durante l’emergenza, il giudice ha potuto riconoscere soltanto una somma determinata in via equitativa.

Le indicazioni operative per titolari e fornitori IT

Dalla vicenda si ricavano alcune indicazioni concrete, valide per qualsiasi organizzazione che affidi a terzi, in tutto o in parte, la gestione dei propri sistemi.

Per i titolari del trattamento

• Mappare gli accessi privilegiati. Individuare tutti i soggetti, interni ed esterni, che dispongono di credenziali amministrative e disattivare le utenze generiche o condivise. Nel caso deciso erano più di uno e operavano senza una gestione unitaria.
• Designare le persone, non solo la società. Il provvedimento del 2008 richiede una designazione individuale. Quando il servizio è esternalizzato, il fornitore va di regola nominato responsabile del trattamento ex art. 28 GDPR. Il titolare, o il fornitore per suo conto, deve conservare gli estremi identificativi dei tecnici che operano come amministratori.
• Controllare nel tempo. Prevedere la registrazione degli accessi amministrativi, con log inalterabili conservati per almeno sei mesi, e verificare almeno una volta l’anno l’operato degli amministratori.
• Configurare i backup su tutti i dati necessari. Stabilire per iscritto quali dati vengono salvati, con quale frequenza e dove, e aggiornare questo elenco ogni volta che si introduce un nuovo applicativo. L’art. 32 GDPR chiede di poter ripristinare tempestivamente i dati e di verificare regolarmente l’efficacia delle misure: un backup mai testato non offre questa garanzia.
• Prepararsi all’incidente. Una procedura scritta dovrebbe indicare chi isola i sistemi, chi valuta la notifica al Garante entro 72 ore e come si conservano le evidenze. La stessa procedura dovrebbe prevedere la raccolta dei dati sui costi, come ore di lavoro, straordinari, ordini persi e fatture esterne, senza i quali il danno difficilmente potrà essere provato.
• Verificare le garanzie del fornitore. Chiedere evidenza di una polizza che copra l’attività sistemistica e il rischio informatico.

[Vedi anche: Firewall, antivirus e poi? La sicurezza secondo il GDPR]

Per gli amministratori di sistema e i fornitori IT

• Chiedere la designazione e un contratto che descriva il servizio effettivamente svolto. Operare senza nomina non riduce la responsabilità, come mostra la sentenza, ma rende incerti i confini dell’incarico. Se di fatto si gestisce l’infrastruttura, il contratto deve dirlo e indicare cosa resta al cliente.
• Usare utenze nominative. Ogni tecnico dovrebbe accedere con un proprio account, così che ogni operazione resti attribuibile e verificabile, anche a tutela del fornitore stesso.
• Segnalare per iscritto le criticità: un firewall da aggiornare, dati esclusi dal backup, una scelta del cliente che aumenta il rischio. In caso di contestazione, è questa traccia a distinguere ciò che spettava al fornitore da ciò che il cliente aveva deciso di non fare.
• Reagire subito al primo segnale di compromissione. Isolare i sistemi coinvolti e informare il titolare senza ingiustificato ritardo, come l’art. 33, par. 2, GDPR richiede al responsabile del trattamento.