Checklist contrattuale per provider cloud: SLA, protezione dei dati e clausole di exit realmente efficaci

Chi acquista servizi cloud non compra solo potenza di calcolo o spazio di archiviazione, ma realtà operativa: disponibilità, tempi di risposta, flussi di dati, tracciabilità delle verifiche e un’opzione di exit. Proprio qui un contratto decide se la vostra IT può gestire le attività quotidiane o dovrà improvvisare in seguito. Questa checklist contrattuale per provider cloud si concentra quindi su clausole che possono essere formulate concretamente, misurate e verificate tramite audit – con uno sguardo all’operatività IT, alla sicurezza, alla protezione dei dati (GDPR) e alla questione di come effettuare un’uscita pulita in caso di necessità.

Importante: molti contratti standard usano termini come „best effort“, „branchenüblich“ o „angemessene Maßnahmen“. Questo aiuta poco negli audit e in caso di malfunzionamenti, perché è difficile dimostrarlo. L’obiettivo non è regolamentare ogni eventualità, ma definire standard minimi chiari: cosa viene misurato? Chi segnala cosa, quando e come? Quali dati riceverete indietro? Cosa succede se non funziona?

Checklist contrattuale per provider cloud nella pratica

Prima di formulare singole clausole, la situazione di partenza deve essere inequivocabile. Nella pratica i contratti cloud non falliscono tanto per “mancanza di sicurezza”, quanto per responsabilità poco chiare. Il provider gestisce la piattaforma, voi gestite configurazione, identità e dati – a seconda del modello (IaaS, PaaS, SaaS) con profondità diversa. Questa ripartizione dei compiti viene spesso descritta come Shared Responsibility Model: il provider è responsabile di determinate layer (es. infrastruttura fisica), voi di altre (es. IAM, classificazione dei dati, policy applicative).

Checkpunkt: Vertragsgegenstand und Abhängigkeiten explizit machen

• Elenco dei servizi con versioni/edizioni, regioni, finestre operative, funzionalità opzionali (es. Managed Keys, WAF, DLP).
• Servizi di terze parti dipendenti (es. CDN, Anti-DDoS, subappaltatori per il ticketing). In pratica la „Cloud-Leistung“ spesso dipende da più sub-service.
• Matrice di responsabilità (RACI: Responsible, Accountable, Consulted, Informed) per operatività, sicurezza, protezione dei dati, incidenti, modifiche, gestione delle chiavi.
• Tipi di dati: dati personali, dati particolarmente sensibili, segreti aziendali, dati regolamentati (es. dati finanziari). Da ciò derivano TOMs e requisiti di audit.

Se non potete inserire questi punti direttamente nel contratto, almeno un allegato contrattuale referenziato (es. „Service Schedule“) deve farne parte e potrà essere modificato solo con una procedura di change definita.

2) SLA nel contratto cloud: dalle cifre di marketing a obblighi misurabili

Un SLA (Service Level Agreement) è valido solo quanto il suo metodo di misurazione. Per la direzione IT e l’audit non conta se da qualche parte è scritto „99,9 %“, ma cosa esattamente si considera guasto, come viene misurato e quali conseguenze ne derivano. Prestate particolare attenzione alle esclusioni („maintenance“, „force majeure“, „customer network“, „beta features“) – sono spesso in queste clausole standard che si nascondono i rischi reali.

2.1 Verfügbarkeit: Definition, Messpunkte, Wartungsfenster

• Definizione del servizio: disponibilità per servizio (es. object storage, servizio database, IAM) invece di «piattaforma complessiva».
• Punto di misurazione: monitoraggio del provider vs. cliente. Meglio una misurazione doppia e un meccanismo di risoluzione delle discrepanze.
• Definizione di guasto: p.es. «HTTP 5xx per X minuti» o «un’operazione API fallisce in Y % dei tentativi». Per servizi non HTTP analogamente (es. tasso di errori di autenticazione, backlog della coda).
• Finestre di manutenzione: periodo di preavviso, durata massima, fascia oraria (fuso orario locale), «nessuna manutenzione» per finestre critiche (periodi di blackout).

