Poradniki Poradnik

RODO dla sklepów PrestaShop: Czego naprawdę potrzebujesz

Praktyczny przewodnik GDPR dla PrestaShop: zgoda na cookies, polityka prywatności, prawa do danych, retencja, podmioty trzecie i lista kontrolna.

To nie jest porada prawna. Jesteśmy firmą tworzącą moduły do PrestaShop z siedzibą w UE, RODO to prawo, w ramach którego działamy każdego dnia. Opisane poniżej wzorce mają jednak charakter wyłącznie techniczny. Treść umowy powierzenia przetwarzania (DPA), rejestr czynności przetwarzania, zgłaszanie naruszeń oraz to, czy wymagane jest powołanie inspektora ochrony danych (DPO), to zadania dla prawnika specjalizującego się w ochronie danych w danej jurysdykcji. Niniejszą stronę należy traktować jako techniczne uzupełnienie tej rozmowy po stronie deweloperskiej, a nie jako jej zastępstwo.

Co tak naprawdę oznacza „zgodność z RODO” (i czego żaden moduł nie zapewni)

Zbudowaliśmy dwa moduły w tym obszarze (Cookies Revolution do obsługi zgód oraz zestaw narzędzi do ochrony prywatności klientów, obsługujący eksport i usuwanie danych), a w sumie dostarczamy ponad 150 modułów. Jedna rzecz, którą powiedzielibyśmy każdemu sprzedawcy, zanim cokolwiek kupi: „pełnej zgodności z RODO” nie da się kupić w postaci modułu. Moduł obejmuje pliki cookie, rejestrowanie zgód, eksport danych po stronie klienta, usuwanie konta oraz okresowe czyszczenie danych z uwagi na okresy retencji. RODO obejmuje również umowy powierzenia przetwarzania danych z każdym dostawcą, rejestr czynności przetwarzania, udokumentowaną procedurę reagowania na naruszenia, decyzje co do podstaw prawnych oraz (w zależności od skali działalności i jej charakteru) inspektora ochrony danych. Większość z tych elementów to dokumentacja i polityki, a nie PHP.

Formularz rejestracji konta PrestaShop z polami wyboru zgód RODO (regulamin, polityka prywatności i ochrona danych klienta), które uzyskują wyraźną zgodę oraz informują klienta o prawie dostępu do danych osobowych oraz prawie do ich usunięcia.

Gdy zatem na tej stronie pada stwierdzenie „należy stosować baner zgód, który faktycznie blokuje skrypty”, jest to realna poprawka techniczna. Gdy pada stwierdzenie „potrzebna jest umowa powierzenia (DPA) ze Stripe”, to wciąż leży po stronie sprzedawcy, a nie dewelopera modułu.

Zasada, która leży u podstaw wszystkiego

Dane należą do klienta. Sprzedawca przechowuje je po to, aby zrealizować zamówienie. To jedno zdanie zmienia spojrzenie na większość wymogów:

  • Należy informować, jakie dane są zbierane i w jakim celu, żadnego cichego śledzenia, żadnych ukrytych pikseli stron trzecich
  • Należy zbierać wyłącznie to, co jest rzeczywiście potrzebne do realizacji zamówienia, data urodzenia nie wysyła paczki
  • Należy uzyskać prawdziwą, świadomą zgodę (opt-in) na wszystko, co nie jest ściśle niezbędne
  • Należy umożliwić wgląd, sprostowanie, eksport i usunięcie danych na żądanie
  • Należy chronić to, co się przechowuje, i nie przechowywać dłużej niż jest to konieczne

Czy RODO dotyczy danego sklepu?

Jeśli sklep wysyła towary do klientów z UE lub jego strona jest dostępna w jednym z języków UE, tak. Rozporządzenie podąża za osobą, której dane dotyczą, a nie za firmą. Mamy klientów z USA, którzy upierali się, że RODO ich nie dotyczy, aż do pierwszego zamówienia z Francji. Od tego zamówienia zaczęło ich obowiązywać.

Nie warto szukać sposobu na obejście tego wymogu. Praca nad zgodnością niemal w całości pokrywa się z dobrą inżynierią: HTTPS, sensowna retencja, przyzwoity UX zgód, brak zbierania zbędnych danych. Większość tego i tak należałoby wykonać.

Co liczy się jako dane osobowe w bazie danych PrestaShop

Wszystko, co pozwala zidentyfikować osobę bezpośrednio lub w połączeniu z innymi danymi. W przypadku sklepu oznacza to: imię i nazwisko, adres e-mail, telefon, adres, historię zamówień, skrót hasła, adres IP, odcisk przeglądarki (fingerprint), dzienniki zachowań oraz pliki cookie. Pułapka, w którą wpadają niektórzy, to przekonanie „IP to nie dane osobowe”, jest nimi w momencie, gdy można je powiązać ze znacznikiem czasu i sesją.

Sześć podstaw prawnych, z których realnie wykorzystuje się trzy

RODO nie pozwala zbierać danych „dlatego, że można”. Konieczne jest jedno z sześciu uzasadnień. W przypadku sklepu e-commerce trzy z nich dźwigają 99% obciążenia:

  • Umowa: w celu realizacji zamówienia. Adres dostawy, imię i nazwisko, adres e-mail, dane płatnicze.
  • Zgoda: newslettery, marketing, nieistotne pliki cookie. Musi być aktywnym opt-in, szczegółowa (granularna) i równie łatwa do wycofania, jak do udzielenia.
  • Obowiązek prawny: faktury, dokumentacja podatkowa. Okresy retencji zależne od kraju (zwykle 7–10 lat w całej UE).

