Contratto SLA e sicurezza: come strutturare le penali nelle forniture tecnologiche

Nel linguaggio comune del procurement IT, lo SLA (Service Level Agreement) è spesso percepito come un allegato tecnico al contratto principale: un documento che fissa le percentuali di uptime, i tempi di risposta al ticketing e le finestre di manutenzione programmata.

Una visione riduttiva che, nel contesto normativo attuale, non regge più. Lo SLA è, a tutti gli effetti, lo strumento contrattuale attraverso cui l’organizzazione cliente traduce i propri obblighi di sicurezza in impegni vincolanti per il fornitore e in diritti esigibili in caso di inadempimento.

Lo SLA non è solo un documento tecnico: è uno strumento di governance del rischio

Questa visione non è solo teorica.

La Direttiva NIS2 impone ai soggetti essenziali e importanti di adottare misure tecniche e organizzative proporzionate al rischio, includendo esplicitamente la sicurezza della supply chain.

DORA richiede che i contratti con i provider ICT critici includano una serie di elementi minimi, tra cui gli obiettivi di livello di servizio, i diritti di accesso e audit, e le procedure di gestione degli incidenti.

Il GDPR, all’articolo 28, prescrive che il contratto con il responsabile del trattamento contenga istruzioni dettagliate sulle misure di sicurezza e sulle modalità di gestione delle violazioni.

In questo quadro, uno SLA privo di clausole di sicurezza adeguate non è solo una lacuna contrattuale: è una non conformità normativa.

Sul piano del diritto civile italiano, lo SLA si configura come un contratto atipico – o come parte integrante di un contratto di appalto di servizi – soggetto alle disposizioni generali del Codice civile in materia di obbligazioni e responsabilità contrattuale (artt. 1218 e seguenti c.c.).

Le penali previste dallo SLA rientrano nella categoria della clausola penale ex art. 1382 c.c., con la conseguenza che, salvo diversa previsione contrattuale, il creditore non deve provare il danno subito per ottenerle, ma il giudice può ridurle equitativamente se manifestamente eccessive (art. 1384 c.c.).

Conoscere questo quadro è essenziale per strutturare penali che siano al contempo deterrenti efficaci e giuridicamente robuste.

Anatomia di un contratto SLA per forniture IT sicure

Ecco alcuni esempi pratici per la corretta stesura di un contratto SLA per forniture IT sicure.

Disponibilità, RTO e RPO: metriche che contano davvero

La disponibilità del servizio, espressa tipicamente come percentuale annua (“five nines”, 99,999%, corrispondente a meno di 6 minuti di downtime annuo), è la metrica più citata negli SLA e, spesso, quella meno significativa per la sicurezza.

Un sistema disponibile al 99,9% ma con una risposta agli incidenti di 72 ore è un sistema che, in caso di attacco, lascia l’organizzazione esposta per tre giorni.

Le metriche davvero rilevanti per la resilienza operativa sono RTO (Recovery Time Objective) e RPO (Recovery Point Objective).

L’RTO definisce il tempo massimo accettabile per il ripristino del servizio dopo un’interruzione: per i sistemi critici nei settori NIS2, un RTO superiore alle 4 ore è difficilmente giustificabile. L’RPO definisce la quantità massima di dati che l’organizzazione è disposta a perdere in caso di incidente, espressa come intervallo temporale: un RPO di 24 ore significa che il sistema di backup potrebbe non includere l’ultima giornata di dati.

Per i sistemi che trattano dati operativi critici (transazioni finanziarie, cartelle cliniche, dati di infrastruttura) un RPO di 24 ore è inaccettabile.

Queste metriche devono essere negoziate esplicitamente, documentate nello SLA e verificate periodicamente attraverso test di disaster recovery.

KPI di sicurezza: cosa misurare e come

Accanto agli SLA operativi tradizionali, un contratto IT moderno deve includere KPI specificamente dedicati alla sicurezza: indicatori misurabili che consentano all’organizzazione cliente di verificare in modo oggettivo il mantenimento della postura di sicurezza del vendor nel tempo.

La definizione di questi KPI è uno degli aspetti più trascurati nella negoziazione degli SLA, e uno dei più preziosi in caso di contestazione.

I KPI di sicurezza più rilevanti variano per tipo di fornitura, ma alcune categorie sono trasversali:

