Contractul de Furnizare Servicii Cloud — SLA, Securitate și Răspundere

Pe scurt

Contractul de furnizare servicii cloud (IaaS, PaaS, SaaS) nu are o reglementare unitară în dreptul român, ci se supune unui ansamblu de norme: Codul Civil (prestări servicii), GDPR (protecția datelor), OUG 155/2024 (securitate cibernetică NIS2), OUG 141/2021 (servicii digitale B2C) și Regulamentul Data Act (portabilitate date B2B). Acest articol explică cadrul legal, clauzele esențiale ale unui SLA și mecanismele de răspundere.

Cadrul legal

Dreptul comun — Codul Civil

Contractul cloud este, în esență, un contract de prestări servicii reglementat de Art. 2013-2042 din Codul Civil. Prestatorul (furnizorul cloud) se obligă să furnizeze un serviciu digital, iar beneficiarul plătește un preț.

Art. 2013 Cod Civil — Prin contractul de antrepriză, antreprenorul se obligă ca, pe riscul său, să execute o anumită lucrare, materială ori intelectuală, sau să presteze un anumit serviciu pentru beneficiar, în schimbul unui preț. Sursa: Codul Civil, Legea 287/2009

Dispozițiile generale privind răspunderea contractuală (Art. 1350 Cod Civil) se aplică în mod direct: furnizorul răspunde pentru neexecutarea obligațiilor asumate prin contract, inclusiv pentru întârziere și executare necorespunzătoare.

OUG 141/2021 — Servicii digitale (B2C)

Pentru contractele cu consumatori, se aplică OUG 141/2021 (transpunere a Directivei UE 2019/770), care reglementează furnizarea de conținut digital și servicii digitale. Serviciile cloud de tip SaaS intră în definiția serviciului digital (Art. 2 pct. 13 OUG 141/2021): un serviciu care permite consumatorului crearea, prelucrarea, stocarea sau accesarea datelor în format digital.

Obligații cheie ale furnizorului cloud în relația B2C:

Conformitate — serviciul trebuie să corespundă descrierii, funcționalității și interoperabilității promise (Art. 6-7)
Actualizări de securitate — furnizorul trebuie să asigure actualizări pe toată durata contractului (Art. 7 alin. 3)
Modificări ale serviciului — permise doar dacă sunt prevăzute contractual, fără costuri suplimentare, cu notificare prealabilă pe suport durabil (Art. 18)
Răspundere pe 5 ani — pentru neconformități existente la momentul furnizării (Art. 10 alin. 2)
Sancțiuni — amenzi de la 5.000 lei la 50.000 lei, aplicate de ANPC (Art. 21)

Art. 13 alin. 3 OUG 141/2021 — Comerciantul aduce conținutul digital sau serviciul digital în conformitate [...] într-o perioadă de timp rezonabilă care nu poate depăși 15 zile calendaristice. Sursa: OUG 141/2021

Într-un contract cloud, furnizorul acționează de regulă ca împuternicit (processor), iar clientul ca operator (controller) de date cu caracter personal. Art. 28 GDPR impune un acord de prelucrare a datelor (DPA) care trebuie să conțină:

Obiectul și durata prelucrării
Natura și scopul prelucrării
Tipul datelor și categoriile de persoane vizate
Obligațiile și drepturile operatorului
Instrucțiuni documentate de prelucrare
Notificarea încălcărilor de securitate fără întârziere (Art. 33 GDPR)

Furnizorul cloud nu poate angaja un sub-împuternicit (sub-processor) fără autorizarea prealabilă, scrisă, specifică sau generală, a operatorului (Art. 28 alin. 2 GDPR). Contractul trebuie să prevadă dreptul operatorului de a se opune adăugării unui nou sub-processor.

Transferuri internaționale de date: Dacă furnizorul cloud stochează date în afara SEE, sunt necesare garanții adecvate — clauze contractuale standard (SCC), reguli corporatiste obligatorii (BCR) sau o decizie de adecvare a Comisiei Europene (Art. 44-49 GDPR).

OUG 155/2024 — Securitate cibernetică (NIS2)

