Usuwanie danych zgodnie z GDPR w SaaS: co zrobić z kopiami zapasowymi, logami i danymi u podwykonawców

Użytkownik usuwa konto w produkcie SaaS. Jego profil znika z interfejsu, ale adres e-mail pozostaje w dzienniku błędów, plik — w kopii zapasowej, a historia zgłoszeń — w systemie wsparcia. Z perspektywy produktu konto zostało usunięte, ale z punktu widzenia przetwarzania danych proces jeszcze się nie zakończył.

W tym właśnie miejscu pojawia się praktyczna trudność związana z prawem do usunięcia danych zgodnie z GDPR. SaaS przechowuje informacje w kilku systemach w różnych celach, a części kopii technicznie nie można zmienić równie łatwo jak rekordu w głównej bazie danych. Spółka musi ustalić, które dane rzeczywiście podlegają usunięciu, gdzie się znajdują i jak zapobiec ich ponownemu pojawieniu się po przywróceniu systemu.

Usunięcie konta i realizacja żądania usunięcia danych to różne działania

Przycisk «Usuń konto» zazwyczaj uruchamia wcześniej zaprogramowany scenariusz. Żądanie na podstawie GDPR wymaga dodatkowo sprawdzenia, które informacje dotyczą danej osoby i czy istnieją podstawy do przechowywania niektórych z nich po zamknięciu konta.

Na przykład profil i historia korzystania z produktu mogą nie być już potrzebne, ale określone dokumenty płatnicze należy zachować w celu wykonania obowiązków prawnych. Dane niezbędne w związku z konkretnym sporem również mogą być przechowywane, jeżeli istnieje odpowiednia podstawa. Nie oznacza to jednak, że można zachować całe konto «na wypadek roszczeń»: należy określić, jakie dokładnie informacje, w jakim celu i przez jaki okres są przechowywane, a następnie ograniczyć ich dalsze wykorzystanie.

Żądanie może również dotyczyć konkretnego użytkownika w ramach konta firmowego, które nadal pozostaje aktywne. Usunięcie całej bazy danych klienta byłoby w takim przypadku błędem. Należy odnaleźć dane konkretnej osoby bez naruszania dostępu pozostałych użytkowników do ich informacji.

W przypadku żądań osób, których dane dotyczą, GDPR przewiduje udzielenie odpowiedzi bez zbędnej zwłoki, co do zasady w ciągu miesiąca. W przypadku skomplikowanego żądania termin odpowiedzi może zostać przedłużony po spełnieniu określonych warunków i poinformowaniu wnioskodawcy. Dlatego proces usuwania powinien pozwalać nie tylko wykonać odpowiednie działania, ale również terminowo wyjaśnić osobie rezultat i zakres usunięcia.

Gdzie pozostają dane po usunięciu profilu

Pierwszym krokiem technicznym jest znalezienie wszystkich kopii i pochodnych rekordów związanych z użytkownikiem. W SaaS mogą to być:

• Systemy produkcyjne: główna baza danych, repozytorium plików, indeks wyszukiwania, pamięć podręczna, kolejka zadań i eksporty na potrzeby analityki wewnętrznej.
• Narzędzia operacyjne: dzienniki błędów i dostępu, system obsługi zgłoszeń, serwis pocztowy i panel do badania incydentów.
• Środowiska kopii zapasowych: snapshoty baz danych, kopie plików, archiwa i kopie zapasowe u dostawcy usług chmurowych.
• Systemy zewnętrzne: serwisy analityczne, mailingowe lub wsparcia, którym spółka przekazywała dane na potrzeby działania produktu.

Lista ta nie oznacza, że każdy rekord należy usuwać w ten sam sposób. Jest potrzebna po to, aby dane nie były nadal wykorzystywane w systemie, którego zapomniano uwzględnić w procesie.

Warto również sprawdzić identyfikatory pośrednie. Po usunięciu adresu e-mail dana osoba może nadal być możliwa do zidentyfikowania na podstawie ID konta, numeru zgłoszenia, adresu IP lub zawartości przesłanego pliku. Sama zamiana imienia i nazwiska na losowy kod nie zawsze powoduje, że rekord staje się anonimowy.

Co zrobić z kopiami zapasowymi

