Amendă GDPR de 108.570 lei pentru un magazin online spart: ce a sancționat de fapt ANSPDCP

Pe 31 iulie 2026, Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal a făcut public că a amendat un magazin online cu 108.570 lei, în total. Cazul merită citit cu atenție de orice patron care vinde pe internet, dar nu din motivul la care te-ai aștepta. Firma a fost spartă, da. Numai că temeiul juridic al amenzii nu a fost spargerea. A fost lipsa unui proces documentat de testare periodică a securității, un lucru pe care îl scrii pe o pagină și îl semnezi. Iar firma se autosesizase și notificase incidentul singură, conform legii. A fost amendată oricum.

Ce scrie exact în comunicatul oficial

Redăm formulările din comunicatul autorității, pentru că presa le-a parafrazat în feluri care schimbă sensul. Autoritatea „a finalizat, în luna iunie 2026, o investigație la operatorul HOMELUX S.R.L.” și a constatat încălcarea art. 32 alin. (1) lit. d) și alin. (2) din Regulamentul (UE) 2016/679, precum și încălcarea art. 4 alin. (5) din Legea nr. 506/2004.

Prima observație, care s-a pierdut în preluări: 31 iulie este data comunicatului, nu a sancțiunii. Investigația s-a încheiat în iunie. A doua observație, pentru corectitudine: autoritatea publică doar denumirea firmei, fără cod fiscal, deci nu identificăm aici niciun site anume. Nu are, de altfel, nicio importanță pentru ce urmează.

Despre cauza incidentului, comunicatul spune că

incidentul s-a datorat unui atac cibernetic asupra platformei ce asigura funcționarea site-ului administrat de operator; la momentul producerii incidentului platforma nu corespundea din punct de vedere tehnic cu versiunea oficială lansată de producător.

Merită citit de două ori, pentru că formularea oficială este mai largă decât „platformă neactualizată”, cum a apărut în presă. „Nu corespundea din punct de vedere tehnic cu versiunea oficială” acoperă și un cod modificat manual, și o temă sau un modul cumpărat de pe canale neoficiale, și o variantă derivată care nu se mai poate actualiza. Dacă cineva ți-a „personalizat” platforma în urmă cu trei ani și de atunci nu se mai poate face update, ești fix în situația descrisă.

A doua cauză reținută este „complexitatea redusă a parolelor folosite la momentul creării conturilor pe site-ul deținut de operator, deficiență neremediată după incident”. Acel neremediată după incident este, foarte probabil, cuvântul care a costat cel mai mult în tot dosarul.

Datele afectate au fost, textual, „nume, prenume, adrese, e-mailuri și parole”. Comunicatul nu precizează câte persoane au fost afectate, iar noi nu inventăm o cifră.

Firma s-a autosesizat. Și a fost amendată oricum

Aceasta este partea contraintuitivă. Investigația nu a pornit dintr-o plângere a unui client și nici dintr-un control de rutină, ci „ca urmare a transmiterii de către operator a unei notificări de încălcare a securității datelor cu caracter personal, potrivit dispozițiilor art. 33” din RGPD. Cu alte cuvinte, firma a făcut ce trebuia: a observat incidentul și l-a raportat.

Concluzia corectă nu este „mai bine nu notifici”. Notificarea rămâne obligatorie, iar neîndeplinirea ei este o încălcare separată, sancționabilă în sine. Concluzia corectă este că notificarea nu este un scut. Autoritatea se uită la ce măsuri existau înainte de incident și, mai ales, la ce ai reparat după. Aici, parolele slabe erau încă acolo. Pașii concreți de raportare, cu termene, sunt în ghidul despre raportarea unui incident cibernetic.

Nu a fost amendată pentru că a fost spartă

Art. 32 alin. (1) lit. d) din RGPD cere operatorului „un proces pentru testarea, evaluarea și aprecierea periodice ale eficacității măsurilor tehnice și organizatorice pentru a garanta securitatea prelucrării”. Este o obligație de proces, nu de rezultat. Nu ți se cere să nu fii spart niciodată, ceea ce nimeni nu poate promite. Ți se cere să poți arăta că verifici periodic dacă măsurile tale funcționează.

Diferența e uriașă în practică. Poți fi amendat pe acest temei fără să te fi spart nimeni vreodată, dacă un control constată că nu ai procesul. Și, invers, un proces documentat și respectat este exact ce te ajută când se întâmplă ceva.

Cele trei măsuri corective, traduse

Pe lângă amenzi, autoritatea a dispus măsuri corective. Le-am tradus în lucruri pe care le poți face în câteva ore, păstrând alături formularea oficială.

A treia măsură se referă la cookie-uri: îndeplinirea cumulativă a condițiilor din art. 4 alin. (5) din Legea nr. 506/2004.

A doua amendă nu are legătură cu atacul

Cei 30.000 lei sunt pentru cu totul altceva. Autoritatea a constatat că operatorul „a stocat informații, respectiv module cookies care nu erau necesare din punct de vedere tehnic pentru funcționarea site-ului” și a obținut acces la informația din echipamentul utilizatorilor „fără obținerea acordului acestora”. Această încălcare ar fi existat și dacă nu s-ar fi produs niciun incident de securitate. A fost descoperită pur și simplu cu ocazia investigației.

