Jak długo powinniśmy przechowywać dane i jak faktycznie je usunąć?

Dlaczego retencja to prawdziwa decyzja, a nie domyślne ustawienie

Większość firm nie decyduje, jak długo przechowywać dane. Trzymają wszystko, bo przechowywanie jest tanie, a usuwanie wydaje się ryzykowne. Ten domyślny wybór jest problemem.

Zasada ograniczenia przechowywania z RODO, w art. 5 ust. 1 lit. e, stanowi, że dane osobowe muszą być „przechowywane w formie umożliwiającej identyfikację osób, których dane dotyczą, przez okres nie dłuższy, niż jest to niezbędne do celów, w których dane te są przetwarzane". Prawo nie podaje ci liczby. Oczekuje, że sam ją ustalisz, dla każdego celu z osobna, i że będziesz umiał ją uzasadnić. Art. 5 ust. 2, zasada rozliczalności, czyni to twoim obowiązkiem: musisz umieć wykazać zgodność, nie tylko ją zadeklarować.

Z tego wynikają dwie rzeczy. Po pierwsze, „trzymamy to na zawsze, na wszelki wypadek" nie jest pozycją obronną, bo „na wszelki wypadek" nie jest celem. Po drugie, okres ustalasz i dokumentujesz sam, co daje więcej wolności i więcej odpowiedzialności, niż ludzie się spodziewają.

Istnieje argument bezpieczeństwa, który sam się broni. Najczystszym sposobem na zmniejszenie szkody z naruszenia jest trzymanie mniejszej ilości danych. Rekordu klienta, który usunąłeś dwa lata temu, nie ma w bazie, którą dziś w nocy skopiuje atakujący, a stary eksport na wspólnym dysku to ekspozycja bez żadnej korzystnej wartości. Retencja jednocześnie zmniejsza twoją powierzchnię prawną i powierzchnię naruszenia, a kosztuje przestrzeń dyskową, nie etaty.

Przeciwwagą jest to, że część danych trzeba zachować z mocy prawa, co ludzie wykorzystują jako uzasadnienie trzymania wszystkiego. Uczciwa wersja jest węższa niż to.

Dlaczego mimo to trzeba niektóre rzeczy zachować

Ograniczenie przechowywania nie oznacza usuwania tak szybko, jak to możliwe. Kilka obowiązków wymaga przechowywania konkretnych rekordów przez określone okresy, a niektóre sytuacje całkowicie zamrażają usuwanie.

Częste kategorie obowiązkowej retencji:

• Dokumenty podatkowe i księgowe. Faktury, księgi rachunkowe i sprawozdania finansowe mają ustawowe minimalne okresy przechowywania określone przez prawo krajowe. Różnią się w zależności od kraju, zwykle mieszczą się w przedziale kilku lat, i obowiązują niezależnie od tego, co mówi polityka twojego CRM.
• Dokumenty kadrowe i płacowe. Umowy, paski płacowe i powiązane dokumenty mają własne zasady retencji wynikające z krajowego prawa pracy i podatkowego.
• Dokumenty potrzebne do obrony roszczenia prawnego. Art. 17 ust. 3 lit. e RODO, dotyczący prawa do usunięcia, uznaje, że możesz zachować dane osobowe, gdy jest to niezbędne do ustalenia, dochodzenia lub obrony roszczeń. Art. 17 ust. 3 lit. b podobnie zachowuje dane, które musisz przechowywać w celu wypełnienia obowiązku prawnego.

Ponad tymi stałymi zasadami, legal hold (blokada prawna) to zdarzenie. Kiedy postępowanie sądowe, dochodzenie regulacyjne albo wiarygodny spór są racjonalnie przewidywalne, musisz zawiesić rutynowe usuwanie wszystkiego, co potencjalnie istotne, nawet jeśli twój harmonogram normalnie by to usunął. Legal hold przebija harmonogram retencji na cały czas swojego obowiązywania i powinien być nazwanym, świadomym krokiem, a nie przypadkiem wynikającym z tego, że ktoś zapomniał uruchomić zadanie usuwania.

Pogodzenie tych zasad jest proste. Dane objęte obowiązkową retencją są przechowywane przez wymagany okres i nie dłużej. Wszystko inne jest przechowywane tylko tak długo, jak służy żywemu celowi. Legal holdy wstrzymują usuwanie konkretnych danych, które obejmują. Nic z tego nie wymaga domyślnego trzymania wszystkiego.

