Dokumentacja RODO dla SaaS — kompletny przewodnik dla dostawców – Audyt i Wdrożenie RODO | Obsługa RODO dla Firm

Spis treści:

Dostawcy rozwiązań SaaS działają w specyficznej roli — są jednocześnie administratorem danych swoich własnych Klientów (użytkowników platformy, pracowników) i podmiotem przetwarzającym dla danych, które ich Klienci przechowują w aplikacji. Ta podwójna rola wymaga dokumentacji RODO istotnie bogatszej niż w przypadku typowej organizacji. W naszej praktyce jako Certyfikowanego Inspektora Ochrony Danych widzimy, że to właśnie dostawcy SaaS najczęściej potrzebują wsparcia w porządkowaniu dokumentacji — zwłaszcza gdy ich produkt zaczyna wchodzić do większych Klientów korporacyjnych, którzy w procedurze zakupowej wymagają pełnego pakietu zgodnościowego.

W niniejszym artykule przeprowadzimy Państwa przez kompletny zestaw dokumentów, które powinna posiadać firma oferująca oprogramowanie w modelu SaaS — od polityki prywatności i umowy powierzenia (DPA), przez rejestr czynności przetwarzania w roli procesora, listę podprocesorów, wykaz środków technicznych i organizacyjnych (TOM), po oceny skutków (DPIA) oraz dokumentację transferów międzynarodowych. Artykuł jest komplementarny względem naszego przewodnika o wdrożeniu RODO w IT.

Specyfika SaaS — dlaczego standardowa dokumentacja RODO nie wystarczy

Kiedy dostawca SaaS zgłasza się do nas po dokumentację, pierwszym pytaniem, które zadajemy, jest: czy Państwa Klient korporacyjny poprosił Państwa o konkretne dokumenty. Odpowiedź zwykle brzmi: tak, lista na dwie strony A4. I rzeczywiście — profesjonalne działy zakupów w dużych firmach mają gotowe listy pytań i dokumentów wymaganych od dostawcy. Brak któregokolwiek elementu oznacza najczęściej nieprzejście weryfikacji i odpadnięcie z procesu.

Kluczowa różnica między typową firmą usługową a dostawcą SaaS polega na tym, że dostawca SaaS jest odpowiedzialny za dane tysięcy osób, których nigdy nie widział na oczy — użytkowników Klientów, ich pracowników, ich Klientów końcowych. Skala ryzyka jest nieporównanie większa, bo jeden incydent w SaaS może dotknąć setek tysięcy osób w jednym ruchu. Dlatego zarówno organy nadzorcze, jak i Klienci korporacyjni, oczekują od dostawców SaaS znacznie wyższego poziomu dojrzałości compliance niż od przeciętnej firmy usługowej.

Druga specyfika to architektura multi-tenant. Wielu Klientów współdzieli tę samą instancję aplikacji, te same serwery baz danych, ten sam kod źródłowy. Z perspektywy RODO rodzi to szczególne wymagania dotyczące separacji danych, kontroli dostępu i możliwości wykonania operacji (usunięcia, eksportu) dla jednego Klienta bez wpływu na pozostałych. Szerzej o tym w dalszej części artykułu.

Trzecia specyfika — łańcuch podprocesorów. Żaden SaaS nie działa sam. Korzysta z hostingu (AWS, Azure, GCP), usług obserwowalności (Datadog, Sentry), płatności (Stripe, Adyen), poczty transakcyjnej (SendGrid, Postmark), narzędzi CRM (HubSpot, Salesforce). Każdy z tych dostawców jest w łańcuchu przetwarzania i musi zostać ujawniony Klientom jako podprocesor.

Dokumenty must-have dla dostawcy SaaS

Standardowy pakiet dokumentów RODO, który rekomendujemy każdemu dostawcy SaaS wchodzącemu w segment B2B, obejmuje jedenaście pozycji. Poniżej opisujemy każdy z nich krótko; najważniejszym czterem poświęciliśmy osobne sekcje w dalszej części artykułu.