2.2 Performance- und Support-SLAs: Latenz, Durchsatz, Reaktionszeiten

Molti contratti si limitano alla disponibilità e lasciano aperta la performance. Per soluzioni digitali aziendali vicine ai processi è spesso determinante il tempo di risposta. Senza parametri chiari si finisce in discussioni del tipo «funziona in qualche modo».

• Performance-SLOs (Service Level Objectives) per API core: es. latenza p95/p99 in regioni e finestre temporali definite.
• Impegni di capacità: limiti, quote, regole di burst, comportamento di scalabilità e preavviso in caso di modifica dei limiti.
• Classi di supporto: priorità (P1–P4) con tempo di risposta, frequenza degli aggiornamenti, tempo obiettivo per la fornitura di un workaround.
• Canali di comunicazione: status page, e-mail, ticket, telefono, livelli di escalation definiti inclusa escalation alla direzione.

2.3 Incident- und Problem-Management: Postmortems, RCA, Evidence

Per compliance e direzione aziendale non è rilevante solo la risoluzione dell’anomalia, ma la tracciabilità: qual è stata la causa (RCA: Root Cause Analysis), quali azioni sono state intraprese e cosa comporta questo per il rischio di recidiva?

• Obbligo di segnalazione per eventi di sicurezza e interruzioni operative con scadenze (es. «segnalazione iniziale entro X ore dalla rilevazione»).
• Formato RCA: cronologia, causa, componenti interessate, impatto sui clienti, misure immediate, prevenzione, punti aperti.
• Supporto per log e forensics: quali log vengono forniti, per quanto tempo, in quale formato, con quale integrità (es. conservazione a prova di manomissione).
• Trasparenza delle modifiche: change del provider che interessano i clienti, con preavviso, opzioni di rollback e classificazione «breaking change».

2.4 Konsequenzen bei Nichterfüllung: Service Credits sind nicht genug

Service Credits raramente compensano il danno aziendale. Sono comunque utili come innesco vincolante per l’escalation e i piani di miglioramento. Integrateli con diritti operativi.

• Service Credits con calcolo chiaro e accredito automatico, non solo «su richiesta».
• Right to Cure: termine per la risoluzione e misure di miglioramento definite.
• Diritto di recesso speciale in caso di violazioni ripetute degli SLA o gravi incidenti di sicurezza.

3) Protezione dei dati e AVV: conforme al GDPR non significa automaticamente auditabile

Se il provider cloud tratta dati personali per vostro conto, in genere è necessario un contratto di elaborazione per conto del titolare (AVV) ai sensi dell’art. 28 del GDPR. «Abbiamo un AVV» non è sufficiente dal punto di vista operativo. Decisivo è se con quello potete soddisfare i vostri obblighi di rendicontazione: minimizzazione dei dati, limitazione della finalità, TOMs (misure tecniche e organizzative), politiche di cancellazione e evidenze.

3.1 Ruoli e flussi di dati: Titolare, responsabile del trattamento, responsabilità congiunta

Chiarite contrattualmente e negli allegati, chi ricopre quale ruolo. Soprattutto nel SaaS esistono zone grigie, ad esempio quando il fornitore persegue scopi propri (p. es. miglioramento del prodotto tramite telemetria). Questo può modificare la qualificazione.

• Finalità del trattamento e categorie di dati personali.
• Gruppi interessati (clienti, dipendenti, partner) e categorie particolari (art. 9 del GDPR), se rilevante.
• Telemetria/dati di diagnostica: quali dati, opt-in/opt-out, aggregazione/anonimizzazione, periodi di conservazione.

3.2 TOMs e livello di sicurezza: concreto anziché generico

