RODO a SaaS, czyje są dane klientów na Booking i ZnanyLekarz

Część przewodnika: Własne systemy zamiast SaaS, kompletny przewodnik 2026 →
Ten artykuł skupia się na ochronie danych i bezpiecznym wyjściu z usługi.

Ważne: to materiał informacyjny, nie porada prawna. Role i obowiązki zależą od konkretnej usługi, umów, konfiguracji oraz danych. Przy danych zdrowotnych, monitorowaniu osób, profilowaniu lub transferach międzynarodowych skonsultuj wdrożenie z prawnikiem albo inspektorem ochrony danych.

Pytanie „czyje są dane?” brzmi prosto, ale prowadzi na skróty. RODO nie tworzy ogólnego prawa własności do danych osobowych. Rozdziela role i obowiązki: kto ustala cele oraz sposoby przetwarzania, kto wykonuje operacje w cudzym imieniu, na jakiej podstawie i z jakimi zabezpieczeniami.

To dlatego sama nazwa platformy nie wystarcza do oceny. Booking, Booksy, system medyczny albo narzędzie do rezerwacji mogą pełnić różne role w różnych procesach. Trzeba przeczytać umowę i sprawdzić, co faktycznie dzieje się z danymi.

Administrator, procesor i niezależny administrator

Administrator ustala cele i sposoby przetwarzania danych osobowych. Jeżeli salon zbiera imię i telefon, by umawiać własnych klientów, zwykle to salon decyduje po co dane są potrzebne i jak długo je przechowuje.

Procesor, po polsku podmiot przetwarzający, przetwarza dane w imieniu administratora i według jego udokumentowanych instrukcji. Dostawca systemu rezerwacji może pełnić tę rolę dla bazy klientów salonu.

Ten sam dostawca może równocześnie działać jako niezależny administrator w innym celu, na przykład przy prowadzeniu konta, zapobieganiu nadużyciom albo świadczeniu własnej usługi marketplace. W określonych okolicznościach mogą też pojawić się współadministratorzy.

Wytyczne EDPB 07/2020 podkreślają funkcjonalny charakter ról. Liczy się rzeczywisty wpływ na cele i zasadnicze sposoby przetwarzania, a nie nazwa wpisana przez handlowca do prezentacji.

Prosty test dla każdego przepływu

Przygotuj tabelę i przejdź osobno przez rezerwację, płatność, wiadomości, marketing, analitykę oraz wsparcie:

Pytanie	Co ustalić
Kto decyduje o celu?	firma, dostawca czy obie strony
Kto wybiera zakres danych?	pola obowiązkowe, historia, notatki, pliki
Czy dostawca używa danych do własnych celów?	analityka produktu, reklama, rozwój usługi
Kto odpowiada osobie, której dane dotyczą?	dostęp, sprostowanie, usunięcie, sprzeciw
Co dzieje się po rozwiązaniu umowy?	eksport, okres dostępu, usunięcie, backupy

Jedno zdanie „SaaS jest procesorem” nie zastępuje tej analizy. Niektóre platformy opisują role w kilku dokumentach: regulaminie, DPA, polityce prywatności i wykazie podprocesorów. Osobnej oceny wymaga również bramka płatności podłączona do strony, bo uczestniczy w innym przepływie niż kalendarz rezerwacji.

Umowa powierzenia z art. 28 RODO

Jeżeli dostawca działa jako procesor, potrzebna jest umowa lub inny instrument prawny spełniający art. 28 RODO. Często nazywa się go DPA, Data Processing Agreement, albo umową powierzenia przetwarzania danych osobowych.

Umowa powinna określać co najmniej:

• przedmiot, czas, charakter i cel przetwarzania;
• rodzaje danych oraz kategorie osób;
• prawa i obowiązki administratora;
• przetwarzanie wyłącznie na udokumentowane polecenie;
• poufność osób dopuszczonych do danych;
• środki bezpieczeństwa i pomoc przy obowiązkach administratora;
• warunki korzystania z podprocesorów;
• pomoc przy prawach osób, naruszeniach i ocenach ryzyka;
• zwrot lub usunięcie danych po zakończeniu usługi;
• informacje i audyty pozwalające wykazać zgodność.