Kopia zapasowa służy do przywrócenia produktu po awarii lub ataku. W niektórych architekturach usunięcie z niej rekordu pojedynczego użytkownika bez zmiany całego snapshotu jest niemożliwe albo taka zmiana naruszyłaby integralność kopii. Jednak zasada «backupów nie ruszamy» nie rozwiązuje kwestii zgodności z GDPR.

Potrzebny jest odrębny schemat postępowania z kopiami. Spółka określa okres ich przechowywania, ogranicza dostęp i wyklucza ich wykorzystywanie do zwykłych zadań. Jeżeli selektywne usunięcie danych jest technicznie niemożliwe, kopie powinny być usuwane zgodnie z ustalonym cyklem, a informacje objęte żądaniem — uwzględniane przy każdym przywracaniu systemu. Długość cyklu powinna być uzasadniona; bezterminowego przechowywania starego snapshotu nie można uzasadnić wyłącznie tym, że jest on kopią zapasową.

Najważniejszą kwestią do sprawdzenia jest ponowne pojawienie się danych po przywróceniu systemu. Załóżmy, że profil użytkownika został usunięty 10 kwietnia, a 15 kwietnia bazę danych przywrócono ze snapshotu z 8 kwietnia. Jeżeli przywrócony produkt zostanie od razu udostępniony użytkownikom, usunięty profil pojawi się ponownie. Dlatego procedura przywracania powinna obejmować zastosowanie usunięć zarejestrowanych po utworzeniu kopii oraz sprawdzenie rezultatu przed przywróceniem systemu do normalnego działania.

W 2026 roku EDPB zwróciła osobno uwagę na problem spółek, które nie posiadają procedury obsługi żądań usunięcia danych w odniesieniu do kopii zapasowych. Podejście zależy od architektury i ryzyk, ale poleganie wyłącznie na automatycznej rotacji kopii bez uwzględniania otrzymanych już żądań nie jest wystarczające dla zapewnienia niezawodnego procesu.

Czy można pozostawić dane w logach

Logi pomagają badać awarie, chronić serwis i potwierdzać działania wykonywane w systemie. Usunięcie całego dziennika z powodu jednego rekordu często jest niemożliwe lub szkodliwe dla bezpieczeństwa innych użytkowników. Nie oznacza to jednak, że każdy log można przechowywać bez ograniczenia czasu i zakresu danych.

Najpierw należy ustalić, co dokładnie trafia do dziennika. Do diagnozowania błędu może wystarczyć czas zdarzenia, kod techniczny i ograniczony identyfikator. Adres e-mail, pełna treść żądania, token dostępu lub zawartość dokumentu użytkownika mogą okazać się zbędne. Najlepszym rozwiązaniem w takim przypadku jest zmiana sposobu logowania, aby nowe dane osobowe nie trafiały do logów.

W przypadku istniejących już rekordów ocenia się cel, okres przechowywania oraz możliwość usunięcia lub zanonimizowania danych konkretnej osoby bez naruszania istotnej części dziennika. Jeżeli określone rekordy muszą zostać tymczasowo zachowane, ogranicza się dostęp do nich, ich wykorzystanie sprowadza się do zadeklarowanego celu i określa moment ich usunięcia.

Szczególnej uwagi wymagają logi automatycznie przesyłane dostawcy systemu monitoringu. Usunięcie rekordu z własnego panelu nie oznacza, że zniknął on z systemu dostawcy.

Jak zorganizować usuwanie danych u podwykonawców

Dostawca SaaS może korzystać z zewnętrznego hostingu, narzędzi analitycznych, serwisu wsparcia i narzędzi do wysyłki wiadomości. W przypadku każdego z nich należy wiedzieć, jakie dane są przekazywane i kto może zainicjować ich usunięcie.

Jeżeli podwykonawca przetwarza dane na zlecenie spółki SaaS, żądanie usunięcia powinno zostać przekazane do niego za pośrednictwem procesu przewidzianego w umowie i integracji technicznej. Może to być API, panel administracyjny lub zgłoszenie do wsparcia dostawcy. Ważny jest możliwy do zweryfikowania rezultat: zespół powinien wiedzieć, czy żądanie zostało przyjęte, jakie dane zostały usunięte i czy działanie obejmuje również kopie znajdujące się u dostawcy.

