RODO i umowa powierzenia przetwarzania danych

Niniejsza strona przedstawia zobowiązanie BEO TECHNOLOGY SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ w zakresie ochrony danych oraz wiążącą umowę powierzenia przetwarzania danych (DPA) zgodną z art. 28 RODO, która ma zastosowanie zawsze, gdy przetwarzamy dane osobowe osób odwiedzających Twoje strony w Twoim imieniu za pośrednictwem Usługi SGTM.space.

1. Nasze zobowiązanie w zakresie RODO

Gdy korzystasz z Usługi, dane osobowe Twoich Odwiedzających (takie jak ich adres IP, user agent oraz dane wysyłane przez Twoje tagi) przechodzą przez naszą infrastrukturę. Przetwarzamy je wyłącznie na Twoje polecenie i zgodnie z RODO. W skrócie: szyfrujemy połączenia, ograniczamy dostęp, przechowujemy tylko to, czego Usługa potrzebuje do działania i rozliczeń (wiersz żądania bez parametrów zapytania, przez 90 dni, z okresem przejściowym opisanym w punkcie 6, oraz standardowe logi żądań Google Cloud przez 30 dni), korzystamy wyłącznie z podprocesorów wymienionych w Załączniku 2 i uprzedzamy o ich zmianie z 30-dniowym wyprzedzeniem, zgłaszamy naruszenia w ciągu 48 godzin oraz pomagamy Ci w realizacji żądań osób, których dane dotyczą, ocenach skutków i audytach. Wiążące postanowienia znajdują się poniżej, a szczegóły w Załącznikach 1-4.

2. Definicje

„Administrator”, „Podmiot przetwarzający”, „Podprocesor”, „Dane osobowe”, „Przetwarzanie”, „Osoba, której dane dotyczą” oraz „Naruszenie ochrony danych osobowych” mają znaczenie nadane w RODO. Ponadto:

• „Usługa” oznacza platformę SGTM.space;
• „Organizacja” oznacza organizację w Usłudze, do której należą Kontenery, subskrypcje i dane do faktur;
• „Klient” oznacza Organizację, a jeżeli za Organizacją stoi przedsiębiorca (osoba prawna, jednostka organizacyjna albo osoba fizyczna prowadząca działalność gospodarczą), ten podmiot;
• „Operator”, „my”, „nas” oznacza BEO Technology sp. z o.o. działającego jako Podmiot przetwarzający;
• „Kontener” oznacza kontener Klienta w Usłudze: jego hosty tagowania i Better Loadera, konfigurację na brzegu sieci oraz, jeżeli został skonfigurowany, Serwer tagujący;
• „Serwer tagujący” oznacza usługi Google Cloud Run Kontenera, w których działa obraz serwerowego Google Tag Managera: serwer tagujący i serwer podglądu;
• „Worker” oznacza Worker Cloudflare Operatora, przez który przechodzi ruch hostów Kontenera;
• „Worker Klienta” oznacza kod obsługujący ścieżkę Same Origin Transport na własnym koncie Klienta: Worker Cloudflare na koncie Cloudflare Klienta albo, jeżeli Usługa to oferuje, plik generowany przez Usługę dla projektu Klienta na Vercel lub Netlify („plik platformy”);
• „Odwiedzający” oznacza osobę odwiedzającą strony lub aplikacje Klienta, której przeglądarka lub urządzenie wysyła żądania do hostów Kontenera, w tym testera sesji Live Logs lub Preview Mode;
• „Dane Odwiedzających” oznacza dane osobowe Odwiedzających przetwarzane za pośrednictwem Usługi.

3. Role stron, obowiązki i prawa Klienta

W odniesieniu do Danych Odwiedzających Klient jest Administratorem, a Operator jest Podmiotem przetwarzającym. Jeżeli Klient przetwarza Dane Odwiedzających w imieniu innego administratora (na przykład agencja dla swojego klienta), Klient jest wobec niego podmiotem przetwarzającym, Operator jest dalszym podmiotem przetwarzającym, a Klient zapewnia, że jego polecenia i niniejsza umowa są zgodne z umową z tym administratorem. W odniesieniu do danych konta, rozliczeń i zabezpieczeń logowania Operator działa jako administrator, co opisano w Polityce prywatności.

Obowiązki Klienta. Klient odpowiada za podstawę prawną przetwarzania Danych Odwiedzających, w tym za zgody wymagane dla plików cookie i tagów, za informowanie Odwiedzających oraz za to, jakie dane wysyłają jego tagi. O tym, co Serwer tagujący odczytuje z żądania, co robi z danymi i do jakich odbiorców je wysyła (na przykład Google Analytics, Google Ads lub Meta), decyduje konfiguracja kontenerów Google Tag Managera Klienta. Odbiorcy wybrani w tej konfiguracji są odbiorcami Klienta, a nie podprocesorami Operatora. To samo dotyczy Google w odniesieniu do żądań wbudowanego Google Tag Gateway Same Origin Transport (punkt 5): włączając go, Klient poleca Operatorowi przekazywać te żądania do Google, które otrzymuje je jako odbiorca Klienta na podstawie własnych umów Klienta z Google. To samo dotyczy dostawcy asystenta AI, którego użytkownik Klienta połączy z Usługą (punkt 5): dane odczytane przez asystenta trafiają do tego dostawcy jako odbiorcy Klienta, na polecenie Klienta. Klient informuje testerów, zanim dołączą do sesji Live Logs lub Preview Mode. Jeżeli Klient korzysta z własnego konta Cloudflare (Worker Same Origin Transport, Google Tag Gateway), Cloudflare działa tam na podstawie umowy Klienta z Cloudflare, a w przypadku pliku platformy Vercel lub Netlify działa na podstawie umowy Klienta z tą platformą. Worker Klienta, jego trasy i reguły działają na koncie Klienta; Klient zachowuje klucz Kontenera w tajemnicy (w przypadku pliku platformy w zmiennych środowiskowych projektu, nigdy w samym pliku), zmienia go, jeżeli mógł wyciec, i odpowiada za zmiany, które sam wprowadzi w kodzie tego Workera.

Prawa Klienta. Klient wydaje polecenia (punkt 7), otrzymuje informacje i może przeprowadzać audyty (punkt 14), może sprzeciwić się zmianie podprocesora (punkt 10) oraz żądać usunięcia lub zwrotu danych (punkty 12 i 15).

4. Przedmiot i czas trwania

Przedmiotem jest przetwarzanie Danych Odwiedzających niezbędne do świadczenia Usługi dla Kontenerów Klienta. Przetwarzanie trwa przez okres korzystania z Usługi przez Klienta, powiększony o okres usunięcia danych opisany w punkcie 15.

5. Charakter i cel przetwarzania

Obsługa żądań na brzegu sieci. Każde żądanie wysłane do hostów Kontenera trafia do Workera w sieci Cloudflare. Worker odczytuje konfigurację Kontenera, stosuje dodatki włączone przez Klienta, dodaje kraj i kod regionu Odwiedzającego na potrzeby ustawień regionalnych Kontenera i przekazuje żądanie do Serwera tagującego. Kontener może działać bez Serwera tagującego („web only”); wtedy Worker obsługuje wyłącznie Better Loadera i dodatki na brzegu sieci.

Serwer tagujący. Każdy Kontener z Serwerem tagującym ma własne usługi Cloud Run (serwer tagujący i serwer podglądu) z obrazem serwerowego Google Tag Managera, w którym działa konfiguracja kontenera GTM wklejona przez Klienta. Serwer tagujący przetwarza treść żądań (na przykład parametry zdarzeń GA4) zgodnie z tą konfiguracją. Operator jej nie zmienia i nie wykorzystuje przetwarzanych w niej danych.

