Prawo do bycia zapomnianym (art. 17 RODO) w PrestaShop: usuwanie konta bez zrywania śladu księgowego w 2026

Artykuł 17 RODO: obowiązek prosty do sformułowania, złożony w wykonaniu

„Klient może zażądać usunięcia swoich danych”. Zdanie w artykule 17 RODO jest lapidarne. Jego wdrożenie w sklepie PrestaShop albo WooCommerce, który istnieje od 5 lat, jest wszystkim, tylko nie proste. Bo dobrze zrobione „usunięcie konta” musi lawirować między czterema sprzecznymi wymogami:

• Prawo klienta do bycia zapomnianym (artykuł 17 RODO).
• Obowiązek przechowywania dokumentacji księgowej (ustawa o rachunkowości).
• Wymogi podatkowe i możliwość odtworzenia ewidencji sprzedaży (Ordynacja podatkowa, pliki JPK).
• Możliwość obrony w ewentualnym sporze (rękojmia i roszczenia z umowy sprzedaży).

Praktyczna stawka: moduł, który brutalnie usuwa wszystko, stawia firmę w konflikcie z prawem księgowym. Moduł, który nie usuwa nic, stawia firmę w konflikcie z RODO (kara do 4 % światowego obrotu). Dobrą praktyką jest selektywna pseudonimizacja: usunąć to, co nie jest konieczne do wypełnienia obowiązku prawnego, a resztę zachować w formie nienadającej się do powiązania ze zidentyfikowaną osobą.

Co dokładnie mówi artykuł 17 RODO

Artykuł 17 ustęp 1 wymienia sześć przesłanek uzasadniających żądanie usunięcia:

1. Dane nie są już niezbędne do celów, w których zostały zebrane.
2. Osoba cofa zgodę i nie ma innej podstawy prawnej.
3. Osoba wnosi sprzeciw wobec przetwarzania i nie występują nadrzędne prawnie uzasadnione podstawy.
4. Dane były przetwarzane niezgodnie z prawem.
5. Dane muszą zostać usunięte w celu wywiązania się z obowiązku prawnego.
6. Dane zebrano w związku z oferowaniem usług społeczeństwa informacyjnego dziecku.

Artykuł 17 ustęp 3 przewiduje jednak pięć wyjątków, które często mają zastosowanie w e-commerce:

1. Korzystanie z prawa do wolności wypowiedzi i informacji.
2. Wywiązanie się z obowiązku prawnego (na przykład przechowywanie dokumentacji księgowej).
3. Względy interesu publicznego w dziedzinie zdrowia publicznego.
4. Cele archiwalne, badania naukowe lub historyczne, cele statystyczne.
5. Ustalenie, dochodzenie lub obrona roszczeń.

Wyjątek drugi, czyli obowiązek prawny, jest tym, który stosuje się do danych księgowych. Ale nie obejmuje on wszystkich danych konta klienta, tylko te ściśle niezbędne do prowadzenia ksiąg i dochowania okresu przechowywania.

Ile lat trzeba przechowywać dane w Polsce

To punkt, w którym polskie realia różnią się od wielu zagranicznych poradników, więc warto go ustalić precyzyjnie. Co do zasady:

• Księgi rachunkowe i dowody księgowe: 5 lat, liczone od początku roku następującego po roku obrotowym, którego dotyczą (ustawa o rachunkowości).
• Dokumentacja podatkowa: powiązana z okresem przedawnienia zobowiązania podatkowego, czyli co do zasady 5 lat licząc od końca roku kalendarzowego, w którym upłynął termin płatności podatku (Ordynacja podatkowa).
• Roszczenia z umowy sprzedaży i rękojmia: rękojmia za wady co do zasady 2 lata od wydania rzeczy, z własnymi terminami przedawnienia roszczeń.