Nie każdy zewnętrzny odbiorca działa wyłącznie zgodnie z instrukcjami spółki SaaS. Na przykład niektóre serwisy płatnicze lub inne niezależne podmioty mogą przechowywać część informacji w celu wykonania własnych obowiązków prawnych. W takiej sytuacji nie można obiecywać użytkownikowi, że spółka «usunęła wszystkie dane u wszystkich partnerów». Należy dokładnie ustalić charakter przekazania danych i poinformować o wykonanych działaniach bez ich wyolbrzymiania.

Odrębne ryzyko pojawia się przy zakończeniu umowy z dużym klientem korporacyjnym. Jego dane mogą znajdować się jednocześnie u kilku podwykonawców, a okres ich zwrotu i usunięcia może być określony w umowie z klientem. Zespół potrzebuje procedury obejmującej cały ten łańcuch, a nie wyłącznie wyłączenie dostępu do głównego konta.

Jak wygląda praktyczny proces usuwania danych

Żądanie można wygodnie traktować jako sekwencję działań z przypisanymi osobami odpowiedzialnymi i potwierdzeniem rezultatu:

1. Ustalić zakres żądania. Zidentyfikować osobę lub konto, zweryfikować uprawnienia wnioskodawcy i ustalić, czy żądanie dotyczy danych użytkownika, klienta korporacyjnego czy obu tych przypadków.
2. Podzielić dane według podstaw ich przechowywania. Ustalić, co można usunąć od razu, co musi zostać tymczasowo zachowane i dlaczego. Decyzję podejmuje się w odniesieniu do konkretnych kategorii danych, a nie całego konta.
3. Usunąć dane z aktywnego środowiska. Oprócz głównej bazy danych sprawdzić pliki, indeksy, pamięć podręczną, kolejki i pochodne zbiory danych. Ponowne uruchomienie odroczonego zadania nie powinno odtworzyć usuniętego rekordu.
4. Uruchomić działania w systemach zewnętrznych. Przekazać żądanie odpowiednim podwykonawcom i odnotować status jego realizacji; w razie potrzeby powiadomić innych odbiorców danych.
5. Uwzględnić kopie zapasowe i sprawdzić proces przywracania. Ustalić, kiedy kopie zostaną zastąpione, i upewnić się, że przywrócony system ponownie stosuje wykonane wcześniej usunięcia.
6. Odpowiedzieć wnioskodawcy. Poinformować, co zostało zrobione, jakie informacje są nadal przechowywane na konkretnej podstawie oraz w jaki sposób spółka postępuje z danymi znajdującymi się w kopiach zapasowych.

Do celów kontroli wewnętrznej wystarczy zachować minimalny zapis dotyczący samego żądania: datę, podjętą decyzję, wykonane działania i udzieloną odpowiedź. Taki ślad pomaga wykazać wykonanie obowiązków, ale nie powinien przekształcić się w nową bezterminową kopię usuniętego profilu.

Co sprawdzić w produkcie przed otrzymaniem pierwszego żądania

Usuwanie danych trudno zorganizować ręcznie, jeżeli te same informacje są zapisywane w dziesiątkach systemów bez wspólnego identyfikatora. Dlatego podczas rozwoju SaaS warto sprawdzać każdą nową integrację nie tylko pod kątem przyjmowania danych, ale również możliwości ich znalezienia, usunięcia i potwierdzenia usunięcia.

Dobrym testem jest utworzenie konta, skorzystanie z kluczowych funkcji, wysłanie zgłoszenia do wsparcia, a następnie usunięcie danych i sprawdzenie wszystkich powiązanych systemów. Drugi test polega na przywróceniu z kopii zapasowej środowiska, w którym konto to nadal istniało, i sprawdzeniu, czy nie pojawiło się ponownie po zastosowaniu procedury przywracania.

Taka kontrola ujawnia problemy niewidoczne w interfejsie: zapomniany indeks wyszukiwania, log zawierający pełną treść żądań lub podwykonawcę, dla którego nikt nie przewidział polecenia usunięcia danych. To właśnie te szczegóły decydują o tym, czy SaaS będzie w stanie w praktyce spełnić obietnicę złożoną użytkownikowi.