Rejestrowanie żądań. Dla każdego zliczanego żądania Worker zapisuje w Google BigQuery jeden wiersz z danymi wymienionymi w punkcie 6. Wiersze służą do zliczania żądań według planu Kontenera i ich rozliczania, do egzekwowania limitu (po jego wyczerpaniu Worker odpowiada kodem 429), do wykrywania ruchu automatycznego oraz do pokazywania Klientowi statystyk użycia. Poza sesją Live Logs Worker nie zapisuje treści żądań, plików cookie ani parametrów zapytania; przekazuje je do Serwera tagującego (w przypadku wbudowanego Google Tag Gateway do Google), zmieniając je wyłącznie w sposób opisany w tym punkcie. Okres przejściowy dla wierszy zapisanych przed tą zmianą opisuje punkt 6.

Dodatki działają tylko wtedy, gdy Klient je włączy, z jednym wyjątkiem: Bot Filtering włącza się sam w trybie „Tylko oznaczaj” (oznacza prawdopodobne boty i niczego nie blokuje), gdy plan Kontenera go obejmuje, chyba że Klient wcześniej sam ustawił Bot Filtering dla tego Kontenera; Klient może w każdej chwili zmienić jego tryb albo go wyłączyć:

• Better Loader podaje skrypt ładujący GTM i skrypty Google z hosta Klienta przez Worker; wymagają go Cookie Extender, Request Proxy, Google Tag Gateway, Same Origin Transport z wbudowanym Google Tag Gateway, opcja dataLayer dodatku Bot Filtering oraz Live Logs;
• Cookie Extender odczytuje pliki cookie wysłane do hosta tagowania i ponownie ustawia wybrane przez Klienta pliki cookie z dłuższą ważnością;
• Bot Filtering blokuje lub oznacza ruch automatyczny i może przekazywać werdykt do Serwera tagującego w nagłówkach; werdykt (na podstawie user agenta, nagłówków przeglądarki i sieci, z której przychodzi żądanie) jest ustalany dla każdego żądania także przy wyłączonym dodatku i zapisywany w wierszu żądania; z opcją dataLayer Better Loader umieszcza werdykt także w warstwie danych (dataLayer) strony;
• Request Proxy zmienia w przeglądarce adresy żądań tagów na zakodowany adres na hoście Klienta, a Worker je dekoduje i przekazuje pod pierwotną ścieżką;
• Request Enricher dodaje do żądania nagłówki z lokalizacją, siecią oraz danymi urządzenia i przeglądarki ustalonymi z adresu IP i user agenta; adres IP i szczegółową lokalizację tylko wtedy, gdy Klient włączy szczegółową lokalizację;
• Preview Mode przez najwyżej 60 minut przekazuje żądania pasujące do opcjonalnego filtra ścieżki i adresu IP z nagłówkiem podglądu GTM, tak że Klient widzi je w trybie podglądu swojego kontenera serwerowego; bez filtra IP dotyczy to żądań wszystkich Odwiedzających;
• Google Tag Gateway działa w strefie Cloudflare lub w sieci CDN Klienta, poza Usługą; Usługa prowadzi Klienta przez jego włączenie, sprawdza wynik, a Better Loader ładuje GTM przez ten adres;
• Same Origin Transport (gdy jest dostępny) przesyła ruch tagowania ze ścieżki na stronie Klienta (na najwyżej 10 hostach witryny) przez Worker Klienta do Kontenera. Worker Klienta przekazuje żądanie przeglądarki bez nagłówków Authorization, wyłącznie pliki cookie o dozwolonych nazwach (bez plików cookie o nazwach zaczynających się od __Host- i popularnych plików cookie sesji i logowania), a w osobnych nagłówkach adres IP Odwiedzającego, lokalizację ustaloną z niego przez Cloudflare albo platformę hostingową Klienta oraz host i ścieżkę witryny. Worker Operatora ufa tym nagłówkom tylko wtedy, gdy skrót SHA-256 przesłanego klucza Kontenera zgadza się z zapisanym, a po upływie terminu obowiązującej wersji minimalnej (niżej) Worker Klienta nie jest starszy niż ta wersja; wtedy traktuje ten adres IP i tę lokalizację jako dane Odwiedzającego we wszystkich funkcjach opisanych w tym punkcie. Bez ważnego klucza żądanie jest przekazywane dalej jako niezweryfikowane, z adresem i lokalizacją centrum danych sieci, w której działa Worker Klienta. Domyślnie Worker Operatora ufa każdej wersji Workera Klienta; tylko w razie rzeczywistego problemu z bezpieczeństwem starszych wersji Operator może ustalić wersję minimalną z terminem co najmniej 30 dni późniejszym, o którym informuje Klienta e-mailem i w Usłudze. Od tego terminu żądanie od Workera Klienta starszego niż wersja minimalna jest nadal przekazywane dalej, także przez wbudowany Google Tag Gateway, ale z adresem i lokalizacją, które widzi sam Worker Operatora (sieci, w której działa Worker Klienta), zamiast przesłanych przez niego adresu IP i lokalizacji Odwiedzającego, więc przetwarzanie, które się na nich opiera, traci je do czasu aktualizacji Workera przez Klienta. Po pomyślnym sprawdzeniu ścieżki skrypt Better Loadera zawiera klienta, który w przeglądarce Odwiedzającego kieruje przez tę ścieżkę żądania pomiarowe Google adresowane do hosta tagowania (zdarzenia Google Analytics, Google Ads i Floodlight oraz pobieranie plików cookie po odpowiedzi strumieniowej); pozostałe żądania, w tym żądania fetch z treścią w obiekcie Request, zostają na hoście tagowania; klient nie zapisuje plików cookie ani danych w przeglądarce i nie zmienia zakresu przesyłanych danych. Worker Operatora oznacza każdą odpowiedź na ruch przez ścieżkę nagłówkiem, po którym klient rozpoznaje, że żądanie do niego dotarło; bez tego nagłówka (z wyjątkiem odpowiedzi na żądania fetch przekierowanych lub nieczytelnych dla strony) klient kieruje resztę danej odsłony do hosta tagowania i może wysłać tam dane żądanie ponownie. Przez 24 godziny po wyłączeniu dodatku Worker Operatora nadal ufa nagłówkom Workera Klienta, aby ruch z kart otwartych wcześniej zachował dane Odwiedzającego.
• Wbudowany Google Tag Gateway Same Origin Transport (gdy jest dostępny) obsługuje Google Tag Gateway dla kontenera GTM ładowanego przez Better Loader, w folderze ścieżki Same Origin Transport (/{ścieżka}/{folder}/). Worker Klienta przekazuje te żądania do Workera Operatora, który obsługuje je wyłącznie dla ruchu ze zweryfikowanym kluczem i przesyła je na adres bramy Google dla tego kontenera ({tag}.fps.goog): skrypt GTM (gtm.js), tag Google (gtag.js) oraz żądania pomiarowe i reklamowe Google (na przykład Google Analytics i Google Ads). Adres żądania z parametrami zapytania i treść żądania trafiają do Google tak, jak wysłała je przeglądarka (na przykład parametry zdarzenia w żądaniu pomiarowym). Z nagłówków przeglądarki przekazuje wyłącznie User-Agent, Accept, Accept-Language, Accept-Encoding, Content-Type, Origin i Referer, a z jej plików cookie wyłącznie te o dozwolonych nazwach (identyfikatory Google, nigdy pliki cookie o nazwach zaczynających się od __Host- ani plik cookie Live Logs), a dodaje zweryfikowany adres IP Odwiedzającego (X-Forwarded-For) oraz jego kraj i kod regionu. Nagłówek Referer trafia do Google tak, jak wysłała go przeglądarka: jako pełny adres strony, który może zawierać parametry zapytania. Z odpowiedzi Google Worker przekazuje z powrotem tylko dozwolone nagłówki, pliki cookie o dozwolonych nazwach i wyłącznie skrypty, JSON, obrazy rastrowe i zwykły tekst, nigdy HTML; przekierowanie przekazuje tylko w obrębie tego samego folderu albo na własne adresy Google i nie zachowuje tych odpowiedzi w swojej pamięci podręcznej. Na hostach, na których sprawdzenia bramy przez Operatora przechodzą, Better Loader ładuje przez nią GTM po własnych klientach. Google otrzymuje więc adres IP i lokalizację Odwiedzającego tak jak przy zwykłej instalacji tagu Google; jeżeli Google Tag Gateway w Cloudflare w strefie ukrywał adres IP („Hide original client IP”), Google otrzymuje go, gdy wbudowany gateway przejmie ruch. Google otrzymuje te żądania jako odbiorca Klienta (punkt 3).

