Politica de confidențialitate: inventarul de prelucrări

Un pull request adaugă un widget de programări pe pagina de contact. Trece de review, intră în main, ajunge în producție joi seara. Din acel moment site-ul trimite adresa IP a fiecărui vizitator care deschide pagina către un furnizor nou, dintr-o jurisdicție nouă, pentru un scop absent din politica de confidențialitate.

Politica, între timp, a rămas exact cum a fost scrisă la lansare: o mie de cuvinte generate dintr-un șablon, care descriu un site care nu mai există. Nu e o problemă de redactare juridică. E o problemă de inventar: nimeni nu ține lista prelucrărilor reale, deci nimeni nu observă când lista se schimbă.

Textul de mai jos tratează politica de confidențialitate ca pe ceea ce este de fapt — documentația unui sistem. Construiești inventarul din cod, îl mapezi pe cele cinci coloane cerute de regulament, îl declari onest și îl ții sincronizat cu deploy-urile printr-un pas de CI.

Ce cere articolul 13 de la politica de confidențialitate

Regulamentul (UE) 2016/679 nu descrie o pagină. Descrie un set de informații care trebuie să ajungă la persoana vizată în momentul colectării. Articolul 13 se aplică atunci când datele vin direct de la ea; articolul 14, când le obții din altă parte.

Lista minimă de conținut și calibrarea sancțiunilor din România — inclusiv cifrele din comunicatul ANSPDCP din 25 mai 2026, cu 5.186 de plângeri și 228 de investigații deschise în primele patru luni ale anului, plus dosarul HOMELUX — sunt tratate la punctul 3 din checklist-ul legal al unui site de firmă. Nu le relua aici.

Ce contează pentru articolul de față e o singură observație din acea listă: fiecare element se raportează la o prelucrare, nu la site în ansamblu. Scopurile și temeiurile se declară pe prelucrare, destinatarii se declară pe prelucrare, duratele se declară pe prelucrare. O politică scrisă la nivel de site nu poate îndeplini o cerință formulată la nivel de prelucrare, indiferent câte pagini are.

Un temei per scop, nu un temei pe pagină

Formularea care pică cel mai des sună aproximativ așa: „prelucrăm datele dumneavoastră în scopuri comerciale, în temeiul interesului legitim și al consimțământului”. Are trei defecte simultane.

Primul: nu spune care date. Al doilea: enumeră două temeiuri fără să le lege de ceva — iar dacă temeiul e interesul legitim, interesul trebuie numit, nu invocat. Al treilea, cel mai costisitor practic: face imposibilă exercitarea drepturilor. Cineva care vrea să se opună prelucrării bazate pe interes legitim nu poate ști la ce se opune, iar tu nu poți răspunde punctual la o cerere pe care textul tău a făcut-o imprecisă.

Consimțământul nu e nici el opțiunea sigură. E cel mai fragil temei dintre toate, fiindcă se poate retrage și trebuie dovedit. Dacă o prelucrare stă în picioare pe executarea contractului, mutarea ei pe consimțământ îți slăbește poziția, nu ți-o întărește.

Ce adaugă articolul 14

Când datele nu vin de la persoana vizată, apar două elemente în plus — categoriile de date obținute și sursa lor — plus un termen: informarea se face în cel mult o lună, sau la prima comunicare, dacă aceasta vine mai devreme.

Exemplul care lipsește din aproape toate politicile: adresele de contact ale persoanelor din firmele-client, introduse în CRM de un coleg din vânzări, nu de persoana însăși.

Inventarul: extragi lista din cod, nu din memorie

Nu poți scrie corect un document despre un sistem pe care nu l-ai inventariat. Ordinea corectă pornește din capătul celălalt față de cum se procedează de obicei: întâi lista prelucrărilor, apoi textul.

Cele opt suprafețe pe care le găsești în orice aplicație web

Merg în ordinea în care apar în repo, nu în ordinea importanței legale:

• Formularele — contact, ofertă, newsletter, aplicare la un job. Fiecare e o prelucrare separată, cu scop separat. Singur formularul de contact are opt etape și cinci destinatari, desfăcute în articolul dedicat.
• Autentificarea și conturile — inclusiv login social, care aduce un destinatar în plus.
• Plățile — procesatorul vede identitatea cumpărătorului, nu doar cardul.
• E-mailul tranzacțional — confirmări, resetări de parolă, notificări. Trece prin furnizorul de trimitere, care stochează conținutul și adresa.
• Chat-ul și suportul — istoricul conversațiilor e o prelucrare cu durată proprie, adesea nedeclarată.
• Embed-urile — hărți, video, fonturi externe, widget-uri de programare. Fiecare expune IP-ul vizitatorului unui terț.
• Hosting-ul, CDN-ul și baza de date — furnizori care prelucrează tot ce trece prin aplicație.
• Log-urile și monitorizarea — IP, user agent, uneori identificatori de sesiune, păstrate în alt sistem, cu altă retenție.

Grep-ul de pornire

Un scan peste repo îți dă în câteva minute lista de origini externe pe care aplicația le atinge:

1# Origini externe referite în sursă
2grep -rEoh "https?://[a-zA-Z0-9._-]+" 
3  --include="*.ts" --include="*.tsx" --include="*.js" 
4  . | sort -u
5
6# Variabile de mediu care trădează un furnizor
7grep -rEh "^[A-Z0-9_]+=" .env.example | cut -d= -f1 | sort -u

1# Origini externe referite în sursă
2grep -rEoh "https?://[a-zA-Z0-9._-]+" 
3  --include="*.ts" --include="*.tsx" --include="*.js" 
4  . | sort -u
5
6# Variabile de mediu care trădează un furnizor
7grep -rEh "^[A-Z0-9_]+=" .env.example | cut -d= -f1 | sort -u

Comanda pe variabilele de mediu e cea productivă. Numele cheilor din .env.example sunt o hartă a furnizorilor mai onestă decât orice diagramă de arhitectură — fiecare cheie de API înseamnă un serviciu care primește ceva.

Ce nu prinde grep-ul

Trei categorii scapă sistematic, iar ele produc cele mai multe divergențe: Terții injectați dintr-un tag manager. Configurația nu e în repo. O găsești doar deschizând containerul sau inspectând ce se încarcă în pagină.

Embed-urile puse din CMS. Cineva a lipit un iframe într-un articol de blog acum opt luni. Codul aplicației e curat; pagina nu e.

Job-urile de fundal. Un cron care exportă contacte într-un instrument de marketing prelucrează date personale fără să atingă vreo pagină. Îl găsești în definițiile de task-uri, nu în componente.

Tabelul canonic: scop × categorii × temei × durată × destinatari

Cinci coloane. Un rând per prelucrare. Formatul ăsta nu e o preferință stilistică — e structura care face verificabilă informarea, fiindcă fiecare celulă goală devine vizibilă.

Ultimul rând merită o precizare: cookie-urile intră în inventar ca o linie, nu ca un capitol. Arhitectura de consimțământ, categoriile pe scop și dovada acordului sunt tratate integral în articolul despre consimțământ pentru cookies. Aici te interesează doar ce apare în tabel: ce se colectează, pe ce temei, cât timp, cine primește.

Durata: criteriu, nu formulă de politețe

„Cât timp este necesar” nu e o durată și nu e nici un criteriu. Regulamentul acceptă alternativa — perioada exactă sau criteriile după care se determină — dar criteriul trebuie să fie verificabil de altcineva.

Comparație directă: „păstrăm datele cât timp este necesar” nu spune nimic. „Păstrăm mesajele din formular 24 de luni de la ultimul schimb, după care se șterg automat” e o durată. „Păstrăm datele contractuale pe durata contractului plus termenul de prescripție extinctivă” e un criteriu, pentru că oricine poate calcula rezultatul.

Pentru datele financiare, termenul nu ți-l alegi tu: obligațiile contabile și fiscale îl fixează, iar el se aplică indiferent ce ai scris în politică — detaliile pe partea de facturare și e-Factura sunt în ghidul de conformitate fiscală pentru SaaS.

Diferența dintre categorii de date și câmpuri

Nu enumera fiecare coloană din baza de date. Categoriile sunt pentru cititor, nu pentru auditor: „date de identificare”, „date de contact”, „date tehnice de conexiune”. Dar trebuie să acopere realitatea — dacă formularul cere și numele firmei, iar politica declară doar „nume și e-mail”, categoria e greșită, nu doar scurtă.

Subprocesatorii: trei lucruri de declarat pentru fiecare