I TOMs non devono nominare ogni singolo strumento, ma devono essere verificabili. Per gli audit è utile se il provider fornisce un catalogo TOM strutturato, che sia mappabile sui vostri requisiti (es. controllo degli accessi, registrazione/protocollazione, crittografia, separazione, disponibilità, ripristinabilità).

• Crittografia: dati a riposo e in transito, standard minimi (es. TLS), key management (KMS), opzioni per chiavi controllate dal cliente (BYOK/HYOK – Bring/Hold Your Own Key).
• Identità e accessi amministrativi: MFA, accessi privilegiati, account break-glass, accesso JIT (Just-in-Time), processo di approvazione.
• Logging: quali eventi, quali retention, possibilità di esportazione nel vostro SIEM (gestione delle informazioni e degli eventi di sicurezza).
• Gestione delle vulnerabilità: cicli di patch, classi di criticità, gestione dei zero-day, obblighi di comunicazione.

3.3 Subappaltatori e trasferimento verso paesi terzi: punti di controllo per le catene di fornitura

La maggior parte dei provider cloud impiega subappaltatori (es. gestione dei data center, supporto, servizi anti-spam/abuse). Dal punto di vista contrattuale sono rilevanti trasparenza, diritti di opposizione e obblighi di informazione. Nel trasferimento verso paesi terzi (dati al di fuori di UE/SEE) entrano in gioco clausole contrattuali standard (SCC) e valutazioni d’impatto sul trasferimento (TIA).

• Elenco aggiornato dei subappaltatori come allegato, incluso quota di servizio e categorie di dati.
• Notifica di modifica: preavviso per nuovi subappaltatori, processo di opposizione, opzioni alternative.
• Localizzazione dei dati: regioni/sedi obbligatorie, inclusi metadati, backup e accessi di supporto.
• Trasferimento verso paesi terzi: regolamentazione chiara su quando avviene, quali garanzie si applicano e come verranno comunicate le modifiche.

3.4 Diritti degli interessati, cancellazione, conservazione: l’ultimo miglio

In pratica i problemi di protezione dei dati nascono spesso durante i processi di cancellazione, i backup e gli export. Il contratto dovrebbe definire, come la cancellazione e le richieste di accesso possano essere imposte tecnicamente e quali termini si applichino.

• Piano di cancellazione: termini, attuazione tecnica (incl. backup), forma di prova (es. protocollo di cancellazione).
• Esportazione di dati personali in formati comuni (portabilità dei dati) e processo in caso di richieste di accesso di massa.
• Conservazione: retention predefinita e capacità di controllo da parte del cliente (Legal Hold vs. obbligo di cancellazione).

4) Clausole di exit e portabilità dei dati: limitare attivamente il vendor lock-in

Le clausole di exit non sono un tema da „worst case“, ma parte della normale governance. I motivi per un exit sono diversi: evoluzione dei costi, cambio di strategia, M&A, requisiti normativi, situazione della sicurezza o semplicemente un servizio che non è più adatto. Senza regole di exit un progetto ordinato può rapidamente trasformarsi in un evento di rischio.

4.1 Cosa deve prevedere contrattualmente un exit

• Trigger per l’exit: recesso ordinario, recesso straordinario, grave incidente, violazioni di compliance, ripetuta mancata osservanza degli SLA.
• Supporto alla transizione: ambito di supporto definito (tempi, ruoli, tempi di risposta), opzionalmente a pagamento, ma con logica dei prezzi e limiti massimi.
• Piano di exit come allegato: esportazione dei dati, esercizio parallelo, Cutover, responsabilità, canali di comunicazione.
• Deprovisioning: spegnimento sicuro, rimozione dei diritti di accesso, token/chiavi, account di servizio.

4.2 Restituzione dei dati: formati, completezza, integrità

„Forniamo un export“ è troppo vago. Servono precisazioni sull’ambito dei dati e sui criteri di qualità. Soprattutto nel SaaS gli export sono talvolta solo estratti CSV parziali senza integrità referenziale (relazioni tra record).

