Formular de contact GDPR: câmpuri, antibot, retenție

Cineva completează formularul de contact și apasă butonul. În următoarele câteva sute de milisecunde mesajul trece prin patru sisteme diferite: procesul care validează datele, serviciul care decide dacă expeditorul e om, baza de date care păstrează rândul și furnizorul care duce notificarea într-o cutie poștală. Trei dintre ele aparțin altcuiva.

Formularul e cel mai mic artefact din site și cel mai des tratat ca detaliu de interfață. În realitate e un mic sistem complet, cu o obligație legală atașată fiecărei etape: un temei pentru colectare, o justificare pentru fiecare câmp, o declarație pentru antibot, un contract cu furnizorul de e-mail, o durată de păstrare și un mecanism care chiar șterge la capătul ei.

Textul de mai jos parcurge traseul în ordinea în care îl parcurge mesajul și pune, la fiecare oprire, întrebarea care se poate verifica din exterior: ce pleacă de aici, cine primește și pe ce temei.

Formularul ca sistem, nu ca widget

Un formular de contact are, în forma lui obișnuită, opt etape. Fiecare produce fie o prelucrare nouă, fie un destinatar nou, fie amândouă.

Cele opt opriri ale mesajului

Cererea pleacă din browser. Validarea de pe server decide ce intră și ce se respinge. Antispamul evaluează expeditorul, uneori cu ajutorul unui terț. Persistența scrie rândul în bază. E-mailul tranzacțional duce notificarea la o adresă reală. Uneori urmează un CRM. Apoi vine intervalul de păstrare. La final ar trebui să vină ștergerea.

Cinci dintre cele opt implică pe altcineva decât tine: furnizorul de antibot, cel de hosting, cel de bază de date, cel de e-mail, eventual CRM-ul. Fiecare intră în inventarul de prelucrări ca destinatar, cu rolul lui declarat. În tabelul de cinci coloane pe care îl cere inventarul de prelucrări, formularul ocupă un singur rând. Aici se desface rândul acela în etapele lui.

Ce se decide o singură dată, în schema

Trei lucruri sunt scumpe de schimbat după lansare, pentru că afectează date deja colectate: setul de câmpuri, temeiul și durata de păstrare. Restul — furnizorul de antibot, formularea de sub buton, destinația notificării — se pot înlocui într-un sprint.

De asta ordinea corectă e inversă față de cum se lucrează de obicei. Întâi decizi ce ai voie și ce ai nevoie să colectezi, apoi desenezi ecranul.

Temeiul: cine cere ce și de ce contează diferența

Aici se produce prima confuzie, iar ea nu e academică: temeiul ales determină ce drepturi are persoana, ce trebuie să dovedești și ce se întâmplă când cineva se răzgândește.

Consimțământul e alegerea slabă pentru un mesaj primit

Bifa „sunt de acord cu prelucrarea datelor mele” apare pe majoritatea formularelor din România. Are un defect structural: consimțământul se poate retrage oricând, iar retragerea produce efecte imediate. Dacă temeiul pe care citești și răspunzi la un mesaj e consimțământul, o retragere în timpul pregătirii ofertei îți taie chiar prelucrarea pe care persoana ți-a cerut-o.

Mai are un cost: sarcina probei. Articolul 7 alineatul (1) din Regulamentul (UE) 2016/679 cere operatorului să poată demonstra că persoana a consimțit. Un câmp boolean consent: true în baza de date nu demonstrează nimic despre ce text a fost afișat în ziua respectivă.

Măsuri precontractuale sau interes legitim

Pentru o cerere de ofertă, două temeiuri se potrivesc mai bine, iar alegerea dintre ele ține de cine e persoana din formular.

Când cel care scrie e chiar viitorul client — un profesionist independent, o persoană fizică autorizată — se aplică articolul 6 alineatul (1) litera b): prelucrarea e necesară pentru a face demersuri la cererea persoanei vizate înainte de încheierea contractului. Nu ai nevoie de acordul nimănui ca să răspunzi la o cerere pe care ai primit-o.