Połączenie Cloudflare (gdy jest dostępne). Po połączeniu przez Organizację konta Cloudflare Operator, na polecenie użytkownika i po jego potwierdzeniu, tworzy lub usuwa rekordy DNS (a tylko po wyraźnym potwierdzeniu przez użytkownika nadpisania wskazanego rekordu blokującego nazwę potrzebną Kontenerowi nadpisuje go, zapisując pełny poprzedni rekord w dzienniku zmian i przywracając go po Cofnij, gdy użytkownik zleci usunięcie rekordów ustawionych przez Operatora, oraz przy usunięciu Kontenera z wybraną przez użytkownika opcją usunięcia tych rekordów; nie dotyczy to Danych Odwiedzających), zmienia ustawienie Google Tag Gateway w strefie oraz wdraża, aktualizuje lub usuwa Worker Same Origin Transport na koncie Klienta. Worker Same Origin Transport wdrożony w ten sposób przez Operatora może być później aktualizowany do nowszej wersji jego kodu bez ponownego potwierdzenia, ale wyłącznie w miejscu: ten sam skrypt i te same trasy, a zmienia się tylko kod Workera (a przy zmianie klucza także jego klucz); każda taka aktualizacja jest zapisywana w dzienniku zmian, który widzi Organizacja, a utworzenie, przeniesienie lub usunięcie trasy, reguły albo Workera zawsze wymaga podglądu i potwierdzenia. Nowe wersje są wdrażane etapami, a każdy Worker jest sprawdzany po aktualizacji; gdy sprawdzenie się nie powiedzie, Operator może przywrócić kod, który każdy zaktualizowany Worker miał wcześniej, w ten sam sposób, w miejscu, z zapisem w dzienniku zmian. Aby utrzymywać takie Workery w aktualnej wersji, Operator raz w tygodniu odnawia dostęp połączenia w Cloudflare. Jeżeli Cloudflare udostępnia takie ustawienie, trasy tworzone przez Operatora są ustawiane tak, aby po osiągnięciu limitu żądań Workerów na koncie przepuszczały żądania do witryny Klienta bez Workera (fail open). Workera wdrożonego przez Klienta samodzielnie z pobranego kodu Operator nigdy nie zmienia. Jeżeli Usługa to oferuje, a ścieżkę Same Origin Transport obsługuje już trasa własnego Workera Klienta, Operator może skierować tę trasę na swojego Workera (przejęcie trasy), wyłącznie po podglądzie wskazującym tę trasę i tego Workera oraz po potwierdzeniu przez administratora Organizacji; nigdy nie zmienia ani nie usuwa skryptu własnego Workera Klienta, dziennik zmian zapisuje, na którego Workera wskazywała trasa, a przy usunięciu Workera Operatora („Remove from my Cloudflare”) Usługa proponuje skierowanie trasy z powrotem na tamtego Workera, jeżeli nadal istnieje. Działania te nie obejmują Danych Odwiedzających; ich rejestr opisuje Polityka prywatności. Kod autoryzacji i tokeny połączenia mogą przechodzić w drodze do Cloudflare przez Worker Operatora w sieci Cloudflare, który ich nie zapisuje ani nie loguje. Zakładając na polecenie Klienta ustawienie Google Tag Gateway w strefie, która go nie ma albo ma je tylko puste, Operator pozostawia opcję ukrywania pierwotnego adresu IP klienta („Hide original client IP”) tak, jak jest w strefie, a gdy nie jest ustawiona, wyłączoną, więc Google otrzymuje wtedy adres IP Odwiedzającego tak jak przy zwykłej instalacji tagu Google. W ustawieniu, które już istnieje, niezależnie od tego, kto je założył, Operator wyłącza albo włącza tę opcję wyłącznie na polecenie użytkownika, który może zmieniać ustawienia Cloudflare Organizacji, i po podglądzie tej jednej wartości, zapisuje zmianę w dzienniku zmian, a przy cofnięciu przywraca poprzednią wartość; Klient może ją też zmienić w Cloudflare. Ustawienie obejmuje wszystkie strony w strefie. Ruch bramy nie przechodzi przez Usługę, a Google jest tam odbiorcą Klienta (punkt 3). Gdy Better Loader ładuje GTM przez wbudowany Google Tag Gateway Same Origin Transport, Operator, na polecenie użytkownika, który może zmieniać ustawienia Cloudflare Organizacji, i po podglądzie wymieniającym nazwy hostów strefy objęte proxy oraz inne Kontenery Organizacji w strefie, wyłącza to ustawienie strefy, zmieniając wyłącznie wartość, która je włącza, a na późniejsze polecenie włącza je ponownie (cofnięcie); nigdy nie robi tego z własnej inicjatywy ani w strefie samego SGTM.space. Jeżeli Usługa to oferuje: gdy Klient wyłącza dodatek Google Tag Gateway, a połączenie może zmieniać ustawienie strefy, potwierdzenie proponuje wyłączenie Google Tag Gateway w strefie w ten sam sposób, niezależnie od tego, kto je tam założył (zaznaczone z góry tylko wtedy, gdy w strefie nie ma innej witryny ani innego Kontenera Organizacji, a w przeciwnym razie niezaznaczone, z listą pozostałych nazw hostów strefy objętych proxy i innych Kontenerów Organizacji), co dotyczy wszystkich stron w strefie; na stronie dodatku Google Tag Gateway, na polecenie użytkownika, który może zmieniać ustawienia Cloudflare Organizacji, i po podglądzie wymieniającym nazwy hostów strefy objęte proxy i inne Kontenery Organizacji w strefie, samo ustawienie Google Tag Gateway w strefie jest wyłączane w ten sam sposób, niezależnie od tego, czy dodatek jest włączony (włączony dodatek pozostaje włączony, chyba że wbudowana bramka Same Origin Transport wczytuje Google Tag Managera dla tej witryny: wtedy zostaje wyłączony), i ponownie włączane przy cofnięciu; a gdy Klient wyłącza Same Origin Transport, potwierdzenie proponuje ponowne włączenie Google Tag Gateway w strefie (jak cofnięcie, z przywróceniem dodatku Google Tag Gateway), jeżeli Operator go wyłączył, oraz, dla Workera wdrożonego przez Operatora, zaplanowanie usunięcia tego Workera, jego tras i reguły pamięci podręcznej po upływie 24 godzin, które jest anulowane, jeżeli dodatek zostanie ponownie włączony, usuwa tylko to, co Operator utworzył i czego nikt od tego czasu nie zmienił, i jest rejestrowane. W Cloudflare nic się nie zmienia, jeżeli żadna opcja nie zostanie zaznaczona, a każda zmiana jest zapisywana w dzienniku zmian. Żadne z tych działań nie obejmuje Danych Odwiedzających.

Live Logs (gdy jest dostępny). Gdy Klient uruchomi sesję Live Logs dla Kontenera, rejestrujemy także ruch testerów, którzy do niej dołączą, przez wybrany przez Klienta czas (15, 30 lub 60 minut), aby Klient mógł sprawdzić działanie swoich tagów. Tester dołącza, otwierając link startowy przekazany mu przez Klienta: link wyświetla testerowi stronę z informacją, co jest rejestrowane i do kiedy, wraz z linkiem do opuszczenia sesji, oraz ustawia w witrynie Klienta plik cookie _sgtm_dbg do planowanego końca sesji. Rejestrowane są wyłącznie żądania przeglądarki, która przesyła ten plik cookie, wraz z raportami kontenera serwerowego o tych żądaniach (punkt 6); dla pozostałych Odwiedzających nic się nie zmienia. Przed uruchomieniem sesji Klient potwierdza w Usłudze, że testerzy wiedzą, że ich żądania są tam pokazywane; potwierdzenie i jego wersja są rejestrowane. To, co sesja zarejestruje, jest pokazywane Klientowi w zakładce Live Logs Kontenera i zostało opisane w punkcie 6.