Nie wystarczy pobrać PDF i schować go do folderu. Administrator ma wybrać podmiot dający wystarczające gwarancje oraz nadzorować go w trakcie współpracy. UODO wyjaśnia to wprost w odpowiedzi czy administrator musi kontrolować procesora.

Zakres kontroli powinien być proporcjonalny do ryzyka. Przy prostym newsletterze może wystarczyć analiza dokumentacji i certyfikatów. System przechowujący dokumentację zdrowotną, numery PESEL lub duże zbiory wymaga głębszej oceny i często konsultacji specjalisty.

Podprocesorzy: dostawcy stojący za dostawcą

SaaS rzadko działa sam. Korzysta z hostingu, poczty, monitoringu błędów, obsługi klienta, płatności lub narzędzi analitycznych. Część tych firm może być podprocesorami.

Art. 28 wymaga uprzedniej szczegółowej albo ogólnej pisemnej zgody administratora na kolejnych procesorów. Przy zgodzie ogólnej procesor powinien informować o planowanych zmianach i umożliwić sprzeciw. Na podprocesora trzeba nałożyć zasadniczo te same obowiązki ochrony danych, a pierwszy procesor pozostaje odpowiedzialny wobec administratora za wykonanie tych obowiązków.

W praktyce sprawdź:

• aktualny wykaz podprocesorów i datę jego aktualizacji;
• kraj podmiotu i miejsca, z których może uzyskać dostęp;
• funkcję, jaką wykonuje;
• sposób informowania o zmianach;
• termin oraz skutki sprzeciwu;
• czy lista obejmuje wsparcie techniczne i podmioty z grupy kapitałowej.

Region hostingu to za mało. Baza może leżeć w Niemczech, a zespół wsparcia albo podprocesor uzyskiwać dostęp z państwa trzeciego.

Transfery danych poza EOG

Transfer poza Europejski Obszar Gospodarczy nie oznacza automatycznie naruszenia ani obowiązku zebrania zgód od wszystkich klientów. Trzeba wskazać mechanizm z rozdziału V RODO i sprawdzić, czy zapewnia on wymagany poziom ochrony.

Możliwe mechanizmy obejmują między innymi:

• decyzję Komisji Europejskiej stwierdzającą odpowiedni stopień ochrony;
• odpowiednie zabezpieczenia z art. 46, w tym standardowe klauzule umowne;
• wiążące reguły korporacyjne w grupach przedsiębiorstw;
• wyjątki z art. 49 w szczególnych sytuacjach.

SCC nie są tym samym co DPA. Umowa powierzenia reguluje relację administrator–procesor, a klauzule transferowe zabezpieczają określony przepływ do państwa trzeciego. Czasem potrzebne są oba dokumenty.

Po wyroku Schrems II samo podpisanie SCC może nie wystarczyć. Zalecenia EDPB 01/2020 opisują ocenę prawa i praktyk państwa odbiorcy oraz ewentualne środki uzupełniające. To obszar, w którym ogólny artykuł nie zastąpi analizy konkretnego transferu.

Zgoda osoby z art. 49 jest wyjątkiem obwarowanym warunkami. Nie należy przedstawiać jej jako domyślnego rozwiązania dla stałego działania firmowego SaaS.

Kto odpowiada za naruszenie

Nie jest prawdą, że po każdym incydencie „karę zawsze płaci klient SaaS”. Administrator i procesor mają własne obowiązki i każda strona może odpowiadać za swoje naruszenia.

Procesor ma zgłosić administratorowi naruszenie bez zbędnej zwłoki po jego stwierdzeniu. Administrator dokumentuje zdarzenie, ocenia ryzyko i, jeśli naruszenie może powodować ryzyko dla praw lub wolności osób, zgłasza je organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od stwierdzenia.