Când cel care scrie e angajatul unei firme, contractul se va încheia cu firma, nu cu el. Atunci temeiul e interesul legitim, articolul 6 alineatul (1) litera f), iar interesul trebuie numit în politică: gestionarea cererilor comerciale primite prin site. Un interes invocat fără să fie numit nu îndeplinește cerința de informare.

Ambele variante lasă intact dreptul de opoziție din articolul 21, ceea ce înseamnă că tot ai nevoie de o cale prin care mesajul se șterge la cerere. Diferența față de consimțământ e că opoziția se evaluează, nu se execută automat.

Newsletterul e alt scop, deci altă bifă

Aici temeiul chiar este consimțământul, și e separat de trimiterea mesajului. Bifa trebuie să fie distinctă, niciodată prebifată, și niciodată condiție pentru trimiterea formularului.

Regula de fond vine din articolul 12 din Legea nr. 506/2004: comunicările comerciale prin poștă electronică sunt interzise, cu excepția cazului în care destinatarul și-a exprimat în prealabil consimțământul expres. Alineatul (2) prevede o excepție îngustă, adesea invocată greșit — adresa obținută direct de la un client cu ocazia vânzării unui produs sau serviciu poate fi folosită pentru produse ori servicii similare, cu condiția ca posibilitatea de opoziție să fie oferită clar și gratuit atât la colectare, cât și în fiecare mesaj. Un formular de contact nu e o vânzare, deci excepția nu îl acoperă. Alineatul (3) adaugă două interdicții permanente: identitatea reală a expeditorului nu poate fi ascunsă și trebuie să existe o adresă validă pentru cererea de încetare.

Autoritatea competentă e aceeași pentru ambele texte: ANSPDCP aplică și regulamentul, și legea din 2004.

Minimizarea se decide în schema, nu în layout

Fiecare câmp obligatoriu adaugă o categorie de date pe care trebuie să o declari, să o păstrezi și să o ștergi. Regula practică e brutal de simplă: câmpul e obligatoriu doar dacă absența valorii face răspunsul imposibil.

Testul justificării scrise

Pentru fiecare câmp marcat obligatoriu, scrie o propoziție care explică de ce fără el nu poți răspunde. Dacă propoziția sună a preferință comercială — „ne ajută la calificare”, „vrem să știm de unde vin lead-urile” — câmpul e opțional, nu obligatoriu.

Cazul clasic e telefonul obligatoriu pe un formular care spune „scrie-ne un mesaj”. Dacă mesajul primește răspuns pe e-mail, numărul nu e necesar pentru scopul declarat. Poate rămâne în formular, marcat opțional, cu o justificare vizibilă lângă el.

Al doilea caz, mai subtil: câmpurile care există doar ca să populeze un raport intern. Ele nu sunt interzise, dar mută prelucrarea într-un scop secundar, care are nevoie de propriul temei și de propriul rând în inventar.

Validarea pe server și ce nu ajunge în log-uri

Validarea din browser e pentru confort. Cea care contează juridic rulează pe server, pentru că articolul 32 cere măsuri tehnice adecvate, iar el e articolul pe care se sprijină cele mai multe sancțiuni din România.

1import { z } from "zod";
2
3export const contactSchema = z.object({
4  name: z.string().min(2).max(120),
5  email: z.string().email().max(254),
6  message: z.string().min(20).max(4000),
7  company: z.string().max(160).optional(),
8  phone: z.string().max(32).optional(),
9  // câmp-capcană: completat înseamnă bot, se aruncă tăcut
10  website: z.string().max(0).optional(),
11  noticeVersion: z.literal("2026-08-17"),
12  newsletter: z.boolean().default(false),
13});