„Prawnie uzasadniony interes” bywa powoływany w przypadku zapobiegania oszustwom i podstawowych dzienników bezpieczeństwa. Pozostałe dwie podstawy (żywotne interesy, interes publiczny) niemal nigdy nie mają zastosowania w sklepie.

Co tak naprawdę zbiera sklep PrestaShop, i gdzie te dane się znajdują

Zanim będzie można opisać, jakie dane są zbierane, trzeba to wiedzieć. Większość sprzedawców zaniża to o połowę. Audyt, który przeprowadzamy w każdym wdrażanym sklepie, przechodzi przez każdą z poniższych kategorii tabel.

Konta klientów

ps_customer przechowuje imię, nazwisko, adres e-mail, skrót hasła, opcjonalnie datę urodzenia i płeć, flagi newslettera i optin, datę utworzenia konta, datę ostatniego logowania, adres IP z momentu rejestracji oraz pola B2B (firma, SIRET/APE). Większość sklepów prosi o datę urodzenia przy rejestracji, nigdy jej później nie wykorzystując. Jeśli nie prowadzi się kampanii urodzinowych, należy usunąć to pole.

Zamówienia i adresy

Każde zamówienie zapisuje dane w tabelach ps_orders, ps_order_detail, ps_order_payment, ps_order_history, ps_address, ps_order_carrier oraz ps_message. Sama tabela ps_address może przechowywać pełne dane pocztowe, dwa numery telefonu, nazwę firmy, numer VAT oraz krajowy numer identyfikacyjny (pole dni, używane w Hiszpanii i kilku innych krajach).

Goście, połączenia, odsłony: tabela, która po cichu rośnie lawinowo

Nawet odwiedzający, którzy nigdy się nie rejestrują, zostawiają ślad w tabelach ps_guest, ps_connections, ps_connections_source, ps_connections_page, ps_page oraz ps_page_viewed. W umiarkowanie ruchliwym sklepie widzieliśmy, jak ps_connections w ciągu roku osiąga ośmiocyfrową liczbę wierszy. Adres IP w połączeniu z zachowaniami podczas przeglądania to dane osobowe, a nikt nigdy nie powiedział nam: „tak, celowo przechowujemy je przez trzy lata”. One po prostu się gromadzą, bo nic ich nie czyści.

Koszyki

ps_cart otrzymuje wiersz w momencie, gdy odwiedzający wrzuci coś do koszyka, niezależnie od tego, czy sfinalizuje zakup, czy nie. Powiązany z klientem lub gościem, z wyborem produktów, adresami i znacznikami czasu. Porzucone koszyki, które prowadzą z powrotem do konkretnej osoby, to dane osobowe. Większość sklepów nigdy ich nie czyści.

Newsletter, pliki cookie, dzienniki serwera, moduły stron trzecich

ps_emailsubscription (lub ps_newsletter w starszych sklepach) przechowuje adresy e-mail, daty subskrypcji, a czasem adres IP. Własne pliki cookie PrestaShop mają charakter funkcjonalny (sesja, koszyk, uwierzytelnianie w panelu administracyjnym) i nie wymagają zgody. Zgody wymagają te pliki cookie, które ustawiają moduły stron trzecich: GA, Meta Pixel, Hotjar, widżety czatu, znaczniki retargetingowe. Dzienniki dostępu Apache/Nginx również są danymi osobowymi (IP + znaczniki czasu + adresy URL). Należy zaudytować każdy moduł, który tworzy własne tabele, opinie, listy życzeń, czat na żywo, programy lojalnościowe, odzyskiwanie koszyków, moduły analityczne. Nie wiedząc, jakie tabele utworzył dany moduł, nie sposób zachować przejrzystości co do tego, jakie dane są zbierane.

Należy otworzyć phpMyAdmin, przefiltrować listę tabel według prefiksu modułu i sprawdzić, co się w nich znajduje. Robimy to w każdym audytowanym sklepie i zawsze znajduje się coś, o czym sprzedawca zapomniał, że zainstalował.

Zgody na pliki cookie: tu większość sklepów wciąż popełnia błąd

Gdybyśmy jutro zaudytowali losowy sklep, najbardziej prawdopodobnym naruszeniem, które byśmy znaleźli, jest zgoda na pliki cookie. Albo baner jest jedynie kosmetyczny (wyświetla się, a GA i tak się ładuje), albo pola są zaznaczone z góry, albo brakuje szczegółowej kontroli. Organy regulacyjne sprawdzają to w pierwszej kolejności, ponieważ najłatwiej to zweryfikować inspektorem w przeglądarce.

Czego faktycznie wymagają ePrivacy + RODO

  • Ściśle niezbędne pliki cookie (sesja, koszyk, CSRF, uwierzytelnianie w panelu administracyjnym) nie wymagają zgody
  • Wszystko inne (analityka, marketing, personalizacja, media społecznościowe) wymaga wyraźnego opt-in przed ustawieniem pliku cookie lub uruchomieniem skryptu
  • Zgoda musi być dobrowolna, konkretna (per kategoria), świadoma i aktywna
  • Wycofanie zgody musi być równie łatwe, jak jej udzielenie

Co nie jest ważną zgodą

  • „Kontynuując przeglądanie, użytkownik akceptuje pliki cookie”, zgoda dorozumiana nie jest zgodą
  • Baner zawierający wyłącznie „OK”: brak realnego wyboru
  • Pola zaznaczone z góry: musi to być opt-in, a nie opt-out
  • Ściany cookie („zgoda albo wyjście”): większość organów regulacyjnych w UE orzekła przeciwko nim
  • Baner, który wyświetla się, gdy skrypty już się wykonały, czysto dekoracyjny