• Ambito: dati primari, metadati, configurazione, log di audit, modelli di autorizzazione, parametri di crittografia (nella misura consentita).
• Formati: formati aperti e documentati; per i database ad es. dump più schema; per object storage esportazioni strutturate incluse checksum.
• Integrità: hash/checksum, validazione campionaria, elenchi di esportazione completi.
• Tempistica: termini per la messa a disposizione e finestre di download, opzioni di proroga.

4.3 Cancellazione dei dati dopo l’exit e rendicontazione

Al termine del contratto molte organizzazioni desiderano una prova solida che i dati non vengano più conservati. Contemporaneamente devono essere rispettati gli obblighi legali di conservazione (es. derivanti dal diritto commerciale o fiscale) – spesso tale obbligo è a vostro carico, non del provider.

• Termini di cancellazione dopo l’Exit, distinti per dati produttivi, backup, log.
• Prova della cancellazione (conferma, registro, rapporto di audit) e gestione dei residui tecnici inevitabili (es. rotazione dei backup).
• Diritti sui dati derivati (es. statistiche anonimizzate) regolamentati in modo chiaro.

4.4 Controllo dei costi nell’Exit: la dimensione di controllo nascosta

I costi di exit spesso derivano dall’estrazione dei dati (Egress), dal supporto aggiuntivo o da operatività parallele a breve termine. Stabilite almeno dei paletti.

• Logica dei prezzi per il Transition Support e l’esportazione dei dati (tariffe giornaliere, forfait, limiti massimi).
• Costi di Egress: trasparenza, preavviso di variazioni di prezzo, eventualmente contingenti.
• Fine licenza/abbonamento: date di fatturazione chiare, nessun rinnovo automatico senza conferma attiva.

5) Diritti di audit, evidenze e compatibilità regolatoria

Un dilemma comune: il provider fornisce report di certificazione, ma non consente audit individuali. Questo può essere accettabile se i report coprono i vostri requisiti. Per molte aziende è cruciale che tracce di verifica esistano: quali evidenze ricevete, quanto sono aggiornate e come vengono gestite le deviazioni?

5.1 Evidenze: cosa è realistico e utile

• Relazioni di verifica indipendenti regolari (es. sui controlli ISMS) e frequenza di aggiornamento chiara.
• Right to Audit come regola graduata: verifica documentale e interviste di default; audit on-site solo per causa giustificata (es. incidente grave) e con requisiti di sicurezza.
• Evidence-API/Exports: registri, evidenze di configurazione, dati di modifica che potete integrare nei vostri processi GRC/audit.

5.2 Gestione dei findings: CAPA e scadenze

Un finding d’audit non è automaticamente un criterio di esclusione. Determinante è l’esistenza di un piano vincolante: CAPA (Corrective and Preventive Actions) con priorità, scadenze e report di avanzamento.

• Classificazione di severità e scadenze per classe.
• Trasparenza sui findings rilevanti che riguardano i vostri dati o la disponibilità.
• Diritti di recesso/speciali, se i findings critici non vengono risolti.

6) Clausole di sicurezza che supportano realmente l’operatività

Buone clausole di sicurezza non sono „solo altro testo“, ma meccaniche operative chiare: accesso, chiavi, log, accessi di emergenza, responsabilità. Particolarmente importante è il collegamento con le vostre policy interne, affinché audit e operatività parlino lo stesso linguaggio.

6.1 Accesso e identità: garantire contrattualmente i requisiti IAM

IAM (Identity and Access Management) è, negli ambienti cloud, la leva di controllo più comune. Contrattualmente dovRESTe quantomeno assicurarvi che la piattaforma offra le funzionalità di sicurezza richieste e che non vengano modificate unilateralmente.

• MFA per accessi privilegiati, SSO (Single Sign-On) tramite protocolli standard (es. SAML/OIDC) e modelli di ruolo.
• Registrazione delle azioni amministrative e accesso ai log con retention definita.

6.2 Gestione delle chiavi: chi controlla i „gioielli della corona“?