Jak zbudować harmonogram retencji, który przetrwa zderzenie z rzeczywistością

Harmonogram retencji nie musi być obszernym dokumentem. Użyteczna wersja to tabela z czterema kolumnami, wypełniona uczciwie.

• Dane konta klienta · Dlaczego je przechowujemy: Dostarczanie usługi, wsparcie, rozliczenia · Jak długo: Czas trwania konta, potem określony okres po zamknięciu · Co się dzieje na końcu: Usunięcie albo anonimizacja we wszystkich systemach
• Leady sprzedażowe bez konwersji · Dlaczego je przechowujemy: Ściganie aktywnej szansy sprzedaży · Jak długo: Określony okres nieaktywności · Co się dzieje na końcu: Usunięcie z CRM i narzędzi enrichmentu
• Faktury i dokumenty księgowe · Dlaczego je przechowujemy: Ustawowy obowiązek podatkowy i księgowy · Jak długo: Krajowe minimum ustawowe · Co się dzieje na końcu: Usunięcie po upływie okresu ustawowego
• Dane kandydatów do pracy (nieprzyjęci) · Dlaczego je przechowujemy: Prowadzenie procesu rekrutacji · Jak długo: Krótki określony okres po decyzji · Co się dzieje na końcu: Usunięcie, chyba że jest zgoda na zachowanie w bazie
• Zgłoszenia do supportu · Dlaczego je przechowujemy: Rozwiązanie i poprawa jakości usługi · Jak długo: Określony okres po rozwiązaniu · Co się dzieje na końcu: Usunięcie albo anonimizacja
• Dane pracowników · Dlaczego je przechowujemy: Zatrudnienie, płace, obowiązek prawny · Jak długo: Zgodnie z krajowym prawem pracy i podatkowym · Co się dzieje na końcu: Usunięcie po wymaganym okresie

Kolumna „jak długo" to miejsce, gdzie jest cała robota. Ustal każdy okres na podstawie celu i odpowiedniego minimum prawnego, nie na podstawie przyzwyczajenia. Tam, gdzie cel się zakończył i żadne prawo nie wymaga retencji, okres powinien być krótki. Tam, gdzie ustawa ustala dolny próg, ten próg wygrywa, ale tylko dla tego konkretnego typu danych.

Trzy zasady utrzymują harmonogram uczciwym:

1. Jeden cel, jeden zegar. Dane zebrane do kilku celów mogą mieć kilka okresów retencji. Dane leada wykorzystywane do sprzedaży i księgowości mogą nadawać się do usunięcia z CRM na długo przed tym, zanim powiązaną fakturę będzie można usunąć z księgowości.
2. Anonimizacja to legalne zakończenie. Ograniczenie przechowywania dotyczy danych, które „umożliwiają identyfikację". Jeśli naprawdę i nieodwracalnie usuniesz identyfikatory, pozostały zbiór zagregowany przestaje być danymi osobowymi i można go zachować do analityki. Próg to realna nieodwracalność, nie lekkie maskowanie.
3. Zapisuj uzasadnienie, nie tylko liczbę. Rozliczalność z art. 5 ust. 2 polega na tym, żeby umieć wyjaśnić, dlaczego okres jest taki, jaki jest. Jednozdaniowe uzasadnienie na wiersz wystarczy i ratuje cię, kiedy zapyta o to regulator albo inspektor ochrony danych klienta.

Harmonogram jest wart tyle, ile jest egzekwowany, i tu większość z nich zawodzi. Dokument to łatwa część. Sprawienie, żeby usuwanie faktycznie się działo, to trudna część.

Trudna część: faktyczne usuwanie w systemach, SaaS i backupach

Usuwanie jest trudne, bo dane nie żyją w jednym miejscu. Pojedynczy rekord klienta może istnieć w CRM, systemie supportu, systemie rozliczeń, hurtowni danych, trzech narzędziach SaaS, które zsynchronizowały go przez integracje, kilku eksportach analityków, wątku e-mail i wczorajszym backupie. Usunięcie go z CRM usuwa jedną kopię.

To podstawowy problem, który trzeba zaplanować. Żeby usuwanie było realne, musisz wiedzieć, dokąd dane trafiają, zanim spróbujesz je usunąć.

