Clausole penali e risarcimento danni nelle SLA dei servizi di Hosting - 🏆 Managed Server
17 Agosto 2022

Clausole penali e risarcimento danni nelle SLA dei servizi di Hosting

Qual è il risarcimento dei danni per un hosting che perde i vostri dati? Tocchiamo dal vivo un argomento poco conosciuto dai clienti e poco trattato dai fornitori.

service level agreement Hosting

C’è un aspetto poco conosciuto sia per il cliente che per i fornitori inerentemente ai diritti che un cliente ha nel momento in cui ad esempio si trova il sito hackerato, compromesso, offline, o addirittura irrimediabilmente perso.

Mentre per i primi tre casi, l’evenienza è abbastanza frequente in base al tipo di manutenzione, ad esempio, e al tipo di connettività, la perdita totale del sito in modo irrimediabile è cosa fortunatamente piuttosto rara, sebbene non impossibile come abbiamo ad esempio visto con il triste incendio di OVH diversi mesi orsono, che hanno in qualche modo aperto e chiuso altrettanto velocemente un dibattito su quali sarebbero stati i risarcimenti per quei milioni di utenti che hanno perso irrimediabilmente i loro siti.

Tra chi invocava condanne penali per l’amministratore delegato, e chi mostrava improbabili esercizi di stile nel campo del diritto tirando in ballo il codice al consumo e la GDPR, alla fine è stato evidente che tutti gli sforzi ufficiosi ed ufficiali sono stati liquidati, rimandando ad una lenta ed efficace lettura e comprensione del contratto sottoscritto in tutte le parti che non offriva alcun rimborso o risarcimento danni.

Datacenter OVH Incendio 2021 foto

Al di la del discorso di OVH che ha avuto solo come scopo quello di introdurre un argomento pruriginoso, poco trattato sia dai clienti che dai fornitori, è bene dire che in questo articolo non parleremo di un fornitore o un caso particolare, ma capire quale sia la logica alla base di quel “braccio di ferro” tra cliente e fornitore, di cui il primo cerca a tutti i costi di ottenere forme di tutela, garanzia e ristoro del danno maggiore possibile e mentre il fornitore cerca a sua volta di manlevarsi di tutte le responsabilità civili e penali.

Ci si trova di fatto di fronte ad uno scaricabarile, laddove qualsiasi esperto di diritto bacchetterebbe la definizione appena data “scaricabarile”, che non troverebbe accoglimento in alcuna aula di tribunale, ma che ben si presta all’introduzione dell’argomento delle responsabilità dell’Hosting provider in seguito di un danno al proprio cliente.

SLA o Service Level Agreement cosa significa?

service level agreement (in italiano: accordo sul livello del servizio), in sigla SLA, sono strumenti contrattuali attraverso i quali si definiscono le metriche di servizio (es. qualità di servizio) che devono essere rispettate da un fornitore di servizi (provider) nei confronti dei propri clienti/utenti. Di fatto, una volta stipulato il contratto, assumono il significato di obblighi contrattuali.

Un impegno a livello di servizio (SLC) è una forma più ampia e generalizzata di SLA. I due differiscono perché uno SLA è bidirezionale e coinvolge due squadre. Al contrario, un SLC è un obbligo unidirezionale che stabilisce ciò che un gruppo può garantire ai propri clienti in un dato momento.

Perché gli SLA sono importanti?

I fornitori di servizi hanno bisogno di SLA per aiutarli a gestire le aspettative dei clienti e definire i livelli di gravità e le circostanze in cui non sono responsabili per interruzioni o problemi di prestazioni. I clienti possono anche beneficiare degli SLA perché il contratto descrive le caratteristiche di prestazione del servizio, che possono essere confrontate con gli SLA di altri fornitori, e stabilisce i mezzi per risolvere i problemi del servizio.

Lo SLA è in genere uno dei due accordi fondamentali che i fornitori di servizi hanno con i propri clienti. Molti fornitori di servizi stabiliscono un contratto di servizio principale per stabilire i termini e le condizioni generali in cui lavoreranno con i clienti.

Lo SLA è spesso incorporato per riferimento nel contratto di servizio principale del fornitore di servizi. Tra i due contratti di servizio, lo SLA aggiunge una maggiore specificità per quanto riguarda i servizi forniti e le metriche che verranno utilizzate per misurarne le prestazioni. Gli impegni di servizio definiscono i servizi inclusi nell’offerta di servizi.

Quando l’outsourcing IT è emerso alla fine degli anni ’80, gli SLA si sono evoluti come meccanismo per governare tali relazioni. Gli accordi sul livello di servizio fissano le aspettative per le prestazioni di un fornitore di servizi e stabiliscono sanzioni per il mancato raggiungimento degli obiettivi e, in alcuni casi, bonus per il loro superamento. Poiché i progetti di outsourcing erano spesso personalizzati per un particolare cliente, gli SLA di outsourcing venivano spesso redatti per governare e regolamentare un progetto specifico.