Praktyczny wniosek dla sklepu: horyzont przechowywania danych transakcyjnych to zwykle 5 lat, a nie 10, jak bywa w innych jurysdykcjach. To istotna różnica, bo pozwala szybciej przejść do pełnego usunięcia. Ponieważ jednak terminy liczone są od końca roku i mogą się wydłużać przy zawieszeniu biegu przedawnienia, konkretne ustawienie retencji w sklepie warto potwierdzić ze swoim księgowym, zamiast wpisywać na sztywno wartość z artykułu.

Mapowanie danych konta klienta

W sklepie PrestaShop z 5-letnią historią konto klienta zawiera typowo:

Zasada segregacji: czy ta dana jest niezbędna do śladu księgowego albo do ewentualnego sporu? Jeśli tak, zachowujemy w formie pseudonimizowanej. Jeśli nie, usuwamy.

Pseudonimizacja: mechanizm centralny

Pseudonimizacja to nie anonimizacja. Różnica jest prawna i techniczna:

• Anonimizacja: nieodwracalne usunięcie powiązania między daną a osobą. Danej nie da się już nigdy przypisać. Anonimizacja wyprowadza daną poza zakres RODO.
• Pseudonimizacja: zastąpienie bezpośrednich identyfikatorów pseudonimem, przy czym powiązanie pozostaje teoretycznie odtwarzalne (na przykład przez zaszyfrowaną tabelę odwzorowań). Dana pozostaje w zakresie RODO, ale przetwarzanie uznaje się za mniej ryzykowne.

W e-commerce dąży się zwykle do silnej pseudonimizacji, praktycznie zbliżonej do anonimizacji:

• customer.firstname na "Klient"
• customer.lastname na "#" + id_customer (na przykład "#42851")
• customer.email na "deleted-" + id_customer + "@invalid" (specjalny prefiks, nieprawidłowa domena)
• customer.phone na NULL
• customer.passwd na losowe bajty (konto faktycznie bezużyteczne)
• customer.note na NULL
• address.firstname i address.lastname na starych adresach: pseudonim
• address.firstname i address.lastname na adresie do faktury istniejących zamówień: zachować (niezbędne do faktury)

Klucz tkwi w niuansie: zachowujemy fakturę taką, jaka została wystawiona (obowiązek księgowy), ale usuwamy wszystko, co nie służy już żadnemu celowi.

Architektura zgodnego modułu usuwania

Poważny moduł dla PrestaShop, taki jak DfAccountDelete, realizuje pięć warstw:

Warstwa 1: przyjęcie żądania

Trzy możliwe kanały:

• Przycisk w panelu klienta: „Usuń moje konto”, dostępny z sekcji danych osobowych. Samoobsługowe UX.
• Formularz żądania: dla dawnych klientów, którzy nie mogą się już zalogować. Weryfikacja tożsamości e-mailem z linkiem potwierdzającym.
• Żądanie do inspektora ochrony danych albo na adres kontaktowy: e-mailem lub listownie, obsługiwane ręcznie z odnotowaniem w systemie.

Warstwa 2: weryfikacja tożsamości

Przed usunięciem sprawdzamy, czy osoba jest faktycznie posiadaczem konta. Dla klientów zalogowanych: sam fakt zalogowania plus podanie hasła albo potwierdzenie e-mailem. Dla niezalogowanych: wysyłka e-maila potwierdzającego z jednorazowym linkiem o ograniczonym czasie ważności (typowo 1 godzina). Dla żądań listownych: kopia dokumentu tożsamości przechowywana przez rok, a następnie niszczona.

Warstwa 3: czas do namysłu

Opcjonalne, ale zalecane: odstęp od 7 do 30 dni między żądaniem a faktycznym wykonaniem. Użytkownik dostaje e-mail „Twoje żądanie zostanie zrealizowane [data], kliknij tutaj, aby anulować”. Pozwala to uniknąć przypadkowych usunięć i żalu po fakcie.

Warstwa 4: wykonanie pseudonimizacji

Moduł wykonuje w atomowej transakcji MySQL:

1. Pseudonimizuje ps_customer (nazwisko, e-mail, telefon i tak dalej).
2. Pseudonimizuje rekordy ps_address niepowiązane z zakończonymi zamówieniami.
3. Usuwa porzucone rekordy ps_cart, ps_compare, ps_wishlist.
4. Usuwa wpisy programu lojalnościowego, alerty cenowe i alerty magazynowe.
5. Anonimizuje publiczne opinie („Klient anonimowy”) albo je usuwa, zależnie od polityki.
6. Usuwa logi sesji, tokeny logowania bez hasła i zapisane koszyki.
7. Usuwa zapisy do newslettera i propaguje usunięcie do Mailchimpa czy Brevo przez API, jeśli są podłączone.
8. Oznacza konto jako usunięte (active=0, deleted=1, deleted_at na teraz).
9. Zachowuje nienaruszone zamówienia, faktury i korekty (ps_orders, ps_order_invoice, ps_order_slip).

Warstwa 5: dziennik audytu i powiadomienie

Wpis w dzienniku audytu RODO:

• Data żądania, data wykonania.
• Pierwotny adres e-mail (sprzed pseudonimizacji).
• Identyfikator klienta.
• Metoda weryfikacji tożsamości.
• Lista objętych tabel i liczba zmienionych wierszy.

Ten dziennik przechowuje się przez okres pozwalający wykazać zgodność w razie kontroli UODO albo pytania samej osoby („czy naprawdę usunęliście moje dane?”).

Na pierwotny adres wysyłany jest e-mail potwierdzający, ze wzmianką, że dane zostały usunięte poza tymi niezbędnymi do celów księgowych (przejrzystość z artykułu 12 RODO).

Pomost z JPK: co bezwzględnie trzeba zachować

Część danych jest niezbędna do wytworzenia poprawnej ewidencji i plików JPK:

• Identyfikacja nabywcy na wystawionej fakturze (nazwa i adres do faktury z momentu wystawienia). Nie musi jednak być stale odnajdywalna z poziomu żywej bazy klientów, bo znajduje się na zarchiwizowanej fakturze PDF i w ps_orders.
• Kwoty netto, VAT, wysyłka, suma brutto: czyste dane księgowe, do zachowania w nienaruszonej postaci.
• Data zamówienia, faktury i płatności: podobnie.
• Metoda płatności (Stripe, PayU, Przelewy24, przelew): przydatna do uzgodnień bankowych.

Praktyczny wzorzec: pseudonimizujemy ps_customer, ale zostawiamy ps_orders.firstname, ps_orders.lastname i ps_orders.email takimi, jakie były w chwili zamówienia. To właśnie widnieje na wystawionej fakturze. Faktura jest zapisem księgowym, niezmiennym. Konto klienta jest żywym agregatem, który można zanonimizować.

W PrestaShop ułatwia to fakt, że faktura jest obsługiwana przez ps_order_invoice z własnymi polami (nazwa nie jest wyłącznie referencją przez id_customer, lecz zamrożona także w zamówieniu). W WooCommerce jest trudniej: zamówienia WC przechowują identyfikator klienta i odtwarzają dane przy wyświetlaniu. Trzeba więc zamrozić nazwę i adres do faktury na zamówieniu w momencie pseudonimizacji, inaczej ponownie wygenerowana faktura wyświetli „Klient anonimowy”.

Opinie i komentarze: przypadek osobny

Publicznie wyświetlana opinia o produkcie z nazwiskiem klienta jest daną osobową (artykuł 4 RODO). Jej usunięcie na żądanie rodzi dwa problemy:

• Treść opinii ma wartość dla innych klientów (informacja konsumencka).
• Historia opinii służy do wyliczania średniej oceny.

