Krótka odpowiedź: gdy gość prosi o usunięcie swoich danych osobowych, restauracja powinna najpierw zweryfikować, że żądanie pochodzi od właściwej osoby, następnie sprawdzić, czy istnieją uzasadnione powody zachowania części danych (np. nieopłacona faktura, dokumentacja finansowa, otwarta rezerwacja), a potem usunąć lub zanonimizować dane we wszystkich systemach, które je przechowują – rezerwacyjnym, CRM, POS i marketingowym – dokumentując każdy krok. Poniżej znajduje się praktyczny model postępowania.
Prośba gościa o usunięcie danych rzadko dotyczy jednego systemu. Dane z rezerwacji często są kopiowane do CRM, systemu POS, platformy do wysyłki e-maili marketingowych i czasem do arkuszy używanych przez zespół sali. Bez jasnej procedury łatwo usunąć dane w jednym miejscu, a zapomnieć o kopii w innym – co samo w sobie może być problemem, niezależnie od interpretacji prawnej konkretnego przypadku.
Model W-O-D-Z: cztery etapy obsługi żądania
Poniższy model porządkuje proces w cztery etapy, które można zastosować niezależnie od wielkości lokalu: Weryfikacja, Ocena wyjątków, Działanie w systemach, Zamknięcie i dokumentacja.
1. Weryfikacja tożsamości i zakresu żądania
Zanim jakiekolwiek dane zostaną usunięte, warto potwierdzić dwie rzeczy: że osoba składająca żądanie jest tą samą osobą, której dane dotyczą, oraz co konkretnie ma zostać usunięte. Gość może chcieć usunięcia tylko adresu e-mail z listy marketingowej, a nie całej historii rezerwacji.
- Poproś o potwierdzenie tożsamości w sposób proporcjonalny do ryzyka (np. odpowiedź z adresu e-mail powiązanego z kontem lub rezerwacją).
- Zapytaj, czy prośba dotyczy wszystkich danych, czy konkretnej kategorii (marketing, historia rezerwacji, dane płatnicze).
- Zapisz datę wpływu żądania – to punkt odniesienia dla terminu odpowiedzi.
2. Ocena wyjątków i ograniczeń retencji
Nie każde dane można usunąć w momencie żądania. Komisja Europejska w swoich zasadach ochrony danych opisuje minimalizację celu i ograniczenie przechowywania jako reguły, według których dane powinny służyć konkretnemu celowi i nie być przechowywane dłużej, niż jest to konieczne dla tego celu. Nie oznacza to jednak, że każde żądanie usunięcia musi być zrealizowane w całości i od razu – jeśli istnieje otwarty cel (np. niezapłacona rachunek, trwający spór, obowiązek dokumentacji podatkowej), dane związane z tym celem mogą wymagać zachowania na czas określony przepisami krajowymi lub wewnętrzną polityką finansową.
Ważne ograniczenie: ten artykuł nie stanowi porady prawnej. Konkretne terminy przechowywania dokumentacji finansowej, sanitarnej czy podatkowej różnią się między krajami i branżami. Każda restauracja powinna potwierdzić dokładne okresy retencji i wyjątki z prawnikiem lub działem compliance, zanim ustali własną politykę.
3. Działanie we wszystkich systemach
To etap, na którym najczęściej brakuje spójności – nie dlatego, że dane te systemy są ze sobą niekompatybilne, ale dlatego, że rzadko istnieje jedna lista wszystkich miejsc, gdzie dane gościa faktycznie się znajdują. Warto zbudować i utrzymywać taką listę na bieżąco, a nie tworzyć ją dopiero w chwili żądania.
| System | Typowe dane gościa | Działanie po weryfikacji |
|---|---|---|
| System rezerwacji | Imię, kontakt, historia wizyt, preferencje | Usunięcie lub anonimizacja poza zakresem wyjątków |
| CRM / baza marketingowa | E-mail, telefon, segmenty, zgody | Usunięcie z list wysyłkowych i profili |
| POS / płatności | Dane transakcyjne, ewentualnie dane karty | Zachowanie zgodnie z wymogami księgowymi, usunięcie danych zbędnych do rozliczeń |
| Arkusze / notatki zespołu | Preferencje, alergie, uwagi | Ręczne usunięcie, jeśli dane nie są objęte wyjątkiem |
| Kopie zapasowe | Wszystkie powyższe kategorie | Uwzględnienie w polityce retencji backupów |
4. Zamknięcie i dokumentacja
Po wykonaniu działań w systemach warto poinformować gościa, co konkretnie zostało usunięte, a co – i z jakiego powodu – zostało zachowane. Ta informacja nie musi być długa, ale powinna być konkretna. Cały proces, od weryfikacji do zamknięcia, warto zapisać wewnętrznie: kto obsłużył żądanie, jakie systemy sprawdzono i jaką decyzję podjęto w sprawie wyjątków.
Checklist do wdrożenia w restauracji
- Wyznacz osobę lub rolę odpowiedzialną za przyjmowanie i obsługę żądań usunięcia danych.
- Zbuduj listę wszystkich systemów przechowujących dane gości (rezerwacje, CRM, POS, marketing, arkusze zespołu, backupy).
- Ustal wewnętrzny szablon weryfikacji tożsamości osoby składającej żądanie.
- Skonsultuj z prawnikiem, jakie kategorie danych podlegają obowiązkowej retencji i na jaki okres.
- Przygotuj procedurę działania krok po kroku dla każdego systemu z listy.
- Ustal wewnętrzny termin odpowiedzi na żądanie i sposób jego monitorowania.
- Zapisuj każde żądanie i decyzję w rejestrze wewnętrznym, niezależnie od tego, czy dane zostały usunięte w całości.
Pomiar i monitorowanie procesu
Warto śledzić proces obsługi żądań wewnętrznie, nie po to, by porównywać się z jakąkolwiek zewnętrzną normą – takich danych branżowych nie podajemy w tym artykule – ale by wiedzieć, czy proces w danej restauracji faktycznie działa. Sensowne miary wewnętrzne to:
- Liczba otrzymanych żądań usunięcia danych w danym okresie.
- Czas od wpływu żądania do jego zamknięcia, mierzony na podstawie własnych zapisów.
- Liczba systemów, które musiały zostać sprawdzone przy każdym żądaniu.
- Liczba przypadków, w których zastosowano wyjątek od pełnego usunięcia, wraz z powodem.
Te dane pomagają ocenić, czy lista systemów jest aktualna i czy procedura wymaga uproszczenia, a nie służą do porównań z innymi lokalami czy do formułowania ogólnych wniosków o branży.
Ograniczenia tego modelu
Model W-O-D-Z porządkuje kroki operacyjne, ale nie zastępuje analizy prawnej. Nie każda restauracja podlega tym samym przepisom, a interpretacja pojęć takich jak „uzasadniony cel” czy „niezbędny okres przechowywania” zależy od jurysdykcji i konkretnego stanu faktycznego. Model nie określa też sztywnych terminów odpowiedzi na żądania – te powinny wynikać z obowiązujących przepisów i polityki wewnętrznej restauracji, ustalonej z prawnikiem.
Gdzie w tym procesie może pojawić się ChefNet
ChefNet rozwija produkty związane z odkrywaniem restauracji i operacjami gastronomicznymi, w tym elementy dotyczące zarządzania danymi rezerwacyjnymi. Jeśli restauracja korzysta z systemu opartego na ChefNet lub rozważa jego wdrożenie, warto samodzielnie zweryfikować, które konkretne funkcje związane z obsługą żądań usunięcia danych są obecnie dostępne w danym momencie, ponieważ zakres funkcji produktu może się zmieniać w miarę jego rozwoju. Ten artykuł opisuje ogólny proces operacyjny, niezależny od konkretnego dostawcy technologii.
Przypadki brzegowe, których podstawowy model nie obejmuje
Model W-O-D-Z opisuje sytuację standardową – jeden gość, jedna rezerwacja, jasny zakres żądania. W praktyce operacyjnej pojawiają się warianty, które wymagają dodatkowej decyzji przed przejściem do etapu działania w systemach.
Rezerwacja z wieloma gośćmi
Gdy rezerwacja obejmuje kilka osób, a żądanie usunięcia pochodzi tylko od jednej z nich, restauracja powinna rozgraniczyć dane, które dotyczą wyłącznie osoby składającej żądanie (np. jej adres e-mail, preferencje), od danych współdzielonych z resztą rezerwacji (np. nazwa rezerwującego, liczba osób, godzina). Usunięcie danych jednej osoby nie powinno automatycznie usuwać zapisu całej rezerwacji, jeśli inni goście z niej nie zgłosili takiego żądania.
Dane pochodzące z platform zewnętrznych
Jeśli rezerwacja wpłynęła przez platformę rezerwacyjną, agregator lub media społecznościowe, restauracja może przechowywać jedynie kopię danych, których pierwotnym administratorem lub źródłem jest inny podmiot. W takim przypadku warto ustalić w procedurze wewnętrznej, czy żądanie obsługuje sama restauracja w zakresie swoich systemów, czy gość powinien zostać poinformowany, że część danych znajduje się także u dostawcy platformy i wymaga osobnego zgłoszenia.
Żądanie niemożliwe do zweryfikowania
Nie każde żądanie da się jednoznacznie zweryfikować – na przykład gdy przychodzi z adresu e-mail innego niż ten użyty przy rezerwacji, albo telefonicznie bez możliwości potwierdzenia tożsamości. W takiej sytuacji procedura powinna przewidywać krok pośredni: prośbę o dodatkowe potwierdzenie, a nie automatyczne usunięcie lub automatyczną odmowę. Odmowa działania bez próby weryfikacji alternatywną drogą jest tak samo ryzykowna operacyjnie jak usunięcie danych bez weryfikacji.
Dane związane z aktywną rezerwacją lub bezpieczeństwem gościa
Informacje o alergiach lub nietolerancjach pokarmowych powiązane z nadchodzącą, niezrealizowaną jeszcze rezerwacją stanowią odrębny przypadek – ich usunięcie przed wizytą może wpływać na bezpieczeństwo obsługi. Warto rozstrzygnąć z gościem, czy chce usunięcia tych danych po zakończeniu wizyty, czy natychmiast, rozumiejąc konsekwencje dla obsługi rezerwacji, która jeszcze się nie odbyła.
Rozszerzony harmonogram odpowiedzi – checklist wewnętrzny
Poniższy harmonogram nie wyznacza terminów prawnych – te ustala się z prawnikiem – lecz proponuje wewnętrzne punkty kontrolne, które pomagają monitorować status żądania od wpływu do zamknięcia.
| Punkt kontrolny | Co sprawdzić | Kto potwierdza |
|---|---|---|
| Wpływ żądania | Data, kanał, zakres żądania zapisany w rejestrze | Osoba przyjmująca żądanie |
| Weryfikacja tożsamości | Czy tożsamość potwierdzona, czy wymaga dodatkowego kroku | Osoba odpowiedzialna za dane |
| Przegląd wyjątków | Czy istnieje otwarty cel przetwarzania (np. nierozliczona płatność) | Osoba odpowiedzialna / dział finansowy |
| Działanie w systemach | Lista systemów sprawdzonych i status w każdym z nich | Osoba wykonująca działanie techniczne |
| Zamknięcie | Informacja do gościa i wpis do rejestru wewnętrznego | Osoba odpowiedzialna za dane |
Ograniczenia pomiaru i dokumentacji
Zasady integralności, poufności oraz rozliczalności, opisane wśród ogólnych zasad ochrony danych Komisji Europejskiej, wskazują na potrzebę odpowiedniego zabezpieczenia danych oraz zdolności do wykazania, że decyzje o zachowaniu lub usunięciu danych zostały podjęte świadomie. W praktyce oznacza to, że sam rejestr żądań nie jest celem – jest dowodem, że decyzja o wyjątku (lub jego braku) była udokumentowana w momencie jej podjęcia, a nie zrekonstruowana później.
Warto też pamiętać, że przywrócenie danych z kopii zapasowej po incydencie technicznym może ponownie ujawnić dane wcześniej usunięte na żądanie gościa – to ograniczenie techniczne, które procedura wewnętrzna powinna uwzględniać, ustalając z dostawcą systemu, jak backupy są traktowane w kontekście takich żądań.
Źródła pierwotne
FAQ
Czy restauracja musi usunąć dane gościa natychmiast po otrzymaniu prośby?
Nie zawsze natychmiast i nie zawsze w całości. Część danych może być powiązana z bieżącym, uzasadnionym celem, na przykład nieuregulowaną fakturą lub zaplanowaną rezerwacją, a przepisy dotyczące dokumentacji finansowej lub prawnej mogą wymagać przechowywania niektórych rekordów przez określony czas. Przed zamknięciem żądania operator powinien potwierdzić ewentualne wyjątki z prawnikiem.
Co oznacza zasada minimalizacji celu w odniesieniu do rekordu rezerwacji?
Zasada minimalizacji celu, opisana w zasadach ochrony danych Komisji Europejskiej, oznacza, że dane osobowe powinny być zbierane i wykorzystywane tylko w konkretnym celu wskazanym w momencie ich gromadzenia. W przypadku rezerwacji celem jest zwykle obsługa wizyty gościa, a nie bezterminowe wykorzystanie danych do marketingu, jeśli gość nie wyraził na to odrębnej zgody.
Jak długo restauracja może przechowywać historię rezerwacji usuniętego gościa?
Zasady Komisji Europejskiej opisują ograniczenie przechowywania jako trzymanie danych osobowych nie dłużej, niż jest to niezbędne dla celu, dla którego zostały zebrane, ale nie wskazują jednej liczby dni obowiązującej dla wszystkich restauracji. Okres retencji zależy od konkretnego celu, przepisów krajowych oraz zasad dokumentacji finansowej lub sanitarnej, dlatego dokładne terminy warto potwierdzić z prawnikiem.
Nota redakcyjna: ChefNet publikuje ten przewodnik i rozwija produkty wspierające odkrywanie restauracji oraz ich działalność. Ogólne zalecenia operacyjne są oddzielone od twierdzeń o produkcie. Funkcje mogą się zmieniać wraz z rozwojem pilotaży. Opublikowano 2026-08-12.