Jak wygląda działające wdrożenie

Wzorzec znacznika skryptu, który faktycznie działa:

<!-- Zamiast ładować Google Analytics bezpośrednio: -->
<script src="https://www.googletagmanager.com/gtag/js?id=GA_ID"></script>

<!-- Ładować go warunkowo, w zależności od zgody: -->
<script type="text/plain" data-cookieconsent="statistics">
  // Ten skrypt wykonuje się dopiero po wyrażeniu przez użytkownika zgody na statystyczne pliki cookie
  (function(){ /* kod GA tutaj */ })();
</script>

type="text/plain" uniemożliwia przeglądarce wykonanie skryptu. Po wyrażeniu zgody menedżer zgód zmienia go na type="text/javascript" i wykonuje. Jeśli „baner zgód” tego nie robi (jeśli w Narzędziach deweloperskich widać _ga przed kliknięciem czegokolwiek), to jest zepsuty.

Problem z Google Analytics, o którym nikt nie mówi uczciwie

Jeśli zgody zostaną wdrożone prawidłowo, znacząca część odwiedzających odmówi zgody na analitykę, a liczby w GA spadną. To prawidłowy efekt. Dane, które dotychczas się posiadało, były zbierane bez podstawy prawnej. Trzy uczciwe drogi naprzód:

  • Pozostać przy GA4 z prawidłową zgodą i pogodzić się z niekompletnymi danymi. Trendy nadal działają, liczby bezwzględne, nie.
  • Przejść na samodzielnie hostowane Matomo lub Plausible, skonfigurowane tak, aby działały bez identyfikujących plików cookie. Niektórzy prawnicy akceptują dla nich „brak konieczności zgody” na podstawie prawnie uzasadnionego interesu. Warto sprawdzić u swojego.
  • Użyć GA4 Consent Mode, który w razie odmowy wysyła sygnały bez plików cookie i modeluje lukę. To kompromis, a nie rozwiązanie.

Oficjalny moduł psgdpr a dedykowane platformy CMP

PrestaShop dostarcza moduł psgdpr, który dodaje baner zgód, dostępny dla klienta proces eksportu i usuwania danych oraz dziennik zgód. To rozsądny punkt wyjścia. Nie zawsze blokuje pliki cookie stron trzecich przed wyrażeniem zgody (zależy to od tego, jak motyw i moduły ładują skrypty), a UX banera jest podstawowy. Dla małego sklepu z GA i niczym więcej to wystarcza. Dla sklepu korzystającego z GA + Pixel + Hotjar + czatu + retargetingu + pikseli afiliacyjnych warto sięgnąć po nasz moduł Cookies Revolution albo po dedykowaną platformę CMP, taką jak Cookiebot lub CookieYes.

Cokolwiek się zainstaluje, należy to przetestować. Prywatne okno przeglądarki, otwarte Narzędzia deweloperskie na karcie Aplikacja → Pliki cookie, przeładowanie strony głównej. Jeśli _ga, _fbp lub jakikolwiek inny plik cookie śledzący zostaje ustawiony przed kliknięciem czegokolwiek, wdrożenie nie spełnia swojej roli.

Polityka prywatności

To dokument prawny. Ogólne szablony pobrane z internetu zawodzą, ponieważ opisują sklep, który nie jest danym sklepem. Polityka musi wymieniać podmioty przetwarzające, okresy retencji oraz konkretne przepływy danych w danym sklepie.

Co musi obejmować (art. 13 i 14 RODO)

  • Kim jest administrator: nazwa firmy, adres siedziby, kontaktowy adres e-mail w sprawach prywatności
  • Dane kontaktowe inspektora ochrony danych (DPO), jeśli został powołany
  • Jakie dane osobowe są zbierane, w podziale na kategorie
  • W jakim celu zbierana jest każda kategoria: cel przetwarzania
  • Podstawa prawna dla każdej kategorii (umowa, zgoda, prawnie uzasadniony interes, obowiązek prawny)
  • Komu udostępniane są dane: płatności, wysyłka, e-mail, analityka, hosting
  • Transfery międzynarodowe oraz stojący za nimi mechanizm prawny
  • Okresy retencji dla każdego rodzaju danych
  • Prawa osoby, której dane dotyczą: dostęp, sprostowanie, usunięcie, przenoszenie, sprzeciw, ograniczenie
  • Sposób realizacji tych praw
  • Prawo do wniesienia skargi do organu nadzorczego
  • Czy podanie danych jest wymagane do korzystania z usługi
  • Wszelkie zautomatyzowane podejmowanie decyzji (większość sklepów nie stosuje żadnego)
  • Informacje o plikach cookie lub odnośnik do odrębnej polityki plików cookie

Szkielet, który można zaadaptować

1. Kim jesteśmy
   - Nazwa firmy, numer rejestrowy, adres
   - Kontaktowy adres e-mail w sprawach prywatności

2. Jakie dane zbieramy
   - Dane z rejestracji konta (imię i nazwisko, e-mail, hasło)
   - Dane zamówień (adres dostawy, adres rozliczeniowy, zawartość zamówienia)
   - Dane płatnicze (uwaga: nie przechowujemy numerów kart: robi to nasz operator płatności)
   - Dane komunikacyjne (wiadomości z formularza kontaktowego, wiadomości do zamówień)
   - Dane techniczne (adres IP, typ przeglądarki, pliki cookie)
   - Subskrypcja newslettera (adres e-mail)

