Livelli di servizio nei contratti SaaS: disponibilità, supporto e sanzioni

Lo SLA come strumento di governance nel contratto SaaS

Un Service Level Agreement (SLA) stabilisce, in quanto parte integrante del contratto o come documento a sé stante, le caratteristiche prestazionali concrete di un servizio IT, quali ad esempio la disponibilità, i tempi di reazione o di risoluzione dei guasti. Tali caratteristiche sono Key Performance Indicators (KPI), con i quali è possibile misurare la qualità di un servizio IT. Gli SLA sono diffusi in tutti i settori IT, dai contratti di esercizio alle soluzioni SaaS, fino ai classici modelli di outsourcing IT. Nel settore IT sono diventati noti grazie a ITIL; fanno parte del Service-Level-Management (SLM).

Nei contratti SaaS, lo SLA ha un peso maggiore, poiché convergono due fattori: i prodotti SaaS supportano regolarmente processi aziendali importanti o addirittura critici e i clienti pagano di norma un corrispettivo mensile. È pertanto necessario concordare quali standard qualitativi il prodotto debba soddisfare, quando il supporto sia raggiungibile e entro quali tempi debba essere possibile la risoluzione di un errore. Lo SLA rende la prestazione misurabile qualitativamente: le parti ottengono la certezza che il prodotto corrisponda agli standard concordati e, di conseguenza, quando sussista un «errore» o un «difetto». Da ciò è possibile stimare se e in quale misura si debba comunque pagare nonostante il mancato rispetto degli standard pattuiti.

Spesso si stipula uno SLA proprio quando le norme legali di garanzia per il caso concreto non sono sufficienti o non sono adeguate. In mancanza di chiare clausole SLA, l'ambito delle prestazioni, la responsabilità o i meccanismi di escalation rimangono indefiniti, con costi spesso elevati in caso di controversie. Uno SLA crea le basi per definire con precisione i contenuti delle prestazioni e per valutare obiettivamente le violazioni contrattuali.

Il rovescio della medaglia: nella pratica, le clausole SLA sono spesso imprecise o incomplete e non coprono le esigenze concrete. Di solito, ciò viene constatato solo quando la prestazione viene erogata in modo difettoso.

Vantaggi e rischi delle clausole SLA nei contratti SaaS

Disponibilità: periodo di riferimento, metodo di misurazione e finestre di manutenzione

Un impegno di disponibilità si compone di tre elementi, che il contratto deve stabilire singolarmente: il valore percentuale, il periodo di calcolo o di riferimento e il metodo di misurazione. Nella pratica, è proprio necessario chiarire innanzitutto questi tre elementi. Un'interruzione ha un impatto diverso a seconda del periodo di calcolo: la stessa interruzione pesa di più in una finestra temporale breve rispetto a una lunga.

Le finestre di manutenzione sono di norma escluse dalla disponibilità concordata. Il contratto deve pertanto definire quali aspetti rientrano in una finestra di manutenzione e quali siano le condizioni quadro, come ad esempio una comunicazione preventiva ai clienti o orari chiaramente definiti in cui possono essere eseguiti i lavori di manutenzione. In mancanza di queste condizioni quadro, non è possibile stabilire in seguito se un'interruzione conti come manutenzione programmata o come disservizio.

Quanto l'impegno e la misurazione possano divergere lo dimostra un esempio svizzero: il fornitore BESA QSys dichiara per la sua piattaforma SaaS RAI-System che il gestore garantisce contrattualmente una disponibilità del 99%, mentre la disponibilità attualmente misurata si aggira quasi al 100%. Secondo le stesse indicazioni, i dati e l'infrastruttura SaaS si trovano in un data center nei dintorni di Zurigo. Il valore garantito e quello misurato sono dunque due grandezze diverse; quale dei due sia determinante in caso di controversia non emerge dalla percentuale, bensì dal metodo di misurazione e dal periodo di riferimento concordati.

Confronto degli impegni di disponibilità e dei metodi di misurazione nei contratti SaaS svizzeri

Parametri SLA importanti nei contratti SaaS svizzeri

Supporto: tempi di reazione, intervento e risoluzione

Uno SLA distingue tipicamente tre concetti temporali: il tempo di reazione, il tempo di intervento e il tempo di risoluzione. Decisive non sono solo le loro definizioni, ma anche le eventuali differenziazioni. Spesso i tempi vengono stabiliti in modo graduale a seconda della gravità del caso, in un modello di incidente graduato con livelli di gravità (Severity Levels). È il grado di gravità a determinare quali scadenze si applicano: un disservizio che paralizza l'attività aziendale fa scattare scadenze diverse rispetto a una richiesta senza interruzione dell'attività.