Regulamentul îți permite să declari destinatarii pe categorii, nu neapărat pe nume. Majoritatea politicilor de firmă din România nu declară nici măcar categoriile, ceea ce lasă un element din articolul 13 pur și simplu necompletat.

Numirea explicită e totuși alegerea mai bună, din motive practice: îți documentezi propriul inventar în același timp în care informezi utilizatorul, iar orice modificare a listei devine un eveniment vizibil, nu o schimbare tăcută de infrastructură.

Pentru fiecare furnizor din stack, notează trei lucruri. Sunt singurele care contează pentru textul politicii.

Entitatea cu care contractezi. Nu brandul, ci persoana juridică. La Stripe, de exemplu, contul din afara Americilor contractează cu Stripe Payments Europe, Limited, iar acordul de prelucrare o spune explicit. Diferența contează, fiindcă entitatea determină cine e exportatorul și cine importatorul într-un transfer.

Regiunea în care stau datele. E aproape întotdeauna o alegere pe care ai făcut-o tu la provisioning și pe care ai uitat-o. MongoDB precizează în documentația de confidențialitate că datele urcate în Atlas sunt stocate fizic de furnizorul de cloud ales de client, în regiunea aleasă de client — deci regiunea e a ta, nu a lor, și numai tu o poți declara.

Mecanismul de transfer pe care îl invocă furnizorul. Vercel scrie în documentația proprie de conformitate că se sprijină pe clauzele contractuale standard și pe addendumul pentru Regatul Unit atunci când transferă date în afara Spațiului Economic European. Stripe declară că e certificat sub cadrul UE–SUA, dar incorporează și clauzele standard, tocmai pentru ca transferurile să continue dacă acel cadru cade. Formulări diferite, mecanisme diferite, deci propoziții diferite în politica ta.

Procesator sau operator independent

Distincția asta se pierde constant, deși schimbă complet ce declari. Un furnizor care prelucrează strict pe instrucțiunile tale e persoană împuternicită. Unul care decide singur scopul unei prelucrări e operator independent pentru acea prelucrare, iar tu îl declari ca destinatar, nu ca împuternicit.

Exemplele sunt în documentele furnizorilor. MongoDB se descrie ca operator pentru datele de cont și facturare ale clientului, și ca împuternicit pentru datele urcate în serviciu. Procesatorii de plăți acționează frecvent ca operatori independenți pentru prevenirea fraudei și pentru obligațiile lor de conformitate — nu prelucrează scorul de risc pentru tine, îl prelucrează pentru ei.

Consecința pentru text: același furnizor poate apărea de două ori în inventar, cu roluri diferite și cu temeiuri diferite.

Accesul pentru suport e tot un transfer

Regiunea aleasă acoperă datele în repaus. Nu acoperă automat accesul echipelor de suport ale furnizorului, care pot fi în altă parte a lumii și care apar, în listele serioase de subprocesatori, ca o linie separată. Dacă politica ta spune că datele „nu părăsesc Uniunea Europeană”, verifică întâi dacă afirmația supraviețuiește unui tichet de suport deschis la trei dimineața.

Transferurile în afara UE: scrie propoziția ca să reziste

Acesta e punctul cel mai volatil din toată politica, și singurul unde formularea contează mai mult decât conținutul.

Situația la data acestui articol: cadrul UE–SUA privind confidențialitatea datelor e în vigoare. Tribunalul Uniunii Europene a respins pe 3 septembrie 2025 acțiunea în anulare introdusă de deputatul francez Philippe Latombe, confirmând decizia de adecvare a Comisiei — dar limitându-și analiza la situația de fapt și de drept existentă la momentul adoptării deciziei, potrivit relatării IAPP. Latombe a atacat hotărârea la Curtea de Justiție pe 31 octombrie 2025, în dosarul C-703/25 P, iar recursul era în continuare pendinte la mijlocul lui 2026, fără termen de ședință anunțat.

Contextul contează pentru cum îți scrii textul: Curtea de Justiție, nu Tribunalul, a invalidat ambele cadre anterioare. Un al treilea rezultat de acel tip ar rupe peste noapte fiecare politică ce numește cadrul drept unic temei al transferurilor.

Formularea care supraviețuiește

Nu construi propoziția în jurul numelui cadrului. Construiește-o în jurul a ceea ce faci.