OUG 155/2024 transpune Directiva NIS2 (Directiva UE 2022/2555) și abrogă Legea 362/2018. Furnizorii de servicii de cloud computing sunt menționați explicit (Art. 4 lit. ll) și intră sub jurisdicția DNSC (Directoratul Național de Securitate Cibernetică) dacă sediul lor principal UE este în România (Art. 7 alin. 3).

Clasificare:

Entitate esențială — întreprinderi mari care furnizează servicii cloud (Art. 5 alin. 2)
Entitate importantă — întreprinderi mijlocii din sectoare acoperite (Art. 6 alin. 1)

Obligații de securitate (Art. 11-12):

Măsuri tehnice, operaționale și organizatorice proporționale pentru gestionarea riscurilor
Politici de securitate a rețelelor și sistemelor informatice
Gestionarea incidentelor și continuitatea activității
Securitatea lanțului de aprovizionare (security supply chain)
Audit periodic de securitate cibernetică

Raportare incidente (Art. 15):

Notificare inițială către DNSC în 24 de ore de la constatarea incidentului
Raport complet în 72 de ore

Sancțiuni (Art. 60-61):

Entități esențiale: până la 2% din cifra de afaceri anuală sau 10.000.000 EUR (care valoare este mai mare)
Entități importante: până la 1,4% din cifra de afaceri anuală sau 7.000.000 EUR
Conducerea poate fi suspendată temporar din funcțiile executive

Regulamentul Data Act (UE) 2023/2854

Aplicabil din 12 septembrie 2025, Data Act impune furnizorilor cloud obligații de portabilitate și interzicere a clauzelor abuzive în contractele B2B:

Dreptul de switch — clientul trebuie să poată migra datele și aplicațiile la un alt furnizor (Art. 23-26)
Eliminarea taxelor de ieșire (egress fees) — de la 12 ianuarie 2027 (Art. 29)
Interoperabilitate — furnizorii trebuie să respecte standarde deschise și interfețe comune (Art. 30)
Clauze contractuale abuzive B2B — sunt nule clauzele care dezechilibrează în mod semnificativ drepturile și obligațiile părților (Art. 13)

Explicație detaliată

Natura juridică — contract complex, nu simplu prestări servicii

Contractul cloud include elemente de prestări servicii (acces la platformă), licență software (aplicații SaaS), depozit de date (stocare) și eventual locațiune de infrastructură virtuală (IaaS). Cu toate acestea, calificarea unitară ca prestări servicii se justifică prin:

Criteriul prestației caracteristice — în doctrina contractelor mixte din dreptul român, contractele complexe se califică după prestația care determină centrul de greutate al raportului juridic. La contractele cloud, prestația caracteristică este furnizarea continuă a unui serviciu digital accesibil online, iar elementele de licență, stocare sau infrastructură sunt accesorii integrate, nu prestații autonome.

Art. 1171 Cod Civil prevede că regulile contractelor denumite se aplică prin analogie și contractelor nenumite. Contractul cloud, ca tip de contract complex, se supune regulilor contractului de antrepriză/prestări servicii (Art. 2013-2042 CC) pentru prestația principală, cu aplicarea subsidiară a normelor specifice acolo unde natura prestației o impune.

Directiva (UE) 2019/770, transpusă prin OUG 141/2021, confirmă această abordare unitară: definește serviciul digital ca incluzând explicit serviciile cloud (SaaS, stocare în cloud, rețele sociale), indiferent de componentele tehnice subiacente. Art. 2 pct. 13 OUG 141/2021 acoperă „un serviciu care permite consumatorului crearea, prelucrarea, stocarea sau accesarea datelor în format digital".

Consecință practică: clientul beneficiază de un regim juridic unitar — nu trebuie să gestioneze separat un contract de licență, un contract de depozit și unul de locațiune. Furnizorul răspunde unitar pentru conformitatea și continuitatea întregului serviciu.

Când furnizorul cloud principal este din SUA, apare un conflict juridic direct între obligațiile GDPR și US CLOUD Act (2018), care permite autorităților federale americane să solicite date de la orice entitate americană, indiferent de locul stocării.

