Rozdziały przewodnika
§ - Ważne zastrzeżenie dotyczące charakteru materiału00 - Jak korzystać z przewodnika01 - Najpierw wybierz model działalności i odpowiedzialności, potem buduj marketplace02 - Plan budowy: co musi istnieć i kiedy03 - Matryca odpowiedzialności: operator, sprzedawca i dostawcy04 - Onboarding sprzedawcy: kogo dopuścić do sprzedaży05 - Karta produktu: informacje, bez których oferta nie może się opublikować06 - GPSR: bezpieczeństwo produktów w praktyce07 - Bramki kategorii produktowych08 - BDO, opakowania i EPR: kto naprawdę ma obowiązek09 - Prawo konsumenckie: sprzedaż, odstąpienie i reklamacja10 - Ceny, promocje, ranking, reklamy i opinie11 - Płatności, wypłaty, VAT i dokument sprzedaży12 - RODO bez mitów: co zapisać, gdzie i na jakiej podstawie13 - DSA: zgłoszenia, moderacja i identyfikowalność sprzedawców14 - P2B: uczciwe zasady dla sprzedawców biznesowych15 - DAC7: dane sprzedawców i coroczne raportowanie16 - Dostępność e-commerce od 28 czerwca 2025 r.17 - Cyberbezpieczeństwo i KSC/NIS218 - Retencja: jak długo przechowywać dane i dowody19 - Operacje po uruchomieniu: kalendarz i właściciele20 - Cztery modele biznesowe - konkretne decyzje21 - Pakiet dokumentów i procedur do przygotowania22 - Checklista GO / NO-GO przed uruchomieniem23 - Najczęstsze błędne założenia24 - Źródła i zasada aktualizacji

RODO bez mitów: co zapisać, gdzie i na jakiej podstawie

Akceptacja regulaminu: wymagany dowód, nie wymagana osobna tabela#

Akceptacja regulaminu nie jest zgodą RODO na realizację zamówienia. Dane niezbędne do konta, zamówienia, płatności, bezpieczeństwa i obowiązków prawnych przetwarza się na właściwej podstawie, np. wykonania umowy, obowiązku prawnego lub uzasadnionego interesu. Nie należy wymuszać „zgody RODO”, której cofnięcie miałoby uniemożliwiać wykonanie zawartej umowy.

Checkbox „akceptuję regulamin” jest oświadczeniem umownym. Prawo wymaga przede wszystkim, aby regulamin został udostępniony przed zawarciem umowy w sposób pozwalający go pozyskać, odtworzyć i utrwalić oraz aby operator potrafił wykazać, jaka treść obowiązywała. Żaden przepis nie nakazuje z tego powodu utworzenia tabeli o konkretnej nazwie ani osobnej tabeli akceptacji.

Operator musi jednak mieć wiarygodny dowód pozwalający połączyć:

  • kto zaakceptował;
  • datę i dokładny czas;
  • wersję regulaminu i polityki, której akceptacja dotyczyła;
  • dokładny tekst etykiety checkboxa;
  • kontekst, np. rejestracja sprzedawcy albo konkretne zamówienie;
  • identyfikator dowodu pozwalający odtworzyć zdarzenie.

Można to wdrożyć na kilka prawidłowych sposobów: w istniejącym logu zdarzeń konta, historii zamówienia, dzienniku audytowym albo w osobnym rejestrze akceptacji. Wybór tabel i nazw jest decyzją techniczną. Warunkiem jest, aby dokument był wersjonowany i niezmienny, a zapis konta lub zamówienia jednoznacznie wskazywał tę wersję.

Minimalny wariant dla Artovni:

  1. Każda opublikowana wersja regulaminu ma identyfikator, datę obowiązywania oraz niezmienną treść - np. wersjonowany plik PDF lub zablokowaną rewizję w CMS. Dodatkowym dowodem może być skrót pliku.
  2. Istniejące zdarzenie utworzenia konta zapisuje identyfikator wersji regulaminu i czas akceptacji. Nie trzeba kopiować całego regulaminu do każdego rekordu.
  3. Jeżeli tekst checkboxa jest częścią niezmiennej wersji formularza lub wydania aplikacji, można odtworzyć go z tej wersji; nie musi być powielany w każdym rekordzie.
  4. Przy zamówieniu zapisuje się wersje dokumentów właściwych dla tej transakcji albo snapshot checkoutu. Akceptacja regulaminu konta nie zastępuje dowodu informacji i warunków konkretnej sprzedaży.