Testul pe care îl poți face singur, în trei minute: deschide site-ul tău într-o fereastră nouă, intră în instrumentele pentru dezvoltatori ale browserului, la secțiunea Application, și uită-te ce cookie-uri sunt deja puse înainte să apeși pe Accept. Dacă vezi acolo module de analiză a traficului sau pixeli de publicitate, bannerul tău de consimțământ este decorativ. Detaliile despre ce trebuie să scrie în politici sunt în articolul despre politica de confidențialitate.

Cât de mare este amenda, în context

„Amendă uriașă” ar fi o exagerare, iar exagerările strică argumentul. Trei repere, toate din comunicate oficiale ale aceleiași autorități, din aceeași fereastră de timp:

Deci nu este nici pe departe un record. Este însă o sumă serioasă pentru un magazin online mic sau mediu, la care se adaugă costul măsurilor corective, care oricum trebuie implementate, plus timpul pierdut cu procedura. Iar plafonul teoretic e cu totul altul: pentru art. 32 din RGPD, până la 10 milioane de euro sau 2% din cifra de afaceri mondială, iar pentru partea de cookie-uri, art. 13 din Legea nr. 506/2004 prevede între 5.000 și 100.000 lei, cu posibilitatea de a ajunge la 2% din cifra de afaceri pentru societățile care depășesc 5 milioane de lei.

Un al doilea lucru pe care îl arată graficul: art. 32, adică securitatea prelucrării, este în acest moment cel mai activ temei de sancționare în România. Am scris despre tipar și în analiza mai veche a amenzilor GDPR primite de firme sparte.

Planul de o pagină pe care îl scrii azi

Nu îți trebuie consultant pentru varianta minimă. Un document care conține următoarele rânduri acoperă cerința de proces din art. 32 alin. (1) lit. d) și îți dă ceva de arătat:

• Cine răspunde: numele persoanei din firmă care verifică, plus numele furnizorului care execută, dacă e cazul.
• Ce se verifică: versiunea platformei, a temei și a modulelor; existența actualizărilor neaplicate; conturile de administrator active; funcționarea autentificării în doi pași; ce cookie-uri se încarcă înainte de consimțământ; dacă backupul se restaurează.
• La ce interval: lunar pentru actualizări și conturi, trimestrial pentru restul, plus obligatoriu după orice incident.
• Unde se consemnează: un tabel simplu, cu data, cine a verificat, ce a găsit, ce a reparat.
• Semnătura și data. Un plan nesemnat și nedatat nu demonstrează nimic.

Dacă ai deja un registru al prelucrărilor, planul acesta stă lângă el, în același dosar.

Ce ține de tine și ce ține de agenția care îți face site-ul

Răspunderea față de autoritate rămâne la operator, adică la firma ta, iar măsura corectivă acoperă explicit „modificările ulterioare efectuate de operator sau furnizorii de servicii (persoane împuternicite)”. Contractul cu agenția poate stabili cine face actualizările, în cât timp de la apariția unui patch și ce se întâmplă dacă nu le face. Nu mută însă răspunderea legală. Concret, merită să ai scris în contract: cine aplică actualizările, termenul maxim pentru o actualizare de securitate, cine te anunță când apare o vulnerabilitate și cine ține evidența verificărilor. Dacă lucrezi cu agenții web, subiectul e tratat pe larg în pagina dedicată.

Ce nu îți rezolvă un furnizor de securitate, inclusiv noi

Ca să fim corecți până la capăt: un filtru în fața site-ului acoperă o bucată din a doua măsură corectivă, cea de detectare și blocare a tentativelor de atac și de filtrare a datelor introduse de utilizatori. Atât. Nu acoperă planul procedurat, nu ține loc de actualizări ale platformei, nu îți face politica de parole, nu îți rezolvă bannerul de cookie-uri și nu garantează conformitatea GDPR. Nimeni nu poate vinde onest așa ceva. Ce putem face este să reducem suprafața de atac și să îți spunem, în scris, ce am găsit și ce am blocat, ceea ce devine chiar una dintre dovezile tale de verificare periodică.

Surse

• Comunicatul integral, sursă primară: dataprotection.ro, 31 iulie 2026.
• Reperele comparative, tot comunicate oficiale ANSPDCP: 26 iunie 2026 și 17 iulie 2026.
• Textul art. 32 din Regulamentul (UE) 2016/679 și art. 4 alin. (5) și art. 13 din Legea nr. 506/2004.

Concluzie

Cazul acesta nu este despre o firmă care a avut ghinion. Este despre distanța dintre „am fost spart” și „nu puteam demonstra că verific”. Prima situație i se poate întâmpla oricui. A doua este cea care se sancționează, și se repară cu o pagină scrisă, o politică de parole și autentificare în doi pași pe conturile importante. Verifică azi două lucruri, îți ia cinci minute: ce versiune rulează platforma site-ului tău și dacă formularul de înregistrare acceptă parola 123456. Sunt exact cele două puncte reținute de autoritate în acest dosar.

Acest articol explică ce a sancționat autoritatea și ce măsuri a impus. Nu este consultanță juridică și nu stabilește dacă un anumit site este sau nu conform.