Art. 48 GDPR stipulează că hotărârile și deciziile autorităților din state terțe sunt recunoscute și executabile doar dacă se bazează pe un acord internațional (ex. tratat de asistență juridică reciprocă — MLAT). CLOUD Act nu se bazează pe un astfel de acord, deci transferurile solicitate pe această bază încalcă GDPR.

EDPB Guidelines 02/2024 (privind Art. 48 GDPR) clarifică: orice transfer necesită (1) bază legală sub Art. 6 GDPR și (2) conformitate cu Capitolul V (transferuri internaționale). CLOUD Act nu satisface niciuna.

Data Act Art. 32 extinde protecția și la date non-personale: furnizorul trebuie să ia „toate măsurile adecvate" pentru a preveni accesul guvernamental terț la datele non-personale din UE.

EU-U.S. Data Privacy Framework (decizia de adecvare din iulie 2023) oferă o cale parțială de conformitate pentru transferuri către furnizori certificați DPF. Cu toate acestea, nu rezolvă complet conflictul — furnizorul rămâne supus cererilor CLOUD Act chiar și cu certificare DPF.

Măsuri de protecție contractuale:

Criptare end-to-end cu chei gestionate de client (client-managed keys) — cea mai eficientă barieră
Clauze contractuale care interzic transferuri fără consimțământul explicit al clientului
Drept de reziliere imediată dacă furnizorul transferă date pe baza unei cereri CLOUD Act
Strategie multi-cloud cu furnizori din diferite jurisdicții pentru distribuirea riscului

Protecția IMM/PFA față de hyperscaleri

Un IMM sau PFA român care contractează cu un hyperscaler (AWS, Azure, Google Cloud) se confruntă cu termeni standard nenegociabili și limite de răspundere foarte joase. Protecția reală este fragmentată dar nu inexistentă:

1. Data Act Art. 13 (în vigoare din 12 septembrie 2025) — instituie pentru prima dată o protecție B2B împotriva clauzelor contractuale abuzive în domeniul accesului și utilizării datelor. Sunt nule clauzele care: exclud răspunderea pentru intenție sau culpă gravă, exclud remediile pentru neexecutare, sau acordă unei singure părți dreptul de a interpreta contractul. Protecția se aplică clauzelor legate de date, nu tuturor clauzelor cloud.

2. Art. 1355 alin. 4 Cod Civil — interdicție imperativă: nimeni nu poate exclude răspunderea pentru culpă gravă sau intenție (dol). O clauză de limitare la 12 luni de taxe nu protejează furnizorul dacă pierderea de date rezultă din neglijență gravă.

3. Art. 1203 Cod Civil — clauzele neobișnuite dintr-un contract de adeziune (cum ar fi limitări drastice de răspundere sau renunțarea la dreptul de audit) trebuie acceptate separat și explicit. Simpla acceptare a Termenilor Generali nu este suficientă.

4. Art. 1170 Cod Civil — principiul bunei-credințe în executarea contractului.

Limitări: Legea 193/2000 (clauze abuzive) se aplică doar în B2C, nu B2B. DMA nu a desemnat încă furnizorii cloud ca „gatekeepers" (metricile se bazează pe utilizatori consumatori, nu contracte enterprise).

Strategii practice: negociați pe baza Data Act Art. 13; solicitați acceptare separată pentru limitări de răspundere; documentați orice incident ca potențială culpă gravă; implicați consilier juridic înainte de semnare.

Insolvența furnizorului cloud

Insolvența furnizorului cloud produce efecte complexe la intersecția mai multor regimuri juridice:

Contracte în curs (Legea 85/2014, Art. 86-87) — contractul cloud nu se reziliează automat la deschiderea procedurii de insolvență. Administratorul judiciar decide continuarea sau rezilierea. Dacă serviciile cloud sunt necesare pentru restructurare sau lichidare ordonată, ele pot fi continuate ca „activități curente" (Art. 5 pct. 2).

Acces la date — datele rămân proprietatea clientului. Furnizorul le deține doar ca processor. Administratorul judiciar poate fi obligat de judecătorul-sindic să mențină accesul temporar (30-90 zile) și să faciliteze exportul datelor.