Come servizi gestiti e cloud computing; i servizi diventano più prevalenti, gli SLA si evolvono per affrontare i nuovi approcci. I servizi condivisi, piuttosto che le risorse personalizzate, caratterizzano i nuovi metodi di contrattazione; quindi, gli impegni a livello di servizio vengono spesso utilizzati per produrre accordi generali destinati a coprire tutti i clienti di un fornitore di servizi.

Chi ha bisogno di un contratto di servizio?

Si pensa che gli SLA abbiano avuto origine con i fornitori di servizi di rete, ma ora sono ampiamente utilizzati in una vasta gamma di campi legati all’IT. Alcuni esempi di settori che stabiliscono SLA includono fornitori di servizi IT e fornitori di servizi gestiti, nonché fornitori di servizi Internet e cloud computing.

Le organizzazioni IT aziendali, in particolare quelle che hanno abbracciato la gestione dei servizi IT , stipulano SLA con i propri clienti interni, ovvero gli utenti di altri dipartimenti dell’azienda. Un reparto IT crea uno SLA in modo che i suoi servizi possano essere misurati, giustificati e magari confrontati con quelli dei fornitori in outsourcing.

Componenti chiave di uno SLA

I componenti chiave di un contratto di servizio includono:

Panoramica dell’accordo. Questa prima sezione espone le basi dell’accordo, comprese le parti coinvolte, la data di inizio e un’introduzione generale dei servizi forniti.

Descrizione dei servizi. Lo SLA necessita di descrizioni dettagliate di ogni servizio offerto, in tutte le possibili circostanze, con i tempi di consegna inclusi. Le definizioni dei servizi dovrebbero includere come vengono forniti i servizi, se viene offerto il servizio di manutenzione, quali sono gli orari di funzionamento, dove esistono dipendenze, uno schema dei processi e un elenco di tutte le tecnologie e le applicazioni utilizzate.

Esclusioni. Anche i servizi specifici che non vengono offerti dovrebbero essere chiaramente definiti per evitare confusione ed eliminare spazio per ipotesi di altre parti.

Prestazioni di servizio. Le metriche di misurazione delle prestazioni e i livelli di prestazione sono definiti. Il cliente e il fornitore di servizi dovrebbero concordare un elenco di tutte le metriche che utilizzeranno per misurare i livelli di servizio del fornitore.

Riparare. Il compenso o il pagamento dovrebbero essere definiti se un fornitore non è in grado di adempiere adeguatamente al proprio SLA.

Parti interessate. Definisce chiaramente le parti coinvolte nell’accordo e ne stabilisce le responsabilità.

Sicurezza. Sono definite tutte le misure di sicurezza che saranno adottate dal fornitore del servizio. In genere, ciò include la redazione e il consenso su accordi antibracconaggio, sicurezza IT e non divulgazione.

Gestione del rischio e ripristino di emergenza. I processi di gestione del rischio e un piano di ripristino di emergenza sono stabiliti e comunicati chiaramente.

Monitoraggio e reportistica del servizio. Questa sezione definisce la struttura di rendicontazione, gli intervalli di monitoraggio e le parti interessate coinvolte nell’accordo.

Revisione periodica e processi di cambiamento. Lo SLA e tutti gli indicatori chiave di prestazione ( KPI ) stabiliti dovrebbero essere rivisti regolarmente. Questo processo è definito così come il processo appropriato per apportare modifiche.

Processo di cessazione. Lo SLA dovrebbe definire le circostanze in cui l’accordo può essere risolto o scadrà. Dovrebbe essere stabilito anche il periodo di preavviso da entrambe le parti.

Firme. Infine, tutte le parti interessate e i partecipanti autorizzati di entrambe le parti devono firmare il documento per dimostrare la loro approvazione di ogni dettaglio e processo.

Quali sono i tre tipi di SLA?

Esistono tre tipi di base di SLA: contratto del livello di servizio del cliente, interno e multilivello.

Un contratto a livello di servizio clienti è tra un fornitore di servizi e i suoi clienti esterni. A volte è chiamato contratto di servizio esterno.

In uno SLA basato sul cliente, il cliente e il fornitore di servizi raggiungono un accordo negoziato sui servizi che verranno forniti. Ad esempio, un’azienda può negoziare con il fornitore di servizi IT che gestisce il proprio sistema di contabilità fornitori per definire in dettaglio le proprie specifiche relazioni e aspettative.

Un contratto a livello di servizio clienti include:

  • i dettagli esatti del servizio previsto dal cliente;
  • disposizioni della disponibilità del servizio;
  • standard per ogni livello di servizio;
  • le responsabilità di ciascuna parte;
  • procedure di escalation; e
  • termini per la cancellazione.

Uno SLA interno è tra un’organizzazione e il suo cliente interno: potrebbe trattarsi di un’altra organizzazione, dipartimento o sito.

Ciò significa che, sebbene un’azienda possa avere uno SLA aperto con ciascuno dei suoi clienti, potrebbe anche avere uno SLA separato tra i suoi reparti marketing e vendite.