Zacznij od mapy tego, gdzie żyją dane. Nie możesz usunąć czegoś, czego nie zlokalizowałeś. Systemy przechowujące dane osobowe to te oczywiste plus długi ogon: CRM, system HR, system supportu, platforma marketingowa, system finansowy, hurtownia danych oraz narzędzia SaaS, które gromadzą kopie przez integracje i eksporty. Ta sama mapa, która wspiera rejestr czynności przetwarzania z art. 30, to mapa potrzebna do usuwania.

Śledź kopie, nie tylko oryginały. Integracje to powód, dla którego usuwanie przecieka. Kiedy CRM synchronizuje kontakty z narzędziem marketingowym i usługą enrichmentu, usunięcie rekordu źródłowego może zostawić kopie nietknięte. Dla każdego systemu wiedz, co on zasila i czy usunięcie propaguje się dalej, czy trzeba je wywołać osobno.

Wykorzystaj mechanizmy usuwania, które dają narzędzia. Dojrzałe platformy SaaS udostępniają ustawienia retencji, narzędzia do masowego usuwania i API do usuwania. Skonfiguruj je zgodnie z harmonogramem, żeby usuwanie było automatyczne, a nie ręcznym obowiązkiem, o którym ktoś zapomina. Tam, gdzie takich mechanizmów nie ma, to ustalenie do zapisania i pytanie do dostawcy, zanim zaczniesz na nim polegać w kwestii danych osobowych.

Miej oko na ciche gromadzące się miejsca. Eksporty do arkuszy, dane skopiowane do hurtowni, załączniki na wspólnych dyskach i stare skrzynki to miejsca, gdzie usunięte dane przetrwają. Rzadko pojawiają się w harmonogramie retencji, bo nikt nie traktuje ich jako systemów rekordu, a mimo to zawierają realne kopie.

Potem są backupy, które zasługują na własne uczciwe potraktowanie, bo to jedyne miejsce, gdzie natychmiastowe usunięcie zwykle nie jest ani możliwe, ani wskazane.

Backupy i uczciwa odpowiedź

Backupy istnieją po to, żeby przywrócić wszystko do jednego punktu w czasie. Chirurgiczne usunięcie rekordu jednej osoby z każdego zrzutu backupu zepsułoby samą rzecz, do której backup służy, a w wielu architekturach nie jest to technicznie wykonalne bez przebudowy backupu.

Przyjęte rozwiązanie, opisane w wytycznych ICO dotyczących prawa do usunięcia, polega na oddzieleniu danych żywych od danych backupowych. Dane żywe, aktywne systemy usuwasz od razu. Kopie backupowe wyłączasz z użytku: nie wykorzystujesz danych z backupu do żadnego aktywnego celu, chronisz je tym samym poziomem bezpieczeństwa co resztę i pozwalasz im wygasnąć i zostać nadpisanymi w ramach normalnego cyklu backupu. Stanowisko ICO jest takie, że dopóki backup jest po prostu przechowywany do czasu zastąpienia go w ramach ustalonego harmonogramu i nie jest wykorzystywany do niczego w międzyczasie, zachowanie danych osobowych w tym backupie raczej nie stwarza istotnego ryzyka.

Z tego wynikają dwie praktyczne konsekwencje. Po pierwsze, ma znaczenie okres retencji twojego backupu: backup przechowywany bezterminowo to bezterminowo przechowywane dane osobowe, więc backupy powinny mieć zdefiniowany cykl życia jak wszystko inne. Po drugie, jeśli kiedykolwiek przywrócisz dane z backupu sprzed usunięcia, musisz ponownie zastosować usunięcia, które zaszły w międzyczasie, bo inaczej po cichu wskrzesisz dane, które byłeś zobowiązany usunąć. Ten krok ponownego zastosowania powinien znaleźć się w twoim runbooku przywracania.

Osobne pytanie, czy w ogóle musisz backupować swoje dane SaaS i jak, stoi obok tego. Retencja decyduje, jak długo żyją kopie, strategia backupu decyduje, jakie kopie w ogóle istnieją. Trzeba je zaprojektować razem. To temat towarzyszącego przewodnika, „Czy musimy robić backup danych z SaaS".

Jak to wspiera wnioski o usunięcie danych od osób, których dane dotyczą