• il tempo medio di patching per le vulnerabilità critiche (CVSS ≥ 9.0), con SLA distinti per severity;
• il tempo di notifica degli incidenti di sicurezza al cliente;
• la frequenza e la copertura delle scansioni di vulnerability assessment;
• la percentuale di controlli di sicurezza conformi al baseline definito (es. CIS Benchmarks per i CSP);
• il tempo di risposta e risoluzione per le richieste di audit.

Per i servizi cloud, si aggiungono KPI specifici: configurazione conforme ai benchmark CIS, copertura del logging, tempo di rilevamento delle anomalie nel SIEM.

Le clausole di sicurezza irrinunciabili

Di seguito, invece, le clausole di sicurezza che non possono mancare in un contratto con i propri fornitori.

Notifica degli incidenti e obblighi di trasparenza

La clausola di notifica degli incidenti è, in ordine di importanza, la più critica in un contratto SLA orientato alla sicurezza.

Le ragioni sono tanto operative quanto normative: NIS2 impone ai soggetti essenziali di notificare gli incidenti significativi ad ACN entro 24 ore (early warning) e 72 ore (notifica completa); DORA prevede obblighi analoghi per le entità finanziarie verso le autorità competenti; il GDPR richiede la notifica al Garante entro 72 ore dalla scoperta di una violazione dei dati personali.

Tutti questi obblighi presuppongono che l’organizzazione cliente sia informata tempestivamente dal proprio vendor, il che non accade se non è contrattualmente previsto.

La clausola di notifica deve definire almeno:

1. la soglia di rilevanza degli incidenti che attiva l’obbligo (non solo i breach conclamati, ma anche gli accessi non autorizzati, le anomalie significative, i tentativi di compromissione rilevati);
2. il termine massimo di notifica (4 ore per gli incidenti critici è uno standard ragionevole e compatibile con gli obblighi NIS2);
3. il canale di comunicazione (email certificata, portale dedicato, numero di emergenza);
4. il contenuto minimo della notifica iniziale (natura dell’incidente, sistemi coinvolti, misure di contenimento adottate, stima dell’impatto).

Patch management e gestione delle vulnerabilità

Il patch management è uno degli SLA di sicurezza più frequentemente violati nella pratica e uno dei vettori di attacco più sfruttati. La ragione è strutturale: applicare le patch richiede test, finestre di manutenzione, potenziale impatto sulla disponibilità del servizio.

I vendor tendono a rallentare il processo; i clienti, se non hanno SLA vincolanti, raramente esercitano pressione fino a che non si verifica un incidente.

Per i servizi cloud e i software SaaS, il patch management è tipicamente responsabilità del vendor (modello shared responsibility): il cliente non ha accesso diretto ai layer infrastrutturali e deve affidarsi agli impegni contrattuali del provider.

Per i software on-premise e i servizi gestiti MSP/MSSP, la responsabilità è più articolata e deve essere definita esplicitamente: chi scansiona, chi decide la priorità, chi applica la patch, chi verifica l’applicazione. L’assenza di questa definizione è una delle cause più frequenti di gap nella copertura delle vulnerabilità.

Diritto di audit e ispezione

Il diritto di audit è una delle clausole che i vendor resistono maggiormente in fase di negoziazione e che l’organizzazione cliente deve difendere con maggiore determinazione.

Senza un diritto di audit formalmente riconosciuto e operativamente esercitabile, tutti gli altri obblighi contrattuali di sicurezza diventano dichiarazioni di intenti non verificabili.

La clausola di audit deve essere specifica: un generico “il cliente si riserva il diritto di effettuare audit” è insufficiente e, in caso di contestazione, di difficile applicazione.

Gli elementi essenziali di una clausola di audit efficace sono:

1. la frequenza minima garantita (almeno una volta all’anno per i vendor critici);
2. il preavviso richiesto (tipicamente 15-30 giorni, ridotto a 48 ore in caso di incidente);
3. il perimetro dell’audit (sistemi, processi, documentazione);
4. le modalità di esecuzione (audit documentale, accesso tecnico, utilizzo di terze parti qualificate);
5. la gestione dei risultati (obblighi di remediation, tempi di risposta, follow-up).

Come alternativa all’audit diretto, spesso costoso e impattante per entrambe le parti, è buona pratica prevedere la possibilità di richiedere report di audit di terza parte (SOC 2 Type II, ISO 27001) come strumento di verifica equivalente.

Dal risk assessment al contratto: il collegamento necessario