Ad esempio, il reparto vendite di un’azienda ha quasi € 10.000 di vendite ogni mese, con ogni vendita del valore di € 500. Se il tasso di chiusura medio del team di vendita è del 20%, le vendite sanno che il marketing deve fornire almeno 100 lead qualificati ogni mese.

Pertanto, il capo del reparto marketing dell’organizzazione può collaborare con il capo del reparto vendite su uno SLA che prevede che il reparto marketing invierà 100 contatti qualificati al direttore delle vendite entro una data specifica ogni mese.

Questo contratto sul livello di servizio potrebbe prevedere che includerà quattro rapporti di stato settimanali ogni mese inviati dal marketing alle vendite per garantire che i contatti che il team di vendita sta ottenendo consentano loro di raggiungere il loro obiettivo di vendita mensile.

Uno SLA multilivello dividerà l’accordo in vari livelli specifici per una serie di clienti che utilizzano il servizio. Ad esempio, un fornitore di software come servizio ( SaaS ) potrebbe offrire servizi di base e supporto a tutti i clienti che utilizzano un prodotto, ma potrebbe anche offrire fasce di prezzo diverse al momento dell’acquisto del prodotto che determinano livelli di servizio diversi. Questi diversi livelli di servizio saranno stratificati nello SLA multilivello.

Esempi di SLA

Un esempio specifico di SLA è un contratto sul livello di servizio del data center. Questo SLA includerà:

  • Una garanzia di uptime che indica la percentuale di tempo in cui il sistema è disponibile. Niente di meno che un tempo di attività del 99,99% dovrebbe essere considerato accettabile per i moderni data center di livello aziendale.
  • Una definizione di condizioni ambientali adeguate. Ciò dovrebbe includere le pratiche di supervisione e manutenzione, nonché gli standard di riscaldamento e raffreddamento.
  • La promessa del supporto tecnico. I clienti devono essere certi che il personale del data center risponderà in modo rapido ed efficace a qualsiasi problema e sarà disponibile in qualsiasi momento per risolverlo.
  • Precauzioni di sicurezza dettagliate che manterranno al sicuro i beni del cliente. Ciò potrebbe includere misure di sicurezza informatica che proteggono dagli attacchi informatici, nonché misure di sicurezza fisica che limitano l’accesso al data center al personale autorizzato. Le funzionalità di sicurezza fisica potrebbero includere l’autenticazione a due fattori , le voci gated, le telecamere e l’autenticazione biometrica.

Un altro esempio specifico di SLA è un contratto sul livello di servizio del provider di servizi Internet. Questo SLA includerà una garanzia di uptime, ma definirà anche le aspettative di consegna dei pacchetti e la latenza. La consegna dei pacchetti si riferisce alla percentuale di pacchetti di dati ricevuti rispetto al numero totale di pacchetti di dati inviati. La latenza è la quantità di tempo necessaria a un pacchetto per viaggiare tra client e server.

Come convalidare i livelli SLA

La verifica dei livelli di erogazione del servizio del fornitore è necessaria per l’applicazione di un contratto di servizio. Se lo SLA non venisse adeguatamente adempiuto, il cliente potrebbe essere in grado di richiedere il risarcimento concordato nel contratto.

La maggior parte dei fornitori di servizi rende disponibili le proprie statistiche sul livello di servizio tramite un portale online. Ciò consente ai clienti di monitorare se viene mantenuto il livello di servizio corretto. Se scoprono che non lo è, il portale consente anche ai clienti di vedere se hanno diritto a un risarcimento.

Questi sistemi e processi sono spesso controllati da società terze specializzate. In tal caso, è necessario che anche la terza parte sia inclusa nelle trattative SLA. Ciò fornirà loro chiarezza sui livelli di servizio che dovrebbero essere monitorati e spiegazioni su come rintracciarli.

Sono inoltre disponibili strumenti che automatizzano l’acquisizione e la visualizzazione dei dati sulle prestazioni a livello di servizio.

SLA e clausole di indennizzo

Un indennizzo è un obbligo contrattuale assunto da una parte – l’indennizzo – di risarcire i danni, le perdite e le responsabilità subite da un’altra parte – l’indennizzo – o da una terza parte. All’interno di uno SLA, una clausola di indennizzo richiederà al fornitore di servizi di riconoscere che il cliente non è responsabile per eventuali costi sostenuti per violazione delle garanzie contrattuali. La clausola risarcitoria imporrà inoltre al prestatore di servizi il pagamento al cliente di eventuali spese di contenzioso da parte di terzi derivanti dall’inadempimento contrattuale.

Per limitare la portata degli indennizzi, un fornitore di servizi può:

  • consultare un avvocato;
  • limitare il numero degli indennizzi;
  • stabilire limiti monetari per la clausola;
  • creare limiti di tempo;
  • definire il punto in cui inizia la responsabilità dell’indennizzo.

Metriche delle prestazioni SLA