Jeżeli ryzyko jest mało prawdopodobne, art. 33 przewiduje wyjątek od zgłoszenia organowi. Powiadomienie osób z art. 34 jest wymagane co do zasady przy wysokim ryzyku, z uwzględnieniem wyjątków. Nie wolno więc automatycznie wysyłać każdemu klientowi wiadomości o każdym błędzie technicznym ani równie automatycznie ukrywać incydentu.

UODO opisało sprawę, w której oceniano obowiązki obu stron po nieprawidłowym udostępnieniu bazy. Materiał „Za proces przetwarzania odpowiada administrator oraz podmiot przetwarzający” dobrze pokazuje, dlaczego nadzór administratora nie usuwa odpowiedzialności procesora, a błąd procesora nie zwalnia administratora z doboru i kontroli dostawcy.

Plan reagowania powinien wskazywać osoby kontaktowe, kanał zgłoszeń, zakres informacji od procesora, sposób oceny ryzyka i prowadzenia dokumentacji. Termin 72 godzin nie jest czasem na rozpoczęcie czytania umowy.

Eksport danych to coś więcej niż przycisk CSV

„Możesz pobrać CSV” nie oznacza jeszcze łatwego wyjścia. Plik może pomijać załączniki, historię zmian, relacje między rekordami, zgody, logi, identyfikatory i ustawienia. Własne nazwy kolumn też niewiele dają, jeśli nie ma dokumentacji formatu.

Przed podpisaniem umowy lub najpóźniej przed odnowieniem sprawdź:

1. jakie zbiory obejmuje eksport;
2. czy zawiera pliki, metadane i relacje;
3. w jakim formacie i kodowaniu jest dostarczany;
4. ile trwa przygotowanie eksportu i czy jest płatny;
5. jak długo konto pozostaje dostępne po wypowiedzeniu;
6. czy można wykonać próbny import do innego systemu;
7. jak odzyskać dane przy awarii lub sporze.

Prawo osoby do przenoszenia danych z art. 20 RODO nie jest tym samym co firmowy eksport całej bazy. Pierwsze dotyczy danych osobowych dostarczonych przez konkretną osobę i ma określone warunki. Drugie powinno wynikać również z umowy, architektury i planu ciągłości działania.

Praktyczną procedurę przejścia opisuje artykuł migracja z SaaS na własny system.

Usunięcie, retencja i kopie zapasowe

Administrator powinien ustalić okresy przechowywania na podstawie celów, podstaw prawnych i obowiązków branżowych. „Trzymamy wszystko, bo może się przydać” nie spełnia zasady ograniczenia przechowywania.

Umowa i konfiguracja powinny rozróżniać:

• dane aktywne;
• konta zawieszone i rekordy archiwalne;
• logi bezpieczeństwa oraz audytowe;
• kopie zapasowe;
• dane objęte obowiązkiem zachowania;
• materiały w systemach wsparcia i zgłoszeniach.

Usunięcie z ekranu użytkownika nie musi usuwać rekordu z backupu. Ustal cykl nadpisywania kopii, dostęp do nich, szyfrowanie, procedurę odtworzenia i sposób postępowania, jeśli przywrócona kopia zawiera dane wcześniej usunięte. Po zakończeniu umowy art. 28 przewiduje zwrot lub usunięcie danych zgodnie z decyzją administratora, chyba że prawo nakazuje dalsze przechowywanie.

Prawo do usunięcia danych z art. 17 nie jest bezwzględne. Mogą istnieć podstawy do dalszego przetwarzania, na przykład obowiązek prawny albo potrzeba ustalenia, dochodzenia lub obrony roszczeń. Dlatego system potrzebuje procedury oceny wniosku, a nie przycisku kasującego wszystko bez śladu. Podstawowe obowiązki informacyjne opisuje poradnik RODO na stronie firmowej.

Bezpieczeństwo i backup

Art. 32 wymaga środków odpowiednich do ryzyka. RODO nie narzuca jednej listy technologii dla każdej firmy. Wymienia między innymi poufność, integralność, dostępność, odporność systemów, możliwość szybkiego odtworzenia oraz regularne testowanie skuteczności zabezpieczeń.

W audycie SaaS zapytaj o:

