Adres IP, logi, zachowania użytkowników — dlaczego Twój produkt SaaS przetwarza dane osobowe, nawet jeśli nie zbierasz imion

Jeśli Twój produkt SaaS rejestruje adresy IP, zapisuje logi sesji lub śledzi aktywność użytkowników na dashboardzie — przetwarza dane osobowe. Nawet jeśli nigdzie w formularzu nie pytasz o imię, nazwisko ani PESEL.

RODO definiuje dane osobowe szeroko: to wszelkie informacje o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej, w tym identyfikatory internetowe. Adres IP, identyfikator cookies, ID sesji — wszystko to wchodzi w zakres definicji z art. 4 pkt 1 RODO. Potwierdził to Trybunał Sprawiedliwości UE w wyroku C-582/14 (sprawa Breyer), a w Polsce — Naczelny Sąd Administracyjny w wyroku I OSK 1079/10.

Dla foundera lub CTO oznacza to jedno: Twoja umowa SaaS musi adresować kwestię danych osobowych od pierwszego dnia. Nie po audycie. Nie przed kontrolą UODO. Od momentu, w którym pierwszy użytkownik loguje się do systemu.

W tym artykule pokażę, kiedy dostawca SaaS staje się administratorem danych, jakie elementy techniczne Twojego produktu generują dane osobowe, czego brakuje w większości umów SaaS i jak wbudować zgodność z RODO w backlog produktowy zamiast w dokumentację tworzoną na ostatnią chwilę.

Dane osobowe w SaaS — co musisz wiedzieć, zanim przejdziesz dalej

Zanim przejdziemy do konkretnych scenariuszy, warto uporządkować kilka pojęć, które będą się pojawiać w całym artykule.

Pojęcie	Znaczenie w kontekście SaaS
Dane osobowe (art. 4 pkt 1 RODO)	Wszelkie informacje o osobie, którą da się zidentyfikować — bezpośrednio lub pośrednio, np. przez adres IP, identyfikator cookies, ID sesji
Administrator danych (art. 4 pkt 7 RODO)	Podmiot, który samodzielnie ustala cele i sposoby przetwarzania danych — decyduje po co i jak dane są zbierane
Podmiot przetwarzający (art. 4 pkt 8 RODO)	Podmiot, który przetwarza dane wyłącznie w imieniu administratora, na jego udokumentowane polecenie
Umowa powierzenia (art. 28 RODO)	Umowa między administratorem a podmiotem przetwarzającym, określająca zakres, cel i zasady przetwarzania danych
Privacy by Design (art. 25 RODO)	Obowiązek uwzględnienia ochrony danych w architekturze produktu od etapu projektowania
Pseudonimizacja (art. 4 pkt 5 RODO)	Przetworzenie danych tak, by nie dało się ich przypisać konkretnej osobie bez dodatkowych informacji — ale dane nadal pozostają danymi osobowymi

Jedna uwaga: motyw 26 RODO nakazuje przy ocenie identyfikowalności brać pod uwagę wszelkie rozsądnie prawdopodobne sposoby identyfikacji — w tym koszty, czas i dostępne technologie. Jeśli Twój system przechowuje adres IP obok ID konta użytkownika, identyfikacja jest nie tylko prawdopodobna — jest trywialna.

Kiedy Twój SaaS staje się administratorem danych — scenariusze z codziennej architektury produktu

Większość dostawców SaaS zakłada, że pełnią wyłącznie rolę podmiotu przetwarzającego — bo to klient decyduje, jakie dane wprowadzają jego użytkownicy. To założenie bywa błędne.

Dostawca SaaS staje się administratorem danych w każdym zakresie, w którym samodzielnie ustala cele przetwarzania. Nie chodzi o nazwę w umowie. Chodzi o to, kto faktycznie podejmuje decyzje.

Kryteria, które przesądzają o statusie administratora

Kryterium	Podmiot przetwarzający	Administrator
Kto decyduje, jakie dane są zbierane	Klient	Dostawca SaaS
Kto ustala okres przechowywania danych	Klient	Dostawca SaaS
Kto wykorzystuje dane do własnych celów analitycznych	Nikt — dane służą wyłącznie klientowi	Dostawca SaaS
Kto łączy dane z wielu klientów	Nikt — dane są izolowane per tenant	Dostawca SaaS
Kto decyduje o obowiązkowych polach formularzy	Klient	Dostawca SaaS