Sprawdzenie serwera w Live Logs Enhance (gdy jest dostępne) nie obejmuje Danych Odwiedzających. Wyłącznie gdy Klient je uruchomi, Worker tworzy jedno żądanie testowe, zdarzenie GA4 z identyfikatorem pomiaru, który nie należy do żadnej prawdziwej usługi, z odmową zgody, ze stroną główną witryny Klienta jako adresem strony i bez danych użytkownika, plików cookie ani adresu IP osoby, i wysyła je do kontenera serwerowego Klienta, w którym tagi Klienta mogą przekazać je swoim dostawcom jak każde inne zdarzenie. Z raportu szablonu tagu serwerowego o tym żądaniu Worker zachowuje wyłącznie wersję szablonu, identyfikator i wersję kontenera serwerowego, nazwę klienta, liczbę tagów oraz identyfikatory i nazwy najwyżej pięciu tagów, które nie zadziałały (z zamaskowanymi adresami e-mail, jeśli je zawierają), najdłużej przez 2 minuty, w Cloudflare Durable Objects (w jurysdykcji UE Cloudflare dla Kontenera hostowanego w UE); Usługa zapisuje wynik sprawdzenia przy Kontenerze. Żądanie nie jest zliczane ani zapisywane w BigQuery.

Asystenci AI (gdy są dostępni). Użytkownik Klienta może połączyć z Usługą asystenta AI przez serwer MCP Operatora; asystent działa wtedy jako ten użytkownik, z jego dostępem. Gdy asystent odczytuje sesję Live Logs, Worker analizy Live Logs Operatora w Cloudflare oblicza podsumowanie sesji lub przefiltrowaną stronę jej zdarzeń z danych przechowywanych w Durable Object sesji, już zamaskowanych w sposób opisany w punkcie 6, a serwer aplikacji Operatora odczytuje tę odpowiedź i przekazuje ją asystentowi bez jej zapisywania, z zamaskowanymi wewnętrznymi nazwami hostów platformy (karta Live Logs Kontenera odczytuje natomiast sesję z Workera bezpośrednio w przeglądarce użytkownika). Zlecając asystentowi odczyt sesji, Klient poleca Operatorowi wysłanie tych danych do dostawcy asystenta, który otrzymuje je jako odbiorca Klienta na podstawie własnej umowy Klienta z tym dostawcą, a nie jako podprocesor Operatora (punkt 10). Log wywołań asystenta prowadzony przez Operatora nie zawiera Danych Odwiedzających, nigdy danych sesji, argumentów ani odpowiedzi, a jedynie narzędzie, czas, status wyniku, czas trwania, metodę i ścieżkę żądania, adres IP i user agent, z których przyszło żądanie, użytkownika, aplikację i Kontener. Sesja Live Logs lub sprawdzenie Live Logs Enhance uruchomione przez asystenta jest poleceniem Klienta, tak jak uruchomione w Usłudze.

6. Dane osobowe i osoby, których dane dotyczą

Kategorie osób, których dane dotyczą: osoby odwiedzające strony Klienta i użytkownicy końcowi, w tym testerzy, którzy dołączą do sesji Live Logs lub Preview Mode.

Kategorie danych osobowych przetwarzane za pośrednictwem Usługi:

• adres IP Odwiedzającego, odczytywany z nagłówka CF-Connecting-IP, a dla ruchu Same Origin Transport z nagłówka, który przesyła Worker Klienta, i przekazywany do Google przez wbudowany Google Tag Gateway;
• żądanie w postaci wysłanej przez przeglądarkę: adres ze ścieżką i parametrami zapytania, nagłówki (w tym User-Agent, Referer i Host), pliki cookie wysłane do hostów Kontenera oraz treść żądania, czyli dane, które wysyłają tagi Klienta (na przykład identyfikatory klienta, sesji i użytkownika, adres strony i parametry zdarzeń);
• metoda HTTP, kod statusu, rozmiar odpowiedzi, czas trwania i znacznik czasu oraz kategoria żądania (np. GA4, Universal Analytics, gtag.js, gateway dla wbudowanego Google Tag Gateway lub inna);
• werdykt wykrywania ruchu automatycznego (czy żądanie wygląda na automatyczne, powód i czy zostało zablokowane);
• pliki cookie odczytywane i ponownie ustawiane z wydłużoną ważnością przez dodatek Cookie Extender;
• kraj i kod regionu Odwiedzającego (np. US i USCA) ustalane na brzegu sieci na podstawie adresu IP Odwiedzającego i przekazywane do Kontenera Klienta z każdym żądaniem, niezależnie od włączonych dodatków, aby działały ustawienia regionalne kontenera serwerowego Klienta;
• przybliżona lokalizacja i dane sieci (kraj, region, miasto, kod pocztowy, współrzędne, strefa czasowa i sieć) ustalane na brzegu sieci na podstawie adresu IP Odwiedzającego oraz dane urządzenia i przeglądarki ustalane na podstawie nagłówka User-Agent, przekazywane do Kontenera Klienta przez dodatek Request Enricher; spośród nich adres IP Odwiedzającego, region, miasto, kod pocztowy i współrzędne są dodawane wyłącznie wtedy, gdy Klient włączy szczegółową lokalizację, z wyjątkiem kraju i kodu regionu z poprzedniego punktu;
• dla ruchu Same Origin Transport: przybliżona lokalizacja i sieć (kraj i informacja, czy leży w UE, kontynent, region i jego kod, miasto, kod pocztowy, współrzędne, strefa czasowa oraz numer i nazwa sieci), ustalane na podstawie adresu IP Odwiedzającego przez Cloudflare w strefie Klienta albo przez platformę hostingową Klienta (w zakresie, w jakim je podaje) i przekazywane przez Worker Klienta, a także host i ścieżka witryny; po weryfikacji klucza Worker Operatora używa tej lokalizacji zamiast ustalanej samodzielnie i przekazuje ją dalej tylko tak, jak opisują poprzednie punkty;
• dla wbudowanego Google Tag Gateway: żądanie w postaci przekazanej do Google (jego adres z parametrami zapytania, nagłówki wymienione w punkcie 5, przy czym nagłówek Referer zawiera pełny adres strony z parametrami zapytania, pliki cookie o dozwolonych nazwach i treść żądań pomiarowych Google), wysyłane z nim adres IP Odwiedzającego oraz kraj i kod regionu, a także odpowiedź Google, w tym ustawiane przez nią pliki cookie o dozwolonych nazwach;
• w Preview Mode: adres IP testera wpisany przez Klienta jako filtr.

Co trafia do Serwera tagującego. Worker przekazuje żądanie wraz z nagłówkami przeglądarki, więc Serwer tagujący otrzymuje dane wysłane przez przeglądarkę. Adres IP Odwiedzającego może do niego docierać w standardowych nagłówkach pośredniczących (takich jak X-Forwarded-For), niezależnie od dodatku Request Enricher, który tylko przy szczegółowej lokalizacji dodaje go w osobnym nagłówku. Dla ruchu Same Origin Transport Worker usuwa nagłówki pośredniczące dodane na odcinku od Workera Klienta oraz nagłówki X-SGTM-Site-*, a zweryfikowany adres IP Odwiedzającego przekazuje w ich miejsce w nagłówku X-Forwarded-For (oraz, przy szczegółowej lokalizacji, w nagłówku Request Enrichera, jak opisano wyżej).