• uwierzytelnianie wieloskładnikowe i role użytkowników;
• szyfrowanie transmisji oraz zarządzanie kluczami;
• logi administracyjne i alerty;
• testy podatności, aktualizacje oraz obsługę incydentów;
• częstotliwość backupu, retencję i testy odtwarzania;
• deklarowane RPO i RTO, jeśli ciągłość jest ważna;
• procedurę odbierania dostępu pracownikom;
• certyfikaty i raporty z audytów wraz z ich zakresem.

Certyfikat nie zastępuje oceny. Trzeba sprawdzić, czego dotyczy, jakie systemy obejmuje i do kiedy jest ważny. Podobnie hasło „szyfrowanie danych” nie mówi, czy dostawca może je odszyfrować i kto zarządza kluczami.

Czy własny system upraszcza RODO

Własny system może zwiększyć kontrolę nad eksportem, funkcjami, retencją i dostawcami. Pozwala też zaprojektować uprawnienia oraz logi pod konkretny proces. Nie usuwa jednak obowiązków administratora. Wcześniej warto oddzielić rzeczywiste ryzyko wyjścia od marketingowych uproszczeń o uzależnieniu firmy od SaaS.

Firma nadal może korzystać z hostingu, poczty, SMS-ów, płatności, monitoringu i wsparcia technicznego. Te podmioty trzeba sklasyfikować i objąć właściwymi umowami. Ktoś musi aktualizować oprogramowanie, odbierać dostępy, testować backupy, analizować alerty i reagować na incydenty.

Serwer w Polsce nie daje „RODO z automatu”. Może ograniczyć niektóre transfery, lecz błędne uprawnienia, brak retencji albo nieprzetestowany backup pozostają problemem. Z drugiej strony dobrze skonfigurowany SaaS bywa bezpieczniejszy niż własna aplikacja bez stałej opieki.

Przed decyzją porównaj oba warianty w kontekście procesu. Pomocne są artykuły własny CRM dla małej firmy oraz ile kosztuje system rezerwacji online.

Ile kosztuje własny system w Lokal360

Aktualne ceny bazowe są pobierane bezpośrednio ze źródła cen projektu:

Wariant	Cena bazowa	Przykładowy zakres
Mini	3 999 zł netto	prosty proces dla jednej małej firmy
Standard	5 999 zł netto	bardziej rozbudowane rezerwacje i płatności
Pro	8 999 zł netto	wiele kategorii lub zasobów
Custom	14 999 zł netto	dedykowane procesy, CRM i integracje

Cena wdrożenia nie obejmuje automatycznie analizy prawnej ani gwarancji zgodności z RODO. Zakres powinien jasno opisywać hosting, utrzymanie, backup, reagowanie na incydenty, eksport i odpowiedzialność za dokumentację. Aktualne warianty znajdziesz na stronie własne systemy Lokal360.

Plan audytu SaaS w 12 krokach

1. Spisz procesy i kategorie danych, nie tylko nazwy aplikacji.
2. Ustal role stron dla każdego celu.
3. Zbierz regulamin, DPA, politykę prywatności i listę podprocesorów.
4. Sprawdź podstawy prawne i obowiązki informacyjne.
5. Zmapuj lokalizacje, zdalny dostęp i transfery poza EOG.
6. Oceń mechanizmy transferowe i środki uzupełniające.
7. Porównaj retencję w umowie z własną polityką firmy.
8. Sprawdź uprawnienia, MFA, logi i procedurę odbierania dostępu.
9. Poproś o informacje o backupach oraz testach odtwarzania.
10. Wykonaj próbny eksport i sprawdź kompletność.
11. Przejrzyj procedurę naruszeń i dane kontaktowe dostawcy.
12. Napisz plan wyjścia z terminami, właścicielami zadań i kryteriami odbioru.

Audyt nie powinien kończyć się oceną „zgodne/niezgodne” bez dowodów. Zapisz dokument, datę, wersję i wniosek. Powtarzaj przegląd po zmianie istotnego podprocesora, funkcji, kraju przetwarzania albo zakresu danych.

Exit plan: jak odejść bez utraty kontroli