Praktyczne scenariusze

System rekrutacyjny (ATS). Jeżeli dostawca tworzy centralną bazę kandydatów dostępną dla wielu pracodawców lub wykorzystuje dane kandydatów do budowy algorytmów dopasowujących — staje się administratorem. Kandydat może mieć wówczas dwóch administratorów: pracodawcę i dostawcę ATS.

System rejestracji czasu pracy. Jeżeli dostawca przechowuje dane dłużej niż wymagają przepisy prawa pracy — np. w celu tworzenia statystyk sektorowych — staje się administratorem w tej części przetwarzania.

Moduły analityczne i benefitowe. Jeżeli dostawca generuje raporty typu „preferencje benefitowe w sektorze IT” lub „skuteczność programów motywacyjnych” i oferuje je jako samodzielne produkty — staje się administratorem danych, na których te raporty powstają.

Precedens: decyzja UODO w sprawie McDonald’s Polska (DKN.5131.5.2025)

Prezes UODO uznał McDonald’s Polska za administratora danych osobowych pracowników franczyzobiorców, ponieważ spółka określiła funkcjonalność systemu SaaS do zarządzania grafikami pracy oraz zakres gromadzonych danych. Łączna kara: ponad 16,9 mln zł na administratora i ponad 183 tys. zł na podmiot przetwarzający.

Wniosek: projektowanie systemu i decydowanie o jego funkcjonalności może przesądzać o uznaniu właściciela SaaS za administratora danych wszystkich użytkowników. Sama treść umowy SaaS nie zmienia obiektywnego charakteru relacji.

Architektura multi-tenant a status administratora

Jeżeli łączysz dane z różnych tenantów do tworzenia globalnych statystyk, rozwijania nowych funkcjonalności lub benchmarkingów — stajesz się administratorem danych wszystkich użytkowników. Jeżeli dane są przetwarzane wyłącznie w ramach danego tenanta bez łączenia — możesz pozostać podmiotem przetwarzającym.

Ta sama logika dotyczy architektury white-label: jeśli dostawca white-label wykorzystuje dane użytkowników do własnych celów, staje się administratorem — nawet jeśli dla użytkownika końcowego pozostaje „niewidoczny”.

Napisz do nas

IP, cookies, logi sesji — co dokładnie jest daną osobową w Twojej aplikacji webowej

Każda aplikacja webowa generuje dane techniczne przy każdym połączeniu użytkownika. Pytanie nie brzmi „czy zbierasz dane osobowe”, tylko „ile ich zbierasz i czy o tym wiesz”.

Adres IP

Dynamiczny adres IP stanowi daną osobową, jeżeli usługodawca dysponuje środkami prawnymi umożliwiającymi zidentyfikowanie użytkownika — np. poprzez pozyskanie informacji od dostawcy usług internetowych. Tak orzekł TSUE w wyroku C-582/14 (sprawa Breyer). NSA w wyroku I OSK 1079/10 potwierdził: informacją dotyczącą osoby jest zarówno informacja odnosząca się do niej wprost, jak i taka, która odnosi się do urządzeń, ale poprzez możliwość powiązania tych urządzeń z określoną osobą — pośrednio stanowi informację o niej.

UODO traktuje adresy IP analogicznie do numerów PESEL czy numerów rejestracyjnych pojazdów.

Pliki cookies

Motyw 30 RODO wprost wymienia identyfikatory plików cookie jako przykłady identyfikatorów internetowych mogących służyć do tworzenia profili osób fizycznych. UODO potwierdza: identyfikator cookies oraz numer IP przypisane do danego urządzenia jednoznacznie identyfikują w środowisku cyfrowym osobę fizyczną.

Wyrok TSUE C-673/17 (Planet49) przesądził, że zgoda na cookies musi mieć charakter aktywny — domyślnie zaznaczone okienka nie stanowią ważnej zgody.

Logi serwera i logi sesji

Typowe logi serwera HTTP zawierają:

Adres IP użytkownika
Datę i godzinę połączenia
Żądany adres URL
Kod statusu odpowiedzi
Ilość przesłanych danych
Informacje o przeglądarce (user agent)
Identyfikator zalogowanego użytkownika lub identyfikator sesji

Logi sesji dokumentują ciąg działań użytkownika od zalogowania do wylogowania: odwiedzone podstrony, wykonane akcje, czas spędzony na poszczególnych modułach. Zestawienie adresu IP, identyfikatora cookies i logów sesji umożliwia szczegółową rekonstrukcję aktywności konkretnej osoby.

