SLA di continuità e backup: metriche e penali da negoziare

Cosa deve entrare in uno SLA di continuità e backup

Uno SLA (Service Level Agreement) è il contratto tra fornitore di servizi e cliente: definisce il servizio, il livello di prestazioni, come misurarlo e approvarlo e cosa succede se non viene raggiunto (IBM). In un accordo di continuità e backup devono quindi comparire quattro elementi distinti e verificabili: perimetro del servizio (sistemi, dati e processi coperti), livello atteso in numeri, metrica con finestra di misurazione, conseguenza contrattuale dell'inadempimento.

La tipologia di SLA cambia il contenuto. IBM ne distingue tre: SLA a livello di cliente, tra fornitore e singolo cliente (esterno o interno, per esempio tra due reparti della stessa organizzazione); SLA a livello di servizio, servizio standard offerto a più clienti con lo stesso livello di assistenza; SLA multilivello, che combina più livelli di dettaglio. Un fornitore cloud che applica lo stesso livello a tutti usa di norma uno SLA di servizio: qui il cliente perde potere negoziale, perché il livello non è calibrato sui suoi processi critici.

Continuità e disaster recovery non coincidono, e lo SLA deve rifletterlo. La Business Continuity è la capacità di continuare a fornire prodotti e servizi essenziali in tempi accettabili durante un'interruzione; include controlli preventivi e gestione delle persone. Il Disaster Recovery è il sottoinsieme che mira a ridurre al minimo i tempi di inattività e a recuperare la normale operatività il prima possibile, con misure tecniche e organizzative su data center, procedure e applicazioni, anche in siti alternativi (ACN). Uno SLA con un fornitore IT copre la parte tecnica, ma va affiancato da accordi su sedi alternative, comunicazione e processi manuali: altrimenti la continuità resta scoperta.

Il riferimento normativo è l'art. 24, comma 2, lettera c) del D.Lgs. 138/2024 (recepimento italiano della direttiva NIS2): articola la misura "Continuità operativa e gestione delle crisi" in tre elementi, piano di Business Continuity e Disaster Recovery, gestione dei backup e ridondanza, gestione delle crisi. Sono i tre capitoli che uno SLA di continuità dovrebbe richiamare, con obblighi e responsabilità separati per ciascuno.

Un ultimo elemento contrattuale riguarda la dipendenza dal fornitore. Il Garante privacy, nel Parere WP 196 sul cloud computing, annovera tra i rischi la mancanza di disponibilità per scarsa interoperabilità e il vendor lock-in, cioè la dipendenza da un unico fornitore. Clausole su formati di esportazione, reversibilità e transizione a un fornitore alternativo appartengono quindi allo SLA di continuità, non solo a quello di exit.

Dal BIA agli obiettivi contrattuali: RTO, RPO e SDO

Gli obiettivi di ripristino non si scelgono a tavolino: derivano dalla Business Impact Analysis (BIA), che determina l'impatto e le ricadute sul business di eventi che interrompono produzione o erogazione dei servizi, ed è propedeutica al Business Continuity Plan e al Disaster Recovery Plan. Il dominio Business Continuity and Disaster Recovery dell'ACN indica la BIA tra le attività principali, insieme al disaster recovery e ai test dei piani.

I risultati della BIA e della valutazione dei rischi fissano gli obiettivi di recupero (Beta80). Il Recovery Time Objective (RTO) è il tempo massimo consentito per recuperare risorse e funzioni aziendali dopo un disastro; il Recovery Point Objective (RPO) è la quantità di dati che specifiche attività o applicazioni ICT possono perdere per un'interruzione; il Service Delivery Objective (SDO) è il livello minimo di prestazioni che le funzioni aziendali devono raggiungere durante la modalità di elaborazione alternativa. In clausole diventano tre impegni distinti: entro quanto tempo il sistema torna disponibile, quanti minuti di dati posso perdere, con quale livello di funzionalità si opera nel frattempo.