Polityka prywatności (publiczna, na stronie produktu) — opisująca przetwarzanie w roli administratora względem użytkowników platformy.
Umowa powierzenia przetwarzania (DPA) — wzorcowa umowa gotowa do podpisu z Klientami, zawierająca wszystkie elementy z art. 28 ust. 3 RODO.
Rejestr czynności przetwarzania w roli administratora (art. 30 ust. 1 RODO).
Rejestr kategorii czynności przetwarzania w roli podmiotu przetwarzającego (art. 30 ust. 2 RODO).
Wykaz środków technicznych i organizacyjnych (TOM) — szczegółowy opis środków bezpieczeństwa, często jako załącznik do DPA.
Lista podprocesorów — aktualna, publikowana publicznie lub udostępniana Klientom na żądanie, z mechanizmem notyfikacji zmian.
Dokumentacja transferów międzynarodowych — SCC, ocena transferu (TIA), wskazanie mechanizmu zabezpieczającego dla każdego transferu do państwa trzeciego.
Procedura obsługi żądań osób — jak Klient i użytkownik końcowy mogą zgłosić żądanie i w jakim terminie zostanie ono zrealizowane.
Procedura reagowania na incydenty bezpieczeństwa — w szczególności zgodna z 72-godzinnym terminem z art. 33 RODO.
Polityka retencji danych — dla każdej kategorii danych i dla różnych statusów Klienta (aktywny, rozwiązana umowa, etap grace period).
DPIA dla kluczowych funkcjonalności wysokiego ryzyka.

Dla organizacji, które dopiero rozpoczynają budowę dokumentacji, polecamy nasz podstawowy przewodnik po audycie RODO krok po kroku — daje on punkt wyjścia do zbudowania całego pakietu.

Polityka prywatności SaaS — na co zwrócić uwagę

Polityka prywatności dostawcy SaaS to dokument, który pełni dwie funkcje: prawną (klauzula informacyjna w rozumieniu art. 13 i 14 RODO) oraz marketingową (sygnał dla Klientów, że organizacja poważnie traktuje ochronę danych). W praktyce spotykamy trzy typy polityk, które nie spełniają wymogów: polityki skopiowane z generatora, polityki opisujące wszystkie możliwe przetwarzania „na wszelki wypadek” oraz polityki, które są prawidłowe dla użytkowników strony, ale pomijają specyfikę rejestracji i korzystania z platformy.

Dobra polityka prywatności dostawcy SaaS wyróżnia trzy obszary przetwarzania: (1) dane osób odwiedzających stronę produktową (cookies, formularze kontaktowe, newsletter), (2) dane Klientów i ich osób kontaktowych (zawieranie umów, fakturowanie, obsługa), (3) dane użytkowników końcowych platformy, z wyraźnym zaznaczeniem, że w tym zakresie dostawca działa jako podmiot przetwarzający w imieniu Klienta. Ten czwarty element jest kluczowy — bo określa granicę odpowiedzialności dostawcy względem użytkowników, z którymi nie ma bezpośredniego stosunku umownego.

Dla każdego z tych trzech obszarów polityka musi precyzyjnie wskazać: cele przetwarzania, podstawy prawne, okresy retencji, kategorie odbiorców (ze wskazaniem podprocesorów i ich lokalizacji), transfery międzynarodowe z mechanizmem zabezpieczającym, prawa osób i sposoby ich realizacji oraz dane kontaktowe do administratora i — jeśli został wyznaczony — do IOD.

Praktyczna wskazówka: warto udostępnić skrócony „privacy summary” na osobnej stronie (np. /privacy-summary), w formie tabeli, jako uzupełnienie pełnej polityki. Dla Klientów korporacyjnych jest to często wygodniejszy punkt wejścia w ocenę zgodności dostawcy, niż przeklikiwanie się przez kilkanaście stron prawniczego tekstu.

Umowa powierzenia przetwarzania (DPA)

Każdy dostawca SaaS powinien mieć gotową wzorcową umowę powierzenia (DPA — Data Processing Agreement), którą może automatycznie podpisywać z Klientami. Brak takiej umowy — albo udostępnianie Klientowi dopiero na osobne żądanie, po negocjacjach — jest dla Klientów korporacyjnych sygnałem niedojrzałości compliance i często bywa jednym z powodów odrzucenia oferty w procesie zakupowym.

Obowiązkowe elementy DPA wynikające z art. 28 ust. 3 RODO to: przedmiot i czas trwania przetwarzania, charakter i cel, rodzaj danych osobowych i kategorie osób, obowiązki i prawa administratora. Do tego dodatkowo dostawca SaaS powinien zawrzeć: listę podprocesorów (jako załącznik), opis TOM (jako załącznik), procedurę notyfikacji zmian podprocesorów, procedurę pomocy przy realizacji żądań osób, procedurę notyfikacji naruszeń, zasady audytu Klienta u dostawcy oraz mechanizm zwrotu lub usunięcia danych po zakończeniu umowy.