Se il provider controlla le chiavi, può (a seconda del modello) ottenere accesso nell’ambito del supporto o per richieste da parte delle autorità. Ciò non è di per sé illecito, ma deve essere compatibile con la vostra accettazione del rischio. Le opzioni BYOK/HYOK riducono questo rischio, ma aumentano la responsabilità operativa (rotazione, disponibilità del KMS, ripristino).

• Opzioni di chiave e responsabilità (rotazione, backup, accesso).
• Key Escrow e processi di rilascio (se previsti) solo a condizioni chiare.
• Richieste da parte delle autorità: obblighi informativi, per quanto legalmente possibile, e report di trasparenza.

6.3 Logging, Monitoring, integrazione SIEM: senza dati non c’è controllo

Molti incidenti cloud vengono rilevati tardi perché i log non sono raccolti centralmente o sono conservati per troppo poco tempo. Contrattualmente dovreste assicurarvi che la piattaforma fornisca le fonti di log necessarie e che esportazione/conservazione non siano limitate in modo arbitrario.

• Fonti di log minime disponibili (azioni amministrative, autenticazione, accessi ai dati, eventi di rete – a seconda del servizio).
• Periodo di conservazione e esportazione in formati standard, accesso tempestivo in caso di incidente.
• Integrità (p. es. archiviazione a prova di manomissione) per audit e attività forense.

7) Conseguenze operative e governance: ruoli, percorsi decisionali, controllo dei costi

Un contratto cloud è sempre anche un modello operativo. Se i ruoli non sono chiari o i budget non sono controllabili, nascono „processi ombra“: i team aggirano l’approvvigionamento, i log non vengono protetti, le policy vengono interpretate localmente. Questo è un problema di governance, non tecnico.

7.1 Modello di ruoli e responsabilità

• Service Owner (funzionale/tecnico) con mandato su budget e priorità.
• Security/Compliance con controlli minimi e diritti di approvazione per eccezioni di rischio.
• Operazioni IT con controllo delle change, monitoring, processo di incident e runbook.
• Vendor Management con reporting SLA, QBR (Quarterly Business Review) e logica di escalation.

7.2 Controllo dei costi e dell’utilizzo come parte contrattuale

La meccanica FinOps (controllo dei costi negli ambienti cloud) necessita di dati e diritti: tagging, budget, esportazione dei dati di utilizzo, limiti. Senza questi elementi il controllo dei costi è vano.

• Reporting dei costi ed esportazione dei dati di utilizzo in formati leggibili da macchina.
• Funzioni di budget e limiti (quotas), incluse notifiche.
• Variazioni di prezzo: termini di preavviso, trasparenza, diritto di recesso per modifiche sostanziali.

8) Checklist contrattuale compatta: clausole minime che potete „formulare“

La lista seguente è pensata come struttura per la vostra revisione contrattuale. Non sostituisce una consulenza legale, ma aiuta a tradurre i requisiti tecnici e organizzativi minimi in un linguaggio contrattuale chiaro.

8.1 SLA e gestione operativa

• Disponibilità per servizio incl. definizione di „guasto“ e metodo di misurazione
• Finestre di manutenzione con preavviso, durata, periodi non disponibili
• Priorità di supporto con tempi di risposta e di aggiornamento
• Segnalazione degli incidenti, RCA, formato dei postmortem, canali di comunicazione
• Service Credits e diritti speciali in caso di recidiva

8.2 Protezione dei dati (AVV/DSGVO)

• Ruoli, finalità, categorie di dati, regole di telemetria
• Catalogo TOM: crittografia, accesso, Logging, patch/vulnerabilità
• Elenco dei subappaltatori + notifica di modifica + processo di opposizione
• Localizzazione dei dati incl. backup/Logs/accessi di supporto
• Concetto di cancellazione, diritti degli interessati, accesso/esportazione, prove

8.3 Sicurezza e Audit