3. W jakim celu je zbieramy (cele i podstawa prawna)
   - Aby realizować zamówienia (umowa)
   - Aby utworzyć konto i zarządzać nim (umowa)
   - Aby wysyłać potwierdzenia zamówień i informacje o wysyłce (umowa)
   - Aby wysyłać wiadomości marketingowe (zgoda: w każdej chwili można zrezygnować)
   - Aby ulepszać naszą witrynę (prawnie uzasadniony interes / zgoda na analityczne pliki cookie)
   - Aby spełniać przepisy podatkowe i rachunkowe (obowiązek prawny)
   - Aby zapobiegać oszustwom (prawnie uzasadniony interes)

4. Komu udostępniamy dane
   - Operator płatności: [Nazwa]: obsługuje płatności kartą
   - Przewoźnik: [Nazwa]: otrzymuje adres dostawy i numer telefonu
   - Usługa e-mail: [Nazwa]: wysyła wiadomości transakcyjne i marketingowe
   - Analityka: [Nazwa]: statystyki korzystania z witryny
   - Dostawca hostingu: [Nazwa]: przechowuje wszystkie dane witryny

5. Transfery międzynarodowe
   - [Lista wszystkich usług przekazujących dane poza UE/EOG]
   - Stosowane zabezpieczenia (Ramy ochrony danych UE-USA, standardowe klauzule umowne)

6. Jak długo przechowujemy dane
   - Dane konta: do momentu usunięcia konta
   - Dane zamówień: [X] lat (wymóg prawny dotyczący faktur)
   - Dane porzuconych koszyków: [X] miesięcy
   - Dane analityczne: [X] miesięcy
   - Dzienniki serwera: [X] dni

7. Prawa użytkownika
   - Dostęp, sprostowanie, usunięcie, przenoszenie, sprzeciw, ograniczenie
   - Sposób ich realizacji (e-mail, ustawienia konta, moduł RODO)
   - Prawo do wniesienia skargi do [organu nadzorczego w danym kraju]

8. Pliki cookie
   - [Podsumowanie lub odnośnik do polityki plików cookie]

9. Zmiany niniejszej polityki
   - Ostatnia aktualizacja: [data]

10. Kontakt
    - Adres e-mail do zapytań dotyczących prywatności

Gdzie ją umieścić jako odnośnik

Stopka (każda strona), formularz rejestracji, checkout, formularz kontaktowy, zapis do newslettera oraz baner plików cookie. W PrestaShop zwykle tworzy się politykę jako stronę CMS (Wygląd → Strony) i udostępnia ją za pośrednictwem widżetu odnośników (Link Widget) lub stopki motywu.

Prawa klienta dotyczące danych

Klient może zażądać swoich danych, poprosić o ich sprostowanie, poprosić o ich usunięcie lub o ich wydanie w formacie umożliwiającym przeniesienie. Czas na odpowiedź wynosi 30 dni.

Prawo dostępu: eksport danych

Nie tylko strona konta. Wszystko: zamówienia, adresy, rejestry zgód, wiadomości, status newslettera oraz wszystko, co przechowały moduły. Moduł psgdpr dodaje na stronie konta przycisk, który generuje plik PDF/CSV z podstawowych tabel PrestaShop. Jeśli wykonuje się to ręcznie:

-- Pobranie wszystkich danych konkretnego klienta
SELECT * FROM ps_customer WHERE id_customer = {ID};
SELECT * FROM ps_address WHERE id_customer = {ID};
SELECT * FROM ps_orders WHERE id_customer = {ID};
SELECT * FROM ps_cart WHERE id_customer = {ID};
SELECT * FROM ps_message WHERE id_customer = {ID};
SELECT * FROM ps_customer_message WHERE id_customer = {ID};

-- Należy uwzględnić tabele specyficzne dla modułów
SELECT * FROM ps_emailsubscription WHERE email = '{EMAIL}';
-- Należy sprawdzić wszelkie inne tabele modułów, które przechowują dane klientów

Prawo do usunięcia: prawo do bycia zapomnianym

Nie jest bezwzględne. Można odmówić, gdy istnieje obowiązek prawny zachowania danych (faktury do celów podatkowych, zwykle 5–10 lat w całej UE) lub trwa aktywny spór prawny. W praktyce oznacza to połączenie usuwania, anonimizacji i zachowywania:

  • Usunięcie: samo konto, nieużywane adresy, porzucone koszyki, subskrypcję newslettera, rekordy gości, listę życzeń, opinie
  • Anonimizacja: zamówienia, zastąpienie pól osobowych wartością „Deleted Customer”, zachowanie rekordu finansowego do celów rachunkowych
  • Zachowanie: faktury, z zanonimizowanymi danymi klienta na egzemplarzu udostępnianym klientowi, przy pełnym rekordzie zachowanym do celów podatkowych

Podejście ręczne, jeśli nie można skorzystać z modułu:

-- Anonimizacja rekordu klienta (bez usuwania: powiązane zamówienia zostałyby uszkodzone)
UPDATE ps_customer SET
  firstname = 'Deleted',
  lastname = 'Customer',
  email = CONCAT('deleted_', id_customer, '@anonymous.invalid'),
  passwd = '',
  birthday = '0000-00-00',
  phone = '',
  optin = 0,
  newsletter = 0,
  deleted = 1,
  active = 0
WHERE id_customer = {ID};

-- Anonimizacja adresów niepowiązanych z dostarczonymi zamówieniami
UPDATE ps_address SET
  firstname = 'Deleted',
  lastname = 'Customer',
  address1 = 'Deleted',
  address2 = '',
  postcode = '00000',
  city = 'Deleted',
  phone = '',
  phone_mobile = '',
  other = '',
  company = '',
  vat_number = '',
  dni = '',
  deleted = 1