Co przechowujemy. Wiersz żądania w Google BigQuery zawiera wyłącznie: identyfikator wiersza, Kontener, datę i znacznik czasu, ścieżkę żądania bez parametrów zapytania (dla dodatku Request Proxy zdekodowaną ścieżkę pierwotną, również bez parametrów), host, nagłówek Referer bez parametrów zapytania i fragmentu, user agent, adres IP Odwiedzającego w otrzymanej postaci, metodę, kod statusu, rozmiar odpowiedzi, czas trwania, kategorię żądania, werdykt wykrywania ruchu automatycznego, znacznik ruchu Same Origin Transport (site_path: valid albo auth_failed, wyłącznie dla żądań z nagłówkiem klucza Same Origin Transport) oraz skrót MD5 z Kontenera, znacznika czasu, adresu żądania i adresu IP. Treść żądania, pliki cookie, parametry zapytania i pozostałe nagłówki nie są zapisywane. Żądanie wbudowanego Google Tag Gateway otrzymuje taki sam wiersz, z kategorią gateway i nagłówkiem Referer również bez parametrów zapytania i fragmentu; poza sesją Live Logs nic więcej z tego żądania, z tego, co przekazuje do Google, ani z odpowiedzi Google nie jest przechowywane, a żądania, którymi Usługa sama sprawdza konfigurację i działanie bramy, nie są rejestrowane (audyt strony, który wczytuje strony w prawdziwej przeglądarce, jest rejestrowany jak każdy odwiedzający). Tak zapisuje wiersze Worker od wdrożenia wersji wprowadzonej wraz z wersją 1.4 niniejszej umowy. Wiersze zapisane wcześniej zawierają także parametry zapytania adresu żądania i pełny nagłówek Referer; są one usuwane zgodnie z punktem 15, tak jak pozostałe wiersze. Zagregowane dzienne liczby żądań na Kontener przechowywane są w bazie danych Operatora. Ani kraj i kod regionu, ani dane dodawane przez Request Enricher nie są przechowywane: są one przekazywane wyłącznie wraz z żądaniem, do Kontenera Klienta w przypadku ruchu do Serwera tagującego, a w przypadku wbudowanego Google Tag Gateway (punkt 5) kraj i kod regionu do Google. Filtr IP Preview Mode jest przechowywany w bazie danych Operatora jako ustawienie Kontenera oraz, na czas sesji, w konfiguracji Workera. Lokalizacja przekazana przez Worker Klienta nie jest przechowywana. Gdy żądanie z nagłówkiem klucza Same Origin Transport, inne niż sonda diagnostyczna sprawdzenia konfiguracji, nie przejdzie weryfikacji (klucza, hosta, ścieżki lub adresu IP), Worker zapisuje w swoim magazynie konfiguracji (Cloudflare KV) znacznik dla Kontenera z czasem, powodem i strefą Cloudflare Workera, który wysłał żądanie, jeśli taki był, bez żadnych danych Odwiedzającego; znacznik wygasa jeden dzień po ostatnim zapisanym w nim nieudanym żądaniu. Google Cloud Logging przechowuje przez 30 dni (domyślne ustawienie Google) logi żądań usług Cloud Run (Serwera tagującego i serwera podglądu): pełny adres żądania wraz z parametrami, adres IP Odwiedzającego, user agent, nagłówek Referer, status odpowiedzi i czas jej obsługi.

Sesje Live Logs obejmują dodatkowo, wyłącznie w odniesieniu do testerów:

• żądania wysyłane przez ich przeglądarki do hostów tagowania i Better Loadera Kontenera oraz przez ścieżkę Same Origin Transport, w tym żądania jej wbudowanego Google Tag Gateway, w postaci, w jakiej otrzymuje je Worker Cloudflare (adres, nagłówki i treść, przy czym treść do określonego limitu rozmiaru), to, co Worker zrobił z każdym żądaniem, oraz zwróconą odpowiedź;
• jeżeli w przeglądarce testera działa agent strony (dostarczony przez Better Loader albo ładowany przez szablon tagu GTM dla kontenera internetowego instalowany przez Klienta), to, co strona umieszcza w swojej warstwie danych (dataLayer), oraz wysyłane przez nią żądania śledzące, w tym wysyłane bezpośrednio do Google, Google Ads, Meta lub innych usług reklamowych;
• jeżeli Klient zainstaluje szablony tagów Live Logs w swoich kontenerach GTM, informacje, które tagi internetowe i serwerowe zostały uruchomione dla zdarzeń, o których raportują, oraz dane zdarzenia przetworzone przez kontener serwerowy. Worker dodaje nagłówek X-SGTM-Debug, zawierający identyfikator sesji i identyfikator żądania, do przekazywanych do Kontenera Klienta żądań danych testerów, a szablon tagu serwerowego na jego podstawie odsyła do Workera raporty o tych żądaniach.

Dane te są maskowane przed zapisaniem: wartości plików cookie są zachowywane wyłącznie dla plików cookie służących do śledzenia (takich jak _ga, FPID, _gcl_*, _fbp i _fbc) oraz dla własnego pliku cookie sesji _sgtm_dbg, a każdy inny plik cookie jest pokazywany tylko w postaci opisu jego kształtu; nagłówki Authorization, nagłówki kluczy API i podglądu GTM, klucz Kontenera i lokalizacja przekazywane przez Worker Same Origin Transport oraz dane uwierzytelniające środowisk GTM w adresach są maskowane; adresy IP w nagłówkach z adresem IP klienta (w tym w nagłówku, w którym Worker Same Origin Transport przekazuje adres Odwiedzającego) i w polach adresu IP (takich jak ip_override) są zapisywane z ukrytą ostatnią częścią; wartości pod określonym zestawem kluczy oznaczających adres e-mail, numer telefonu, imię lub nazwisko, ulicę, kod pocztowy lub miasto albo identyfikator użytkownika (takich jak email, phone, first_name i user_id; parametr GA4, taki jak ep.phone, jest oceniany według własnej nazwy), wszystkie wartości obiektów danych użytkownika oraz jawne adresy e-mail w dowolnym miejscu są zastępowane opisem ich kształtu (rodzajem i długością albo pierwszymi znakami hasha SHA-256), nigdy samą wartością. Wszystkie pozostałe dane, takie jak user agent, adresy stron, pseudonimowe identyfikatory śledzące i wartości pod innymi kluczami, są zapisywane w otrzymanej postaci. Zarejestrowane dane są przechowywane wyłącznie w obiekcie Durable Object Cloudflare przypisanym do danej sesji i nigdy nie są zapisywane w BigQuery ani w bazie danych Operatora.

7. Przetwarzanie na udokumentowane polecenie

Przetwarzamy Dane Odwiedzających wyłącznie na udokumentowane polecenie Klienta, co dotyczy także przekazywania danych osobowych do państwa trzeciego lub organizacji międzynarodowej, chyba że obowiązek taki nakłada na nas prawo Unii lub prawo państwa członkowskiego, któremu podlegamy; w takim przypadku przed rozpoczęciem przetwarzania informujemy Klienta o tym obowiązku prawnym, o ile prawo to nie zabrania udzielania takiej informacji z uwagi na ważny interes publiczny. Udokumentowanym poleceniem są: niniejsza umowa powierzenia, konfiguracja Kontenera i dodatków w Usłudze (w tym wybór regionu Kontenera), konfiguracja kontenerów GTM Klienta oraz polecenia przekazane nam przez Klienta w formie elektronicznej, w tym przez asystenta AI połączonego przez użytkownika Klienta (punkt 5). Niezwłocznie informujemy Klienta, jeżeli naszym zdaniem wydane polecenie narusza RODO lub inne przepisy o ochronie danych. Nie przetwarzamy Danych Odwiedzających do własnych celów: zliczanie i rozliczanie żądań, limity, wykrywanie ruchu automatycznego i statystyki opisane w punkcie 5 służą świadczeniu Usługi Klientowi.

8. Poufność

Zapewniamy, że dostęp do Danych Odwiedzających mają wyłącznie osoby, które potrzebują go do świadczenia Usługi, i że są one zobowiązane do zachowania poufności.

9. Bezpieczeństwo przetwarzania (art. 32)