Gli SLA includono metriche per misurare le prestazioni del fornitore di servizi. Poiché può essere difficile selezionare metriche corrette per il cliente e il fornitore di servizi, è importante che le metriche siano sotto il controllo del fornitore di servizi. Se il fornitore di servizi non è in grado di controllare se una metrica si comporta come specificato, non è corretto ritenere il fornitore responsabile per quella metrica.

E dovrebbe essere facile raccogliere accuratamente i dati per le metriche: l’acquisizione automatica dei dati sarebbe la cosa migliore. Inoltre, lo SLA dovrebbe specificare una linea di base ragionevole per le metriche, che può essere perfezionata quando sono disponibili più dati su ciascuna metrica.

Gli SLA stabiliscono le aspettative dei clienti in merito alle prestazioni e alla qualità del fornitore di servizi in diversi modi. Alcune metriche che gli SLA possono specificare includono:

  • Disponibilità e percentuale di uptime . La quantità di tempo in cui i servizi sono in esecuzione e accessibili al cliente. Il tempo di attività viene generalmente monitorato e riportato per mese di calendario o ciclo di fatturazione.
  • benchmark di prestazione specifici.La performance effettiva sarà periodicamente confrontata con questi benchmark.
  • Tempo di risposta del fornitore di servizi. Il tempo impiegato dal fornitore di servizi per rispondere al problema o alla richiesta di un cliente. Un fornitore di servizi più grande può gestire un service desk per rispondere alle richieste dei clienti.
  • Tempo di risoluzione. Il tempo necessario per la risoluzione di un problema una volta registrato dal fornitore di servizi.
  • Tasso di abbandono. La percentuale di chiamate in coda che i clienti abbandonano in attesa di risposta.
  • Risultati aziendali. Utilizzo dei KPI per determinare in che modo i contributi dei fornitori di servizi influiscono sulle prestazioni dell’azienda.
  • Tasso di errore. La percentuale di errori in un servizio, ad esempio errori di codifica e scadenze mancate.
  • Risoluzione di prima chiamata. La percentuale di chiamate in entrata dei clienti che vengono risolte senza la necessità di essere richiamate dall’help desk.
  • Tempo medio di recupero. Il tempo necessario per il ripristino dopo un’interruzione del servizio.
  • Sicurezza. Il numero di vulnerabilità sconosciute, ad esempio. Se si verifica un incidente, i fornitori di servizi devono dimostrare di aver adottato misure preventive.
  • Fattore di servizio del tempo. La percentuale di chiamate in coda che i rappresentanti del servizio clienti rispondono entro un determinato intervallo di tempo.
  • Tempo di consegna. Il tempo impiegato da un fornitore di servizi per risolvere un problema specifico una volta ricevuto.

Altre metriche includono la pianificazione per la notifica in anticipo delle modifiche alla rete che potrebbero influire sugli utenti e le statistiche generali sull’utilizzo del servizio.

Uno SLA può specificare disponibilità, prestazioni e altri parametri per diversi tipi di infrastruttura del cliente, comprese reti interne, server e componenti dell’infrastruttura, come gruppi di continuità.

Cosa succede se i livelli di servizio concordati non vengono raggiunti?

Gli accordi sul livello di servizio includono sanzioni concordate nel caso in cui un fornitore di servizi non soddisfi i livelli di servizio concordati. Tali rimedi potrebbero essere riduzioni del canone o crediti di servizio a fronte dei canoni sostenuti dal cliente, nonché la risoluzione del contratto per ripetuti fallimenti.

I clienti possono far valere questi crediti di servizio quando i fornitori di servizi non rispettano gli standard di prestazione concordati. In genere, il cliente e il fornitore di servizi concordano di mettere a rischio una determinata percentuale del canone mensile. I crediti di servizio vengono prelevati da quelle commissioni a rischio quando il venditore non rispetta gli SLA.

Lo SLA dovrebbe dettagliare come verranno calcolati i crediti di servizio. Ad esempio, il cliente e il venditore potrebbero sviluppare una formula che fornisce crediti di servizio in base alla quantità di tempi di inattività che supera i termini dello SLA. Un fornitore di servizi può limitare le penali di performance a un importo massimo in dollari per limitare l’esposizione.

Lo SLA includerà anche una sezione che descrive in dettaglio le esclusioni, ovvero le situazioni in cui le garanzie di uno SLA – e le sanzioni per il mancato rispetto delle stesse – non si applicano. L’elenco potrebbe includere eventi come disastri naturali o atti terroristici. Questa sezione viene talvolta definita clausola di forza maggiore, che mira a esonerare il fornitore di servizi da eventi al di fuori del suo ragionevole controllo.

Sanzioni

Le sanzioni SLA sono misure disciplinari che esistono per garantire il mantenimento dei termini del contratto. Queste sanzioni differiscono da contratto a contratto. Sono i seguenti:

  • Disponibilità del servizio. Include fattori quali il tempo di attività della rete, le risorse del data center e la disponibilità del database. Le sanzioni dovrebbero essere aggiunte come deterrenti contro i tempi di fermo del servizio, che potrebbero influire negativamente sull’attività.
  • Qualità del servizio. Comprende la garanzia delle prestazioni, il numero di errori consentiti in un prodotto o servizio, le lacune di processo e altri problemi relativi alla qualità.