WHERE id_customer = {ID}
AND id_address NOT IN (
  SELECT id_address_delivery FROM ps_orders WHERE id_customer = {ID}
  UNION
  SELECT id_address_invoice FROM ps_orders WHERE id_customer = {ID}
);

-- Usunięcie porzuconych koszyków (nieprzekształconych w zamówienia)
DELETE FROM ps_cart_product
WHERE id_cart IN (
  SELECT id_cart FROM ps_cart
  WHERE id_customer = {ID}
  AND id_cart NOT IN (SELECT id_cart FROM ps_orders)
);
DELETE FROM ps_cart
WHERE id_customer = {ID}
AND id_cart NOT IN (SELECT id_cart FROM ps_orders);

-- Usunięcie subskrypcji newslettera
DELETE FROM ps_emailsubscription WHERE email = '{ORIGINAL_EMAIL}';
Zawsze należy najpierw wykonać kopię zapasową, zawsze uruchomić wersję SELECT każdego zapytania i sprawdzić liczbę wierszy, zawsze testować na środowisku staging. Tam, gdzie wiersze są powiązane z zamówieniami, należy anonimizować. Naprawiliśmy dość spartolonych ręcznych usunięć, by za każde tutejsze słowo ręczyć.

Prawo do przenoszenia

Eksport w formacie nadającym się do odczytu maszynowego (JSON lub CSV), tak aby osoba, której dane dotyczą, mogła przenieść je gdzie indziej. Eksport psgdpr to obejmuje. Przy realizacji ręcznej, ten sam zestaw zapytań co przy prawie dostępu, sformatowany jako CSV lub JSON.

Prawo do sprostowania

Najprostsze z praw. Klienci mogą obsłużyć większość tego samodzielnie z poziomu strony konta. Jeśli napiszą wiadomość e-mail, należy poprawić dane w panelu administracyjnym. Gotowe.

Prowadzenie procesu

  1. Weryfikacja tożsamości: ten sam adres e-mail co przy koncie lub zgodność imienia i nazwiska z rekordem klienta. Widzieliśmy próby przejęcia konta za pomocą wiadomości e-mail z żądaniem „prawa do usunięcia”.
  2. Zarejestrowanie żądania: kto złożył, kiedy, czego dotyczyło
  3. Odpowiedź w ciągu 30 dni: z możliwością przedłużenia o kolejne 60 dni w skomplikowanych przypadkach, ale poinformować o tym należy w ciągu pierwszych 30 dni
  4. Realizacja lub odmowa z udokumentowanym powodem: np. „zanonimizujemy wszystko z wyjątkiem faktur, przechowywanych na podstawie obowiązku prawnego przez 7 lat”
  5. Potwierdzenie zakończenia na piśmie

Zarządzanie zgodami

Formularz rejestracji

Niezaznaczone pole zgody na politykę prywatności, z odnośnikiem do polityki. Nie zaznaczone z góry. Niepowiązane ze zgodą na newsletter, to odrębne zgody na odrębne cele.

Newsletter

Aktywny opt-in, jasna informacja o tym, na co się zapisuje, łatwa rezygnacja w każdej wiadomości. Należy sprawdzić szablon bloku newslettera w motywie. Starsze motywy dostarczają pole zaznaczone z góry, które trzeba ręcznie odznaczyć.

Zgoda na marketing / reklamę

Jeśli przekazuje się listy adresów e-mail do Facebook Custom Audiences lub podobnych usług, jest to odrębny cel i wymaga własnej zgody (opt-in). Zgoda na politykę prywatności tego nie obejmuje.

Przechowywanie dowodów

Trzeba móc wykazać, że zgoda została udzielona. Kto, kiedy, na co, w jaki sposób i która wersja polityki obowiązywała. psgdpr prowadzi dziennik. Przy tworzeniu własnego rozwiązania:

CREATE TABLE ps_gdpr_consent_log (
  id_consent_log INT AUTO_INCREMENT PRIMARY KEY,
  id_customer INT DEFAULT NULL,
  customer_email VARCHAR(255) NOT NULL,
  consent_type VARCHAR(50) NOT NULL,  -- 'privacy_policy', 'newsletter', 'marketing'
  consent_given TINYINT(1) NOT NULL,  -- 1 = udzielona, 0 = wycofana
  ip_address VARCHAR(45) DEFAULT NULL,
  date_add DATETIME NOT NULL,
  request_details TEXT DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Retencja: jak długo można przechowywać dane?

RODO mówi „nie dłużej niż jest to konieczne”. Nie podaje konkretnych liczb, to administrator je definiuje, dokumentuje i ich przestrzega. Do cyklicznych czyszczeń Database Cleanup może obsłużyć te tabele PrestaShop, które zwykle przekraczają ustalone okresy retencji. Nasze domyślne ustawienia w sklepach, które prowadzimy:

  • Konta aktywne: tak długo, jak są aktywne. Za nieaktywne uznajemy konta bez logowania lub zakupu przez 24–36 miesięcy.
  • Konta nieaktywne: wiadomość reaktywacyjna, a następnie anonimizacja w razie braku reakcji w ciągu 30 dni.
  • Dane zamówień: okres retencji podatkowej obowiązujący w danym kraju (zwykle 5–10 lat w całej UE). Należy zanonimizować pola osobowe i zachować rekord finansowy.
  • Faktury: okres określony przepisami prawa, bez wyjątków.
  • Porzucone koszyki: maks. 6–12 miesięcy. Nie ma biznesowego powodu, by przechowywać je dłużej.
  • Goście / połączenia: 6 miesięcy. ps_connections to tabela, która najbardziej daje się we znaki, jeśli się o niej zapomni.
  • Subskrybenci newslettera: do momentu rezygnacji. Długo nieaktywnych subskrybentów należy okresowo ponownie potwierdzać.
  • Dzienniki serwera: 30–90 dni, należy je agresywnie rotować.
  • Rejestry zgód: co najmniej przez czas trwania zgody (zwykle minimum 12 miesięcy).

Polecenia SQL do czyszczenia, których faktycznie używamy

-- Usunięcie rekordów gości starszych niż 6 miesięcy
DELETE FROM ps_guest
WHERE id_guest NOT IN (SELECT id_guest FROM ps_cart WHERE id_cart IN (SELECT id_cart FROM ps_orders))
AND id_guest IN (
  SELECT g.id_guest FROM ps_guest g
  INNER JOIN ps_connections c ON c.id_guest = g.id_guest
  GROUP BY g.id_guest
  HAVING MAX(c.date_add) < DATE_SUB(NOW(), INTERVAL 6 MONTH)
);

-- Usunięcie starych rekordów połączeń (zachowuje statystyki, ale usuwa dane powiązane z IP)
DELETE FROM ps_connections_source
WHERE id_connections IN (
  SELECT id_connections FROM ps_connections
  WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH)
);