Centrale è la domanda su quando inizi a decorrere il tempo di reazione: con la segnalazione da parte del cliente, con il suo arrivo in un determinato sistema, con la conferma di ricezione o solo con la classificazione del caso. Una definizione semplice nello SLA risponde a questa domanda; senza di essa, in caso di controversia, rimane aperto se una scadenza sia stata effettivamente violata.

Ai concetti temporali è legata la raggiungibilità del supporto: occorre concordare quando il supporto sia raggiungibile e entro quali tempi possa avvenire la risoluzione di un errore. Nella pratica, si distingue tra orari d'ufficio e un servizio presidiato in modo continuativo; la variante più adatta dipende da quanto sia critico il processo aziendale che si basa sul prodotto SaaS. Un modello di incidente graduato unisce entrambi gli aspetti: associa il grado di gravità alla raggiungibilità e alle scadenze, invece di fissare lo stesso tempo per tutti i casi.

Definizioni ed esclusioni: affinché lo SLA non resti privo di efficacia

Definizioni chiare sono il primo punto di verifica, anche se possono sembrare poco spettacolari. È necessario rispondere a domande come: «A cosa si riferisce la disponibilità?» e «Quando inizia a decorrere il tempo di reazione?». Le risposte possono essere fissate in modo relativamente semplice come definizioni nello SLA. A ciò appartiene anche come vengano descritti errori e difetti: solo tramite queste definizioni è possibile determinare quando sussista una deviazione dallo standard concordato e quali diritti ne derivino.

Le esclusioni stabiliscono quali eventi non debbano essere rilevanti ai fini dello SLA. Esempi tipici sono le dipendenze da terzi, gli attacchi DDoS e il caso di forza maggiore. Tali esclusioni sono legittime, ma devono essere circoscritte in modo rigoroso: più la formulazione è aperta, più è facile classificare come caso escluso un disservizio che il fornitore avrebbe potuto influenzare.

Clausole poco chiare o incomplete hanno conseguenze concrete. Nella pratica, gli SLA non sono di rado redatti in modo rudimentale e poco chiaro, il che può renderli inefficaci; le lacune emergono regolarmente solo in caso di erogazione carente della prestazione, non al momento della stipula del contratto. Uno SLA che non definisce cosa sia un errore, cosa una finestra di manutenzione e cosa una circostanza esclusa, non offre in caso di controversia alcuna base per una valutazione obiettiva.

Misurazione, reporting e prova

I metodi di misurazione e i periodi di riferimento sono il secondo punto di verifica: chi misura cosa, come e per quali periodi? Senza queste disposizioni, un impegno SLA è difficilmente valutabile in modo obiettivo, poiché già il periodo di riferimento altera il risultato. Chi non regola la misurazione, affida di fatto la valutazione a chi fornisce i numeri.

Per quanto riguarda il reporting, bisogna chiarire in quale forma e con quale periodicità il fornitore informi sui valori misurati e se vengano forniti anche i punti di misurazione o i dati grezzi.

Ai fini della prova, è pertanto necessario regolare chi abbia accesso ai dati di misurazione e come si gestiscano le lacune di misurazione. Quale cifra sia determinante in caso di controversia non emerge dall'impegno, bensì dalle regole di misurazione: dal metodo di misurazione, dal periodo di riferimento e dalla questione di quale misurazione sia riconosciuta come riferimento.

Sanzioni e conseguenze in caso di violazioni dello SLA

In mancanza di una regolamentazione delle conseguenze in caso di violazione, lo SLA rimane una «tigre di carta». Gli impegni di disponibilità e i tempi di reazione restano privi di vincolo finché non vi è associata alcuna conseguenza giuridica; senza clausole chiare, anche i meccanismi di escalation rimangono indefiniti, con costi elevati in caso di controversie.

Nella pratica, come conseguenze si discutono spesso accrediti sul corrispettivo ricorrente, oltre a livelli di escalation dal primo referente fino alla direzione aziendale, nonché diritti di recesso o di risoluzione straordinari in caso di violazioni ripetute o gravi. Quali meccanismi scattino e a partire da quale soglia, deve rientrare nella regolamentazione delle conseguenze; l'escalation dovrebbe inoltre agganciarsi agli stessi livelli di gravità concordati per i tempi di supporto.