Oltre ai crediti di servizio, potrebbero esserci:

  • Sanzioni pecuniarie. Richiedere al venditore di rimborsare al cliente l’importo del danno concordato nel contratto.
  • Estensione della licenza o supporto. Richiede al venditore di estendere la durata della licenza o di offrire al cliente supporto aggiuntivo gratuito. Ciò potrebbe includere lo sviluppo e la manutenzione.

Tali sanzioni devono essere specificate nella lingua dello SLA o non saranno esecutive. Inoltre, alcuni clienti potrebbero non pensare che il credito di servizio o le penali per l’estensione della licenza siano un compenso adeguato poiché potrebbero mettere in dubbio il valore di continuare a ricevere i servizi di un fornitore che non è in grado di soddisfare i suoi livelli di qualità.

Di conseguenza, può valere la pena considerare una combinazione di sanzioni, oltre a includere un incentivo, come un bonus monetario, per un lavoro più che soddisfacente.

Considerazioni sulle metriche SLA

Quando si sceglie quali metriche di performance includere nello SLA, un’azienda dovrebbe considerare i seguenti fattori.

Le misurazioni dovrebbero motivare il comportamento corretto. Quando si definiscono le metriche, entrambe le parti dovrebbero ricordare che l’obiettivo delle metriche è motivare il comportamento appropriato per conto del fornitore di servizi e del cliente.

Le metriche dovrebbero riflettere solo i fattori che rientrano nel ragionevole controllo del fornitore di servizi. Le misurazioni dovrebbero anche essere facili da raccogliere. Inoltre, entrambe le parti dovrebbero resistere alla scelta di quantità eccessive di metriche o misurazioni che producono grandi quantità di dati. Tuttavia, anche l’inclusione di un numero insufficiente di metriche può essere un problema, poiché mancarne una potrebbe far sembrare che il contratto sia stato violato.

Affinché le metriche stabilite siano utili, è necessario stabilire una linea di base adeguata con le misurazioni impostate su livelli di prestazione ragionevoli e raggiungibili. Questa linea di base sarà probabilmente ridefinita durante il coinvolgimento delle parti nell’accordo, utilizzando i processi specificati nella sezione revisione periodica e modifica dello SLA.

Earn Back o Guadagna indietro

Un earn back è una disposizione che può essere inclusa nello SLA che consente ai fornitori di riguadagnare crediti a livello di servizio se effettuano prestazioni pari o superiori al livello di servizio standard per un determinato periodo di tempo. I guadagni di ritorno sono una risposta alla standardizzazione e alla popolarità dei crediti a livello di servizio.

I crediti a livello di servizio, o semplicemente crediti di servizio, dovrebbero essere l’unico ed esclusivo rimedio a disposizione dei clienti per compensare i guasti a livello di servizio. Un credito di servizio sottrae una somma di denaro dall’importo totale da pagare in base al contratto se il fornitore di servizi non soddisfa gli standard di prestazione e prestazione del servizio.

Se entrambe le parti accettano di includere i guadagni di ritorno nello SLA, il processo dovrebbe essere definito attentamente all’inizio della negoziazione e integrato nella metodologia del livello di servizio.

Quando rivedere uno SLA

Un contratto di servizio non è un documento statico. Piuttosto, uno SLA dovrebbe essere aggiornato e rivisto regolarmente con nuove informazioni. La maggior parte delle aziende rivede i propri SLA annualmente o semestralmente. Tuttavia, più rapidamente cresce un’organizzazione, più spesso dovrebbe rivedere e rivedere i suoi SLA.

Sapere quando e quando non apportare modifiche a uno SLA è una parte fondamentale della gestione della relazione cliente/fornitore di servizi. Le due parti dovrebbero incontrarsi a un programma prestabilito per rivedere il loro SLA e assicurarsi che soddisfi ancora i requisiti di entrambe le parti.

Uno SLA dovrebbe essere rivisto:

  • quando i requisiti aziendali del cliente sono cambiati, ad esempio, i suoi requisiti di disponibilità aumentano perché ha creato un sito di e-commerce che vende molto di più;
  • se c’è un cambiamento nei carichi di lavoro;
  • se gli strumenti di misurazione, i processi e le metriche sono migliorati;
  • quando il fornitore di servizi smette di offrire un servizio esistente o aggiunge un nuovo servizio;
  • quando le capacità tecniche del fornitore di servizi cambiano, ad esempio, nuove tecnologie o apparecchiature più affidabili consentono al venditore di fornire tempi di risposta più rapidi; tuttavia, il fornitore di servizi dovrebbe rivedere il suo SLA ogni 18-24 mesi anche se le sue capacità o servizi non sono cambiati molto per ridurre i contenuti imprecisi o non aggiornati.

Clausole risarcitorie contrattuali per danni nei contratti di Hosting.