Transferurile către furnizori din afara Spațiului Economic European se realizează pe baza clauzelor contractuale standard adoptate de Comisia Europeană, completate cu o evaluare a impactului transferului. Acolo unde furnizorul este certificat sub o decizie de adecvare în vigoare, aceasta se aplică prioritar.

Ordinea contează. Mecanismul care rămâne valabil orice s-ar întâmpla e menționat primul; decizia de adecvare e menționată ca strat suplimentar, nu ca fundație. Dacă adecvarea cade, propoziția rămâne adevărată și nu trebuie republicată în aceeași săptămână.

Modelul nu e o invenție editorială. Stripe descrie exact această stivă în întrebările frecvente la acordul de prelucrare: mai multe mecanisme incorporate simultan, cu precizarea că, atunci când se aplică mai multe, cadrul de adecvare are prioritate — și că restul există pentru cazul în care cadrul e invalidat.

Ce înseamnă practic evaluarea impactului

Nu e un document de cincizeci de pagini. Pentru un furnizor obișnuit de infrastructură, e o notă de o pagină cu patru răspunsuri: ce date ajung acolo, ce legislație de acces al autorităților se aplică în țara importatorului, ce măsuri tehnice suplimentare există — criptare cu chei păstrate în Uniune, pseudonimizare, minimizare — și ce ai decis pe baza lor. Se ține în repo, alături de restul documentației, și devine utilă abia când cineva îți cere să justifici o alegere de acum doi ani.

Sincronizarea cu deploy-urile

Un inventar corect construit o dată se degradează în șase luni. Singura variantă care ține e să legi actualizarea de mecanismul care produce schimbarea — pipeline-ul de build.

Un pas de CI care compară build-ul cu lista aprobată

Ideea e simplă: ții într-un fișier versionat lista originilor externe pe care le-ai declarat, iar la fiecare build compari lista efectivă cu ea. Orice diferență oprește pipeline-ul până când cineva decide dacă furnizorul e legitim și, dacă e, actualizează politica.

1// scripts/check-third-parties.mjs
2import { readdirSync, readFileSync, statSync } from "node:fs";
3import { join } from "node:path";
4
5const ALLOWED = JSON.parse(readFileSync("third-parties.json", "utf8"));
6const BUILD_DIR = ".next";
7const ORIGIN = /https?://([a-z0-9.-]+.[a-z]{2,})/gi;
8
9function walk(dir) {
10  return readdirSync(dir).flatMap((entry) => {
11    const path = join(dir, entry);
12    return statSync(path).isDirectory() ? walk(path) : [path];
13  });
14}
15
16const found = new Set();
17for (const file of walk(BUILD_DIR)) {
18  if (!/.(js|mjs|css|html)$/.test(file)) continue;
19  const text = readFileSync(file, "utf8");
20  for (const match of text.matchAll(ORIGIN)) found.add(match[1].toLowerCase());
21}
22
23const unexpected = [...found].filter((host) => !ALLOWED.includes(host));
24if (unexpected.length > 0) {
25  console.error("Origini externe nedeclarate:", unexpected.join(", "));
26  process.exit(1);
27}

1// scripts/check-third-parties.mjs
2import { readdirSync, readFileSync, statSync } from "node:fs";
3import { join } from "node:path";
4
5const ALLOWED = JSON.parse(readFileSync("third-parties.json", "utf8"));
6const BUILD_DIR = ".next";
7const ORIGIN = /https?://([a-z0-9.-]+.[a-z]{2,})/gi;
8
9function walk(dir) {
10  return readdirSync(dir).flatMap((entry) => {
11    const path = join(dir, entry);
12    return statSync(path).isDirectory() ? walk(path) : [path];
13  });
14}
15
16const found = new Set();
17for (const file of walk(BUILD_DIR)) {
18  if (!/.(js|mjs|css|html)$/.test(file)) continue;
19  const text = readFileSync(file, "utf8");
20  for (const match of text.matchAll(ORIGIN)) found.add(match[1].toLowerCase());
21}
22
23const unexpected = [...found].filter((host) => !ALLOWED.includes(host));
24if (unexpected.length > 0) {
25  console.error("Origini externe nedeclarate:", unexpected.join(", "));
26  process.exit(1);
27}