1import { z } from "zod";
2
3export const contactSchema = z.object({
4  name: z.string().min(2).max(120),
5  email: z.string().email().max(254),
6  message: z.string().min(20).max(4000),
7  company: z.string().max(160).optional(),
8  phone: z.string().max(32).optional(),
9  // câmp-capcană: completat înseamnă bot, se aruncă tăcut
10  website: z.string().max(0).optional(),
11  noticeVersion: z.literal("2026-08-17"),
12  newsletter: z.boolean().default(false),
13});

Două detalii din schema de mai sus fac diferența la audit. noticeVersion leagă rândul de versiunea exactă a textului afișat sub buton. newsletter are implicit false, ceea ce face imposibilă o bifă prebifată din greșeală într-un refactor de interfață.

Pe partea de log-uri, regula e să nu scrii conținutul mesajului în jurnalele aplicației. Log-urile au propria durată, de obicei mai lungă decât ai vrea pentru un text liber în care oamenii scriu, previzibil, mai mult decât ai cerut.

Antibotul e o prelucrare pe care trebuie să o declari

Un antibot care trimite ceva unui terț nu e o măsură de securitate invizibilă. E o prelucrare cu destinatar, cu temei și, de regulă, cu transfer în afara Uniunii. Alegerea dintre variante se face după cine primește datele, nu doar după cât de bine prinde boți.

Ce declară Google despre reCAPTCHA

Documentația proprie e punctul de plecare, nu articolele terților. Google scrie că reCAPTCHA setează un cookie pe care îl numește necesar, _GRECAPTCHA, în scopul analizei de risc, și că badge-ul poate fi ascuns dacă pagina afișează în schimb mențiunea că e protejată de reCAPTCHA.

Schimbarea de fond e din 2026. Începând cu 2 aprilie 2026, clienții reCAPTCHA sunt singurii operatori ai datelor, iar Google le prelucrează exclusiv conform Termenilor Google Cloud și Cloud Data Processing Addendum. Tot de la acea dată, referințele la politica de confidențialitate și la termenii de utilizare ai Google au fost scoase din badge, iar Google recomandă clienților să le elimine și de pe propriile site-uri. Cookie-ul rămâne neschimbat.

Pentru textul politicii tale, mutarea are o consecință directă: rolul pe care îl declarai — „Google, operator independent” — nu mai e corect după acea dată, iar responsabilitatea de a explica scopul prelucrării trece integral la tine.

Există și o ambiguitate care merită spusă ca atare. La întrebarea despre datele de sesiune colectate, documentația nu enumeră câmpuri, ci trimite la addendum și la termenii specifici serviciului. Dacă furnizorul nu publică lista, politica ta nu o poate publica nici ea; scrii categoria și indici sursa, în loc să inventezi o enumerare.

Ce declară Cloudflare despre Turnstile

Addendumul de confidențialitate al Turnstile, actualizat în iunie 2025, e mai explicit pe conținut. Turnstile prelucrează semnale din browser precum adresa IP a clientului, amprenta TLS, antetul User-Agent și cheia de site împreună cu originea asociată, iar Cloudflare afirmă că nu poate identifica direct persoane pornind de la aceste semnale, inclusiv de la adresele IP.

Partea pe care o ratează majoritatea politicilor e rolul dublu. Cloudflare se declară persoană împuternicită pentru semnalele prelucrate ca să protejeze site-urile clienților — acolo clientul e operatorul și stabilește temeiul — și operator pentru semnalele prelucrate ca să își îmbunătățească algoritmii de detecție, invocând propriul interes legitim.

Consecința pentru inventarul tău: același furnizor apare de două ori, cu roluri diferite, exact ca în cazul unui furnizor de publicitate care măsoară conversii pe cont propriu.

A doua observație ține de cookie-uri. Secțiunea dedicată din addendum afirmă că semnalele sunt strict necesare pentru detecția boților și trimite pentru detalii la politica de cookies și la documentația pentru dezvoltatori, fără să numească un cookie anume. Dacă politica ta afirmă existența unui cookie strict necesar pus de Turnstile, spui mai mult decât spune furnizorul — verifică-l în browser înainte să lași fraza acolo.