Alle sanzioni si affianca la questione della responsabilità. Nei contratti SaaS, le disposizioni su responsabilità, garanzia e diritti di proprietà intellettuale fanno parte del contenuto contrattuale usuale, e uno SLA viene stipulato proprio quando le norme legali di garanzia non sono sufficienti o non sono adeguate. È pertanto necessario chiarire come interagiscano le sanzioni SLA e le norme generali sulla responsabilità, in particolare se un accredito resti la conseguenza definitiva o se sussistano inoltre pretese più ampie.

Integrazione nel contratto SaaS, nelle CG e nella pratica svizzera

Nei modelli SaaS standardizzati, contratto SaaS, CG, livelli di servizio, contratto di elaborazione dei dati (DPA) e documentazione sulla protezione dei dati devono essere coordinati tra loro. Altrettanto importanti sono le questioni relative all'utilizzo dei dati, all'esportazione dei dati e all'exit. I modelli SaaS e software richiedono inoltre regolamentazioni chiare su ambito delle prestazioni, disponibilità, diritti d'uso, aggiornamenti, supporto, responsabilità e risoluzione (Lezzi Legal, Zurigo). Se lo SLA indica valori diversi dalle CG o dalla documentazione del prodotto, si crea una contraddizione che in caso di controversia deve essere risolta in primo luogo.

I prodotti SaaS vengono sviluppati in modo iterativo; funzioni, modelli di prezzo, integrazioni e dipendenze tecniche cambiano continuamente. La documentazione giuridica dovrebbe pertanto poter crescere con il prodotto e non dover essere ricostruita a ogni adeguamento tecnico (Lezzi Legal). Ne consegue che, per lo SLA, gli adeguamenti del metodo di misurazione, delle finestre di manutenzione e dei tempi di supporto necessitano di un percorso ordinato nel contratto.

Per i contratti SaaS in Svizzera, l'hosting sul territorio nazionale può essere un elemento contrattuale opportuno. Il contratto modello WEKA per SaaS ne indica come vantaggi: disponibilità garantita con regolamentazioni SLA chiaramente definite, hosting in Svizzera con backup, trasparenza dei costi tramite tariffe chiare e un modello di fatturazione comprensibile, disposizioni su responsabilità, garanzia e diritti di proprietà intellettuale, nonché il controllo sui propri dati, inclusa la loro restituzione senza diritto di ritenzione.

L'accesso può essere concretizzato contrattualmente: il fornitore BESA QSys indica che l'accesso alla soluzione SaaS è di norma delimitato tramite un geoblocking o può essere limitato a determinati luoghi di accesso in fase di configurazione. Tali indicazioni devono essere confrontate con lo SLA, poiché un blocco all'accesso può far scattare le stesse scadenze di disponibilità e supporto.

Checklist per la negoziazione del contratto

Definizioni: cos'è un errore, cos'è un difetto, cos'è un disservizio? A cosa si riferisce la disponibilità? Quando inizia a decorrere un tempo di reazione? Le definizioni nello SLA rispondono a queste domande e sono il presupposto affinché il documento non resti inefficace.

Misurazione e periodi di riferimento: chi misura cosa, come e per quali periodi? Quale periodo di calcolo vale per la disponibilità e quale valore di misurazione è determinante in caso di controversia?

Tempi di supporto: fissare separatamente i tempi di reazione, intervento e risoluzione e differenziarli in base al grado di gravità (modello di incidente graduato con livelli di gravità); regolare inoltre la raggiungibilità del supporto.

Finestre di manutenzione ed esclusioni: definire quali aspetti rientrano in una finestra di manutenzione e quali condizioni quadro si applicano (comunicazione preventiva, orari chiaramente definiti). Circoscrivere le esclusioni: i candidati tipici sono le dipendenze da terzi, gli attacchi DDoS e la forza maggiore.

Conseguenze e coordinamento: è indispensabile una regolamentazione delle conseguenze delle violazioni dello SLA con relativi meccanismi di escalation, altrimenti lo SLA rimane privo di efficacia. Verificare infine se i livelli di servizio, il contratto SaaS, le CG, il contratto di elaborazione dei dati (DPA) e la documentazione sulla protezione dei dati siano coordinati tra loro.

Ordine di priorità dei criteri SLA più importanti per i contratti SaaS svizzeri