Secondo la stessa fonte, il piano di ripristino deve basarsi sui risultati della valutazione del rischio e contenere: finalità, ambito di applicazione e pubblico; ruoli e responsabilità; contatti principali e canali di comunicazione interni ed esterni; condizioni di attivazione e disattivazione del piano; ordine di ripristino delle operazioni; piani di ripristino per operazioni specifiche, compresi gli obiettivi di ripristino; risorse necessarie, compresi backup e ridondanze; ripristino e ripresa delle attività dalle misure temporanee. Sono voci da riportare come allegati tecnici allo SLA, con un responsabile nominato per ciascuna.

L'ordine di ripristino è il punto in cui la BIA diventa contratto: se lo SLA prevede una sequenza di riavvio delle applicazioni che non riflette la priorità dei processi aziendali, il fornitore ripristinerà per primo il sistema più comodo, non quello che blocca l'azienda. Le priorità vanno scritte per applicazione e per processo, con RTO e RPO distinti.

Per capire quanto questi numeri siano realistici, confronta il costo dell'interruzione con il costo del servizio. Gartner (2025) stima per le PMI europee un costo medio del downtime IT di 5.600 EUR/ora; secondo BullTech, le PMI senza SLA subiscono in media 14-20 ore di fermo non pianificato all'anno. Con questi numeri, un RTO stretto resta sostenibile anche con un canone mensile più alto.

Metriche da mettere nero su bianco (e come misurarle)

Secondo BullTech, le cinque metriche fondamentali di uno SLA IT sono uptime, MTTA, MTTR, FCR e CSAT, con penali per il mancato rispetto; la stessa fonte cita anche MTBF tra le metriche misurabili. MTTA è il tempo di presa in carico, MTTR il tempo di riparazione, MTBF il tempo medio tra guasti, FCR la risoluzione al primo contatto. Ognuna richiede unità di misura, finestra di osservazione, soglia e periodicità di reportistica: senza questi quattro elementi non è contestabile in nessun senso.

Uptime. Si esprime in percentuale sulla finestra di osservazione; BullTech indica almeno il 99,5% per i sistemi critici e ricorda che uno SLA al 99,9% limita il fermo a massimo 43 minuti al mese. La finestra (mensile o annuale) cambia molto la severità: una percentuale annua assorbe singole interruzioni lunghe senza penale, una mensile no.

Tempi di risposta e ripristino. MTTA e MTTR vanno definiti separatamente per presa in carico e risoluzione e riferiti a ticket classificati per priorità: esempio ricorrente, presa in carico entro 1 ora per i ticket Priority 1 e risoluzione entro 4 ore lavorative. Va chiarito se il conteggio scorre su ore di calendario o ore lavorative: è la differenza tra un impegno 24/7 e uno 8x5.

Affidabilità. MTBF misura l'intervallo medio tra guasti e distingue un fornitore con un guasto lungo da uno con molti guasti brevi: a parità di uptime, la frequenza degli incidenti è ciò che consuma tempo interno.

Backup. Vanno contrattualizzate frequenza delle copie, integrità verificata (non solo esito del job) e tempo di ripristino effettivo, diverso dall'RTO dichiarato. La gestione dei backup e la ridondanza sono uno dei tre elementi della misura NIS2 su continuità operativa e gestione delle crisi: la reportistica su frequenza, esito e test di restore è anche materiale di compliance.

Qualità percepita. FCR e CSAT misurano l'efficacia del supporto dal lato utente: FCR indica quanti ticket si chiudono al primo contatto, CSAT la soddisfazione rilevata. Vanno misurate su un campione dichiarato, altrimenti restano un indicatore di cortesia, non un dato gestionale.

La reportistica deve essere un allegato contrattuale con contenuto minimo, formato, periodicità e diritto di verifica. Un report mensile trasparente è la base per calcolare penali e crediti senza contestazioni.

Penali, crediti e rimedi: cosa rende una clausola efficace

La differenza tra uno SLA e una brochure è la conseguenza economica. Nei contratti IT si usa il credito sul canone: una percentuale tra il 5% e il 15% del canone mensile per ogni violazione, secondo BullTech, che sottolinea come uno SLA senza penali resti una promessa vuota. Non è punizione ma incentivo: il fornitore che rischia di perdere una quota di ricavo organizza turni, scorte e ridondanze diversamente da chi non rischia nulla.