Câmpul-capcană și limitarea ratei

Varianta fără terți rezolvă o parte din problemă și trebuie evaluată onest, nu prezentată ca soluție universală.

Un câmp ascuns pe care oamenii nu îl completează, un prag minim de timp între randarea paginii și trimitere și o limitare a numărului de cereri per adresă IP acoperă boții simpli, care sunt majoritatea traficului de spam pe un formular de firmă. Nimic nu pleacă spre un terț, deci nu apare nici destinatar nou, nici transfer.

Ce nu îți cumpără: nu oprește atacurile țintite și nu scalează pe un formular cu volum mare. Iar limitarea ratei prelucrează ea însăși o adresă IP, care rămâne dată cu caracter personal — intră în inventar la categoria log-uri tehnice, pe interes legitim.

Ce spune și ce nu spune jurisprudența

Întrebarea dacă un antibot are nevoie de consimțământ înainte de încărcare nu are, la data acestui articol, un răspuns tranșat la nivel european.

Reperul cel mai citat rămâne o hotărâre a instanței administrative federale din Austria, în dosarul W298 2274626-1, publicată la sfârșitul lui 2024: potrivit relatărilor de presă juridică, instanța a reținut că, deși un mecanism de verificare a boților e util, cookie-urile pe care le pune nu sunt tehnic necesare, iar utilizarea fără consimțământ prealabil nu e permisă.

Ce nu am găsit, căutând acum: o decizie formală a unei autorități europene de supraveghere pe acest subiect după mijlocul lui 2025. Absența e ea însăși informația utilă. Înseamnă că nu poți sprijini alegerea pe o autoritate care a decis deja, ci pe un test de echilibrare documentat, pe minimizare reală și pe un furnizor ale cărui declarații le poți cita. Dacă alegi să încarci antibotul înainte de orice acord, scrie de ce, cu argumentul de necesitate, și păstrează documentul.

Nu confunda dovada de aici cu cea din banner. Bannerul ține evidența categoriilor acceptate, cu propria arhitectură de consimțământ pentru cookies; formularul ține evidența textului afișat sub buton la momentul trimiterii. Un acord dat în banner nu spune nimic despre ce a citit persoana înainte să apese, iar invers e la fel de adevărat.

Destinatarii reali: e-mail tranzacțional, notificări, CRM

Rândul din baza de date e doar prima copie a mesajului. Restul copiilor sunt cele care surprind la un audit.

Furnizorul de e-mail vede tot conținutul

Serviciul care duce notificarea primește adresa destinatarului și textul integral al mesajului. Nu e un curier care transportă un plic sigilat — stochează, indexează și afișează.

Documentația Resend, ca exemplu concret pe care îl poți deschide, e explicită pe durată: datele de e-mail se păstrează 30 de zile pe toate planurile, cu retenție flexibilă pentru Enterprise. Acordul de prelucrare al aceleiași companii definește separat datele de utilizare a serviciului — cele care identifică sursa și destinația unei comunicări, plus jurnalele de activitate — și precizează că, acolo unde le prelucrează în calitate de operator, se aplică propria politică de confidențialitate. Din nou două roluri pentru același furnizor, la fel ca în cazul antibotului.

Concluzia practică: promisiunea ta de retenție nu e doar a ta. O copie a mesajului trăiește pe ceasul furnizorului, iar politica trebuie să spună asta fără să exagereze în nicio direcție.

Notificarea în chat e un destinatar în plus

Webhook-ul care aruncă mesajul într-un canal de Slack sau Teams pare o comoditate internă. Este, de fapt, o a treia copie, într-un sistem cu propria retenție, propriul furnizor și propriul contract de prelucrare — și, de obicei, cu mai mulți oameni care au acces decât are baza de date.

Dacă notificarea conține doar un identificator și un link către panoul intern, copia dispare din ecuație. Diferența costă zece minute de implementare.

Când mesajul intră în CRM, scopul se schimbă