DELETE FROM ps_connections_page
WHERE id_connections IN (
  SELECT id_connections FROM ps_connections
  WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH)
);

DELETE FROM ps_connections
WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);

-- Usunięcie porzuconych koszyków starszych niż 12 miesięcy (nieprzekształconych w zamówienia)
DELETE cp FROM ps_cart_product cp
INNER JOIN ps_cart c ON cp.id_cart = c.id_cart
WHERE c.date_add < DATE_SUB(NOW(), INTERVAL 12 MONTH)
AND c.id_cart NOT IN (SELECT id_cart FROM ps_orders);

DELETE FROM ps_cart
WHERE date_add < DATE_SUB(NOW(), INTERVAL 12 MONTH)
AND id_cart NOT IN (SELECT id_cart FROM ps_orders);

-- Czyszczenie starych statystyk odsłon (anonimowe dane zagregowane: niższy priorytet)
DELETE FROM ps_page_viewed
WHERE date_add < DATE_SUB(NOW(), INTERVAL 12 MONTH);
Każde DELETE należy najpierw opakować w SELECT i sprawdzić liczbę wierszy przed uruchomieniem. Należy uruchamiać je co miesiąc poza godzinami szczytu za pośrednictwem crona. Zawsze należy najpierw wykonać kopię zapasową. Pierwszy raz, gdy zapomni się o klauzuli WHERE, jest zarazem ostatnim.
# Przykładowy wpis crontab: uruchamia się o 3:00 pierwszego dnia każdego miesiąca
0 3 1 * * /usr/bin/php /path/to/your/store/scripts/gdpr-cleanup.php >> /var/log/gdpr-cleanup.log 2>&1

Skrypt powinien zapisywać, co usunął i kiedy. Ten dziennik jest częścią dokumentacji rozliczalności.

Podmioty przetwarzające (strony trzecie)

Sklep nie działa w izolacji. Każdy dostawca, do którego przekazuje się dane klientów, jest podmiotem przetwarzającym działającym w imieniu administratora, a z każdym z nich potrzebna jest umowa powierzenia przetwarzania danych (DPA).

Podmioty przetwarzające typowego sklepu PrestaShop

  • Płatności: Stripe, PayPal, Adyen, Mollie
  • Przewoźnicy: DHL, UPS, DPD, lokalne poczty krajowe
  • Marketing e-mail: Mailchimp, Brevo, Klaviyo
  • Analityka: GA, Matomo, Plausible
  • Hosting: własny VPS, serwer dedykowany lub dostawca chmury
  • CDN / WAF: Cloudflare, Sucuri
  • Narzędzia wsparcia: Zendesk, Freshdesk
  • Piksele marketingowe: Meta, TikTok, Pinterest
  • ERP / księgowość: cokolwiek pobiera zamówienia do zaplecza

Umowy powierzenia (DPA)

Każdy z nich wymaga podpisanej umowy powierzenia (DPA). Dobra wiadomość: wszyscy więksi dostawcy mają gotowe wersje, które można zaakceptować w ich panelu.

  • Stripe: wbudowana w ich Regulamin (Terms of Service)
  • PayPal: w ich dokumentach prawnych
  • Google: Data Processing Amendment, przełącznik w panelu administracyjnym GA
  • Mailchimp: standardowa umowa DPA na ich stronie prawnej
  • Brevo: DPA w regulaminie lub na żądanie
  • Cloudflare: DPA w ich dokumentacji dotyczącej zaufania i bezpieczeństwa

Należy je zaakceptować, zachować kopie i odłożyć w miejscu, w którym można je odnaleźć podczas audytu. My korzystamy ze współdzielonego folderu dla każdego sklepu, z jednym plikiem PDF na dostawcę.

Transfery międzynarodowe

Jeśli podmiot przetwarzający znajduje się poza UE/EOG (a większość z powyższej listy SaaS ma siedzibę w USA), potrzebny jest mechanizm prawny dla takiego transferu. Obecnie:

  • Ramy ochrony danych UE-USA (EU-US Data Privacy Framework): firmy z USA, które uzyskały certyfikat. Można to sprawdzić pod adresem dataprivacyframework.gov.
  • Standardowe klauzule umowne: wzorcowe klauzule zatwierdzone przez Komisję Europejską. Większość dużych dostawców zawiera je w swoich umowach DPA.
  • Decyzje stwierdzające odpowiedni stopień ochrony: Wielka Brytania, Kanada, Japonia, Korea Południowa, Szwajcaria i kilka innych.

