Contratti MSP e NIS2: i Limiti di Responsabilità sono Validi?

La Direttiva NIS2 e il suo recepimento nazionale hanno inciso fortemente nel settore dei servizi IT gestiti (Managed Service Providers – MSP). Fino a ieri, la contrattualistica di settore si reggeva su un equilibrio precario ma accettato: il fornitore erogava un servizio basato sul “miglior sforzo” (best effort), blindando la propria esposizione economica dietro clausole limitative della responsabilità (i cosiddetti liability caps).

Oggi, questo paradigma vacilla. La normativa impone un obbligo di “adeguatezza” delle misure di sicurezza che mal si concilia con la natura puramente “di mezzi” spesso rivendicata dai fornitori. Quando un incidente ransomware paralizza un’azienda cliente, la domanda che i tribunali si pongono non è più solo “hai fatto del tuo meglio?”, ma “il risultato di sicurezza era adeguato allo stato dell’arte?”.

Come confermato da recenti orientamenti giurisprudenziali, inclusi provvedimenti del Garante Privacy che rifiutano l’argomento del “budget limitato” come scusante per mancati aggiornamenti, e sentenze civili che riqualificano i contratti software complessi come obbligazioni di risultato, le clausole che limitano il risarcimento rischiano di non essere idonei a tutelare il fornitore dei servizi.

1. L’Impatto della NIS2 sui Contratti IT: Oltre la Carta

La Direttiva NIS2 (Network and Information Security 2) introduce un principio di responsabilità diretta per gli organi di amministrazione delle entità essenziali e importanti. Questo si traduce, a cascata, in una pressione senza precedenti sulla catena di fornitura (supply chain). Il cliente finale non può più “esternalizzare il rischio” semplicemente firmando un contratto con un MSP; deve garantire che anche il fornitore adotti misure di gestione dei rischi di cybersicurezza adeguate.

1.1 Il Conflitto tra Adeguatezza Normativa e Clausole Contrattuali

Qui nasce il cortocircuito. Da un lato, la norma richiede:

• Misure tecniche e organizzative adeguate al rischio;
• Gestione degli incidenti e continuità operativa;
• Sicurezza della catena di approvvigionamento.

Dall’altro lato, i contratti standard proposti da molti System Integrator e MSP continuano a prevedere:

• Esclusioni totali per danni da perdita dati, ransomware o interruzione di servizio;
• Liability Caps (Tetti di Responsabilità) spesso limitati al valore del canone annuale del servizio (es. “Il risarcimento non potrà eccedere il 50% del corrispettivo pagato negli ultimi 12 mesi”);
• Qualificazione dell’obbligazione come mera “assistenza tecnica” (mezzi) priva di garanzie di risultato.

Tuttavia, come vedremo nei prossimi capitoli, la giurisprudenza sta iniziando a smontare queste difese. Quando un fornitore vende un “sistema di sicurezza” o un software gestionale complesso, non sta vendendo solo ore-uomo, ma un risultato funzionale. Se questo risultato manca a causa di negligenze operative (come il mancato aggiornamento di un server vulnerabile), il limite risarcitorio crolla.

2. Mezzi o Risultato? La Trappola della Qualificazione Contrattuale

Nella redazione dei contratti MSP (Managed Service Provider), è prassi comune inserire clausole che qualificano esplicitamente l’attività del fornitore come obbligazione di mezzi. La logica è chiara: il fornitore si impegna a svolgere l’attività con la diligenza professionale richiesta, ma non garantisce che il sistema sarà inviolabile o esente da guasti.

Tuttavia, la realtà delle aule di tribunale racconta una storia diversa. Quando il contratto ha ad oggetto sistemi complessi, forniture software o servizi di sicurezza gestita, la giurisprudenza tende a riqualificare il rapporto in termini di obbligazione di risultato. Se il Cliente acquista una soluzione per “mettere in sicurezza” o “gestire” l’infrastruttura, si aspetta (e paga per) un risultato funzionale, non solo per lo sforzo del tecnico.

L’impatto sulla NIS2: Applicando questi principi ai servizi di Cybersecurity, se un MSP vende un servizio di “monitoraggio e protezione”, sta vendendo un risultato di sicurezza. Se l’incidente avviene perché una misura di sicurezza di base (es. patch management) non è stata attuata, potrebbe essere complicato sostenere davanti a un giudice che si trattava solo di un’obbligazione di mezzi.

3. Il “Cap” Risarcitorio alla Prova dell’Art. 1229 c.c.

La seconda linea di difesa degli MSP è il cosiddetto liability cap: una clausola che limita il risarcimento massimo erogabile a una somma predeterminata (spesso pari al canone annuale del servizio o a una percentuale dello stesso).

Queste clausole sono valide nel nostro ordinamento, ma incontrano un limite invalicabile nell’articolo 1229 del Codice Civile:

“È nullo qualsiasi patto che esclude o limita preventivamente la responsabilità del debitore per dolo o per colpa grave.”

Il punto cruciale del contenzioso post-incidente informatico diventa quindi la qualificazione della condotta del fornitore: l’errore che ha permesso l’attacco (es. la mancata chiusura di una porta RDP, l’omesso aggiornamento di un firewall) è frutto di semplice negligenza (colpa lieve) o di una trascuratezza imperdonabile (colpa grave)?

Se viene accertata la colpa grave, il “tetto” al risarcimento salta e il fornitore risponde dell’intero danno subito dal cliente, inclusi i danni da fermo operativo e, potenzialmente, delle eventuali sanzioni amministrative. E come vedremo nel prossimo capitolo, il concetto di “colpa grave” in ambito IT si sta espandendo notevolmente.

4. Il “precedente” del Garante: Perché l’economicità non è una scusa

Spesso, nei contenziosi post-incidente, i fornitori IT cercano di difendersi sostenendo che l’adozione di misure di sicurezza più avanzate (come sistemi di alert in tempo reale o SOC H24) avrebbe comportato costi sproporzionati rispetto al valore del contratto.

Tuttavia, un recente provvedimento del Garante per la Protezione dei Dati Personali (n. 271 del 29/04/2025) ha eretto un muro invalicabile contro questa linea difensiva.

Le conseguenze per gli MSP: Se un fornitore omette una misura di sicurezza ormai standard (come l’MFA o il patch management) giustificandosi con il “risparmio” o la mancanza di budget allocato dal cliente, si espone al rischio di vedersi contestata la colpa grave. Come afferma il Garante, il costo è solo un fattore di scelta tra più soluzioni, non una scusa per non agire. E dove c’è colpa grave, ricordiamo, il limite al risarcimento del danno non opera.

5. Conclusioni e Checklist Operativa

La Direttiva NIS2 e l’evoluzione giurisprudenziale stanno chiudendo il cerchio intorno alla responsabilità dei fornitori IT. Le clausole “scudo” che per anni hanno protetto gli operatori da risarcimenti ingenti sono oggi fragili di fronte a incidenti causati da negligenze operative su misure di base.

Domande Frequenti (FAQ)