Nie trzeba zapisywać adresu IP ani user-agentu „na wszelki wypadek”. Można je dodać po analizie ryzyka i podstawy prawnej, ale podstawowym dowodem jest spójne powiązanie użytkownika lub zamówienia, czasu i niezmiennej wersji treści.

Sam fakt, że przycisk był zablokowany bez zaznaczenia checkboxa, nie jest wystarczającym dowodem, jeżeli platforma nie potrafi odtworzyć zdarzenia i wersji dokumentu. Jeżeli obecny model danych pozwala to zrobić pewnie i niezmiennie, może być wystarczający bez nowej tabeli.

Kiedy potrzebna jest zgoda i jak ją udowodnić#

Zgoda jest typowa dla opcjonalnego marketingu, nieobowiązkowych cookies i niektórych dodatkowych funkcji. Ma być dobrowolna, konkretna, świadoma, jednoznaczna, niezaznaczona z góry i równie łatwa do cofnięcia jak do udzielenia.

Dowód zgody powinien być dostępny w jednym kontrolowanym źródle dowodowym, a nie wyłącznie w narzędziu mailingowym bez własnego eksportu i historii. Może to być istniejący dziennik zdarzeń lub osobny rejestr; prawo nie narzuca nazwy ani struktury tabeli. Dowód powinien zawierać:

  • osobę lub konto;
  • administratora i cel;
  • kanał: e-mail, SMS, telefon, push - oddzielnie, jeśli różnią się zakresem;
  • dokładny tekst i wersję klauzuli;
  • czas, źródło i sposób udzielenia;
  • status oraz czas cofnięcia;
  • systemy, do których zgoda została przekazana.

Cookies i podobne technologie#

  • Technologie niezbędne do transmisji lub usługi żądanej przez użytkownika mogą działać bez zgody.
  • Analityka, reklama, personalizacja i inne technologie opcjonalne nie uruchamiają się przed zgodą.
  • Pierwsza warstwa daje równie łatwe „zaakceptuj” i „odrzuć”; użytkownik może wybrać kategorie.
  • Cofnięcie jest stale dostępne i zatrzymuje przyszłe działanie.
  • Platforma zapisuje identyfikator decyzji, wersję panelu/listy dostawców, kategorie, czas i zmianę decyzji.
  • Nowy dostawca lub nowy cel wymaga aktualizacji informacji i, gdy wykracza poza udzielony zakres, ponownej decyzji użytkownika.

Kto jest administratorem danych#

ProcesTypowa rola operatoraRola sprzedawcy/innego podmiotu
Konto kupującego, bezpieczeństwo platformy, ranking, moderacjaodrębny administratorsprzedawca nie ma dostępu poza swoim zamówieniem
Konto i weryfikacja sprzedawcy, P2B, prowizja, DAC7administratorsprzedawca jest osobą/podmiotem danych lub odrębnym administratorem swoich procesów
Realizacja zamówienia, dostawa, faktura, reklamacjaoperator i sprzedawca zwykle są odrębnymi administratorami dla własnych celów; trzeba opisać przepływsprzedawca - administrator danych potrzebnych do jego sprzedaży
Hosting, wysyłka e-maili, helpdesk działający wyłącznie na polecenieadministrator korzystający z procesoradostawca - procesor na podstawie umowy powierzenia
PSP, bank, kurierzależy od faktycznej roli i usługiczęsto odrębny administrator przynajmniej części własnych obowiązków

Co przechowywać i gdzie - opis architektury, nie model danych#