Każdy transfer należy wymienić w polityce prywatności, podając kraj i mechanizm.

Gdy dane wyciekają: procedura na wypadek naruszenia

„Naruszenie ochrony danych” w rozumieniu RODO to nie tylko „zostaliśmy zhakowani”. To każdy incydent prowadzący do przypadkowego lub niezgodnego z prawem zniszczenia, utraty, zmodyfikowania, ujawnienia lub udostępnienia danych, a więc błędnie zaadresowany eksport zamówień, źle skonfigurowany zasobnik kopii zapasowych, skradziony laptop, nieuprawnione zapytanie pracownika czy ransomware blokujący dostęp do rekordów klientów: wszystko to się kwalifikuje.

Zegar 72 godzin

Jeśli naruszenie może wpłynąć na prawa osób, których dane dotyczą, należy powiadomić organ nadzorczy w ciągu 72 godzin od chwili stwierdzenia naruszenia. Jeśli ryzyko jest wysokie, należy także bez zbędnej zwłoki powiadomić osoby, których to dotyczy. „Stwierdzenie naruszenia” oznacza moment, w którym można było rozsądnie uznać, że doszło do naruszenia, a oczekuje się posiadania monitoringu, który sprawi, że ten moment nastąpi szybko.

Co zawiera zgłoszenie naruszenia

  • Charakter naruszenia
  • Kategorie i przybliżona liczba osób, których dane dotyczą
  • Kategorie i przybliżona liczba rekordów, których dotyczy naruszenie
  • Dane kontaktowe inspektora ochrony danych (DPO) lub głównego punktu kontaktowego
  • Prawdopodobne konsekwencje
  • Podjęte lub proponowane środki

Plan trzeba mieć, zanim się przyda

  1. Ustalenie organu nadzorczego: CNIL (Francja), ICO (Wielka Brytania), UODO (Polska), BfDI (Niemcy), Garante (Włochy), AEPD (Hiszpania) i tak dalej
  2. Dodanie do zakładek ich formularza zgłaszania naruszeń
  3. Przygotowanie szablonu zgłoszenia już teraz: dla organu i dla osób, których dane dotyczą
  4. Udokumentowanie każdego incydentu, nawet tych, co do których zapadnie decyzja, że nie wymagają zgłoszenia. Samo uzasadnienie jest wymagane przez RODO.
  5. Ustalenie, kto prowadzi dochodzenie, kto naprawia, kto się komunikuje
Zablokowany atak bez utraty danych to incydent, a nie naruszenie. Mimo to należy go zarejestrować, pokazuje, że monitoring istnieje.

Najczęściej spotykane błędy

W audytach, które przeprowadziliśmy w sklepach PrestaShop, powraca tych samych dziesięć rzeczy.

1. Pola zgód zaznaczone z góry

Pole zgody na newsletter w checkoucie lub przy rejestracji zaznaczone z góry. Należy przeszukać szablony motywu pod kątem checked lub checked="checked" przy każdym polu związanym ze zgodą. Odznaczyć.

2. Brak możliwości usunięcia konta

W standardowej instalacji PrestaShop nie pozwala klientowi samodzielnie usunąć konta. Należy zainstalować psgdpr, nasz moduł ochrony prywatności klienta albo utworzyć własny przycisk na stronie Moje konto.

3. Bezterminowe gromadzenie danych

Brak polityki retencji. Wiersze w ps_connections z 2019 roku. Koszyki porzucone trzy lata temu wciąż leżą w bazie. Należy zdefiniować okna retencji i zautomatyzować czyszczenie.

4. Słaby fundament techniczny

Art. 32 RODO wymaga „odpowiednich środków technicznych i organizacyjnych”. Udokumentowany standard utwardzenia (hardening), wdrożony ręcznie lub egzekwowany za pomocą modułu Security Revolution, jest częścią wykazania istnienia tych zabezpieczeń. Uchybienia, które spotykamy:

  • Brak HTTPS: w 2026 roku nie ma na to usprawiedliwienia
  • Konta administracyjne na słabych hasłach lub współdzielone między pracownikami
  • Wersje PrestaShop zaległe o lata względem poprawek bezpieczeństwa
  • Wciąż zainstalowane moduły ze znanymi podatnościami (CVE)
  • Brak kopii zapasowych lub kopie w publicznie dostępnym katalogu
  • Hosting współdzielony ze słabą izolacją najemców
  • FTP zamiast SFTP: dane uwierzytelniające przesyłane otwartym tekstem

5. Google Analytics uruchamiany przed wyrażeniem zgody

Klasyk. Baner się pojawia, GA już załadowane. Baner jest teatrem.

6. Kosmetyczny baner plików cookie

Baner istnieje, skrypty i tak się uruchamiają. Należy otworzyć Narzędzia deweloperskie i obserwować kartę Sieć podczas ładowania strony, jeśli Pixel i GA uruchamiają się przed jakimkolwiek kliknięciem, baner jest dekoracją.

7. Brakująca lub ogólnikowa polityka prywatności

Skopiowany szablon z niewypełnionymi miejscami na dane lub wymieniający podmioty przetwarzające, z których sklep faktycznie nie korzysta. Polityka musi opisywać dany sklep.

8. Brak rejestru zgód

„Należy wykazać, że ten klient zgodził się na wiadomości marketingowe”, i nie ma niczego do okazania. Albo dziennik psgdpr, albo dziennik naszego Cookies Revolution, albo własna tabela zgód.