Standardowe rozwiązanie prawne: zanonimizować nazwisko („Klient anonimowy” albo inicjały), zachować treść opinii i ocenę. To przetwarzanie w celach statystycznych w rozumieniu artykułu 17 ustęp 3 litera d. Jeśli klient wyraźnie żąda całkowitego usunięcia opinii („nie chcę, żeby ten tekst dalej istniał”), usuwamy w całości, a średnią przeliczamy bez utraconej danej.

Ten niuans należy przedstawić użytkownikowi w formularzu: „Czy chcesz usunąć swoje opinie, czy uczynić je anonimowymi?”.

Trudne przypadki szczególne

Konto klienta z trwającym sporem

Jeśli zamówienie jest przedmiotem sporu (zablokowany zwrot, reklamacja, roszczenie z rękojmi), usunięcie danych klienta osłabia obronę firmy. Artykuł 17 ustęp 3 litera e obejmuje ten przypadek: można odmówić usunięcia do czasu rozstrzygnięcia sporu, informując klienta o przyczynie. Przechowywanie odbywa się wtedy pod statusem „w sporze”, z ograniczonym dostępem.

Konto B2B z wieloma użytkownikami

Na koncie B2B z kilkoma użytkownikami usunięcie konta jednego z nich nie może usuwać firmy. Usuwamy użytkownika (który ma prawo indywidualne), zachowujemy zamówienia wystawione na firmę (która jako osoba prawna nie ma prawa do bycia zapomnianą).

Newsletter bez konta (anonimowy)

Adres zapisany do newslettera bez konta klienta: usunięcie jest natychmiastowe, bez pseudonimizacji. Nie wiąże się z nim żaden obowiązek księgowy. Wyjątek: jeśli zgoda marketingowa jest zapisywana jako dowód, można zachować historię zgody (data, adres IP, potwierdzenie zapisu) przez rozsądny okres na wypadek zarzutu wysyłki bez zgody. Potem pełne usunięcie.

Abonenci usługi cyklicznej

W sklepach abonamentowych usunięcie konta wymaga najpierw zatrzymania abonamentu (nie da się obciążać karty konta, które nie istnieje). Moduł musi zachować kolejność: anulowanie abonamentów, odczekanie jednego cyklu na potwierdzenie, pseudonimizacja. Pominięcie tej sekwencji powoduje osierocone obciążenia i spory z klientami.

Termin odpowiedzi narzucony przez RODO

Artykuł 12 ustęp 3 RODO: odpowiedź na żądanie musi nastąpić w ciągu miesiąca, z możliwością przedłużenia o kolejne dwa miesiące przy żądaniach złożonych (z powiadomieniem wnioskodawcy o przedłużeniu). W praktyce dla e-commerce:

• Proste żądanie przyciskiem „usuń moje konto”: wykonanie natychmiastowe (z opcjonalnym czasem do namysłu), grubo poniżej terminu ustawowego.
• Żądanie e-mailem albo listownie wymagające weryfikacji tożsamości: 1 do 2 tygodni obsługi, poniżej miesiąca.
• Żądanie w kontekście złożonym (spór, aktywny abonament, wiele kont): miesiąc, z informowaniem wnioskodawcy o statusie.

Niedochowanie terminu naraża na sankcje UODO. Zautomatyzowany moduł odpowiadający w 24 do 48 godzin z zapasem pokrywa to ryzyko.

Koszt i zwrot z inwestycji

Zwrot z modułu usuwania konta mierzy się inaczej niż przy module konwersyjnym:

• Koszt modułu: 39 € licencji dla PrestaShop.
• Uniknięty koszt kary: zmienny, ale kary nakładane w e-commerce sięgają od kilku tysięcy złotych dla małych firm po wielomilionowe kwoty dla dużych podmiotów. Stosunek kosztu do ryzyka jest skrajnie korzystny.
• Uniknięty koszt obsługi ręcznej: w sklepie z 50 000 klientów ręczna obsługa 5 do 10 żądań miesięcznie to od 2 do 4 godzin pracy miesięcznie.
• Korzyść zaufania: dobrze widoczny przycisk „usuń moje konto” stał się w 2026 roku silnym sygnałem zaufania, mierzalnym we współczynniku zakładania kont.