Una clausola efficace richiede cinque parametri. Primo, soglia di violazione: quanto scostamento fa scattare il credito (superamento dell'RTO dichiarato, uptime sotto soglia, MTTR oltre il limite). Secondo, unità di calcolo: percentuale sul canone del mese della violazione. Terzo, cumulabilità: se più violazioni nello stesso mese si sommano o si contano una sola volta. Quarto, massimale annuo, che il fornitore vorrà sempre introdurre. Quinto, escalation: cosa cambia dopo la seconda o terza violazione dello stesso tipo nello stesso periodo.

Le penali vanno dimensionate sul danno, non sul canone. Se il fermo costa all'azienda una cifra oraria dell'ordine di migliaia di euro, un credito simbolico non compensa né dissuade. In negoziazione il calcolo è: costo stimato di un'ora di indisponibilità per l'RTO contrattuale, confrontato con il credito massimo ottenibile.

I rimedi non economici contano spesso più delle penali: diritto di sospendere i pagamenti, diritto di recesso per violazioni ripetute, obbligo di piano di rimedio entro un termine, passaggio a risorse tecniche dedicate e soprattutto un exit plan con esportazione dei dati in formati utilizzabili da terzi. Il Garante privacy, nel Parere WP 196 sul cloud computing, richiama espressamente il rischio di mancanza di disponibilità per scarsa interoperabilità e vendor lock-in: se il contratto non prevede la reversibilità, nessuna penale restituisce l'operatività quando il fornitore diventa inutilizzabile.

Regola pratica: a ogni metrica dell'accordo corrisponde una conseguenza. Una metrica senza penale o credito è una dichiarazione di intenti; una penale senza metrica misurabile non è azionabile.

Classificare i sistemi per differenziare i livelli di servizio

Applicare lo stesso livello di servizio a tutto fa pagare troppo sui sistemi marginali e troppo poco su quelli che fermano l'azienda. La segmentazione proposta è in quattro classi: critico (server, email, ERP), alto (backup, VPN), medio (stampanti, Wi-Fi) e basso (PC singolo), con tempi di risposta diversi per livello (BullTech). La classificazione va fatta prima di negoziare: è il presupposto per chiedere livelli e penali differenziati.

Alla classificazione corrispondono finestre di copertura distinte. I livelli standard di mercato sono bronze (8x5), silver (12x5) e gold (24/7) (BullTech). La logica: i sistemi critici richiedono copertura continua e finestre di misurazione brevi; quelli di classe media convivono con orari lavorativi; quelli di classe bassa con interventi programmati.

Il punto di controllo è la coerenza tra classe, RTO e penale. Un sistema critico con RTO di poche ore non può avere copertura 8x5: l'RTO sarebbe violato per definizione ogni volta che l'incidente cade di notte o nel fine settimana. La penale su un sistema critico dovrebbe essere la più alta della scala; quella su un sistema di classe bassa può essere assente o sostituita da un impegno di best effort.

La classificazione va collegata alla BIA: classi di criticità tecnica e priorità di ripristino delle operazioni devono coincidere. Se un'applicazione è media nel contratto ma essenziale per l'erogazione del servizio nella BIA, il piano di ripristino contrattuale riattiverà per primo ciò che non serve e l'azienda resterà ferma comunque.

Va fissato anche il criterio di riclassificazione: chi decide, con quale periodicità e preavviso un sistema passa da una classe all'altra, e come cambiano canone e livelli di servizio. Senza questa clausola, la classificazione invecchia e resta ferma alle esigenze dell'anno di firma del contratto.

Classificazione dei sistemi per criticità aziendale

Backup, ridondanza e test: clausole che proteggono davvero

La gestione dei backup e la ridondanza sono uno dei tre elementi della misura su continuità operativa e gestione delle crisi del D.Lgs. 138/2024, insieme al piano di Business Continuity e Disaster Recovery e alla gestione delle crisi. In clausole si traducono in obblighi concreti: frequenza delle copie per sistema, tipo di copia, conservazione in luogo separato dal sito primario, ridondanza delle componenti e risorse necessarie al ripristino comprese nell'elenco degli elementi del piano.

Il test è la parte sistematicamente omessa e rende verificabili RTO e RPO. Il dominio Business Continuity and Disaster Recovery dell'ACN comprende esplicitamente le attività di test per verificare completezza ed efficacia delle procedure definite per continuità e disaster recovery, e indica il test dei piani tra le attività principali. Senza esercitazioni documentate, RTO e RPO restano stime del fornitore: l'unico dato attendibile è il tempo misurato in un ripristino reale.

Gli standard di riferimento aiutano a strutturare gli obblighi: ISO 22301 per la business continuity e ISO 27031 per la preparazione ICT alla continuità (BullTech). La clausola minima prevede test periodici concordati, con scenari dichiarati (guasto, perdita di dati, indisponibilità del sito), verbale dei risultati, scostamenti rispetto agli obiettivi e piano di correzione con termine.

L'errore da evitare è la falsa sicurezza. BullTech descrive il caso tipico dell'azienda che dichiara "abbiamo il disaster recovery" e poi ha il backup su un NAS nello stesso ufficio del server, senza procedure scritte. Backup e ridondanza nello stesso perimetro fisico non coprono incendi, allagamenti o ransomware che cifra la rete: in questi scenari la continuità dipende dalla copia in sede separata e dalla capacità di ripristinarla.

Va contrattualizzata anche la fase di crisi: chi attiva il piano, chi comunica internamente ed esternamente, quali sono i canali alternativi, come si coordina il fornitore con l'azienda e con gli altri fornitori. Il piano NIS2 richiamato da Beta80 include ruoli e responsabilità, contatti e canali, condizioni di attivazione e disattivazione e ripristino dalle misure temporanee: nello SLA diventano nominativi, numeri di reperibilità e tempi di risposta in regime di crisi.

Errori da evitare in negoziazione e checklist finale

Gli errori che trasformano uno SLA in un documento inutile sono ricorrenti e riconoscibili. Formule vaghe come "risposta rapida" non significano nulla: ogni metrica deve avere un numero e un'unità di misura (BullTech). Metriche senza finestra di osservazione o non misurabili, perché il fornitore non espone i dati necessari a calcolarle. Penali simboliche o assenti, che eliminano l'incentivo economico. Mancato allineamento tra SLA e BIA, con RTO contrattuali che non corrispondono alla priorità dei processi aziendali. Assenza di test e verbali, che impedisce di sapere se gli obiettivi sono realistici. Trascuratezza su interoperabilità e dipendenza dal fornitore, con il rischio di vendor lock-in segnalato dal Garante privacy nel Parere WP 196 sul cloud computing.

Un errore meno evidente è accettare uno SLA a livello di servizio con sistemi eterogenei: il livello standardizzato non distingue il gestionale dalla stampante e l'azienda garantisce lo stesso impegno a tutto senza differenziare la spesa. Un altro è non prevedere cumulabilità e massimale delle penali, trasformando un impegno forte in un tetto basso raggiungibile con una sola violazione grave.

Checklist operativa per la negoziazione: 1) elenca i sistemi e classificali per criticità, collegando ogni classe a un livello di copertura (8x5, 12x5, 24/7); 2) per ogni sistema scrivi RTO, RPO e SDO derivati dalla BIA, con priorità di ripristino delle operazioni; 3) definisci per ogni metrica unità di misura, finestra di osservazione, soglia e formato del report; 4) assegna a ogni metrica una conseguenza: credito del 5-15% sul canone mensile, cumulabilità, massimale, escalation; 5) aggiungi rimedi non economici: piano di rimedio, recesso per violazioni ripetute, exit plan con esportazione dei dati; 6) contrattualizza backup, ridondanza, sede separata e tempi di ripristino; 7) prevedi test periodici con verbale, scostamenti e azioni correttive; 8) verifica la conformità delle clausole agli obblighi di continuità operativa applicabili all'azienda; 9) fissa criterio e periodicità di riclassificazione dei sistemi; 10) verifica il diritto di auditare i dati di misurazione: senza accesso ai dati, le penali non sono azionabili.