Standardowe konfiguracje serwerów zapisują pełne dane umożliwiające identyfikację — logi serwera nie są z natury anonimowe. Pseudonimizacja (zastąpienie bezpośrednich identyfikatorów losowymi ciągami znaków) redukuje ryzyko, ale dane nadal pozostają danymi osobowymi w rozumieniu RODO.

Obowiązki, które z tego wynikają

Rodzaj danych	Typowa podstawa prawna	Obowiązek informacyjny
Adresy IP i logi sesji (cele bezpieczeństwa)	Prawnie uzasadniony interes administratora (art. 6 ust. 1 lit. f RODO)	Tak — art. 13 RODO
Cookies analityczne / marketingowe	Zgoda użytkownika (art. 6 ust. 1 lit. a RODO)	Tak — art. 13 RODO + aktywna zgoda
Dane behawioralne do profilowania	Zgoda lub uzasadniony interes — zależnie od kontekstu	Tak — art. 13 RODO + informacja o profilowaniu (art. 22)

Wyciek logów serwera zawierających adresy IP i identyfikatory cookies może stanowić naruszenie ochrony danych wymagające zgłoszenia do UODO w ciągu 72 godzin (art. 33 RODO). Jeżeli naruszenie może spowodować wysokie ryzyko — obowiązek poinformowania osób fizycznych (art. 34 RODO).

Czego brakuje w większości umów SaaS: powierzenie danych, role stron, zakres przetwarzania

Art. 28 ust. 3 RODO precyzyjnie określa, co musi zawierać umowa powierzenia przetwarzania danych. Mimo to wiele komercyjnych umów SaaS nie spełnia tych wymagań.

Typowe luki w umowach SaaS

1. Brak jednoznacznego określenia ról stron. Wiele regulaminów SaaS nie deklaruje wprost, że klient jest administratorem, a dostawca podmiotem przetwarzającym. Stosuje się ogólnikowe sformułowania: „przetwarzanie danych zgodnie z polityką prywatności”. Brak refleksji nad możliwością współadministrowania (art. 26 RODO) lub zmiany roli w zależności od modułu.

2. Niedookreślenie zakresu i celu przetwarzania. Umowa powinna wskazywać: jakie kategorie danych są przetwarzane, jakich kategorii osób dotyczą, w jakim celu i przez jaki czas. Ogólnikowe zapisy typu „dane niezbędne do świadczenia usługi” nie spełniają tego wymogu.

3. Brak zasad podpowierzenia. Art. 28 ust. 2 RODO wymaga, by podmiot przetwarzający nie korzystał z usług innego podmiotu przetwarzającego (np. dostawcy chmury, dostawcy narzędzi analitycznych) bez uprzedniej zgody administratora — szczegółowej lub ogólnej. Wiele umów SaaS pomija ten element lub reguluje go zbyt ogólnikowo.

4. Brak procedur zgłaszania naruszeń. Podmiot przetwarzający musi niezwłocznie informować administratora o naruszeniu ochrony danych. Umowa powinna określać: termin, formę i kanał komunikacji. Bez tego zapisu administrator może nie dotrzymać 72-godzinnego terminu na zgłoszenie do UODO.

5. Brak zasad usuwania lub zwrotu danych po zakończeniu umowy. Art. 28 ust. 3 lit. g RODO wymaga, by podmiot przetwarzający po zakończeniu usług usunął lub zwrócił dane — w zależności od decyzji administratora. Wiele umów SaaS nie reguluje procedury eksportu danych ani formatu, w jakim dane zostaną zwrócone.

6. Brak lokalizacji danych. Umowa powinna wskazywać, gdzie dane są przechowywane i czy mogą być przekazywane poza Europejski Obszar Gospodarczy. Wzorzec NASK (umowa EZD RP) wprost zakazuje przekazywania danych poza EOG bez uprzedniej pisemnej zgody administratora.

7. Brak prawa do audytu. Art. 28 ust. 3 lit. h RODO wymaga, by podmiot przetwarzający udostępniał administratorowi informacje niezbędne do wykazania zgodności i umożliwiał audyty. Wiele umów SaaS albo pomija to prawo, albo ogranicza je do rocznego raportu SOC 2.