Di norma la proposta di clausole risarcitorie del danno nei contratti di Hosting vanno intese come clausole vessatorie ovvero delle clausole contrattuali che – malgrado la buona fede (ovvero indipendentemente dall’intenzione) – determinano a carico del consumatore un significativo squilibrio dei diritti e degli obblighi derivanti dal contratto.

Il non adempimento ad una SLA non da automaticamente diritto ad alcun risarcimento del danno, soprattutto laddove il contratto faccia esplicitamente menzione alla manleva del fornitore di hosting.

Ecco perchè la SLA è sicuramente un ottimo punto di partenza che potrebbe rivelarsi assolutamente vana qualora non si possa accedere poi a dei risarcimenti nel caso della violazione della stessa, risarcimenti che ovviamente il fornitore nel suò più evidente ed esplicito e legittimo interesse cercherà di evitare tramite opportune clausole di manleva che hanno il suo perchè e denota comunque la serietà e professionalità di un fornitore che non si getta a capofitto in contratti che lo vedono con un’eccessiva responsabilità soprattutto se in comparazione di quelli che sono gli standard di mercato, ove nessun hosting o quasi è disposto ad accollarsi il risarcimento dei danni e non manlevarsi.

Cosa dovrebbe aspettarsi un cliente che si vede un fornitore dire sempre di si anche a clausole risarcitorie molto pericolose in grado di minare il futuro imprenditoriale dell’impresa? Dire sempre di si non è in alcun modo sinonimo di professionalità, così come l’estrema accondiscendenza di un fornitore denota approssimazione e inesperienza, ovvero un chiaro campanello di allarme che mette in discussione il fornitore di hosting stesso su tutti i fronti.

Yes Man

Immaginiamo ad esempio che il baretto sotto casa a gestione familiare con un fatturato di 100 mila euro l’anno, ed un utile di appena 20 mila decidesse di farci ospitare il loro sito costato 1000 euro, ad un costo di 100€ l’anno, ed in fase contrattuale pretendessero l’accettazione una clausola vessatoria in cui in caso di attacco hacker risarciremmo 50 mila euro a titolo di risarcimento danni.

Si capisce sin da subito come tale richiesta sia squilibrata nella classica formula bonus / malus che vediamo ad esempio nelle polizze assicurative (specie quelle americane). Sappiamo che il prezzo dell’assicurazione dell’auto per un neopatentato è maggiore di quella di un 50 enne appartenente alla minima classe di rischio essendo un guidatore modello, e che soprattutto in caso di sinistro, l’assicurazione faccia riferimento a tabelle e riferimenti superpartes per valutare il danno da risarcire. Se la FIAT 500 del ’48 in cui avete conosciuto vostra moglie insomma ha un valore simbolico ed affettivo senza paragoni, la vostra richiesta di danni morali per 100 mila euro, sarà liquidata dal liquidatore con le tabelle vigenti su Quattroruote, con 5 o 6 mila euro insomma. A prescindere dalle vostre ragioni, ci sono dei valori inopinabili da rispettare.

Un premio in contrapposizione ad un massimale all’interno di una proposta assicurativa, permette insomma di valutare un rischio, la probabilità dello stesso, l’incidenza reale sul business del cliente, e da li formulare un canone che comprende oltre che ai costi vivi di esercizio, il ricarico che costituisce la merginalità, anche il premio per l’azienda di hosting che decide di far fronte a tali impegni contrattuali.

Un cliente che non pretende nulla che il servizio in best effort (così come lo abbiamo proposto nella nostra offerta) avrà il costo del canone di esercizio. Un cliente che invece pretende ALTRO, avrà il costo del canone di esercizio più il costo per poter fornire ALTRO.

Prendendo l’esempio sopra del baretto sotto casa, in cui si chiede un risarcimento danno di 50 mila euro in caso di attacco hacker, è normalissimo, che il fornitore di hosting andrà a specificare le sue responsabilità e quelle del cliente. Da dove è entrato l’attaccante? Dal sistema linux gestito dall’hosting o da un plugin WordPress non aggiornato gestito dal webmaster? Ed ecco qui una serie di clausole che iniziano ad essere estremamente puntigliose e specifiche per mettere nero su bianco le casistiche che vedono l’hosting responsabile e dunque imputabile di risarcire il cliente.

Quale hosting provider accetterebbe di esporsi per 50 mila euro di risarcimento, per un canone di 100 euro l’anno? Ovviamente nessuno.

Diverso è esporsi per 50 mila euro a fronte di un canone di 5 mila euro anno. Sebbene possa sembrare un’assurdità, è vero che cambiando il tipo di tecnologia e gestione del sistema, tramite l’installazione di ulteriori precauzioni, sistemi di hashing dei file e notifica variazioni, ecc… ecc.., l’hosting può arrivare a calcolare statisticamente e probabilisticamente parlando che l’evento che comporterebbe un risarcimento di 50 mila euro, ha una probabilità dello 0,5% e pertanto ha senso accettare e correre il rischio a fronte di un canone annuale di 5000 euro, e non 100€.

Ci si troverebbe di fatto ad una controproposta in cui il fornitore di hosting accetta la clausola risarcitoria proponendo il nuovo canone di hosting, che però diventa assolutamente non accettabile e troppo esoso per il cliente.

