Nelle aziende digitali il cloud viene spesso trattato come un acquisto “a catalogo”. Ecco, è bene precisare subito che questo è un errore costoso!
Il cloud è un modello di erogazione basato su accesso remoto, risorse condivise, elasticità e servizi misurati. Queste caratteristiche, già in sé, spostano il baricentro del rischio dai server alla governance contrattuale.
In altre parole, quando si adotta un servizio Software as a Service (SaaS) non si compra un bene. Si entra in una relazione continuativa, spesso multilivello, con prestazioni composite (applicazioni, storage, supporto, sicurezza, continuità). E, come si è avuto modo di approfondire in un contributo pubblicato per la prestigiosa rivista Ciberspazio e Diritto (premere qui per leggere), la prassi lo conferma, il cloud, più che un tipo legale, è un contratto socialmente tipico con contenuti ricorrenti ma variabili.
E quando il rapporto è variabile, lo è anche la responsabilità.
Il punto cieco n. 1: la responsabilità “a geometria variabile”
Molti contratti cloud sono scritti per sterilizzare la responsabilità del provider e “spingere” il rischio sull’utente. In sé non è illegittimo. Diventa però problematico quando la ripartizione è opaca, o peggio, incompatibile con gli obblighi inderogabili (privacy, cybersecurity, continuità, tutela del consumatore quando rileva).
Nel cloud convivono almeno tre piani di responsabilità:
Responsabilità per indisponibilità del servizio
Il SaaS è “accesso” prima ancora che “software”. Se l’accesso cade, cade il processo aziendale.
Qui la prevenzione passa da SLA non cosmetici: disponibilità misurabile, finestre di manutenzione, metriche, rimedi credibili (service credit non simbolici), gestione incidenti e tempi di ripristino. La centralità degli SLA e dei ruoli (provider, consumer, broker, auditor) è un tratto strutturale del cloud.
Responsabilità per perdita o corruzione dei dati
Il rischio non è solo “data loss”. È anche data integrity compromessa, log incompleti, backup non verificabili.
Esternalizzare in public cloud comporta una cessione di controllo, spesso anche sull’ubicazione e sugli spostamenti dei dati. È qui che il contratto deve compensare la perdita di presidio tecnico con diritti di controllo e obblighi di trasparenza.
Responsabilità per illeciti e contenuti
Nel perimetro “hosting” (e servizi affini) la responsabilità dell’intermediario ha una disciplina peculiare, ma la prassi cloud può includere attività che vanno oltre la mera memorizzazione (indicizzazione, gestione, editing). Questo sposta l’analisi dal principio astratto alla funzione concreta del rapporto e alle prestazioni effettive.
Il risultato è chiaro: la responsabilità nel cloud non è mai “standard”. Va disegnata.
Il punto cieco n. 2: i dati come obbligazione principale, non accessoria
Nel SaaS i dati sono il vero asset. Eppure nei contratti vengono spesso trattati come allegato marginale.
È una sottovalutazione pericolosa, perché il dato impatta simultaneamente:
(i) protezione dei dati personali: ruoli, istruzioni, sub-responsabili, trasferimenti, misure tecniche e organizzative, audit, incident response;
(ii) segreto industriale e riservatezza: dataset, modelli, logiche, configurazioni;
(iii) continuità operativa: accessibilità, portabilità, exit.
Sui ruoli privacy, la letteratura e la prassi ricordano che il cloud può implicare catene di fornitura complesse, con subfornitori e servizi “a strati”. È proprio qui che l’impresa committente rischia di non vedere l’intera filiera del trattamento, e quindi di non controllarla.
Dove sono i dati? La domanda che decide il contenzioso
“Dove” non è una curiosità tecnica. È bensì una clausola di rischio: giurisdizione, accessi governativi, trasferimenti, misure.
Le analisi operative richiamano esplicitamente la necessità di presidiare contrattualmente localizzazione, spostamenti e catena dei subfornitori, anche già in fase precontrattuale.
E dal 2025 in avanti la portabilità smette di essere solo “best practice”.
Il 2025–2026 alza l’asticella: portabilità e sicurezza diventano regola
Due traiettorie recenti incidono direttamente anche sulle aziende digitali non regolamentate “in senso stretto”.
Data Act: la portabilità non è più una “gentile concessione”
Il Regolamento (UE) 2023/2854 (Data Act) segna una cesura netta rispetto alla prassi contrattuale che, per oltre un decennio, ha governato i servizi cloud. La portabilità dei dati non è più una concessione commerciale, né un’opzione negoziale subordinata al potere contrattuale del provider. Diventa, a tutti gli effetti, un obbligo regolatorio strutturale, destinato a incidere profondamente sulla redazione e sull’interpretazione dei contratti SaaS, PaaS e IaaS.
Il Data Act nasce infatti con un obiettivo dichiarato: ridurre le barriere allo switching e contrastare i fenomeni di vendor lock-in che hanno caratterizzato il mercato cloud europeo.
Per anni la dipendenza tecnologica è stata alimentata da tre fattori ricorrenti, e cioè i formati proprietari o non interoperabili, i costi di uscita elevati e opachi e l’assenza di obblighi temporali certi per la migrazione.
Il Regolamento interviene proprio su questo terreno, imponendo una normalizzazione giuridica dell’uscita dal servizio.
Non si tratta di favorire la mobilità per principio, ma di riequilibrare un mercato strutturalmente asimmetrico.
Uno degli errori più diffusi è leggere la portabilità come mera restituzione del dato grezzo. Il Data Act adotta invece una nozione funzionale, che guarda all’effettiva possibilità di riutilizzo.
In concreto, la portabilità riguarda:
- dati esportabili in formato strutturato, comunemente usato e leggibile da macchina;
- metadati necessari alla comprensione e al riutilizzo;
- tempi certi per l’esecuzione della migrazione;
- assistenza tecnica ragionevole durante il passaggio a un nuovo fornitore.
Ne deriva un principio chiave: la restituzione non deve essere meramente teorica, ma operativamente utile. Un export formalmente corretto ma inutilizzabile in ambiente produttivo non soddisfa il Regolamento.
Non solo, il Data Act incide in modo diretto su una delle clausole più critiche dei contratti cloud: i costi di uscita.
Il Regolamento prevede infatti il divieto di costi di switching ingiustificati, una progressiva riduzione dei costi di migrazione e l’obiettivo di azzeramento dei costi per il cambio fornitore al termine del periodo transitorio.
Questo significa che le clausole che subordinano l’uscita a fee elevate, penali mascherate o servizi “obbligatori” di migrazione imposti dal provider diventano regolatoriamente fragili, se non apertamente incompatibili.
Alla luce del Data Act, poi, la exit strategy non può più essere relegata alle condizioni generali o a un allegato tecnico.
Una clausola di uscita coerente con il nuovo quadro dovrebbe disciplinare in modo puntuale tempistiche massime per la migrazione, formati di restituzione e standard utilizzati, supporto tecnico incluso e suoi limiti, continuità del servizio durante la fase di transizione e cancellazione certificabile dei dati residui.
La portabilità diventa così una obbligazione contrattuale qualificata, non una prestazione eventuale.
Il rafforzamento della portabilità produce un effetto sistemico: riduce l’asimmetria informativa e riequilibra la responsabilità negoziale.
Un provider che ritarda la migrazione, o che ostacola tecnicamente l’export, o ancora che restituisce dati incompleti o inutilizzabili, non viola solo il contratto, ma espone l’utente a rischi operativi, reputazionali e regolatori.
La responsabilità non è più confinata al perimetro SLA, ma incide sulla continuità aziendale del cliente.
Per le aziende digitali, questo significa una cosa sola: la governance del dato non può più essere separata dalla governance contrattuale.
NIS2 in Italia: obblighi di cybersecurity e filiera
La Direttiva (UE) 2022/2555 (NIS2) segna un cambio di paradigma in quanto non introduce soltanto nuovi obblighi di sicurezza, ma trasforma la cybersecurity da presidio tecnico-organizzativo a dovere giuridico strutturale, con riflessi immediati sulla contrattualistica cloud e SaaS.
Il recepimento italiano avviene con il d.lgs. 4 settembre 2024, n. 138, che assegna all’Agenzia per la Cybersicurezza Nazionale (ACN) un ruolo centrale di vigilanza, indirizzo e controllo.
Il punto, per le aziende digitali, non è più soltanto stabilire se rientrano nel perimetro NIS2. Il vero nodo è come gli obblighi si riflettono a valle, lungo la filiera dei fornitori tecnologici.
La NIS2 amplia in modo significativo i soggetti destinatari, distinguendo tra soggetti essenziali e soggetti importanti, sulla base del settore e delle dimensioni, ma il suo impatto non si esaurisce nei confini formali della norma.
Viene infatti chiarito un principio decisivo: la gestione del rischio non si arresta all’organizzazione, ma si estende alla supply chain.
In termini concreti, ciò significa che il rischio cyber generato da un fornitore cloud diventa rischio giuridicamente rilevante per il cliente, e che l’esternalizzazione non attenua la responsabilità, la ridisegna, e quindi la sicurezza del servizio dipende dalla sicurezza dell’intera filiera ICT.
La cybersecurity diventa, quindi, una prestazione indiretta ma essenziale del contratto cloud.
Il d.lgs. 138/2024 impone l’adozione di misure tecniche, operative e organizzative adeguate e proporzionate.
La formula è volutamente elastica, ma non indeterminata. Tra i requisiti minimi, infatti, emergono:
- gestione strutturata del rischio;
- politiche di sicurezza documentate;
- sicurezza della supply chain;
- gestione delle vulnerabilità;
- controllo degli accessi;
- crittografia e protezione dei dati;
- sicurezza nello sviluppo e nella manutenzione dei sistemi.
Questi elementi, se traslati sul piano contrattuale, non possono restare dichiarazioni di principio. Devono bensì diventare obblighi verificabili, corredati da evidenze, audit e diritti di controllo.
Un contratto cloud che si limita a richiamare genericamente “misure adeguate” senza specificazione rischia di essere inermi in sede di incidente.
Uno dei profili più incisivi della NIS2 riguarda poi la gestione degli incidenti. La norma prevede infatti obblighi di notifica tempestiva, flussi informativi strutturati verso l’ACN, aggiornamenti progressivi sull’evoluzione dell’incidente e la predisposizione di report finali.
Nel rapporto cliente–provider, questo si traduce in una domanda cruciale: chi comunica cosa, a chi e in quanto tempo?
E’ chiaro quindi che senza una disciplina contrattuale puntuale il cliente rischia di non ricevere informazioni utili nei tempi richiesti dalla norma, il provider può trovarsi a gestire l’incidente secondo logiche incompatibili con gli obblighi regolatori del cliente ed allora la responsabilità diventa difficilmente allocabile.
La prevenzione passa quindi da incident response clause che definiscano ruoli, tempi, canali e contenuti delle comunicazioni.
La NIS2 introduce poi un concetto che incide profondamente sul cloud, e cioè quello della sicurezza della catena di approvvigionamento.
Il legislatore europeo parte da un dato empirico, molti incidenti gravi non nascono da attacchi diretti, ma da fornitori compromessi. Il decreto italiano recepisce questa impostazione, imponendo valutazioni e controlli sui partner ICT.
Nel cloud questo significa conoscere i subfornitori del provider, valutare dove e come vengono erogati i servizi, presidiare l’outsourcing a cascata ed evitare clausole che impediscano o limitino il diritto di verifica.
Il contratto SaaS diventa così uno strumento di estensione del perimetro di sicurezza, non un semplice accordo di servizio.
Ed allora lla luce della NIS2, un contratto cloud realmente “difensivo” dovrebbe includere almeno obblighi di sicurezza dettagliati, non meramente dichiarativi, diritti di audit e accesso alle evidenze, diretti o tramite terzi, discipline chiare sugli incidenti, con tempi compatibili con la normativa, clausole sulla supply chain, che impediscano subforniture incontrollate e meccanismi di cooperazione regolatoria, in caso di richieste dell’ACN.
Non è iper-regolazione. È allineamento normativo.
DORA: le “lezioni” sulla gestione dei fornitori critici
Il Regolamento (UE) 2022/2554 (DORA), applicabile dal 17 gennaio 2025, nasce per rafforzare la resilienza operativa digitale del settore finanziario. La sua portata, tuttavia, eccede il perimetro soggettivo formale. DORA introduce un modello giuridico di gestione del rischio ICT che funge da benchmark regolatorio anche per le aziende digitali non vigilate.
Il messaggio di fondo è netto: quando un servizio ICT è essenziale per la continuità operativa, il relativo fornitore non può più essere gestito come un vendor ordinario.
DORA non si limita a imporre obblighi agli enti finanziari, ma attribuisce rilevanza giuridica autonoma ai fornitori terzi di servizi ICT, in particolare a quelli qualificabili come critici o importanti.
Nel cloud questo riguarda, tipicamente fornitori SaaS core per processi primari, provider infrastrutturali (IaaS/PaaS), servizi di data analytics, cybersecurity, business continuity, e piattaforme che concentrano funzioni operative essenziali.
Il criterio non è formale, ma funzionale: un fornitore è critico quando la sua indisponibilità o compromissione può generare interruzioni gravi, perdite rilevanti o violazioni regolatorie.
È un approccio che può essere trasposto integralmente anche fuori dal settore finanziario.
Uno degli assunti impliciti di molta contrattualistica cloud è che l’esternalizzazione riduca il rischio. DORA ribalta questa impostazione: il rischio non si trasferisce, ma si trasforma.
Il regolamento impone agli enti finanziari di identificare e classificare i fornitori ICT, valutare il rischio associato a ciascun servizio, presidiare l’intero ciclo di vita del rapporto contrattuale e garantire continuità, resilienza e reversibilità.
Il contratto diventa, quindi, lo strumento primario di governo del rischio esternalizzato.
Questa logica è perfettamente replicabile nelle aziende digitali che dipendono strutturalmente dal cloud.
Pur non applicandosi direttamente, DORA offre indicazioni operative molto chiare su come dovrebbe essere scritto un contratto cloud quando il servizio è critico.
1. Classificazione del servizio
Il contratto dovrebbe distinguere tra servizi accessori, servizi rilevanti e servizi critici per la continuità. Una classificazione non meramente teorica, ma che serve a calibrare obblighi, responsabilità, livelli di controllo e rimedi.
2. Accesso, audit e ispezioni
DORA impone diritti di accesso, ispezione e audit sui fornitori critici.
Trasposto nel cloud, questo significa superare clausole che escludono ogni audit, che limitano l’accesso a report standardizzati non verificabili e che subordinano i controlli a consenso discrezionale del provider.
Per i servizi critici, il diritto di verifica diventa una clausola di equilibrio, non di sfiducia.
3. Continuità operativa e test di resilienza
Il regolamento richiede test periodici di resilienza operativa.
Nel cloud, ciò si traduce in obblighi di business continuity e disaster recovery documentati, in test periodici (anche con il cliente), in evidenze tecniche disponibili e in coordinamento tra piani del provider e del cliente.
Un contratto che tace su questi profili lascia scoperto il momento più delicato, la crisi.
4. Incident reporting e cooperazione
DORA enfatizza la tempestività e la qualità delle informazioni sugli incidenti ICT.
Nel rapporto contrattuale ciò implica notifiche rapide e strutturate, flussi informativi compatibili con obblighi regolatori del cliente, cooperazione attiva nella gestione dell’incidente e supporto alla comunicazione verso autorità e stakeholder.
L’assenza di una disciplina chiara genera conflitti proprio quando il tempo è il fattore decisivo.
5. Exit strategy e concentrazione del rischio
Uno degli aspetti più innovativi di DORA è l’attenzione al concentration risk, cioè l’eccessiva dipendenza da pochi fornitori critici.
Il contratto cloud, in questa prospettiva, deve rendere possibile la migrazione, evitare dipendenze tecnologiche irreversibili, prevedere piani di uscita realistici e non ostacolare la multi-cloud strategy.
Qui il dialogo con il Data Act è evidente. Portabilità e resilienza sono due facce della stessa prevenzione.
Dalla teoria alla pratica: le clausole che fanno davvero prevenzione
Come obiettivo editoriale dichiarato, quest’anno ci siamo imposti di dare un taglio più pratico e meno teorico ai nostri contributi, motivo per cui l’analisi che segue non si limita alla ricostruzione dei profili teorici o regolatori del cloud computing, già ampiamente indagati in dottrina e nella prassi (ed anche su questo portale – premere qui per approfondire). L’obiettivo qui è diverso. Si intende fornire criteri concreti di lettura e di intervento contrattuale, utili a prevenire contenziosi, discontinuità operative e responsabilità latenti. Le clausole esaminate sono quelle che, nella pratica negoziale, fanno realmente la differenza, non per il loro valore formale, ma per la loro capacità di governare il rischio tecnologico prima che si trasformi in rischio giuridico.
Qui infatti la prevenzione è concreta. Non serve un contratto lungo. Serve un contratto esigibile.
1) Oggetto e perimetro del servizio
Pretendere una descrizione non anfibia: funzionalità, ambienti, dipendenze, limiti, esclusioni, requisiti minimi del cliente.
Nel cloud la “virtualizzazione” e la fruizione “as a service” rendono frequente l’ambiguità sull’oggetto: chiarirlo riduce la zona grigia che alimenta le contestazioni.
2) SLA e rimedi effettivi
Disponibilità misurata, metodologie di calcolo, penali o service credit proporzionati, escalation, RTO/RPO, obblighi di comunicazione, reportistica.
3) Sicurezza e auditabilità
Misure tee, gestione vulnerabilità, log, segregazione multi-tenant, access control, cifratura, procedure di incident response.
La criticità del public cloud non va mai sottovalutata visto il concreto rischio perdita di controllo e la complessità infrastrutturale. Tutto ciò va compensato con obblighi di trasparenza e garanzie verificabili.
4) Data governance: titolarità, istruzioni, subfornitori
Chi è titolare, chi è responsabile, chi sono i sub-responsabili, come si autorizzano, come si controllano.
Nelle filiere cloud, questo è il punto che “salta” unto che, quando salta, produce i costi più alti.
5) Exit strategy e portabilità
Restituzione dati in formato utile, tempi, costi, cancellazione certificabile, assistenza alla migrazione, continuità durante il recesso, retention dei log.
6) Responsabilità e limitazioni: “cap” sì, ma con eccezioni intelligenti
Limitazioni di responsabilità ragionevoli possono reggere. Ma vanno scolpite con eccezioni: dolo/colpa grave, violazioni di riservatezza, data breach imputabile, violazioni su proprietà intellettuale quando pertinenti, obblighi di sicurezza essenziali.
Il vero obiettivo: ridurre l’alea, non trasferirla
Il cloud non è un male. È una leva competitiva.
Ma la leva diventa trappola quando l’azienda digitale firma condizioni che trasformano un servizio essenziale in una prestazione “a discrezione”, con responsabilità evanescenti e dati trattati come accessorio.
La dottrina civilistica sul cloud e sull’hosting ricorda che la qualificazione non va cercata dogmaticamente, bensì nella funzione concreta del rapporto e negli interessi in gioco. È un criterio di metodo che, in pratica, significa una cosa: leggere il contratto con lo stesso realismo con cui si legge un incidente in produzione.
Insomma, se la vostra azienda sta adottando o rinnovando servizi SaaS, PaaS o IaaS, una analisi contrattuale preventiva può evitare dispute su indisponibilità, perdita dati, subfornitura e exit. Verificare oggi la tenuta contrattuale significa ridurre l’esposizione a contenziosi, interruzioni operative e non conformità regolatorie.
PER APPROFONDIRE:
- N. NAPPI, I contratti di cloud computing alla luce dell'entrata in vigore della Direttiva UE 770/2019: species del genus dei contratti di fornitura di contenuti e servizi digitali?, in Ciberspazio e Diritto, 1-2022, p. 79 ss.;
- G. SARTOR, L'Informatica Giuridica e le Tecnologie dell'Informazione, Torino, 2016;
- C. PERLINGIERI, Profili civilistici dei social networks, Napoli, 2014;
- Comunicazione della Commissione al Parlamento Europeo, al Consiglio, al Comitato Economico e Sociale Europeo e al Comitato delle Regioni, Un'agenda digitale europea, COM(2010)245 def., 19/05/2010;
- GARANTE PER LA PROTEZIONE DEI DATI PERSONALI, Proteggere i dati per non cadere dalle nuvole, Miniguida per imprese e pubblica amministrazione, 24 Maggio 2012, https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/189449. [Consultato il giorno 2 Novembre 2021];
- C. CAMARDI, Prime osservazioni sulla Direttiva (UE) 2019/770 sui contratti per la fornitura di contenuti e servizi digitali. Operazioni di consumo e circolazione di dati personali, in Giustizia Civile, vol. 2/2019, p. 499;
- M. FARINA, Cloud Computing, in G. ZICCARDI - P. PERRI, Dizionario Legal tech, Milano, 2020, p. 176 e ss.;
- MELL - GRANCE, The NIST Definition of Cloud Computing. Recommendations of the National Institute of Standards and Technology, Special Publication 800-145, Settembre 2011, https://nvlpubs.nist.fov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf. [Consultato il giorno 2 Novembre 2021];
- A. MANTELERO, Processi di outsourcing informatico e cloud computing: la gestione dei dati personali ed aziendali, in Diritto dell'Informazione e Informatica, 4/5 2010, pp. 682-683;
- D. MULA, Il contratto di fornitura di servizi cloud, in C. PERLINGIERI – L. RUGGERI Internet e Diritto Civile, Napoli, 2015, p. 549 ss.;
- S. BRADSHAW - C. MILLARD - I. WALDEN, Contracts for Clouds: Comparison and Analysis of the Terms and Conditions of Cloud Computing Services, in International Journal of Law & Information Technology, 2011, 11;
- W.K. HON - J. HÖRNLE - C. MILLARD, Data Protection Jurisdiction and Cloud Computing - When are Cloud Users and Providers Subject to EU Data Protection Law? The Cloud of Unknowing Part 3, in International Review of Law Computer & Technology, 2012, 19;
- A. MARTINI, Dalla "nuvola" al negozio: il contratto di cloud computing, in La Nuova Giurisprudenza Civile Commentata, 4/2020, p. 970 ss.;
- A. BENLIAN - T. HESS - P. BUXMANN (a cura di), Software-as-a-Service: Anbieterstrategien, Kundenbedürfnisse und Wertschöpfungsstrukturen, Wiesbaden, 2010;
- G. LAWTON, Developing Software Online With Platform-as-a-Service Technology, in Computer, VI 2008, p. 13;
- K. ROEBUCK, Platform As a Service (PaaS), LaVergne, 2012;
- A. MANTELERO, Il contratto per l'erogazione alle imprese di servizi di cloud computing, in Contratto ed imprese, 4-5, 2012, pp. 1216-1222;
- S. BHARDWAJ - L. JAIN - S. JAIN, Cloud Computing: A Study of Infrastructure as a Service (IaaS), in International Journal of Engineering and Information Technology, I, 2010, p. 62;
- K. YONGSIRIWIT - N. ASSY - W. GAALOUL, A semantic framework for configurable business process as a service in the cloud, in Journal of Network and Computer Application, n. 59, luglio 2015;
- L. NEIROTTI, Contratto cloud computing, la guida per tutelarsi: ecco come, in Agenda Digitale, 23 Marzo 2021, https://www.agendadigitale.eu/sicurezza/contratto-cloud-computing-la-guida-completa-ecco-come-funziona/. [Consultato il giorno 2 Novembre 2021];
- C. FLICK - V. AMBRIOLA, Dati nelle nuvole: aspetti giuridici del cloud computing e applicazione alle amministrazioni pubbliche, in Federalismi.it, 20 Marzo 2013, https://www.federalismi.it/nv14/articolo-documento.cfm?artid=22061. [Consultato il giorno 2 Novembre 2021];
- S. SADEGHANI - M. J. TAROKH, A Cost Model for Hybrid Cloud, 2017;
- X. YANG - T. LEHMAN, Model driven advanced hybrid cloud services for big data: paradigm and practice, in Proceedings of the 7th International Workshop on Data-Intensive Computing in the Cloud, novembre 2016, pp. 32 - 36.
Nicola Nappi
Ultimi post di Nicola Nappi (vedi tutti)
- E-commerce: gli obblighi legali decisivi - 30 Marzo 2026
- Videosorveglianza sul lavoro: gli errori che costano caro - 23 Marzo 2026
- Il DPO esterno nelle PMI - 16 Marzo 2026
- Data breach: cosa fare nelle prime 72 ore - 9 Marzo 2026
- Privacy e imprese: il problema non è il regolamento - 2 Marzo 2026