GDPR nu se suspendă prin insolvență — Art. 28 GDPR obligă procesatorul să returneze sau să șteargă toate datele personale la încetarea serviciilor. Lichidatorul furnizorului devine responsabil pentru conformitate GDPR.

Obligații fiscale — Legea 82/1991 (contabilitate) impune retenția documentelor contabile pentru 5-10 ani. Furnizorul nu poate șterge date fiscal-relevante chiar dacă clientul o solicită. Art. 28 GDPR permite această retenție dacă „legislația unui stat membru o impune".

Data Act Art. 23-26 — drepturile de comutare și portabilitate rămân exercitabile chiar în insolvență. Lichidatorul nu poate refuza exportul datelor; clientul poate solicita intervenția judecătorului-sindic.

Protecții contractuale esențiale: clauze de escrow de date (terță parte neutră păstrează copii), drepturi de acces garantate în caz de insolvență, backup multi-cloud, SLA-uri cu termene explicite pentru export la reziliere.

Data Act — standarde și acte de implementare

Multe obligații din Data Act (Regulamentul 2023/2854) depind de acte de implementare și standarde tehnice care nu sunt încă finalizate, creând un decalaj între cerințele legale și aplicabilitatea practică:

Art. 30 (aspecte tehnice ale comutării) — furnizorul trebuie să asigure compatibilitatea cu „specificații comune bazate pe specificații deschise de interoperabilitate" în termen de 12 luni de la publicarea lor. Aceste specificații trebuie adoptate de Comisie ca acte de implementare sau dezvoltate ca standarde armonizate de CEN/CENELEC.

Art. 33 (cerințe esențiale de interoperabilitate) — structura datelor, formatele, vocabularele și mijloacele tehnice de acces trebuie definite prin standarde armonizate. CEN, CENELEC și ETSI s-au angajat să livreze 4 standarde europene (EN) și 3 specificații tehnice (TS) prin comitetul CEN-CLC/JTC 25 „Data Management, Dataspaces, Cloud and Edge" — dar calendarele se extind în 2026-2027.

Art. 35 (interoperabilitate serviciilor de prelucrare) — cinci niveluri de interoperabilitate (portabilitate sintactică, instrucțiuni, metadate, comportament, politici) trebuie asigurate pe baza specificațiilor comune.

Art. 29 (eliminarea taxelor de comutare) — taxele de ieșire se elimină complet de la 12 ianuarie 2027. Până atunci, pot fi percepute taxe reduse, limitate la costurile directe ale procesului de comutare.

Calendar și riscuri: obligațiile statutare de interoperabilitate intră în vigoare la 12 septembrie 2026, dar standardele CEN/CENELEC probabil nu vor fi finalizate decât în 2027, creând un decalaj de 6-12 luni. Recomandare pentru contracte: includeți clauze de flexibilitate care permit ajustarea specificațiilor tehnice odată cu publicarea standardelor, și clauze de renegociere la adoptarea actelor de implementare.

Dreptul de audit în medii multi-tenant

Exercitarea dreptului de audit al clientului (Art. 28 alin. 3 lit. h GDPR) în medii cloud multi-tenant este o provocare practică majoră. Furnizorul poate refuza accesul direct invocând securitatea și confidențialitatea altor clienți. Soluțiile practice acceptate:

1. Certificări independente de terță parte — ISO 27001 (securitate informațională), ISO 27017/27018 (controale specifice cloud), SOC 2 Type II (audit operațional anual). Rapoartele certificatorilor acoperă domeniile relevante GDPR și NIS2.

2. Audituri programate cu restricții — conform EU Cloud Code of Conduct (aprobat EDPB 2024), furnizorul facilitează auditul cu: notificare prealabilă (minim 5-10 zile), acces pe bază de program, prezența personalului furnizorului, restricții pentru protejarea datelor altor clienți.

3. Rapoarte de audit ale furnizorului — furnizorul pune la dispoziție periodic rapoarte de la auditorul extern care certifică conformitatea pe domenii relevante.