W naszej praktyce DPA dostawcy SaaS ma zwykle 8–15 stron, z czego połowa to załączniki (TOM, lista podprocesorów, opis operacji przetwarzania, SCC dla transferów). Ważne jest, aby DPA było spójne z resztą dokumentacji — sprzeczności między DPA a polityką prywatności czy regulaminem są jednym z pierwszych punktów, które wyłapują prawnicy korporacyjnych Klientów.

Coraz więcej dostawców SaaS udostępnia DPA w formie click-through — Klient akceptuje standardowe DPA przy rejestracji konta lub w panelu administratora. Takie rozwiązanie jest dopuszczalne pod warunkiem, że akceptacja jest udokumentowana (data, godzina, wersja dokumentu, osoba akceptująca) i że Klient ma możliwość pobrania podpisanej cyfrowo kopii.

Rejestr czynności — perspektywa podmiotu przetwarzającego

Art. 30 ust. 2 RODO nakłada na podmioty przetwarzające osobny obowiązek prowadzenia rejestru — innego niż ten, który prowadzi administrator. Rejestr procesora jest prostszy w swej strukturze, ale musi zawierać: dane kontaktowe procesora i podprocesorów, kategorie przetwarzania prowadzone w imieniu każdego administratora, transfery do państw trzecich oraz opis środków technicznych i organizacyjnych.

W przypadku dostawcy SaaS rejestr w roli procesora zwykle opisuje kategorie przetwarzania agregatowo (np. „hosting i udostępnianie platformy XYZ”, „generowanie raportów”, „integracja z systemem płatności”) — nie trzeba wymieniać każdego Klienta osobno. Ważne jest jednak, aby rejestr był aktualizowany przy każdej istotnej zmianie funkcjonalności produktu, która wpływa na sposób przetwarzania danych.

Więcej na temat tego, jak zbudować i utrzymać rejestr czynności — zarówno w roli administratora, jak i procesora — piszemy w szczegółowym przewodniku o rejestrze czynności przetwarzania.

Środki techniczne, podprocesorzy i transfery

Wykaz środków technicznych i organizacyjnych (TOM) to załącznik do DPA, w którym dostawca deklaruje, w jaki sposób technicznie zabezpiecza dane Klientów. Dla dostawcy SaaS standardem branżowym jest TOM zawierający następujące obszary: kontrola dostępu fizycznego do data center (zwykle opisywana przez pryzmat certyfikatów dostawców chmury), kontrola dostępu logicznego (uwierzytelnianie, autoryzacja, MFA, SSO), rozdzielenie środowisk (produkcja / staging / dev), kryptografia (szyfrowanie w spoczynku i w tranzycie, zarządzanie kluczami), ciągłość działania (backup, DR, RTO/RPO), zarządzanie podatnościami (skanowanie, łatanie), bezpieczeństwo kodu (SAST, DAST, SCA, code review), logowanie i monitorowanie, procedury obsługi incydentów oraz szkolenia pracowników.

Lista podprocesorów powinna być publikowana publicznie (najczęściej na dedykowanej stronie /subprocessors lub /trust) i zawierać: nazwę podprocesora, cel wykorzystania, kategorię przetwarzanych danych, lokalizację przetwarzania, mechanizm zabezpieczający w przypadku transferu do państwa trzeciego oraz link do jego własnej polityki prywatności. Dodatkowo — dostawca powinien mieć mechanizm notyfikacji Klientów o planowanych zmianach (dodaniu nowego podprocesora), z terminem pozwalającym Klientowi na wyrażenie sprzeciwu — zwykle 30 dni.

Transfery międzynarodowe wymagają oddzielnej dokumentacji. Dla każdego podprocesora spoza EOG dostawca SaaS powinien udokumentować: mechanizm zabezpieczający (najczęściej SCC lub Data Privacy Framework dla certyfikowanych podmiotów z USA), ocenę transferu (TIA — Transfer Impact Assessment) oraz ewentualne dodatkowe środki (np. szyfrowanie end-to-end, pseudonimizacja). Temat chmury i transferów omawiamy szerzej w artykule RODO w chmurze.

Kiedy DPIA jest potrzebna w SaaS

Ocena skutków dla ochrony danych (DPIA) nie jest obowiązkowa dla każdej funkcjonalności SaaS, ale istnieje kilka scenariuszy, w których należy ją przeprowadzić obowiązkowo: kiedy produkt przetwarza dane wrażliwe (zdrowotne, biometryczne, dotyczące dzieci), kiedy obejmuje systematyczny monitoring zachowań użytkowników, kiedy wykorzystuje algorytmy AI do podejmowania decyzji wpływających na osoby, kiedy łączy dane z różnych źródeł w celu profilowania. Lista operacji wymagających DPIA opublikowana przez Prezesa UODO zawiera kilkanaście scenariuszy, a orzecznictwo EROD dodaje kolejne.