FAQ

Czy naprawdę trzeba trzymać zamówienia po usunięciu konta?

Tak, wynika to z obowiązku księgowego i podatkowego. RODO nie zwalnia z prawa podatkowego. Rozwiązanie: zamówienia pozostają w bazie w formie pseudonimizowanej (nazwisko klienta nie jest już powiązane z żywym kontem, ale nadal widnieje na wystawionej fakturze, bo jest to konieczne). Po upływie okresu przechowywania możliwe jest pełne usunięcie.

Co zrobić, jeśli Mailchimp albo Brevo dalej wysyła newsletter?

Artykuł 19 RODO nakłada obowiązek propagacji usunięcia do odbiorców danych. Jeśli zsynchronizowałeś bazę z Mailchimpem, Brevo albo Klaviyo, moduł musi wywołać ich API, żeby usunąć kontakt, a nie tylko go wypisać. To punkt do zweryfikowania przy instalacji: wszystkie konektory marketingowe muszą otrzymać sygnał usunięcia.

Jak obsłużyć usunięcie u podmiotów przetwarzających (Stripe, PayU)?

Operatorzy płatności przechowują tokeny płatnicze i historię transakcji zgodnie z własną polityką (zwykle na potrzeby zgodności podatkowej i przeciwdziałania praniu pieniędzy). Nie możesz wymusić ich usunięcia, bo to ich odrębny obowiązek prawny. Twoja polityka prywatności musi wskazywać, że podmioty przetwarzające płatności zachowują dane przez własny okres ustawowy.

Czy można usunąć konto bez informowania klienta?

Jeśli to klient zażądał usunięcia, informujemy go o wykonaniu. Jeśli usuwa firma z własnej inicjatywy (na przykład z powodu długiej bezczynności), taka polityka musi być przewidziana w regulaminie i polityce prywatności, a najlepiej powiadomić 30 dni przed usunięciem, aby umożliwić sprzeciw. Usunięcie bez powiadomienia jest ryzykowne.

Czy klient może wrócić po żądaniu usunięcia?

Prawo do bycia zapomnianym nie jest prawem do cofnięcia tej decyzji. Po usunięciu albo pseudonimizacji danych klient, który wraca, zakłada nowe konto od zera. Historia pozostaje w dzienniku audytu RODO (który służy wykazaniu, że żądanie wykonano), ale nie może być użyta do odtworzenia pierwotnego konta.

Podsumowanie

Usunięcie konta zgodne z artykułem 17 RODO to ćwiczenie w równoważeniu czterech sprzecznych obowiązków prawnych. Rozwiązaniem jest selektywna pseudonimizacja: usuwamy albo anonimizujemy wszystko, czego nie obejmuje obowiązek przechowywania, i zachowujemy nienaruszony ślad księgowy niezbędny do ewidencji i kontroli podatkowej.

Moduł DfAccountDelete dla PrestaShop realizuje tę logikę w pięciu warstwach zgodnego procesu: przyjęcie żądania, weryfikacja tożsamości, opcjonalny czas do namysłu, atomowa pseudonimizacja, dziennik audytu. Integruje się z eksportem księgowym, aby nie zerwać łańcucha ewidencji, oraz z głównymi narzędziami marketingowymi (Mailchimp, Brevo, Klaviyo), aby propagować usunięcie.

Dobry odruch w 2026 roku: umieścić dobrze widoczny przycisk „usuń moje konto” w panelu klienta (sygnał zaufania i wyraźna zgodność), udokumentować proces w polityce prywatności (przejrzystość z artykułu 12) i prowadzić dziennik audytu, aby wykazać zgodność w razie kontroli.

Przeczytaj także: JPK i eksport księgowy w e-commerce oraz B2B na PrestaShop.

Aby przejść do działania: nasz wybór modułów do RODO i cookies.