
Assistenza Post-Vendita
SLA di hosting e cloud: continuità, backup e penali
Lo SLA non è un allegato tecnico da confrontare sul prezzo. È lo strumento con cui un'organizzazione governa una dipendenza operativa.
SLA di hosting e cloud: da voce tecnica a scelta di governance
Lo SLA non è un allegato tecnico da confrontare sul prezzo. È lo strumento con cui un'organizzazione governa una dipendenza operativa. Questa incide su continuità, sicurezza, responsabilità, evidenze e condizioni di uscita.
La negoziazione si gioca su tre fronti distinti: continuità operativa, backup e ripristino, penali. Ogni fronte ha metriche, evidenze e conseguenze proprie. Un contratto costruito solo sulla percentuale di disponibilità ne copre uno solo.
Per chi rientra nel perimetro della Direttiva NIS2, adottare misure tecniche, operative e organizzative adeguate e proporzionate alla gestione dei rischi informatici è un obbligo. La Direttiva è recepita in Italia con il D.Lgs. 4 settembre 2024, n. 138, in vigore dal 16 ottobre 2024. La scelta dell'infrastruttura e del provider diventa così una decisione di governance.
Per cloud hosting si intende l'insieme delle risorse infrastrutturali, dei servizi gestiti e dei controlli operativi usati per erogare applicazioni e servizi aziendali. Non è il semplice spazio web associato a un sito.
Il quadro NIS2 indica come ambiti principali l'analisi e la gestione dei rischi informatici, la gestione e la notifica degli incidenti, la continuità operativa con backup e ripristino dei servizi. Indica anche la sicurezza della catena di approvvigionamento, la gestione delle vulnerabilità, il controllo degli accessi e la protezione delle comunicazioni.
Il quadro include l'uso della crittografia, la formazione del personale, la valutazione dell'efficacia delle misure e la responsabilità degli organi di amministrazione e direzione. In un contratto cloud, questi elementi finiscono dentro o fuori la clausola di livello di servizio.
La sicurezza va declinata in riservatezza, integrità e disponibilità. È lo schema della norma ISO 27000, e serve a leggere ogni voce dello SLA senza fermarsi al prezzo.
Sul fronte privacy, il riferimento nazionale è il D.Lgs. 30 giugno 2003, n. 196, il Codice in materia di protezione dei dati personali. Il Garante ha pubblicato indicazioni per l'utilizzo consapevole dei servizi cloud (doc. web 1819933, 23 giugno 2011).
Secondo il CrowdStrike 2024 – Global Threat Report, citato in un'analisi sul Regolamento Cloud e NIS2, gli attacchi che hanno coinvolto infrastrutture cloud sono aumentati del 75% nel 2023. I gruppi criminali specializzati esclusivamente negli ambienti cloud sono cresciuti del 110% (avversari «cloud-conscious»).
Dal Rapporto Clusit 2024 emerge che gli attacchi cyber in Italia sono aumentati del 65%. Tra il 2019 e il 2023 il campione ha incluso 653 attacchi noti di particolare gravità che hanno coinvolto realtà italiane. Di questi, 310 incidenti, più del 47%, sono avvenuti nel 2023.
Per la pubblica amministrazione il riferimento è esplicito: il Regolamento Cloud adottato da AGID con Determinazione 628/2021. Definisce i livelli minimi di sicurezza, capacità elaborativa, risparmio energetico e affidabilità delle infrastrutture digitali. Definisce anche le caratteristiche di qualità, sicurezza, performance e scalabilità.
Definisce la portabilità dei servizi cloud, le modalità di migrazione e le modalità di qualificazione dei servizi cloud per la PA. Anche un'impresa privata può usarlo come elenco di ciò che è legittimo pretendere da un fornitore. Indica le dimensioni su cui un servizio cloud va misurato e documentato, non solo erogato.
Molti repository di dati nel cloud offrono ampie garanzie di sicurezza, soprattutto quando sono gestiti da grandi operatori come Microsoft, Google e Amazon. La garanzia va comunque verificata in contratto, non presunta dal nome del fornitore.
La valutazione va condotta congiuntamente da direzione, IT, security e procurement. Non può fermarsi a CPU, spazio e prezzo. Deve includere data center, architettura, gestione delle identità, patch, monitoraggio, backup, incident response, SLA, portabilità e modello di responsabilità condivisa.
Il quadro NIS2 richiede un processo continuativo e verificabile. Non basta acquistare singole tecnologie. Servono responsabilità definite, misure proporzionate, procedure documentate e controlli capaci di evolvere insieme a sistemi e minacce.
Continuità operativa: cosa deve reggere quando il servizio si interrompe
La continuità operativa, con backup e ripristino dei servizi, è uno degli ambiti che la NIS2 affianca alla gestione e notifica degli incidenti e alla sicurezza della catena di approvvigionamento.
In clausole, questo significa che lo SLA non può limitarsi a una percentuale di disponibilità. Deve stabilire come e quando il fornitore rileva un guasto o un incidente. Deve indicare entro quanto tempo lo comunica al cliente, attraverso quale canale e a quale referente.
Deve precisare quali informazioni minime fornisce nella notifica: servizi impattati, cause note, azioni in corso, tempi stimati. Deve stabilire con quale frequenza aggiorna la situazione e con quale documento chiude l'evento.
Un impegno di disponibilità senza obblighi di notifica e rendicontazione lascia il cliente a scoprire l'interruzione dai propri utenti.
Un secondo fronte è la catena di approvvigionamento. La sicurezza della supply chain impone di conoscere non solo le misure interne del fornitore, ma anche dipendenze, subfornitori e capacità operativa dei partner tecnologici. L'approccio richiesto è multirischio e considera anche ambiente fisico, fornitori e servizi esterni.
Se il provider appoggia a sua volta su un altro cloud, su un data center terzo o su un fornitore di connettività, quel livello va dichiarato nel contratto. Va verificata l'esistenza di accordi coerenti a monte: un incidente del subfornitore è un incidente che l'azienda cliente subisce comunque.
Il legame con il rischio d'impresa va esplicitato, perché è ciò che giustifica gli investimenti. Siti, applicazioni, database, piattaforme e servizi essenziali dipendono sempre più da infrastrutture cloud e fornitori esterni. Un'interruzione o una compromissione può causare perdita di ricavi, blocco operativo, violazioni contrattuali e danni reputazionali.
Per questo lo SLA va letto insieme al piano di continuità aziendale. Quali processi si fermano se la piattaforma non risponde? Quali workaround sono praticabili? Chi ha l'autorità di attivarli? Quali dati o funzioni devono restare accessibili anche in modalità degradata?
Il riferimento metodologico per la continuità è la norma ISO 22301. Lo SLA copre la parte affidata al fornitore; il piano di continuità copre ciò che l'organizzazione deve saper fare anche senza di lui.
Sul piano delle evidenze, il criterio pratico è chiedere l'architettura, non l'aggettivo. Quali componenti sono ridondati e a quale livello? Quali sono i punti singoli di guasto residui? Quali dipendenze esterne esistono?
Come vengono eseguite le manutenzioni programmate e con quale preavviso? Come i tempi di ripristino dichiarati sono stati verificati? La NIS2 richiede una valutazione dell'efficacia delle misure adottate. Un impegno di continuità mai provato in esercizio è una dichiarazione, non un controllo.
Backup e ripristino: RPO, RTO, cifratura, test e retention
Il GDPR non impone un software specifico per il backup, ma un risultato: garantire disponibilità, integrità e resilienza dei dati personali trattati.
Nell'articolo 32, comma 1, la capacità di ripristinare tempestivamente la disponibilità e l'accesso ai dati personali è alla lettera c). L'obbligo di testare, verificare e valutare regolarmente l'efficacia delle misure è alla lettera d). Sono i due riferimenti da richiamare in clausola.
L'articolo 32 richiede al titolare misure tecniche e organizzative adeguate. Tra queste indica espressamente la capacità di ripristinare tempestivamente la disponibilità e l'accesso ai dati personali in caso di incidente fisico o tecnico.
Indica anche la cifratura dei dati personali e una procedura per testare e verificare regolarmente l'efficacia delle misure adottate. In pratica: non basta «avere un backup». Serve un backup cifrato, testato e ripristinabile in tempi certi.
Se i dati dei clienti o dei dipendenti si perdono per un guasto, un ransomware o un errore umano e non è possibile ripristinarli in tempi ragionevoli, la mancanza di un sistema di backup adeguato diventa una violazione della normativa.
Molte PMI collocano dati personali in servizi di archiviazione gratuiti come Dropbox o Google Drive, spesso per iniziativa di singoli uffici o collaboratori. In quel caso non esiste alcuno SLA: nessun RPO, nessun RTO, nessuna retention e nessuna penale. Il primo passo è censire questi usi.
Da qui la necessità di negoziare due parametri distinti, spesso confusi nelle offerte. L'RPO indica quanti dati si è disposti a perdere, cioè la distanza massima ammessa tra l'ultima copia valida e il momento dell'incidente. L'RTO indica quanto tempo può durare l'indisponibilità prima che il servizio torni operativo.
Il punto tecnico da mettere per iscritto è che tra il momento dell'incidente e l'ultimo backup eseguito i dati sono cambiati e le attività sono proseguite. La sincronizzazione perfetta non esiste.
Al backup inteso come insieme di policy, strumenti e procedure per produrre copie di riserva occorre affiancare policy, strumenti e procedure di ripristino. Un RTO dichiarato senza una procedura di ripristino documentata e provata è solo un numero.
Il perimetro del backup va definito per iscritto e deve riguardare tutti i dati personali presenti in azienda. Include file e cartelle, database (incluso il gestionale), posta elettronica e PEC, macchine virtuali e immagini di sistema.
Un backup parziale — per esempio solo le cartelle condivise e non le mailbox — lascia scoperti trattamenti che sono a tutti gli effetti dati personali.
Nella valutazione del fornitore questo si traduce in domande precise: quali componenti sono incluse, con quale frequenza, dove risiedono le copie, per quanto tempo restano disponibili e chi può accedervi.
La cifratura è una misura richiesta, non un optional: i dati devono essere crittografati prima di essere trasferiti nel cloud. Un esempio di impostazione tecnica è l'uso di algoritmi AES con chiave a 256 bit, con la chiave conosciuta solo dal cliente. La scelta concreta da contrattualizzare è però chi detiene e gestisce le chiavi, perché è questo che determina chi può realmente leggere i backup.
Sul fronte dei test, l'articolo 32 richiede che le misure siano testate, verificate e valutate regolarmente nella loro efficacia. Backup e ripristino rientrano tra queste misure. Le prove devono essere provate, verificate come corrispondenti all'obiettivo e ripetibili, e valutate negli eventuali margini di miglioramento.
Nello SLA questo significa pretendere un calendario di prove di ripristino, il loro esito documentato e l'indicazione dei tempi effettivamente misurati, non solo di quelli promessi.
La retention va gestita con un piano documentato, perché il principio di limitazione della conservazione impone di non conservare i dati personali più a lungo del necessario. Questo vale anche per le copie di backup.
Il piano deve essere coerente con le finalità del trattamento e con gli obblighi di legge di settore. Un esempio sono i 10 anni previsti dal codice civile per la corrispondenza a rilevanza giuridica e commerciale.
Il piano deve stabilire, per ogni categoria di dati, quante copie conservare, per quanto tempo, dove e chi è autorizzato ad accedervi. È uno dei documenti che il titolare deve poter esibire in caso di ispezione, in base al principio di accountability.
Infine, l'uso dei backup è un tema di trattamenti non previsti. Con provvedimento n. 139 del 7 aprile 2011, il Garante privacy ha vietato un trattamento specifico. Ha vietato il trattamento di dati personali del dipendente ricavati da file e documenti acquisiti in operazioni di backup sul server aziendale.
Le copie di riserva non sono un archivio da cui attingere per altre finalità. La stessa logica va applicata al fornitore: chi, al suo interno, può accedere ai backup, per quale scopo e con quale tracciamento delle attività.
Passaggi per garantire conformità GDPR e NIS2 nel backup
- Definire il perimetro del backupTutti i dati personali: file, database, email, PEC, VM
- Applicare cifratura con chiavi a custodia clienteAlgoritmo AES-256, chiave nota solo al cliente
- Stabilire RPO e RTO per ogni servizioIn base alla criticità del trattamento
- Programmare prove di ripristino regolariDocumentate, verificate e ripetibili
Penali e rimedi: come rendere esigibili gli impegni dello SLA
Una penale è esigibile solo se la metrica che la attiva è definita in modo non discutibile. Il primo passo è separare gli oggetti della misurazione: disponibilità del servizio, durata del ripristino dopo un incidente, rispetto dei tempi di notifica, integrità dei dati.
Il contratto deve contenere cifre: percentuale di disponibilità garantita, tempo massimo di ripristino, importo del credito di servizio, tetto della penale. Se la clausola rinvia a livelli generici senza valori, la metrica non è contestabile e la penale resta teorica.
Un impegno sulla sola disponibilità può risultare rispettato anche con un ripristino lento o un incidente comunicato in ritardo. Sono proprio gli scenari che generano il danno maggiore. Per questo le clausole vanno costruite su più indicatori, ciascuno con la propria conseguenza.
Per ogni indicatore servono unità di misura, per esempio minuti di indisponibilità per singolo servizio, non per il data center nel suo complesso. Servono anche perimetro oggetto della misura, finestra di misurazione (mensile o trimestrale) e periodo di osservazione.
Servono poi formula di calcolo, soglia di attivazione e franchigia. Vanno elencate le esclusioni ammesse: tipicamente manutenzioni programmate comunicate con un preavviso definito, interruzioni dovute a sistemi o connettività del cliente, cause di forza maggiore. Va definita la procedura con cui il cliente contesta il dato e il fornitore risponde.
Le conseguenze possono essere graduate: credito di servizio proporzionato alla durata e alla gravità dell'evento, rimborso, penale vera e propria, fino al diritto di recesso anticipato senza oneri in caso di violazioni ripetute.
È opportuno fissare anche un tetto massimo alle penali, sapendo che il tetto limita la tutela del cliente. Quanto più è basso, tanto più la penale diventa simbolica rispetto al danno reale.
Il costo della non conformità non è solo contrattuale. Violare i principi del GDPR o incidere sui diritti dell'interessato espone a una sanzione amministrativa che può arrivare fino a 20.000.000 di euro. È il parametro con cui confrontare il tetto delle penali negoziate.
Accanto ai rimedi economici vanno previsti rimedi non economici. Un esempio è l'obbligo di consegnare un'analisi della causa radice e un piano correttivo con scadenze verificabili.
Nessuna penale è applicabile senza evidenze. Il contratto deve obbligare il fornitore a produrre periodicamente un report di disponibilità per servizio. Deve obbligarlo a conservare e rendicontare i log degli incidenti.
Deve obbligarlo a documentare gli esiti dei test di ripristino e a formalizzare le notifiche inviate al cliente con data e ora. Se il cliente non riceve questi dati, non può dimostrare il superamento della soglia.
Su questo punto le clausole contrattuali e gli obblighi di gestione e notifica degli incidenti previsti dalla NIS2 vanno nella stessa direzione. Insieme alla valutazione dell'efficacia delle misure e alla responsabilità degli organi di amministrazione e direzione, indicano che ciò che non è documentato non è verificabile.
Il limite da tenere presente è che la penale non ripara il danno e non sostituisce le condizioni di uscita. Perdita di dati, ripristino incompleto, notifica tardiva, dipendenza da un subfornitore non dichiarato e impossibilità di migrare i dati sono eventi che richiedono rimedi specifici.
Richiedono indennizzi commisurati, obblighi di ripristino, diritti di portabilità ed exit, non soltanto una riduzione in fattura.
Ruoli e responsabilità: titolare, provider e subfornitori
Chi decide finalità e modalità del trattamento dei dati personali è il titolare. Questa qualifica non si trasferisce al fornitore insieme all'infrastruttura. Il provider che tratta dati per conto del cliente opera su istruzioni documentate.
Non può utilizzarli per finalità proprie. Può ricorrere a subfornitori solo se autorizzato, con gli stessi obblighi lungo tutta la catena.
Nel contratto questo si traduce in clausole su istruzioni di trattamento, misure di sicurezza, gestione degli accessi. Include anche assistenza al titolare nella risposta agli incidenti e nelle richieste degli interessati, cancellazione o restituzione dei dati alla cessazione del servizio.
Il modello di responsabilità condivisa va scritto nero su bianco, perché è la principale fonte di equivoci in caso di incidente. Alcuni controlli sono in capo al provider: data center, architettura dell'infrastruttura, gestione delle identità e degli accessi di piattaforma.
Sono in capo al provider anche applicazione delle patch di competenza, monitoraggio, backup dell'infrastruttura, incident response. Altri controlli restano necessariamente in capo al cliente.
Il cliente gestisce configurazione dei servizi, utenti e permessi, classificazione dei dati, corretta impostazione delle policy, backup dei dati e delle applicazioni di propria competenza.
La selezione del provider non dovrebbe quindi fermarsi a CPU, spazio e prezzo. Deve includere data center, architettura, identità, patch, monitoraggio, backup, incident response, SLA, portabilità e modello di responsabilità condivisa.
La dimensione dei subfornitori è oggi un requisito esplicito. La sicurezza della catena di approvvigionamento impone di conoscere non solo le misure interne, ma anche dipendenze, subfornitori e capacità operativa dei partner tecnologici. L'approccio normativo è multirischio e comprende ambiente fisico, fornitori e servizi esterni.
In concreto servono elenco aggiornato dei subfornitori critici, obbligo di preavviso per le modifiche, diritto di opposizione, indicazione dei luoghi di trattamento e degli accordi a monte. Serve anche la verificabilità delle stesse misure presso il subfornitore.
Il Codice in materia di protezione dei dati personali, D.Lgs. 30 giugno 2003, n. 196, è il quadro nazionale entro cui il Garante ha adottato i suoi provvedimenti in materia di copie di riserva. Le istruzioni documentate del titolare restano lo strumento con cui questi obblighi arrivano al provider.
Un'area di rischio sottovalutata è l'uso delle copie di riserva. Un provvedimento del Garante privacy (n. 139 del 7 aprile 2011) ha vietato il trattamento di dati personali del dipendente ricavati da file e documenti acquisiti in operazioni di backup effettuate sul server aziendale. La copia di sicurezza non è una fonte utilizzabile per finalità diverse.
Applicato al rapporto con il provider, questo principio richiede di definire contrattualmente chi può accedere ai backup, per quale scopo, con quali autorizzazioni e quale tracciamento. Richiede di escludere esplicitamente riutilizzi dei dati del cliente per finalità proprie del fornitore.
Pro e contro della responsabilità condivisa tra titolare e provider
- Pro: Chiarezza sulle competenzeOgni parte sa cosa deve gestire: provider su infrastruttura, cliente su configurazione e dati
- Contro: Rischio di lacune nei controlliSe non ben definito, si rischia un vuoto di responsabilità in caso di incidente
- Pro: Maggiore resilienza operativaCombinazione di forze tra clienti e provider migliora gestione rischi
- Contro: Complessità contrattualeNegoziare ruoli e responsabilità richiede competenza tecnica e legale
Checklist per negoziare SLA, continuità e uscita dal servizio
Architettura e data center. Chiedere rappresentazione dell'architettura, localizzazione dei data center e dei luoghi di trattamento. Chiedere livelli di ridondanza e punti singoli di guasto residui. Chiedere dipendenze da fornitori terzi (cloud sottostanti, connettività, energia) e misure fisiche e logiche di separazione dei dati tra clienti.
Per le pubbliche amministrazioni il riferimento è il Regolamento Cloud AGID (Determinazione 628/2021). Definisce livelli minimi di sicurezza, capacità elaborativa, risparmio energetico e affidabilità delle infrastrutture digitali. Definisce anche caratteristiche di qualità, sicurezza, performance, scalabilità e portabilità dei servizi cloud, oltre a modalità di migrazione e di qualificazione.
Identità, patch, monitoraggio. Chiedere come sono gestiti account amministrativi, autenticazione e autorizzazioni. Chiedere con quale periodicità vengono applicate le patch di competenza del fornitore e con quali tempi di reazione alle vulnerabilità critiche.
Chiedere quali metriche di monitoraggio esistono e chi viene avvisato quando una soglia viene superata. Sono le voci che il quadro NIS2 riconduce a controllo degli accessi, gestione delle vulnerabilità e valutazione dell'efficacia delle misure.
Backup, ripristino e incident response. Chiedere RPO e RTO per ogni servizio. Chiedere perimetro delle copie (file, database, posta elettronica e PEC, macchine virtuali e immagini), cifratura e gestione delle chiavi.
Chiedere calendario e risultati delle prove di ripristino, piano di data retention con numero di copie, durata, ubicazione e persone autorizzate all'accesso.
Sul fronte degli incidenti: procedure documentate, canale e tempi di notifica, referenti, contenuti minimi della comunicazione. Chiedere obbligo di analisi della causa radice e piano correttivo.
SLA, penali e misure dell'impatto. Chiedere quali indicatori vengono misurati, su quale perimetro e con quale finestra temporale. Chiedere quali esclusioni sono previste, quali crediti o penali si attivano e a quali condizioni. Chiedere quale reportistica periodica è fornita e con quali log a supporto delle contestazioni.
Verificare che gli impegni su continuità, notifica degli incidenti e ripristino siano coperti da rimedi, non solo la disponibilità.
Portabilità, migrazione e uscita. Chiedere in quali formati e con quali strumenti i dati possono essere esportati. Chiedere quali tempi e costi sono previsti per la migrazione. Chiedere quale supporto il fornitore garantisce nella fase di transizione verso un altro operatore.
Chiedere per quanto tempo i dati restano disponibili dopo la cessazione, come e quando vengono cancellati o restituiti e quali copie residue vengono distrutte. Le condizioni di uscita vanno negoziate all'inizio, quando il rapporto contrattuale è ancora equilibrato.
Evidenze da acquisire. Elenco aggiornato dei subfornitori e dei luoghi di trattamento. Certificazioni e attestazioni pertinenti (gestione della sicurezza delle informazioni, continuità di servizio).
Report di disponibilità, verbali e log degli incidenti, esiti documentati dei test di ripristino, risultati delle valutazioni di vulnerabilità. Un fornitore che non fornisce queste evidenze rende impraticabili sia la penale sia la verifica richiesta dalla normativa.
Per ogni voce la risposta attesa è un numero o un documento: percentuale di disponibilità, minuti di ripristino, ore di preavviso per le manutenzioni, mesi di conservazione, importo della penale e tetto. Se la risposta resta un aggettivo, la clausola non è stata negoziata.
Checklist per la negoziazione di SLA, continuità e uscita dal servizio
- Architettura e data centerLocalizzazione, ridondanza, punti singoli di guasto, dipendenze da terzi
- Identità, patch, monitoraggioGestione accessi, tempi applicazione patch, metriche di monitoraggio
- Backup, ripristino e incident responseRPO/RTO, perimetro copie, cifratura, test ripristino, retention
- SLA, penali e impattoIndicatori misurati, esclusioni, crediti, reportistica periodica
- Portabilità, migrazione e uscitaFormati dati, tempi e costi migrazione, supporto transizione, cancellazione dati
- Evidenze da acquisireElenco subfornitori, certificazioni, log incidenti, report disponibilità