Plan wyjścia powinien powstać przed migracją, najlepiej jeszcze przy wyborze usługi. Ustal minimalny okres nakładania się systemów, odpowiedzialność za mapowanie danych i sposób potwierdzenia kompletności.

Przed zakończeniem SaaS:

• wykonaj pełny eksport i zachowaj sumy kontrolne plików;
• porównaj liczbę klientów, rezerwacji, załączników i zgód;
• przeprowadź próbny import oraz testy funkcji;
• zabezpiecz wymagane logi i dokumentację rozliczalności;
• odbierz tokeny API i konta integracji;
• ustal datę blokady zmian w starym systemie;
• poproś o potwierdzenie usunięcia zgodnie z umową;
• zachowaj dokumenty, które trzeba przechowywać prawnie.

Plan cofnięcia powinien opisywać, co zrobić, jeśli import jest niekompletny albo nowy system nie obsługuje krytycznej funkcji. Nie kasuj starego środowiska przed odbiorem danych i testem backupu nowego rozwiązania.

Często zadawane pytania

Kto jest administratorem danych klientów w systemie SaaS?

Najczęściej firma korzystająca z systemu jest administratorem danych przetwarzanych dla własnych celów, a dostawca działa jako procesor. Nie jest to jednak reguła dla każdej funkcji. Platforma może być niezależnym administratorem danych konta, płatności lub własnej usługi. Role ustala się na podstawie faktycznych celów i sposobów przetwarzania.

Czy dostawca SaaS jest właścicielem danych klientów?

RODO nie opiera obowiązków na pojęciu własności danych osobowych. Ważne są role, cele, podstawa prawna i zakres kontroli. Umowa powinna osobno określać prawa do danych biznesowych, możliwość eksportu, retencję, usunięcie po zakończeniu usługi oraz korzystanie z danych przez dostawcę.

Kiedy potrzebna jest umowa powierzenia danych?

Umowa z art. 28 RODO jest potrzebna, gdy dostawca przetwarza dane osobowe w imieniu administratora. Powinna określać między innymi instrukcje, poufność, bezpieczeństwo, podprocesorów, pomoc w realizacji praw osób, obsługę naruszeń, zwrot lub usunięcie danych oraz audyty.

Czy transfer danych do USA wymaga zgody klientów?

Nie zawsze. Transfer poza EOG musi mieć podstawę z rozdziału V RODO, na przykład decyzję stwierdzającą odpowiedni stopień ochrony albo odpowiednie zabezpieczenia, takie jak SCC. Zgoda z art. 49 jest jednym z wyjątków i nie powinna być automatycznym rozwiązaniem dla regularnych transferów.

Kto odpowiada po naruszeniu u dostawcy SaaS?

Procesor ma powiadomić administratora bez zbędnej zwłoki. Administrator ocenia ryzyko i zgłasza naruszenie organowi, jeżeli może ono powodować ryzyko naruszenia praw lub wolności osób; termin wynosi w miarę możliwości 72 godziny od stwierdzenia naruszenia. Każda strona może odpowiadać za własne naruszenia obowiązków.

Czy własny system automatycznie zapewnia zgodność z RODO?

Nie. Własny system może zwiększyć kontrolę, ale firma nadal musi określić cele, podstawy prawne, retencję, uprawnienia, bezpieczeństwo, obsługę praw osób i naruszeń. Hosting, poczta, SMS-y, płatności lub wsparcie techniczne mogą nadal być procesorami albo podprocesorami.

Co sprawdzić przed rezygnacją z SaaS?

Przetestuj pełny eksport wraz z załącznikami i metadanymi, ustal format, termin dostępu po rozwiązaniu umowy, zasady usunięcia kopii produkcyjnych i backupów oraz możliwość potwierdzenia usunięcia. Przygotuj mapę integracji, kopię konfiguracji, migrację użytkowników i plan wycofania.

---

Ten artykuł zawiera informacje ogólne i nie stanowi porady prawnej. Konkretne role, obowiązki i dokumenty wymagają oceny danego procesu przez prawnika lub specjalistę ochrony danych.