Trecerea unui contact din formular în CRM, urmată de includerea lui într-o secvență de e-mailuri, nu mai e gestionarea unei cereri primite. E marketing direct, cu temei propriu și cu regula din legea din 2004 de mai sus.

Iar dacă adresa e introdusă în CRM de un coleg, nu de persoana însăși, se aplică articolul 14: informarea trebuie făcută în cel mult o lună sau la prima comunicare, oricare vine mai devreme.

Retenția: un formular fără job de ștergere păstrează pe viață

O bază de date nu uită singură. În lipsa unui mecanism, mesajele din 2019 sunt încă acolo, cu nume, adrese și, uneori, cu detalii pe care oamenii le scriu în câmpuri libere fără să le ceară nimeni.

Criteriul trebuie să fie calculabil de altcineva

Regulamentul acceptă fie o perioadă exactă, fie criteriile după care se stabilește. Testul pe care îl aplici formulării tale e dacă un terț, cu aceleași date în față, ajunge la aceeași dată de ștergere.

„Cât timp este necesar” nu trece testul. „Trei ani de la ultima interacțiune relevantă” nu trece nici el, pentru că relevanța nu e definită nicăieri. „Douăzeci și patru de luni de la ultimul mesaj din fir” trece, pentru că evenimentul de pornire e un rând cu marcaj de timp.

Ștergerea ca linie de cod

Un job programat care rulează zilnic e tot ce cere partea asta. Ce lipsește mai des nu e jobul, ci decizia despre ce nu se șterge.

1// rulează zilnic; păstrează mesajele devenite documente contractuale
2const cutoff = new Date(Date.now() - 24 * 30 * 24 * 3600 * 1000);
3
4await db.collection("contactMessages").deleteMany({
5  lastMessageAt: { $lt: cutoff },
6  becameContract: { $ne: true },
7});

1// rulează zilnic; păstrează mesajele devenite documente contractuale
2const cutoff = new Date(Date.now() - 24 * 30 * 24 * 3600 * 1000);
3
4await db.collection("contactMessages").deleteMany({
5  lastMessageAt: { $lt: cutoff },
6  becameContract: { $ne: true },
7});

Trei straturi se sting în momente diferite, iar textul politicii ar trebui să le numească pe toate: rândul din baza activă la termenul declarat, copiile de la furnizori pe ceasul lor, copiile de siguranță la rotația lor. Un text care sugerează dispariția completă în ziua cererii e inexact chiar dacă jobul rulează perfect.

Mesajele care au devenit parte dintr-un contract ies din regimul ăsta și intră în cel contractual sau fiscal, cu durate pe care nu ți le alegi tu. Ele nu se șterg la cerere, iar excepțiile din articolul 17 alineatul (3) acoperă situația.

Informarea la punctul de colectare

Articolul 13 cere ca informațiile să ajungă la persoană în momentul în care îi iei datele. Un link în subsolul paginii nu îndeplinește cerința, pentru că nu e prezentat acolo unde are loc colectarea.

Textul de sub buton, versionat

Formularea utilă are patru elemente și încape în două rânduri: cine e operatorul, în ce scop folosești datele, cât le păstrezi și unde citește restul. Un exemplu care trece testul: „Datele din formular ajung la [denumirea firmei] și sunt folosite exclusiv pentru a răspunde cererii tale. Le păstrăm 24 de luni de la ultimul mesaj din fir. Detalii complete în [politica de confidențialitate].” Versionarea nu e ceremonial. Când cineva întreabă peste doi ani ce i s-a spus la momentul trimiterii, răspunsul vine din identificatorul stocat pe rând, nu din pagina de azi.

Ce înregistrezi la trimitere

Patru valori, salvate pe același rând cu mesajul: identificatorul versiunii de text afișate, marcajul de timp, temeiul pe care l-ai aplicat și, separat, dacă bifa de newsletter a fost marcată. Separat, pentru că retragerea acordului de marketing nu trebuie să atingă mesajul primit.

Accesibilitatea formularului e cerință, nu bună practică

