Niniejszy dokument jest publikowany w kilku wersjach językowych. W razie rozbieżności między wersjami językowymi wiążąca jest wersja polska.
Wersja 1.2 · Stan na: 29 października 2026 r.
1. Jak czytać ten rejestr
Jest to rejestr czynności przetwarzania prowadzony zgodnie z art. 30 RODO dla formexposed. Nie jest to polityka prywatności ani materiał reklamowy. Jego zadaniem jest pokazać organowi nadzorczemu, Klientowi, który sprawdza nas jako podmiot przetwarzający, albo kolejnej osobie, która musi odpowiedzieć na jakieś pytanie, co faktycznie jest przetwarzane, gdzie się znajduje, kto to otrzymuje i jak długo jest przechowywane. Publikujemy go, ponieważ usługa sprawdzania i monitorowania formularzy sama powinna dać się sprawdzić.
Przy jego sporządzaniu kierowaliśmy się trzema zasadami.
- Zmierzone, a nie zamierzone. Twierdzenie o polach danych, terminach, odbiorcach lub środkach ochrony pojawia się tylko tam, gdzie potwierdza je kod programu, schemat bazy danych albo pomiar. To, co jest planowane, nazywamy „planowanym”. To, co jest fabrycznie wyłączone, nazywamy „fabrycznie wyłączonym”. Tam, gdzie czegoś nie możemy wykazać, mówimy o tym.
- Okres przechowywania podajemy dwukrotnie. Raz przy każdej czynności przetwarzania i raz w sekcji 6 jako obraz całości: który nocny przebieg usuwa jakie dane i których danych nie obejmuje. Rejestr, który podaje termin usunięcia obowiązujący tylko dla części danych, jest gorszy od rejestru, który wskazuje otwartą kwestię.
- Otwarte kwestie są w tekście, a nie w przypisie. Sekcja 8.1 wymienia środki, które nie zostały jeszcze wdrożone, sekcja 10 – otwarte kwestie wraz z planowanymi środkami. Rejestr jest narzędziem pracy, a nie zaświadczeniem.
Pola danych zamiast nazw tabel. Przy każdej czynności przetwarzania podajemy przechowywane dane jako zrozumiałe pola. Nazwa tabeli w bazie danych stoi za nimi w nawiasie, aby kontrolujący mógł znaleźć to miejsce, na przykład „próby logowania (login_attempts)”. Listy pól wyprowadzono ze schematu bazy danych, a nie z pamięci.
Terminy jako symbole zastępcze. Tam, gdzie termin można ustawić w panelu administracyjnym, podajemy go tutaj tak, jak odczytuje go nocny przebieg: liczba, którą Państwo widzą, pochodzi z tego samego ustawienia, według którego dane są usuwane. Terminy zapisane na stałe w programie podajemy jako liczbę.
Podstawa pomiaru. Schemat, kod i ustawienia zmierzono 11 października 2026 r. w systemie deweloperskim, który pod względem kodu i schematu odpowiada systemowi produkcyjnemu. Nie podajemy liczby wierszy z systemu deweloperskiego; zawierają one dane testowe i nic nie mówią o działaniu produkcyjnym.
Celowo pominięte. Ten rejestr nie podaje nazw komputerów, wewnętrznych adresów sieciowych, portów, nazw użytkowników ani wersji oprogramowania naszych serwerów. Takie informacje pomagają atakującemu, a nie osobie, której dane dotyczą. Z tego samego powodu otwarte kwestie zabezpieczenia naszych własnych serwerów opisujemy tylko ogólnie (sekcja 8.1): nazywamy ryzyko, ale nie drogę do niego. Organowi nadzorczemu przedstawimy szczegóły na żądanie.
Charakter prawny. Ten rejestr jest dokumentacją, którą prowadzimy zgodnie z art. 30 RODO na potrzeby organu nadzorczego; publikujemy go dobrowolnie. Nie stanowi części umowy i nie stanowi zapewnienia, gwarancji ani uzgodnienia właściwości wobec Klientów lub osób trzecich. Nasze zobowiązania wobec Klientów określają Regulamin, Umowa powierzenia przetwarzania danych i jej załączniki; w zakresie tych obowiązków mają one pierwszeństwo przed niniejszym rejestrem. Rejestr opisuje stan na dzień niniejszej wersji. Kwalifikacje takie jak „otwarta kwestia” lub „ocena” wyrażają naszą własną ocenę i nie przesądzają o ocenie prawnej dokonanej przez organ nadzorczy lub sąd; środki określone jako „planowane” są zamierzeniami bez przyrzeczonego terminu.
2. Podmiot prawny i dlaczego ten rejestr ma dwie części
| Pole | Wpis |
|---|
| Podmiot prawny | LW IT Solutions Company Lukas Wójcik, jednoosobowa działalność gospodarcza wpisana do Centralnej Ewidencji i Informacji o Działalności Gospodarczej (CEIDG); właściciel Lukas Wójcik |
| Adres | al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polska |
| Identyfikatory podatkowe | NIP 7252266190, NIP UE PL7252266190 |
| Kontakt | contact@lukaswojcik.com; okno wsparcia (znak zapytania w nawigacji); strona kontaktowa |
| Usługa | formexposed: sprawdzanie, monitorowanie i zabezpieczanie formularzy kontaktowych na stronach internetowych (aplikacja pod adresem formexposed.com, strona docelowa pod adresem form.exposed) |
| Przedstawiciel na podstawie art. 27 RODO | Nie dotyczy. Podmiot prawny ma siedzibę w Unii (w Polsce). |
| Inspektor ochrony danych | Niewyznaczony. Ocena na podstawie art. 37 znajduje się w sekcji 9. |
| Właściwy organ nadzorczy | Prezes Urzędu Ochrony Danych Osobowych (Prezes UODO), ul. Moniuszki 1A, 00-014 Warszawa |
| Hosting | Własne serwery w Polsce: serwer WWW z aplikacją i bazą danych oraz serwer skanujący z lokalnym modelem językowym w tej samej sieci wewnętrznej. Bez centrum danych ani dostawcy chmury będącego podmiotem trzecim. |
Wobec różnych grup osób formexposed pełni różne role. Kto je pomiesza, otrzyma rejestr, który nie zgadza się dla żadnej z grup.
- Administrator (część B, art. 30 ust. 1). Za dane naszych własnych Klientów i członków ich zespołów (konto, logowanie, rozliczenia, wsparcie, dzienniki), za osoby odwiedzające naszą własną stronę, za sprawdzenia bez konta (bezpłatne sprawdzenie, narzędzie do nagłówków, badanie, sprawdzenie potencjalnego klienta) oraz za przeciwdziałanie nadużyciom odpowiadamy sami.
- Podmiot przetwarzający (część A, art. 30 ust. 2). W odniesieniu do danych osobowych osób trzecich, które Klient wprowadza do usługi lub które powstają przy świadczeniu usługi na jego rzecz, działamy w jego imieniu: kopie prawdziwych wiadomości z formularzy w kontroli doręczenia, subskrybenci jego portalu klienta, odbiorcy jego alertów, osoby przypadkowo widoczne na sprawdzanych stronach, dane dostępowe jego konta testowego, wklejony przez niego kod formularza. Podstawą jest umowa powierzenia przetwarzania danych, zawierana ze wszystkimi Klientami przy rejestracji.
- Wyłącznie u Klienta. Niektóre funkcje wtyczki do WordPressa i rozszerzenia do TYPO3 przetwarzają dane wyłącznie na stronie Klienta, a dane te do nas nie docierają (kwarantanna, siatka bezpieczeństwa, zagadka matematyczna, okresy przechowywania, lokalne liczniki, rejestrator). Nie są one przetwarzaniem przez nas i dlatego nie figurują w żadnej z dwóch części. Opisujemy je jednak na końcu części A, aby granica była widoczna.
Podział jest zapisany w kodzie, a nie tylko w tekście: kontrola doręczenia zapisuje z prawdziwej wiadomości z formularza do bazy danych tylko czas, przypisanie i wynik uwierzytelnienia; zrzuty ekranu ze sprawdzeń w przeglądarce maskują pola wprowadzania; dane dostępowe konta testowego są szyfrowane tak, że serwer WWW nie może ich już odczytać. Szczegóły znajdują się przy poszczególnych wpisach.
Sekcje 6–11 dotyczą obu części: przechowywanie, zautomatyzowane podejmowanie decyzji, środki techniczne i organizacyjne, inspektor ochrony danych, otwarte kwestie i aktualizacja tego rejestru.
Zakres. Ten dokument jest częścią rejestru dotyczącą usługi formexposed. Czynności przetwarzania tego samego podmiotu dotyczące innych usług są ujęte w ich własnym rejestrze; ogólna księgowość i administracja przedsiębiorstwem poza usługą nie są przedmiotem tej części.
3. Część A – art. 30 ust. 2: czynności przetwarzania w imieniu Klientów
A.0 Strony
| Pole | Wpis |
|---|
| Podmiot przetwarzający | LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polska; contact@lukaswojcik.com |
| Administratorzy | Klienci formexposed: przedsiębiorstwa i agencje, które prowadzą domeny na koncie i korzystają z funkcji, przy których powstają dane osób trzecich. W przypadku agencji administratorem może być dodatkowo jej klient końcowy; agencja działa wówczas wobec niego jako podmiot przetwarzający, a my jako dalszy podmiot przetwarzający. |
| Wykaz administratorów | Część niniejszego rejestru, prowadzona w formie elektronicznej (art. 30 ust. 3 RODO) w systemie usługi i niezamieszczona w tej publicznej wersji, ponieważ zawiera dane osobowe Klientów i dezaktualizowałaby się z każdym nowym Klientem: właściciel każdego obszaru roboczego z imieniem i nazwiskiem, adresem e-mail i firmą z konta Klienta (adres i numer NIP UE tylko w Stripe) (users, workspaces, workspace_users), a także domeny obszaru roboczego (domains). Organowi nadzorczemu udostępnimy go na żądanie w formie wyciągu. |
| Przedstawiciele i inspektorzy ochrony danych administratorów | Osobnego pola na te dane w systemie nie ma. Jeżeli Klient wyznaczył przedstawiciela zgodnie z art. 27 RODO lub inspektora ochrony danych, może nam go wskazać; tę informację prowadzimy razem z wykazem administratorów. |
| Przedstawiciel podmiotu przetwarzającego | Nie dotyczy (siedziba w Polsce). |
| Inspektor ochrony danych | Niewyznaczony (sekcja 9). |
| Polecenia | Polecenie wynika z umowy powierzenia przetwarzania danych oraz z ustawień, których Klient dokonuje sam: włącza kontrolę doręczenia, zakłada cele alertów, zapisuje konto testowe, konfiguruje portal klienta. Bez tej czynności dane przetwarzanie nie ma miejsca. |
| Środki techniczne i organizacyjne | Sekcja 8 oraz strona Środki techniczne i organizacyjne dotyczą każdej czynności przetwarzania w części A. Środki szczególne podano przy danym wpisie. |
A.1 Kontrola doręczenia – kopia kontrolna wiadomości z formularzy
| Pole | Wpis |
|---|
| Cel | Sprawdzenie, czy wiadomość z formularza kontaktowego Klienta jest faktycznie wysyłana i jak jest uwierzytelniona (SPF, DKIM, DMARC, zgodność domen). Po przyjętym aktywnym zgłoszeniu testowym jego kopia musi dotrzeć do skrzynki kontrolnej w ustawialnym czasie oczekiwania (obecnie 3 godziny); w przeciwnym razie powstaje alert „Wiadomość testowa nie dotarła”. Z nagłówków ustala się ponadto autentyczność wiadomości z formularza, używaną usługę pocztową oraz adres wysyłki na potrzeby sprawdzenia na listach blokujących. |
| Warunek | Płatny plan, zweryfikowana domena, włączenie przez Klienta. Klient wpisuje własny adres kontrolny z identyfikatorem (w postaci „delivery+identyfikator@…”) jako ukrytą kopię (UDW) w powiadomieniu swojego formularza. Bez skonfigurowanej skrzynki kontrolnej funkcja jest niedostępna. |
| Kategorie osób, których dane dotyczą | Osoby odwiedzające stronę Klienta, które wysyłają jego formularz; osoby, których dane odwiedzający wpisuje do wiadomości; pracownicy Klienta wskazani w nagłówkach jako odbiorcy. |
| Kategorie danych osobowych | W skrzynce kontrolnej (u dostawcy poczty e-mail): pełna kopia każdej wiadomości z formularza, a więc także prawdziwych zapytań z imieniem i nazwiskiem, adresem e-mail, numerem telefonu i tekstem dowolnym, do czasu usunięcia. Odczytywane przy pobieraniu: nagłówki i najwyżej pierwsze 8 KB treści. W bazie danych: czas wpływu, przypisanie do domeny i ewentualnie do przebiegu testowego (delivery_log); ostatni wynik uwierzytelnienia dla każdej domeny z wynikiem SPF, DKIM i DMARC, zgodnością domen, domeną nadawcy, domenami podpisującymi i adresem wysyłającego serwera pocztowego (pole autentyczności domeny w domains). Treść, temat i adres nadawcy będącego odwiedzającym nie są zapisywane w bazie danych. |
| Uwaga dotycząca domeny nadawcy | Jeżeli formularz wpisuje adres odwiedzającego jako nadawcę (błąd konfiguracji, który sprawdzenie ma właśnie wykryć), w wyniku uwierzytelnienia figuruje domena tego adresu, a nie sam adres. W przypadku prywatnej domeny odwiedzającego także ona może być daną osobową. Zostaje nadpisana przy następnym wpływie. |
| Źródło | Formularz na stronie Klienta, za pośrednictwem ukrytej kopii wpisanej przez Klienta. |
| Podstawa prawna (określana przez administratora) | Określa ją Klient. Nasza propozycja tekstu do jego polityki prywatności opiera kopię na art. 6 ust. 1 lit. f RODO (prawnie uzasadniony interes w niezawodnym otrzymywaniu zapytań). Klient informuje odwiedzających o tym przepływie danych; zobowiązuje go do tego umowa powierzenia przetwarzania danych. |
| Odbiorcy | Dostawca poczty e-mail prowadzący skrzynkę kontrolną (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). Kopia trafia bezpośrednio tam: dociera tylko wtedy, gdy rekordy MX naszej domeny wskazują na tę skrzynkę (sprawdza to lista kontrolna przed startem); przez przekierowanie nie dociera do skrzynki. Klient widzi na stronie domeny tylko czas, przypisanie i wynik uwierzytelnienia. Jeżeli wynik uwierzytelnienia się pogorszy, alert wysyłany do Klienta i do wybranych przez niego kanałów podaje domenę nadawcy, jeżeli nie należy ona do strony (A.3, 4.1). |
| Państwo trzecie | Zależnie od dostawcy poczty e-mail; zob. sekcja 4. Umowa z przewidzianym dostawcą i podstawa przekazania nie są jeszcze udokumentowane. |
| Okres przechowywania | Po pomyślnym przetworzeniu wiadomość jest oznaczana do usunięcia i w tym samym przebiegu usuwana ze skrzynki, także wtedy, gdy nie da się jej przypisać do żadnej domeny. Pobieranie odbywa się w ramach przebiegu statusowego co pięć minut, dopóki monitorowanie jest włączone w panelu administracyjnym (srv/cron_status.php, cfg/zustellung_lib.php). Jeżeli pobranie lub usunięcie się nie powiedzie, wiadomość pozostaje w skrzynce do następnego udanego przebiegu. Przypisania w delivery_log ten sam proces pobierania usuwa po 180 dniach. Wynik uwierzytelnienia istnieje tak długo jak domena. |
| Czego dowodzi potwierdzenie | Wyłącznie wpływu do skrzynki kontrolnej kopii przypisanej do konkretnego przebiegu testowego. Nie dowodzi ono ani dotarcia do właściwego odbiorcy, ani wpisu w CRM. Natywne potwierdzenie z HubSpot nie jest oferowane. |
| Środki techniczne i organizacyjne | Sekcja 8. W szczególności: treść jest analizowana wyłącznie w pamięci operacyjnej; brak zapisu tekstu, tematu ani pełnych adresów nadawców; usunięcie niezależnie od tego, czy przypisanie się powiodło. |
Kontrola doręczenia jest jedyną funkcją, w ramach której trafiają do nas prawdziwe wiadomości od osób odwiedzających strony naszych Klientów. Dlatego jest ona powierzeniem przetwarzania, a nie usługą świadczoną na własną odpowiedzialność, i dlatego właściwą miarą ryzyka jest czas przebywania w skrzynce: w normalnym przypadku są to minuty, w razie zakłócenia pobierania – tak długo, aż znów zacznie działać. Kopie nie powinny zawierać szczególnych kategorii danych osobowych; technicznie nie możemy temu zapobiec, ponieważ o tym, co pisze odwiedzający, decyduje on sam.
A.2 Portal klienta i raport miesięczny dla subskrybentów
| Pole | Wpis |
|---|
| Cel | Agencja (plan Business) pokazuje swoim klientom końcowym pod własną marką stan ich domen (portal pod losowym adresem, opcjonalnie z hasłem, opcjonalnie pod własną subdomeną agencji). Klient końcowy może tam sam zamówić miesięczny raport wysyłany e-mailem. Raport jest wysyłany w imieniu agencji. |
| Kategorie osób, których dane dotyczą | Klienci końcowi agencji i ich pracownicy, którzy zamawiają raport; osoby otwierające portal. |
| Kategorie danych osobowych | Subskrybent: adres e-mail, język, identyfikator potwierdzenia, czas zamówienia i adres IP przy zamówieniu, czas potwierdzenia (double opt-in), czas wypisania się, ostatnio wysłany miesiąc (client_subscribers). Portal: nazwa, wybór domen, losowy identyfikator, hasło wyłącznie jako skrót (hash), osoba zakładająca, czas, odwołanie (client_portals). Wywołania portalu pojawiają się w dzienniku odsłon (B.2). |
| Źródło | Wprowadzone przez samego subskrybenta w portalu. |
| Podstawa prawna (określana przez administratora) | Zgoda subskrybenta uzyskana w procedurze double opt-in; administratorem jest agencja. Nie piszemy do nikogo, kto sam się nie zapisał i tego nie potwierdził. |
| Odbiorcy | Agencja (widzi swoich subskrybentów); dostawca poczty e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) w zakresie wiadomości potwierdzającej i raportu. |
| Państwo trzecie | Za pośrednictwem dostawcy poczty e-mail; zob. sekcja 4. |
| Okres przechowywania | Nocny przebieg usuwania (cfg/fristen_lib.php, część „subskrybenci portalu”): nigdy niepotwierdzone zamówienia po 30 dniach; wypisani subskrybenci trzy lata po wypisaniu się, jako dowód wcześniejszej zgody. Potwierdzeni, niewypisani subskrybenci pozostają tak długo, jak istnieje obszar roboczy agencji. Odwołany portal jest tylko blokowany, a nie usuwany; jego subskrybenci nie otrzymują już raportów, ale ich dane pozostają (sekcja 10). Wraz z obszarem roboczym portale i subskrybenci są usuwani natychmiast (fe_arbeitsbereich_daten_loeschen()). Wysłane raporty pozostają w skrzynce nadawczej przez 30 dni (B.25). |
| Środki techniczne i organizacyjne | Sekcja 8. W szczególności: hasło do portalu wyłącznie jako skrót (hash), próby odgadnięcia ograniczone (dziesięć na portal i adres IP, 50 na portal w ciągu 15 minut); wypisanie się jednym kliknięciem w każdej wiadomości; portal pokazuje tylko stan i wskaźniki, bez pojedynczych ustaleń z dowodami. |
A.3 Odbiorcy alertów, osoby potwierdzające i osoby odpowiedzialne po stronie Klienta
| Pole | Wpis |
|---|
| Cel | Powiadomienia o zakłóceniach i zmianach wysyłane do celów, które Klient zakłada dla domeny: e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Dla każdego celu natychmiast albo zbiorczo codziennie lub co tydzień, a także cele wyłącznie dla eskalacji. Każde powiadomienie o problemie staje się incydentem, którego przyjęcie odbiorca może potwierdzić za pomocą linku. Dla monitorowanych formularzy Klient może wyznaczyć osobę odpowiedzialną i termin. |
| Kategorie osób, których dane dotyczą | Pracownicy i usługodawcy Klienta, których wpisuje on jako cel alertów lub wskazuje jako osoby odpowiedzialne; osoby potwierdzające incydent. Członkowie zespołu z własnym kontem figurują dodatkowo w części B. |
| Kategorie danych osobowych | Cel alertu: kanał, adres docelowy (adres e-mail, adres webhooka lub czatu, identyfikator czatu Telegram), wybrane zdarzenia, tryb wysyłki, sekret podpisu dla webhooków, ostatnia wysyłka i ostatni błąd (alerts). Dziennik wysyłki: cel, zdarzenia, status, błąd, czas (alert_log). Kolejka zbiorcza: wiersze powiadomień i link do czasu wysyłki (alert_queue). Incydent: tytuł, wiersze powiadomienia, link, identyfikator potwierdzenia, czas oraz imię i nazwisko lub adres e-mail osoby potwierdzającej w postaci wpisanej w formularzu, a w przeciwnym razie adres zalogowanego członka (alert_incidents). Próby doręczenia eskalacji dla każdego incydentu i celu: liczba prób (najwyżej pięć), czas ostatniej i następnej próby oraz powodzenia, odwołanie do wiadomości e-mail w skrzynce nadawczej, błąd (tabela alert_escalation_deliveries). Odpowiedzialność: konto osoby odpowiedzialnej i termin (w monitored_forms). |
| Treść powiadomień | Domena, zdarzenie, krótkie objaśnienie i link do strony domeny. Bez treści wiadomości od odwiedzających. |
| Źródło | Wpisane przez Klienta; osoba potwierdzająca sama wpisuje swoje imię i nazwisko; identyfikator czatu Telegram powstaje, gdy odbiorca naciśnie w bocie „Start” (B.32). |
| Podstawa prawna (określana przez administratora) | Określa ją Klient; zwykle organizacja jego własnych procesów (art. 6 ust. 1 lit. b lub f RODO w relacji z jego pracownikami i usługodawcami). |
| Odbiorcy | Operatorzy wybranych kanałów; zob. 4.1. Alerty e-mail za pośrednictwem dostawcy poczty e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Państwo trzecie | Zależnie od wybranego kanału; kilku dostawców ma siedzibę w USA, Telegram poza UE bez decyzji stwierdzającej odpowiedni stopień ochrony. Zob. 4.1. |
| Okres przechowywania | Dziennik wysyłki po 90 dniach (co noc, fe_alert_log_aufraeumen() z srv/cron_status.php). Powiadomienia zbiorcze 30 dni po wysyłce (cfg/kanal_lib.php, przy każdej wysyłce zbiorczej). Incydenty do czasu rozwiązania; rozwiązane 180 dni po rozwiązaniu (cfg/vorfall_lib.php, przebieg eskalacji), a wraz z nimi próby doręczenia eskalacji. Cele alertów i przypisania odpowiedzialności do usunięcia przez Klienta lub wraz z domeną. |
| Środki techniczne i organizacyjne | Sekcja 8. W szczególności: webhooki z podpisem opartym na odrębnym sekrecie dla każdego celu; potwierdzenie dopiero po kliknięciu (POST), aby podglądy linków w komunikatorach niczego nie wywoływały; alerty w fazie konserwacji są tylko rejestrowane, a nie wysyłane. |
A.4 Osoby przypadkowo widoczne na sprawdzanych stronach Klientów i na zrzutach ekranu
| Pole | Wpis |
|---|
| Cel | Sprawdzenie domen na koncie Klienta (skan, monitorowanie, sprawdzenie aktywne) odczytuje jego publiczne strony i wykonuje zdjęcia formularzy. To, co strona sama wyświetla, może dotyczyć osób, które nie mają nic wspólnego ze sprawdzeniem. Dane te powstają przy okazji; nie są celem sprawdzenia. |
| Kategorie osób, których dane dotyczą | Osoby, których imię i nazwisko, zdjęcie lub dane kontaktowe znajdują się na sprawdzanej stronie (osoba kontaktowa obok formularza, zdjęcia zespołu na stronie głównej, dane w nocie prawnej). |
| Kategorie danych osobowych | Zrzuty ekranu: widoczny obszar strony głównej, każdy widoczny formularz jako wycinek oraz obraz strony następnej po aktywnym zgłoszeniu testowym; przechowywane jako pliki poza katalogiem WWW, w bazie danych tylko odwołanie (scan_screenshots). Struktura formularza: adres strony, selektor, nazwy pól, typy pól, etykiety pól, cecha wymagalności i widoczności, etykiety przycisków wysyłania (forms, pole „mapa pól”); bez wartości pól. Początek pól ukrytych (do 24 znaków) i atrybuty danych (do 60 znaków) skaner odczytuje tylko w trakcie sprawdzenia, aby rozpoznać znaczniki czasu i tokeny; zapisywany jest tylko wynik. Ustalenia z dowodami (findings), podsumowanie z tytułami stron (scans). W przypadku kwalifikujących się sprawdzeń na kontach płatnych lokalny model generuje plan działań według priorytetów na podstawie wybranych ustaleń i metadanych skanu; jego tekst, język, status i znacznik czasu są zapisywane w podsumowaniu skanu. Jeżeli w formularzu jako odbiorca figuruje adres e-mail, zapisywana jest tylko jego domena, nigdy adres. |
| Źródło | Publiczne strony domeny Klienta pobrane przez skaner. |
| Podstawa prawna (określana przez administratora) | Określa ją Klient w odniesieniu do treści swojej własnej strony. Dla nas przetwarzanie jest częścią zleconego sprawdzenia. |
| Odbiorcy | Klient; w przypadku agencji jej klient końcowy przez portal lub raport white label; każdy, kto otrzyma link do raportu (raporty pod losowymi adresami, nieindeksowane w wyszukiwarkach). Lokalny model językowy na własnym serwerze otrzymuje przy niejasnym typie formularza strukturę formularza wraz z tytułem strony, adresem strony i widocznym tekstem formularza (do 400 znaków) w celu jego zaklasyfikowania; obrazów nie otrzymuje. W przypadku kwalifikujących się płatnych sprawdzeń lokalny model otrzymuje również nazwę hosta, ogólny wynik i wynik punktowy, CMS, typ miarodajnego formularza i adres jego strony, ewentualną rozpoznaną wtyczkę oraz wybrane ustalenia z wynikiem negatywnym lub niejasnym w celu sporządzenia planu działań. Zapytanie jest tymczasowo przechowywane w wewnętrznej kolejce zleceń i usuwane po odebraniu wyniku lub przez zaplanowane czyszczenie wpisów starszych niż jedna godzina. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Wyniki sprawdzeń domeny najwyżej 13 miesięcy; ostatnie zakończone sprawdzenie każdej domeny pozostaje (nocny przebieg usuwania, część „stare wyniki sprawdzeń”). Wraz z wynikiem sprawdzenia usuwane są formularze, ustalenia, odwołania do obrazów i pliki obrazów. Wraz z domeną dane te są usuwane natychmiast (łańcuch usuwania w B.15; wyjątki w sekcji 6.4). |
| Granica maskowania | Zrzuty ekranu z pełnego sprawdzenia niczego nie maskują: pokazują to, co strona pokazuje każdemu odwiedzającemu. Pola formularzy są przy pobraniu puste, ponieważ skaner niczego nie wpisuje; wartości wstępnie wypełnione byłyby widoczne. Za logowaniem nie są wykonywane zrzuty ekranu (A.5). Obrazy ze sprawdzeń w przeglądarce maskują pola wprowadzania (A.6). |
| Środki techniczne i organizacyjne | Sekcja 8. W szczególności: obrazy dostępne wyłącznie przez raport, cudzy identyfikator obrazu zwraca „nie znaleziono”; raporty z noindex; każde sprawdzenie przebiega we własnym, odizolowanym kontenerze. |
Przy sprawdzeniach bez konta (bezpłatne sprawdzenie, badanie, sprawdzenie potencjalnego klienta) powstają te same dane. Nie ma tam Klienta, w którego imieniu działamy; przypadki te figurują zatem w części B (B.5, B.7, B.8).
A.5 Dane dostępowe konta testowego do skanu za logowaniem
| Pole | Wpis |
|---|
| Cel | Odczyt formularzy, które pojawiają się dopiero po zalogowaniu (strefa klienta, strefa członkowska). Skaner loguje się kontem testowym, które Klient założył na swojej własnej stronie, i odczytuje wskazane strony. Poza formularzem logowania niczego nie wysyła, nie przeprowadza tam testu aktywnego, nie wykonuje zrzutów ekranu i nie odwiedza adresów wylogowania, usunięcia konta ani wypowiedzenia. Jeżeli formularz logowania zawiera CAPTCHA, skaner przerywa działanie; CAPTCHA nie są obchodzone. |
| Warunek | Zweryfikowana domena, płatny plan, rola właściciela lub admina, wyraźne potwierdzenie, że chodzi o konto testowe. Najwyżej pięć stron, wszystkie w tej samej domenie. |
| Kategorie osób, których dane dotyczą | Osoba, na którą zarejestrowane jest konto testowe (nie powinna to być żadna osoba; Klient powinien użyć konta funkcyjnego); osoby, których dane znajdują się na stronach za logowaniem. |
| Kategorie danych osobowych | Nazwa użytkownika i hasło konta testowego, wyłącznie w postaci zaszyfrowanej; wskazówka dotycząca nazwy użytkownika (pierwszy znak i długość); adres logowania, lista stron, nazwy pól logowania, znacznik powodzenia, osoba zakładająca, znaczniki czasu, ostatni wynik jako krótki kod (domain_logins). Dla bieżącego zlecenia kopia szyfrogramu (pole „pakiet logowania” w scan_jobs). Ze stron za logowaniem: struktura formularza jak w A.4, bez zrzutów ekranu i bez plików cookie. |
| Źródło | Wprowadzone przez Klienta na koncie. |
| Podstawa prawna (określana przez administratora) | Określa ją Klient. Zapewnia on, że ma prawo dysponować kontem testowym. |
| Odbiorcy | Brak. Ani Klient, ani wsparcie, ani interfejs programistyczny nie mogą odczytać danych dostępowych; interfejs pokazuje tylko wskazówkę dotyczącą nazwy użytkownika. |
| Państwo trzecie | Brak. |
| Ochrona danych dostępowych | Nazwa użytkownika i hasło są natychmiast przy zapisie szyfrowane kluczem publicznym serwera skanującego (X25519, HKDF-SHA256, AES-256-GCM; domena jest powiązana jako dane dodatkowe, szyfrogramu nie da się przypiąć do innej domeny). Klucz prywatny ma wyłącznie serwer skanujący. Serwer WWW, baza danych i kopie zapasowe zawierają wyłącznie szyfrogram; także my nie możemy go tam odszyfrować. Serwer skanujący odszyfrowuje dane dopiero na potrzeby przebiegu, przekazuje dane dostępowe do odizolowanego kontenera sprawdzającego wyłącznie przez standardowe wejście, natychmiast usuwa kopię w zleceniu i nie zapisuje ich w żadnym wyniku, dzienniku ani komunikacie o błędzie. W drodze do strony Klienta chroni je tylko szyfrowanie tej strony; granice tego transportu opisano w sekcji 10. |
| Okres przechowywania | Zapisane dane dostępowe do usunięcia przez Klienta. Przy usuwaniu szyfrogram jest nadpisywany losowymi danymi tej samej długości, a wiersz usuwany; oczekujące zlecenia są czyszczone (fe_login_loeschen()). Wraz z domeną wiersz jest usuwany przez klucz obcy. Kopie w zleceniach serwer skanujący czyści po przebiegu; to, co pozostanie (zlecenie przerwane, awaria serwera skanującego), przebieg statusowy czyści najpóźniej po godzinie (fe_login_aufraeumen(), część „login_jobs”). W kopiach zapasowych bazy danych szyfrogram pozostaje do wygaśnięcia kopii po 14 dniach. |
| Środki techniczne i organizacyjne | Sekcja 8. W szczególności: szyfrowanie asymetryczne z rozdzielonymi kluczami; lista blokad dla ścieżek wylogowania i usunięcia; brak zrzutów ekranu za logowaniem; funkcja tylko dla płatnych planów i zweryfikowanych domen; każda zmiana w dzienniku aktywności (bez danych dostępowych). |
Celowo nie stworzyliśmy możliwości zapisania danych dostępowych do serwera, panelu administracyjnego CMS ani kont hostingowych Klienta. Konto testowe jest kontem odwiedzającego na stronie Klienta, a nie dostępem do jego systemu.
A.6 Skonfigurowane ścieżki formularzy, sprawdzenia w przeglądarce i niezależna sonda
| Pole | Wpis |
|---|
| Cel | Monitorowany formularz jest przechodzony w prawdziwej przeglądarce (Chromium, WebKit lub obie) aż do momentu przed wysłaniem: załadowanie strony, wykonanie poprzedzających kliknięć (najwyżej pięciu, nigdy na pole wprowadzania ani przycisk wysyłania), wypełnienie pól wyraźnie syntetycznymi wartościami (np. adresem w zarezerwowanej domenie .invalid), przełączanie formularzy wieloetapowych. Sprawdzenie w przeglądarce niczego nie wysyła; wysłanie jest w przeglądarce technicznie zablokowane. Ponadto pomiary czasu i porównania wizualne formularza. |
| Kategorie osób, których dane dotyczą | Jak w A.4 (osoby widoczne na stronie formularza); pracownicy Klienta wpisani jako osoby odpowiedzialne (A.3). |
| Kategorie danych osobowych | Konfiguracja: adres formularza, selektory, adres wejściowy, kroki kliknięć, wybór przeglądarki, nazwa, krytyczność, odpowiedzialność, termin (monitored_forms). Wyniki każdego przebiegu: stan, techniczna przyczyna błędu, oczyszczone komunikaty o błędach, pomiary sieciowe i czasowe, obraz formularza w formacie JPEG o rozmiarze najwyżej 32 KB z zamaskowanymi polami wprowadzania (form_browser_runs). Obserwacje dla każdego sprawdzenia (form_observations), szeregi czasowe (form_performance). Zlecenia z listą celów (pola „cele” i „wynik” w scan_jobs). |
| Dostępy testowe | Jeżeli Klient zapisał konto testowe (A.5), pełne sprawdzenie używa go także dla skonfigurowanych ścieżek formularzy. Samodzielne sprawdzenia w przeglądarce między dwoma pełnymi sprawdzeniami działają według zmierzonego kodu bez konta testowego. |
| Niezależna sonda | Przewidziany jest drugi punkt sprawdzający w innej lokalizacji, który przed alertem dokonuje sprawdzenia krzyżowego. Otrzymywałby domenę, oczyszczoną konfigurację i identyfikator zlecenia, bez danych wprowadzanych przez odwiedzających i bez danych dostępowych. Obecnie nie jest skonfigurowany (fabrycznie wyłączony). Bez sondy nie ma potwierdzenia z drugiej lokalizacji; alert opiera się wówczas na własnym pomiarze. |
| Źródło | Skonfigurowane przez Klienta; wyniki z pobrania strony Klienta. |
| Podstawa prawna (określana przez administratora) | Określa ją Klient w odniesieniu do treści swojej strony i odpowiedzialności swoich pracowników. |
| Odbiorcy | Klient; przy skonfigurowanej sondzie jej operator (obecnie nikt). |
| Państwo trzecie | Brak. |
| Okres przechowywania | Wyniki przebiegów w przeglądarce, zakończone zlecenia przeglądarkowe i szeregi czasowe po 13 miesiącach (nocny przebieg usuwania, części „browser_runs”, „browser_jobs”, „form_performance”). Konfiguracje do czasu usunięcia domeny (pojedynczo można je zmieniać lub wyłączać, ale nie usuwać); wraz z domeną są usuwane razem z przebiegami, obserwacjami i szeregami czasowymi przez klucze obce. |
| Czego dowodzi pomiar | Czasów i stanów z naszej przeglądarki sprawdzającej. Nie mierzą one tego, czego doświadczają prawdziwi odwiedzający, i nie dowodzą ani wskaźników ukończenia, ani utraconych zapytań. |
| Środki techniczne i organizacyjne | Sekcja 8. W szczególności: wysłanie technicznie uniemożliwione; tylko adresy w tej samej domenie; zamaskowane obrazy; odizolowany kontener sprawdzający. |
A.7 „Fix it for me” – wklejony kod formularza
| Pole | Wpis |
|---|
| Cel | Klient wkleja kod swojego formularza; model językowy na naszym własnym sprzęcie wbudowuje moduł ochronny. Zwracane są zmieniony plik, łatka (patch), wynik sprawdzenia składni oraz informacja, czy wywołanie sprawdzające zostało faktycznie wbudowane. Bez wklejonego kodu usługa dostarcza gotowy moduł z nazwami pól z ostatniego skanu. |
| Kategorie osób, których dane dotyczą | Osoby, których dane przypadkowo znajdują się we wklejonym kodzie (np. adres odbiorcy, nazwiska w komentarzach, dane dostępowe do serwera pocztowego). |
| Kategorie danych osobowych | Wklejony kod, najwyżej 30 000 znaków. W bazie danych tylko wpis w dzienniku aktywności (akcja „fix_ai” z obszarem roboczym i czasem), który liczy dzienny limit wynoszący obecnie dziesięć wywołań na obszar roboczy. |
| Źródło | Wklejone przez Klienta. |
| Podstawa prawna | Wykonanie umowy z Klientem (art. 6 ust. 1 lit. b RODO) w odniesieniu do samego kodu; w odniesieniu do przypadkowo zawartych danych osób trzecich podstawę określa Klient. |
| Odbiorcy | Brak. Model językowy działa na własnym serwerze skanującym w sieci wewnętrznej; brak zewnętrznej usługi AI, także jako rozwiązania awaryjnego. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Kod nie jest zapisywany. Na potrzeby sprawdzenia składni powstaje plik tymczasowy, usuwany bezpośrednio potem. Wpis w dzienniku aktywności jest usuwany po 365 dniach. |
| Wskazówka dla Klienta | Kod zawierający hasła, klucze API lub dane osobowe należy przed wklejeniem oczyścić. Nie sprawdzamy treści. |
| Środki techniczne i organizacyjne | Sekcja 8. W szczególności: tylko właściciele i admini płatnych planów; wklejony kod jest przekazywany modelowi oznaczony jako dane i nigdy nie jest wykonywany; brak przesyłania na cudze serwery. |
A.8 Marka white label i osoby kontaktowe agencji
| Pole | Wpis |
|---|
| Cel | Raporty, krótkie raporty, protokoły weryfikacji i portal klienta agencji (plan Business) są wyświetlane pod jej marką, na życzenie pod własną subdomeną agencji. |
| Kategorie osób, których dane dotyczą | Osoby kontaktowe agencji, których imię i nazwisko lub dane kontaktowe znajdują się w wierszu kontaktowym. |
| Kategorie danych osobowych | Nazwa firmy, strona internetowa, wiersz kontaktowy, tekst informacyjny dla klienta końcowego, kolor akcentu, sposób wyświetlania, plik logo, przełącznik wzmianki o formexposed, własna domena z identyfikatorem potwierdzenia i statusem weryfikacji (workspace_branding). |
| Źródło | Wprowadzone przez agencję. |
| Podstawa prawna | Wykonanie umowy z agencją (art. 6 ust. 1 lit. b RODO). W zakresie, w jakim wiersz kontaktowy wymienia pracowników agencji, podstawę określa agencja. |
| Odbiorcy | Każdy, komu agencja przekaże raport, krótki raport lub link do portalu. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Do zmiany przez agencję; wraz z obszarem roboczym usuwane są marka i plik logo (fe_arbeitsbereich_daten_loeschen()). Własna domena, której potwierdzenie DNS przez siedem dni się nie zgadza, jest wyłączana. Własna domena jest fabrycznie wyłączona. |
| Środki techniczne i organizacyjne | Sekcja 8. |
A.9 Wartości liczbowe, cechy stanu i błędy pól z wtyczki i rozszerzenia
| Pole | Wpis |
|---|
| Cel | Wtyczka do WordPressa i rozszerzenie do TYPO3 raz dziennie przekazują liczby dotyczące formularzy połączonej strony: odparte zgłoszenia według przyczyny, zgłoszenia, wysłane i nieudane wiadomości e-mail, cechy stanu ustawień formularzy, zapisane zapytania według źródła i okresu przechowywania. Opcjonalnie, fabrycznie wyłączone: zdarzenia formularzy i kategorie błędów pól według pozycji pola. Na tej podstawie powstają „Ochrona w liczbach”, raport miesięczny, alert o ciszy oraz wskazówki dotyczące ryzykownych ustawień. |
| Kwalifikacja | Liczby są zbudowane tak, aby nie opisywały żadnej osoby. Ujmujemy je w części A, ponieważ powstają ze zdarzeń na stronie Klienta wywoływanych przez jego odwiedzających; naszym zdaniem mają charakter danych osobowych co najwyżej w przypadkach granicznych (strona z bardzo małą liczbą zgłoszeń jednego dnia). Samo przekazanie (klucze, wersje, host) figuruje w części B (B.20). |
| Kategorie osób, których dane dotyczą | Osoby odwiedzające stronę Klienta, które wysyłają formularz. |
| Kategorie danych osobowych | Liczby dzienne dla każdego hosta: odparte łącznie i według przyczyny, zgłoszenia, wiadomości wysłane i nieudane, kategoria błędu wysyłki poczty (tylko jedna z czterech kategorii, nigdy tekst błędu, ponieważ może on zawierać adresy odbiorców), liczby odpowiedzi reCAPTCHA, usunięte i zwolnione zapytania (plugin_stats). Stan: wersje z zamkniętej listy wtyczek formularzy, CAPTCHA i poczty, cechy ustawień jako liczby, okresy przechowywania (plugin_health). Powiadomienia o zmianach: nazwa i wersja zaktualizowanej wtyczki (plugin_changes). Opcjonalnie: liczniki dla każdego formularza i dnia z kategoriami błędów według pozycji pola (form_metrics). Nigdy: dane wprowadzone, nazwy pól, hasła, pliki, adresy e-mail, imiona i nazwiska, adresy IP ani trwałe identyfikatory odwiedzających. |
| Źródło | Wtyczka na stronie Klienta, przez interfejs programistyczny z sekretem połączenia strony. |
| Podstawa prawna (określana przez administratora) | Określa ją Klient; decyduje on o włączeniu opcjonalnych liczników i o informowaniu swoich odwiedzających. |
| Odbiorcy | Klient. Domeny z linków w odpartych wiadomościach trafiają do ochrony roju (B.21). |
| Państwo trzecie | Brak. |
| Okres przechowywania | Liczby dzienne, powiadomienia o zmianach i liczniki formularzy po 13 miesiącach (nocny przebieg usuwania, części „plugin_stats” i „form_metrics”). Cechy stanu są nadpisywane przy każdym przekazaniu. Wszystkie dane wtyczki dotyczące hosta są usuwane, gdy żadna domena w systemie nie prowadzi już tego hosta (natychmiast przy usunięciu ostatniej domeny; dane historyczne co noc, część „orphan_hosts”). |
| Czego dowodzą liczby | Tego, co policzyła wtyczka. Nie dowodzą ani wskaźników ukończenia, ani utraconych zapytań. |
| Środki techniczne i organizacyjne | Sekcja 8. W szczególności: przyjęcie tylko z powiązaną parą kluczy strony; przejmowane są tylko znane klucze i liczby, wszystko inne jest odrzucane; dni spoza okna 14 dni są odrzucane. |
A.10 Granica: co pozostaje wyłącznie na stronie Klienta
Poniższe funkcje wtyczki do WordPressa i rozszerzenia do TYPO3 przetwarzają dane wyłącznie na serwerze Klienta. Nie docierają one do nas i nie mamy do nich dostępu. Administratorem jest wyłącznie operator strony; decyduje on o włączeniu, okresach przechowywania i informowaniu swoich odwiedzających. Wtyczka proponuje mu w tym celu fragmenty do jego polityki prywatności.
| Funkcja | Co jest przetwarzane lokalnie | Okres przechowywania po stronie Klienta |
|---|
| Kwarantanna | Zatrzymane zgłoszenia z przyczyną, możliwe do zwolnienia e-mailem wysłanym na adres strony | 14 dni |
| Siatka bezpieczeństwa | Zgłoszenia, których wiadomość z formularza nie została wysłana, do ponownej wysyłki (fabrycznie włączona) | 30 dni |
| Zagadka matematyczna zamiast reCAPTCHA | Zadanie rachunkowe w przeglądarce odwiedzającego, bez usługi podmiotu trzeciego (fabrycznie wyłączona) | – |
| Okresy przechowywania | Usuwanie zapisanych zapytań we wtyczkach formularzy po okresie wybranym przez operatora (fabrycznie wyłączone) | zgodnie z ustawieniem |
| Ograniczanie liczby zapytań | identyfikator krótkotrwale wyprowadzony z adresu IP, nieprzekazywany nam | krótkotrwale |
| Lokalne liczniki dzienne | stany liczników przed przekazaniem | najwyżej 14 dni |
| Rejestrator dla administratorów | techniczne selektory i kroki nawigacji w pamięci sesji przeglądarki zalogowanego administratora; dane wprowadzane nie są odczytywane. Przekazywana jest tylko wybrana konfiguracja (wówczas A.6) | najwyżej 15 minut |
| Pomoc dla odwiedzających | włączana osobno; nie zapisuje wersji roboczych i nie wysyła automatycznie ponownie | – |
| Obserwacja nowych reguł antyspamowych | dodatkowe trafienia są liczone lokalnie, bez automatycznej aktywacji | siedem dni |
A.11 Ochrona formularzy (formconfirmed)
| Pole | Wpis |
|---|
| Cel | Ocena zgłoszeń wysyłanych przez formularze na stronach Klientów w celu rozpoznania zgłoszeń automatycznych: wydawanie i sprawdzanie zadań (dowód wykonania obliczeń), jednorazowe znaczniki kontrolne, czas wypełniania, pole-pułapka, powtarzające się żądania; na życzenie Klienta ocena tekstu wiadomości przez model językowy. Wyłącznie dla Klientów, którzy włączą ochronę formularzy. |
| Kategorie osób, których dane dotyczą | Osoby odwiedzające strony Klientów, które wyświetlają stronę z chronionym formularzem lub go wysyłają. |
| Kategorie danych osobowych | Adres IP (zapisywany tylko w skróconej postaci i jako skrót z kluczem zmienianym codziennie), adres i domena strony, momenty i czas wypełniania, wypełnienie pola-pułapki tak/nie, identyfikator przeglądarki w dzienniku serwera WWW; tylko przy włączonym sprawdzaniu treści – tekst wiadomości (wyłącznie w pamięci operacyjnej). |
| Źródło | Przeglądarka odwiedzającego (zadanie, znacznik kontrolny); serwer Klienta (żądanie sprawdzenia, ewentualnie tekst). |
| Odbiorcy | Klient (wynik punktowy, akcja, powody). Brak innych; brak dalszych podmiotów przetwarzających dla tego przetwarzania. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Skrót identyfikatora 1 godzina; wykorzystane znaczniki kontrolne najwyżej 11 minut; wyniki sprawdzeń bez adresu IP i bez tekstu 30 dni; dane dzienne 400 dni; dziennik serwera WWW 14 dni; tekst nie jest przechowywany. |
| Środki techniczne i organizacyjne | Sekcja 8; ponadto skracanie i skrót z kluczem dziennym, podpisane zadania, jednorazowe użycie, model językowy na własnym sprzęcie bez rejestrowania tekstu. |
4. Część A – odbiorcy, dalsze podmioty przetwarzające i przekazywanie do państw trzecich
Poniższa tabela wymienia odbiorców, których sami angażujemy i którzy mogą otrzymywać dane z części A. Miarodajnym, bieżąco aktualizowanym wykazem jest strona Podmioty przetwarzające dalej; jeżeli odbiega ona od tej tabeli, jest to ustalenie wymagające wyjaśnienia, a nie problem z formatowaniem.
| Odbiorca | Co otrzymuje | Państwo trzecie | Podstawa | Stan |
|---|
| Namecheap, Inc. (Private Email), Phoenix, Arizona, USA | Skrzynka kontrolna kontroli doręczenia (A.1); wysyłka alertów e-mail (A.3), potwierdzeń i raportów dla subskrybentów portalu (A.2) | Miejsce przetwarzania do sprawdzenia; zob. strona „Podmioty przetwarzające dalej” | Umowa powierzenia przetwarzania danych; podstawa przekazania do sprawdzenia | Otwarte. Odpowiednia umowa, faktyczne miejsca przetwarzania i podstawa przekazania nie są jeszcze udokumentowane. Ten rejestr nie potwierdza ani certyfikacji, ani zawartej umowy. |
| Namecheap, Inc. (rejestrator, DNS; do czasu skonfigurowania skrzynki przekierowanie poczty e-mail) | Do czasu skonfigurowania skrzynki ogólna poczta przychodząca na adresy w naszej domenie; nie kopie z kontroli doręczenia, które docierają tylko przy rekordach MX wskazujących bezpośrednio na skrzynkę (A.1) | USA | do sprawdzenia: certyfikacja w ramach EU-US Data Privacy Framework lub standardowe klauzule umowne | W użyciu; podstawa otwarta. |
| Własny serwer skanujący z lokalnym modelem językowym | Struktura formularza do zaklasyfikowania oraz wybrane ustalenia wraz z metadanymi skanu do planów działań dla kont płatnych (A.4), wklejony kod (A.7), odszyfrowane dostępy testowe wyłącznie w trakcie przebiegu (A.5) | – | Eksploatacja własna, brak podmiotu trzeciego | W użyciu. |
| Niezależna sonda w drugiej lokalizacji | Domena, oczyszczona konfiguracja, identyfikator zlecenia (A.6) | zależnie od lokalizacji | do ustalenia przed uruchomieniem | Nieskonfigurowana. |
Hosting: brak podmiotu trzeciego. Aplikacja, baza danych, zrzuty ekranu i kopie zapasowe znajdują się na własnych serwerach w Polsce. W razie przejścia do centrum danych lub dostawcy chmury ten akapit należy zredagować na nowo.
4.1 Kanały alertów wybrane przez Klienta
Obok odbiorców, których angażujemy, istnieją kanały, które Klient wybiera dla swoich alertów (A.3). Przekazanie inicjuje nasz serwer; cel i dostawcę określa Klient. Wybór kanału nie znosi naszych własnych obowiązków jako podmiotu przetwarzającego. Rolę, umowę i wymagane zabezpieczenia dla państw trzecich należy ustalić dla każdego dostawcy; w przypadku usług czatu nie zostało to jeszcze zakończone (otwarte pytanie weryfikacji prawnej).
| Kanał | Co jest przekazywane | Siedziba dostawcy |
|---|
| E-mail | Domena, zdarzenie, objaśnienie, link; na wpisany adres | przez Namecheap, Inc. (Private Email), Phoenix, Arizona, USA |
| Webhook na dowolnie wybrany adres | Zdarzenie jako JSON (domena, zdarzenia, wiersze, link, znacznik czasu), podpisane sekretem celu | określa Klient |
| Slack, Discord, Microsoft Teams, Google Chat | to samo powiadomienie jako wiadomość czatu na wpisany adres webhooka | przeważnie USA |
| Telegram | cel wybrany przez Klienta; wiadomość wysyłamy przez naszego bota na powiązany identyfikator czatu | poza UE, brak decyzji stwierdzającej odpowiedni stopień ochrony; podstawa przekazania – otwarte pytanie weryfikacji prawnej |
W żadnym przypadku nie jest przekazywana treść wiadomości od odwiedzającego. Powiadomienia zawierają domenę, zdarzenie i link.
5. Część B – art. 30 ust. 1: czynności przetwarzania na własną odpowiedzialność
Administrator wszystkich czynności w tej części: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polska, contact@lukaswojcik.com. Przedstawiciel nie jest wymagany (siedziba w Unii). Inspektor ochrony danych niewyznaczony (sekcja 9). Środki techniczne i organizacyjne: sekcja 8 oraz strona Środki techniczne i organizacyjne. Sposób wykonywania praw przez osoby, których dane dotyczą, opisuje strona Dostęp, usunięcie i pozostałe prawa; posiadacze kont mogą sami pobrać swoje dane jako plik (Ustawienia).
Tam, gdzie opieramy się na prawnie uzasadnionych interesach (art. 6 ust. 1 lit. f RODO), wskazujemy interes oraz powód, dla którego łagodniejszy środek nie wystarcza. Wyważenie interesów jest naszą oceną; stanowi część weryfikacji prawnej.
B.1 Osoby odwiedzające naszą stronę – dzienniki serwera WWW
| Pole | Wpis |
|---|
| Cel | Działanie i bezpieczeństwo strony i aplikacji: dostarczanie treści, wyszukiwanie błędów, wykrywanie ataków i przeciążeń. |
| Kategorie osób, których dane dotyczą | Wszyscy, którzy otwierają stronę formexposed.com lub form.exposed, w tym osoby odwiedzające strony Klientów, których przeglądarka ładuje obraz naszej pieczęci (B.18), odbiorcy otwierający link do raportu lub link potwierdzający oraz strony, których wtyczka wywołuje nasz interfejs. |
| Kategorie danych osobowych | Pełny adres IP, czas, żądany adres, kod statusu, liczba przesłanych bajtów, strona odsyłająca (referrer), identyfikator przeglądarki (user agent). |
| Miejsce przechowywania | Dzienniki dostępu poprzedzającego serwera proxy i serwera WWW jako pliki na serwerze WWW, nie w bazie danych. |
| Źródło | Przeglądarka lub program wysyłający żądanie. |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO. Interes: bezpieczne i niezakłócone działanie. Wyważenie: bez pełnego adresu nie da się przypisać powtarzających się żądań temu samemu nadawcy ani odpierać ataków; skrócony adres nie pozwala na takie rozróżnienie. Dzienniki nie są łączone z innymi danymi i są usuwane po krótkim czasie. |
| Odbiorcy | Brak. |
| Państwo trzecie | Brak. |
| Okres przechowywania | 14 dni: codzienna rotacja z 14 wersjami, potem nadpisanie (usługa systemowa rotacji dzienników, nie nocny przebieg usuwania aplikacji). |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.2 Dziennik odsłon aplikacji
| Pole | Wpis |
|---|
| Cel | Bezpieczeństwo i wykrywanie nadużyć (kto, co i jak często wywołuje), rozliczalność dostępu do kont, prosta statystyka użycia bez usługi analitycznej. |
| Kategorie osób, których dane dotyczą | Wszystkie osoby odwiedzające stronę i użytkownicy aplikacji przy rzeczywistych odsłonach stron (bez żądań w tle, bez przesyłania formularzy). |
| Kategorie danych osobowych | Pełny adres IP, ustalony z niego przy zapisie kraj (lokalna baza geolokalizacyjna, bez zapytania do podmiotu trzeciego), identyfikator konta w przypadku zalogowanych użytkowników, wywołany adres i strona odsyłająca (zawarte w nich tokeny dostępu, na przykład z linków do raportów lub portali, zamaskowane), identyfikator przeglądarki, ustalone na jego podstawie typ urządzenia, system operacyjny i przeglądarka, język, czas (access_logs). W trybie „widok jako klient” (B.14) identyfikator konta nie jest ustawiany, aby wywołania wsparcia nie trafiały do dziennika Klienta. |
| Źródło | Żądanie przeglądarki. |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO. Interes: przeciwdziałanie nadużyciom i rozliczalność. Wyważenie: jak w B.1; okres jest dłuższy, ponieważ wzorce nadużyć ujawniają się w ciągu tygodni. Czy adres IP powinien być skracany albo okres skrócony, jest otwartym pytaniem weryfikacji prawnej. |
| Odbiorcy | Brak. Posiadacze kont otrzymują swoje własne wywołania w eksporcie danych. |
| Państwo trzecie | Brak. |
| Okres przechowywania | 60 dni (co noc między 03:00 a 03:05, srv/cron_status.php, ustawienie „dziennik odsłon”). |
| Środki techniczne i organizacyjne | Sekcja 8. Adres IP z przekazanego nagłówka jest przejmowany tylko wtedy, gdy żądanie pochodzi z własnego poprzedzającego serwera proxy, i wówczas tylko wpis dodany przez ten serwer proxy; w przeciwnym razie każdy mógłby dowolnie podać swoje pochodzenie. |
B.3 Pliki cookie i pamięć w przeglądarce
| Pole | Wpis |
|---|
| Cel | Technicznie niezbędne przechowywanie: sesja, ochrona przed fałszowaniem żądań (CSRF), liczenie limitów dla sprawdzeń bez konta, logowanie, na życzenie pozostanie zalogowanym, tryb jasny lub ciemny. |
| Kategorie osób, których dane dotyczą | Osoby odwiedzające i użytkownicy formexposed.com. |
| Kategorie danych osobowych | Plik cookie sesji bpid (identyfikator sesji; wygasa po zamknięciu przeglądarki; HttpOnly, SameSite=Lax, Secure przy HTTPS). Plik cookie bp_remember tylko po wybraniu opcji „Pozostań zalogowany” (identyfikator wyboru i wartość kontrolna; 30 dni). Pamięć lokalna bp_theme (jasny, ciemny lub systemowy). W panelu administracyjnym dodatkowo lokalne ustawienia wyświetlania operatorów. Na potrzeby limitów z identyfikatora sesji tworzony jest skrót (hash); sam identyfikator nie jest zapisywany. |
| Nieustawiane | Brak plików cookie analitycznych, reklamowych lub służących do ponownego rozpoznawania. Program partnerski (B.33) działa bez pliku cookie. Obraz pieczęci na stronach Klientów nie ustawia pliku cookie (B.18). reCAPTCHA może przy wysyłaniu chronionego formularza ustawiać pliki cookie Google (B.23). |
| Podstawa prawna | Dostęp do urządzenia końcowego: bezwzględnie niezbędny do świadczenia usługi żądanej przez użytkownika (§ 25 ust. 2 pkt 2 TDDDG, niemieckiej ustawy o ochronie danych w telekomunikacji i usługach cyfrowych; art. 399 ust. 3 Prawa komunikacji elektronicznej (PKE)). Przetwarzanie: art. 6 ust. 1 lit. b RODO (konto) i lit. f (bezpieczeństwo, limity). |
| Odbiorcy | Brak. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Sesja; 30 dni dla znacznika zapamiętania. Wygasłe znaczniki w bazie danych usuwa nocny przebieg (remember_tokens); przy wylogowaniu, zmianie hasła i odwołaniu urządzenia – natychmiast. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.4 Bezpłatne sprawdzenie bez konta – przyjmowanie, limity i obserwacja nadużyć
| Pole | Wpis |
|---|
| Cel | Każdy może zlecić sprawdzenie domeny bez konta. Aby pole wprowadzania nie stało się bronią przeciwko cudzym stronom, obowiązują stopniowane limity: jedno anonimowe sprawdzenie na domenę w ciągu siedmiu dni (potem ten sam raport), limity na adres IP i na sesję w ciągu 24 godzin, limit dzienny dla całego systemu, blokada bardzo młodych domen, lista blokad i opt-out, wyłącznie adresy publiczne. Podejrzane wzorce są rejestrowane i zgłaszane operatorowi. Limity na adres IP, na sesję i dla całego systemu obowiązują, liczone każdorazowo osobno, także dla sprawdzenia z wtyczki bez konta (wtyczka z powiązaną parą kluczy jest liczona na stronę zamiast na adres) i dla opt-outu (B.30); bezpłatne narzędzie do nagłówków (B.9) ma własne limity na adres IP i dzień oraz dla całego systemu. |
| Kategorie osób, których dane dotyczą | Osoby inicjujące sprawdzenie, narzędzie do nagłówków lub opt-out; serwery, na których zainstalowana jest wtyczka. |
| Kategorie danych osobowych | Dziennik każdego żądania: źródło (sprawdzenie, wtyczka, narzędzie do nagłówków, opt-out), pełny adres IP, skrót (hash) identyfikatora sesji, sprawdzany host, kraj ustalony z adresu IP, przyjęte lub odrzucone z przyczyną, czas (check_throttle). Nieprawidłowości: rodzaj (adres IP, sesja, kraj, system), klucz (przy rodzaju „IP” pełny adres IP), wzorzec, waga, krótki opis, czas wykrycia i załatwienia, osoba załatwiająca (abuse_flags). Zlecenie: host, tryb, poziom zaufania i skrócony skrót sesji jako identyfikator zlecającego (scan_jobs). Raport: losowy identyfikator, host, język, wygaśnięcie, pierwsze wywołanie, liczba wywołań (reports). Zbuforowany wiek domeny z informacji rejestru (domain_age_cache). |
| Źródło | Dane wprowadzone przez osobę; jej żądanie; informacja rejestru (RDAP) o wieku domeny. |
| Podstawa prawna | Przeprowadzenie zleconego sprawdzenia: art. 6 ust. 1 lit. b RODO (korzystanie z bezpłatnego sprawdzenia na podstawie Regulaminu); pomocniczo lit. f. Limity i obserwacja: art. 6 ust. 1 lit. f. Interes: zapobieganie wykorzystaniu usługi jako narzędzia przeciwko cudzym stronom lub do rozsyłania spamu. Wyważenie: bez przypisania do adresu i sesji limitów nie dałoby się egzekwować; okres siedmiu dni jest tak krótki jak najdłuższy limit liczony na tej podstawie. |
| Odbiorcy | Google (reCAPTCHA przy wysyłaniu, B.23). W celu ustalenia wieku domeny skaner odpytuje usługę przekierowującą RDAP rdap.org, która przekazuje zapytanie do właściwego rejestru; przekazywana jest wyłącznie nazwa domeny. Operator otrzymuje w razie nieprawidłowości sygnał przez Telegram bez żadnej zmiennej (bez hosta, bez adresu). Raport widzi każdy, kto ma jego losowy link. |
| Państwo trzecie | USA za pośrednictwem reCAPTCHA (B.23). |
| Okres przechowywania | Dziennik żądań 7 dni (co noc, srv/cron_status.php). Załatwione nieprawidłowości 90 dni po załatwieniu; niezałatwione pozostają, dopóki ktoś ich nie załatwi (sekcja 10). Anonimowe raporty wygasają po 30 dniach; następnie nocny przebieg usuwa raport, zlecenie, wynik sprawdzenia, formularze, ustalenia i obrazy (fe_reports_aufraeumen()). Administrator może ręcznie zwolnić wpisy dotyczące danego adresu; usuwa to jego dziennik z ostatnich 24 godzin. |
| Środki techniczne i organizacyjne | Sekcja 8. Wyłącznik awaryjny dla wszystkich anonimowych sprawdzeń w panelu administracyjnym; mechanizm wyrównywania obciążenia, który przy zatorze nie przyjmuje nowych bezpłatnych sprawdzeń. |
B.5 Sprawdzenie cudzych stron przez crawler
| Pole | Wpis |
|---|
| Cel | Sprawdzenie bezpieczeństwa publicznych formularzy kontaktowych: środki ochrony przed spamem i nadużyciami, cechy ochrony danych i dostępności, osadzone skrypty podmiotów trzecich, zachowanie po odrzuceniu w banerze cookie, widok mobilny. Dotyczy sprawdzeń bez konta (B.4), domen na koncie, które nie zostały jeszcze zweryfikowane, oraz stanowi podstawę badania (B.7) i sprawdzenia potencjalnego klienta (B.8). W odniesieniu do zweryfikowanych domen na koncie działamy w imieniu Klienta (A.4). |
| Zachowanie crawlera | Własny identyfikator z odesłaniem do strony crawlera; przed sprawdzeniem odczytuje robots.txt i przerywa działanie, jeżeli zakaz obejmuje stronę główną (podobnie przy niedostępnym robots.txt lub błędzie serwera); zakazy dotyczące pojedynczych podścieżek nie są osobno uwzględniane. Puls formularza, pobieranie potwierdzenia, narzędzie do nagłówków i wyszukiwanie publicznie dostępnych plików nie odczytują robots.txt. Najwyżej osiem publicznych stron na sprawdzenie, do tego do trzech stron z kliknięciem „Odrzuć” w banerze cookie, do trzech stron w widoku telefonu, przy zweryfikowanych domenach próby aktywne i do pięciu stron za logowaniem (A.5); strony są ładowane kolejno, nie równolegle; wyłącznie adresy publiczne, bez sieci wewnętrznych, przekierowania są sprawdzane ponownie; lista blokad i opt-out są sprawdzane przed przyjęciem i po raz drugi w skanerze. Pasywnie: bez potwierdzenia uprawnień do domeny niczego się nie wysyła w przypadku Klientów (wyjątek: wewnętrzne sprawdzenia własnych domen testowych i demonstracyjnych, B.6). |
| Kategorie osób, których dane dotyczą | Operatorzy sprawdzanych stron (o ile są osobami fizycznymi, np. jednoosobowymi przedsiębiorcami); osoby przypadkowo widoczne na sprawdzanych stronach. |
| Kategorie danych osobowych | Jak w A.4: adresy i tytuły stron, struktura formularza (nazwy, typy i etykiety pól, bez wartości pól), środki ochrony, skrypty podmiotów trzecich (adresy; identyfikatory kont pikseli i narzędzi nagrywających są zastępowane przed zapisaniem), zachowanie banera cookie, zrzuty ekranu (widoczny obszar strony głównej, formularze). Jeżeli w formularzu figuruje adres odbiorcy, tylko jego domena (scans, forms, findings, scan_screenshots). |
| Źródło | Strony dostępne publicznie. |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO. Interes: przeprowadzenie zleconego sprawdzenia bezpieczeństwa; zwrócenie uwagi operatorom stron na słabe punkty, które mogą szkodzić ich odwiedzającym. Wyważenie: odczytywane jest tylko to, co widzi każdy odwiedzający, w niewielkim zakresie i bez wysyłania; operator może w każdej chwili trwale wykluczyć swoją domenę bez potwierdzania uprawnień. Informacja na podstawie art. 14 RODO jest przekazywana przez stronę crawlera, opt-out i politykę prywatności; czy jest to wystarczające w świetle art. 14 ust. 5 lit. b, jest otwartym pytaniem weryfikacji prawnej. |
| Odbiorcy | Osoba inicjująca raport i każdy, komu przekaże ona losowy link; lokalny model językowy na własnym serwerze przy niejasnym typie formularza (struktura formularza, tytuł i adres strony, widoczny tekst formularza). Ostrzeżenia o lukach wynikające z wersji wtyczek nigdy nie pojawiają się w anonimowych raportach. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Anonimowo: 30 dni (B.4). Sprawdzenie potencjalnego klienta: 90 dni (B.8). Badanie: do publikacji (B.7). Domena na koncie: najwyżej 13 miesięcy, ostatnie sprawdzenie pozostaje; wraz z domeną – natychmiast. Wewnętrzne sprawdzenia operatora bez domeny i bez raportu (np. założone z wiersza poleceń): brak terminu (sekcja 10). Pliki tymczasowe na serwerze skanującym są usuwane po każdym przebiegu. |
| Środki techniczne i organizacyjne | Sekcja 8. W szczególności: własny kontener sprawdzający z odebranymi uprawnieniami, systemem plików tylko do odczytu, limitem pamięci i własną siecią; podwójna kontrola celu. |
B.6 Aktywne zgłoszenia testowe
| Pole | Wpis |
|---|
| Cel | Sprawdzenie, czy formularz kontaktowy przyjmuje zgłoszenie bez ochrony, czy CAPTCHA, pułapka (honeypot), token, weryfikacja adresu e-mail i ograniczenie liczby zgłoszeń działają po stronie serwera oraz czy można wstrzyknąć nagłówki. |
| Warunek | W przypadku Klientów tylko dla domen, w przypadku których potwierdzono uprawnienia do domeny (wpis DNS, meta tag, plik lub połączona wtyczka); ponadto operator za pomocą wewnętrznego narzędzia wiersza poleceń zakłada sprawdzenia z poziomem „zweryfikowany” dla własnych domen testowych i demonstracyjnych. Tylko przy włączonym przełączniku globalnym, tylko dla formularza, który został z pewnością zaklasyfikowany jako ogólny formularz kontaktowy. Nigdy przy zamówieniach, rezerwacjach, rejestracji, newsletterze, płatności, przesyłaniu plików, polach obowiązkowych z prawdziwymi danymi osobowymi ani w domenach urzędów, placówek ochrony zdrowia i placówek oświatowych. |
| Kategorie osób, których dane dotyczą | Pracownicy Klienta otrzymujący wiadomości z formularzy. |
| Kategorie danych osobowych | Zgłoszenie testowe nie zawiera danych osobowych: nadawca „FormExposed Security Scanner”, własny adres nadawcy lub adres w domenie .invalid, oznaczony temat i tekst w języku strony z odesłaniem do strony crawlera i opt-outu oraz numerem sprawdzenia. Zapisywane u nas: odpowiedź strony, ustalenia, obraz strony następnej (jak w A.4). |
| Zakres | Najwyżej pięć zgłoszeń na sprawdzenie (ustawienie, wartość domyślna 5); cyklicznie z częstotliwością sprawdzeń właściwą dla planu, w najwyższym planie codziennie. |
| Źródło | Zlecenie Klienta. |
| Podstawa prawna | Wykonanie umowy z Klientem (art. 6 ust. 1 lit. b RODO); zgłoszenia trafiają do formularza samego Klienta. W odniesieniu do odbiorców po stronie Klienta: jego organizacja. |
| Odbiorcy | Klient (jego wiadomość z formularza). |
| Państwo trzecie | Brak z naszej strony. |
| Okres przechowywania | Wyniki jak w A.4. |
| Środki techniczne i organizacyjne | Sekcja 8. Wstrzykiwanie nagłówków jest tylko wykrywane, nigdy wykonywane z prawdziwym odbiorcą; weryfikacja adresu e-mail używa wyłącznie domeny, która nie może istnieć. |
B.7 Badanie „Indeks bezpieczeństwa formularzy”
| Pole | Wpis |
|---|
| Cel | Statystyka dotycząca ochrony formularzy kontaktowych w danym kraju lub branży. Publikowane są wyłącznie sumy, bez nazw stron, a segmenty dopiero od 20 stron z formularzem. |
| Kategorie osób, których dane dotyczą | Operatorzy stron z listy; osoby przypadkowo widoczne. |
| Kategorie danych osobowych | Jak w B.5, wyłącznie pasywnie. Do tego lista: host, segment, status, zlecenie (study_domains); badanie z tytułem, krajem, sumami wyników (studies). |
| Źródło | Lista publicznych stron zestawiona przez operatora; same strony. |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO. Interes: statystyczne wnioski o stanie bezpieczeństwa formularzy. Wyważenie: pasywnie, z ograniczeniem tempa (niewiele zleceń na przebieg), lista blokad i opt-out obowiązują, publikacja wyłącznie w postaci sum, dane surowe są usuwane. |
| Odbiorcy | Opinia publiczna, wyłącznie sumy. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Dane surowe (wyniki sprawdzeń, formularze, ustalenia, obrazy, zlecenia) są usuwane przy publikacji (fe_studie_veroeffentlichen()). Lista hostów z segmentem pozostaje potem zachowana; dla niej i dla nigdy nieopublikowanych badań nie ma terminu (sekcja 10). O tym, które listy są sprawdzane i czy badania są publikowane, decyduje operator. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.8 Sprawdzenie potencjalnego klienta (tryb akwizycji dla agencji)
| Pole | Wpis |
|---|
| Cel | Agencja (plan Business) pasywnie sprawdza stronę potencjalnego klienta i otrzymuje krótki raport pod swoją marką oraz raport pasywny. Do nikogo nie piszemy; link przekazuje sama agencja. |
| Kategorie osób, których dane dotyczą | Operator sprawdzanej strony; osoby przypadkowo widoczne; pracownicy agencji inicjujący sprawdzenie. |
| Kategorie danych osobowych | Jak w B.5, wyłącznie pasywnie. Do tego: obszar roboczy, osoba inicjująca, host, losowy identyfikator raportu, czas (prospect_checks). |
| Źródło | Dane wprowadzone przez agencję; strony publiczne. |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO (nasz interes w świadczeniu usługi i interes agencji w rzetelnie przygotowanym kontakcie). Rola między agencją a nami oraz obowiązki agencji przy przekazywaniu są otwartymi pytaniami weryfikacji prawnej: jeżeli agencja wysyła raport bez zapytania e-mailem lub dzwoni, jest to – zgodnie z art. 398 PKE i § 7 ust. 2 UWG (niemieckiej ustawy o zwalczaniu nieuczciwej konkurencji) – także między przedsiębiorcami marketing bezpośredni wymagający zgody. Jest to sprawa agencji; zobowiązuje ją do tego Regulamin. |
| Odbiorcy | Agencja i każdy, komu przekaże ona link. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Raport i wynik sprawdzenia wygasają po 90 dniach i są wtedy usuwane przez nocny przebieg (fe_reports_aufraeumen()); wpis sprawdzenia jest usuwany po 90 dniach w codziennym przebiegu roju od godz. 04:00 (srv/cron_status.php). Wraz z obszarem roboczym – natychmiast. |
| Środki techniczne i organizacyjne | Sekcja 8. Limit miesięczny (ustawienie, wartość domyślna 30); ta sama strona w ciągu siedmiu dni daje ten sam raport; opt-out obowiązuje. |
B.9 Narzędzie do nagłówków bez konta
| Pole | Wpis |
|---|
| Cel | Bezpłatna ocena (od A+ do F) nagłówków bezpieczeństwa strony głównej domeny. Dwa pobrania, bez przeglądarki, bez formularza, bez zgłoszenia. |
| Kategorie osób, których dane dotyczą | Osoby korzystające z narzędzia; operatorzy sprawdzanej domeny. |
| Kategorie danych osobowych | Dziennik żądań jak w B.4 (źródło „headers”, adres IP, skrót sesji, host). Wynik: host, ocena, punkty, przeanalizowane nagłówki (header_checks). |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO, jak w B.4 i B.5. |
| Odbiorcy | Google (reCAPTCHA, B.23). |
| Państwo trzecie | USA za pośrednictwem reCAPTCHA. |
| Okres przechowywania | Dziennik żądań 7 dni; wyniki po obecnie 90 dniach (nocny przebieg usuwania, część „header_checks”, ustawienie „headers_keep_days”). Dla domen na koncie ocena jest ustalana codziennie na nowo i zapisywana wraz z domeną. |
| Środki techniczne i organizacyjne | Sekcja 8. Limity na adres IP i dzień; opt-out obowiązuje. |
B.10 Konta Klientów
| Pole | Wpis |
|---|
| Cel | Prowadzenie kont Klientów, obszarów roboczych i planów. |
| Kategorie osób, których dane dotyczą | Klienci (przedsiębiorcy) i członkowie ich zespołów z własnym kontem. |
| Kategorie danych osobowych | Adres e-mail i jego postać znormalizowana, hasło wyłącznie jako skrót (hash), imię (obowiązkowo), nazwisko i firma (o ile podano); adresu i NIP UE aplikacja nie zapisuje, podaje się je wyłącznie w Stripe (B.26); status, język, tryb wyświetlania, waluta, plan i status rozliczeń, identyfikator klienta i subskrypcji w Stripe, koniec okresu rozliczeniowego, wypowiedzenie na koniec okresu, identyfikatory potwierdzenia i resetowania z terminem ważności, nowy adres e-mail do czasu potwierdzenia, czas rejestracji, ostatnie logowanie i ostatni adres IP, czas odwołania wszystkich sesji, dane uwierzytelniania dwuskładnikowego (B.11), raport miesięczny włączony/wyłączony, czas wysłania wiadomości przypominającej, odblokowania za pomocą kodów, kod polecający i polecenie (users). Obszary robocze z nazwą, znacznikami czasu, statusem (workspaces); członkostwo z rolą i datą dołączenia (workspace_users). |
| Źródło | Rejestracja i ustawienia dokonane przez osobę; status rozliczeń ze Stripe. |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO (umowa). Ostatni adres IP: lit. f (bezpieczeństwo konta). |
| Odbiorcy | Stripe (B.26); dostawca poczty e-mail w zakresie wiadomości dotyczących konta (B.25). Członkowie tego samego obszaru roboczego widzą imię i nazwisko, adres e-mail i rolę pozostałych członków. |
| Państwo trzecie | Za pośrednictwem Stripe i dostawcy poczty e-mail. |
| Okres przechowywania | Do usunięcia przez posiadacza konta. Usuwane są wtedy jego własne obszary robocze, z których nikt inny nie korzysta, wraz ze wszystkimi domenami i ich danymi; obszary robocze z innymi członkami przechodzą na innego członka, w pierwszej kolejności na administratorów, a spośród nich na członka z najdłuższym stażem. Członkostwa, znaczniki zapamiętania, urządzenia, klucze API, otwarte kody Telegram, zgłoszenia do raportów (B.35) i wiersz konta są usuwane; trwająca płatna subskrypcja jest wcześniej natychmiast kończona w Stripe, bez zwrotu (www/ajax.php, fe_konto_reste_loeschen()). Wypowiedzenie w obszarze rozliczeń działa natomiast na koniec okresu; potem konto działa dalej w planie bezpłatnym. To, co pozostaje, opisano w sekcji 6.4. Nigdy niepotwierdzone konta bez logowania są usuwane po 30 dniach, chyba że z ich obszarem roboczym powiązany jest inny członek (nocny przebieg usuwania, część „pending_accounts”). Usuwania nieaktywnych kont nie ma. Jeżeli umowa dotycząca konta zakończy się w inny sposób, np. wskutek naszego wypowiedzenia, usuwamy konto najpóźniej 30 dni po zakończeniu umowy; obecnie odbywa się to ręcznie (zobowiązanie z umowy powierzenia przetwarzania danych). |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.11 Logowanie, urządzenia, drugi składnik i dziennik aktywności
| Pole | Wpis |
|---|
| Cel | Ochrona kont: ograniczanie prób logowania i innych prób podania hasła, wyświetlanie i odwoływanie zalogowanych urządzeń, logowanie dwuskładnikowe, rozliczalność zmian. |
| Kategorie osób, których dane dotyczą | Posiadacze kont i członkowie zespołów; osoby podejmujące próbę logowania, rejestracji lub podania hasła portalu klienta. |
| Kategorie danych osobowych | Próby logowania: adres IP, wpisany adres e-mail, powodzenie, czas (login_attempts). Urządzenia: skrót (hash) identyfikatora sesji (nigdy sam identyfikator), powiązanie ze znacznikiem zapamiętania, adres IP, identyfikator przeglądarki, ustalone na jego podstawie przeglądarka, system operacyjny, typ urządzenia, czas logowania, ostatniej aktywności i odwołania, w trybie „widok jako klient” identyfikator wsparcia (login_sessions). Znacznik dla opcji „Pozostań zalogowany”: identyfikator wyboru, wartość kontrolna, termin ważności (remember_tokens). Uwierzytelnianie dwuskładnikowe: sekret w postaci zaszyfrowanej, czas aktywacji, ostatnio użyty krok czasowy, kody odzyskiwania wyłącznie jako skrót (w users). Dziennik aktywności: konto, obszar roboczy, akcja, cel, szczegóły, adres IP, kraj, czas (audit_logs). Liczniki prób logowania, drugiego składnika, potwierdzenia hasła, resetowania hasła, rejestracji i haseł portali klienta: klucz HMAC wyliczony z celu i identyfikatora konta (w przypadku nieznanego adresu lub przy resetowaniu – z adresu e-mail zapisanego małymi literami), z adresu IP, z konta i adresu IP łącznie albo z identyfikatora portalu (także łącznie z adresem IP), liczba prób, termin wygaśnięcia; adresy e-mail i IP nie są tam przechowywane w postaci jawnej (tabela auth_attempt_buckets). |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO w związku z art. 32 (lista urządzeń, drugi składnik) oraz lit. f (próby logowania, dziennik aktywności). Interes: ochrona kont przed przejęciem, dokumentowanie zmian (art. 5 ust. 2). Wyważenie: skrócony adres nie odpowiada na pytanie „czy to byłem ja?”; dziennik aktywności musi przetrwać spór, który powstaje dopiero po miesiącach. |
| Odbiorcy | Brak. Posiadacz konta widzi swoje urządzenia i otrzymuje próby logowania, urządzenia i aktywności w eksporcie danych; w trakcie „widoku jako klient” nie pojawiają się tam ani adres IP, ani przeglądarka wsparcia. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Próby logowania 7 dni; po udanym logowaniu nieudane próby z tego samego adresu są natychmiast usuwane. Liczniki prób – z końcem ich okna czasowego (obecnie 15 minut, przy resetowaniu hasła i rejestracji jedna godzina); wygasłe usuwa najbliższy dostęp i nocny przebieg. Urządzenia 90 dni po ostatnim użyciu lub po odwołaniu (nocny przebieg usuwania, część „sessions”), wraz z kontem – natychmiast. Znaczniki zapamiętania wygasają po 30 dniach. Dziennik aktywności 365 dni (co noc); przy usunięciu konta jego wpisy pozostają do końca terminu (sekcja 6.4). |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.12 Dowód zawarcia umowy
| Pole | Wpis |
|---|
| Cel | Wykazanie, którą wersję Regulaminu, umowy powierzenia przetwarzania danych i polityki prywatności Klient zaakceptował lub przyjął do wiadomości przy rejestracji oraz że korzysta z usługi na potrzeby swojej działalności gospodarczej. |
| Kategorie osób, których dane dotyczą | Klienci. |
| Kategorie danych osobowych | Dla każdego dokumentu: konto, dokument, wersja (skrót wyświetlonego tekstu), okoliczność, adres IP, identyfikator przeglądarki, czas (legal_consents). Sama wyświetlona wersja z pełnym tekstem, językiem, tytułem i adresem, raz dla każdej wersji (legal_versions; nie zawiera danych osobowych). |
| Podstawa prawna | Art. 6 ust. 1 lit. b i f RODO (dowód zawarcia umowy, obrona przed roszczeniami). |
| Odbiorcy | Brak. Posiadacz konta otrzymuje swoje dowody w eksporcie danych. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Tak długo, jak istnieje konto; po usunięciu konta – cztery lata od wyrażenia akceptacji, następnie usuwane co noc (srv/cron_status.php). Uzasadnienie w kodzie: trzyletni termin przedawnienia liczony od końca roku, zaokrąglony w górę. Czy prawo polskie wskazuje inny termin, należy do weryfikacji prawnej. |
| Środki techniczne i organizacyjne | Sekcja 8. Jeżeli brakuje któregokolwiek z trzech dokumentów, rejestracja jest zamknięta. |
B.13 Zaproszenia do zespołu
| Pole | Wpis |
|---|
| Cel | Zapraszanie kolejnych osób do obszaru roboczego. |
| Kategorie osób, których dane dotyczą | Osoby zaproszone. |
| Kategorie danych osobowych | Adres e-mail, rola, identyfikator zaproszenia, osoba zapraszająca, termin ważności, czas przyjęcia (workspace_invites); wiadomość z zaproszeniem w skrzynce nadawczej (B.25). |
| Źródło | Wprowadzone przez zapraszającego członka. |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO w relacji z Klientem; wobec osoby zaproszonej lit. f (interes Klienta we włączeniu swojego zespołu). |
| Odbiorcy | Dostawca poczty e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Państwo trzecie | Za pośrednictwem dostawcy poczty e-mail. |
| Okres przechowywania | Zaproszenie jest ważne 14 dni i tylko tak długo, jak osoba zapraszająca jest właścicielem lub adminem obszaru roboczego. Nieprzyjęte zaproszenia po wygaśnięciu, przyjęte 30 dni po przyjęciu (co noc, srv/cron_status.php i część „invites” w cfg/fristen_lib.php). Wraz z obszarem roboczym – natychmiast. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.14 „Widok jako klient” przez wsparcie
| Pole | Wpis |
|---|
| Cel | Superadmin widzi aplikację tak, jak widzi ją Klient, aby wyjaśnić zgłoszenie do wsparcia („u mnie brakuje przycisku”). |
| Kategorie osób, których dane dotyczą | Dany Klient; superadmin. |
| Kategorie danych osobowych | Wszystko, co Klient widzi w aplikacji. Rejestrowane: odrębny wiersz urządzenia z identyfikatorem superadmina (login_sessions), początek i koniec w dzienniku aktywności (audit_logs). |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO (wsparcie jako część usługi), pomocniczo lit. f. |
| Granice | Najwyżej jedna godzina, potem pełne wylogowanie. Także zakończenie widoku całkowicie wylogowuje superadmina, łącznie z sesją, z której przyszedł; do panelu administracyjnego wraca on tylko po ponownym zalogowaniu hasłem i drugim składnikiem. Kończy się natychmiast, gdy superadmin zostanie zdegradowany lub zablokowany. Zablokowane jest wszystko, co zmienia konto Klienta: hasło, adres e-mail, drugi składnik, urządzenia, subskrypcja, eksport, usunięcie, przekazanie. Panel administracyjny jest w trakcie widoku zamknięty. Klient widzi dostęp na swojej liście urządzeń i w eksporcie danych jako dostęp wsparcia. |
| Odbiorcy | Brak. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Wiersz urządzenia 90 dni, dziennik aktywności 365 dni. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.15 Domeny, potwierdzenie uprawnień do domeny i monitorowanie
| Pole | Wpis |
|---|
| Cel | Podstawowa usługa dla Klientów: prowadzenie domen na koncie, potwierdzanie uprawnień do domeny, regularne sprawdzanie i wykrywanie zmian. Należą do tego puls formularza (lekkie pobranie bez przeglądarki co 10–30 minut zależnie od planu), codzienny strażnik DNS poczty i certyfikatów, data wygaśnięcia domeny, listy blokujące, publicznie dostępne pliki, wersje widoczne z zewnątrz, inwentarz skryptów, wizualne zmiany formularza, zakłócenia u dostawców CAPTCHA i poczty oraz strażnik luk dla wtyczek formularzy. |
| Kategorie osób, których dane dotyczą | Klienci i członkowie ich zespołów; operatorzy domen, o ile są osobami fizycznymi. |
| Kategorie danych osobowych | Domena z hostem, publicznym identyfikatorem, notatką, etykietą klienta, rodzajem i identyfikatorem potwierdzenia, częstotliwością sprawdzeń, monitorowaniem włączonym/wyłączonym, oknem konserwacji, wartością zapytania, identyfikatorami dla pieczęci, kontroli doręczenia i deploy hooka, kluczem wtyczki, stanami i ostatnimi wynikami strażników (DNS, certyfikat, autentyczność wiadomości z formularza, listy blokujące, publicznie dostępne pliki, nagłówki, wersje) (domains). Puls dla każdej strony z formularzem (form_pulse). Luki wynikające z wersji wtyczek (vuln_hits). Inwentarz skryptów z adresem, skrótem, rozmiarem, zatwierdzeniem wraz z osobą zatwierdzającą i uzasadnieniem (script_inventory, script_changes). Sprawdzenia jak w A.4. W przypadku publicznie dostępnych plików zapisywane są ścieżka, waga i rodzaj, nigdy treść. |
| Zapytania do podmiotów trzecich | Zapytania DNS (SPF, DMARC, MX, wpis potwierdzający). Informacja rejestru przez RDAP według katalogu IANA: wyłącznie nazwa domeny. Listy blokujące DNS (SpamCop, PSBL, Mailspike, SURBL; Spamhaus tylko przy zapisanym dostępie, obecnie nie): adresy IP serwera WWW i serwera pocztowego oraz nazwa domeny, bez danych odwiedzających. Google Web Risk tylko, jeżeli jest skonfigurowany (obecnie nie): adres strony głównej. Usługa znacznika czasu: wyłącznie wartość skrótu (B.19). WPVulnerability: wyłącznie identyfikator wtyczki lub motywu albo wersja WordPressa; porównania z zainstalowaną wersją wtyczki dokonujemy sami. Strony statusu Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun i Brevo: nie jest przekazywane nic poza samym pobraniem. |
| Źródło | Klient; pobrania strony Klienta; publiczne rejestry. |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO. |
| Odbiorcy | Wymienione usługi nie otrzymują danych osobowych naszych Klientów, o ile nazwy domen i adresy serwerów przedsiębiorstwa nimi nie są; w przypadku jednoosobowych przedsiębiorców nazwa domeny może być daną osobową. Członkowie obszaru roboczego widzą domenę. |
| Państwo trzecie | Zapytania mogą trafiać do usług w państwach trzecich (np. informacje rejestru, listy blokujące). Przekazywane jest wyłącznie to, co podano w wierszu „Zapytania do podmiotów trzecich”. |
| Okres przechowywania | Do usunięcia domeny. Wówczas fe_domain_loeschen() natychmiast usuwa wyniki sprawdzeń, formularze, ustalenia, obrazy, raporty, zlecenia, cele alertów i dziennik alertów, incydenty, kody Telegram, doręczenia, puls, luki i potwierdzenia; przez klucze obce – monitorowane formularze, przebiegi w przeglądarce, konto testowe i liczniki formularzy; dane wtyczki dotyczące hosta, jeżeli nie prowadzi go żadna inna domena. Również usuwane są inwentarz skryptów i zmiany skryptów domeny; nie mają one własnego terminu (sekcja 6.4). Wyniki sprawdzeń najwyżej 13 miesięcy, ostatni pozostaje. |
| Środki techniczne i organizacyjne | Sekcja 8. Strażnik publicznie dostępnych plików i wersji tylko dla zweryfikowanych domen, najwyżej jedno pobranie na ścieżkę, tylko pierwsze 8 KB; sprawdzanie cudzych ścieżek bez pytania byłoby narzędziem ataku. |
B.16 Alerty, incydenty i eskalacja wobec posiadacza konta
| Pole | Wpis |
|---|
| Cel | Informowanie Klienta o zakłóceniach i zmianach, uwzględnianie okien konserwacji, potwierdzanie i eskalowanie incydentów. W zakresie, w jakim celami są osoby trzecie, działamy w imieniu Klienta (A.3); w zakresie, w jakim chodzi o samego posiadacza konta, czynność figuruje tutaj. |
| Kategorie osób, których dane dotyczą | Posiadacze kont i członkowie zespołów jako odbiorcy. |
| Kategorie danych osobowych | Jak w A.3. Powiadomienia są wyświetlane w języku posiadacza konta. |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO. |
| Odbiorcy | Dostawca poczty e-mail; wybrane usługi czatu (4.1). |
| Państwo trzecie | Zależnie od kanału (4.1). |
| Okres przechowywania | Jak w A.3: dziennik wysyłki 90 dni, powiadomienia zbiorcze 30 dni po wysyłce, incydenty do rozwiązania, a następnie 180 dni. Cele alertów wraz z domeną. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.17 Raport miesięczny dla kont
| Pole | Wpis |
|---|
| Cel | Pierwszego dnia miesiąca od godz. 08:00 (z nadrabianiem do 3. dnia) jedna wiadomość na konto o wszystkich jego domenach: poziom, liczba punktów i jej zmiana, alerty, odparte boty, wysyłka poczty, wartość porównawcza. |
| Kategorie osób, których dane dotyczą | Aktywni posiadacze kont z włączonym raportem miesięcznym. |
| Kategorie danych osobowych | Adres e-mail, język, wskaźniki domen. |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO (część usługi). Można zrezygnować w ustawieniach; centralnie wyłączalny. |
| Odbiorcy | Dostawca poczty e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Państwo trzecie | Za pośrednictwem dostawcy poczty e-mail. |
| Okres przechowywania | Brak odrębnego przechowywania; wiadomość pozostaje 30 dni w skrzynce nadawczej (B.25). |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.18 Pieczęć i publiczna strona potwierdzenia
| Pole | Wpis |
|---|
| Cel | Klient może osadzić obraz pieczęci na swojej stronie i podlinkować publiczną stronę potwierdzenia. Pieczęć pokazuje „Zabezpieczony” tylko wtedy, gdy domena jest zweryfikowana, monitorowanie działa, a ostatnie zakończone sprawdzenie ma najwyżej 45 dni i dało wynik „Zabezpieczony” lub „Częściowo zabezpieczony”; w przeciwnym razie pokazuje neutralnie „Sprawdzenie formularza”. Strona potwierdzenia podaje poziom i datę, bez pojedynczych ustaleń. |
| Kategorie osób, których dane dotyczą | Osoby odwiedzające stronę Klienta, których przeglądarka ładuje obraz; osoby odwiedzające stronę potwierdzenia. |
| Kategorie danych osobowych | Przy ładowaniu obrazu: adres IP, czas, żądany adres, strona odsyłająca i identyfikator przeglądarki w dzienniku serwera WWW (B.1). Adres obrazu nie rozpoczyna sesji, nie ustawia pliku cookie i nie zapisuje niczego w dzienniku odsłon. Strona potwierdzenia jest zwykłą stroną (B.2, B.3). |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO. Interes: dostarczenie obrazu i zapewnienie działania. Czy w odniesieniu do przekazywania adresu IP odwiedzającego między Klientem a nami istnieje współadministrowanie w rozumieniu orzecznictwa dotyczącego osadzonych treści podmiotów trzecich i czy konieczne jest uzgodnienie na podstawie art. 26, jest otwartym pytaniem weryfikacji prawnej. Klient otrzymuje propozycję tekstu do swojej polityki prywatności. |
| Odbiorcy | Brak. |
| Państwo trzecie | Brak. |
| Okres przechowywania | 14 dni (dziennik serwera WWW). Obraz jest buforowany przez godzinę. Po wyłączeniu pieczęci identyfikator traci ważność. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.19 Protokół weryfikacji i znacznik czasu
| Pole | Wpis |
|---|
| Cel | Protokół dla każdej domeny i każdego miesiąca (płatne plany): co sprawdzono, z jakim wynikiem, co zgłoszono i co się zmieniło, jako dowód na potrzeby rozliczalności, ubezpieczyciela lub audytu dostawców. Każda wersja otrzymuje numer weryfikacyjny; publiczna strona potwierdza domenę, okres i wskaźniki, bez szczegółów. Od 7 października 2026 r. czas potwierdza usługa znacznika czasu zgodna z RFC 3161. |
| Kategorie osób, których dane dotyczą | Klienci; pośrednio osoby, które mogą być wymienione w protokole jako zatwierdzające lub potwierdzające. |
| Kategorie danych osobowych | Domena, miesiąc, numer weryfikacyjny, skrót treści (SHA-512), podsumowanie i dane protokołu, odpowiedź ze znacznikiem czasu, usługa znacznika czasu i czas, nieudane próby (proof_docs). |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO. |
| Odbiorcy | Usługa znacznika czasu (domyślnie Certum, zapasowo DigiCert) otrzymuje wyłącznie skrót protokołu, a nie jego treść. Publicznie: wskaźniki przez stronę potwierdzenia. Klient i każdy, komu przekaże on protokół lub numer weryfikacyjny. |
| Państwo trzecie | Brak przekazywania danych osobowych: skrót nie pozwala na wnioskowanie o treści. Zapasowa usługa ma siedzibę w USA. |
| Okres przechowywania | Do usunięcia domeny (fe_domain_loeschen()). Znacznik czasu nie jest kwalifikowanym elektronicznym znacznikiem czasu w rozumieniu eIDAS. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.20 Wtyczka i rozszerzenie: sprawdzenie, łączenie i przekazywanie danych
| Pole | Wpis |
|---|
| Cel | Wtyczka do WordPressa i rozszerzenie do TYPO3 mogą zlecić sprawdzenie (także bez konta), połączyć się z kontem (instalacja po jednym kliknięciu na koncie stanowi potwierdzenie uprawnień do domeny), odblokować funkcje ochronne, codziennie przekazywać liczby (A.9), natychmiast zgłaszać błędy poczty i tryb konserwacji. |
| Kategorie osób, których dane dotyczą | Klienci; operatorzy stron, którzy korzystają z wtyczki bez konta. |
| Kategorie danych osobowych | Dla każdego hosta: wersja wtyczki i CMS, liczba sprawdzeń, ostatni identyfikator raportu, skrót sekretu połączenia, pierwszy i ostatni kontakt (plugin_sites). Jednorazowe kody do łączenia jako skrót z terminem ważności (plugin_connect_tokens). Kody wdrożeniowe agencji jako skrót z prefiksem, nazwą, liczbą użyć, osobą zakładającą (workspace_connect_codes). Dziennik żądań z adresem IP wywołującego serwera (B.4). Klucz wtyczki jest publicznie widoczny w nagłówku strony; jest skrótem sekretu, a sam sekret jest zapisywany wyłącznie jako skrót i nigdy nie jest zwracany. |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO (konto); bez konta lit. f (zlecone sprawdzenie, przeciwdziałanie nadużyciom). |
| Odbiorcy | Brak. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Dane hosta są usuwane, gdy żadna domena go już nie prowadzi; wiersz wtyczki bez konta dopiero po 90 dniach bez kontaktu (nocny przebieg usuwania, część „orphan_hosts”). Kody jednorazowe dzień po wygaśnięciu. Kody wdrożeniowe wraz z obszarem roboczym. |
| Środki techniczne i organizacyjne | Sekcja 8. Od 27 września 2026 r. serwer przyjmuje wyłącznie pary kluczy powiązane ze stroną internetową; starsze, niepowiązane sekrety połączenia zostały usunięte. |
B.21 Ochrona roju
| Pole | Wpis |
|---|
| Cel | Wspólna ochrona przed spamem: połączone strony zgłaszają domeny z linków w wiadomościach, które zatrzymała ich warstwa ochronna. Domena, która w ciągu siedmiu dni pojawi się na co najmniej trzech stronach z co najmniej pięcioma trafieniami, trafia na listę przekazywaną z powrotem do wszystkich połączonych stron; ich warstwa ochronna umieszcza wiadomości z takimi linkami w kwarantannie, nigdy ich nie usuwa bez śladu. |
| Kategorie osób, których dane dotyczą | Właściciele zgłoszonych domen z linków, o ile są osobami fizycznymi (np. operator strony spamowej pod własnym nazwiskiem). Nie dotyczy nadawców ani odbiorców wiadomości: adresy, teksty i nazwiska nie są zgłaszane. |
| Kategorie danych osobowych | Sygnały: rodzaj, domena, zgłaszający host, dzień, trafienia (swarm_signals). Lista: rodzaj, domena, liczba stron i trafień, znaczniki czasu (swarm_list). Nigdy nie są umieszczane na liście duże usługi, domeny naszych Klientów ani wyjątki ustalone przez operatora. |
| Sieci IP | Przygotowane jest współdzielenie sieci IP (/24, /48). Jest ono wyłączone i wtyczka żadnych nie zgłasza; zostanie włączone dopiero po analizie prawnej, ponieważ adresy IP są danymi osobowymi. |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO. Interes: ochrona formularzy wszystkich Klientów przed falami spamu. Wyważenie: wyłącznie domeny, progi minimalne przeciw zatruwaniu listy, brak utraty wiadomości, możliwość wykreślenia w każdej chwili. |
| Odbiorcy | Wszystkie połączone strony (lista domen). |
| Państwo trzecie | Zależnie od lokalizacji połączonych stron; lista może trafiać także do stron spoza EOG. Danymi osobowymi jest tylko w przypadkach granicznych (domeny osób fizycznych). Podstawę przekazania zgodnie z rozdziałem V RODO dla tych przypadków trzeba jeszcze ustalić (otwarta kwestia do weryfikacji prawnej). |
| Okres przechowywania | Sygnały 30 dni (codzienny przebieg roju od godz. 04:00, cfg/swarm_lib.php). Lista jest codziennie obliczana na nowo; to, co nie osiąga już progu, wypada z niej. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.22 Klucze API, interfejs programistyczny i serwer MCP
| Pole | Wpis |
|---|
| Cel | Dostęp własnych narzędzi Klienta (REST API, Zapier, Make, serwer MCP dla asystentów AI) do jego domen, sprawdzeń i incydentów. |
| Kategorie osób, których dane dotyczą | Klienci zakładający klucze. |
| Kategorie danych osobowych | Klucz wyłącznie jako skrót, prefiks, nazwa, czas utworzenia, ostatniego użycia i odwołania (api_keys). Wywołania na minutę (api_usage). |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO. |
| Odbiorcy | Narzędzie, któremu Klient przekaże klucz; określa je Klient. |
| Państwo trzecie | Zależnie od narzędzia Klienta. |
| Okres przechowywania | Klucze do odwołania, wraz z kontem – natychmiast; klucze bez konta (dane historyczne) co noc. Liczniki wywołań po jednym dniu (okazjonalnie czyszczone przy wywołaniu). |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.23 reCAPTCHA i własna ochrona formularzy
| Pole | Wpis |
|---|
| Cel | Odpieranie zautomatyzowanych wywołań naszych własnych formularzy: bezpłatne sprawdzenie, narzędzie do nagłówków, opt-out, logowanie, rejestracja, zapomniane hasło i jego resetowanie, wsparcie i kontakt. Ponadto własna ochrona bez podmiotów trzecich: pułapka (ukryte pole), podpisana kontrola czasu i token CSRF. Od 29 października 2026 r. dodatkowo nasza ochrona formularzy formconfirmed (dowód wykonania obliczeń i jednorazowy znacznik kontrolny) przy bezpłatnym sprawdzeniu, rejestracji, logowaniu i funkcji „zapomniane hasło”. |
| Kategorie osób, których dane dotyczą | Osoby wysyłające te formularze. |
| Kategorie danych osobowych | U Google: adres IP, dane przeglądarki i urządzenia, dane o zachowaniu, pliki cookie Google. U nas: ocena Google (liczba punktów i akcja) wyłącznie w chwili sprawdzenia, bez zapisywania, także wtedy, gdy zgłoszenie zostanie odrzucone. Przy własnej ochronie formularzy: adres IP (zapisywany tylko w skróconej postaci i jako skrót), strona, momenty, wypełnienie pola-pułapki tak/nie; bez treści. |
| Moment | Skrypt Google ładuje się dopiero przy wysyłaniu chronionego formularza, a nie przy otwarciu strony. Własna ochrona formularzy pobiera zadanie przy otwarciu strony i wykonuje obliczenia, gdy tylko formularz zostanie użyty. W systemie deweloperskim reCAPTCHA jest wyłączona. |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO. Interes: ochrona przed botami, zwłaszcza przy bezpłatnym sprawdzeniu, które w przeciwnym razie mogłoby zostać użyte przeciwko cudzym stronom. Czy dostęp do urządzenia końcowego wymaga zgody na podstawie § 25 TDDDG lub art. 399 PKE, mimo że skrypt ładuje się dopiero przy wysyłaniu, jest otwartym pytaniem weryfikacji prawnej. Własna ochrona formularzy nie używa plików cookie, niczego nie zapisuje w przeglądarce i nie tworzy odcisku urządzenia; w dłuższej perspektywie ma zastąpić reCAPTCHA. |
| Odbiorcy | Google Ireland Limited; Google LLC. Przy własnej ochronie formularzy brak. |
| Państwo trzecie | USA (wyłącznie reCAPTCHA). Podstawa: certyfikacja w ramach EU-US Data Privacy Framework lub standardowe klauzule umowne; do szczegółowego udokumentowania. |
| Okres przechowywania | reCAPTCHA: u nas brak przechowywania; u Google według jego zasad. Własna ochrona formularzy: skrót identyfikatora 1 godzina, wykorzystane znaczniki kontrolne najwyżej 11 minut, wyniki sprawdzeń bez adresu IP 30 dni. |
| Awaria | Jeżeli Google nie odpowie w ciągu trzech sekund lub odpowiedź nie nadaje się do użycia, zgłoszenie jest odrzucane; tak samo pusty token i odpowiedź dla innej akcji niż akcja formularza. Sprawdzenie jest pomijane tylko przy wyłączonej reCAPTCHA. Przy własnej ochronie formularzy zgłoszenie bez ważnego znacznika kontrolnego jest odrzucane; jeżeli usługa była niedostępna przy pobieraniu zadania, zgłoszenie jest dopuszczane. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.24 Wsparcie i formularz kontaktowy
| Pole | Wpis |
|---|
| Cel | Przyjmowanie zapytań przez okno wsparcia i stronę kontaktową oraz udzielanie na nie odpowiedzi. Oba kanały korzystają z tej samej ścieżki i tej samej tabeli. |
| Kategorie osób, których dane dotyczą | Osoby wysyłające zapytania, zalogowane lub nie. |
| Kategorie danych osobowych | Konto (jeżeli osoba jest zalogowana; wówczas obowiązuje adres konta, a nie wpisany), adres e-mail, powód z zamkniętej listy, tekst do 4000 znaków, status, pełny adres IP, kraj, identyfikator przeglądarki, strona odsyłająca (tylko własne ścieżki), język, czas wpływu i odpowiedzi (support_requests); wpis w dzienniku aktywności (bez tekstu); potwierdzenie otrzymania dla pytającego w skrzynce nadawczej (B.25), z tekstem do 2000 znaków tylko w przypadku zalogowanych nadawców, przy zapytaniach bez logowania bez tekstu. |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO, o ile zapytanie dotyczy umowy; w przeciwnym razie lit. f. Pełny adres IP: lit. f (ograniczenie do trzech zapytań na godzinę i adres, przeciwdziałanie nadużyciom). |
| Odbiorcy | Dostawca poczty e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) w zakresie potwierdzenia i odpowiedzi. Telegram otrzymuje stały sygnał bez żadnej zmiennej („jest nowe zapytanie do wsparcia”), a więc żadnych danych osobowych. |
| Państwo trzecie | Za pośrednictwem dostawcy poczty e-mail. |
| Okres przechowywania | 24 miesięcy (nocny przebieg usuwania, część „support”); ręcznie wcześniej. Przy usunięciu konta zapytania pozostają do końca terminu (sekcja 6.4). |
| Środki techniczne i organizacyjne | Sekcja 8. reCAPTCHA, własna ochrona formularzy, ograniczenie częstotliwości. |
B.25 Wysyłka e-maili (skrzynka nadawcza)
| Pole | Wpis |
|---|
| Cel | Wiadomości transakcyjne: potwierdzenie rejestracji i nowych adresów e-mail, resetowanie hasła, zaproszenia, alerty, raporty miesięczne, potwierdzenia i raporty portalu, potwierdzenia i odpowiedzi wsparcia, przypomnienia o okresie próbnym i konfiguracji, komunikaty eksploatacyjne dla operatorów. Bez reklam, bez wiadomości do osób, które same się nie zapisały ani nie zostały wpisane przez Klienta jako odbiorcy. |
| Kategorie osób, których dane dotyczą | Odbiorcy tych wiadomości. |
| Kategorie danych osobowych | Adres odbiorcy, temat, pełna treść, adres do odpowiedzi, cel, kanał wysyłki, status, błąd, próby, znaczniki czasu (mail_outbox). Treść może zawierać linki potwierdzające i resetujące z ważnymi identyfikatorami. |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO; w przypadku komunikatów eksploatacyjnych lit. f. |
| Odbiorcy | Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (wysyłka); posiadacz konta widzi swoje wysłane wiadomości w eksporcie danych (bez treści). |
| Państwo trzecie | Zależnie od miejsca przetwarzania u dostawcy poczty e-mail; umowa i podstawa przekazania wymagają jeszcze udokumentowania (sekcja 4). |
| Okres przechowywania | 30 dni (co noc, srv/cron_status.php). Termin ten jest celowo najkrótszy spośród dzienników: długi dziennik wysyłki byłby zbiorem ważnych kluczy. Przebieg statusowy co pięć minut sprawdza, czy należy ponowić próbę. |
| Stan | Wysyłkę poczty należy skonfigurować przed startem. Dopóki dostawca poczty e-mail wraz z siedzibą i podstawą nie zostanie ustalony, teksty prawne zawierają oznaczenie. |
| Środki techniczne i organizacyjne | Sekcja 8. Nieudane wiadomości są ponawiane w rosnących odstępach i porzucane po maksymalnej liczbie prób. |
B.26 Płatności i rozliczenia
| Pole | Wpis |
|---|
| Cel | Zawieranie subskrypcji i zarządzanie nimi (miesięcznie lub rocznie z góry), 14-dniowy okres próbny bez karty z przypomnieniem trzy dni przed końcem, płatność na fakturę dla subskrypcji rocznych (fabrycznie wyłączona), odblokowania za pomocą kodów hostingodawców i partnerów bez płatności, wystawianie faktur, przechowywanie do celów podatkowych. |
| Kategorie osób, których dane dotyczą | Klienci. |
| Kategorie danych osobowych | U Stripe: adres e-mail, imię i nazwisko, adres do faktury, NIP UE, dane płatnicze, faktury; jako metadane nasz identyfikator konta i plan. U nas: identyfikator klienta i subskrypcji w Stripe, plan, status, koniec okresu, wypowiedzenie na koniec okresu (users); otrzymane zdarzenia Stripe wyłącznie z identyfikatorem, rodzajem, statusem i znacznikami czasu, bez treści (stripe_events); realizacje kodów hostingodawców z kontem, kampanią i terminem ważności (bundle_redemptions). Dane kart nigdy do nas nie docierają. |
| Źródło | Klient w procesie płatności Stripe; zdarzenia ze Stripe. |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO; w zakresie przechowywania do celów podatkowych lit. c. |
| Odbiorcy | Stripe Payments Europe Limited (Irlandia); Stripe, Inc. (USA). Stripe działa w odniesieniu do części obsługi płatności na własną odpowiedzialność; dokładny podział ról jest częścią weryfikacji prawnej. |
| Państwo trzecie | USA za pośrednictwem Stripe, Inc.; podstawa: Data Privacy Framework lub standardowe klauzule umowne zgodnie z warunkami Stripe. |
| Okres przechowywania | Pola rozliczeniowe wraz z kontem; trwająca subskrypcja jest kończona przed usunięciem konta. Faktury i dokumenty rozliczeniowe zgodnie z polskim prawem podatkowym przez pięć lat od końca roku, w którym upłynął termin płatności podatku; znajdują się w Stripe i są dostępne w portalu klienta Stripe. Zdarzenia Stripe i realizacje kodów nie mają terminu (sekcja 6.4). |
| Środki techniczne i organizacyjne | Sekcja 8. Przyjmowanie zdarzeń Stripe wyłącznie z ważnym podpisem; każde zdarzenie jest przetwarzane jednokrotnie. |
B.27 Kopie zapasowe
| Pole | Wpis |
|---|
| Cel | Odtworzenie po błędzie: omyłkowe usunięcie, uszkodzona migracja. |
| Kategorie osób, których dane dotyczą | Wszystkie osoby, których dane znajdują się w bazie danych. |
| Kategorie danych osobowych | Pełny, skompresowany zrzut bazy danych aplikacji. Zrzuty ekranu i pliki logo znajdują się poza bazą danych i nie są częścią tej kopii zapasowej. Dane dostępowe kont testowych są w niej zawarte wyłącznie jako szyfrogram (A.5). |
| Przebieg | Co noc o godz. 03:00, po przebiegu usuwania, aby kopia nie zabierała tego, co terminy właśnie usunęły. Zrzut jest zachowywany dopiero po sprawdzeniu jego zawartości (kod wyjścia, liczba tabel, wiersz końcowy). W niedziele próba odtworzenia wgrywa najnowszą kopię do jednorazowej bazy danych i porównuje ją tabela po tabeli. Jeżeli coś się nie powiedzie, operatorzy otrzymują sygnał i wiadomość e-mail. |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO w związku z art. 32 ust. 1 lit. c. |
| Odbiorcy | Brak. |
| Państwo trzecie | Brak. |
| Okres przechowywania | 14 dni; starsze zrzuty są usuwane dopiero po udanym utworzeniu nowej kopii (cfg/backup_lib.php). Usunięcia dokonane w tym czasie docierają do kopii zapasowej dopiero z jej wygaśnięciem; w razie odtworzenia z kopii zlecenia usunięcia są następnie stosowane ponownie. |
| Miejsce | Kopie zapasowe znajdują się obecnie w tej samej lokalizacji co baza danych i nie są odrębnie szyfrowane; planowana jest zaszyfrowana kopia w drugiej lokalizacji (sekcje 8.1 i 10). |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.28 Dziennik błędów i alert o błędach
| Pole | Wpis |
|---|
| Cel | Znajdowanie i usuwanie błędów, zanim zgłosi je Klient. Nowe rodzaje błędów i fale błędów są zgłaszane operatorom, do tego codzienne podsumowanie od godz. 08:00. |
| Kategorie osób, których dane dotyczą | Użytkownicy, przy których żądaniu powstaje błąd; pośrednio osoby, których dane znajdują się w komunikacie o błędzie. |
| Kategorie danych osobowych | Poziom, źródło, komunikat, kontekst jako JSON, identyfikator konta z sesji, czas (error_logs). Rodzaje błędów: odcisk (fingerprint), wzorzec (z którego usunięto adresy e-mail, adresy, liczby i identyfikatory), jeden niezmieniony przykładowy komunikat do 2000 znaków, pierwsze i ostatnie wystąpienie, liczba (error_kinds). |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO (bezpieczeństwo działania, art. 32). |
| Odbiorcy | Operatorzy e-mailem za pośrednictwem dostawcy poczty e-mail: przy nowym rodzaju błędu źródło i surowy tekst komunikatu do 400 znaków (nieoczyszczony), do tego codzienne podsumowanie e-mailem; przy fali błędów wysyłany jest tylko sygnał przez Telegram. Telegram otrzymuje wyłącznie stałe zdania bez zmiennych („Wystąpił nowy rodzaj błędu”, „Wiele błędów w krótkim czasie”). |
| Państwo trzecie | Za pośrednictwem dostawcy poczty e-mail. |
| Okres przechowywania | Dziennik błędów 90 dni (co noc). Rodzaje błędów bez terminu (sekcja 10). Alert o błędach jest włączony w systemie produkcyjnym, a wyłączony w systemie deweloperskim. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.29 Sygnały eksploatacyjne i monitorowanie stanu
| Pole | Wpis |
|---|
| Cel | Wykrywanie awarii: co pięć minut sprawdzenie komponentów (strona główna, baza danych, miejsce na dysku, sygnał życia skanera, zaległości w kolejce), strona statusu, sygnał przy zakłóceniu i jego ustaniu, sygnał życia wysyłany do zewnętrznej usługi monitorującej, aby zauważona została także całkowita awaria; zator przed skanerem. |
| Kategorie osób, których dane dotyczą | Zasadniczo brak. |
| Kategorie danych osobowych | Brak. Wiersze dzienne dla każdego komponentu z liczbą sprawdzeń i ostatnim błędem (system_status_logs), sygnał życia skanera (scanner_heartbeat), wskaźniki dzienne bez odniesienia do osób (daily_stats). Sygnały do Telegramu to stałe zdania bez zmiennych; sygnał życia to wywołanie bez treści. |
| Podstawa prawna | Nie dotyczy z uwagi na brak danych osobowych; na wszelki wypadek art. 6 ust. 1 lit. f. |
| Odbiorcy | Telegram (stałe zdania); zewnętrzna usługa monitorująca (wyłącznie wywołanie); operatorzy e-mailem. |
| Państwo trzecie | Telegram poza UE; nie są przekazywane żadne dane osobowe. |
| Okres przechowywania | Wiersze statusu 400 dni (co noc). |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.30 Opt-out – wykluczenie domeny
| Pole | Wpis |
|---|
| Cel | Każdy może bez potwierdzania uprawnień trwale wykluczyć dowolną domenę ze sprawdzeń; blokada działa natychmiast dla wszystkich ścieżek sprawdzania (bezpłatne sprawdzenie, wtyczka bez konta, badanie, sprawdzenie potencjalnego klienta, narzędzie do nagłówków), a także dla domen płacących Klientów z potwierdzeniem uprawnień do domeny; ich bieżące monitorowanie kończy się wraz z następnym przypadającym sprawdzeniem. Obejmuje domenę i jej wariant www, nie inne subdomeny. Uchylić ją możemy wyłącznie my, na wniosek i po przedstawieniu potwierdzenia uprawnień. Aby nadużycie (np. konkurent blokujący cudze domeny) dało się rozpoznać i cofnąć, blokada jest rejestrowana. |
| Kategorie osób, których dane dotyczą | Osoby wykluczające domenę. |
| Kategorie danych osobowych | Domena, dobrowolnie podany powód do 250 znaków, źródło, adres IP, kraj, identyfikator przeglądarki, czas; przy uchyleniu czas, osoba uchylająca i powód (blocklist). Dziennik żądań jak w B.4. |
| Podstawa prawna | W odniesieniu do wykluczenia art. 6 ust. 1 lit. f RODO. Interes: trwałe uwzględnianie, na wszystkich ścieżkach sprawdzania, życzenia, aby domena nie była sprawdzana. Jeżeli osoba dokonująca wykluczenia jest sama osobą, której dane dotyczą, wykluczenie realizuje zarazem jej sprzeciw na podstawie art. 21 (art. 6 ust. 1 lit. c). W odniesieniu do adresu, kraju i identyfikatora przeglądarki lit. f (wykrywanie nadużyć). |
| Odbiorcy | Google (reCAPTCHA, B.23). |
| Państwo trzecie | USA za pośrednictwem reCAPTCHA. |
| Okres przechowywania | Adres IP, kraj i identyfikator przeglądarki po 12 miesiącach (nocny przebieg usuwania, część „optout_ip”). Samo wykluczenie pozostaje na stałe, aby było skuteczne. |
| Środki techniczne i organizacyjne | Sekcja 8. Wiele blokad z jednego kraju w krótkim czasie powoduje odnotowanie nieprawidłowości (B.4). |
B.31 Przypomnienie po rejestracji
| Pole | Wpis |
|---|
| Cel | Jedna jedyna wiadomość od dwóch do 14 dni po rejestracji, wysyłana do potwierdzonych kont bez potwierdzonej domeny: „Dodaj stronę” lub „Potwierdź domenę”. Bez oferty, bez ceny, bez propozycji zmiany planu; z informacją, że wiadomość się nie powtórzy. W dni robocze w godz. 09–18, najwyżej 50 na przebieg. |
| Kategorie osób, których dane dotyczą | Nowi posiadacze kont. |
| Kategorie danych osobowych | Adres e-mail, język, czas wysyłki (pole „przypomnienie wysłane” w users), domena i stan potwierdzenia. |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO (wskazówka dotycząca konfiguracji własnego konta). Czy wiadomość stanowi komunikat dotyczący stosunku umownego, czy informację handlową wymagającą zgody (art. 10 ustawy o świadczeniu usług drogą elektroniczną (u.ś.u.d.e.), art. 398 PKE, § 7 UWG), jest otwartym pytaniem weryfikacji prawnej; operator może ją wyłączyć centralnie. |
| Odbiorcy | Dostawca poczty e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Państwo trzecie | Za pośrednictwem dostawcy poczty e-mail. |
| Okres przechowywania | Czas wysyłki istnieje tak długo jak konto; wiadomość 30 dni w skrzynce nadawczej. |
| Środki techniczne i organizacyjne | Sekcja 8. Czas jest ustawiany przed wysyłką, aby przerwanie nie spowodowało wysłania drugiej wiadomości. |
B.32 Bot Telegram dla alertów Klientów
| Pole | Wpis |
|---|
| Cel | Czat Telegram jest powiązywany jako cel alertów: Klient otrzymuje link do naszego bota z jednorazowym kodem; gdy odbiorca naciśnie „Start”, nasz serwer odczytuje kod z nowych wiadomości do bota i zapamiętuje identyfikator czatu. Otwarty punkt dostępu po naszej stronie (webhook) nie jest do tego potrzebny. |
| Kategorie osób, których dane dotyczą | Klienci i osoby, których czat Telegram jest powiązywany. |
| Kategorie danych osobowych | Kod jednorazowy, domena, konto zakładające, zdarzenia, tryb wysyłki, identyfikator czatu, znaczniki czasu (telegram_links); identyfikator czatu jako cel (alerts). Telegram dostarcza wraz z wiadomością dalsze dane profilowe; analizowane i zapisywane są wyłącznie kod i identyfikator czatu. |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO; w odniesieniu do osób trzecich jako odbiorców – A.3. |
| Odbiorcy | Telegram. |
| Państwo trzecie | Poza UE, brak decyzji stwierdzającej odpowiedni stopień ochrony; wyboru dokonuje Klient (4.1). Podstawa i informacja są otwartymi pytaniami weryfikacji prawnej. |
| Okres przechowywania | Kod jest ważny 30 minut; wiersze powiązań są usuwane przy tworzeniu nowego kodu po upływie jednego dnia, otwarte kody – wraz z kontem i domeną. Identyfikator czatu jako cel do usunięcia celu alertu lub domeny. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.33 Program partnerski i kody odblokowujące
| Pole | Wpis |
|---|
| Cel | Konto może pozyskiwać nowych Klientów za pomocą kodu polecającego i otrzymuje prowizję od ich opłaconych faktur przez ograniczoną liczbę miesięcy. Kod jest przekazywany w adresie aż do rejestracji; nie jest ustawiany żaden plik cookie. Hostingodawcy i partnerzy mogą wydawać kody, które odblokowują plan na określony czas bez płatności; tydzień przed końcem Klient otrzymuje przypomnienie. |
| Stan | Program partnerski jest fabrycznie wyłączony, dopóki nie zostaną ustalone Warunki programu partnerskiego. |
| Kategorie osób, których dane dotyczą | Partnerzy i pozyskani Klienci. |
| Kategorie danych osobowych | Kod polecający, polecający partner i czas polecenia (w users); prowizja z partnerem, Klientem, identyfikatorem faktury w Stripe, kwotą, walutą, prowizją, statusem, znacznikami czasu (partner_commissions). Odblokowanie z planem, końcem, źródłem, przypomnieniem (w users); kampanie i realizacje (bundle_campaigns, bundle_redemptions). |
| Podstawa prawna | Art. 6 ust. 1 lit. b RODO (umowa partnerska); w odniesieniu do Klienta lit. f (rozliczenie prowizji, bez przekazywania jego danych partnerowi poza wysokością prowizji); dokumenty podatkowe lit. c. |
| Odbiorcy | Partner widzi swoje prowizje. |
| Państwo trzecie | Brak. |
| Okres przechowywania | Polecenie i odblokowanie wraz z kontem. Prowizje i realizacje nie mają terminu w kodzie; jako dowody księgowe prowizje podlegają przechowywaniu do celów podatkowych (sekcja 6.4). |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.34 Punkt zgłaszania luk bezpieczeństwa
| Pole | Wpis |
|---|
| Cel | Przyjmowanie zgłoszeń dotyczących słabych punktów w formexposed, zgodnie z zasadami na stronie Bezpieczeństwo i w /.well-known/security.txt. |
| Kategorie osób, których dane dotyczą | Osoby zgłaszające; osoby, których dane zawiera zgłoszenie jako dowód. |
| Kategorie danych osobowych | Adres e-mail, imię i nazwisko, treść zgłoszenia i załączniki w postaci przesłanej przez osobę zgłaszającą. Zgłoszenie dociera do nas e-mailem na podany tam adres; aplikacja go nie zapisuje. |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO (bezpieczeństwo usługi, art. 32); w zakresie, w jakim zgłoszenie zawiera dane osobowe osób trzecich jako dowód, również lit. f w celu usunięcia luki. |
| Odbiorcy | Dostawca poczty e-mail oraz, do czasu skonfigurowania skrzynki, przekierowanie domeny w Namecheap (sekcja 4). |
| Państwo trzecie | Za pośrednictwem dostawcy poczty e-mail oraz, do czasu przestawienia, przekierowania. |
| Okres przechowywania | Termin nie został określony ani wdrożony technicznie (sekcja 10). Termin ustali jeszcze operator; nasuwającym się rozwiązaniem byłoby usuwanie danych dowodowych osób trzecich po usunięciu luki i traktowanie korespondencji jak zapytań do wsparcia. |
| Środki techniczne i organizacyjne | Sekcja 8. |
B.35 Zgłoszenie do raportu
| Pole | Wpis |
|---|
| Cel | Przyjmowanie zgłoszeń pod raportem („Coś się nie zgadza w tym raporcie?”) w celu wykrywania błędów rozpoznawania formularzy. Superadministrator je klasyfikuje (nowe, potwierdzone, naprawione, odrzucone) i może pobrać dane sprawdzenia z raportu jako przypadek testowy (formularze z polami, powodami i wynikami, bez zrzutów ekranu i bez aktywnie wysłanych tekstów). |
| Kategorie osób, których dane dotyczą | Osoby oglądające raport, zalogowane lub nie. |
| Kategorie danych osobowych | Kategoria i sprawdzenie ze stałych list, adres strony do 500 znaków, tekst do 1000 znaków, język, czas, identyfikator raportu, sprawdzenie, host; identyfikator konta, jeśli zalogowano; HMAC-SHA256 adresu IP z tajnym kluczem na potrzeby limitu; status, osoba obsługująca, czas obsługi (report_feedback). Dziennik aktywności: zmiany statusu i pobrania przypadku testowego. Bez adresu e-mail, bez adresu IP w postaci jawnej. |
| Podstawa prawna | Art. 6 ust. 1 lit. f RODO (wykrywanie i usuwanie błędów rozpoznawania; limit przeciw nadużyciom). |
| Odbiorcy | Brak. |
| Państwo trzecie | Brak. |
| Okres | 24 miesięcy (nocny przebieg usuwania, część „report_feedback”); suma kontrolna adresu IP czyszczona po 2 dniach (część „report_feedback_ip”); przy usunięciu konta natychmiast. Pobrane przypadki testowe nie zawierają danych osoby zgłaszającej. |
| TŚO | Sekcja 8. Własna ochrona formularzy (pułapka, podpisany czas, CSRF), najwyżej 5 zgłoszeń na godzinę i 20 na dzień na sumę kontrolną, 10 na raport; odczyt tylko dla superadministratorów. |
6. Przechowywanie – co obejmuje nocny przebieg usuwania, a czego nie
Istnieje automatyczne usuwanie i ma ono swoje miejsce. Przebieg statusowy (srv/cron_status.php) jest uruchamiany co pięć minut przez tablicę crona serwera WWW, zarówno w systemie produkcyjnym, jak i deweloperskim. Sprawdza komponenty, pobiera wiadomości kontroli doręczenia, planuje sprawdzenia i wysyła alerty. Raz dziennie, w oknie od 03:00 do 03:04, usuwa dane według terminów, a następnie tworzy kopię zapasową. Od 27 września 2026 r. wywołuje przy tym dodatkowo przebieg terminów w cfg/fristen_lib.php (fe_fristen_lauf()), którego części działają niezależnie od siebie: jeżeli jedna zawiedzie, pozostałe działają dalej, a błąd trafia do dziennika błędów.
Dowód, że przebieg działa: status kopii zapasowej systemu deweloperskiego wykazuje dla 11 października 2026 r. udaną kopię o godz. 03:00; kopia powstaje w tym samym bloku bezpośrednio po usuwaniu. Dziennik dla każdej usuniętej tabeli przebieg zapisuje wyłącznie na standardowe wyjście, które tablica crona odrzuca; trwałego zapisu tego, co i kiedy zostało usunięte, nie ma (sekcja 10).
Terminy, które pojawiają się jako symbole zastępcze, znajdują się w panelu administracyjnym w ustawieniach przechowywania. Te same ustawienia odczytuje przebieg; teksty pokazują więc zawsze termin, po którym dane są faktycznie usuwane.
6.1 Objęte codziennym przebiegiem
| Dane | Termin i zdarzenie wyzwalające | Miejsce w kodzie |
|---|
Dziennik odsłon (access_logs) | 60 dni | srv/cron_status.php |
Dziennik aktywności (audit_logs) | 365 dni | srv/cron_status.php |
Dziennik błędów (error_logs) | 90 dni | srv/cron_status.php |
Skrzynka nadawcza (mail_outbox) | 30 dni | srv/cron_status.php |
Znaczniki „Pozostań zalogowany” (remember_tokens) | po wygaśnięciu (30 dni) | srv/cron_status.php |
Nieprzyjęte zaproszenia (workspace_invites) | po wygaśnięciu (14 dni) | srv/cron_status.php |
Próby logowania (login_attempts); liczniki prób (auth_attempt_buckets) | 7 dni; liczniki z upływem ich okna czasowego (obecnie 15 minut, przy resetowaniu hasła i rejestracji jedna godzina), także przy najbliższym dostępie | srv/cron_status.php |
Dziennik żądań sprawdzeń bez konta (check_throttle) | 7 dni | srv/cron_status.php |
Jednorazowe kody do łączenia wtyczki (plugin_connect_tokens) | 1 dzień po wygaśnięciu | srv/cron_status.php |
Załatwione nieprawidłowości (abuse_flags) | 90 dni po załatwieniu | srv/cron_status.php |
| Wygasłe raporty wraz z wynikiem sprawdzenia, formularzami, ustaleniami, obrazami i zleceniem (tylko bez domeny na koncie) | anonimowe 30 dni, potencjalni klienci 90 dni | fe_reports_aufraeumen() |
Dziennik wysyłki alertów (alert_log) | 90 dni | fe_alert_log_aufraeumen() |
Wiersze statusu (system_status_logs) | 400 dni | srv/cron_status.php |
Dowody akceptacji usuniętych kont (legal_consents) | gdy konto zostało usunięte, a akceptacja miała miejsce ponad 4 lata wcześniej | srv/cron_status.php |
| Osierocone dane usuniętych domen: wyniki sprawdzeń, zlecenia, dane alertów, incydenty, kody Telegram, doręczenia, puls, luki, potwierdzenia, inwentarz skryptów i zmiany skryptów | natychmiast przy następnym przebiegu | fe_fristen_lauf(), części „orphan_scans”, „orphan_rows” |
| Dane wtyczki dotyczące hostów bez domeny; wiersz wtyczki bez konta | natychmiast; wiersz po 90 dniach bez kontaktu | część „orphan_hosts” |
Wyniki narzędzia do nagłówków (header_checks) | obecnie 90 dni | część „header_checks” |
| Wyniki sprawdzeń domeny z formularzami, ustaleniami, obrazami, raportami, zleceniami | 13 miesięcy; ostatni zakończony dla każdej domeny pozostaje | część „old_scans” |
Przebiegi w przeglądarce, zakończone zlecenia przeglądarkowe, szeregi czasowe (form_browser_runs, scan_jobs, form_performance) | 13 miesięcy | części „browser_runs”, „browser_jobs”, „form_performance” |
Liczniki formularzy (form_metrics), liczby dzienne wtyczki i powiadomienia o zmianach (plugin_stats, plugin_changes) | 13 miesięcy | części „form_metrics”, „plugin_stats” |
Zalogowane urządzenia (login_sessions) | 90 dni po ostatnim użyciu lub odwołaniu | część „sessions” |
| Przyjęte zaproszenia | 30 dni po przyjęciu | część „invites” |
Zapytania do wsparcia (support_requests) | 24 miesięcy | część „support” |
Zgłoszenia do raportów (report_feedback) | 24 miesięcy; suma kontrolna adresu IP 2 dni | części „report_feedback” i „report_feedback_ip” |
Wersje PDF raportów w pamięci podręcznej (var/pdf) | 7 dni | część „pdf_cache” |
Adres IP, kraj i identyfikator przeglądarki w opt-oucie (blocklist) | 12 miesięcy; wykluczenie pozostaje | część „optout_ip” |
Subskrybenci portalu (client_subscribers) | niepotwierdzeni 30 dni; wypisani 3 lata | część „subscribers” |
| Nigdy niepotwierdzone konta wraz z obszarem roboczym | 30 dni bez logowania, chyba że powiązany jest z nimi inny członek | część „pending_accounts” |
| Klucze API bez konta (dane historyczne) | natychmiast | część „api_keys” |
6.2 Poza oknem o godz. 03:00
| Dane | Termin i zdarzenie wyzwalające | Miejsce w kodzie |
|---|
| Kopie w skrzynce kontrolnej kontroli doręczenia | po przetworzeniu, co pięć minut | fe_zustellung_abholen() |
Przypisania kontroli doręczenia (delivery_log) | 180 dni, przy każdym pobraniu | fe_zustellung_abholen() |
Szyfrogram konta testowego w zleceniach (scan_jobs) | po przebiegu, najpóźniej po godzinie | serwer skanujący; fe_login_aufraeumen() |
Incydenty (alert_incidents) wraz z próbami doręczenia eskalacji | do rozwiązania; 180 dni po rozwiązaniu | fe_vorfaelle_aufraeumen() w cfg/vorfall_lib.php |
Wysłane powiadomienia zbiorcze (alert_queue) | 30 dni po wysyłce | cfg/kanal_lib.php |
Sygnały roju (swarm_signals) | 30 dni, codziennie od godz. 04:00 | cfg/swarm_lib.php |
Sprawdzenia potencjalnych klientów (prospect_checks) | 90 dni, codziennie od godz. 04:00 | srv/cron_status.php |
Kody powiązania Telegram (telegram_links) | 1 dzień, przy tworzeniu nowego kodu | cfg/kanal_lib.php |
Liczniki wywołań API (api_usage) | 1 dzień, okazjonalnie przy wywołaniu | cfg/agentur_lib.php |
Zakończone zakłócenia u dostawców (provider_incidents), bufor luk (vuln_cache) | odpowiednio 90 i 30 dni; brak danych osobowych | cfg/anbieter_lib.php, cfg/luecken_lib.php |
| Dane surowe badań | przy publikacji | fe_studie_veroeffentlichen() |
| Kopie zapasowe | 14 dni, po udanym utworzeniu nowej kopii | cfg/backup_lib.php |
| Dzienniki serwera WWW | 14 dni | systemowa rotacja dzienników |
6.3 Przy usunięciu przez Klienta
- Usunięcie domeny (
fe_domain_loeschen()): wyniki sprawdzeń z formularzami, ustaleniami i plikami obrazów, raporty, zlecenia, cele alertów, dziennik wysyłki, kolejka zbiorcza, incydenty, kody Telegram, doręczenia, puls, luki, protokoły weryfikacji, domena z portali klienta ze stałym wyborem; przez klucze obce – monitorowane formularze z przebiegami w przeglądarce, obserwacjami i szeregami czasowymi, konto testowe, liczniki formularzy; dane wtyczki dotyczące hosta, jeżeli nie prowadzi go żadna inna domena. Również usuwane są inwentarz skryptów i zmiany skryptów domeny; nie mają one własnego terminu (sekcje 6.4 i 10). Dane, które z okresu sprzed 27 września 2026 r. pozostały bez powiązanej domeny, usuwa nocny przebieg (części „orphan_scans”, „orphan_rows”).
- Usunięcie obszaru roboczego (
fe_arbeitsbereich_daten_loeschen()): dodatkowo marka wraz z logo, portale klienta wraz z subskrybentami, kody wdrożeniowe, sprawdzenia potencjalnych klientów; do tego zaproszenia i członkostwa.
- Usunięcie konta: natychmiastowe zakończenie trwającej płatnej subskrypcji w Stripe, bez zwrotu; przekazanie lub usunięcie własnych obszarów roboczych; usunięcie członkostw, znaczników zapamiętania, urządzeń, kluczy API z licznikami, otwartych kodów Telegram i wiersza konta.
- Usunięcie konta testowego (
fe_login_loeschen()): nadpisanie szyfrogramu, usunięcie wiersza, wyczyszczenie oczekujących zleceń.
6.4 Czego przebieg nie obejmuje
Ta lista jest ważniejsza. Wymienia dane, dla których nie ma automatycznego terminu lub które przetrwają usunięcie.
| Dane | Co obowiązuje | Ocena |
|---|
Dane konta łącznie z ostatnim adresem IP (users) | do usunięcia przez posiadacza konta; brak usuwania nieaktywnych kont | dane umowne; brakuje reguły dla trwale nieaktywnych kont bez subskrypcji |
| Dziennik aktywności, odsłony, dziennik błędów usuniętego konta | pozostają z identyfikatorem konta i adresem IP do końca swojego terminu | zamierzone (dowód działań także po wypowiedzeniu); identyfikator nie wskazuje już na żadne konto |
| Zapytania do wsparcia usuniętego konta | pozostają do 24 miesięcy ze starym identyfikatorem konta | zamierzone; identyfikator nie jest czyszczony |
| Dowody akceptacji usuniętego konta | do upływu 4 lat od akceptacji (liczonych od akceptacji, a nie od usunięcia konta) | zamierzone (sekcja B.12) |
Niezałatwione nieprawidłowości z adresem IP (abuse_flags) | dopóki ktoś ich nie załatwi | otwarta kwestia (sekcja 10) |
Rodzaje błędów z niezmienionym przykładowym komunikatem (error_kinds) | brak terminu | otwarta kwestia (sekcja 10) |
Inwentarz skryptów i zmiany skryptów (script_inventory, script_changes) | brak własnego terminu; pozostają, dopóki istnieje domena, i są usuwane razem z nią | otwarta kwestia (sekcja 10) |
| Subskrybenci odwołanych portali klienta | do usunięcia obszaru roboczego | otwarta kwestia (sekcja 10) |
| Odwołane klucze API i kody wdrożeniowe | do usunięcia konta lub obszaru roboczego | tylko skróty, prefiks i nazwa; niewielkie znaczenie |
Lista hostów badania (study_domains), nigdy nieopublikowane badania | brak terminu | otwarta kwestia (sekcja 10) |
| Wewnętrzne sprawdzenia bez domeny i bez raportu (wyniki sprawdzeń, formularze, ustalenia, zrzuty ekranu) | brak terminu; nie obejmuje ich żadna ścieżka usuwania | otwarta kwestia (sekcja 10) |
| Prowizje, realizacje kodów, zdarzenia Stripe | brak terminu | związek z księgowością; termin do ustalenia według prawa podatkowego |
Zbuforowany wiek domeny (domain_age_cache) | brak terminu | tylko nazwa domeny i data rejestracji |
| Wynik uwierzytelnienia wiadomości z formularza z domeną nadawcy | wraz z domeną; nadpisywany przy każdym wpływie | zob. A.1 |
| Wykluczenia w opt-oucie | na stałe | zamierzone; bez trwałości żadne wykluczenie nie działa |
| E-maile w skrzynce punktu zgłaszania luk i w skrzynce ogólnej | brak technicznego terminu | otwarta kwestia (sekcja 10) |
6.5 Poza bazą danych
- Zrzuty ekranu są przechowywane jako pliki poza katalogiem WWW i usuwane wraz z wynikiem sprawdzenia (wszystkie powyższe ścieżki usuwania usuwają także pliki).
- Pliki logo marki są usuwane przy zastąpieniu i wraz z obszarem roboczym.
- Na serwerze skanującym dla każdego zlecenia powstaje katalog tymczasowy z wynikiem i obrazami; jest on usuwany po każdym przebiegu, także po błędzie.
- Kopie zapasowe znajdują się na serwerze WWW (B.27).
- Dzienniki serwera WWW z pełnym adresem IP są przechowywane przez 14 dni (B.1).
7. Zautomatyzowane podejmowanie decyzji, profilowanie i ocena
formexposed ocenia strony internetowe, nie ludzi. Według naszej oceny usługa nie podejmuje decyzji, która wywoływałaby wobec osoby skutki prawne lub w podobny sposób istotnie na nią wpływała (art. 22 ust. 1 RODO). Istnieją jednak zautomatyzowane oceny i automatyczne blokady. Wymieniamy je, aby kwalifikację można było zweryfikować.
| Mechanizm | Co robi | Kogo dotyczy |
|---|
| Liczba punktów i werdykt sprawdzenia | Ważona suma brakujących warstw ochrony (CAPTCHA, pułapka, token, kontrola czasu, nieskuteczna CAPTCHA, znana otwarta konfiguracja), od 0 do 100; na tej podstawie „Niezabezpieczony”, „Częściowo zabezpieczony” lub „Zabezpieczony”. Werdykt dla strony zależy od najsłabszego formularza kontaktowego, który jako taki rozpoznały reguły (a nie model językowy); bez formularza kontaktowego nie ma werdyktu. Wagi można ustawiać w panelu administracyjnym. | Operatorzy stron; w przypadku jednoosobowych przedsiębiorców pośrednio osoba fizyczna. Werdykt nie wywołuje skutków prawnych; jest ustaleniem z dowodami i instrukcją. |
| Klasyfikacja typu formularza | Najpierw reguły, lokalny model językowy tylko wtedy, gdy reguły zwrócą „nieznany”. Rozstrzyga, czy dozwolone jest aktywne zgłoszenie testowe (tylko w przypadku formularza kontaktowego rozpoznanego z pewnością przez reguły). Formularze zaklasyfikowane przez model językowy nigdy nie są wysyłane i nie liczą się do liczby punktów ani werdyktu. | Klient i odbiorcy jego wiadomości z formularzy; efekt ochronny: w razie wątpliwości nic nie jest wysyłane. |
| Plan działań według priorytetów w płatnych raportach | Lokalny model językowy podsumowuje wybrane ustalenia z wynikiem negatywnym lub niejasnym i metadane skanu w formie krótkich, ponumerowanych kroków. Jego tekst jest oznaczony jako podsumowanie AI; miarodajne pozostają poszczególne ustalenia. Nie zmienia wyniku punktowego skanu, werdyktu ani konfiguracji strony internetowej. | Klient lub inny uprawniony czytelnik raportu, który decyduje, jakie kroki podjąć. |
| Pieczęć | Pokazuje „Zabezpieczony” tylko przy spełnieniu stałych warunków (B.18), w przeciwnym razie treść neutralną. | Klient; brak wpływu na odwiedzających. |
| Limity i blokady przy bezpłatnym sprawdzeniu, narzędziu do nagłówków i opt-oucie | Odrzucają żądania, gdy osiągnięto limity na adres, sesję, domenę lub system, gdy domena jest zbyt młoda lub jej wiek jest nieznany albo gdy znajduje się na liście blokad. | Osoby wysyłające żądania; skutek: bezpłatna usługa zostaje odmówiona na kilka godzin lub dni. Administrator może zwolnić adres; zapytania przez stronę kontaktową trafiają do człowieka. |
| Nieprawidłowości | Wzorce (wiele domen z jednego adresu, nagłe serie żądań, wiele odrzuceń, wiele opt-outów z jednego kraju, osiągnięty limit dzienny) są rejestrowane i zgłaszane. Same niczego nie blokują; blokady wynikają z limitów. | Osoby wysyłające żądania. |
| Blokada logowania | Po obecnie ośmiu nieudanych logowaniach z jednego adresu w ciągu 15 minut logowanie z tego adresu jest tymczasowo odrzucane. Ponadto liczone są wszystkie próby logowania, łącznie z udanymi, dla każdego konta i adresu IP (obecnie osiem), dla każdego konta ze wszystkich adresów łącznie (znacznie więcej, przeciw rozproszonemu zgadywaniu) i każdego adresu IP (obecnie 80) w ciągu 15 minut, a także kody drugiego składnika (dziesięć na konto w ciągu 15 minut); powyżej tych limitów próby są odrzucane. Nieudane próby z obcego adresu nie blokują więc już właścicielowi dostępu do konta. W ten sam sposób ograniczone są potwierdzenia hasła (pięć na konto w ciągu 15 minut), e-maile do resetowania hasła (trzy na adres w ciągu godziny, przy niezmienionej odpowiedzi), rejestracje (dziesięć na adres IP w ciągu godziny) i próby podania hasła portalu klienta (dziesięć na portal i adres IP, 50 na portal w ciągu 15 minut). | Osoby logujące się, rejestrujące lub otwierające portal klienta; skutek ograniczony w czasie, resetowanie hasła pozostaje możliwe. |
| Próg reCAPTCHA | Odrzuca zgłoszenia poniżej liczby punktów przyznanej przez Google; próg dla każdego miejsca użycia (dla sprawdzenia i opt-outu obecnie 0,7). Odrzucane są także odpowiedzi dla innej akcji oraz zgłoszenia, na które Google nie odpowie w ciągu trzech sekund. | Osoby wysyłające nasze formularze; skutek: ponowna próba lub droga przez stronę kontaktową. |
| Ochrona roju | Automatycznie umieszcza domenę z linku na liście po osiągnięciu progów minimalnych; warstwy ochronne połączonych stron umieszczają wiadomości z takimi linkami w kwarantannie. | Nadawcy wiadomości do stron Klientów. Skutek: wiadomość zostaje wstrzymana, a nie usunięta, i może zostać zwolniona przez operatora strony. Decyzję co do wiadomości podejmuje jego wtyczka na jego stronie, a nie my. |
| Wartości porównawcze | „Lepiej zabezpieczona niż X% sprawdzonych stron”, wyłącznie z sum od 20 hostów. | Operatorzy stron; brak skutków. |
Najbliżej art. 22 znajduje się warstwa ochronna wtyczki na stronach Klientów, która automatycznie wstrzymuje zgłoszenia. Jest to przetwarzanie dokonywane przez operatora strony na jego serwerze (A.10). Niczego nie usuwa, lecz umieszcza w kwarantannie, a operator może zwolnić każdą wiadomość. Profilowanie odwiedzających nie odbywa się ani tam, ani u nas; nie istnieje identyfikator odwiedzającego, który łączyłby jedną wiadomość z inną.
8. Środki techniczne i organizacyjne (art. 32) – ogólny opis
Ta sekcja stanowi ogólny opis w rozumieniu art. 30 ust. 1 lit. g i ust. 2 lit. d RODO. Szczegółowa wersja znajduje się na stronie Środki techniczne i organizacyjne. Każdy z poniższych środków ma potwierdzenie w kodzie lub w konfiguracji. Środki, które nie zostały jeszcze wdrożone, wymieniono w tej samej sekcji (8.1), aby opis był kompletny.
| Obszar | Stosowany środek |
|---|
| Szyfrowanie transmisji | HTTPS dla strony, aplikacji i interfejsów; HSTS; pliki cookie sesji i zapamiętania wyłącznie przez HTTPS, HttpOnly, SameSite=Lax. |
| Kontrola dostępu do systemu | Hasła wyłącznie jako skrót, nowe co najmniej dziesięć znaków i najwyżej 72 bajty; blokada logowania po powtarzających się nieudanych próbach i limity prób dla konta i adresu IP łącznie, dla konta i dla adresu IP, tak aby nieudane próby z obcego adresu nie blokowały właściciela; limity prób także dla potwierdzeń hasła, resetowania hasła (z taką samą odpowiedzią i czasem odpowiedzi), rejestracji i haseł portali; logowanie dwuskładnikowe (TOTP) z zaszyfrowanym sekretem, ochroną przed ponownym użyciem kodu i zahaszowanymi kodami odzyskiwania; nowy identyfikator sesji przy każdym logowaniu, identyfikatory niewydane przez serwer nie są przyjmowane; „Pozostań zalogowany” nie dla superadminów, każdy znacznik ważny tylko raz; zmiana adresu e-mail unieważnia niewykorzystany link do resetowania hasła; urządzenia można odwołać pojedynczo lub wszystkie; na liście urządzeń wyłącznie skrót identyfikatora sesji. |
| Kontrola dostępu do danych | Role w obszarze roboczym (właściciel, admin, czytelnik); uprawnienia są sprawdzane na obiekcie, nigdy na identyfikatorze z formularza; konto testowe, „Fix it for me” i sprawdzenia aktywne tylko dla właścicieli i adminów; „widok jako klient” ograniczony w czasie i zablokowany dla czynności zmieniających konto, jego zakończenie całkowicie wylogowuje, powrót do panelu administracyjnego tylko z hasłem i drugim składnikiem; zaproszenia ważne tylko tak długo, jak osoba zapraszająca jest właścicielem lub adminem; adresy webhooków i kanałów czatu widoczne dla czytelników tylko skrócone do nazwy hosta; nazwy hosta zweryfikowanej domeny nie można zmienić. |
| Bezpieczeństwo aplikacji | Token CSRF; przygotowane instrukcje bazy danych (prepared statements); własna ochrona formularzy (pułapka, podpisana kontrola czasu); reCAPTCHA w formularzach publicznych; ograniczanie częstotliwości dla wsparcia, sprawdzeń i interfejsów; w każdym obszarze roboczym tylko jedno wywołanie „Fix it for me” naraz, aby limit obowiązywał także przy jednoczesnych żądaniach; Content-Security-Policy z ochroną przed osadzaniem w ramkach, która pozwala uruchamiać tylko skrypty z zezwoleniem (nonce) danej odpowiedzi; adres IP z przekazanych nagłówków wyłącznie od własnego serwera proxy i tylko z dodanego przez niego wpisu; tokeny dostępu w dzienniku odsłon zamaskowane. |
| Sekrety | Klucze API, kody wdrożeniowe, sekrety połączenia wtyczki, kody jednorazowe i hasła do portali wyłącznie jako skrót; dane dostępowe kont testowych szyfrowane asymetrycznie, klucz prywatny wyłącznie na serwerze skanującym; webhooki podpisane; zdarzenia Stripe wyłącznie z ważnym podpisem. |
| Minimalizacja danych | Kontrola doręczenia nie zapisuje treści ani pełnych adresów nadawców; adresy odbiorców w formularzach tylko jako domena; identyfikatory kont w adresach skryptów są zastępowane; liczby z wtyczki wyłącznie z zamkniętych list; teksty błędów wysyłki poczty wyłącznie jako kategoria; sygnały Telegram bez zmiennych; obrazy ze sprawdzenia w przeglądarce z zamaskowanymi danymi wprowadzanymi; brak zrzutów ekranu za logowaniem. |
| Izolacja skanera | Każde sprawdzenie we własnym kontenerze: odebrane wszystkie uprawnienia (capabilities) systemu Linux, brak eskalacji uprawnień, system plików tylko do odczytu, limit pamięci i procesów, własna sieć; kontrola celu pod kątem sieci prywatnych i lokalnych przed przyjęciem i w skanerze, także po przekierowaniach; service workery zablokowane, połączenia WebSocket zamykane. Pobrania wykonywane przez serwer WWW (potwierdzenie uprawnień, narzędzie do nagłówków, wyszukiwanie plików, puls, RDAP, certyfikaty, webhooki i alarmy na czat) tylko na typowych portach WWW i tylko do dokładnie sprawdzonego adresu, webhooki i alarmy na czat tylko przez HTTPS. |
| Przechowywanie plików | Zrzuty ekranu poza katalogiem WWW, dostępne wyłącznie przez raport; raporty pod losowymi adresami z noindex; katalog kopii zapasowych do odczytu wyłącznie przez usługę. |
| Dostępność i odtwarzanie | Nocna kopia zapasowa ze sprawdzeniem zawartości, cotygodniowa próba odtworzenia, alert w razie niepowodzenia; sprawdzanie komponentów co pięć minut z sygnałem i wiadomością e-mail; zewnętrzny sygnał życia; wyłącznik awaryjny dla anonimowych sprawdzeń; wyrównywanie obciążenia przy zatorze. |
| Rozliczalność | Dziennik aktywności dla logowań, zmian, usunięć, dostępów wsparcia i zatwierdzeń; dziennik błędów z alertem. |
| Usuwanie | Terminy w jednym miejscu w kodzie, z tych samych ustawień co teksty (sekcja 6); łańcuchy usuwania dla domeny, obszaru roboczego i konta, z wyjątkami z sekcji 6.4. |
| Prawa osób, których dane dotyczą | Eksport wszystkich danych konta jako plik jednym kliknięciem, według listy dozwolonych pól, bez sekretów. |
| Organizacja | Panel administracyjny wyłącznie dla kont z uprawnieniem superadmina, zablokowany w trakcie „widoku jako klient”; system deweloperski i produkcyjny rozdzielone, system deweloperski za dodatkową blokadą dostępu; przenoszenie tekstów prawnych po zatwierdzeniu za pomocą narzędzia, które odrzuca projekty i symbole zastępcze. |
8.1 Środki jeszcze niewdrożone
- Brak szyfrowania bazy danych w stanie spoczynku (zmierzone 11 października 2026 r.). Wyjątek stanowią dane dostępowe kont testowych i sekret uwierzytelniania dwuskładnikowego, które są szyfrowane na poziomie pól.
- Połączenia wewnętrzne nie są w całości szyfrowane. Połączenia w obrębie naszej sieci wewnętrznej nie są w całości szyfrowane. Dane dostępowe kont testowych są tam przesyłane wyłącznie jako szyfrogram.
- Brak kopii zapasowej w drugiej lokalizacji. Kopie zapasowe znajdują się obecnie w tej samej lokalizacji co baza danych i nie są odrębnie szyfrowane; planowana jest zaszyfrowana kopia w drugiej lokalizacji. Do tego czasu chronią przed błędnym poleceniem usunięcia, a nie przed utratą lokalizacji.
- Utwardzanie administracji serwerami nie zostało zakończone. Zabezpieczenie dostępów administracyjnych do naszych serwerów nie odpowiada jeszcze poziomowi, który przewidujemy dla działania produkcyjnego; utwardzanie jest kontynuowane. Szczegółów nie publikujemy, ponieważ pomogłyby atakującemu; organowi nadzorczemu przedstawimy je na żądanie.
- Brak merytorycznego dziennika odczytów w panelu administracyjnym. Czynności zapisujące figurują w dzienniku aktywności; kto jedynie przeglądał które zapytanie do wsparcia lub który raport, wynika wyłącznie z dziennika odsłon (60 dni).
- Brak trwałego dziennika usunięć. To, co usunął nocny przebieg, nie jest rejestrowane (sekcja 6).
- Brak niezależnego drugiego punktu sprawdzającego. Sonda w drugiej lokalizacji nie jest skonfigurowana (A.6).
9. Inspektor ochrony danych – ocena na podstawie art. 37 RODO
Wynik: według naszej oceny nie istnieje obowiązek wyznaczenia. Ocena jest częścią weryfikacji prawnej i zostanie powtórzona, gdy tylko zmieni się którakolwiek z okoliczności wymienionych poniżej.
Art. 37 ust. 1 wymaga wyznaczenia w trzech przypadkach.
- Litera a (organ lub podmiot publiczny) nie dotyczy.
- Litera b (główna działalność wymagająca regularnego i systematycznego monitorowania osób na dużą skalę): naszą główną działalnością jest regularne, systematyczne sprawdzanie stron internetowych i formularzy, a nie obserwowanie osób. Nie tworzymy profili odwiedzających, nie stosujemy ponownego rozpoznawania i nie łączymy jednej wiadomości z inną. Kontrola doręczenia (A.1) przepuszcza prawdziwe wiadomości od odwiedzających przez naszą skrzynkę, ale do przypisania analizuje wyłącznie nagłówki i pierwsze 8 KB i nie zapisuje treści; obserwuje drogi doręczenia, a nie ludzi. Konta Klientów i dzienniki mają charakter pomocniczy wobec działalności gospodarczej.
- Litera c (przetwarzanie na dużą skalę szczególnych kategorii danych na podstawie art. 9 lub danych dotyczących wyroków skazujących i czynów zabronionych na podstawie art. 10 jako główna działalność): niespełniona. Szczególne kategorie mogą pojawiać się przypadkowo w kopiach wiadomości z formularzy (A.1), na stronach za logowaniem (A.5) lub we wklejonym kodzie (A.7); przypadkowe ich zebranie nie jest główną działalnością.
Art. 37 ust. 4 pozwala prawu krajowemu przewidzieć dalsze przypadki. Czy prawo polskie wymaga od nas wyznaczenia, zlecimy potwierdzić prawnikowi.
Zdarzenia wymagające ponownej oceny: włączenie ochrony roju z sieciami IP; funkcja, która rozpoznaje odwiedzających w wielu wiadomościach lub na wielu stronach; zapisywanie treści z kontroli doręczenia; Klient, którego formularze dotyczą przeważnie szczególnych kategorii danych (zdrowie, rekrutacja), z włączoną kontrolą doręczenia na dużą skalę; pierwszy pracownik z dostępem do danych Klientów. Dobrowolne wyznaczenie pozostaje możliwe; wówczas w pełni obowiązują art. 37–39.
Odrębnie: czy dla poszczególnych czynności przetwarzania konieczna jest ocena skutków dla ochrony danych na podstawie art. 35, wyjaśnia strona Ocena skutków dla ochrony danych. Przeprowadzona tam analiza progowa prowadzi do wniosku, że ocena skutków jest wymagana dla ochrony roju (B.21) i dla badań w zaplanowanej skali (B.7) i jest przez nas przeprowadzana, a także że jest wymagana dla kontroli doręczenia (A.1) w typowej konfiguracji – jako obowiązek Klienta, którego w tym wspieramy.
10. Otwarte kwestie i planowane środki
Poniższe kwestie są udokumentowane w kodzie, w schemacie lub w konfiguracji, a nie przypuszczalne. Opisują stan na dzień niniejszej wersji; kwalifikacja jest naszą własną oceną i nie przesądza o ocenie prawnej. Uporządkowano je według ich znaczenia dla osób, których dane dotyczą, a nie według tego, jak łatwo je usunąć. Planowane środki i ich kolejność określa Ocena skutków dla ochrony danych.
| Otwarta kwestia | Co jest udokumentowane | Znaczenie |
|---|
| Dostawca poczty e-mail bez udokumentowanej umowy | Dla Namecheap, Inc. (Private Email), Phoenix, Arizona, USA nie udokumentowano umowy, miejsc przetwarzania ani podstawy przekazania. Przez tego dostawcę przechodzą wiadomości dotyczące kont, alerty i skrzynka kontrolna z prawdziwymi wiadomościami od odwiedzających. | Właściwe są art. 28 ust. 2 i 4 oraz rozdział V RODO. Zawarcie i udokumentowanie umowy przewidziano przed startem. |
| Otwarte podstawy dla usług czatu i reCAPTCHA | Alerty do Telegramu (brak decyzji stwierdzającej odpowiedni stopień ochrony), Slacka, Discorda, Microsoft Teams i Google Chat; reCAPTCHA bez zapytania o zgodę. | Otwarte pytania weryfikacji prawnej; do tego czasu informacja i podstawa nie są ostateczne. |
| Skrzynka kontrolna może w razie zakłóceń przechowywać wiadomości | Usuwanie następuje po pomyślnym przetworzeniu; jeżeli pobranie się nie powiedzie, kopie pozostają do następnego udanego przebiegu. Ostrzeżenia przy dłuższym zatorze w skrzynce nie ma. | Kopie zawierają prawdziwe zapytania od odwiedzających. |
| Brak kopii zapasowej w drugiej lokalizacji, brak szyfrowania bazy danych w stanie spoczynku | Sekcja 8.1. Planowana jest zaszyfrowana kopia zapasowa w drugiej lokalizacji. | Pojedyncze zdarzenie w lokalizacji dotyka jednocześnie danych i kopii zapasowej; skradziony nośnik byłby czytelny. |
| Niezałatwione nieprawidłowości bez terminu | Nieprawidłowości z pełnym adresem IP jako kluczem są usuwane dopiero 90 dni po załatwieniu; te, które nigdy nie zostaną załatwione, pozostają. | Związek z zasadą ograniczenia przechowywania (art. 5 ust. 1 lit. e); usunięcie zależy od ręcznego załatwienia. Planowany jest stały termin (środki z Oceny skutków dla ochrony danych). |
| Rodzaje błędów z przykładowym komunikatem bez terminu | Przykładowy komunikat jest zapisywany w niezmienionej postaci do 2000 znaków; oczyszczony wzorzec usuwa adresy i liczby, przykład – nie. | Komunikaty o błędach mogą zawierać adresy e-mail, nazwy hostów lub adresy IP. |
| Inwentarz skryptów bez własnego terminu | Inwentarz skryptów i zmiany skryptów są usuwane razem z domeną (FE_DOMAIN_TABELLEN), także przy usuwaniu obszaru roboczego lub konta oraz w nocnym przebiegu dla danych osieroconych; nie mają własnego terminu. Zawierają adresy skryptów, adresy stron, a przy zatwierdzeniach osobę zatwierdzającą i uzasadnienie w postaci tekstu dowolnego. | Związek z zasadą ograniczenia przechowywania (art. 5 ust. 1 lit. e); dziennik zmian wraz z zatwierdzeniami rośnie, dopóki istnieje domena. |
| Subskrybenci odwołanych portali | Odwołany portal jest blokowany, a nie usuwany; jego subskrybenci pozostają do usunięcia obszaru roboczego. | Cel (wysyłka raportu) ustał wraz z odwołaniem. |
| Listy badań bez terminu | Po publikacji hosty i segmenty pozostają zachowane; nigdy nieopublikowane badania zachowują także swoje dane surowe. | Zapewnienie „dane surowe są usuwane” dotyczy wyłącznie opublikowanych badań. |
| Wewnętrzne sprawdzenia bez ścieżki usuwania | Sprawdzeń z poziomem zaufania „wewnętrzny”, które nie mają ani domeny, ani raportu (badania i sprawdzenia założone przez operatora z wiersza poleceń), nie obejmuje żadna ze ścieżek usuwania; wraz z nimi pozostają formularze, ustalenia i zrzuty ekranu cudzych stron. | Związek z zasadą ograniczenia przechowywania (art. 5 ust. 1 lit. e); dotyczy osób, które nic nie wiedzą o sprawdzeniu. Ocenione jako wysokie ryzyko w Ocenie skutków dla ochrony danych. |
| Potwierdzenie uprawnień do domeny nie jest odnawiane | Potwierdzenie uprawnień do domeny jest sprawdzane jednorazowo; w kodzie nie istnieje ścieżka, na której domena mogłaby je ponownie utracić. | Aktywne zgłoszenia testowe, wyszukiwanie plików i skan za logowaniem działają dalej po zmianie właściciela lub zleceniodawcy. |
| Skan za logowaniem: transport do strony Klienta | Jako adres logowania obok https dopuszczony jest także http, a błędy certyfikatu strony Klienta nie wstrzymują logowania. | Dane dostępowe konta testowego mogłyby zostać przechwycone w drodze do strony Klienta. |
| Usuwanie zależy od okna czasowego | Codzienny blok działa tylko wtedy, gdy przebieg statusowy rozpocznie się między 03:00 a 03:04. Jeżeli ten jeden przebieg nie dojdzie do skutku (baza danych nieosiągalna, ponowne uruchomienie serwera), usuwanie i kopia zapasowa z tego dnia przepadają; nie są nadrabiane. To, co zostało usunięte, nie jest trwale rejestrowane. | Terminy wydłużają się wtedy niepostrzeżenie o jeden dzień. Pominięte okno nie wywołuje alertu; zgłaszana jest tylko kopia zapasowa, która została uruchomiona i się nie powiodła. Lista konfiguracyjna w panelu administracyjnym pokazuje datę ostatniej udanej kopii zapasowej. |
| Niektóre usunięcia zależą od monitorowania | Opróżnianie skrzynki kontrolnej kontroli doręczenia, usuwanie incydentów, wysłanych powiadomień zbiorczych, sygnałów roju i sprawdzeń potencjalnych klientów oraz opróżnianie pozostałych w zleceniach kopii kont testowych odbywają się w części planującej przebiegu statusowego, która działa tylko wtedy, gdy monitorowanie jest włączone w panelu administracyjnym; przypisania kontroli doręczenia są usuwane tylko wtedy, gdy skonfigurowana jest skrzynka kontrolna. | Jeżeli monitorowanie zostanie centralnie wyłączone lub skrzynka usunięta, terminy te zatrzymują się niepostrzeżenie. |
| Punkt zgłaszania luk i skrzynki pocztowe bez terminu | Zgłoszenia luk bezpieczeństwa i inne przychodzące e-maile są przechowywane poza aplikacją; termin nie został określony. | Zgłoszenia mogą zawierać dane dowodowe osób trzecich. |
| Wartości pól ukrytych są odczytywane w trakcie sprawdzenia | Skaner odczytuje wartość ukrytych pól formularza do 24 znaków i atrybuty danych do 60 znaków, aby rozpoznać znaczniki czasu i tokeny. Do mapy pól i ustaleń trafiają tylko nazwa pola, typ, etykieta i wynik rozpoznania, nie wartość. | Brak luki w zakresie zapisu; wartość znajduje się tylko w trakcie sprawdzenia w pamięci roboczej kontenera skanującego. Wstępnie wypełniona wartość (np. numer klienta) jest przy tym odczytywana, ale nie zapisywana. |
| Wyprowadzona domena nadawcy w wyniku uwierzytelnienia | A.1. | W przypadku prywatnych domen odwiedzających jest to dana osobowa pochodząca z prawdziwej wiadomości. |
| Utwardzanie administracji serwerami niezakończone; połączenia wewnętrzne nie w całości szyfrowane | Sekcja 8.1. Utwardzanie jest kontynuowane; szczegółów nie podajemy publicznie. | Incydent bezpieczeństwa na poziomie serwera dotknąłby jednocześnie aplikacji, bazy danych i kopii zapasowych. |
| Pomiar w systemie deweloperskim | Schemat, kod i ustawienia zmierzono w systemie deweloperskim. | Kod i schemat odpowiadają systemowi produkcyjnemu; ustawienia mogą się różnić i należy je tam ponownie sprawdzić przed startem. |
11. Aktualizacja tego rejestru
Art. 30 wymaga prowadzenia rejestru w formie pisemnej i udostępniania go organowi nadzorczemu na żądanie. Potrzebna jest do tego osoba, która za niego odpowiada, oraz odstęp czasu, w którym jest on sprawdzany z systemem, a nie z poprzednią wersją.
- Odpowiedzialność: Lukas Wójcik, właściciel. Przegląd odbywa się raz w roku i przy każdej zmianie czynności przetwarzania.
- Zdarzenia wymuszające aktualizację: nowy lub zmieniony podmiot przetwarzający dalej, w szczególności ustalenie dostawcy poczty e-mail; nowa tabela lub nowe pole z danymi osobowymi; zmiana terminów lub łańcuchów usuwania w
cfg/fristen_lib.php lub srv/cron_status.php; nowy kanał alertów lub nowe zapytanie do podmiotu trzeciego; włączenie funkcji fabrycznie wyłączonej (ochrona roju z sieciami IP, sonda, własne domeny, program partnerski, płatność na fakturę, Spamhaus lub Google Web Risk); przeniesienie na inne serwery.
- Sposób postępowania: każde twierdzenie w tym rejestrze pochodzi z kodu, schematu lub pomiaru. Przegląd, który czyta jedynie tekst, niczego nie sprawdził: schemat i łańcuchy usuwania są mierzone na nowo, symbole zastępcze pozostają symbolami zastępczymi, otwarte punkty są zamykane lub aktualizowane z uzasadnieniem.
- Relacja do innych dokumentów: ten rejestr nie zastępuje ani Polityki prywatności, ani Umowy powierzenia przetwarzania danych, Środków technicznych i organizacyjnych czy wykazu Podmiotów przetwarzających dalej. Tam, gdzie one i ten rejestr się różnią, rozbieżność jest ustaleniem wymagającym wyjaśnienia.
- Zmiany tego dokumentu są publikowane na stronie Zmiany dokumentów umownych.
English 
Deutsch 
Polski 
Български 
Čeština 
Dansk 
Ελληνικά 
Español 
Eesti 
Suomi 
Français 
Gaeilge 
Hrvatski 
Magyar 
Italiano 
Lietuvių 
Latviešu 
Malti 
Nederlands 
Português 
Română 
Slovenčina 
Slovenščina 
Svenska 
العربية 
हिन्दी 
Bahasa Indonesia 
日本語 
한국어 
Русский 
简体中文 
Norsk (bokmål) 
Português (Brasil) 
Türkçe 
Українська 
Español (México) 
Tiếng Việt 
ไทย 
Íslenska 
עברית 
Bahasa Melayu 
Srpski (latinica)