Un errore frequente nella strutturazione degli SLA è trattarli come documenti autonomi, scollegati dal processo di valutazione preliminare del vendor. In realtà, gli SLA di sicurezza dovrebbero essere la diretta conseguenza contrattuale del risk assessment: le clausole più stringenti, le penali più elevate e i KPI più granulari devono applicarsi ai vendor classificati come critici, mentre per i vendor a basso rischio è accettabile uno SLA semplificato.

La stesura delle penali in caso di disservizio garantisce la tutela legale delle informazioni aziendali. Questo impianto contrattuale deve riflettere gli esiti delle metriche di Vendor Risk Management applicate durante l’analisi preliminare del software: è nella fase di due diligence dei vendor che emergono le vulnerabilità strutturali, le dipendenze critiche e i gap di compliance che lo SLA dovrà presidiare sul piano contrattuale.

Questa continuità tra assessment e contratto non è solo metodologicamente corretta: è anche la migliore difesa in caso di contestazione legale. Un’organizzazione che può dimostrare di aver condotto un risk assessment documentato, di aver strutturato lo SLA in coerenza con i risultati, e di aver monitorato il rispetto degli SLA nel tempo è in una posizione molto più solida — sia davanti a un giudice in caso di contenzioso civile, sia davanti all’autorità di supervisione in caso di ispezione NIS2 o DORA.

Le penali: come strutturarle perché siano efficaci

Penali per violazione dei KPI di sicurezza

La clausola penale è lo strumento giuridico che trasforma un obbligo contrattuale in un impegno con conseguenze economiche concrete.

Per essere efficace, ovvero per avere reale valore deterrente e non solo simbolico, deve essere strutturata in modo proporzionale all’impatto della violazione, non arbitrariamente. Una penale troppo bassa non disincentiva il vendor dall’inadempimento; una penale manifestamente sproporzionata rischia di essere ridotta dal giudice ex art. 1384 c.c.

Per le violazioni dei KPI di sicurezza, il modello più efficace prevede penali scalari in funzione della gravità e della recidività: una prima violazione di un KPI entro un trimestre genera una penale ridotta; la recidiva entro lo stesso periodo genera una penale progressivamente più elevata; il superamento di una soglia di violazioni cumulative attiva il diritto di risoluzione contrattuale.

Questo schema incentiva la remediation rapida e scoraggia l’inadempimento sistematico. Per i servizi cloud e SaaS, è pratica comune esprimere le penali come crediti sul canone mensile (service credits), con massimali tipicamente compresi tra il 10% e il 30% del canone mensile per le violazioni più gravi.

Penali per data breach e violazione del GDPR

Le penali per violazione dei dati personali meritano una trattazione separata, per ragioni sia normative che economiche.

Sul piano normativo, il GDPR attribuisce all’interessato il diritto al risarcimento del danno subito (art. 82 GDPR), e il titolare del trattamento risponde solidalmente con il responsabile – il vendor – salvo che quest’ultimo dimostri che l’evento non gli è in alcun modo imputabile.

Questo significa che, in caso di data breach causato da una vulnerabilità del vendor, l’organizzazione cliente può trovarsi a rispondere verso gli interessati e verso il Garante, con diritto di rivalsa sul vendor.

Le clausole contrattuali devono presidiare questo scenario su due fronti: l’obbligo del vendor di indennizzare il cliente per le sanzioni amministrative e i risarcimenti riconducibili a proprie condotte negligenti, e l’obbligo di cooperazione attiva nella gestione del breach (notifica al Garante, comunicazione agli interessati, misure di contenimento).

Dato che le sanzioni GDPR possono raggiungere il 4% del fatturato mondiale annuo del titolare, è essenziale che il massimale di responsabilità del vendor non sia fissato a livelli simbolici, un cap di responsabilità pari al valore annuo del contratto è raramente sufficiente a coprire l’esposizione reale in caso di breach significativo.

Limitazioni di responsabilità: come negoziarle

I vendor, in sede di negoziazione, tendono a inserire clausole di limitazione della responsabilità che riducono drasticamente la loro esposizione economica:

1. cap di responsabilità pari al valore del contratto degli ultimi 3 o 6 mesi;
2. esclusione dei danni indiretti e del lucro cessante;
3. esenzione per cause di forza maggiore definite in modo molto ampio.

Queste clausole sono legittime sul piano contrattuale, ma possono rendere le penali e i risarcimenti contrattualmente previsti di fatto irrecuperabili in caso di sinistro significativo.