Din tot ce cere Legea nr. 232/2022 în interfață, patru criterii cad direct pe un formular și se verifică în câteva minute.

Eticheta trebuie asociată programatic cu câmpul, prin for și id — un placeholder nu e etichetă și dispare la scriere. Erorile trebuie identificate în text, nu doar printr-un chenar roșu, și trebuie să spună ce e greșit, nu doar că ceva e greșit. Indicatorul de focus trebuie să rămână vizibil, ceea ce în practică înseamnă să nu îl ștergi cu outline: none într-un reset de CSS. Grupurile de opțiuni — intervale de buget, tipuri de proiect — cer fieldset și legend, altfel eticheta grupului nu ajunge la tehnologiile asistive.

Restul criteriilor, calendarul de aplicare și felul în care se scrie declarația de accesibilitate sunt în articolul dedicat despre accesibilitate sub Legea 232/2022.

Ce cere formularul de pe basetech.ro și ce declară politica

Metoda descrisă mai sus s-a aplicat pe 17 august 2026 pe propriul formular al site-ului: câmpurile din pagină, textul de sub buton și antibotul din pagină, puse față în față cu ce declară politica de confidențialitate.

Pagina /contact cere nume complet, rol în companie, e-mail profesional, adresa site-ului firmei, un interval de buget dintr-o listă și descrierea proiectului. Pentru o pre-calificare B2B fiecare câmp are o justificare plauzibilă, iar telefonul lipsește cu totul — exact tiparul recomandat mai sus. Ce nu se poate stabili din pagina servită e care câmpuri sunt obligatorii și care opționale; marcajul explicit ar rezolva și cerința de minimizare, și pe cea de accesibilitate.

Textul de informare nu trimite la politică. Sub buton scrie că trimiterea formularului înseamnă acordul de a fi contactat pe e-mail pentru evaluarea tehnică și că nu se trimite newsletter. A doua parte e chiar separarea scopurilor cerută de lege, declarată explicit. Prima parte are două probleme mici: nu există link către /confidentialitate la punctul de colectare, iar formularea sugerează consimțământ acolo unde prelucrarea e o măsură precontractuală la cererea persoanei. Reparația e o frază și un link.

Politica nu leagă formularul de niciun temei. Secțiunea 3 enumeră corect cele patru temeiuri, dar articolul 6 alineatul (1) litera b) e descris ca „livrarea serviciilor contractate” — adică doar prima ramură a textului. Cererea de ofertă, care e a doua ramură, rămâne fără rând propriu.

Antibotul declarat nu se vede în pagină. Secțiunea 6 numește Cloudflare Turnstile, cu un cookie strict necesar pentru formularele de contact. Pagina servită conține un câmp-capcană — un input numit website, marcat „leave blank” — și niciun widget vizibil. Turnstile poate rula în mod invizibil, așa că afirmația nu e neapărat falsă; constatarea e că nu se poate verifica din pagină și că e mai specifică decât documentul furnizorului, care nu numește niciun cookie. În plus, Turnstile apare exclusiv la categoria împuterniciți, deși Cloudflare se declară operator pentru îmbunătățirea detecției — același tratament corect pe care politica îl aplică deja furnizorului de publicitate.

Singurul destinatar fără nume e cel care vede mesajul întreg. Lista de împuterniciți numește MongoDB Atlas, Google Analytics 4, Vercel Analytics, Google Ads și Cloudflare Turnstile, dar trece serviciile de e-mail tranzacțional ca „furnizori conformi GDPR”. Furnizorul care primește conținutul integral al fiecărui mesaj e singurul rămas la nivel de categorie.

Retenția are un criteriu necalculabil. Datele de contact comercial se păstrează „3 ani de la ultima interacțiune semnificativă”. Nimeni din exterior nu poate stabili ce e semnificativ. Înlocuirea cu un eveniment cu marcaj de timp — ultimul mesaj din fir — face criteriul verificabil fără să schimbe durata.