Cosa cerca di ottenere il cliente?

A questo punto bisogna necessariamente porsi la domanda, di cosa stia cercando il cliente. Come può ad esempio un sito di un baretto che fattura poco pretendere un risarcimento di 50 mila euro per un sito web che ne è costato appena 2000? Perché ad esempio non chiedere il risarcimento dei costi vivi della realizzazione del sito più eventuali, per un importo di 5000 euro e non invece 50 mila?

C’è forse temerarietà? Ci si trova di fronte ad uno speculatore che sta gettando le basi per poter procedere legalmente per un risarcimento danni magari per un sito attaccato da un suo amico?

Questi sono dei campanelli di allarme che vanno sempre considerati e valutati pensando male. Nel mondo dell’imprenditoria la gentilezza è un aspetto puramente formale ma non sostanziale.

Vediamo dunque i campanelli di allarme standard che un fornitore di Hosting dovrebbe valutare nel momento in cui il cliente rigetta il contratto standard ma lo integra con clausole risarcitorie e vessatorie del genere.

Risarcimento del danno generico.

Di fatto il cliente scrive nel contratto in una clausola vessatoria che in caso di responsabilità del fornitore (o presunta tale, ci sarà sempre una CTU che costerà cifre assurde e che in teoria pagherà il soccombente), avrà diritto a richiedere dei danni. Non spiega di che tipo, inerenti a quali ambiti, mancato guadagno, cessato lucro, danni materiali, danni morali, o altro, ne specifica un importo che è di fatto un massimale.

Il cliente pretende di fatto un assegno in bianco da poter riempire a piacimento con pezze di appoggio (anche reali) di fronte ad un canone di servizio invece ben definito e delineato.

Viene meno insomma la proporzionalità del premio in base al massimale che di fatto è indefinito. È possibile che il risarcimento arrivi ad un milione di euro, o un miliardo, a fronte di 100euro di canone mensile.

Mancanza di delineazione delle responsabilità.

Il cliente non specifica in modo estremamente preciso i domini e contesti di competenza, ma tende ad accollare tutte le responsabilità al fornitore anche per conseguenze non a lui imputabili.

Il cliente che ad esempio pretende un risarcimento del danno a fronte di hackeraggio, non avendo l’onestà intellettuale di specificare che attacchi che vedrà come causa l’applicazione (plugin non aggiornati, e simili) e che rigirando la responsabilità al fornitore, non solo non si pre-occupa di mantenere aggiornata l’installazione a livello applicativo, ma magari pretende un risarcimento di 10 mila euro per danni di immagine in caso di hackeraggio.

Le responsabilità e le aree di competenza insomma vanno sempre ben delineate in maniera esplicita ed eloquente, ribadendo che tutto quello che non è esplicitamente competenza del fornitore lo manleva in modo diretto ed indiretto dalle relative conseguenze.

Cosa cerca di ottenere invece il fornitore?

Il fornitore di Hosting cerca di vendere un servizio di Hosting, minimizzando i costi e massimizzando i profitti secondo le basi della ricerca operativa. A tal proposito tende a sgravarsi di responsabilità civili in modo esplicito ed eloquente a livello contrattuale anche per fermare nell’immediato qualsiasi iniziativa legale che costerebbe comunque cifre ingenti e non proporzionate al canone di noleggio.

Il gioco deve valere la candela insomma.

Raramente un fornitore ha interesse ad esporsi se il rischio non è estremamente calcolato e le SLA sono estremamente vantaggiose.

L’uptime garantito di fronte ad un risarcimento del danno scenderà inevitabilmente dal 99,99% al 99,8% su base annuale che significa di fatto 17ore di down all’anno.

In base al tipo di massimale risarcibile ed in base al tipo del tipo di danno, il canone di esercizio può aumentare in modo molto importante e di norma MAI inferiore al 20% del massimale coperto.

Ad esempio, dietro una copertura per un massimale di 50 mila euro, il fornitore può applicare un extra al costo di hosting standard pattuito di tra i 5000 e le 10000 euro annue.

Ovviamente in alcun modo il fornitore ha obblighi di accettare clausole di questo tipo, considerando che non sempre correre un rischio può essere cosa buona a livello imprenditoriale e pertanto il fornitore semplicemente utilizza il modello standard di contratto in suo possesso che di fatto è un contratto di tipo best effort senza risarcimento del danno se non per motivi dolosi.

Trovare un equilibrio tra le esigenze del cliente e quelle del fornitore.

Il modo migliore per trovare un equilibrio tra le esigenze del cliente e quelle del fornitore è quello di instaurare le condizioni pecuniarie per un rapporto win – win in cui tutti vincono.

Il cliente si accerta dell’impegno massimo del fornitore nel conseguire in modo assolutamente virtuoso e paranoico la manutenzione del sito del cliente per tutte le aree di competenza e servizi di responsabilità del fornitore.