Wdrażamy odpowiednie środki techniczne i organizacyjne, wymienione w Załączniku 3, w tym: szyfrowanie połączeń (TLS); osobne usługi Cloud Run dla każdego Kontenera z Serwerem tagującym, przy czym ruch hostów Kontenera kierowany jest przez Worker; ograniczenie dostępu do kont dostawców infrastruktury i do danych Kontenera; minimalizację danych (wiersze żądań bez treści, plików cookie i parametrów zapytania, przechowywane przez 90 dni, z okresem przejściowym z punktu 6); maskowanie danych Live Logs; oraz weryfikację podprocesorów. Ponieważ adresy IP Odwiedzających są przechowywane w otrzymanej postaci, Klient powinien uwzględnić to we własnej ocenie ryzyka. Dane Live Logs są maskowane przed zapisaniem (punkt 6), można je odczytać wyłącznie tokenem dostępu wydanym dla danej sesji i są usuwane po zakończeniu sesji (punkt 15).

10. Podprocesorzy

Klient udziela ogólnej zgody na korzystanie przez Operatora z podprocesorów wymienionych w Załączniku 2. O zamierzonym dodaniu lub zastąpieniu podprocesora informujemy co najmniej 30 dni wcześniej komunikatem w Usłudze i wiadomością e-mail do administratorów Organizacji, wraz z nową wersją Załącznika 2. W tym terminie Klient może zgłosić sprzeciw z uzasadnionych przyczyn dotyczących ochrony danych. Jeżeli nie uzgodnimy rozwiązania, Klient może przed dokonaniem zmiany wypowiedzieć Usługę w zakresie, którego zmiana dotyczy, bez dodatkowych opłat. Na każdego podprocesora nakładamy w umowie te same obowiązki w zakresie ochrony danych, co w niniejszej umowie, w szczególności obowiązek zapewnienia wystarczających gwarancji wdrożenia odpowiednich środków technicznych i organizacyjnych. Jeżeli podprocesor nie wywiąże się ze swoich obowiązków, Operator ponosi wobec Klienta pełną odpowiedzialność za ich wypełnienie (art. 28 ust. 4 RODO).

DigitalOcean, LLC nie hostuje Kontenerów; zapewnia centrum danych we Frankfurcie dla serwera aplikacji Operatora (Załącznik 2) jako podprocesor Laravel. Ponowne hostowanie Kontenerów w DigitalOcean wymaga powiadomienia opisanego powyżej. Podprocesorami nie są odbiorcy wybrani przez Klienta w konfiguracji GTM, Google w odniesieniu do żądań wbudowanego Google Tag Gateway, dostawcy asystentów AI łączonych przez użytkowników Klienta ani konto Cloudflare Klienta (punkt 3), a dostawcy, z których Operator korzysta jako administrator (na przykład płatności i poczta e-mail), nie otrzymują Danych Odwiedzających.

11. Transfery międzynarodowe

Operator ma siedzibę w Polsce, w EOG. Worker działa w globalnej sieci Cloudflare: żądanie jest obsługiwane w centrum danych najbliższym Odwiedzającemu, które może znajdować się poza EOG, a konfiguracja Workera, w tym filtr IP Preview Mode, jest dostępna we wszystkich centrach danych. Serwer tagujący działa w regionie Google Cloud wybranym przez Klienta dla Kontenera: domyślnie europe-west1 (Belgia), a do wyboru także us-east1 (USA) i asia-southeast1 (Singapur). Wybór regionu spoza UE przez Klienta jest jego poleceniem przekazania danych do tego państwa. Wiersze żądań wszystkich Kontenerów, niezależnie od regionu, są przechowywane w jednym zbiorze danych BigQuery w lokalizacji UE (multi-region). Serwer aplikacji i baza danych Operatora znajdują się we Frankfurcie (Niemcy). Sesja Live Logs Kontenera hostowanego w UE (jego serwer działa w chwili rozpoczęcia sesji w regionie położonym w państwie członkowskim UE) jest przechowywana w jurysdykcji UE Cloudflare; dla każdego innego Kontenera miejsce przechowywania sesji wybiera Cloudflare i może się ono znajdować poza EOG. Mechanizmy transferu do podprocesorów spoza EOG opisuje Załącznik 4.

12. Pomoc dla administratora

Uwzględniając charakter przetwarzania, pomagamy Klientowi odpowiednimi środkami w odpowiadaniu na żądania osób, których dane dotyczą, oraz w wypełnianiu obowiązków Klienta wynikających z art. 32-36 RODO (bezpieczeństwo, zgłaszanie naruszeń, oceny skutków dla ochrony danych i uprzednie konsultacje). Usługa nie identyfikuje Odwiedzających, więc wiersze żądań konkretnej osoby można odnaleźć tylko po danych, które wskaże Klient (na przykład adresie IP i okresie). Na żądanie Klienta wysłane na adres podany w punkcie 13 odnajdziemy i usuniemy takie wiersze Kontenerów Klienta albo przekażemy ich kopię w ciągu 30 dni. W Usłudze Klient może włączać i wyłączać dodatki, wybierać pliki cookie ponownie ustawiane przez Cookie Extender, decydować, czy Request Enricher przekazuje szczegółową lokalizację, zmieniać lub usuwać filtr IP Preview Mode, zatrzymać sesję Live Logs, co usuwa zarejestrowane w niej dane, zmienić klucz Same Origin Transport oraz usunąć Kontener.

13. Naruszenia ochrony danych osobowych

Powiadomimy Klienta bez zbędnej zwłoki, a w każdym razie w ciągu 48 godzin od stwierdzenia, o każdym naruszeniu ochrony danych osobowych dotyczącym Danych Odwiedzających, wiadomością e-mail wysłaną na adresy administratorów Organizacji. Powiadomienie zawiera informacje wymagane przez art. 33 ust. 3 RODO w zakresie, w jakim są wtedy dostępne, a pozostałe przekazujemy niezwłocznie w miarę ich ustalania. Klient zgłasza nam podejrzenie naruszenia oraz sprawy ochrony danych pod adresem [email protected].

14. Audyty

Udostępnimy informacje niezbędne do wykazania zgodności z art. 28 RODO oraz umożliwimy audyty, w tym inspekcje, przeprowadzane przez Klienta lub upoważnionego przez niego audytora, za rozsądnym wyprzedzeniem, z zachowaniem poufności oraz rozsądnych ograniczeń częstotliwości i kosztów. W stosownych przypadkach możemy opierać się na certyfikatach i raportach podmiotów trzecich, w tym podprocesorów.

15. Okres przechowywania, zwrot i usunięcie danych

Przechowywanie w trakcie świadczenia Usługi. Wiersze żądań w BigQuery, w tym adres IP i user agent Odwiedzającego, przechowywane są przez 90 dni. Codzienne zadanie usuwa wiersze z dni starszych niż 90 dni, gdy zostały już ujęte w zagregowanych dziennych liczbach żądań, więc wiersz może pozostać do około 92 dni od zapisania; jeżeli zadanie nie może się wykonać albo dzienne liczby nie zostały jeszcze policzone, wiersze są usuwane przy najbliższym udanym wykonaniu. Logi żądań usług Cloud Run w Google Cloud Logging są przechowywane przez 30 dni (punkt 6). Znacznik nieudanej weryfikacji Same Origin Transport wygasa jeden dzień po ostatnim zapisanym w nim nieudanym żądaniu. Po usunięciu pozostają wyłącznie zagregowane dzienne liczby żądań na Kontener: liczba żądań w podziale na Kontener, dzień i kategorię żądania (także liczba żądań automatycznych i zablokowanych), bez adresu IP, user agenta i jakiegokolwiek innego identyfikatora dotyczącego Odwiedzającego. Agregaty te nie stanowią już danych osobowych i są przechowywane bezterminowo jako podstawa statystyk zużycia i faktur. Filtr IP Preview Mode jest usuwany z konfiguracji Workera, gdy Klient wyłączy Preview Mode, a po wygaśnięciu sesji (najwyżej po 60 minutach) przez zadanie uruchamiane co minutę; Worker nie stosuje go po wygaśnięciu sesji, a po wcześniejszym wyłączeniu od chwili zapisania zmiany w jego konfiguracji. W bazie danych Operatora filtr pozostaje jako ustawienie Kontenera, dopóki Klient go nie zmieni lub nie usunie.