Fișierul third-parties.json devine, în practică, versiunea executabilă a secțiunii de destinatari din politică. Când cineva îl modifică, diff-ul din pull request arată exact ce trebuie schimbat în text — iar dacă nu se schimbă nimic în text, review-ul are un motiv concret să întrebe de ce.

Plasa de la runtime

Verificarea din build nu prinde ce se injectează după livrare: un script adăugat dintr-un tag manager, un embed pus din CMS. Pentru asta există o politică de securitate a conținutului rulată în mod raportare.

1Reporting-Endpoints: csp-endpoint="https://exemplu.ro/api/csp"
2Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint

1Reporting-Endpoints: csp-endpoint="https://exemplu.ro/api/csp"
2Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint

Antetul Content-Security-Policy-Report-Only nu blochează nimic — trimite un raport JSON către endpoint-ul definit, cu tipul de conținut application/reports+json, de fiecare dată când pagina încarcă ceva din afara listei. Directiva report-to e cea curentă; report-uri e marcată ca depreciată în documentația MDN și e ignorată de browserele care o suportă pe prima, deci se declară amândouă doar cât timp ai nevoie de acoperire pe browsere vechi.

Efectul practic: primești o notificare când apare un terț nou, chiar dacă nimeni nu a atins repo-ul.

Versionarea politicii și data ultimei actualizări

Data din antetul politicii nu e ornament. E singurul semnal public că procesul de revizuire există — și, invers, dovada că nu există. O politică datată cu opt luni în urmă, pe un site care a schimbat între timp furnizorul de e-mail, spune unui inspector exact ce vrea să afle, înainte să citească vreun paragraf.

Ține fiecare versiune în repo, cu istoric în Git, și notează în commit ce prelucrare s-a schimbat. Când cineva întreabă ce declara politica în martie, răspunsul e un git show. Iar dacă modificarea atinge o prelucrare bazată pe consimțământ, versiunea afișată în momentul acordului e chiar elementul cu care dovedești ce a acceptat persoana.

Responsabilul cu protecția datelor și registrul: unde se vinde mai mult decât cere legea

Două obligații pe care piața de consultanță le prezintă frecvent ca generale. Niciuna nu e.

Când e obligatoriu un DPO

Articolul 37 alineatul (1) enumeră trei situații, și doar trei. Prelucrarea e făcută de o autoritate sau un organism public. Activitățile principale ale operatorului constau în operațiuni care necesită monitorizarea periodică și sistematică a persoanelor, pe scară largă. Sau activitățile principale constau în prelucrarea pe scară largă a categoriilor speciale de date ori a datelor privind condamnări penale.

Expresia care decide aproape toate cazurile e „activitățile principale”. Un magazin online cu analytics nu are ca activitate principală monitorizarea persoanelor, ci vânzarea. O firmă de software nu intră în ipoteză doar pentru că folosește un CRM. Intră o platformă al cărei produs este urmărirea comportamentală, sau un furnizor de servicii medicale.

Desemnarea voluntară e permisă și e uneori o decizie comercială bună, dar are un preț: din momentul desemnării se aplică integral regimul din articolele 38 și 39 — independență, resurse, imposibilitatea de a primi instrucțiuni privind exercitarea atribuțiilor, raportare la cel mai înalt nivel de conducere. Un DPO desemnat pe hârtie și tratat ca o adresă de e-mail e o poziție mai proastă decât absența lui.

Al doilea detaliu, procedural: articolul 37 alineatul (7) cere publicarea datelor de contact ale responsabilului și comunicarea lor autorității de supraveghere. ANSPDCP are un formular dedicat de declarare. Un site care afișează o secțiune numită „contact DPO” fără să fi desemnat și declarat pe cineva face o afirmație inexactă către utilizatori — și încă una gratuită, pentru că un simplu „punct de contact pentru protecția datelor” e perfect suficient dacă nu ai obligația.

Registrul art. 30: scutirea e mai îngustă decât pare

Textul în vigoare scutește operatorii cu mai puțin de 250 de angajați, dar scutirea cade dacă e îndeplinită oricare dintre trei condiții: prelucrarea e susceptibilă să genereze un risc pentru drepturile și libertățile persoanelor; prelucrarea nu este ocazională; sau prelucrarea vizează categorii speciale de date ori date privind condamnări penale.