W naszej praktyce rekomendujemy dostawcom SaaS prowadzenie „uproszczonej DPIA” dla każdej nowej funkcjonalności produktu, niezależnie od tego, czy formalnie przekracza ona próg obowiązku — jako element procesu zarządzania produktem. Pełna DPIA jest wykonywana wtedy, gdy uproszczona ocena wskaże wysokie ryzyko. Kompleksowy przewodnik po metodyce DPIA znajdą Państwo w naszym artykule o DPIA — ocenie skutków dla ochrony danych.

Multi-tenant a separacja danych

Architektura multi-tenant jest normą w rozwiązaniach SaaS — jedna instancja aplikacji obsługuje wielu Klientów. Z perspektywy kosztów i utrzymania jest to model optymalny; z perspektywy RODO niesie ze sobą specyficzne wymagania dotyczące separacji danych. Kluczowe pytanie brzmi: czy jeden Klient może — celowo lub przez błąd — uzyskać dostęp do danych innego Klienta.

Dobre praktyki obejmują: separację danych na poziomie identyfikatora Klienta w każdym zapytaniu do bazy (row-level security), testy automatyczne weryfikujące, że dane jednego Klienta nie są widoczne dla innego, separację logów audytowych, osobne klucze szyfrujące dla Klientów korporacyjnych (BYOK — Bring Your Own Key), możliwość eksportu i trwałego usunięcia wszystkich danych jednego Klienta w operacji, która nie wpływa na pozostałych, oraz dedykowane środowiska (single-tenant) dla Klientów o szczególnych wymaganiach regulacyjnych.

Jeśli Państwa produkt SaaS zamierza wchodzić do sektorów regulowanych — finansowego, medycznego, energetycznego — rekomendujemy wczesne zaprojektowanie architektury z myślą o tych wymaganiach. Dostosowanie istniejącej architektury multi-tenant do wymogów sektora regulowanego jest zwykle dużo kosztowniejsze niż uwzględnienie ich od początku.

FAQ

Czy polityka prywatności w języku angielskim jest wystarczająca dla polskich Klientów?
Nie. RODO wymaga, aby informacje były przekazywane w „zwięzłej, przejrzystej, zrozumiałej i łatwo dostępnej formie” — co w praktyce oznacza język zrozumiały dla osoby, której dane dotyczą. Dla polskich użytkowników oznacza to polską wersję językową polityki prywatności. Dla platform międzynarodowych polecamy publikację wersji angielskiej jako wiodącej i tłumaczeń na języki kluczowych rynków.

Czy możemy mieć jeden DPA dla wszystkich Klientów czy musimy negocjować każdy indywidualnie?
Można i należy mieć jeden wzorcowy DPA, który jest domyślnym załącznikiem do umowy głównej. Negocjowanie DPA z każdym Klientem indywidualnie jest operacyjnie niemożliwe przy większej skali. Klienci korporacyjni czasami chcą dodać własne klauzule — dobrą praktyką jest akceptowanie klauzul, które nie są sprzeczne z treścią wzorcowego DPA i z obowiązującym prawem.

Co jeśli Klient prosi o audyt u nas jako dostawcy?
Dobrą praktyką jest oferowanie Klientom corocznych raportów audytowych (SOC 2, ISO 27001, raport pentestu) w ramach tzw. audit-on-paper, zamiast przyjmowania audytów on-site. Dla większości Klientów raporty te są wystarczające. Dla Klientów z sektorów regulowanych warto przewidzieć w DPA możliwość audytu z odpowiednim wyprzedzeniem i w ograniczonym zakresie.

Ile czasu zajmuje przygotowanie pełnej dokumentacji RODO dla dostawcy SaaS?
W zależności od dojrzałości organizacji — od 4 do 12 tygodni. Dla zespołów, które mają już ISO 27001 i solidne procesy bezpieczeństwa, przygotowanie dokumentacji RODO zajmuje zwykle 4–6 tygodni. Dla organizacji, które nie mają ram bezpieczeństwa i zaczynają od zera, projekt trwa 2–3 miesiące i wymaga równoległej pracy nad procesami i dokumentami.

Podsumowanie

