SLA di hosting e cloud: continuità, backup e penali

SLA di hosting e cloud: da voce tecnica a scelta di governance

Lo SLA non è un allegato tecnico da confrontare sul prezzo, ma lo strumento con cui un'organizzazione governa una dipendenza operativa che incide su continuità, sicurezza, responsabilità, evidenze e condizioni di uscita. Per chi rientra nel perimetro della Direttiva NIS2 — recepita in Italia con il D.Lgs. 4 settembre 2024, n. 138, in vigore dal 16 ottobre 2024 — adottare misure tecniche, operative e organizzative adeguate e proporzionate alla gestione dei rischi informatici è un obbligo: la scelta dell'infrastruttura e del provider diventa una decisione di governance. 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, la sicurezza della catena di approvvigionamento, la gestione delle vulnerabilità, il controllo degli accessi e la protezione delle comunicazioni, 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.

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 e 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, e 310 di questi 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, che definisce i livelli minimi di sicurezza, capacità elaborativa, risparmio energetico e affidabilità delle infrastrutture digitali, le caratteristiche di qualità, sicurezza, performance e scalabilità, 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.

La valutazione va condotta congiuntamente da direzione, IT, security e procurement e 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.

Aumento degli attacchi cyber in Italia e nel cloud (2023)

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, entro quanto tempo lo comunica al cliente, attraverso quale canale e a quale referente, quali informazioni minime fornisce nella notifica (servizi impattati, cause note, azioni in corso, tempi stimati), 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 e 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, e 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 e quali dati o funzioni devono restare accessibili anche in modalità degradata.

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, e come i tempi di ripristino dichiarati siano 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. L'articolo 32 richiede al titolare misure tecniche e organizzative adeguate, tra cui espressamente la capacità di ripristinare tempestivamente la disponibilità e l'accesso ai dati personali in caso di incidente fisico o tecnico, 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.

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, quindi 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: 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 — backup e ripristino compresi — siano testate (provate), verificate (corrispondenti all'obiettivo e ripetibili) e valutate (esaminate negli eventuali margini di miglioramento) regolarmente nella loro efficacia. 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, e 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 (per esempio i 10 anni previsti dal codice civile per la corrispondenza a rilevanza giuridica e commerciale) e 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. Il Garante privacy, con provvedimento n. 139 del 7 aprile 2011, ha vietato il trattamento di dati personali del dipendente ricavati da file e documenti acquisiti nell'ambito di operazioni di backup effettuate 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à.

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. Un impegno sulla sola disponibilità può risultare rispettato anche con un ripristino lento o un incidente comunicato in ritardo, cioè proprio negli 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), perimetro oggetto della misura, finestra di misurazione (mensile o trimestrale) e periodo di osservazione, formula di calcolo, soglia di attivazione e franchigia. Vanno poi elencate le esclusioni ammesse — tipicamente manutenzioni programmate comunicate con un preavviso definito, interruzioni dovute a sistemi o connettività del cliente, cause di forza maggiore — e 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. Accanto ai rimedi economici vanno previsti rimedi non economici, come 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, a conservare e rendicontare i log degli incidenti, 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, insieme alla valutazione dell'efficacia delle misure e alla responsabilità degli organi di amministrazione e direzione, vanno nella stessa direzione: 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 — 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, e 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 e 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, 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, applicazione delle patch di competenza, monitoraggio, backup dell'infrastruttura, incident response — e altri restano necessariamente in capo al cliente: configurazione dei servizi, gestione 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, ma 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, e l'approccio normativo è multirischio, comprendendo ambiente fisico, fornitori e servizi esterni. In concreto: elenco aggiornato dei subfornitori critici, obbligo di preavviso per le modifiche, diritto di opposizione, indicazione dei luoghi di trattamento e degli accordi a monte, verificabilità delle stesse misure anche presso il subfornitore.

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 nell'ambito di operazioni di backup effettuate sul server aziendale, a conferma che 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, e di escludere esplicitamente riutilizzi dei dati del cliente per finalità proprie del fornitore.

Vantaggi e rischi dell'uso dei backup per finalità non previste

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, livelli di ridondanza e punti singoli di guasto residui, dipendenze da fornitori terzi (cloud sottostanti, connettività, energia), misure fisiche e logiche di separazione dei dati tra clienti. Per le pubbliche amministrazioni il riferimento è il Regolamento Cloud AGID (Determinazione 628/2021), che definisce livelli minimi di sicurezza, capacità elaborativa, risparmio energetico e affidabilità delle infrastrutture digitali, oltre alle caratteristiche di qualità, sicurezza, performance, scalabilità e portabilità dei servizi cloud e alle modalità di migrazione e di qualificazione.

Identità, patch, monitoraggio. Chiedere come sono gestiti account amministrativi, autenticazione e autorizzazioni, con quale periodicità vengono applicate le patch di competenza del fornitore e con quali tempi di reazione alle vulnerabilità critiche, 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, perimetro delle copie (file, database, posta elettronica e PEC, macchine virtuali e immagini), cifratura e gestione delle chiavi, 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, 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, quali esclusioni sono previste, quali crediti o penali si attivano e a quali condizioni, 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, quali tempi e costi sono previsti per la migrazione, quale supporto il fornitore garantisce nella fase di transizione verso un altro operatore, 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.

Checklist per negoziazione SLA, continuità e uscita dal servizio