• IAM/SSO/MFA, registrazione delle azioni privilegiate, Break-Glass
• Opzioni di gestione delle chiavi (BYOK/HYOK), rotazione e responsabilità
• Esportazione log, Retention, integrazione SIEM, supporto per attività forense
• Prove/Report, modello di audit (revisione documentale/On-site in caso di necessità)
• Processo CAPA per i findings con scadenze ed escalation

8.4 Exit

• Trigger di Exit, diritti speciali di risoluzione
• Piano di Exit in allegato, Transition Support con logica dei prezzi
• Esportazione dei dati: ambito, formati, integrità (checksum), scadenze
• Cancellazione dei dati dopo l’Exit incl. backup/Logs e attestazione
• Controllo dei costi: Egress, funzionamento in parallelo, date di fatturazione

9) Modelli pratici: blocchi di testo e requisiti verificabili

Per evitare che i requisiti rimangano astratti, è utile formularli come criteri verificabili. I seguenti esempi sono descritti volutamente in termini tecnico-operativi. Dovreste adattarli al vostro contesto di rischio e alla vostra situazione legale.

9.1 Esempio: Misurazione SLA e reporting (verificabile)

Il fornitore misura mensilmente la disponibilità del servizio per ciascun servizio nominato. Si considera indisponibilità:
- per i servizi basati su API: un tasso di errore > X% (HTTP 5xx/Timeouts) su un periodo mobile di Y minuti,
- per i servizi di autenticazione: autenticazioni fallite dovute a errori del fornitore > X% su Y minuti.

I dati di misura e la logica di calcolo vengono forniti al cliente mensilmente come report leggibile da macchina.
Le finestre di manutenzione pianificate devono essere annunciate con almeno Z giorni di calendario di preavviso e non devono superare complessivamente N ore al mese.

9.2 Esempio: Modifiche dei subappaltatori e opposizione

Il fornitore mantiene un elenco aggiornato di tutti i subappaltatori che accedono ai dati del cliente o li elaborano.
I subappaltatori nuovi o sostitutivi vengono annunciati almeno 30 giorni prima della loro entrata in vigore.
Il cliente può opporsi entro 14 giorni per giusta causa. In tal caso il fornitore offre
(a) un'alternativa ragionevole senza il subappaltatore o
(b) un diritto speciale di risoluzione per i servizi interessati con un adeguato supporto alla transizione.

9.3 Esempio: Exit ed esportazione dei dati con prova di integrità

Alla fine del contratto il fornitore fornisce entro 10 giorni lavorativi un'esportazione completa dei dati,
inclusa la configurazione, le strutture di autorizzazione e i log di audit (nella misura in cui sono tecnicamente disponibili).
L'esportazione avviene in formati aperti e documentati e include checksum (p. es. SHA-256) per file/oggetto.
Il fornitore supporta il cliente per un massimo di 20 ore per chiarimenti relativi all'interpretazione dell'esportazione.
I dati di produzione vengono cancellati entro 30 giorni dopo il trasferimento riuscito secondo il concetto di cancellazione,
i backup entro 90 giorni, salvo obblighi legali di conservazione o di risoluzione delle controversie.

Conclusione: un contratto cloud è uno strumento di governance – non solo un documento d’acquisto

Con una logica contrattuale chiara i rischi cloud non si possono ’negoziare via‘, ma possono diventare gestibili: SLA misurabili, regole sulla protezione dei dati verificabili in sede di audit e una exit che funzioni operativamente. Il criterio di verifica centrale è sempre lo stesso: la vostra organizzazione è in grado di dimostrare gli obblighi in esercizio – e può, in caso di incidente, agire senza dover prima chiarire questioni interpretative? Se utilizzate questa checklist contrattuale per i provider cloud come standard minimo, un contratto generico di fornitura diventerà un quadro solido per governance, sicurezza e continuità operativa.

Anche per questo tema sono importanti Sla Cloud e Dsgvo Cloud. L’articolo contestualizza questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.