Live Logs. Dane zarejestrowane w sesji Live Logs są usuwane, gdy Klient zatrzyma sesję, od razu lub w ciągu minuty, a najpóźniej z chwilą wygaśnięcia sesji, nie później niż 60 minut od jej rozpoczęcia. Przez dwie godziny pozostaje jedynie znacznik zakończenia sesji, bez żadnych zarejestrowanych danych, aby spóźnione żądania były odrzucane. Baza danych Operatora przechowuje wyłącznie metadane sesji (kto i kiedy ją uruchomił, Kontener, czas trwania, podany adres strony, host i domena pliku cookie sesji, zaszyfrowany token dostępu, jurysdykcja przechowywania, moment i powód zatrzymania oraz potwierdzenie wraz z jego wersją), bez żadnych zarejestrowanych danych, i usuwa je po 90 dniach od planowanego końca sesji.

Usunięcie Kontenera i zakończenie Usługi. Gdy Klient usunie Kontener, Usługa usuwa jego usługi Cloud Run (jeżeli je ma), niestandardowe nazwy hostów i konfigurację Workera. Wiersze żądań nie są usuwane osobno: są usuwane po 90 dniach zgodnie z pierwszym akapitem, a Klient może żądać ich wcześniejszego usunięcia. Konto zamykamy na żądanie wysłane e-mailem, w ciągu 30 dni. Po zakończeniu Usługi, według wyboru Klienta zgłoszonego przed usunięciem, zwrócimy kopię wierszy żądań Kontenerów Klienta lub usuniemy Dane Odwiedzających (wiersze żądań, filtr IP Preview Mode i konfigurację Workera) w ciągu 30 dni, chyba że przechowywanie jest wymagane przez prawo. Zagregowane liczby dzienne mogą zostać zachowane, ponieważ nie są danymi osobowymi i dokumentują faktury. Na żądanie poświadczymy usunięcie.

16. Odpowiedzialność

Odpowiedzialność na podstawie niniejszej umowy powierzenia jest ustalana zgodnie z art. 82 RODO; za podprocesorów Operator odpowiada zgodnie z punktem 10. Ograniczenie odpowiedzialności określone w Regulaminie stosuje się w zakresie dozwolonym przez prawo i nie ogranicza ono praw osób, których dane dotyczą.

17. Zawarcie, zmiany i pierwszeństwo

Niniejsza umowa powierzenia podlega prawu polskiemu i RODO. Jest zawierana przy rejestracji konta: akceptując dokumenty SGTM.space, użytkownik akceptuje także niniejszą umowę, a zaakceptowane wersje i data są rejestrowane. Użytkownik, który zakłada Organizację lub działa w niej w Usłudze, zawiera tę umowę w imieniu Klienta i oświadcza, że jest do tego umocowany. Klient korporacyjny może poprosić o egzemplarz podpisany przez obie strony.

Zmiany. O istotnych zmianach informujemy komunikatem w Usłudze i jedną wiadomością e-mail; wiążą one dotychczasowych Klientów po 14 dniach od powiadomienia, a nowych Klientów od akceptacji. Zmiany wymagane przez prawo lub korzystne dla Klienta obowiązują od publikacji. Dalsze korzystanie z Usługi po tej dacie oznacza akceptację zmian; Klient, który ich nie akceptuje, może wcześniej wypowiedzieć Usługę. Zmiany podprocesorów następują zgodnie z punktem 10.

Niniejsza umowa powierzenia ma pierwszeństwo przed Regulaminem w sprawach przetwarzania danych osobowych. Rozstrzygająca jest wersja polska; wersja angielska jest tłumaczeniem, a pozostałe wersje językowe strony wyświetlają tekst angielski.

18. Załączniki

Załączniki 1-4 są częścią niniejszej umowy powierzenia.

Załącznik 1: szczegóły przetwarzania

Przedmiot i czas trwania: punkt 4. Kategorie osób: Odwiedzający, w tym testerzy (punkt 6). Charakter przetwarzania: odbieranie, przekazywanie, zapisywanie, zliczanie i usuwanie danych, w sposób ciągły przez cały okres świadczenia Usługi.

Operacja	Dane	Cel	Miejsce	Okres przechowywania
Obsługa żądań na brzegu sieci (Worker)	Adres IP, całe żądanie (adres z parametrami, nagłówki, pliki cookie, treść), kraj i kod regionu	Dostarczenie żądań do Serwera tagującego, dodatki	Cloudflare, centrum danych najbliższe Odwiedzającemu	Nie są przechowywane
Serwer tagujący i serwer podglądu (Cloud Run)	Żądanie przekazane przez Worker; dalsze przetwarzanie według konfiguracji GTM Klienta	Tagowanie po stronie serwera według konfiguracji Klienta	Google Cloud, region wybrany przez Klienta	Operator nie przechowuje; logi żądań w Cloud Logging: 30 dni
Wiersze żądań (BigQuery)	Pola wymienione w punkcie 6, bez parametrów zapytania	Zliczanie i rozliczanie, limity, wykrywanie ruchu automatycznego, statystyki	Google BigQuery, UE (multi-region)	90 dni
Dzienne liczby żądań	Liczby na Kontener, dzień i kategorię, bez danych osobowych	Statystyki zużycia i faktury	Baza danych Operatora, Frankfurt	Bezterminowo
Dodatki przekazujące dane (Request Enricher, Cookie Extender, Bot Filtering, Request Proxy)	Lokalizacja, sieć, urządzenie, wybrane pliki cookie, werdykt, zdekodowana ścieżka	Działanie dodatków włączonych przez Klienta	Cloudflare, jak wyżej	Nie są przechowywane, poza werdyktem w wierszu żądania
Preview Mode	Filtr IP testera, filtr ścieżki, żądania pasujące do filtra (bez filtra IP żądania wszystkich Odwiedzających)	Podgląd kontenera serwerowego GTM	Baza danych Operatora, Frankfurt; Cloudflare, globalnie	Sesja do 60 minut; filtr IP do zmiany lub usunięcia przez Klienta
Live Logs (gdy dostępny)	Dane opisane w punkcie 6, zamaskowane	Sprawdzenie tagów przez Klienta	Cloudflare Durable Objects, jurysdykcja UE dla Kontenera hostowanego w UE	Do końca sesji, najwyżej 60 minut; metadane 90 dni
Asystenci AI (gdy dostępni)	Podsumowanie i przefiltrowane zdarzenia sesji Live Logs, z danych opisanych w punkcie 6, zamaskowane	Umożliwienie użytkownikowi Klienta odczytu sesji Live Logs przez asystenta AI, na polecenie Klienta	Cloudflare (Durable Object sesji i Worker analizy), serwer aplikacji Operatora we Frankfurcie, następnie dostawca asystenta, odbiorca Klienta	Nie są przechowywane przez Operatora; okres przechowywania u dostawcy według jego zasad
Same Origin Transport (gdy dostępny)	Żądanie przeglądarki z dozwolonymi plikami cookie; adres IP i lokalizacja Odwiedzającego, host i ścieżka witryny w nagłówkach od Workera Klienta; znacznik site_path w wierszu żądania; znacznik nieudanej weryfikacji bez danych osobowych	Ruch tagowania ze ścieżki na stronie Klienta	Konto Cloudflare Klienta, następnie jak w pierwszym wierszu	Jak w pierwszym i trzecim wierszu; lokalizacja nie jest przechowywana; znacznik nieudanej weryfikacji: 1 dzień od ostatniej zapisanej w nim nieudanej weryfikacji
Wbudowany Google Tag Gateway Same Origin Transport (gdy dostępny)	Żądanie przeglądarki: jego adres z parametrami zapytania i treść w postaci wysłanej, nagłówki wymienione w punkcie 5 (w tym pełny nagłówek Referer) i dozwolone pliki cookie; adres IP Odwiedzającego oraz kraj i kod regionu, odpowiedź Google; wiersz żądania z kategorią gateway	Ładowanie GTM i przekazywanie żądań Google ze ścieżki na stronie Klienta do Google, odbiorcy Klienta, na polecenie Klienta	Konto Cloudflare Klienta, następnie Cloudflare jak w pierwszym wierszu, następnie Google	Nie są przechowywane, poza wierszem żądania (90 dni); Live Logs jak wyżej