8. Brak rozgraniczenia odpowiedzialności za bezpieczeństwo. Standardowe umowy SaaS powinny precyzyjnie określać, kto odpowiada za bezpieczeństwo infrastruktury i aplikacji (dostawca), a kto za zarządzanie dostępem użytkowników i ochronę danych logowania (klient). Bez tego podziału obie strony mogą zakładać, że rozgraniczenia odpowiedzialności leży po drugiej stronie.

Decyzja UODO DKN.5112.11.2021 podkreśliła, że zarówno administrator, jak i podmiot przetwarzający są odpowiedzialni za zapewnienie zawarcia prawidłowej umowy powierzenia. Brak umowy lub jej niekompletność obciąża obie strony.

Minimalne elementy umowy powierzenia w SaaS

Element	Wymaganie RODO	Częsty brak w umowach SaaS
Przedmiot i czas trwania przetwarzania	Art. 28 ust. 3	Ogólnikowe sformułowania
Charakter i cel przetwarzania	Art. 28 ust. 3	Brak lub zbyt szerokie określenie
Rodzaj danych i kategorie osób	Art. 28 ust. 3	Brak katalogu danych
Zasady podpowierzenia	Art. 28 ust. 2	Brak lub automatyczna zgoda
Procedura zgłaszania naruszeń	Art. 28 ust. 3 lit. f	Brak terminów i kanałów
Usunięcie/zwrot danych po zakończeniu	Art. 28 ust. 3 lit. g	Brak procedury eksportu
Prawo do audytu	Art. 28 ust. 3 lit. h	Brak lub ograniczenie
Lokalizacja danych	Art. 28 ust. 3	Brak wskazania lokalizacji

Privacy by Design na etapie produktu — jak wbudować zgodność z RODO w backlog

Art. 25 RODO nakłada na administratora obowiązek wdrożenia odpowiednich środków technicznych i organizacyjnych zarówno przy określaniu sposobów przetwarzania, jak i w czasie samego przetwarzania. To nie jest obowiązek dokumentacyjny. To obowiązek architektoniczny.

Co to oznacza dla zespołu produktowego

Privacy by Design wymaga, by ochrona danych była uwzględniana na etapie koncepcyjnym — nie w dokumentacji sporządzanej przed releasem. W praktyce oznacza to wbudowanie wymagań RODO w Definition of Ready (DoR) i Definition of Done (DoD) dla każdego user story, które dotyka danych użytkowników.

Jak wbudować RODO w backlog

DoR (Definition of Ready) — przed rozpoczęciem prac. Każde user story dotyczące danych użytkowników powinno przed wejściem do sprintu zawierać odpowiedzi na pytania: jakie dane są zbierane, na jakiej podstawie prawnej, jak długo będą przechowywane, kto ma do nich dostęp, czy wymagana jest zgoda użytkownika.
DoD (Definition of Done) — warunek zamknięcia zadania. Zadanie nie jest zakończone, dopóki nie zostaną spełnione wymagania: zaktualizowana klauzula informacyjna (jeśli zmienił się zakres danych), wdrożony mechanizm realizacji praw użytkownika (usunięcie, eksport, ograniczenie), zastosowana zasada minimalizacji danych (art. 5 ust. 1 lit. c RODO), przetestowane mechanizmy kontroli dostępu.
Ocena skutków dla ochrony danych (DPIA) przy nowych funkcjach. Art. 35 RODO wymaga przeprowadzenia DPIA, gdy przetwarzanie może powodować wysokie ryzyko naruszenia praw i wolności osób. Europejska Rada Ochrony Danych (EDPB) wskazuje 9 kryteriów wysokiego ryzyka — m.in. profilowanie, przetwarzanie na dużą skalę, łączenie zbiorów danych. Prezes UODO opublikował wykaz operacji wymagających DPIA (17 czerwca 2019 r.). Jeśli nowa funkcja Twojego SaaS spełnia choćby dwa z tych kryteriów — przeprowadź DPIA zanim trafi do developmentu.
Mechanizmy realizacji praw użytkowników jako wymagania funkcjonalne. Prawo do usunięcia danych (art. 17 RODO), prawo do ograniczenia przetwarzania (art. 18), prawo do sprzeciwu (art. 21) i prawo do niepodlegania zautomatyzowanym decyzjom (art. 22) — to nie są abstrakcyjne zapisy prawne. To wymagania funkcjonalne Twojego produktu. Jeśli dashboard analityczny automatycznie scoringuje użytkowników na podstawie logów aktywności — art. 22 RODO wymaga, by użytkownik mógł się temu sprzeciwić.
Retencja danych jako parametr konfiguracyjny. Zasada ograniczenia przechowywania (art. 5 ust. 1 lit. e RODO) wymaga, by dane były przechowywane nie dłużej niż jest to niezbędne do celów przetwarzania. Zamiast hardcodować okresy retencji, zaprojektuj je jako konfigurowalne parametry — tak, by każdy klient (administrator) mógł ustawić własne zasady.
Obowiązki informacyjne jako element UI. Art. 12 RODO wymaga, by informacje o przetwarzaniu danych były podawane „w zwięzłej, przejrzystej, zrozumiałej i łatwo dostępnej formie, jasnym i prostym językiem”. To wymóg UX/UI — polityka prywatności schowana w stopce strony w formacie PDF nie spełnia tego standardu. Art. 13 RODO wymaga podania co najmniej 11 kategorii informacji osobie, od której zbierane są dane, w tym tożsamość administratora, cele przetwarzania, odbiorców danych, okres przechowywania i informacje o profilowaniu.