Dokumentacja RODO dla dostawcy SaaS jest bardziej złożona niż dla typowej firmy usługowej, ponieważ musi obsługiwać podwójną rolę (administrator + procesor), specyfikę architektury multi-tenant oraz oczekiwania Klientów korporacyjnych. Jedenaście kluczowych dokumentów opisanych w tym artykule stanowi kompletny pakiet, który pozwala przejść weryfikację w procedurach zakupowych większości korporacji w Polsce i Europie. Jeśli potrzebują Państwo wsparcia w budowie lub rewizji dokumentacji RODO dla swojego produktu SaaS — zapraszamy do kontaktu. Telefon +48 601 211 238, e-mail biuro@doit.biz.pl, szczegółowe zakresy na stronie cennik RODO.

Dokumentacja RODO w procesie zakupowym Klienta korporacyjnego

Z naszej praktyki wynika, że moment, w którym dostawca SaaS zaczyna realnie doceniać wartość uporządkowanej dokumentacji RODO, to pierwszy poważny proces zakupowy w dużej firmie. Polskie korporacje — zwłaszcza banki, ubezpieczyciele, telekomy i energetyka — stosują wystandaryzowane procesy oceny dostawców (vendor risk assessment), w których RODO jest jednym z kluczowych filarów obok cyberbezpieczeństwa i ciągłości działania.

Typowy proces wygląda następująco. W pierwszej fazie Klient wysyła dostawcy kwestionariusz — zwykle Excel na 200–400 pytań, pogrupowanych w kilkanaście kategorii. W obszarze ochrony danych pojawiają się pytania o: rolę dostawcy (administrator/procesor), listę przetwarzanych kategorii danych, lokalizacje przetwarzania, mechanizmy szyfrowania, czas retencji, procedurę reagowania na incydenty, listę podprocesorów, posiadane certyfikaty. Dostawca wypełnia kwestionariusz i załącza dokumenty potwierdzające.

W drugiej fazie zespół ochrony danych Klienta przegląda odpowiedzi i formułuje pytania uzupełniające — zwykle 15–30 pytań, które wymagają uzgodnień wewnątrz organizacji dostawcy. W trzeciej fazie odbywa się spotkanie — często z udziałem IOD Klienta i IOD dostawcy — podczas którego omawia się ryzyka i ewentualne wyjątki. W czwartej fazie podpisywany jest DPA z ewentualnymi negocjowanymi klauzulami dodatkowymi. Cały proces trwa zwykle 4–10 tygodni.

W praktyce oznacza to, że dostawca SaaS, który nie ma przygotowanego pakietu dokumentów, może zostać zablokowany w procesie sprzedażowym nawet na kwartał — samo odpowiadanie na kwestionariusz 400-punktowy ad hoc zajmuje zwykle 3–4 tygodnie, jeśli odpowiedzi trzeba szukać w kilku działach. Dostawca, który ma wszystkie dokumenty przygotowane zawczasu, zamyka tę fazę w ciągu kilku dni. Dla małego dostawcy SaaS walczącego o kontrakt z dużym Klientem ta różnica może decydować o powodzeniu projektu.

W naszych wdrożeniach dla dostawców SaaS dedykowaliśmy zawsze osobny element projektu — przygotowanie „vendor pack”, czyli gotowego zestawu odpowiedzi na standardowe kwestionariusze (CAIQ, SIG, własne kwestionariusze banków), podlinkowanych do aktualnej dokumentacji RODO. Taki pakiet staje się narzędziem sprzedaży, które nie tylko spełnia wymogi regulacyjne, ale też realnie przyspiesza cykl sprzedażowy.

Warto dodać jedno zastrzeżenie praktyczne: dokumentacja RODO dla SaaS nie kończy się na jej utworzeniu. Jest to żywy zestaw dokumentów, który wymaga aktualizacji przy każdej istotnej zmianie — dodaniu nowego podprocesora, migracji do nowej lokalizacji chmurowej, wdrożeniu nowej funkcjonalności przetwarzającej kategorię danych wcześniej niewystępującą w produkcie, zmianie w łańcuchu integracji z systemami partnerskimi. W naszych wdrożeniach rekomendujemy ustanowienie wewnętrznego „change review” RODO — krótkiego (15-minutowego) spotkania z udziałem IOD i product ownera przy każdej zmianie, która może mieć wpływ na przetwarzanie danych. Takie lekkie, cykliczne spotkanie redukuje ryzyko, że dokumentacja się zdezaktualizuje, i jednocześnie nie paraliżuje pracy zespołu produktowego zbędną biurokracją.

Dokumentacja RODO dla SaaS — kompletny przewodnik dla dostawców