4. EUCS (EU Cloud Security Certification Scheme) — schemă europeană de certificare în curs de dezvoltare sub Cybersecurity Act (Reg. 2019/881), cu trei niveluri de asigurare (Basic, Substantial, High).

OUG 155/2024 (NIS2) adaugă obligații suplimentare: Art. 11 alin. 5 prevede audit obligatoriu de securitate cibernetică pentru entitățile esențiale/importante; Art. 25 lit. j) — DNSC eliberează atestate pentru auditorii de securitate cibernetică. Furnizorul cloud care deservește entități sub NIS2 trebuie să coopereze cu auditorii atestați.

Clauze contractuale recomandate: (1) drepturi de audit explicite cu termen de notificare; (2) lista certificărilor acceptate ca alternativă la audit direct; (3) posibilitatea de a desemna auditor terț la costul clientului; (4) escaladare la DNSC în caz de refuz nejustificat; (5) termen de 30 zile pentru remedierea deficiențelor identificate.

Cascada notificărilor de incidente

Când o breșă de securitate apare la un sub-împuternicit din afara SEE, se creează o cascadă de notificări cu termene diferite care se suprapun:

Nivelul 1: Sub-împuternicit → Împuternicit (furnizor cloud) — Art. 28 alin. 3 GDPR obligă sub-procesatorul să notifice procesatorul „fără întârziere nejustificată". GDPR nu fixează un termen exact, dar EDPB (Guidelines 9/2022) recomandă ca DPA-ul dintre procesator și sub-procesator să prevadă un termen contractual fix (ex. 24 ore).

Nivelul 2: Împuternicit → Operator (client) — Art. 33 alin. 2 GDPR: procesatorul notifică operatorul „fără întârziere nejustificată". Din nou, nu există termen fix legal, dar EDPB recomandă termene contractuale (ex. 24-48 ore) și notificare progresivă (informații furnizate în etape pe măsură ce devin disponibile).

Nivelul 3: Operator → ANSPDCP — Art. 33 alin. 1 GDPR: maximum 72 de ore de la momentul în care operatorul „a luat cunoștință" de breșă. Termenul curge de la momentul în care operatorul primește suficiente informații de la procesator pentru a stabili că a avut loc o breșă. Dacă notificarea depășește 72h, operatorul trebuie să motiveze întârzierea.

NIS2 (OUG 155/2024, Art. 15) adaugă un canal paralel: 24 ore alertă inițială către DNSC, 72 ore raport complet, 30 zile raport final. Pentru incidente cu impact transfrontalier — 6 ore.

Problema practică: dacă sub-împuternicitul din afara SEE notifică cu întârziere (ex. 48 ore), iar furnizorul cloud transmite informația clientului după alte 24 ore, operatorul rămâne cu doar câteva ore din termenul de 72h. Art. 33 alin. 4 GDPR permite notificarea în etape, dar operatorul trebuie să demonstreze diligență.

Clauze contractuale recomandate: (1) termen fix de notificare pentru fiecare nivel al cascadei (ex. sub-procesator: 12h, procesator: 24h); (2) punct de contact desemnat 24/7; (3) penalități pentru întârziere; (4) obligația de notificare progresivă (informații parțiale imediat, completări în etape); (5) dreptul operatorului de a se adresa direct sub-procesatorului în caz de urgență.

Clauzele esențiale ale unui SLA (Service Level Agreement)

SLA-ul este nucleul contractului cloud. Defineste nivelul de serviciu promis și consecințele nerespectării acestuia:

1. Disponibilitate (Uptime)