Załącznik 2: podprocesorzy

Podmiot	Usługa	Dane	Lokalizacja	Podstawa transferu	Dokumenty
Cloudflare, Inc., 101 Townsend Street, San Francisco, CA 94107, USA	Workers, KV (konfiguracja Kontenerów), Durable Objects (sesje Live Logs), niestandardowe nazwy hostów z certyfikatami TLS, pamięć podręczna, DNS	Dane Odwiedzających w trakcie obsługi żądania; filtr IP Preview Mode; dane Live Logs	Globalna sieć; sesje Live Logs Kontenera hostowanego w UE w jurysdykcji UE	EU-US Data Privacy Framework oraz standardowe klauzule umowne (moduł 3) w umowie DPA Cloudflare	DPA, podprocesorzy, polityka prywatności
Google Cloud Poland sp. z o.o., Polska (podmiot umowy Google Cloud dla adresu rozliczeniowego w Polsce), z Google LLC i jej podmiotami powiązanymi jako podprocesorami	Cloud Run (Serwer tagujący i serwer podglądu), BigQuery (wiersze żądań), Cloud Logging	Żądania przekazane przez Worker; wiersze żądań	Cloud Run: region wybrany przez Klienta; BigQuery: UE (multi-region); logi Cloud Logging: 30 dni	Podmiot umowy w EOG; dalsze transfery Google na podstawie standardowych klauzul umownych (podmiot przetwarzający do podmiotu przetwarzającego, eksporter Google) oraz EU-US Data Privacy Framework (Google LLC)	DPA, podprocesorzy, polityka prywatności
Laravel Holdings Inc., 60 Broad Street, 24th Floor, #1559, New York, NY 10004, USA	Laravel VPS (serwer aplikacji i baza danych MySQL) zarządzany przez Laravel Forge	Filtr IP Preview Mode, metadane sesji Live Logs; dane Live Logs przechodzące, bez zapisywania, gdy sesję odczytuje asystent AI lub własny dostęp diagnostyczny Operatora	Serwer we Frankfurcie (Niemcy), w centrum danych DigitalOcean, LLC (USA), podprocesora Laravel	EU-US Data Privacy Framework według polityki prywatności Laravel; umowa powierzenia Laravel Forge (Data Processing Agreement)	polityka prywatności, DPA

Załącznik 3: środki techniczne i organizacyjne

• Szyfrowanie w trakcie przesyłania: połączenia HTTPS z hostami Kontenerów korzystają z certyfikatów wystawianych przez Cloudflare, z TLS co najmniej w wersji 1.2; Worker łączy się z Serwerem tagującym i BigQuery przez HTTPS.
• Szyfrowanie w spoczynku: Google Cloud i Cloudflare szyfrują przechowywane dane domyślnie, według ich dokumentacji; baza danych Operatora leży na lokalnym dysku serwera aplikacji, którego dostawca hostingu nie szyfruje w spoczynku, a jej codzienne kopie zapasowe są przechowywane w postaci zaszyfrowanej poza tym serwerem. Tokeny podglądu GTM, tokeny dostępu Live Logs, klucze Same Origin Transport i tokeny połączenia Cloudflare są w bazie danych Operatora zaszyfrowane, a konfiguracja Workera zawiera tylko skrót klucza Same Origin Transport.
• Minimalizacja danych: wiersze żądań bez treści, plików cookie i parametrów zapytania (z okresem przejściowym z punktu 6) oraz z nagłówkiem Referer bez parametrów; kraj, region i dane Request Enricher nie są zapisywane; codzienne usuwanie wierszy po 90 dniach; maskowanie danych Live Logs przed zapisaniem.
• Rozdzielenie Kontenerów: osobne usługi Cloud Run dla każdego Kontenera z Serwerem tagującym; osobna konfiguracja Workera dla każdego hosta; ruch hostów Kontenera kierowany przez Worker.
• Kontrola dostępu: dostęp do danych Kontenera w Usłudze mają członkowie Organizacji oraz upoważnieni administratorzy Operatora, a rozliczenia zastrzeżone są dla administratorów Organizacji; logowanie hasłem, kluczem dostępu (passkey), przez Google lub GitHub; dostęp do kont Google Cloud, Cloudflare i Laravel Forge ograniczony do upoważnionych osób Operatora; zapis do BigQuery przez konto serwisowe, którego klucz jest przechowywany jako sekret Workera.
• Live Logs: odczyt danych sesji wyłącznie tokenem wydanym dla danej sesji; usunięcie danych po zakończeniu sesji.
• Asystenci AI: asystent łączy się przez OAuth 2.1 z PKCE, po zatwierdzeniu tej aplikacji przez użytkownika na ekranie zgody Operatora; jego tokeny dostępu wygasają po 60 minutach i przestają działać od razu, gdy użytkownik odłączy aplikację; ma dostęp tylko do tego, do czego jego użytkownik ma dostęp w Usłudze, według tych samych zasad dostępu.
• Same Origin Transport: nagłówkom od Workera Klienta Worker ufa tylko przy zgodnym skrócie SHA-256 klucza Kontenera, porównywanym w stałym czasie, a bez niego traktuje żądanie jako niezweryfikowane; po rzeczywistym problemie z bezpieczeństwem starszych wersji Workera Klienta wersja minimalna z terminem co najmniej 30 dni późniejszym, po którym adres IP i lokalizacja Odwiedzającego od starszego Workera nie są już traktowane jako wiarygodne; klucz ma 32 losowe bajty i Klient może go w każdej chwili zmienić; wbudowany Google Tag Gateway obsługuje wyłącznie ruch ze zweryfikowanym kluczem, przekazuje w obie strony tylko wymienione nagłówki i pliki cookie i nigdy nie podaje HTML Google.
• Kopie zapasowe i odtwarzanie: codzienna kopia bazy danych Operatora, przechowywana w postaci zaszyfrowanej poza serwerem aplikacji przez 14 dni; aplikację i Worker wdraża się ponownie z repozytorium kodu.
• Obsługa incydentów: procedura z punktu 13.
• Podprocesorzy: umowy z każdym podprocesorem z Załącznika 2 obejmujące obowiązki z art. 28 RODO.

Załącznik 4: mechanizm transferu

Operator ma siedzibę w EOG, więc przekazanie danych przez Klienta do Operatora nie jest transferem poza EOG. Transfery do podprocesorów spoza EOG odbywają się na podstawie mechanizmów zawartych w ich umowach:

• Cloudflare, Inc. (USA): certyfikacja w ramach EU-US Data Privacy Framework oraz standardowe klauzule umowne Komisji Europejskiej, moduł 3 (podmiot przetwarzający do podmiotu przetwarzającego), zawarte w umowie DPA Cloudflare.
• Google: podmiotem umowy jest Google Cloud Poland sp. z o.o. w EOG; transfery Google do Google LLC i innych podprocesorów spoza EOG, w tym przy regionie Kontenera spoza UE wybranym przez Klienta, odbywają się na podstawie standardowych klauzul umownych Google (podmiot przetwarzający do podmiotu przetwarzającego, eksporter Google) oraz certyfikacji Google LLC w ramach EU-US Data Privacy Framework.
• Laravel Holdings Inc. (USA): certyfikacja w ramach EU-US Data Privacy Framework według polityki prywatności Laravel oraz umowa powierzenia Laravel Forge; DigitalOcean, LLC zapewnia centrum danych serwera we Frankfurcie jako podprocesor Laravel.

Status certyfikacji można sprawdzić na liście Data Privacy Framework. Standardowe klauzule umowne są częścią umów podprocesorów dostępnych pod powyższymi linkami; Operator nie dołącza ich tekstu do niniejszej umowy.

W sprawach ochrony danych skontaktuj się z BEO Technology sp. z o.o. pod adresem [email protected].