ObszarCo przechowywaćGdzie i kto ma dostęp
Profil użytkownikaaktualne dane konta i preferencjegłówny system kont; użytkownik i ograniczone role obsługi
Dowody zamówienianiezmienny snapshot sprzedawcy, produktu, ceny, dostawy, ostrzeżeń i dokumentów zaakceptowanych przy zakupieistniejący rekord zamówienia i jego pozycje/wersje; sprzedawca widzi wyłącznie własne zamówienia
Zgody i akceptacjewersjonowane, chronologiczne zdarzenia, w tym cofnięcia; dla regulaminu jednoznaczne powiązanie z niezmienną wersjąistniejący log konta/zamówienia albo osobny dziennik dowodowy; rozwiązanie ma być odporne na zmianę i dostępne audytowo
Weryfikacja sprzedawcytylko potrzebne dokumenty, wyniki baz urzędowych, decyzje i terminy ważnościistniejący magazyn plików z szyfrowaniem/kontrolą dostępu i powiązaniem z kontem; tylko zespół upoważniony
Zgodność produktudokumenty produktu, partie, producent, osoba odpowiedzialna, kontrole i wycofaniapliki i dane powiązane z ofertą/sprzedawcą; osobne repozytorium dopiero, gdy obecna struktura nie zapewnia uprawnień, wersji lub wyszukiwania
Zgłoszenia i incydentytreść, dowody, decyzje, komunikacja i terminyistniejący system requestów/ticketów z UUID, statusem i historią; dedykowany system spraw nie jest wymagany na start
Kopie zapasowedane niezbędne do odtworzeniaszyfrowane, odseparowane, testowane; usunięcia propagują się przez ustalony cykl rotacji

Minimalizacja i dostęp sprzedawcy#

Sprzedawca otrzymuje tylko dane konieczne do własnej dostawy, dokumentu sprzedaży i obsługi posprzedażowej. Nie widzi pełnej historii klienta, koszyków u innych sprzedawców, zgód marketingowych operatora, scoringu fraudowego ani dokumentów innych sprzedawców.

Adresu dostawy nie używa do własnego marketingu. Po zakończeniu właściwego okresu przechowywania dostęp operacyjny jest odbierany, nawet jeżeli operator zachowuje dowód z powodu obowiązku prawnego lub obrony roszczeń.

Prawa osób#

Platforma ma jeden kanał żądań i proces rozpoznający, których systemów i ról dotyczy sprawa. Odpowiada zasadniczo w miesiąc; w sprawach złożonych może przedłużyć termin o kolejne dwa miesiące, ale informuje o tym i powodach w pierwszym miesiącu.

Usunięcie konta nie oznacza natychmiastowego wymazania wszystkich zamówień. Platforma usuwa lub anonimizuje dane, których już nie potrzebuje, a dane objęte rachunkowością, podatkami, DAC7, DSA, obroną roszczeń lub incydentem blokuje do właściwego terminu i nie używa do nowych celów.

Naruszenie danych#

Proces ma wykryć, ograniczyć, ocenić ryzyko, zabezpieczyć dowody i zdecydować o zgłoszeniu. Jeżeli naruszenie może powodować ryzyko dla praw i wolności, administrator zgłasza je Prezesowi UODO bez zbędnej zwłoki, w miarę możliwości w 72 godziny od stwierdzenia. Przy wysokim ryzyku informuje też osoby, chyba że zachodzi ustawowy wyjątek.

Dokumenty RODO, które muszą realnie działać#

  • rejestr czynności przetwarzania - typowy marketplace nie korzysta praktycznie ze zwolnienia dla podmiotu poniżej 250 osób, bo przetwarzanie kont i zamówień jest regularne;
  • polityka prywatności i warstwowe klauzule w konkretnych miejscach;
  • umowy powierzenia z procesorami oraz rejestr dostawców i transferów;
  • matryca dostępu i upoważnienia;
  • retencja i mechanizm usuwania;
  • proces praw osób i naruszeń;
  • ocena ryzyka; DPIA, gdy proces może powodować wysokie ryzyko, np. rozległe profilowanie lub systematyczne monitorowanie;
  • decyzja, czy wymagany jest inspektor ochrony danych - marketplace nie potrzebuje go automatycznie, ale może spełnić ustawowe kryteria wraz ze skalą i rodzajem monitorowania.

Podstawa i źródła: RODO - rozporządzenie (UE) 2016/679; Ustawa o świadczeniu usług drogą elektroniczną - art. 8; UODO - rejestr czynności i wyjątek dla podmiotów poniżej 250 osób; UODO - naruszenia ochrony danych; Prawo komunikacji elektronicznej - marketing i informacje w urządzeniu końcowym.

Potrzebujesz wdrożyć te procesy w realnym marketplace?

Projektuję platformy multi-vendor wraz z onboardingiem, płatnościami, moderacją i procesami operacyjnymi.

Zobacz usługę budowy marketplace