Il fornitore si accerta che a fronte del suo impegno atto a scongiurare un rischio, tendente a zero ma mai zero, ci sia un premio di tipo economico (che a sua volta potrebbe ad esempio essere utilizzato anche per accendere una polizza assicurativa con franchigia specifica per il cliente e scaricare il rischio).

Come si giunge a questo equilibrio prendendo come caso l’esempio sopra del baretto che pretendeva un risarcimento danni di 50 mila euro in caso di hackeraggio ?

  1. Si abbassa il massimale risarcitorio da 50 mila euro a 5000 euro.
  2. Si specifica che qualsiasi attacco che proviene da attacchi a livello applicativo manlevano il fornitore.
  3. Si specifica che qualsiasi attacco di tipo 0day a livello sistemistico, manlevano il fornitore
  4. Si aumenta il canone annuale da 100€ a 500€

Questo, ad esempio, nel nostro caso potrebbe essere un buon equilibrio, non ottimale, ma sicuramente degno di valutazione per una successiva probabile accettazione.

Verosimilmente per un altro fornitore potrebbe essere non accettabile, e sarebbe comunque una sua scelta legittima.

 

 

 

Hai dei dubbi? Non sai da dove iniziare? Contattaci !

Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Chatta con noi

Chatta direttamente con il nostro supporto prevendita.

0256569681

Contattaci telefonicamente negli orari d’ufficio 9:30 – 19:30

Contattaci online

Apri una richiesta direttamente nell’area dei contatti.

INFORMAZIONI

Managed Server S.r.l. è un player italiano di riferimento nel fornire soluzioni avanzate di sistemistica GNU/Linux orientate all’alta performance. Con un modello di sottoscrizione dai costi contenuti e prevedibili, ci assicuriamo che i nostri clienti abbiano accesso a tecnologie avanzate nel campo dell’hosting, server dedicati e servizi cloud. Oltre a questo, offriamo consulenza sistemistica su sistemi Linux e manutenzione specializzata in DBMS, IT Security, Cloud e molto altro. Ci distinguiamo per l’expertise in hosting di primari CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart e Magento, affiancato da un servizio di supporto e consulenza di alto livello adatto per la Pubblica Amministrazione, PMI, ed aziende di qualsiasi dimensione.

Red Hat, Inc. detiene i diritti su Red Hat®, RHEL®, RedHat Linux®, e CentOS®; AlmaLinux™ è un marchio di AlmaLinux OS Foundation; Rocky Linux® è un marchio registrato di Rocky Linux Foundation; SUSE® è un marchio registrato di SUSE LLC; Canonical Ltd. detiene i diritti su Ubuntu®; Software in the Public Interest, Inc. detiene i diritti su Debian®; Linus Torvalds detiene i diritti su Linux®; FreeBSD® è un marchio registrato di The FreeBSD Foundation; NetBSD® è un marchio registrato di The NetBSD Foundation; OpenBSD® è un marchio registrato di Theo de Raadt. Oracle Corporation detiene i diritti su Oracle®, MySQL®, e MyRocks®; Percona® è un marchio registrato di Percona LLC; MariaDB® è un marchio registrato di MariaDB Corporation Ab; REDIS® è un marchio registrato di Redis Labs Ltd. F5 Networks, Inc. detiene i diritti su NGINX® e NGINX Plus®; Varnish® è un marchio registrato di Varnish Software AB. Adobe Inc. detiene i diritti su Magento®; PrestaShop® è un marchio registrato di PrestaShop SA; OpenCart® è un marchio registrato di OpenCart Limited. Automattic Inc. detiene i diritti su WordPress®, WooCommerce®, e JetPack®; Open Source Matters, Inc. detiene i diritti su Joomla®; Dries Buytaert detiene i diritti su Drupal®. Amazon Web Services, Inc. detiene i diritti su AWS®; Google LLC detiene i diritti su Google Cloud™ e Chrome™; Microsoft Corporation detiene i diritti su Microsoft®, Azure®, e Internet Explorer®; Mozilla Foundation detiene i diritti su Firefox®. Apache® è un marchio registrato di The Apache Software Foundation; PHP® è un marchio registrato del PHP Group. CloudFlare® è un marchio registrato di Cloudflare, Inc.; NETSCOUT® è un marchio registrato di NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, e Kibana® sono marchi registrati di Elastic N.V. Hetzner Online GmbH detiene i diritti su Hetzner®; OVHcloud è un marchio registrato di OVH Groupe SAS; cPanel®, L.L.C. detiene i diritti su cPanel®; Plesk® è un marchio registrato di Plesk International GmbH; Facebook, Inc. detiene i diritti su Facebook®. Questo sito non è affiliato, sponsorizzato o altrimenti associato a nessuna delle entità sopra menzionate e non rappresenta nessuna di queste entità in alcun modo. Tutti i diritti sui marchi e sui nomi di prodotto menzionati sono di proprietà dei rispettivi detentori di copyright. Ogni altro marchio citato appartiene ai propri registranti. MANAGED SERVER® è un marchio registrato a livello europeo da MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italia.

Torna in alto