Checklist: co sprawdzić w umowie SaaS przed wdrożeniem u klienta enterprise

Przed każdym wdrożeniem u klienta enterprise sprawdź poniższe elementy. To nie jest wyczerpująca lista — ale obejmuje obszary, w których najczęściej pojawiają się luki.

Umowa powierzenia przetwarzania danych

Czy umowa wprost określa, kto jest administratorem, a kto podmiotem przetwarzającym?
Czy wskazano konkretne kategorie danych osobowych i kategorie osób, których dane dotyczą?
Czy określono cel i zakres przetwarzania — nie ogólnikowo, lecz w powiązaniu z konkretnymi funkcjami produktu?
Czy uregulowano zasady podpowierzenia — w tym listę aktualnych sub-procesorów?
Czy określono procedurę zgłaszania naruszeń ochrony danych — termin, formę, kanał?
Czy wskazano lokalizację danych i zasady przekazywania poza EOG?
Czy uregulowano prawo administratora do audytu?
Czy określono procedurę usunięcia lub zwrotu danych po zakończeniu umowy — w tym format eksportu?

Architektura produktu

Czy dane poszczególnych klientów są izolowane (per tenant) — czy łączone do celów analitycznych?
Czy okresy retencji danych są konfigurowalne per klient?
Czy produkt umożliwia realizację praw użytkowników: usunięcie danych, eksport, ograniczenie przetwarzania?
Czy mechanizmy zgody na cookies spełniają wymóg aktywnego działania użytkownika?
Czy logi serwera i logi sesji są objęte polityką retencji i kontrolą dostępu?

Obowiązki informacyjne

Czy polityka prywatności obejmuje identyfikatory internetowe (adres IP, cookies, ID sesji)?
Czy klauzula informacyjna jest dostępna w interfejsie produktu — nie tylko w regulaminie?
Czy użytkownik jest informowany o profilowaniu i zautomatyzowanym podejmowaniu decyzji (jeśli występują)?

Nadchodzące wymagania regulacyjne

Czy umowa uwzględnia obowiązki wynikające z Data Act (rozporządzenie 2023/2854) — obowiązki informacyjne przed zawarciem umowy o usługę powiązaną, zasady udostępniania danych, warunki zakończenia dzielenia się danymi? Przepisy te są stosowane od 12 września 2025 r.
Czy podział odpowiedzialności za bezpieczeństwo jest precyzyjnie określony: dostawca (infrastruktura, aplikacja) vs. klient (zarządzanie dostępem, ochrona danych logowania)?

Umowa SaaS a ochrona danych — jak uporządkować oba obszary

Sankcje za naruszenie obowiązków administratora sięgają 20 mln EUR lub 4% całkowitego rocznego światowego obrotu — stosuje się wartość wyższą (art. 83 RODO). Decyzja w sprawie McDonald’s Polska pokazuje, że kary dotykają zarówno administratora, jak i podmiot przetwarzający. Prawidłowo zawarta umowa SaaS z elementami umowy powierzenia nie eliminuje odpowiedzialności, ale porządkuje role i ogranicza ryzyko obu stron.

Jeśli budujesz produkt SaaS, skalujesz go na rynki UE lub przygotowujesz się do wdrożenia u klienta enterprise — sprawdź, czy Twoja umowa i architektura produktu adresują opisane wyżej wymagania.

