Kiedy retencja i usuwanie maja zastosowanie i co zrobic dalej

Retencja i usuwanie maja zastosowanie zawsze, gdy zespol SaaS zbiera, przechowuje, kopiuje, eksportuje, analizuje, archiwizuje lub usuwa dane osobowe. To nie tylko formalne wnioski o usuniecie. Temat pojawia sie przy churnie klienta, zamknietym tickecie, offboardingu, integracji, logach produktu i backupach.

W GDPR dane osobowe powinny byc przechowywane mozliwie najkrocej dla celu, z terminami usuniecia lub przegladu. Operacyjnie trzeba wiedziec: jakie systemy sa w scope, kto decyduje, jaka akcja nastepuje, jaki wyjatek obowiazuje i jaki dowod to potwierdza.

Kiedy dotyczy SaaS

Zaczyna sie, gdy workflow tworzy lub otrzymuje dane osobowe, i trwa do usuniecia, anonimizacji, ograniczenia, uzasadnionego archiwum albo udokumentowanego wygasniecia. Onboarding, funkcje, vendorzy, zamkniecie konta, tickety, spory, legal holds, diligence klienta, eksporty i backupy sa punktami kontroli.

Kiedy odpowiedz jest inna

Nie wszystkie dane usuwa sie tak samo. Jedne trzeba usunac szybko, inne anonimizowac, inne zachowac dla podatkow, fraudu, security, kontraktu lub roszczen, a inne do wygasniecia backupu. Decyzja powinna byc per kategoria i system.

Krok 1: dane i cel

Zacznij od kategorii: konta, authentication, eventy produktu, support, billing, security logs, kandydaci, vendorzy i raporty moga miec rozne cele. Zapytaj, jaki cel uzasadnia przetwarzanie, gdzie sa dane i czy wystarczy mniej danych lub dane anonimowe.

Krok 2: trigger

Okres retencji nie dziala bez startu. Moze to byc zakonczenie umowy, zamkniecie workspace, final invoice, ticket closure, odrzucenie kandydata, offboarding, zamkniecie incydentu, legal hold release, vendor termination lub backup rotation. Trigger powinien dawac te sama date wszystkim zespolom.

Krok 3: akcja

Akcja to hard deletion, scheduled purge, anonimizacja, restriction, archive, suppression record, vendor deletion, backup expiry albo retencja pod wyjatkiem. Obietnice dla klientow musza pasowac do technicznej rzeczywistosci.

Krok 4: ownerzy

Zdefiniuj ownerow dla reguly, systemu lub vendora, wykrycia triggera, akcji, akceptacji wyjatkow, komunikacji i dowodu. Model moze byc lekki, ale musi byc jasny przed audytem, review klienta lub launchem.

Krok 5: dowod

Dowod moze obejmowac regule, mape systemow, request, approval, deletion log, wynik anonimizacji, vendor confirmation, backup note i completion date. Polityka pokazuje intencje; dowod pokazuje wykonanie.

Co dalej

Wybierz workflow z realna presja: zamkniecie konta, wniosek o usuniecie, support tickets, kandydaci lub vendor offboarding. Wypisz dane i systemy, napisz trigger, okresl akcje i wyjatki, przypisz ownerow, przetestuj przyklad i zapisz dowod. Potem powtorz wzorzec.

FAQ

Jaki jest praktyczny cel?

Trzymac dane osobowe tylko przy uzasadnionym celu lub obowiazku, a potem usunac, zanonimizowac, ograniczyc, zarchiwizowac lub zrewidowac przez kontrolowany workflow.

Kiedy dotyczy zespolow SaaS?

Przy zbieraniu, przechowywaniu, kopiowaniu, eksporcie, analizie, archiwizacji lub usuwaniu danych osobowych, w tym product, support, billing, logs, vendors i backups.

Co dokumentowac najpierw?

Jeden ryzykowny workflow: kategorie, systemy, trigger, owner, akcja, wyjatki i dowod.