Elementele care nu cer nicio modificare

Identificarea operatorului e completă, cu denumire, sediu, CUI, EUID și administrator. Punctul de contact GDPR e unul singur, declarat ca atare, cu termenul din articolul 12 alineatul (3). Duratele sunt exprimate în ani și luni, nu prin formula generică. Iar declarația explicită că formularul nu duce la newsletter e mai mult decât fac majoritatea site-urilor comparabile.

Ce a rămas de la auditul anterior

Cele cinci constatări consemnate pe /termeni în articolul despre termeni și condiții ca specificație de produs sunt toate neatinse: pagina poartă în continuare data de 27 mai 2026, intervalele de preț apar fără regimul de TVA, penalitățile și suspendarea rămân fără mecanism, nu există clauză de modificare sau istoric de versiuni, iar tensiunea dintre exclusivitatea B2B și informarea SAL persistă, ca și absența trimiterii către declarația de accesibilitate.

Întrebări frecvente

Am nevoie de consimțământ pentru un formular de contact?

De regulă, nu. Dacă persoana îți scrie ca să ceară ceva, prelucrarea stă fie pe măsuri precontractuale, fie pe interes legitim, iar consimțământul îți slăbește poziția fiindcă se poate retrage în mijlocul discuției. Consimțământul rămâne necesar pentru scopurile adăugate peste răspuns: newsletter, marketing, profilare.

Pot trimite newsletter celor care mi-au scris prin formular?

Nu, dacă nu au bifat separat. Excepția din articolul 12 alineatul (2) din Legea nr. 506/2004 cere ca adresa să fi fost obținută cu ocazia vânzării unui produs sau serviciu, ceea ce un formular de contact nu este. O bifă separată, nebifată implicit, rezolvă întreaga discuție.

Trebuie să pun reCAPTCHA sau Turnstile?

Nu obligatoriu. Un câmp-capcană plus limitarea ratei acoperă spamul obișnuit al unui site de firmă, fără destinatar nou. Dacă volumul cere un serviciu specializat, alege-l după ce declară despre datele colectate în documentația proprie și declară-l în politică cu rolul pe care și-l asumă, inclusiv atunci când sunt două roluri.

Cât timp pot păstra mesajele din formular?

Cât justifici, cu un criteriu pe care îl poate calcula altcineva. Douăzeci și patru de luni de la ultimul mesaj e o alegere obișnuită și ușor de apărat pentru cereri comerciale. Mesajele care au devenit documente contractuale ies din calcul și intră în termenele contractuale și fiscale.

Ce înregistrez ca dovadă a informării?

Versiunea textului afișat sub buton, marcajul de timp al trimiterii, temeiul aplicat și, separat, bifa de newsletter dacă există. Fără versiune, întrebarea „ce i s-a spus persoanei atunci” nu are răspuns, oricâte capturi de ecran ai păstra.

Formularul meu trimite mesajul într-un canal de chat. E o problemă?

Nu în sine, dar e o copie în plus, la un furnizor în plus, cu o retenție pe care de obicei nu o controlezi. Dacă notificarea conține doar un identificator și un link către panoul intern, copia dispare și inventarul se scurtează cu un rând.

Notă: materialul descrie cerințele care cad pe un formular obișnuit de contact și metoda de verificare, nu ține loc de consultanță juridică. Formularele care colectează categorii speciale de date, candidaturi la locuri de muncă sau date ale minorilor cer analiză separată.

Cel mai mic artefact din site e și singurul care poate fi auditat integral într-o după-amiază: șase câmpuri, un text, o schema, un job de ștergere. Dacă cele patru spun același lucru, restul paginilor legale au un exemplu de urmat. Dacă nu, divergența e vizibilă din exterior, de oricine deschide pagina.

Pentru celelalte suprafețe pe care le atinge aceeași verificare — bannere, politici, pagini de identificare — există câte un material în conformitate legală web. Partea de construit produsul din spatele formularului se discută pe hub-ul SaaS.