Wspieramy founderów i CTO firm technologicznych w porządkowaniu umów SaaS, umów powierzenia przetwarzania danych i wdrażaniu zasad Privacy by Design w architekturze produktu. Łączymy prawo IT, ochronę danych i prawo umów w jeden spójny model — od developmentu po sprzedaż.

Jeśli potrzebujesz weryfikacji swojej umowy SaaS lub chcesz uporządkować kwestie danych osobowych w produkcie — napisz do nas.

Najczęściej zadawane pytania

Czy adres IP użytkownika mojego SaaS jest daną osobową, skoro nie znam jego imienia ani nazwiska?
Tak. TSUE w wyroku C-582/14 (sprawa Breyer) przesądził, że dynamiczny adres IP stanowi daną osobową, jeżeli usługodawca dysponuje środkami prawnymi umożliwiającymi zidentyfikowanie użytkownika — np. poprzez pozyskanie informacji od dostawcy usług internetowych. NSA w wyroku I OSK 1079/10 potwierdził, że informacja odnosząca się do urządzenia, które da się powiązać z konkretną osobą, pośrednio stanowi informację o niej. UODO traktuje adresy IP analogicznie do numerów PESEL.

Kiedy dostawca SaaS przestaje być podmiotem przetwarzającym i staje się administratorem danych?
Wtedy, gdy samodzielnie ustala cele przetwarzania danych — np. prowadzi analizy rynkowe na danych klientów, buduje własną bazę użytkowników, łączy dane z wielu tenantów do tworzenia benchmarkingów lub rozwija algorytmy rekomendacyjne. Decyzja UODO w sprawie McDonald’s Polska (DKN.5131.5.2025) potwierdziła, że projektowanie systemu i decydowanie o jego funkcjonalności oraz zakresie zbieranych danych może przesądzać o uznaniu właściciela systemu za administratora.

Co musi zawierać umowa powierzenia przetwarzania danych w kontekście SaaS?
Art. 28 ust. 3 RODO wymaga określenia: przedmiotu i czasu trwania przetwarzania, charakteru i celu przetwarzania, rodzaju danych osobowych, kategorii osób, obowiązków i praw administratora. Podmiot przetwarzający musi zobowiązać się do przetwarzania danych wyłącznie na polecenie administratora, zapewnienia poufności, wdrożenia środków bezpieczeństwa, respektowania zasad podpowierzenia, pomocy w realizacji praw osób, usunięcia lub zwrotu danych po zakończeniu usług i umożliwienia audytów.

Czy logi sesji i dane behawioralne z dashboardu analitycznego to dane osobowe?
Tak, jeśli można je powiązać z konkretnym użytkownikiem — a w typowym systemie SaaS z kontami użytkowników jest to standardowa sytuacja. Motyw 30 RODO wprost wskazuje, że identyfikatory internetowe w połączeniu z informacjami uzyskiwanymi przez serwery mogą być wykorzystywane do tworzenia profili i identyfikowania osób. Zestawienie adresu IP, identyfikatora cookies i logów sesji umożliwia szczegółową rekonstrukcję aktywności konkretnej osoby.

Czy muszę przeprowadzić ocenę skutków (DPIA) przed uruchomieniem nowej funkcji w produkcie SaaS?
Art. 35 RODO wymaga DPIA, gdy przetwarzanie może powodować wysokie ryzyko naruszenia praw i wolności osób. EDPB wskazuje 9 kryteriów wysokiego ryzyka — m.in. profilowanie, przetwarzanie na dużą skalę, łączenie zbiorów danych. Prezes UODO opublikował wykaz operacji wymagających DPIA (17 czerwca 2019 r.). Jeśli nowa funkcja Twojego SaaS spełnia co najmniej dwa z tych kryteriów — przeprowadź DPIA zanim trafi do developmentu.

Jakie dodatkowe obowiązki nakłada Data Act na dostawców SaaS?
Rozporządzenie 2023/2854 (Data Act), stosowane od 12 września 2025 r., wymaga, aby przed zawarciem umowy o usługę powiązaną dostawca poinformował użytkownika m.in. o: charakterze i częstotliwości zbierania danych, celach ich wykorzystywania, tożsamości osób przetwarzających dane, uzgodnieniach dotyczących przechowywania i okresu zatrzymywania danych oraz sposobie zakończenia dzielenia się danymi. To dodatkowa warstwa obowiązków informacyjnych nakładająca się na wymogi RODO.