9. Audyt wyłącznie rdzenia, z pominięciem modułów

Opinie, listy życzeń, odzyskiwanie porzuconych koszyków, czat na żywo. Każdy z nich przechowuje dane osobowe, każdy musi znaleźć się w polityce prywatności i w czyszczeniu zgodnym z okresami retencji.

10. Brak umów powierzenia (DPA)

Stripe, GA, Mailchimp, Cloudflare w użyciu, zero podpisanych umów DPA w aktach. Należy poświęcić godzinę, zaakceptować je wszystkie i odłożyć pliki PDF.

Lista kontrolna

Należy przejść przez nią raz, a następnie wracać do niej kwartalnie.

Fundament prawny

  • Polityka prywatności napisana, opublikowana, specyficzna dla tego sklepu
  • Odnośnik w stopce, przy rejestracji, w checkoucie, w formularzu kontaktowym
  • Polityka plików cookie (odrębna strona lub sekcja)
  • Regulamin odsyła do polityki prywatności
  • Umowy DPA podpisane z każdym podmiotem przetwarzającym
  • Rejestr czynności przetwarzania (RCPD) prowadzony na bieżąco
  • Inspektor ochrony danych (DPO) powołany, jeśli jest wymagany (zwykle tylko przy przetwarzaniu na dużą skalę lub danych wrażliwych)

Zgoda

  • Rejestracja: niezaznaczone pole polityki prywatności
  • Newsletter: odrębny, aktywny opt-in
  • Marketing: oddzielony od zgody na politykę prywatności
  • Baner plików cookie blokuje nieistotne pliki cookie przed wyrażeniem zgody
  • Szczegółowy wybór: akceptacja wszystkich / odrzucenie wszystkich / dostosowanie
  • Możliwość wycofania zgody z trwałego odnośnika w stopce
  • Rejestr zgód ze znacznikiem czasu, osobą, typem i wersją

Prawa klienta

  • Klienci mogą wyeksportować swoje dane
  • Klienci mogą zażądać usunięcia konta
  • Klienci mogą poprawić swoje dane
  • Dostępny eksport w formacie umożliwiającym przeniesienie (nadającym się do odczytu maszynowego)
  • Udokumentowany proces odpowiedzi w ciągu 30 dni
  • Weryfikacja tożsamości przy każdym żądaniu
  • psgdpr lub odpowiednik zainstalowany i przetestowany

Zarządzanie danymi

  • Okresy retencji zdefiniowane dla każdej kategorii danych
  • Zautomatyzowane czyszczenie tabel gości/połączeń
  • Zautomatyzowane czyszczenie porzuconych koszyków
  • Wdrożona rotacja dzienników serwera
  • Obsługa kont nieaktywnych
  • Wszystkie lokalizacje danych udokumentowane (baza danych, pliki, strony trzecie)

Bezpieczeństwo

  • Wymuszone HTTPS
  • PrestaShop w obsługiwanej wersji z zastosowanymi poprawkami bezpieczeństwa
  • Moduły aktualne
  • Silne hasła administratora (oraz 2FA tam, gdzie jest obsługiwane)
  • Zmieniona nazwa katalogu administracyjnego
  • Kopie zapasowe skonfigurowane, przetestowane, przechowywane poza katalogiem głównym serwisu
  • Wyłącznie SFTP/SSH
  • Rozsądne uprawnienia plików (żadnych 777)
  • Ograniczony dostęp do bazy danych

Gotowość na naruszenia

  • Ustalony organ nadzorczy
  • Przygotowany szablon zgłoszenia
  • Wyznaczona osoba kontaktowa ds. incydentów
  • Wdrożony monitoring (dzienniki, wykrywanie włamań)

Strony trzecie

  • Każdy podmiot przetwarzający wymieniony
  • Umowa DPA w aktach dla każdego z nich
  • Transfery międzynarodowe udokumentowane wraz z podstawą prawną
  • Podmioty przetwarzające wymienione w polityce prywatności
  • Piksele analityczne i marketingowe uzależnione od wyrażenia zgody

Na koniec: uczciwie

Organy regulacyjne nie szukają doskonałości. Szukają rzeczywistego wysiłku i rozsądnej praktyki. Sklep z prawdziwą polityką prywatności, działającym mechanizmem zgód, regułami retencji oraz procesem obsługi żądań osób, których dane dotyczą, jest w mocnej pozycji nawet wtedy, gdy nie każdy przypadek brzegowy został pokryty. Karane jest niedbalstwo: sklepy, które ignorują żądania, gromadzą dane, których nie potrzebują, i utrzymują kosmetyczne banery niespełniające żadnej funkcji.

Należy wybrać powyższą listę kontrolną. Przejść przez nią w ciągu najbliższych kilku tygodni. Wracać do niej kwartalnie. Na tym polega zgodność w praktyce, dokumentacja plus inżynieria, żadna z nich z osobna.

Powiedzieliśmy to dwa razy i powiemy jeszcze raz: jest to techniczne uzupełnienie rozmowy z prawnikiem specjalizującym się w ochronie danych, uzupełnienie po stronie deweloperskiej. Elementy techniczne (uzależnianie skryptów od zgody, czyszczenie zgodne z okresami retencji, procesy usuwania danych, prowadzenie dziennika audytu) możemy dostarczyć. Treść umowy DPA, rejestr czynności przetwarzania, zgłaszanie naruszeń, decyzje co do podstaw prawnych oraz to, czy potrzebny jest inspektor ochrony danych (DPO), to zadania dla doradcy prawnego w danej jurysdykcji.

Powiązane materiały

Powiązane pytania

Do góry