Se exprimă procentual: 99,9% („three nines") = max ~8,76 ore downtime/an; 99,99% = max ~52 minute/an
Exclusiuni: mentenanță planificată, forță majoră, acțiuni ale clientului
Modul de calcul al disponibilității trebuie definit clar (pe lună calendaristică, pe an)

2. Performanță (latency, throughput)

Timpi de răspuns garantați (sub 200ms pentru API, de exemplu)
Capacitate de procesare minimă

3. Remedii pentru nerespectarea SLA (service credits)

Credit SLA — reducere procentuală din factură (tipic 10-30% pentru fiecare nivel de uptime ratat)
Credit SLA-ul este adesea singurul remediu contractual — verificați dacă contractul exclude orice altă formă de despăgubire
Conform dreptului român, o clauză care elimină complet răspunderea pentru culpă gravă sau dol este nulă (Art. 1355 alin. 4 Cod Civil)

4. Suport tehnic

Niveluri de severitate (P1-P4) cu timpi de răspuns și de rezoluție pentru fiecare
Canalele de suport (telefon, email, portal)
Limba de comunicare

5. Backup și recuperare (RTO/RPO)

RTO (Recovery Time Objective) — timpul maxim de restabilire a serviciului
RPO (Recovery Point Objective) — pierderea maximă de date acceptată (ore/minute)

Limitarea răspunderii

Contractele cloud conțin aproape întotdeauna clauze de limitare a răspunderii. Aspecte de verificat:

Plafonarea daunelor — de obicei la valoarea taxelor plătite în ultimele 12 luni
Excluderea daunelor indirecte (pierdere de profit, pierdere de date, daune reputaționale)
Excepții de la limitare — breșe de confidențialitate, încălcări GDPR, dol sau culpă gravă

Art. 1355 alin. 4 Cod Civil — Nu se poate exclude sau limita, prin convenții sau acte unilaterale, răspunderea pentru prejudiciul material cauzat altuia printr-o faptă săvârșită cu intenție sau din culpă gravă. Sursa: Codul Civil, Legea 287/2009

Aceasta înseamnă că, indiferent de termenii contractuali, furnizorul cloud nu se poate exonera de răspundere pentru neglijență gravă sau intenție (dol).

Proprietatea și portabilitatea datelor

Contractul trebuie să clarifice:

Proprietatea datelor rămâne la client — furnizorul are doar dreptul de a le prelucra conform instrucțiunilor
Exportul datelor la încetarea contractului — format standard, termen rezonabil (Data Act impune standarde deschise)
Ștergerea datelor — furnizorul trebuie să șteargă datele după încetarea contractului, cu confirmare scrisă
Lock-in — Data Act interzice taxele de ieșire excesive (de la 2027, zero taxe de ieșire)

Localizarea datelor

România nu impune o obligație generală de localizare a datelor pe teritoriul național. Totuși:

GDPR restricționează transferurile în afara SEE fără garanții adecvate
OUG 89/2022 privind cloudul guvernamental impune ca datele autorităților publice să fie găzduite în infrastructuri de tip cloud conform standardelor naționale de securitate
Regulamentul DORA (UE 2022/2554) impune cerințe suplimentare pentru sectorul financiar privind externalizarea către cloud

Aspecte practice

Lista de verificare pentru un contract cloud

Definiți clar nivelul de serviciu — uptime, performanță, suport, backup
Negociați SLA credits reale — nu acceptați limite simbolice (1-5%)
Verificați clauza de limitare a răspunderii — asigurați-vă că există excepții pentru GDPR, confidențialitate, culpă gravă
Includeți un DPA conform Art. 28 GDPR — cu lista sub-processorilor, drept de audit, notificarea breșelor
Clarificați localizarea datelor — în ce țări/regiuni vor fi stocate datele
Preveniți lock-in-ul — drept de export al datelor în format standard, la încetarea contractului
Stabiliți clauza de exit — termen de tranziție (30-90 zile), asistență la migrare
Verificați conformitatea NIS2 — pentru furnizori care se califică ca entități esențiale/importante
Includeți dreptul de audit — atât pentru securitate, cât și pentru GDPR
Legea aplicabilă și jurisdicția — pentru furnizori internaționali, negociați legea română sau o jurisdicție UE

Greșeli frecvente

Acceptarea SLA „as is" fără negociere — SLA-urile standard ale furnizorilor mari (AWS, Azure, Google Cloud) sunt de tip „take it or leave it", dar pentru contracte enterprise există marjă de negociere
Ignorarea sub-processorilor — furnizorul cloud folosește la rândul lui sub-contractori; fără lista actualizată, riscați încălcarea GDPR
Confuzia între credit SLA și daune — un credit de 10% din factură nu acoperă pierderea reală de business; asigurați-vă că aveți dreptul la daune reale în cazuri grave
Lipsa planului de exit — fără o strategie de ieșire, migrarea poate dura luni și costa semnificativ

Practică și opinii

⚠️ Opinie specialistă — Avocatnet.ro Directiva NIS2, transpusă prin OUG 155/2024, extinde semnificativ obligațiile de securitate cibernetică. Furnizorii de cloud computing sunt explicit incluși în domeniul de aplicare, ca entități esențiale (întreprinderi mari) sau importante (întreprinderi mijlocii), cu obligații de raportare a incidentelor în 24-72 de ore și amenzi de până la 10 milioane EUR. Sursa: Avocatnet.ro — Directiva NIS2 transpusă în România

⚠️ Opinie specialistă — BNT Attorneys Aplicabilitatea OUG 155/2024 se determină pe baza a trei criterii: (1) sectorul de activitate, (2) dimensiunea întreprinderii și (3) impactul potențial al perturbării serviciului. Furnizorii de servicii gestionate (managed service providers) intră, de asemenea, sub incidența OUG, ceea ce extinde obligațiile în tot lanțul de aprovizionare cloud. Sursa: BNT — NIS2 Applicability in Romania

⚠️ Opinie specialistă — Juridice.ro Trecerea de la NIS la NIS2 aduce o schimbare fundamentală: conducerea companiilor este acum direct responsabilă pentru securitatea cibernetică, cu obligații de formare profesională și posibilitatea suspendării din funcțiile executive în caz de neconformitate persistentă. Sursa: Juridice.ro — De la NIS la NIS2

Jurisprudență națională

Litigiile denumite explicit „cloud” rămân rare, dar practica recentă pe servicii software/digitale oferă repere utile pentru SLA, executare și răspundere contractuală.

Decizii favorabile (PRO)

Judecătoria Sectorului 6 București, 12 februarie 2026 — cerere în anulare (OUG 119/2007), contract licențe software Litigiul a pornit din executarea unui contract de furnizare licențe software (contract nr. FR3278/22.06.2021). Creditorul a susținut executarea integrală, iar instanța a admis cererea în anulare. Instanța a reținut că, în litigiile comerciale privind servicii software, rezultatul depinde de proba executării obligațiilor asumate și de documentația contractuală/fiscală prezentată. Sursa: https://www.rejust.ro/juris/659edg6dd

Judecătoria Pătârlagele, 11 februarie 2026 — litigii cu profesioniști, cerere de valoare redusă Într-un raport contractual standardizat de servicii digitale/telecom, instanța a admis în parte pretențiile formulate în procedura cererii de valoare redusă. Instanța a reținut că pretențiile periodice ale furnizorilor se verifică strict pe înscrisuri, cu posibilitatea reducerii/filtrării sumelor solicitate când întinderea debitului nu este dovedită integral. Sursa: https://www.rejust.ro/juris/9d3769652

Decizii contrare sau limitative (CONTRA)

Judecătoria Constanța, 19 ianuarie 2026 — acțiune în răspundere contractuală (pretenții) Reclamanta a solicitat despăgubiri de 177.018 lei într-un litigiu comercial privind transport/manipulare/depozitare și formalități conexe lanțului logistic. Cererea a fost respinsă. Instanța a reținut că, în lipsa probării complete a culpei contractuale și a legăturii directe dintre faptă și prejudiciu, despăgubirile solicitate nu pot fi acordate. Sursa: https://www.rejust.ro/juris/d95369453

Curtea de Apel Oradea, 20 ianuarie 2026 — litigii cu profesioniști, acțiune în daune contractuale (apel + apel incident) Cauza a vizat daune contractuale între profesioniști, cu apel principal al pârâtelor și apel incident al reclamantei împotriva sentinței Tribunalului Satu Mare. Instanța a reținut că întinderea daunelor contractuale și distribuția răspunderii se reanalizează strict în funcție de clauzele contractuale și probatoriul administrat în apel. Sursa: https://www.rejust.ro/juris/d95ge67g7

Tendințe jurisprudențiale

Din practica recentă rezultă câteva direcții stabile:

Litigiile IT/cloud sunt judecate pe instrumente clasice de drept contractual (pretenții, cerere în anulare, daune contractuale), nu pe o „categorie cloud” separată.
Sarcina probei rămâne decisivă: partea care cere plata/despăgubiri trebuie să dovedească executarea, neexecutarea, prejudiciul și legătura cauzală.
Instanțele filtrează strict întinderea sumelor cerute, inclusiv în proceduri simplificate, chiar când există contracte standard.
În apel, controlul asupra cuantumului daunelor este intens, ceea ce arată că formularea clauzelor SLA/limitare răspundere și probatoriul tehnic sunt critice în disputele cloud B2B.

Întrebări frecvente

Ce lege se aplică unui contract cloud cu un furnizor din SUA?

Dacă beneficiarul este o companie sau un consumator din România, se pot aplica normele imperative ale dreptului român (GDPR, OUG 141/2021 pentru consumatori, OUG 155/2024 pentru securitate cibernetică). Chiar dacă contractul prevede legea americană, Art. 6 din Regulamentul Roma I protejează consumatorii, iar GDPR se aplică indiferent de locul prelucrării (Art. 3 alin. 2 GDPR).

SLA-ul este obligatoriu din punct de vedere legal?

Depinde de modul de incorporare. SLA-ul produce efecte juridice depline numai dacă: (1) a fost incorporat expres în contract și acceptat de ambele părți (semnat sau acceptat prin conduită comercială clară); (2) conține indicatori numerici precizați (uptime ≥ 99,9%, RTO ≤ 4 ore, etc.); și (3) definește clar remediile pentru nerespectare (credite SLA, penalități, drept de reziliere).

Dacă anexa SLA lipsește sau nu a fost semnată, contractul-cadru rămâne valabil, dar furnizorul este obligat doar la diligența rezonabilă în executare (obligație de mijloace, nu de rezultat). Prejudiciile se dovedesc a posteriori, fără prezumția automată de neexecutare pe baza unor metrici.

Dacă indicatorii SLA sunt vagi (ex. „disponibilitate rezonabilă", „timp de răspuns acceptabil"), aceștia nu constituie obligații de rezultat precise — furnizorul poate pretinde că a depus eforturi suficiente chiar dacă rezultatul nu este cel așteptat.

Nerespectarea unui SLA cu indicatori clari constituie neexecutare contractuală conform Art. 1350 Cod Civil. Creditele SLA nu exclud automat dreptul la despăgubiri suplimentare, mai ales în cazul culpei grave (Art. 1355 alin. 4).

Cine răspunde dacă furnizorul cloud pierde datele mele?

Furnizorul răspunde contractual pentru pierderea datelor dacă aceasta se datorează neexecutării obligațiilor de backup și securitate asumate. Din perspectiva GDPR, dacă datele pierdute sunt date personale, atât operatorul (clientul), cât și împuternicitul (furnizorul cloud) pot fi sancționați de ANSPDCP. Amenzile GDPR pot ajunge la 20 milioane EUR sau 4% din cifra de afaceri globală.

Ce trebuie să fac la expirarea contractului cloud?

Contractul trebuie să prevadă o perioadă de tranziție (tipic 30-90 zile) în care furnizorul continuă serviciul și asistă la migrarea datelor. Conform Art. 15 alin. 5-6 OUG 141/2021 (B2C), furnizorul trebuie să pună datele la dispoziția consumatorului într-un format utilizat în mod curent, fără costuri, în maximum 15 zile. Data Act (aplicabil din 2025) adaugă obligații suplimentare de portabilitate și interzice taxele de ieșire excesive.

Furnizorii cloud trebuie să respecte NIS2 în România?

Da, dacă sunt întreprinderi medii sau mari cu sediul principal UE în România. OUG 155/2024 include explicit furnizorii de servicii cloud computing (Art. 7 alin. 3). Aceștia trebuie să se înregistreze la DNSC, să implementeze măsuri de securitate proporționale și să raporteze incidentele în 24-72 de ore.