Retencja i usuwanie: praktyczny przewodnik dla zespolow SaaS

Retencja i usuwanie dzialaja najlepiej, gdy zespoly SaaS zamieniaja jezyk polityki na operacyjne reguly dla realnych systemow. Celem jest wiedziec, jakie dane osobowe istnieja, dlaczego sa nadal potrzebne, jakie zdarzenie uruchamia okres retencji, kto odpowiada za akcje, jak odbywa sie usuniecie lub anonimizacja, jakie sa wyjatki i jaki dowod potwierdza wykonanie.

Zgodnie z GDPR dane osobowe nie powinny byc przechowywane w formie identyfikowalnej dluzej, niz jest to konieczne dla celow przetwarzania. W SaaS obejmuje to bazy produkcyjne, support, billing, analytics, logi, backupy, warehouse, exporty i vendorow.

Dlaczego to wazne w praktyce

Polityka mowiaca "usun dane klienta po zakonczeniu umowy" nie odpowiada, ktore systemy maja dane, czy konto zostalo tylko zdezaktywowane, czy analytics pozostaja identyfikowalne, czy tickety maja zalaczniki i czy vendor trzyma kopie.

Zbyt dluga retencja zwieksza skutki breach, zakres wyszukiwania przy access requests, utrudnia migracje i vendor exits oraz oslabia data minimisation. Usuwanie bez kontroli moze z kolei skasowac dane potrzebne do podatkow, fraud, kontraktu, security investigations lub legal claims.

Kiedy ma zastosowanie

Ma zastosowanie, gdy zespol SaaS przechowuje dane osobowe w produkcie, systemie operacyjnym, narzedziu wewnetrznym, platformie vendora, archiwum, logu, file store lub backupie. Obejmuje dane klientow, konta uzytkownikow, support, billing, telemetrie, security logs, leady, kandydatow, pracownikow, contractorow, kontakty vendorow i dowody compliance.

Komisja Europejska wskazuje, ze dane powinny byc przechowywane najkrocej jak to mozliwe, z uwzglednieniem powodow przetwarzania i obowiazkow prawnych. Organizacje powinny tez ustalic limity czasowe usuwania lub review danych.

Buduj schedule wokol zdarzen

Schedule retencji zawodza, gdy opisuja tylko typy rekordow i czasy. Systemy SaaS potrzebuja triggerow.

Dla kazdej kategorii zdefiniuj rekord, systemy i vendorow, zdarzenie startowe, domyslny okres, akcje usuniecia lub anonimizacji, ownera, wyjatek lub legal hold, wymagany dowod i interwal review.

Trigger bywa najtrudniejszy: usuniecie konta, koniec umowy, ostatnia platnosc, zamkniecie ticketu, odrzucenie kandydata, unsubscribe leada lub zamkniecie incydentu. Odpowiedzi moga sie roznic, ale musza byc jawne.

Mapuj reguly do systemow

Wiele problemow retencji to problemy mapowania. Ten sam rekord moze istniec w aplikacji, identity providerze, CRM, billing, support, analytics, warehouse, cloud storage, exportach, arkuszach, logach, backupach i u vendorow.

Zacznij od danych kont, profili, ticketow, billing, analytics, security logs, marketingu, HR oraz dowodow vendor lub compliance. Regula jest operacyjna dopiero wtedy, gdy zespol wie, gdzie dane istnieja.

Ustal, co znaczy usuniecie

Usuniecie nie zawsze jest jedna akcja techniczna. Moze oznaczac hard delete, soft delete plus purge, anonimizacje, pseudonimizacje, ograniczenie archiwalne, suppression albo wygasniecie backupu.

Backupy wymagaja precyzji. Jesli wazny request usuniecia ma zastosowanie, potrzebne sa kroki dla backupow i systemow live. Ale dane moga pozostac w backupie do nadpisania, jesli sa poza uzyciem i nie sa przywracane dla innych celow.

Nie obiecuj natychmiastowego usuniecia z kazdego backupu, jesli backupy dzialaja w rotacji. Opisz, co dzieje sie w systemach live, co z backupami i ile zwykle trwa expiry.

Request usuniecia to nie rutynowa retencja

Rutynowa retencja dziala na schedule i zdarzeniach biznesowych. Request usuniecia zaczyna sie, gdy osoba o to prosi. Artykul 17 GDPR ma zastosowanie w okreslonych sytuacjach, np. gdy dane nie sa juz potrzebne, zgoda zostala wycofana bez innej podstawy, przetwarzanie jest niezgodne z prawem albo prawo wymaga usuniecia. Prawo nie jest absolutne.

Zespol SaaS potrzebuje triage: rozpoznac request, zapisac deadline, zweryfikowac tozsamosc, znalezc systemy i vendorow, zdecydowac co usunac, zachowac lub ograniczyc, udokumentowac powody czesciowej odmowy, wykonac i zachowac dowod.

Wyjatki zdefiniuj przed deadline

Typowe wyjatki to podatki, ksiegowosc, kontrakt, fraud, security, incident response, legal holds, spory, insurance, regulatory reporting i audit evidence. Wazne jest zapisanie, kto zatwierdzil wyjatek, jakie dane obejmuje, dlaczego obowiazuje, kiedy bedzie review i co stanie sie po zakonczeniu.

Uwzglednij vendorow

Dane SaaS rzadko zyja tylko w produkcie. Vendorzy i processorzy moga przechowywac support, billing, analytics, komunikacje, logi, backupy i compliance records. Retencja i usuwanie powinny wiec byc czescia vendor onboarding i processor management.

Zapytaj, jak dziala retention, jak poprosic o deletion, czy backupy maja osobny cykl, czy powstaja exporty, ktorzy subprocessors przechowuja dane i jaki dowod moze dostarczyc vendor.

FAQ

Co zespoly powinny zrozumiec?

Ze retencja i usuwanie to zywy workflow laczacy inventory danych, ownership systemow, triggery, wyjatki prawne, backupy, vendorow, requesty usuniecia i dowody.

Dlaczego to wazne w praktyce?

Firmy SaaS przechowuja dane osobowe w wielu systemach. Bez modelu operacyjnego dane sa trzymane za dlugo, usuwane niespojnie albo zarzadzane decyzjami trudnymi do udowodnienia.

Co dokumentowac najpierw?

Zacznij od danych kont, supportu, billing, analytics, security logs i danych u vendorow. Zdefiniuj trigger, ownera, lokalizacje, akcje, wyjatek i dowod.

Sources

• European Union, General Data Protection Regulation.
• European Commission, For how long can data be kept and is it necessary to update it?
• European Commission, Do we always have to delete personal data if a person asks?
• Information Commissioner's Office, Principle (e): Storage limitation.
• Information Commissioner's Office, Right to erasure.