A doua condiție e cea care anulează scutirea în practică. O firmă cu opt oameni care are un formular de contact activ, un newsletter și facturare recurentă face prelucrări continue, nu ocazionale. Salarizarea propriilor angajați e, prin definiție, o prelucrare permanentă. Practic, orice firmă care operează un site comercial iese din scutire pe criteriul caracterului ocazional, indiferent câți angajați are.

Situația se poate schimba, dar nu s-a schimbat încă. Comisia Europeană a propus pe 21 mai 2025, în pachetul de simplificare cunoscut ca Omnibus IV, modificarea articolului 30 alineatul (5): scutirea s-ar aplica organizațiilor sub un prag mult mai mare de angajați și numai atunci când prelucrarea e susceptibilă să genereze un risc ridicat, în sensul articolului 35 — dispărând, printre altele, criteriul caracterului ocazional. Comitetul European pentru Protecția Datelor și Autoritatea Europeană pentru Protecția Datelor au emis o opinie comună pe 8 iulie 2025, favorabilă reducerii sarcinii administrative, dar cu cereri de clarificare.

Parcursul e important, pentru că pragul s-a mișcat pe drum. Propunerea Comisiei vorbea despre organizații cu mai puțin de 750 de angajați. În acordul provizoriu anunțat de Parlamentul European pe 9 iunie 2026, categoria a fost definită cu mai puțin de 1.000 de angajați și fie cifră de afaceri de cel mult 200 de milioane de euro, fie active totale de cel mult 172 de milioane. Comunicatul Parlamentului din februarie 2026, pe mandatul de negociere, precizează că relaxarea nu acoperă prelucrarea datelor sensibile — date biometrice, privind originea etnică, opiniile politice, religia, sănătatea sau condamnările penale. Textul urma să treacă prin adoptarea formală a ambelor instituții și prin publicarea în Jurnalul Oficial înainte de a produce efecte.

Ce nu se schimbă, în niciuna dintre variante: registrul e scutirea, nu informarea. Articolele 13 și 14 rămân integral aplicabile oricărei firme, oricât de mici. Iar dacă ai construit inventarul de care are nevoie politica, registrul e același tabel cu două coloane în plus. Scutirea îți economisește un document, nu munca.

Ce arată politica de pe basetech.ro față de codul ei

Un articol care cere un inventar ar trebui să suporte propriul test. Verificarea de mai jos a fost făcută pe 15 august 2026, comparând textul celor două pagini legale publicate cu prelucrările pe care site-ul le declară el însuși.

Metoda: descărcarea paginilor /confidentialitate și /cookies, extragerea afirmațiilor din fiecare și punerea lor față în față. Rezultatul e o divergență între cele două documente ale aceluiași site, nu între politică și cod — ceea ce o face cu atât mai ușor de constatat din exterior.

Politica de cookies, actualizată pe 15 august 2026, declară trei categorii, dintre care una de măsurare a campaniilor publicitare, cu tag Google Ads, cookie-ul _gcl_au și transmiterea evenimentului de conversie către Google LLC. Politica de confidențialitate, datată 27 mai 2026, descrie datele colectate prin cookies drept „preferințe sesiune, analytics anonimizate”, nu menționează măsurarea publicitară și afirmă că datele se stochează pe servere „localizate exclusiv în Uniunea Europeană”, cu transferuri către state terțe tratate ca ipotetice. Cele două propoziții nu pot fi ambele adevărate.

Tot din comparație: secțiunea de destinatari din politica de confidențialitate enumeră categorii — hosting, bază de date, e-mail, plăți, contabilitate — dar nu îl include pe furnizorul de publicitate pe care politica de cookies îl numește explicit. Iar secțiunea 9 e intitulată „Contact DPO” deși descrie un punct general de contact, fără vreo desemnare declarată — exact tiparul semnalat mai sus.

Ce e în regulă și merită spus, ca să nu fie reauditat: identificarea operatorului e completă, cu denumire, CUI, EUID și sediu; drepturile sunt enumerate individual, cu trimitere la ANSPDCP; duratele de retenție sunt exprimate în ani și luni, nu prin formula „cât timp este necesar”; termenul de răspuns e cel din articolul 12 alineatul (3).