La strategia negoziale ottimale prevede di distinguere tra categorie di danno con regimi di responsabilità differenziati:

1. per i danni diretti e documentabili (costi di ripristino, penali GDPR attribuibili al vendor, costi di notifica) il cap di responsabilità dovrebbe essere significativo, tipicamente non inferiore al valore annuale del contratto;
2. per i danni da violazione degli obblighi di sicurezza specificamente pattuiti (notifica incidenti, patch management, audit), è ragionevole richiedere l’esclusione dalla limitazione di responsabilità, trattandoli come obblighi essenziali il cui inadempimento è imputabile alla negligenza grave del vendor.

SLA nei settori critici NIS2 e DORA: requisiti specifici

Per i soggetti NIS2, la strutturazione degli SLA con i provider IT non è una scelta discrezionale: è parte integrante del programma di gestione del rischio che l’organizzazione è tenuta a implementare e documentare. Le linee guida ENISA sul rischio supply chain identificano la contrattualizzazione dei requisiti di sicurezza come una delle misure fondamentali per la gestione del rischio terze parti, e ACN, l’autorità di supervisione NIS2 in Italia, includerà la verifica degli SLA con i vendor critici tra gli elementi oggetto di ispezione.

Per le entità finanziarie soggette a DORA, i requisiti sono ancora più specifici. Il regolamento prescrive che i contratti con i provider ICT includano obbligatoriamente: la descrizione completa dei servizi, gli obiettivi di livello di servizio con metriche quantitative, i requisiti di sicurezza delle informazioni, le disposizioni in materia di accesso, recupero e restituzione dei dati, i diritti di audit e ispezione, i requisiti di notifica degli incidenti, le clausole di cessazione del servizio.

L’assenza di anche uno solo di questi elementi rende il contratto non conforme a DORA, con le conseguenti responsabilità per la funzione compliance e per il management.

Per i settori della sanità, dell’energia e delle infrastrutture di trasporto, si aggiungono requisiti specifici derivanti dalle normative di settore:

• per la sanità, le indicazioni AGENAS e del Ministero della Salute sulla sicurezza dei sistemi informativi clinici;
• per l’energia, le linee guida ARERA e ENTSO-E sulla resilienza delle infrastrutture critiche;
• per i trasporti, i requisiti ENAC e dell’Agenzia per la sicurezza ferroviaria.

In tutti questi contesti, lo SLA non è solo un documento commerciale: è un elemento del sistema di gestione della sicurezza che deve essere verificabile, aggiornato e coerente con il quadro normativo di riferimento.

Ciclo di vita dello SLA: revisione, rinnovo e risoluzione

Uno SLA non è un documento statico. Il panorama normativo evolve, le minacce cambiano, l’infrastruttura del vendor si trasforma: uno SLA firmato tre anni fa potrebbe non coprire adeguatamente i rischi attuali, anche se fu strutturato correttamente al momento della stipula.

Le organizzazioni più mature prevedono contrattualmente meccanismi di revisione periodica degli SLA – tipicamente annuale – con la possibilità di aggiornare le metriche, i KPI e le clausole di sicurezza in risposta a cambiamenti normativi o del contesto di rischio.

La risoluzione contrattuale per inadempimento degli SLA di sicurezza è lo strumento di ultima istanza, ma è fondamentale che sia contrattualmente praticabile.

La clausola risolutiva espressa ex art. 1456 c.c. consente di specificare quali inadempimenti determinano automaticamente la risoluzione del contratto, senza necessità di pronuncia giudiziale.

Per gli SLA di sicurezza, è opportuno qualificare come inadempimenti risolutori: il mancato rispetto reiterato degli SLA di notifica degli incidenti, la non applicazione delle patch critiche oltre la soglia contrattuale, il rifiuto di sottoporsi ad audit.

La clausola deve essere accompagnata da adeguate previsioni di exit strategy: tempistiche di trasferimento dei dati, obblighi di supporto alla migrazione, cancellazione certificata dei dati residui.

La gestione consapevole del ciclo di vita degli SLA (dalla negoziazione iniziale alla revisione periodica, fino all’eventuale risoluzione) è il segnale più chiaro della maturità di un programma di governance della supply chain IT.

Non si tratta di diffidenza verso i vendor: si tratta di professionalità nella gestione del rischio, che è esattamente ciò che NIS2, DORA e il buon senso operativo richiedono alle organizzazioni che operano in ambienti IT critici.