Greseli comune de retentie si stergere pe care echipele SaaS inca le fac

Greselile de retentie si stergere apar cand o companie SaaS trateaza subiectul ca pe o politica, nu ca pe o operatie. In GDPR, datele personale nu ar trebui pastrate mai mult decat este necesar pentru scop, trebuie stabilite termene de stergere sau review, iar dreptul la stergere poate cere actiune concreta. Partea grea este dovada in sisteme, tickete, procese cu vendori, backupuri si audit.

Cele mai frecvente probleme sunt triggeri neclari, reguli fara harta sistemelor, exceptii informale, promisiuni nerealiste despre backupuri si dovezi slabe.

De ce se rupe procesul

Pe hartie, totul pare simplu: datele clientilor pentru o perioada, ticketele de suport pentru alta, datele candidatilor dupa proces si backupurile prin rotatie. In realitate, aceleasi date apar in aplicatie, warehouse, CRM, helpdesk, loguri, analytics, billing, exporturi si tooluri ale vendorilor. Fara harta, stergerea este partiala.

Greseala 1: politica fara harta de sisteme

Un retention schedule trebuie legat de sisteme reale. Pentru fiecare workflow important, noteaza unde sunt datele, cine este owner, ce actiune e posibila si ce dovada ramane. Incepe cu inchiderea contului, cereri de stergere, tickete support, date angajati, vendor offboarding, analytics si loguri.

Greseala 2: durata fara trigger

"Pastreaza trei ani" nu spune cand porneste ceasul. Churn, factura finala, dezactivarea contului, inchiderea ticketului sau finalul obligatiilor contractuale pot da date diferite. Triggerul trebuie sa fie un eveniment operational verificabil.

Greseala 3: totul este dat la engineering

Engineering executa deseori actiunea tehnica, dar legal, privacy, security, support, finance, product si procurement au roluri reale. Workflowul trebuie sa spuna cine decide regula, detecteaza triggerul, aproba exceptii, executa si pastreaza dovada.

Greseala 4: minimizarea vine prea tarziu

Stergerea devine mai grea cand au fost colectate prea multe date. Formulare, analytics, atasamente support, integrari si campuri libere raspandesc rapid date personale. Fiecare functionalitate noua ar trebui sa intrebe daca datele sunt necesare, daca date anonime sau agregate sunt suficiente, unde apar copii si ce regula de retentie se aplica.

Greseala 5: backupurile sunt ignorate

Sistemele live pot fi sterse rapid, dar backupurile expira prin rotatie. Unele sunt immutable sau nu permit stergere per inregistrare. Separa live deletion, anonimizare, backup expiry, restore controls si legal holds. EDPB a indicat in 2026 backupurile si perioadele de retentie ca dificultati practice.

Greseala 6: toate cererile sunt tratate la fel

Dreptul la stergere nu este absolut. Obligatii legale, interes public sau apararea unor pretentii pot justifica retentie limitata. Foloseste un decision tree: identitate si scope, sisteme si vendori, temei pentru stergere, exceptii, actiune si documentare.

Greseala 7: dovada se pierde

Un script, un email de la vendor si un ticket inchis nu sunt suficiente daca nu leaga regula, triggerul, decizia, ownerul, actiunea si data. Dovada poate fi simpla, dar trebuie sa fie coerenta.

Greseala 8: schimbarile de produs nu sunt revizuite

Integrari noi, tabele analytics, loguri AI, screenshots support sau migrari billing schimba scope-ul. Lansarile cu risc ar trebui sa raspunda: ce date personale, ce copii, ce owner, ce stergere, ce dovada?

Checklist practic

• Fiecare regula este legata de sisteme si vendori.
• Triggerul este un eveniment clar.
• Ownerii pentru decizie, executie si dovada sunt definiti.
• Backupurile, arhivele si exporturile sunt tratate separat.
• Exceptiile si legal holds sunt documentate.
• Promisiunile catre clienti corespund realitatii tehnice.

Incepe cu un workflow concret, cum ar fi inchiderea contului sau cererea de stergere. Un proces mic si executabil este mai valoros decat o politica larga fara dovezi.