Wszystko powyższe zwraca się, kiedy ktoś skorzysta ze swojego prawa do usunięcia danych na mocy art. 17 RODO. Osoba może poprosić cię o usunięcie jej danych osobowych, a tam, gdzie zastosowanie ma jedna z podstaw z art. 17, najczęściej ta, że dane nie są już potrzebne do pierwotnego celu, albo że osoba wycofała zgodę, na której opierało się przetwarzanie, musisz je usunąć bez zbędnej zwłoki. Zgodnie z art. 12 ust. 3 masz miesiąc na odpowiedź od otrzymania wniosku, z możliwością przedłużenia o kolejne dwa miesiące dla wniosków złożonych albo licznych, pod warunkiem że poinformujesz o tym daną osobę.

Firma bez dyscypliny retencyjnej przeżywa każdy wniosek o usunięcie jak nagły wypadek, bo za każdym razem musi pod presją czasu odkrywać, gdzie żyją dane tej osoby. Firma, która już zmapowała swoje systemy i zbudowała harmonogram retencji, traktuje ten sam wniosek jako rutynę, bo mapa już istnieje.

Co daje ci dobra praktyka retencji, kiedy wpłynie wniosek:

• Znaną listę systemów do sprawdzenia, tę samą mapę, na której zbudowany jest twój harmonogram, więc nie improwizujesz pod presją miesięcznego terminu.
• Już skonfigurowane mechanizmy usuwania, więc usunięcie danych jednej osoby wykorzystuje te same mechanizmy, których używasz do usuwania zaplanowanego.
• Obronną odpowiedź w sprawie backupów, bo możesz wyjaśnić podejście „usuń z żywych systemów od razu, wyłącz z użytku w backupach", zamiast wymyślać je na poczekaniu.
• Jasny zapis tego, co możesz legalnie zachować. Art. 17 ust. 3 pozwala ci zachować konkretne dane, żeby wypełnić obowiązek prawny albo obronić roszczenie prawne, więc możesz usunąć to, co musi zniknąć, i zachować, z podanym powodem, to, czego wymaga prawo.

Prawo do usunięcia nie jest absolutne. Możesz odmówić albo częściowo odmówić, gdy ma zastosowanie wyjątek, a udokumentowany harmonogram retencji to właśnie to, co pozwala ci wyznaczyć tę granicę czysto: to usunęliśmy, to zachowaliśmy, a oto podstawa prawna dla każdego z tych wyborów. Praca, którą wykonujesz, żeby rutynowo przechowywać i usuwać dane, to ta sama praca, która sprawia, że pojedyncze wnioski są łatwe do obsłużenia.

Źródła

• Art. 5 RODO, Zasady dotyczące przetwarzania danych osobowych (ograniczenie przechowywania 5 ust. 1 lit. e, minimalizacja danych 5 ust. 1 lit. c, rozliczalność 5 ust. 2) · https://gdpr-info.eu/art-5-gdpr/ (zasady ograniczenia przechowywania i rozliczalności)
• Art. 17 RODO, Prawo do usunięcia danych ('prawo do bycia zapomnianym') (podstawy w 17 ust. 1; wyjątki dla obowiązku prawnego 17 ust. 3 lit. b i roszczeń prawnych 17 ust. 3 lit. e) · https://gdpr-info.eu/art-17-gdpr/ (prawo do usunięcia i jego granice)
• Art. 12 RODO, Przejrzyste informowanie i komunikacja oraz szczegółowe warunki (miesięczny termin odpowiedzi, dwumiesięczne przedłużenie) · https://gdpr-info.eu/art-12-gdpr/ (termin odpowiedzi na wnioski)
• Art. 30 RODO, Rejestrowanie czynności przetwarzania · https://gdpr-info.eu/art-30-gdpr/ (mapa systemów, na której opiera się retencja i usuwanie)
• ICO, Right to erasure (backupy wyłączone z użytku do czasu nadpisania) · https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-erasure/ (jak obsługiwać usuwanie w backupach)
• ICO, Storage limitation principle (e) · https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/storage-limitation/ (uzasadnianie okresów retencji)
• EDPB, How do I respond to a request for erasure? · https://www.edpb.europa.eu/sme-data-protection-guide/faq-frequently-asked-questions/answer/how-do-i-respond-request-erasure_en (odpowiadanie na wnioski o usunięcie danych jako MŚP)