La data publicării acestui articol divergențele sunt consemnate, nu reparate — iar asta e ea însăși informația utilă. Politica de cookies s-a actualizat în aceeași zi în care s-a schimbat bannerul, pentru că schimbarea a fost un proiect explicit. Politica de confidențialitate a rămas la 27 mai fiindcă nimic din procesul de livrare nu a legat-o de acea modificare. Corectura are trei elemente: adăugarea liniei de măsurare a campaniilor în tabelul de prelucrări, înlocuirea afirmației despre stocarea exclusiv în Uniune cu formularea pe clauze standard din secțiunea anterioară, și redenumirea secțiunii 9.

Actualizare, 15 august 2026. Cele trei corecturi au fost aplicate în aceeași zi, împreună cu a patra pe care comparația o scosese la iveală: secțiunea de destinatari enumeră acum furnizorii de analiză a traficului și de măsurare a campaniilor, plus serviciul anti-spam al formularelor, iar furnizorul de publicitate e declarat ca operator independent pentru măsurarea conversiilor, nu ca împuternicit. Afirmația despre stocare distinge infrastructura proprie, aflată în Uniune, de serviciile care transmit către Statele Unite pe garanțiile din articolele 44-50. Politica poartă data de 15 august 2026. Diferența dintre cele două pagini nu a fost de redactare, ci de proces: modificarea codului nu era legată de documentul pe care îl invalida.

Întrebări frecvente

Un generator online de politică e suficient ca punct de plecare?

Pentru structură, da. Pentru conținut, nu — și motivul e chiar subiectul articolului. Generatorul nu are acces la lista ta de furnizori, nu știe ce regiune ai ales la provisioning, nu știe câte luni păstrezi log-urile. Completează exact partea care se sancționează, cu presupuneri. Folosește-l ca schelet, apoi înlocuiește fiecare afirmație cu una verificată din inventar.

Trebuie să numesc fiecare furnizor sau pot declara categorii?

Regulamentul acceptă categoriile. Numirea explicită e însă mai ușor de întreținut, pentru că lista devine un artefact versionat pe care CI-ul îl poate verifica. Compromisul rezonabil: categorii în textul principal, plus o listă nominală de subprocesatori într-o pagină separată, cu dată și istoric.

Cât de des trebuie actualizată politica?

Nu la interval fix. La fiecare schimbare de fond: furnizor nou, scop nou, durată modificată, temei schimbat. Un pas de CI care semnalează originile nedeclarate transformă întrebarea „când revizuim” într-un eveniment care apare singur, atunci când chiar s-a schimbat ceva.

Ce fac dacă descopăr o prelucrare nedeclarată de luni de zile?

O declari și îți notezi data în istoric. Obligația de informare e continuă, iar textul actualizat e starea corectă de acum înainte. Verifică separat temeiul: dacă prelucrarea rula pe consimțământ și acordul nu a fost cerut niciodată pentru acel scop, problema nu se rezolvă prin text.

Politica de confidențialitate și politica de cookies trebuie să fie documente separate?

Nu obligatoriu, dar separarea funcționează mai bine: cookie-urile se schimbă mai des decât restul prelucrărilor, iar un document scurt e mai ușor de ținut exact. Condiția e ca cele două să nu se contrazică — auto-auditul de mai sus arată cât de repede se întâmplă asta.

Am nevoie de o pagină separată pentru registrul prelucrărilor?

Nu. Registrul din articolul 30 e un document intern, nepublicat, pe care îl prezinți autorității la cerere. Se construiește din același inventar ca politica, plus câmpuri suplimentare — măsurile tehnice și organizatorice, transferurile documentate în detaliu, datele de contact ale eventualului responsabil.

Notă: textul acoperă construirea documentului, nu ține loc de consultanță juridică. Categoriile speciale de date, evaluările de impact și situațiile de operator asociat cer analiză dedicată.

Punctul de sprijin al întregii construcții e că inventarul precede textul. Când lista prelucrărilor e un artefact versionat, verificat la fiecare build, politica devine ceea ce ar fi trebuit să fie de la început: o proiecție citibilă a sistemului, nu un document paralel cu el.

Celelalte obligații care cad pe același site — identificare, informare SAL, accesibilitate — au fiecare articolul lor în conformitate legală web. Pentru partea de produs, de la arhitectură la facturare, punctul de intrare rămâne hub-ul SaaS.