Ocena skutków dla ochrony danych (art. 35 RODO)

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.1 · Stan na: 23 października 2026 r.

1. O co chodzi i czym jest ta strona

Ta strona jest oceną skutków dla ochrony danych (DPIA) formexposed na podstawie art. 35 RODO. Najpierw odpowiada na pytanie wstępne, czy ocena skutków jest w ogóle wymagana – i to dla każdego przetwarzania z osobna, a nie dla usługi jako całości. Tam, gdzie odpowiedź brzmi „tak”, przeprowadza ocenę zgodnie z art. 35 ust. 7 lit. a–d: systematyczny opis, niezbędność i proporcjonalność, ryzyko dla osób, których dane dotyczą, oraz środki przeciwdziałające temu ryzyku. Dalej następują ryzyko szczątkowe, kwestia uprzednich konsultacji na podstawie art. 36 i zasady przeglądu.

Art. 35 nie wymaga publikowania oceny skutków. Robimy to z dwóch powodów. Po pierwsze, Klienci, którzy korzystają z kontroli doręczenia lub skanu za logowaniem, potrzebują do własnej oceny faktów, które znamy tylko my; jako podmiot przetwarzający i tak jesteśmy im te fakty winni (art. 28 ust. 3 lit. f RODO). Po drugie, nasz crawler sprawdza strony internetowe, których operatorzy nas nie znają. Powinni móc przeczytać, jakie ryzyko widzimy dla nich i dla osób na ich stronach i co z tym robimy.

Charakter prawny. Niniejsza ocena skutków jest dokumentacją administratora zgodnie z art. 35 RODO, którą publikujemy dobrowolnie. Nie stanowi części umowy i nie stanowi zapewnienia, gwarancji ani uzgodnienia właściwości wobec Klientów lub osób trzecich. Jakie świadczenia i środki ochrony jesteśmy winni Klientom, określają Regulamin, Umowa powierzenia przetwarzania danych i jej załączniki; w zakresie tych obowiązków mają one pierwszeństwo przed tą stroną. Strona opisuje stan na dzień niniejszej wersji. Klasyfikacje ryzyk i oceny 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. Dla Klientów strona stanowi podstawę ich własnej oceny, a nie poradę prawną.

Jest to pierwsza wersja analizy progowej. Sprawdza ona, przetwarzanie po przetwarzaniu, czy ocena skutków jest wymagana, i zapisuje wynik w pkt 3.5.

Do każdego twierdzenia o faktach stosujemy tę samą zasadę co w pozostałych naszych dokumentach prawnych: zmierzone, a nie zamierzone. To, co jest potwierdzone w kodzie lub w bazie danych, podajemy tu wraz z miejscem w kodzie. To, czego nie udało się potwierdzić, oznaczamy jako „niesprawdzone”. To, co jest tylko planowane, nazywamy „planowanym”. Otwarte kwestie wskazujemy otwarcie, wraz z planowanym środkiem; ocena skutków, która wylicza wyłącznie mocne strony, nie pomaga osobom, których dotyczy.

Pojęcia: Operator to ten, kto prowadzi sprawdzaną stronę internetową. Klient ma konto w formexposed. Odwiedzający to ten, kto korzysta ze strony internetowej Klienta, np. z jej formularza kontaktowego. Przez miejsce w kodzie rozumiemy plik, funkcję lub ustawienie kodu źródłowego, według stanu systemu deweloperskiego z 11 października 2026 r.

Jedną granicę jawności wyznaczamy świadomie: otwarte kwestie zabezpieczenia naszych własnych serwerów opisujemy tylko ogólnie (R13). Wskazujemy ryzyko i jego poziom, ale nie drogę do konkretnej podatności; szczegóły przedstawiamy organowi nadzorczemu na jego żądanie.

2. Role: kogo dotyczy obowiązek i w jakim zakresie

Art. 35 zobowiązuje administratora. formexposed jest administratorem w odniesieniu do niektórych przetwarzań, podmiotem przetwarzającym swoich Klientów w odniesieniu do innych, a w odniesieniu do danych, które nasza wtyczka WordPress i nasze rozszerzenie TYPO3 zapisują na stronie internetowej Klienta – ani jednym, ani drugim. Odpowiedź na niemal każde pytanie w tym dokumencie zależy od tego, o którą rolę chodzi. Przypisanie ról odpowiada Polityce prywatności i Umowie powierzenia przetwarzania danych.

Przetwarzanie	Rola formexposed	Kogo dotyczy obowiązek z art. 35
Sprawdzanie cudzych stron internetowych bez zlecenia ich operatora: bezpłatne sprawdzenie, sprawdzenie potencjalnego klienta dla agencji, badanie	Administrator	formexposed
Sprawdzanie domen na koncie Klienta: monitorowanie, aktywne zgłoszenia testowe, ścieżki przeglądarki, publicznie dostępne pliki, puls formularza	Administrator danych konta i danych sprawdzeń Klienta; podmiot przetwarzający w odniesieniu do danych osobowych osób trzecich widocznych na stronie internetowej Klienta, do której potwierdził uprawnienia; dopóki uprawnienia do domeny nie są potwierdzone – administrator, jak przy bezpłatnym sprawdzeniu	formexposed w zakresie własnej części; Klient w odniesieniu do danych osób trzecich na swojej stronie internetowej
Skan za logowaniem z użyciem konta testowego	Podmiot przetwarzający: dane dostępowe i treści za logowaniem należą do strony internetowej Klienta	Klient; formexposed udziela wsparcia
Kontrola doręczenia z kopią kontrolną	Podmiot przetwarzający	Klient; formexposed udziela wsparcia
Ochrona roju: wspólna lista domen z linków w odpartym spamie	Administrator: łączymy zgłoszenia wielu stron internetowych, tworzymy listę i ją rozpowszechniamy	formexposed
Konta Klientów, logowanie, dzienniki, wsparcie, wysyłka e-maili, płatności, dowody	Administrator	formexposed
Portal klienta i raport miesięczny dla subskrybentów agencji	Podmiot przetwarzający	Agencja
Dane, które wtyczka i rozszerzenie zapisują na stronie internetowej Klienta (kwarantanna, siatka ratunkowa, uratowane zapytania)	Ani jedno, ani drugie: dane nie opuszczają strony internetowej	Operator strony internetowej

Wynika z tego rozróżnienie, które wyraźnie zapisujemy, ponieważ często popełnia się tu błędy w obu kierunkach. Tam, gdzie formexposed jest administratorem, sami przeprowadzamy ocenę i ponosimy odpowiedzialność za jej wynik. Tam, gdzie jesteśmy podmiotem przetwarzającym, nie możemy przeprowadzić oceny za Klienta, rozstrzygnąć za niego, czy jest ona wymagana, ani skonsultować się w jego imieniu z organem nadzorczym na podstawie art. 36. Możemy i musimy natomiast dostarczyć mu wszystko, czego do tego potrzebuje: opis zgodny z lit. a, zmierzone fakty dotyczące ryzyka zgodnie z lit. c i rzetelną listę stanu środków zgodnie z lit. d. W odniesieniu do kontroli doręczenia i skanu za logowaniem ta strona jest właśnie tym.

Klient, który przejmie bez zmian fragmenty dotyczące kontroli doręczenia jako własną ocenę skutków, żadnej oceny nie przeprowadził. Czy kopia kontrolna jest uzasadniona dla jego formularzy, czy należy się w nich spodziewać szczególnych kategorii danych osobowych i jak poinformuje swoich odwiedzających – może rozstrzygnąć tylko on. Pkt 11 podsumowuje, co należy w tym celu wyjaśnić.

3. Ocena progowa: czy ocena skutków jest wymagana?

3.1 Art. 35 ust. 1 i ust. 3

Art. 35 ust. 1 wymaga oceny skutków, jeżeli dany rodzaj przetwarzania – w szczególności z użyciem nowych technologii – ze względu na swój charakter, zakres, kontekst i cele z dużym prawdopodobieństwem może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych. Art. 35 ust. 3 wymienia trzy przypadki, w których tak jest w szczególności. Żaden z nich nie pasuje do formexposed, a to należy uzasadnić, a nie tylko stwierdzić:

Lit. a – systematyczna, kompleksowa ocena czynników osobowych odnoszących się do osób fizycznych, która opiera się na zautomatyzowanym przetwarzaniu i jest podstawą decyzji wywołujących skutki prawne lub w podobny sposób istotnie wpływających na osobę fizyczną. Oceniamy formularze i strony internetowe, a nie czynniki osobowe ludzi. Usługa nie podejmuje wobec żadnej osoby decyzji wywołującej skutki prawne. Najbliżej tego jest ochrona roju: wiadomości z linkiem do domeny z listy trafiają na podłączonych stronach internetowych do kwarantanny. To zautomatyzowany skutek dla wiadomości, a nie kompleksowa ocena osoby; omawiamy to w ramach kryterium „ewaluacja lub ocena punktowa” w pkt 3.3.
Lit. b – przetwarzanie na dużą skalę szczególnych kategorii danych, o których mowa w art. 9, lub danych dotyczących wyroków skazujących i naruszeń prawa, o których mowa w art. 10. Niezamierzone i niezbudowane. Jedną drogą takie dane mogą jednak do nas trafić: w kopii kontrolnej prawdziwych wiadomości odwiedzających przy kontroli doręczenia. Zależy to od konkretnego przypadku i nie jest przetwarzaniem na dużą skalę w rozumieniu tego przepisu; uwzględniamy to jednak w ocenie ryzyka (R1).
Lit. c – systematyczne monitorowanie na dużą skalę miejsc dostępnych publicznie. Chodzi o fizyczną obserwację miejsc, a nie o pobieranie publicznych stron internetowych. Powoływanie się na ten przepis w odniesieniu do crawlera stron internetowych byłoby nietrafne.

Właściwą drogą jest więc sam art. 35 ust. 1, stosowany za pomocą dziewięciu kryteriów z Wytycznych Grupy Roboczej Art. 29 dotyczących oceny skutków dla ochrony danych (WP248 rev.01, zatwierdzonych przez Europejską Radę Ochrony Danych), oraz wykaz polskiego organu nadzorczego na podstawie art. 35 ust. 4 (pkt 3.4).

3.2 Dziewięć kryteriów z wytycznych WP248

Wytyczne wymieniają dziewięć cech wskazujących na prawdopodobieństwo wysokiego ryzyka. Jako praktyczna reguła obowiązuje: jeżeli przetwarzanie spełnia dwa z nich, w większości przypadków należy przeprowadzić ocenę skutków. Administrator może w konkretnym przypadku dojść do innego wniosku, musi go jednak wówczas uzasadnić i udokumentować. I odwrotnie: już jedno kryterium może wystarczyć. Na tej stronie posługujemy się następującymi skrótowymi oznaczeniami:

K1 – Ewaluacja lub ocena punktowa, w tym profilowanie i przewidywanie, np. dotyczące efektów pracy, sytuacji ekonomicznej, wiarygodności lub zachowania.
K2 – Zautomatyzowane podejmowanie decyzji wywołujących skutki prawne lub w podobny sposób istotnie wpływających na osobę.
K3 – Systematyczne monitorowanie, czyli obserwowanie, monitorowanie lub kontrolowanie osób, których dane dotyczą, także za pośrednictwem sieci. Wytyczne wprost uzasadniają to kryterium tym, że osoby, których dane dotyczą, często nie wiedzą, kto zbiera ich dane i w jakim celu.
K4 – Dane szczególnie chronione lub dane o bardzo osobistym charakterze: szczególne kategorie danych z art. 9 i 10, ale także dane, których ujawnienie istotnie wpływa na codzienne życie, w tym komunikacja elektroniczna, której poufność należy chronić.
K5 – Dane przetwarzane na dużą skalę, mierzoną liczbą osób, których dane dotyczą, ilością i zakresem danych, czasem trwania i zasięgiem geograficznym.
K6 – Dopasowywanie lub łączenie zbiorów danych pochodzących z różnych operacji przetwarzania lub od różnych administratorów, w sposób, którego osoby, których dane dotyczą, nie oczekują.
K7 – Dane dotyczące osób wymagających szczególnej opieki, np. pracowników, dzieci, pacjentów lub innych osób w sytuacji nierównowagi sił.
K8 – Innowacyjne wykorzystanie lub zastosowanie nowych rozwiązań technologicznych lub organizacyjnych; w praktyce organów nadzorczych zalicza się tu regularnie wykorzystanie sztucznej inteligencji.
K9 – Uniemożliwienie wykonywania prawa lub korzystania z usługi albo umowy.

Każde kryterium oceniamy jako „spełnione”, „przypadek graniczny” albo „niespełnione” i uzasadniamy tę kwalifikację na podstawie kodu. Przypadek graniczny nie liczy się w sumie jako spełniony, ale jest wymieniany w wyniku; tam, gdzie kilka przypadków granicznych wskazuje w tym samym kierunku, uwzględniamy dane przetwarzanie w ocenie.

3.3 Ocena poszczególnych przetwarzań

V1 – Bezpłatne sprawdzenie bez konta (sprawdzanie dowolnych cudzych stron internetowych na żądanie)

Każdy może wpisać domenę na stronie głównej. Crawler pobiera wówczas najwyżej osiem publicznych podstron tej strony internetowej, odczytuje formularze, wykonuje zrzuty ekranu i tworzy raport, który widzi każdy, kto zna jego losowy link. Operator strony internetowej nic o tym nie wie, chyba że zauważy identyfikator crawlera w swoich dziennikach.

K1 – przypadek graniczny. Raport ocenia zabezpieczenie formularza za pomocą poziomu („Niezabezpieczony”, „Częściowo zabezpieczony”, „Zabezpieczony”) i liczby punktów. W przypadku spółki z o.o. nie dotyczy to osoby fizycznej. W przypadku jednoosobowych przedsiębiorców i wolnych zawodów domenę można przypisać człowiekowi, a poziom mówi wtedy coś o staranności w jego działalności zawodowej. Oceniane jest jednak urządzenie techniczne, a nie zachowanie lub cechy osoby. Traktujemy to jako przypadek graniczny.
K2 – niespełnione. Wobec operatora nic nie jest rozstrzygane. Wobec osoby zlecającej sprawdzenie działają limity na adres IP i sesję (cfg/check_lib.php); odrzucone sprawdzenie nie wywołuje istotnych skutków.
K3 – niespełnione. Jest to pojedyncze pobranie na żądanie, najwyżej raz na domenę w tygodniu (cfg/check_lib.php, ustawienie fc_domain_days = 7). Osoby nie są obserwowane. Występuje jednak okoliczność, którą wytyczne podają jako uzasadnienie K3 – osoby, których dane dotyczą, nic nie wiedzą o przetwarzaniu. Uwzględniamy ją w ocenie ryzyka (R5).
K4 – niespełnione. Zapisywana jest budowa formularza i ustalenia, a nie wpisane wartości (scanner/src/crawl.js przy widocznych polach zapisuje tylko długość wartości). Początki wstępnie wypełnionych pól ukrytych (do 24 znaków) i atrybuty data (do 60 znaków) skaner odczytuje tylko w trakcie sprawdzenia, aby rozpoznać tokeny i znaczniki czasu; nie są one zapisywane. Zrzuty ekranu mogą przypadkowo pokazywać osoby i nazwiska; strona internetowa gabinetu lekarskiego pokazuje na obrazie specjalizację. Są to publiczne informacje zawodowe, a nie dane o zdrowiu określonej osoby.
K5 – przypadek graniczny. Dzienny limit wynosi 200 przyjętych sprawdzeń (fc_daily_cap), czyli rachunkowo do ok. 73 000 stron internetowych rocznie. Na każdą stronę przypada niewiele danych osobowych, a okres przechowywania jest krótki (30 dni). Według pomiaru w systemie deweloperskim w zasobie znajdują się 2 anonimowe sprawdzenia. Obecnie kryterium niespełnione; przy przewidzianej skali – przypadek graniczny.
K6 – niespełnione. Oprócz pobrania stron usługa sprawdza wiek domeny przez usługę RDAP rdap.org (przekazywana jest tylko nazwa domeny; zapisywana tylko data rejestracji, buforowana) i rozwiązuje DNS. Są to dane techniczne dotyczące domeny, a nie łączenie zbiorów danych o osobach.
K7 – niespełnione.
K8 – spełnione w słabej postaci. Strony sprawdza zautomatyzowana przeglądarka, a model językowy na naszym własnym serwerze klasyfikuje formularze, których reguły nie rozpoznają (scanner/src/classify.js). Model widzi tytuł strony, adres, etykiety pól i do 400 znaków tekstu formularza. Nigdy nie może uczynić formularza „możliwym do wysłania”.
K9 – niespełnione.

Wynik cząstkowy V1: jedno kryterium w słabej postaci (K8), dwa przypadki graniczne (K1, K5). Według praktycznej reguły brak obowiązku. Ponieważ oba przypadki graniczne wskazują w tym samym kierunku, a osoby, których dane dotyczą, nic nie wiedzą o przetwarzaniu, uwzględniamy V1 w ocenie.

V2 – Sprawdzenie potencjalnego klienta dla agencji

Agencja w planie Business z ustawioną własną marką może zlecić pasywne sprawdzenie strony internetowej potencjalnego klienta. Otrzymuje krótkie podsumowanie pod swoją marką i szczegółowy raport, a link przekazuje sama (cfg/akquise_lib.php). Nie piszemy do nikogo.

K1 – przypadek graniczny, silniejszy niż przy V1. Krótkie podsumowanie jest wprost pomyślane jako „otwieracz do pierwszej rozmowy”. Ocena strony internetowej staje się więc podstawą do nawiązania kontaktu handlowego z człowiekiem.
K5 – niespełnione. Najwyżej 30 sprawdzeń na agencję miesięcznie (prospect_monthly), usuwane po 90 dniach.
K8 – spełnione w słabej postaci (ta sama technika co przy V1).
Pozostałe kryteria – niespełnione. Wynik jest prezentowany pod marką agencji, ale nie jest łączony z innymi danymi o operatorze.

Wynik cząstkowy V2: według praktycznej reguły brak obowiązku; uwzględnione z tych samych powodów co V1 oraz dlatego, że cel – pozyskiwanie klientów – niesie własne ryzyko (R6).

V3 – Badanie „Indeks bezpieczeństwa formularzy”

Na potrzeby badania pasywnie sprawdzana jest lista stron internetowych, z ograniczeniem do najwyżej pięciu otwartych zleceń na jeden przebieg procesu statusowego, który działa co pięć minut (cfg/studie_lib.php). Publikowane są tylko sumy, a segmenty dopiero od 20 stron internetowych z formularzem (study_min_segment, cfg/studie_lib.php). Dane surowe są usuwane wraz z publikacją (cfg/studie_lib.php).

K5 – przypadek graniczny, przy dużych listach spełnione. Wielkość listy nie jest w kodzie ograniczona; ograniczenie tempa pozwala rachunkowo na ponad tysiąc sprawdzeń dziennie. Badanie rynku jednego kraju obejmuje tysiące stron internetowych, w tym wiele stron jednoosobowych przedsiębiorców. Od takiej skali uznajemy kryterium za spełnione.
K8 – spełnione w słabej postaci.
K1 – niespełnione. Pojedyncza strona internetowa jest wprawdzie klasyfikowana, ale publikowana jest tylko suma; klasyfikacja nie służy wypowiedzi o pojedynczym operatorze.
Pozostałe kryteria – niespełnione.

Wynik cząstkowy V3: przy badaniach w przewidzianej skali dwa kryteria (K5, K8). Badanie osiąga więc próg; formexposed przeprowadza ocenę jako administrator. Według pomiaru w systemie deweloperskim dotychczas nie utworzono żadnego badania.

V4 – Sprawdzanie domen na koncie Klienta

Domeny na swoim koncie Klient zleca do regularnego sprawdzania. Jeżeli potwierdził, że jest uprawniony do dysponowania domeną, dochodzą aktywne zgłoszenia testowe (najwyżej pięć na sprawdzenie), wyszukiwanie publicznie dostępnych plików i skonfigurowane ścieżki przeglądarki.

K3 – niespełnione. Sprawdzanie jest planowe i powtarzalne, ale dotyczy własnej strony internetowej Klienta i odbywa się na jego życzenie, a nie w celu obserwowania osób.
K4 – przypadek graniczny, nie. Wyszukiwanie publicznie dostępnych plików odczytuje ze ścieżek takich jak /backup.sql czy dziennik debugowania najwyżej pierwsze 8 KB, aby po treści rozpoznać, czy plik rzeczywiście jest publicznie dostępny (cfg/dateien_lib.php). Taki fragment może zawierać dane wpisane w formularze przez odwiedzających. Jest sprawdzany wyłącznie w pamięci operacyjnej i nigdy nie jest zapisywany; zapisywane są ścieżka, rodzaj i waga.
K8 – spełnione w słabej postaci.
Pozostałe kryteria – niespełnione.

Dodany etap planu działań. Kwalifikujące się płatne raporty mogą zawierać lokalnie wygenerowany tekst doradczy oparty na wybranych ustaleniach i metadanych skanu. Jest on zapisywany wraz ze sprawdzeniem i wyświetlany z komunikatem o AI; miarodajne pozostają poszczególne ustalenia. Nie zmienia automatycznie stron internetowych ani nie podejmuje decyzji dotyczących osób, które wywołują skutki prawne lub w podobny sposób istotnie na nie wpływają. Samo wykorzystanie modelu językowego nie rozstrzyga o tym, czy wymagana jest odrębna ocena skutków dla ochrony danych. Jego dane wejściowe, odbiorców, skalę i ryzyka szczątkowe należy ocenić wraz ze sprawdzeniem będącym jego podstawą, w tym możliwe powtarzanie danych osobowych z adresów URL lub notatek oraz błędne zalecenia w raporcie, który można udostępnić linkiem. Poniższe punkty 7–9 uwzględniają ten etap; niniejsze uzupełnienie faktów nie stanowi stwierdzenia zakończenia pomiarów produkcyjnych, zatwierdzenia przez właściciela ani ustalenia nowego poziomu ryzyka szczątkowego.

Wynik cząstkowy V4: Sprawdzenie techniczne będące podstawą nie osiąga progu na podstawie opisanych powyżej faktów. Dodany lokalny etap doradczy sam w sobie nie przesądza o odrębnym obowiązku, ale wcześniejszy wynik oceny progowej nie zastępuje uwzględnienia jego rzeczywistych danych wejściowych, skali, odbiorców i skutków. Uwzględnione, ponieważ aktywne zgłoszenia testowe i sprawdzanie plików zależą od potwierdzenia uprawnień, które nigdy nie jest odnawiane (R7).

V5 – Skan za logowaniem

Dla domeny z potwierdzonymi uprawnieniami Klient może zapisać konto testowe swojej strony internetowej. Skaner loguje się za jego pomocą i odczytuje formularze na maksymalnie pięciu wskazanych podstronach strefy klienta (cfg/login_lib.php, scanner/src/login.js).

K4 – przypadek graniczny. Dane dostępowe nie są danymi o bardzo osobistym charakterze w rozumieniu wytycznych, ale ich nadużycie otwiera strefę klienta. Za logowaniem mogą, zależnie od strony internetowej, znajdować się treści poufne, np. w portalu członkowskim lub portalu pacjenta. Zależy to od Klienta, a nie od nas.
K8 – niespełnione. Zautomatyzowane logowania są w usługach monitorujących powszechne.
Pozostałe kryteria – niespełnione.

Wynik cząstkowy V5: według praktycznej reguły brak obowiązku. W przypadku Klientów, których strefa klienta pokazuje treści poufne, może się to zmienić; decyzja należy wtedy do nich. Uwzględnione ze względu na ryzyko dla bezpieczeństwa (R8).

V6 – Kontrola doręczenia z kopią kontrolną

Klient wpisuje adres kontrolny formexposed jako ukrytą kopię (UDW) w ustawieniach poczty swojego formularza. Dzięki temu każdy e-mail z formularza trafia również do naszej skrzynki kontrolnej – zarówno nasza wiadomość testowa, jak i każda prawdziwa wiadomość odwiedzającego. Automatyczne pobieranie odczytuje nagłówki i pierwsze 8 KB, przypisuje wiadomość, ocenia SPF, DKIM i DMARC i ją usuwa (cfg/zustellung_lib.php).

K4 – spełnione. To, co odwiedzający piszą w formularzu kontaktowym, jest komunikacją elektroniczną z przedsiębiorstwem o dowolnej treści. Na stronie internetowej gabinetu lekarskiego, kancelarii, poradni lub szkoły należy spodziewać się danych z art. 9 lub danych dotyczących dzieci. Wytyczne wprost wymieniają poufną komunikację elektroniczną w ramach tego kryterium.
K3 – przypadek graniczny, raczej spełnione. Każda wiadomość jest planowo i w sposób ciągły kopiowana i automatycznie analizowana, bez wiedzy nadawcy. Celem jest kontrola drogi poczty, a nie obserwowanie osób. Okoliczność, którą wytyczne uzasadniają to kryterium – osoby, których dane dotyczą, nie wiedzą, kto otrzymuje ich dane – występuje jednak w pełni, dopóki Klient nie poinformuje swoich odwiedzających.
K7 – zależnie od Klienta. Pacjenci, klienci kancelarii, kandydaci do pracy, rodzice i uczniowie często pozostają w relacji zależności wobec odbiorcy swojej wiadomości.
K5 – przypadek graniczny, nie. Dla pojedynczego Klienta nie jest to duża skala. W formexposed kopie wielu Klientów spływają do jednej skrzynki; zwiększa to wagę ewentualnego naruszenia, a nie liczbę na jednego administratora.
Pozostałe kryteria – niespełnione. Przypisanie do domeny i testu nie jest dopasowywaniem zbiorów danych o osobach; technika nie jest nowa.

Wynik cząstkowy V6: K4 spełnione, K3 jako przypadek graniczny raczej spełnione, K7 u wielu typowych Klientów spełnione. W typowej konstelacji spełnione są zatem co najmniej dwa kryteria. Ocena skutków jest wymagana – jako obowiązek Klienta, który jest administratorem. Pkt 6–11 dostarczają mu potrzebnych do tego faktów.

V7 – Ochrona roju

Połączone strony WordPress raz dziennie zgłaszają domeny z linków w wiadomościach, które zatrzymała ich warstwa ochrony. Domena, która pojawi się na co najmniej trzech różnych stronach internetowych z co najmniej pięcioma trafieniami w ciągu siedmiu dni, trafia na wspólną listę; lista wraca do wszystkich połączonych stron internetowych, które wiadomości z linkami do tej domeny umieszczają następnie w kwarantannie (cfg/swarm_lib.php).

K6 – spełnione. Zgłoszenia wielu niezależnych od siebie stron internetowych, a więc różnych administratorów, są łączone i zwracane wszystkim jako wspólna lista.
K1 – spełnione, o ile domenę można przypisać osobie fizycznej. Lista jest klasyfikacją jako źródło spamu. Wytyczne podają porównywanie ze wspólną bazą danych o oszustwach jako przykład tego kryterium. Większość domen na takiej liście należy do przedsiębiorstw lub jest domenami jednorazowymi; może się na niej jednak znaleźć domena osoby prywatnej – słusznie albo wskutek celowo rozsiewanych fałszywych zgłoszeń.
K9 – przypadek graniczny. Wiadomość z linkiem z listy nie dociera do odbiorcy od razu, lecz leży w jego kwarantannie, dopóki jej nie zwolni. Nie ginie.
K2 – niespełnione. Kwarantanna jest zautomatyzowanym skutkiem dla wiadomości, bez skutków prawnych i ze zwolnieniem przez człowieka po stronie odbiorcy.
Pozostałe kryteria – niespełnione. Sieci IP są wyłączone (swarm_ip_enabled = 0, cfg/swarm_lib.php).

Wynik cząstkowy V7: dwa kryteria (K6, K1) i jeden przypadek graniczny (K9). Próg jest osiągnięty; formexposed przeprowadza ocenę jako administrator. Przy włączonych sieciach IP K1 i K6 byłyby spełnione bez zastrzeżeń; ich włączenie wymaga nowej wersji tej oceny (pkt 12). Według pomiaru w systemie deweloperskim nie ma ani zgłoszeń, ani wpisów na liście.

V8 – Konta Klientów, logowanie, dzienniki, wsparcie, e-mail, płatności

K1 i K9 – niespełnione. Podejrzane zachowanie przy bezpłatnym sprawdzeniu prowadzi do adnotacji z adresem IP (cfg/check_lib.php) i ewentualnie do odrzucania kolejnych sprawdzeń. Jest to przeciwdziałanie nadużyciom o niewielkich skutkach, a nie ocena czynników osobowych.
Pozostałe kryteria – niespełnione. Są to zwykłe dane usługi dla przedsiębiorców.

Wynik cząstkowy V8: ocena skutków nie jest wymagana. Te przetwarzania opisano w Rejestrze czynności przetwarzania.

V9 – Liczby z wtyczki, błędy pól, rejestrator, pieczęć, portal klienta, „Fix it for me”

Wtyczka i rozszerzenie przekazują dzienne liczby, inwentarz wtyczek i kategorie błędów, wtyczka WordPress ponadto na potrzeby ochrony roju (fabrycznie włączonej) domeny linków (V7), a nie treści, adresy, nazwiska czy adresy IP odwiedzających; rejestrator przechowuje selektory najwyżej 15 minut w przeglądarce administratora strony. Żadne kryterium nie jest spełnione.
Pieczęć przy ładowaniu przekazuje zwykłe dane połączenia do dziennika serwera WWW, bez plików cookie. Żadne kryterium nie jest spełnione.
Portal klienta przetwarza adresy e-mail subskrybentów z podwójnym potwierdzeniem (double opt-in) w imieniu agencji. Żadne kryterium nie jest spełnione.
„Fix it for me” przebudowuje wklejony kod formularza za pomocą modelu językowego na naszym własnym serwerze; kod nie jest zapisywany. K8 w słabej postaci, poza tym nic.

Wynik cząstkowy V9: ocena skutków nie jest wymagana.

3.4 Wykaz polskiego organu nadzorczego na podstawie art. 35 ust. 4

Właściwy jest Prezes Urzędu Ochrony Danych Osobowych (Prezes UODO). Wykaz rodzajów operacji przetwarzania, dla których wymagana jest ocena skutków, ogłosił w komunikacie z 17 czerwca 2019 r. (Komunikat Prezesa Urzędu Ochrony Danych Osobowych z dnia 17 czerwca 2019 r. w sprawie wykazu rodzajów operacji przetwarzania danych osobowych wymagających oceny skutków przetwarzania dla ich ochrony, M.P. z 2019 r. poz. 666). Wykaz przyporządkowuje swoje pozycje kryteriom z wytycznych WP248, podaje przykłady i wyraźnie nie jest zamknięty; nie zastępuje oceny na podstawie art. 35 ust. 1.

W naszym odczytaniu treściowo odpowiadają przetwarzaniom formexposed następujące rodzaje operacji z wykazu:

Rodzaj przetwarzania według wykazu (w przybliżeniu)	Przyporządkowane kryterium	Przetwarzanie w formexposed	Kwalifikacja
Porównywanie, ocena lub wnioskowanie na podstawie analizy danych pozyskanych z różnych źródeł	K6	V7 ochrona roju	ma zastosowanie
Ewaluacja lub ocena, w tym profilowanie	K1	V7 ochrona roju; V1 i V2 jako przypadek graniczny	ma zastosowanie do V7
Przetwarzanie szczególnych kategorii danych osobowych	K4	V6 kontrola doręczenia	ma zastosowanie zależnie od Klienta
Innowacyjne wykorzystanie lub zastosowanie rozwiązań technologicznych	K8	V1–V4 (model językowy do klasyfikacji)	ma zastosowanie w słabej postaci
Przetwarzanie na dużą skalę	K5	V3 badanie	ma zastosowanie przy dużych listach
Systematyczne monitorowanie miejsc dostępnych publicznie, także z rozpoznawaniem cech	K3	–	nie ma zastosowania: chodzi o miejsca, a nie o strony internetowe

To przyporządkowanie jest odczytaniem, a nie cytatem; brzmienie pozycji należy porównać w ramach weryfikacji prawnej. Potwierdza ono wynik z pkt 3.3, ale go nie zmienia. Wykazu na podstawie art. 35 ust. 5 – rodzajów przetwarzania, dla których ocena skutków nie jest wymagana – Prezes UODO według naszej wiedzy nie ogłosił.

3.5 Wynik oceny progowej

Przetwarzanie	Spełnione	Przypadek graniczny	Wynik
V1 Bezpłatne sprawdzenie	K8 (słabo)	K1, K5	nieobowiązkowa; uwzględnione
V2 Sprawdzenie potencjalnego klienta	K8 (słabo)	K1	nieobowiązkowa; uwzględnione
V3 Badanie	K8 (słabo), K5 przy dużych listach	–	wymagana (obowiązek formexposed)
V4 Sprawdzanie domen Klientów	K8 (słabo)	K4 (sprawdzanie plików)	nieobowiązkowa; uwzględnione
V5 Skan za logowaniem	–	K4	nieobowiązkowa; uwzględnione; u Klienta zależnie od treści
V6 Kontrola doręczenia	K4; K7 zależnie od Klienta	K3 (raczej spełnione), K5	wymagana (obowiązek Klienta; ta strona wspiera go zgodnie z art. 28 ust. 3 lit. f)
V7 Ochrona roju	K6, K1	K9	wymagana (obowiązek formexposed)
V8 Konta, dzienniki, wsparcie, płatności	–	–	niewymagana
V9 Liczby z wtyczki, pieczęć, portal, „Fix it for me”	K8 (słabo, tylko „Fix it for me”)	–	niewymagana

Wynik w odniesieniu do art. 35 ust. 1: Ocena skutków jest wymagana dla niektórych przetwarzań formexposed. Dla ochrony roju i dla badań w przewidzianej skali jest ona wymagana, a formexposed przeprowadza ją jako administrator. Dla kontroli doręczenia jest ona w typowej konstelacji wymagana, ale jako obowiązek Klienta; formexposed dostarcza podstaw. Dla pozostałych sprawdzeń cudzych i własnych stron internetowych nie jest obowiązkowa. Mimo to uwzględniamy je, ponieważ korzystają z tej samej techniki, ponieważ kilka przypadków granicznych wskazuje w tym samym kierunku i ponieważ osoby, których dane dotyczą – operatorzy bez konta i osoby na sprawdzanych stronach – nic nie wiedzą o przetwarzaniu. Dla kont, dzienników, wsparcia i płatności ocena nie jest wymagana.

Pkt 6–10 dotyczą zatem V1–V7. Tam, gdzie stwierdzenie dotyczy tylko jednego z tych przetwarzań, jest to zaznaczone.

4. Inspektor ochrony danych: ocena na podstawie art. 37

Inspektor ochrony danych nie został wyznaczony. Art. 37 ust. 1 wiąże w równym stopniu administratora i podmiot przetwarzający; pytanie dotyczy więc nas samych. Trzy przypadki ustawowe:

Art. 37 ust. 1	Przesłanka	Wynik
lit. a	Organ lub podmiot publiczny	Nie dotyczy; LW IT Solutions Company Lukas Wójcik jest prywatnym jednoosobowym przedsiębiorstwem.
lit. b	Główna działalność polega na operacjach przetwarzania, które wymagają regularnego i systematycznego monitorowania osób, których dane dotyczą, na dużą skalę	Główną działalnością jest sprawdzanie i monitorowanie stron internetowych i formularzy, regularne i systematyczne. Monitorowane nie są jednak osoby: crawler nie obserwuje zachowań, a kontrola doręczenia analizuje e-maile wyłącznie pod kątem doręczenia i autentyczności. Niespełnione.
lit. c	Główna działalność polega na przetwarzaniu na dużą skalę danych z art. 9 lub 10	Nie z założenia konstrukcyjnego. Szczególne kategorie danych mogą do nas trafić przez kopię kontrolną w ramach kontroli doręczenia; jest to uboczne, a nie główna działalność. Niespełnione.

W naszej ocenie nie ma zatem obowiązku wyznaczenia inspektora. Czy prawo polskie na podstawie art. 37 ust. 4 wymaga ponadto wyznaczenia, jest otwartą kwestią do weryfikacji prawnej. Ponieważ inspektor ochrony danych nie został wyznaczony, odpada zasięganie jego opinii na podstawie art. 35 ust. 2. Jeżeli weryfikacja prawna wykaże obowiązek wyznaczenia, przed zatwierdzeniem tej oceny zasięgniemy opinii wyznaczonego wówczas inspektora ochrony danych (pkt 12). Osobą kontaktową w sprawach tej oceny jest właściciel pod adresem contact@lukaswojcik.com.

5. Metoda, źródła i granice tej wersji

Fakty w tym dokumencie pochodzą z kodu źródłowego aplikacji i skanera, ze schematu bazy danych, z liczby wierszy i ustawień systemu deweloperskiego, według pomiaru z 11 października 2026 r. Dostęp do bazy danych i serwerów odbywał się wyłącznie w trybie odczytu. Tam, gdzie pomiar przeczy zamiarowi – także twierdzeniu w naszych własnych dokumentach prawnych – podajemy wynik pomiaru. Nie stosujemy zatwierdzonych kodeksów postępowania, o których mowa w art. 40, których przestrzeganie należałoby uwzględnić zgodnie z art. 35 ust. 8.

Zmierzono system deweloperski. Usługa nie została jeszcze uruchomiona. Liczby są więc małe i częściowo są artefaktami testów: 112 sprawdzeń, w tym 110 bez domeny Klienta; 432 zrzuty ekranu; 2 domeny, w tym 1 z potwierdzonymi uprawnieniami; żadna kontrola doręczenia nie jest włączona; nie zapisano żadnego konta testowego do skanu za logowaniem; brak badań; brak zgłoszeń w ochronie roju. Przed uruchomieniem i później w regularnych odstępach należy wykonać nowy pomiar.
W tej wersji nie zmierzono i należy uzupełnić przed zatwierdzeniem: konfigurację systemu produkcyjnego, w tym to, czy i jak skonfigurowana jest skrzynka kontrolna oraz czy jest tam skonfigurowana para kluczy do skanu za logowaniem; to, czy oprogramowanie modelu językowego rejestruje zapytania; stan administrowania serwerami (R13); umowę z dostawcą usług poczty e-mail.
Nie dało się zmierzyć, ile prawdziwych wiadomości odwiedzających będzie przechodzić przez kopię kontrolną ani z jakich branż będą pochodzić Klienci. Obie te wielkości decydują o wadze R1 i R2 i należy je ustalić po uruchomieniu.
Miejsca w kodzie odsyłają do plików i funkcji w kodzie źródłowym systemu deweloperskiego. Decydująca jest opisana funkcja, a nie jej położenie w pliku.

Ten dokument jest projektem. Nie został jeszcze zatwierdzony przez administratora (pkt 12), a dwa z jego wniosków – ocena skali dla V1 i V3 oraz waga kontroli doręczenia – zależą od liczb, które pojawią się dopiero po uruchomieniu.

6. (a) Systematyczny opis operacji przetwarzania i celów

6.1 Jak zbudowany jest system sprawdzania

formexposed działa na własnych serwerach w Polsce, bez zewnętrznego dostawcy hostingu: serwer WWW z aplikacją i bazą danych oraz serwer skanujący z usługą sprawdzania i lokalnym modelem językowym, oba w tej samej sieci wewnętrznej. Sprawdzenie przebiega następująco:

Aplikacja tworzy zlecenie w bazie danych – z uwzględnieniem limitów i blokad opisanych w pkt 6.3.
Usługa sprawdzania na serwerze skanującym pobiera zlecenie, ponownie sprawdza listę blokad, nazwy hostów oraz – przy anonimowych sprawdzeniach – wiek domeny i uruchamia dla dokładnie tego zlecenia odizolowany kontener: własna sieć z własnymi regułami filtrowania, brak uprawnień specjalnych, system plików tylko do odczytu, limity pamięci i procesów, limit czasu (scanner/src/worker.js).
W kontenerze zautomatyzowana przeglądarka pobiera najwyżej osiem publicznych podstron, najpierw stronę główną, a następnie przede wszystkim strony kontaktowe, notę prawną i strony wsparcia. Wcześniej odczytuje robots.txt; wykluczenie dla FormExposedBot lub dla wszystkich crawlerów, które obejmuje stronę główną, kończy sprawdzenie, podobnie jak niedostępny plik robots.txt lub błąd serwera przy jego pobieraniu (scanner/src/net.js). Zakazy dla poszczególnych podścieżek nie są osobno respektowane. Puls formularza, pobieranie dowodu, narzędzie do nagłówków i wyszukiwanie publicznie dostępnych plików nie odczytują robots.txt. Oprócz ośmiu podstron dochodzą: do trzech podstron z kliknięciem „Odrzuć” w banerze cookie, do trzech podstron w widoku telefonu, przy domenach z potwierdzonymi uprawnieniami – aktywne próby, oraz do pięciu podstron za logowaniem; podstrony są ładowane kolejno, a nie równolegle. Każde żądanie przeglądarki – także przekierowania i treści osadzone – przechodzi przez filtr, który odrzuca sieci prywatne i obce porty.
Kontener zapisuje wynik i zrzuty ekranu w katalogu tymczasowym. Usługa sprawdzania przekazuje wynik i obrazy przez sieć wewnętrzną do aplikacji i usuwa katalog tymczasowy, także po błędzie (scanner/src/worker.js).
Aplikacja opracowuje wynik, przy domenach Klientów porównuje go z poprzednim sprawdzeniem i zgłasza zmiany do miejsc docelowych skonfigurowanych przez Klienta.

6.2 Co crawler zapisuje – a czego nie

Informacja	Co jest zapisywane	Co nie jest zapisywane	Miejsce w kodzie
Podstrony	adres, status HTTP, nagłówki, Content-Security-Policy, odpytywane obce hosty (najwyżej 120)	treść strony jako tekst lub HTML	`scanner/src/crawl.js`
Pola formularzy	typ, nazwa, etykieta, placeholder, pole obowiązkowe, widoczność, długość istniejącej wartości	wartości pól; przy polach ukrytych pierwsze 24 znaki wartości są odczytywane tylko w trakcie sprawdzenia (do rozpoznawania tokenów)	`scanner/src/crawl.js`
Adresy odbiorców w formularzu	tylko domena	adres	`scanner/src/crawl.js`
Skrypty	inwentarz z sumą kontrolną; adresy i początki tekstu bez identyfikatorów kont usług reklamowych i analitycznych	identyfikatory kont i pikseli	`scanner/src/crawl.js`
Podglądacze	które piksele reklamowe i narzędzia do nagrywania sesji ładują się przed odrzuceniem i po odrzuceniu w banerze cookie oraz czy maskują wpisywane dane	identyfikatory kont w tych usługach	`scanner/src/mitleser.js`, `scanner/src/einwilligung.js`
Tekst formularza	do 400 znaków trafia do lokalnego modelu językowego, jeżeli reguły nie rozpoznają typu	przekazywanie osobom trzecim; zapisywanie tekstu	`scanner/src/classify.js`
Zrzuty ekranu (crawler)	widoczny obszar pierwszej podstrony; dla każdego widocznego formularza obraz elementu formularza	–	`scanner/src/crawl.js`
Zrzuty ekranu (sprawdzenie aktywne)	obraz strony odpowiedzi na zgłoszenie testowe; do tego status, adres docelowy, tytuł i pierwsze 300 znaków jej tekstu	–	`scanner/src/active.js`
Zrzuty ekranu (ścieżki przeglądarki)	obraz formularza z zaczernionymi polami wprowadzania, skompresowany, najwyżej 32 KB	wpisywane dane	`scanner/src/browser.js`
Za logowaniem	jak pola formularzy powyżej	zrzuty ekranu, pliki cookie, linki	`scanner/src/login.js`

Dane osobowe nie występują w tych informacjach z założenia konstrukcyjnego, lecz przypadkowo: nazwisko osoby kontaktowej obok formularza, zdjęcie zespołu na stronie głównej, numer telefonu w etykiecie, domena e-mail osoby prywatnej, nazwisko w placeholderze. Za logowaniem dochodzą informacje o koncie testowym oraz, zależnie od strony internetowej, o innych użytkownikach.

6.3 Kto zleca sprawdzenie i jakie zasady wtedy obowiązują

Zlecający	Poziom zaufania w zleceniu	Zgłoszenia testowe	Wynik dostępny przez	Usunięcie
Ktoś wpisuje domenę na stronie głównej (bezpłatne sprawdzenie)	anonimowy	nie	raport pod losowym linkiem	30 dni, wraz z obrazami (`cfg/check_lib.php`)
Wtyczka lub rozszerzenie bez konta	wtyczka	nie	raport pod losowym linkiem	30 dni
Agencja dla potencjalnego klienta	zarejestrowany	nie	krótkie podsumowanie i raport pod losowym linkiem	90 dni (`cfg/akquise_lib.php`)
Klient, domena bez potwierdzenia uprawnień	zarejestrowany	nie	konto; raport pod losowym linkiem	13 miesięcy, ostatnie sprawdzenie pozostaje
Klient, domena z potwierdzeniem uprawnień	zweryfikowany	tak, najwyżej pięć na sprawdzenie	konto; raport pod losowym linkiem	13 miesięcy, ostatnie sprawdzenie pozostaje (`cfg/fristen_lib.php`)
Badanie	wewnętrzny	nie	tylko sumy po publikacji	wraz z publikacją; bez publikacji brak terminu (R4)
Wewnętrzne sprawdzenie z wiersza poleceń przez Usługodawcę	wewnętrzny; dla własnych domen testowych i demonstracyjnych także „zweryfikowany”	nie; przy poziomie „zweryfikowany” tak (tylko własne domeny testowe i demonstracyjne)	tylko wewnętrznie	brak terminu (R4)

Bezpłatne sprawdzenie poprzedza kilka warstw (cfg/check_lib.php): wyłącznik awaryjny; reCAPTCHA; ta sama domena najwyżej raz na siedem dni (później wyświetlany jest istniejący raport); limity na adres IP, na sesję (jako wartość skrótu, nigdy sam identyfikator sesji) i dla całej usługi na dzień; lista blokad z opt-out i robots.txt; sprawdzenie, czy domena wskazuje na adresy publiczne; oraz blokada dla bardzo młodych lub nieznanych domen. Nieprawidłowości – wiele różnych domen z jednego adresu IP, wiele żądań w krótkim czasie – są odnotowywane wraz z adresem IP i wyzwalają sygnał bez treści (cfg/check_lib.php).

6.4 Sprawdzanie domen na koncie Klienta

Klient potwierdza, że jest uprawniony do dysponowania domeną: wpisem DNS, metatagiem, plikiem lub przez naszą wtyczkę (cfg/verify_lib.php). Dopiero wtedy domena uchodzi za zweryfikowaną. Planista monitorowania planuje regularne sprawdzenia tylko dla aktywnych, monitorowanych i zweryfikowanych domen (cfg/monitor_lib.php).

Aktywne zgłoszenia testowe są uzależnione od dwóch bramek: aplikacja ustawia tryb aktywny w przypadku Klientów tylko dla zweryfikowanych domen (dla własnych domen testowych i demonstracyjnych Usługodawca może za pomocą wewnętrznego narzędzia wiersza poleceń założyć sprawdzenie z poziomem „zweryfikowany”), a usługa sprawdzania ponownie sprawdza poziom zaufania i wyłącznik awaryjny fc_active_enabled (scanner/src/worker.js). Wysłać można tylko formularz, który reguły z dużą pewnością rozpoznają jako ogólny formularz kontaktowy, który nie ma pól obowiązkowych na prawdziwe dane osobowe i którego domena nie wygląda na domenę urzędu, placówki edukacyjnej, kliniki, gabinetu, policji lub sądu (scanner/src/classify.js). Model językowy nie może uczynić formularza możliwym do wysłania (scanner/src/classify.js). Na jedno sprawdzenie wychodzi najwyżej pięć zgłoszeń (fc_active_max_posts), wyraźnie oznaczonych, z nadawcą dummy@formexposed.com, adresem w domenie .invalid do sprawdzenia walidacji adresu e-mail i nieszkodliwym dodatkowym nagłówkiem do wykrywania header injection (scanner/src/active.js).
Ścieżki przeglądarki sprawdzają skonfigurowane ścieżki formularzy w przeglądarce aż do momentu przed wysłaniem. Dopuszczone są tylko żądania GET i HEAD; wszystko inne jest przerywane, podobnie jak adresy ze słowami oznaczającymi wylogowanie, usunięcie, zakup lub płatność (scanner/src/browser.js). Pola obowiązkowe są na potrzeby sprawdzenia wypełniane zmyślonymi wartościami, które nigdy nie opuszczają przeglądarki.
Publicznie dostępne pliki są wyszukiwane co tydzień, tylko przy zweryfikowanych domenach, najwyżej jedno pobranie na ścieżkę, najwyżej 8 KB, treść nigdy nie jest zapisywana (cfg/dateien_lib.php).
Niezależna druga sonda jest przygotowana i domyślnie wyłączona (browser_probe_enabled = 0). Po włączeniu otrzymywałaby tylko domenę, adres, selektor, kroki i wybór przeglądarki, nigdy dane dostępowe, zrzuty ekranu ani dane odwiedzających (cfg/formular_probe_lib.php).

6.5 Skan za logowaniem

Warunki: funkcja jest skonfigurowana, domena jest zweryfikowana, Klient ma płatny plan i jest właścicielem lub administratorem obszaru roboczego (cfg/login_lib.php); potwierdza, że chodzi o konto testowe z możliwie najmniejszymi uprawnieniami (cfg/login_lib.php).

Nazwa użytkownika i hasło są na serwerze WWW natychmiast szyfrowane kluczem publicznym serwera skanującego: klucz jednorazowy dla każdego rekordu (X25519), derywacja klucza (HKDF-SHA256), AES-256-GCM, powiązanie z domeną (cfg/login_lib.php). Klucz prywatny ma tylko usługa sprawdzania na serwerze skanującym (scanner/src/geheim.js). Kto ma serwer WWW, bazę danych lub kopię zapasową, ma tylko szyfrogram.
Interfejs pokazuje z nazwy użytkownika tylko pierwszy znak i długość (cfg/login_lib.php). Dane dostępowe nigdy nie są wyświetlane, nigdy nie są zapisywane w dziennikach i nigdy nie są wydawane przez interfejs programistyczny (API).
Na potrzeby sprawdzenia aplikacja dołącza szyfrogram do zlecenia. Usługa sprawdzania go odszyfrowuje, natychmiast czyści pole w zleceniu i przekazuje dane dostępowe do kontenera wyłącznie przez standardowe wejście, nigdy jako parametry wywołania (scanner/src/worker.js). Pozostałości w przerwanych zleceniach proces statusowy usuwa po godzinie (cfg/login_lib.php).
W kontenerze przeglądarka się loguje. Przerywa, gdy strona logowania przekierowuje do obcego hosta, gdy formularz logowania zawiera CAPTCHA (nie obchodzimy CAPTCHA) albo gdy po wysłaniu nadal widoczne jest pole hasła (scanner/src/login.js). Następnie czyści pole hasła w pamięci strony i zapomina dane dostępowe (scanner/src/login.js).
Odczytuje najwyżej pięć wskazanych przez Klienta podstron tej samej domeny. Adresy ze słowami oznaczającymi wylogowanie, usunięcie, skasowanie lub wypowiedzenie są zablokowane (scanner/src/login.js). Za logowaniem nic nie jest wysyłane, nie powstają zrzuty ekranu, a pliki cookie i linki nie trafiają do wyniku (scanner/src/login.js).
Usunięcie jest ostateczne: szyfrogram zostaje nadpisany losowymi danymi tej samej długości, wiersz usunięty, oczekujące zlecenia wyczyszczone (cfg/login_lib.php). Wraz z domeną wiersz znika automatycznie dzięki kluczowi obcemu.

6.6 Kontrola doręczenia

Kontrola doręczenia odpowiada na pytanie, czy e-mail z formularza kontaktowego rzeczywiście dociera, i ocenia jego cechy autentyczności. Jest opcjonalna, domyślnie wyłączona i wymaga skonfigurowanej skrzynki kontrolnej (cfg/zustellung_lib.php).

Jeżeli Klient ją włączy, domena otrzymuje losowy znacznik. Klient wpisuje adres kontrolny z tym znacznikiem jako ukrytą kopię (UDW) w swoim formularzu.
Od tej chwili każdy e-mail z formularza trafia również do skrzynki kontrolnej: nasze oznaczone zgłoszenia testowe i wszystkie prawdziwe wiadomości odwiedzających. Wiadomości trafiają bezpośrednio do skrzynki u Namecheap, Inc. (Private Email), Phoenix, Arizona, USA – docierają tylko wtedy, gdy rekordy MX naszej domeny tam wskazują; przez przekierowanie, np. u rejestratora domeny Namecheap, Inc., do skrzynki nie docierają – i leżą tam, dopóki nie zostaną pobrane.
Proces statusowy pobiera skrzynkę co pięć minut (srv/cron_status.php). Z każdej wiadomości odczytuje nagłówki i najwyżej pierwsze 8 KB tekstu, nie oznaczając jej jako przeczytanej (cfg/zustellung_lib.php).
Z nagłówków ustala znacznik, a tym samym domenę, a z tekstu ewentualnie identyfikator naszego testu (cfg/zustellung_lib.php). Zapisywane są czas, domena i ewentualnie identyfikator testu (cfg/zustellung_lib.php), na 180 dni (cfg/zustellung_lib.php).
Na podstawie nagłówków ocenia SPF, DKIM i DMARC i zapisuje wynik przy domenie: wyniki sprawdzenia, domenę adresu nadawcy, domeny podpisów i adres wysyłającego serwera poczty (cfg/zustellung_lib.php). Jeżeli wynik się pogorszy, Klient otrzymuje jednorazowo alert, w którym może być podana domena nadawcy (cfg/zustellung_lib.php).
Następnie oznacza każdą pobraną wiadomość do usunięcia, także taką, której nie udało się przypisać do żadnej domeny, i na końcu przebiegu usuwa ją ze skrzynki (cfg/zustellung_lib.php). Jeżeli przebieg zostanie wcześniej przerwany, wiadomości pozostają do następnego udanego przebiegu.
Za dowód doręczenia uznaje się tylko kopię dokładnie tego testu, o który chodzi (cfg/zustellung_lib.php). Jeżeli nie dotrze ona w ciągu trzech godzin (delivery_wait_h), usługa zgłasza „brak doręczenia”.

Tekst prawdziwych wiadomości nigdy nie jest zapisywany w bazie danych, adres odwiedzającego również nie. Oba są jednak odczytywane: pobieranie wczytuje pierwsze 8 KB każdej wiadomości do pamięci operacyjnej, aby wyszukać identyfikator testu.

6.7 Ochrona roju

Warstwa ochrony wtyczki WordPress zatrzymuje wiadomość jako spam i zlicza domeny zawartych w niej linków. Raz dziennie wtyczka zgłasza nam te domeny wraz z liczbą trafień, najwyżej 60 dziennie; bez adresów, bez tekstu, bez adresów IP (cfg/swarm_lib.php).
Raz dziennie tworzymy z tego listę: domena trafia na nią, jeżeli w ciągu siedmiu dni została zgłoszona przez co najmniej trzy różne strony internetowe z co najmniej pięcioma trafieniami (swarm_min_sites, swarm_window_days, cfg/swarm_lib.php). Nigdy nie trafiają na listę duże usługi ze stałej listy wyjątków ani domeny naszych Klientów, w obu przypadkach wraz z subdomenami (cfg/swarm_lib.php).
Lista trafia wraz z odpowiedzią na dzienne zgłoszenie do wszystkich połączonych stron internetowych. Ich warstwa ochrony umieszcza wiadomości z linkami do domen z listy w kwarantannie, a nie w koszu.
To, czego nie ma już na nowej liście, wypada z niej; zgłoszenia są usuwane po 30 dniach (cfg/swarm_lib.php).
Sieci IP (/24 lub /48) są przygotowane, ale wyłączone do czasu zakończenia analizy prawnej (cfg/swarm_lib.php).

6.8 Wykorzystanie sztucznej inteligencji

Model językowy działa na naszym własnym serwerze skanującym, a nie u dostawcy AI. Jest wykorzystywany w trzech miejscach: w usłudze sprawdzania klasyfikuje formularze, których typu reguły nie rozpoznają; widzi przy tym tytuł strony, adres strony, etykiety przycisków wysyłania, typy pól, nazwy, etykiety i placeholdery oraz do 400 znaków tekstu formularza (scanner/src/classify.js). Jest pytany tylko wtedy, gdy reguły zwracają wynik „nieznany”; tak sklasyfikowane formularze nigdy nie są wysyłane i nie liczą się do wyniku punktowego ani oceny. Wynik punktowy, ocena, przeciwdziałanie nadużyciom, ochrona roju i reguły antyspamowe to stałe reguły, a nie AI. W „Fix it for me” model przebudowuje wklejony kod formularza; kod nie jest zapisywany. W przypadku kwalifikujących się sprawdzeń domen na kontach płatnych generuje również plan działań według priorytetów na podstawie nazwy hosta, ogólnego wyniku i wyniku punktowego, systemu CMS, typu miarodajnego formularza i adresu jego strony, ewentualnej rozpoznanej wtyczki oraz wybranych ustaleń z wynikiem negatywnym lub niejasnym. Zapytanie jest tymczasowo przechowywane w wewnętrznej kolejce zleceń i usuwane po odebraniu wyniku lub przez zaplanowane czyszczenie wpisów starszych niż jedna godzina. Wygenerowany tekst, język, status i znacznik czasu są przechowywane wraz z wynikiem skanu zgodnie z jego zasadami przechowywania. Raport oznacza plan jako podsumowanie AI i wskazuje, że miarodajne są poszczególne ustalenia; plan nie zmienia strony internetowej ani wyniku skanu. Model nie podejmuje decyzji dotyczących osób. Więcej na ten temat na stronie AI Act UE: jak formexposed korzysta ze sztucznej inteligencji.

6.9 Podstawy prawne

Przetwarzanie	Podstawa prawna
V1 Bezpłatne sprawdzenie: sprawdzenie wskazanej domeny; limity i przeciwdziałanie nadużyciom	wobec osoby zlecającej art. 6 ust. 1 lit. b; wobec operatora i osób widocznych na zrzutach art. 6 ust. 1 lit. f; przeciwdziałanie nadużyciom art. 6 ust. 1 lit. f
V2 Sprawdzenie potencjalnego klienta	art. 6 ust. 1 lit. f (prawnie uzasadniony interes agencji i formexposed)
V3 Badanie	art. 6 ust. 1 lit. f
V4 Sprawdzanie domen Klientów	art. 6 ust. 1 lit. b wobec Klienta; w odniesieniu do danych osób trzecich na jego stronie internetowej – polecenie Klienta zgodnie z art. 28
V5 Skan za logowaniem	polecenie Klienta zgodnie z art. 28; podstawa prawna Klienta
V6 Kontrola doręczenia	polecenie Klienta zgodnie z art. 28; podstawa prawna Klienta (w naszej propozycji tekstu dla Klientów art. 6 ust. 1 lit. f)
V7 Ochrona roju	art. 6 ust. 1 lit. f (wspólne odpieranie spamu na wielu stronach internetowych)

Nasz prawnie uzasadniony interes przy V1–V3 polega na tym, aby pokazać operatorom i ich usługodawcom słabe punkty ich formularzy, zanim zostaną wykorzystane do spamu lub nadużyć, oraz na świadczeniu usługi. Dane pochodzą z publicznie dostępnych źródeł. Wyważenie interesów znajduje się w pkt 7; czy art. 6 ust. 1 lit. f uzasadnia sprawdzanie cudzych stron internetowych na żądanie, jest otwartą kwestią do weryfikacji prawnej.

6.10 Odbiorcy i przekazywanie do państw trzecich

Odbiorca	Co	Przetwarzanie	Stan
Nikt poza formexposed	wyniki sprawdzeń, zrzuty ekranu, klasyfikacja przez model językowy	V1–V5	usługa sprawdzania i model językowy działają na własnych serwerach; na ścieżce sprawdzania crawlera nie znaleziono żadnego wywołania do osoby trzeciej poza samą sprawdzaną stroną internetową, usługami, których treści ona osadza (jak u każdego odwiedzającego), i usługą RDAP rdap.org w celu ustalenia wieku domeny (tylko nazwa domeny); usługi odpytywane w ramach monitorowania podano w następnym wierszu
Każdy, kto zna link	raport z ustaleniami i zrzutami ekranu	V1, V2, V4	losowy link o długości 128 bitów (`cfg/check_lib.php`), strony z `noindex` (`www/report.php`)
Usługi, które odpytuje monitorowanie domeny Klienta	listy blokad DNS (SpamCop, PSBL, Mailspike, SURBL): domeny i adresy IP serwerów, żadnych danych odwiedzających; Google Web Risk tylko, jeśli jest skonfigurowany: adres strony głównej; urzędy znacznika czasu Certum i DigiCert: tylko wartość skrótu protokołu weryfikacji; RDAP przez rejestr IANA: tylko nazwa domeny; strony statusowe dostawców: nic nie jest przekazywane; wpvulnerability.net: identyfikator wtyczki (bez wersji) lub motywu oraz wersja WordPressa	V4	w użyciu; szczegóły w Rejestrze czynności przetwarzania i na stronie Podmioty przetwarzające dalej
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	kopie kontrolne, w tym prawdziwe wiadomości odwiedzających	V6	umowa jeszcze niezawarta; miejsce przetwarzania i podstawa przekazywania do sprawdzenia
Namecheap, Inc. (USA)	rejestrator i DNS; do czasu skonfigurowania skrzynki przekierowanie ogólnej poczty na adresy naszej domeny, nie kopii kontrolnych (docierają one do skrzynki tylko przez rekordy MX wskazujące bezpośrednio na nią)	– (brak kopii kontrolnych)	podstawa przekazywania do sprawdzenia
Wybrane przez Klienta kanały alertów (e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram)	zdarzenie, domena, link; przy sprawdzaniu autentyczności domena nadawcy, jeżeli nie należy ona do strony	V4, V6	miejsce docelowe wybrane przez Klienta; częściowo poza UE. Wiadomości w Telegramie wysyłamy przez naszego bota; podstawa przekazywania jest w tym zakresie otwartą kwestią do weryfikacji prawnej
Wszystkie połączone strony internetowe	lista domen z linków	V7	w odpowiedzi do wtyczki
Druga sonda	domena, adres formularza, selektor, kroki	V4	wyłączona

6.11 Przechowywanie: zmierzone, a nie zamierzone

Usuwanie odbywa się przeważnie w nocy o 03:00 w procesie statusowym (srv/cron_status.php, cfg/fristen_lib.php); zgłoszenia w ochronie roju i wiersze sprawdzeń potencjalnych klientów codziennie od 04:00, przypisania kontroli doręczenia przy każdym pobraniu; raporty anonimowe i raporty dla potencjalnych klientów – według daty ich wygaśnięcia (cfg/check_lib.php). Zrzuty ekranu są usuwane z dysku razem z danym skanem (cfg/fristen_lib.php).

Dane	Termin według kodu	Miejsce w kodzie	Ustalenie
Bezpłatne sprawdzenie wraz z obrazami	30 dni	`cfg/check_lib.php`	działa
Sprawdzenie potencjalnego klienta wraz z obrazami	90 dni	`cfg/akquise_lib.php`; `srv/cron_status.php` (wiersze potencjalnych klientów)	działa
Sprawdzenia domeny Klienta	13 miesięcy, ostatnie pozostaje, dopóki istnieje domena	`cfg/fristen_lib.php`	działa
Wyniki ścieżek przeglądarki wraz z zaczernionymi obrazami	13 miesięcy	`cfg/fristen_lib.php`	działa
Dane usuniętej domeny	natychmiast; osierocone rekordy w nocy	`cfg/fristen_lib.php` (`fe_domain_loeschen()`, `fe_fristen_lauf()`)	działa, także dla inwentarza skryptów i zmian skryptów, które poza tym nie mają własnego terminu (zob. Rejestr czynności przetwarzania)
Badanie: dane surowe wraz z obrazami	przy publikacji	`cfg/studie_lib.php`	bez publikacji brak terminu; lista sprawdzonych hostów pozostaje także po publikacji bez terminu
Wewnętrzne sprawdzenia bez domeny i bez raportu	brak	–	brak usuwania; zmierzono 85 sprawdzeń z 369 obrazami od 22.09.2026 (R4)
Przypisania w ramach kontroli doręczenia	180 dni	`cfg/zustellung_lib.php`	działa
Wynik sprawdzenia autentyczności przy domenie	do następnego wyniku lub do usunięcia domeny	`cfg/zustellung_lib.php`	nadpisywany, bez terminu
Kopie kontrolne w skrzynce	do następnego udanego pobrania (co pięć minut)	`cfg/zustellung_lib.php`	kopie i kopie zapasowe u dostawcy skrzynki niesprawdzone
Dane dostępowe do skanu za logowaniem	do usunięcia przez Klienta lub usunięcia domeny; w zleceniu najwyżej do końca przebiegu, pozostałości po godzinie	`cfg/login_lib.php`	działa; w kopiach zapasowych wyłącznie jako szyfrogram do 14 dni
Zgłoszenia w ochronie roju	30 dni	`cfg/swarm_lib.php`	działa
Limity bezpłatnego sprawdzenia (IP, kraj, skrót sesji)	7 dni	`srv/cron_status.php`	działa
Adnotacje o podejrzanym zachowaniu z adresem IP	90 dni po wyjaśnieniu	`srv/cron_status.php`	niewyjaśnione adnotacje bez terminu; zmierzono: 3 adnotacje, wszystkie wyjaśnione
Adres IP, kraj, przeglądarka przy opt-out	12 miesięcy; wykluczenie pozostaje	`cfg/fristen_lib.php`	działa
Kopie zapasowe bazy danych	14 dni	`cfg/backup_lib.php`	działa; kopie zapasowe znajdują się obecnie w tej samej lokalizacji co baza danych i nie są dodatkowo szyfrowane; planowana jest zaszyfrowana kopia w drugiej lokalizacji (R13)

7. (b) Ocena niezbędności i proporcjonalności

Miarą są deklarowane cele: pokazanie operatorom, czy ich formularze są chronione przed spamem i nadużyciami (V1–V5), sprawdzenie, czy e-maile z formularzy docierają i wyglądają na autentyczne (V6), oraz wspólne odpieranie spamu na wielu stronach internetowych (V7). Te cele są uprawnione. Pytanie z art. 35 ust. 7 lit. b jest węższe: czy to przetwarzanie w tym zakresie jest niezbędne do realizacji celu i czy ingerencja pozostaje w proporcji do korzyści?

Element	Niezbędny do realizacji celu?	Proporcjonalny w zbudowanej postaci?
Pobranie kilku publicznych podstron, budowa formularzy, wykryte zabezpieczenia	Tak. Bez nich nie ma ustaleń.	Tak. Najwyżej osiem podstron (plus widoki z pkt 6.1), zakaz dla strony głównej w robots.txt jest respektowany, brak wartości pól widocznych, adresy odbiorców tylko jako domena.
Zrzut ekranu każdego formularza	Tak, jako dowód w raporcie: operator rozpoznaje, o który formularz chodzi.	W przeważającej mierze. Pola są puste, ponieważ crawler niczego nie wpisuje. Obraz pokazuje jednak otoczenie elementu formularza bez zaczernienia (R3).
Zrzut ekranu strony głównej	Do samych ustaleń niepotrzebny. Służy rozpoznaniu sprawdzanej strony internetowej w raporcie.	Tylko w ograniczonym zakresie; planowana jest dalsza minimalizacja. Strony główne często pokazują ludzi: zdjęcia zespołu, osoby kontaktowe, opinie klientów z nazwiskami. Zob. R3 i pkt 9.3.
Odczyt wartości pól ukrytych (pierwsze 24 znaki, tylko w trakcie sprawdzenia)	Tak: rozpoznaje się po nich tokeny i znaczniki czasu.	Tak. Zapisywany jest tylko wynik rozpoznania, nie wartość, także za logowaniem (R8).
Strona odpowiedzi na zgłoszenie testowe (obraz i 300 znaków tekstu)	Tak, jako dowód, jak zareagował formularz.	Tak. Odpowiedź dotyczy naszej oznaczonej wiadomości testowej bez danych osobowych.
Klasyfikacja przez model językowy	Przydatna, nie niezbędna: bez niej więcej formularzy pozostaje „nieznanych”.	Tak. Lokalnie, bez przekazywania, bez prawa do wysłania.
Lokalny plan działań na podstawie wybranych ustaleń i metadanych skanu	Przydatny do ustalania priorytetów działań naprawczych, nie jest niezbędny do uzyskania poszczególnych ustaleń.	Ograniczony do istniejących metadanych skanu i najwyżej 18 różnych ustaleń z wynikiem negatywnym lub niejasnym, bez zrzutów ekranu i wpisanych wartości pól w poleceniu dla modelu. Plan ma charakter doradczy i jest oznaczony jako wygenerowany przez AI; miarodajne pozostają poszczególne ustalenia. Adresy URL i notatki nadal mogą zawierać dane osobowe, a wygenerowany tekst podlega przechowywaniu skanu i dostępowi przez posiadanie linku. Ograniczenia te zmniejszają narażenie danych, ale nie dowodzą poprawności merytorycznej (R10).
Aktywne zgłoszenia testowe	Tak. Czy zabezpieczenie działa, okazuje się dopiero wtedy, gdy się je sprawdzi.	Tak, z limitem i oznaczeniem. Przesłanka – potwierdzenie uprawnień do domeny – nigdy jednak nie jest odnawiana (R7).
Wyszukiwanie publicznie dostępnych plików	Tak dla Klienta, którego dane z formularzy mogą tam być publicznie dostępne.	Tak. Tylko zweryfikowane domeny, najwyżej 8 KB, treść nigdy nie jest zapisywana.
Skan za logowaniem	Tak dla formularzy w strefie klienta, które w przeciwnym razie pozostałyby niesprawdzone.	W przeważającej mierze. Szyfrowanie i usuwanie są starannie zbudowane; logowanie akceptuje jednak nieszyfrowane połączenia i błędne certyfikaty (R8).
Kopia kontrolna prawdziwych wiadomości odwiedzających	Do dowodu doręczenia nie. Opiera się on wyłącznie na kopii naszego testu (`cfg/zustellung_lib.php`). Prawdziwe wiadomości przychodzą przy okazji, ponieważ ukryta kopia w formularzu nie odróżnia testu od prawdziwej wiadomości. Do sprawdzania autentyczności (SPF, DKIM, DMARC) są przydatne, ponieważ pokazują rzeczywistą drogę wysyłki.	Częściowo. Treści nie są zapisywane, ale są odczytywane, i do czasu pobrania leżą u dostawcy skrzynki, z którym umowa jest jeszcze otwarta (R1, R2). Łagodniejsze rozwiązanie jest technicznie możliwe: za pomocą naszej wtyczki można by ograniczyć ukrytą kopię do oznaczonych wiadomości testowych (pkt 9.3).
Zapisywanie domeny nadawcy prawdziwych wiadomości	Częściowo: pokazuje, czy formularz wysyła wiadomość z adresem odwiedzającego jako nadawcą (częsta przyczyna klasyfikacji jako spam).	Warunkowo. Dla osoby prywatnej z własną domeną domena jest daną osobową i trafia w alercie do Klienta i jego kanałów (R1).
Wspólna lista domen z linków	Tak. Link spamowy, który pojawia się jednocześnie na wielu stronach internetowych, jest silnym sygnałem, którego pojedyncza strona nie ma.	Tak, z minimalnymi progami, wyjątkami i kwarantanną zamiast usuwania. Sieci IP nie byłyby proporcjonalne bez nowej oceny.
Dane surowe badania	Do czasu analizy tak.	Bez maksymalnego terminu nie (R4).
Raport pod losowym linkiem	Tak. Przekazanie raportu – np. usługodawcy, który obsługuje stronę internetową – jest celem bezpłatnego sprawdzenia.	Tak. Losowy link o długości 128 bitów, `noindex`, bezpłatny raport tylko jako wyciąg (`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`), usunięcie po 30 dniach.

Zgodność z prawem. W przypadku V1–V3 i V7 opieramy się na art. 6 ust. 1 lit. f. Za wynikiem wyważenia przemawia: dane są publiczne i pobierane tak, jak robi to każdy odwiedzający; nic nie jest wysyłane; dane osobowe są uboczne i nieliczne; terminy są krótkie; operator może natychmiast i bez żadnego dowodu wykluczyć dalsze sprawdzenia przez crawler za pomocą zakazu dla strony głównej w robots.txt, a wszelkie dalsze sprawdzenia – przez naszą stronę opt-out; korzyść – zabezpieczony formularz – służy także operatorowi i jego odwiedzającym. Przeciw przemawia: operator nic nie wie o sprawdzeniu, raport jest przeznaczony dla osób trzecich, a w przypadku jednoosobowych przedsiębiorców ocenia człowieka. Uważamy wynik wyważenia za uzasadniony, dopóki obowiązują środki z pkt 9.1; potwierdzenie prawne jest w toku.

Informowanie osób, których dane dotyczą (art. 13 i 14). Operatorów i osoby na sprawdzanych stronach informujemy za pośrednictwem strony o crawlerze, której adres widnieje w identyfikatorze każdego pobrania, Polityki prywatności i strony opt-out. Indywidualne informowanie osób, które przypadkowo pojawiają się na zrzucie ekranu, byłoby możliwe tylko wtedy, gdybyśmy je zidentyfikowali – a to byłaby kolejna, silniejsza ingerencja. W tym zakresie powołujemy się na art. 14 ust. 5 lit. b. Odwiedzających, których wiadomości przechodzą przez kopię kontrolną, informuje Klient; wymaga tego Umowa powierzenia przetwarzania danych, a my udostępniamy w tym celu gotowy tekst.

Minimalizacja danych (art. 5 ust. 1 lit. c). Jest widoczna w wielu miejscach i uzasadniona w kodzie: brak wartości pól, adresy odbiorców tylko jako domena, identyfikatory kont w adresach skryptów ukryte, brak treści z kopii kontrolnej w bazie danych, brak zrzutów ekranu za logowaniem, w ochronie roju tylko domeny. W dwóch miejscach dalsza minimalizacja jest możliwa i planowana (pkt 9.3): przy niezaczernionym zrzucie ekranu strony głównej i przy domenie nadawcy prawdziwych wiadomości.

Ograniczenie przechowywania (art. 5 ust. 1 lit. e). Od 27 września 2026 r. nocny przebieg przestrzega terminów z Polityki prywatności dla danych Klientów i usuwa dane, które z okresu wcześniejszego pozostały bez powiązanej domeny (cfg/fristen_lib.php). Otwarte pozostają dwie ścieżki bez terminu: sprawdzenia wewnętrzne i nieopublikowane badania (R4).

Prawidłowość (art. 5 ust. 1 lit. d). Ustalenie może być błędne: formularz wydaje się niezabezpieczony, ponieważ zabezpieczenie ładuje się dopiero po interakcji, albo zapora sieciowa potraktowała crawler inaczej niż odwiedzającego. Dla operatora, którego strona internetowa jest publicznie przekazywana dalej jako „Niezabezpieczona”, jest to kwestia reputacji. Raport podaje więc metodę, pokazuje dowody i wskazuje granice sprawdzania z zewnątrz.

Wynik w zakresie proporcjonalności: Sprawdzanie cudzych i własnych stron internetowych jest w zbudowanej postaci w zasadzie proporcjonalne. W trzech miejscach istnieje potrzeba poprawy, którą można zaspokoić zwykłymi środkami i dla której zaplanowano środki (pkt 9.3): zrzuty ekranu strony głównej, sprawdzenia wewnętrzne bez terminu i nieszyfrowane logowanie przy skanie za logowaniem. Kontrola doręczenia jest proporcjonalna w odniesieniu do kopii testowej i sprawdzania autentyczności; w odniesieniu do prawdziwych wiadomości odwiedzających jest uzasadniona tylko dopóty, dopóki ich treść nie jest zapisywana, droga przez dostawcę skrzynki jest zabezpieczona umownie, a Klient informuje swoich odwiedzających. Obecnie brakuje drugiego z tych trzech warunków.

8. (c) Ocena ryzyka naruszenia praw lub wolności osób, których dane dotyczą

Ocenia się ryzyko dla osób, których dane dotyczą, a nie dla formexposed. Prawdopodobieństwo wystąpienia oceniane jest jako odległe, możliwe, prawdopodobne lub zaistniałe; „zaistniałe” oznacza, że zdarzenie nie jest prognozą, lecz zmierzonym stanem. Waga oceniana jest jako ograniczona, istotna, poważna lub bardzo poważna, zależnie od tego, co osoba może utracić: poufność swojej wiadomości, kontrolę nad kontem, swoją reputację zawodową, możliwość wykonywania prawa. Poziom wynika z obu tych czynników i opisuje obecny stan przy środkach z pkt 9.1.

Nr	Ryzyko	Przetwarzanie	Prawdopodobieństwo	Waga	Poziom
R1	Prawdziwe wiadomości odwiedzających w kopii kontrolnej, w tym możliwe szczególne kategorie danych	V6	Zaistniałe, gdy tylko funkcja jest włączona	Poważna	Wysoki
R2	Droga kopii kontrolnej przez dostawcę skrzynki bez zawartej umowy i z możliwym związkiem z państwem trzecim	V6	Prawdopodobne, dopóki brakuje umowy	Poważna	Wysoki
R3	Niezaczernione zrzuty ekranu cudzych stron internetowych	V1–V4	Prawdopodobne	Ograniczona	Średni
R4	Dane sprawdzeń i zrzuty ekranu bez ścieżki usuwania	V3, sprawdzenia wewnętrzne	Zaistniałe	Istotna	Wysoki
R5	Sprawdzanie i publiczna ocena cudzych stron internetowych bez wiedzy operatora; nadużycie jako narzędzie rozpoznania	V1	Możliwe	Istotna	Średni
R6	Sprawdzenie potencjalnego klienta jako podstawa niezamówionego kontaktu	V2	Prawdopodobne	Ograniczona	Średni
R7	Potwierdzenie uprawnień do domeny nigdy nie jest odnawiane	V4, V5	Możliwe	Istotna	Średni
R8	Dane dostępowe i treści przy skanie za logowaniem	V5	Możliwe	Poważna	Średni; wysoki przy prawdziwych kontach
R9	Aktywne zgłoszenia testowe i sprawdzanie plików na stronie internetowej Klienta	V4	Odległe	Istotna	Niski
R10	Klasyfikacja przez model językowy	V1–V4	Odległe	Ograniczona	Niski
R11	Wspólna lista blokad ze zgłoszeń wielu stron internetowych	V7	Możliwe	Ograniczona	Niski do średniego; wysoki z sieciami IP
R12	Raporty i zrzuty ekranu pod publicznym linkiem	V1, V2, V4	Możliwe	Ograniczona	Niski
R13	Słabości infrastruktury: kopie zapasowe, dostęp do serwerów, serwer skanujący	wszystkie	Możliwe	Poważna	Wysoki
R14	Prawa osób, których dane dotyczą, w przypadku osób, które nas nie znają	V1–V6	Prawdopodobne	Ograniczona	Niski

R1 – Prawdziwe wiadomości odwiedzających w kopii kontrolnej

Jest to najpoważniejsze ryzyko usługi i nie wynika z błędu, lecz z samej konstrukcji. Ukryta kopia w formularzu nie odróżnia naszej wiadomości testowej od wiadomości odwiedzającego. Jeżeli Klient włączy kontrolę doręczenia, do naszej skrzynki kontrolnej trafia każda wiadomość wysłana przez ten formularz (cfg/zustellung_lib.php). Pobieranie wczytuje nagłówki i pierwsze 8 KB tekstu do pamięci operacyjnej, aby wyszukać nasz identyfikator testu (cfg/zustellung_lib.php). W zwykłym formularzu kontaktowym są to imię i nazwisko, adres e-mail, numer telefonu i pełna treść wiadomości.

O tym, co napisze odwiedzający, decyduje on sam, a pole zachęca do spraw osobistych: prośba o termin wizyty z opisem dolegliwości do gabinetu, opis sporu prawnego do kancelarii, zgłoszenie kandydata do pracy, zapytanie dotyczące dziecka do szkoły. Nasze dokumenty prawne mówią, że kopie „nie powinny zawierać szczególnych kategorii danych osobowych”. Jest to prośba skierowana do Klienta, a nie środek ochrony: ani on, ani my nie wiemy z góry, co napisze odwiedzający.

Należą tu też dwie drogi poboczne. Po pierwsze, sprawdzanie autentyczności zapisuje przy domenie domenę adresu nadawcy (cfg/zustellung_lib.php). Jeżeli formularz wysyła wiadomość z adresem odwiedzającego jako nadawcą, jest to domena odwiedzającego – w przypadku dużego dostawcy poczty nic niemówiąca, w przypadku osoby prywatnej z własną domeną – dana osobowa. Ta domena widnieje także w alercie, który trafia do Klienta i do wybranych przez niego kanałów (cfg/zustellung_lib.php). Po drugie, zapisywany jest adres wysyłającego serwera poczty (cfg/zustellung_lib.php); z reguły jest to serwer strony internetowej, a nie odwiedzającego.

Prawdopodobieństwo – zaistniałe, gdy tylko funkcja jest włączona. Pytanie nie brzmi, czy prawdziwe wiadomości dotrą, lecz ile ich będzie. Według pomiaru w systemie deweloperskim funkcja nie jest włączona dla żadnej domeny. Waga – poważna. Poufność wiadomości skierowanej do przedsiębiorstwa jest dla wielu ludzi ważna, a dane z art. 9 są do przewidzenia u części typowych Klientów. Wagę łagodzi to, że treść nie trafia do bazy danych, leży w skrzynce tylko krótko i nie jest czytana przez żadnego człowieka w formexposed. Poziom – wysoki.

R2 – Droga kopii kontrolnej przez dostawcę skrzynki bez zawartej umowy

Zanim nasze pobieranie zobaczy kopię kontrolną, leży ona w skrzynce u Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. Dociera tam tylko wtedy, gdy rekordy MX naszej domeny wskazują bezpośrednio na tę skrzynkę; przekierowanie u rejestratora domeny Namecheap, Inc. nie jest etapem drogi kopii kontrolnych (przez przekierowanie nie docierają one do skrzynki). Dla etapu, który pozostaje, uregulowanie umowne jest jeszcze otwarte: umowa z dostawcą skrzynki nie została zawarta, jego miejsca przechowywania, dalsze podmioty przetwarzające i okresy przechowywania kopii zapasowych nie zostały ustalone, a otwarte jest, czy dla miejsca, w którym przetwarza dane, potrzebna jest i ma zastosowanie decyzja stwierdzająca odpowiedni stopień ochrony lub standardowe klauzule umowne. W przypadku naszych własnych e-maili transakcyjnych jest to kwestia ukształtowania umowy. W przypadku kopii kontrolnych sprawa jest poważniejsza: są to dane, które otrzymujemy jako podmiot przetwarzający, a każdy usługodawca na tej drodze jest dalszym podmiotem przetwarzającym, za którego odpowiadamy zgodnie z art. 28 ust. 4.

Do tego dochodzi, że „usunięte po pobraniu” dotyczy tylko naszego widoku skrzynki. Czy dostawca przechowuje usunięte wiadomości we własnych kopiach zapasowych lub w koszu i jak długo, nie zostało sprawdzone. Jeżeli pobieranie zostanie przerwane, wiadomości pozostają do następnego udanego przebiegu (cfg/zustellung_lib.php); jeżeli proces statusowy przestanie działać, pozostają bezterminowo. Wreszcie zabezpieczenie samego pobierania należy do punktów, które przed uruchomieniem trzeba sprawdzić w systemie produkcyjnym (pkt 9.3).

Prawdopodobieństwo – prawdopodobne, dopóki brakuje umowy: każda kopia kontrolna przechodzi tą drogą. Waga – poważna, z tych samych powodów co przy R1. Poziom – wysoki. Lista konfiguracyjna aplikacji zgłasza brak skrzynki jako ostrzeżenie; nie ma natomiast blokady, która uniemożliwiałaby kontrolę doręczenia bez udokumentowanej umowy.

R3 – Niezaczernione zrzuty ekranu cudzych stron internetowych

Crawler wykonuje zrzut widocznego obszaru pierwszej podstrony oraz obraz elementu każdego widocznego formularza (scanner/src/crawl.js). Nic przy tym nie jest zaczerniane. Inaczej jest przy ścieżkach przeglądarki: tam pola wprowadzania są maskowane przed wykonaniem zrzutu (scanner/src/browser.js). „Oczyszczone” są więc tylko obrazy ze ścieżek przeglądarki, a nie obrazy crawlera ani obraz strony odpowiedzi przy sprawdzeniu aktywnym.

Ponieważ crawler niczego nie wpisuje, pola formularzy są puste. Strona główna małej firmy często pokazuje jednak właściciela, zespół, opinie klientów z nazwiskiem i zdjęciem albo okno czatu ze zdjęciem pracownicy. Wszystko to jest publiczne; zrzut ekranu tworzy z tego kopię, która jest przechowywana u nas, pojawia się w raporcie i może być przekazywana dalej wraz z linkiem.

Prawdopodobieństwo – prawdopodobne. Zmierzono 432 zrzuty ekranu w zasobie systemu deweloperskiego. Waga – ograniczona: treści są już publiczne, a terminy przy sprawdzeniach bez konta są krótkie. Poziom – średni, ze względu na niewiedzę osób widocznych na obrazach oraz dlatego, że obraz strony głównej nie jest potrzebny do ustaleń.

R4 – Dane sprawdzeń i zrzuty ekranu bez ścieżki usuwania

Nocny przebieg usuwa sprawdzenia dwiema drogami: według daty wygaśnięcia raportu (cfg/check_lib.php) i według terminu dla sprawdzeń domeny Klienta (cfg/fristen_lib.php, tylko dla sprawdzeń z domeną). Sprawdzenie, które nie ma ani raportu, ani domeny, wypada przez oba sita. Są to sprawdzenia z poziomem zaufania „wewnętrzny”: badania i sprawdzenia, które Usługodawca tworzy z wiersza poleceń.

Badania usuwają swoje dane surowe wraz z publikacją (cfg/studie_lib.php). Jeżeli badanie nigdy nie zostanie opublikowane – ponieważ obejmuje zbyt mało stron internetowych z formularzem (cfg/studie_lib.php odmawia wtedy publikacji) albo ponieważ zostanie porzucone – sprawdzenia, formularze, ustalenia i zrzuty ekranu pozostają bez terminu.
Wewnętrzne sprawdzenia z wiersza poleceń w ogóle nie mają ścieżki usuwania. Pomiar z 11 października 2026 r.: 85 takich sprawdzeń cudzych stron internetowych z 978 formularzami i 369 zrzutami ekranu, najstarsze z 22 września 2026 r., żadne z raportem ani domeną.
Adnotacje o podejrzanym zachowaniu przy bezpłatnym sprawdzeniu zawierają adres IP i są usuwane 90 dni po ich wyjaśnieniu (srv/cron_status.php). Adnotacja, która nigdy nie zostanie wyjaśniona, pozostaje. Zmierzono: trzy adnotacje, wszystkie wyjaśnione.

Prawdopodobieństwo – zaistniałe. 85 sprawdzeń to nie scenariusz, lecz stan zasobu. W systemie deweloperskim są to sprawdzenia z testu w warunkach rzeczywistych; w systemie produkcyjnym obowiązuje ten sam kod. Waga – istotna: dla tych danych brakuje terminu usunięcia. W świetle zasady ograniczenia przechowywania (art. 5 ust. 1 lit. e) jest to otwarta kwestia z planowanym środkiem (pkt 9.3, priorytet „najpierw”), która dotyczy akurat osób nic niewiedzących o sprawdzeniu. Sprawdzenia wewnętrzne opisano w Rejestrze czynności przetwarzania; Polityka prywatności nie wymienia ich jeszcze osobno (pkt 9.4). Poziom – wysoki.

R5 – Sprawdzanie i publiczna ocena cudzych stron internetowych bez wiedzy operatora

Każdy może zlecić sprawdzenie dowolnej publicznie dostępnej strony internetowej, bez konta i bez związku z nią. Operator nie jest powiadamiany. Wynikiem jest raport, który klasyfikuje stronę internetową jako „Niezabezpieczoną”, „Częściowo zabezpieczoną” lub „Zabezpieczoną” i który widzi każdy, kto ma link. Dla osób, których dane dotyczą, możliwe są dwa skutki. Jednoosobowy przedsiębiorca zostaje publicznie – choćby tylko wobec odbiorców linku – opatrzony oceną, która może być błędna. A raport pokazuje spamerowi, do którego formularza można bez przeszkód wysyłać wiadomości.

Przeciwdziała temu szereg blokad (cfg/check_lib.php): na domenę najwyżej jedno sprawdzenie w ciągu siedmiu dni, potem ten sam raport; limity na adres IP i sesję; dzienny limit dla całej usługi; brak sprawdzania bardzo młodych domen, typowych dla nadużyć; adnotacja i sygnał przy podejrzanym zachowaniu; robots.txt i opt-out, sprawdzane dwukrotnie (cfg/check_lib.php i w usłudze sprawdzania). Bezpłatny raport jest wyciągiem: pokazuje tylko podstawowe ustalenia, a nie dowody ze wszystkich detektorów. I nie mówi niczego, czego bot nie ustaliłby sam w kilka sekund – niezabezpieczony formularz jest widoczny z zewnątrz.

Prawdopodobieństwo – możliwe. Waga – istotna dla jednoosobowego przedsiębiorcy, do którego formularza po raporcie celowo wysyła się wiadomości lub którego ocena jest błędna. Poziom – średni.

R6 – Sprawdzenie potencjalnego klienta jako podstawa niezamówionego kontaktu

Sprawdzenie potencjalnego klienta jest w interfejsie opisane jako „otwieracz do pierwszej rozmowy”. O sposobie wykorzystania krótkiego podsumowania decyduje agencja; technicznie może je wysłać także operatorowi, który o nie nie prosił. My do nikogo nie piszemy (cfg/akquise_lib.php), a Regulamin zobowiązuje agencję do przestrzegania przepisów o reklamie i kontaktowaniu się z adresatami. Niezamówiony e-mail z wynikiem jest jednak także między przedsiębiorcami marketingiem bezpośrednim, który w Polsce (art. 398 ustawy – Prawo komunikacji elektronicznej (PKE)) i w Niemczech (§ 7 ust. 2 niemieckiej ustawy o zwalczaniu nieuczciwej konkurencji, UWG) wymaga uprzedniej zgody. Interfejs nie zwraca na to uwagi; teksty sprawdzenia potencjalnego klienta mówią tylko o „pasywnym” sprawdzeniu i „liście opt-out”.

Prawdopodobieństwo – prawdopodobne, ponieważ funkcja służy pozyskiwaniu klientów, a my nie możemy sprawdzić, czy odbiorca wyraził zgodę. Waga – ograniczona: dla operatora jest to uciążliwy e-mail reklamowy z oceną jego strony internetowej. Poziom – średni. Ryzyko leży w zachowaniu agencji; ponieważ funkcja pochodzi od nas, planowana jest wskazówka w interfejsie (pkt 9.3).

R7 – Potwierdzenie uprawnień do domeny nigdy nie jest odnawiane

Aktywne zgłoszenia testowe, wyszukiwanie publicznie dostępnych plików i skan za logowaniem wymagają, aby Klient potwierdził, że jest uprawniony do dysponowania domeną. To potwierdzenie jest sprawdzane jeden raz (cfg/verify_lib.php), a później już nigdy. W kodzie nie ma ścieżki, na której domena traci potwierdzenie. Jeżeli domena zmieni właściciela, agencja wypowie zlecenie albo operator usunie wpis DNS, sprawdzenia trwają dalej – nawet codziennie, z maksymalnie pięcioma zgłoszeniami testowymi i, tam gdzie zostało zapisane, z logowaniem na konto testowe, którego nowy operator być może nie zna. Nie da się natomiast przenieść potwierdzenia na inny host przez zmianę nazwy: nazwy hosta domeny z potwierdzeniem uprawnień nie można zmienić.

Prawdopodobieństwo – możliwe: zmiany domen i zmiany zleceń to w agencjach codzienność. Waga – istotna dla nowego operatora i jego pracowników, którzy otrzymują oznaczone wiadomości testowe i których strona internetowa jest przeszukiwana pod kątem publicznie dostępnych plików bez ich zgody. Poziom – średni. Wiadomości testowe same się wyjaśniają i odsyłają do strony o crawlerze i do opt-out; opt-out działa także wobec sprawdzeń zlecanych przez Klientów.

R8 – Dane dostępowe i treści przy skanie za logowaniem

Szyfrowanie danych dostępowych jest starannie zbudowane: serwer WWW po zapisaniu nie może ich już odczytać, w bazie danych i kopii zapasowej znajduje się tylko szyfrogram, rekord jest powiązany ze swoją domeną, dane dostępowe trafiają do kontenera wyłącznie przez standardowe wejście, a następnie są czyszczone w pamięci (pkt 6.5). Pozostają dwie luki; trzeci punkt dotyczy tylko odczytu, a nie zapisu.

Nieszyfrowane logowanie jest dopuszczone. Sprawdzanie adresów dopuszcza http obok https (cfg/login_lib.php, scanner/src/login.js). Jeżeli Klient wpisze stronę logowania z http, nazwa użytkownika i hasło przy każdym sprawdzeniu przechodzą przez internet otwartym tekstem.
Błędy certyfikatów nie zatrzymują logowania. Logowanie obecnie nie zostaje przerwane w przypadku nieważnego certyfikatu strony Klienta (scanner/src/login.js). Certyfikat nie chroni zatem w pełni danych dostępowych w drodze do strony Klienta. Planowane jest przerywanie logowania w razie błędów certyfikatu (pkt 9.3, priorytet „najpierw”).
Wartości pól ukrytych za logowaniem są odczytywane, ale nie zapisywane. Crawler odczytuje z pól ukrytych pierwsze 24 znaki wartości (scanner/src/crawl.js), a ta sama funkcja odczytu działa za logowaniem (scanner/src/login.js). Tam pola ukryte często zawierają numer konta, identyfikator użytkownika lub adres e-mail zalogowanego konta; do mapy pól i ustaleń trafiają jednak tylko nazwa pola, typ, etykieta i wynik rozpoznania.

Do tego dochodzi to, czemu kod nie może zapobiec: Klient potwierdza, że używa konta testowego z możliwie najmniejszymi uprawnieniami (cfg/login_lib.php), ale może wpisać prawdziwe konto administratora. O podstronach, które skaner wtedy odczytuje, decyduje Klient; adresy ze słowami oznaczającymi wylogowanie i usunięcie są zablokowane, inne działania, które strona internetowa uruchamia zwykłym wywołaniem adresu – nie.

Prawdopodobieństwo – możliwe. Waga – poważna, jeżeli dotyczy to konta z szerokimi uprawnieniami; wtedy strefa klienta z danymi wszystkich użytkowników stoi otworem. Poziom – średni przy koncie testowym z niewielkimi uprawnieniami, wysoki przy prawdziwym koncie. Według pomiaru w systemie deweloperskim nie zapisano żadnego konta testowego.

R9 – Aktywne zgłoszenia testowe i sprawdzanie plików na stronie internetowej Klienta

Zgłoszenie testowe trafia do ludzi, którzy czytają e-maile z formularzy Klienta – jego pracowników lub usługodawcy. Nie zawiera danych osobowych: nadawcą jest dummy@formexposed.com, tekst i temat są oznaczone i podają identyfikator sprawdzenia (scanner/src/active.js). Ryzyko polega na błędnej klasyfikacji: gdyby skaner uznał formularz rekrutacyjny, rezerwacyjny lub konsultacyjny za formularz kontaktowy, wiadomość testowa trafiłaby do procesu, który ma skutki. Przeciwdziałają temu surowe reguły dla „możliwego do wysłania” (scanner/src/classify.js), blokada dla domen urzędów, placówek edukacyjnych, klinik, gabinetów, policji i sądów (scanner/src/classify.js) oraz wyłączenie modelu językowego z tej decyzji (scanner/src/classify.js). Z odpowiedzi zapisywane są status, adres docelowy, tytuł, 300 znaków tekstu i obraz; dotyczą one naszej wiadomości testowej.

Sprawdzanie plików odczytuje z typowych ścieżek najwyżej 8 KB. Jeżeli rzeczywiście leży tam publicznie dostępny zrzut bazy danych, te 8 KB może zawierać dane wpisane w formularze przez odwiedzających. Są one jedynie sprawdzane pod kątem sygnatury i odrzucane (cfg/dateien_lib.php); zapisywane są ścieżka, rodzaj i waga.

Prawdopodobieństwo – odległe. Waga – istotna. Poziom – niski. Według pomiaru w systemie deweloperskim w zasobie jest jedno sprawdzenie aktywne, bez przyjętego zgłoszenia.

R10 – Klasyfikacja przez model językowy

W przypadku formularzy, których reguły nie rozpoznają, model językowy otrzymuje tytuł strony, adres, teksty przycisków, opisy pól i do 400 znaków tekstu formularza (scanner/src/classify.js). Może się tam znaleźć nazwisko, np. „Twoja osoba kontaktowa: …”. Model działa na naszym własnym serwerze; w kodzie nic nie trafia do osoby trzeciej. Czy oprogramowanie modelu rejestruje zapytania, nie zostało sprawdzone. Jego wynik określa jedynie wyświetlany typ formularza i nie może uczynić żadnego formularza możliwym do wysłania; błędna klasyfikacja prowadzi do gorszego ustalenia, a nie do działania.

Prawdopodobieństwo – odległe. Waga – ograniczona. Poziom – niski.

R10 – Dodatkowy etap planu działań

W przypadku kwalifikujących się płatnych raportów ten sam lokalny model generuje również kroki doradcze na podstawie wybranych ustaleń i metadanych skanu. W odróżnieniu od klasyfikacji wynikiem jest podsumowanie w języku naturalnym, zachowywane wraz ze skanem. Nazwy hostów, adresy stron i notatki mogą zawierać dane osobowe, które model może powtórzyć. Błędne zalecenie może skłonić czytelnika do osłabienia ochrony lub wprowadzenia niepotrzebnej zmiany; przekazanie linku do raportu może ujawnić powtórzone dane osobowe innemu odbiorcy. Kod nie wykonuje zalecenia automatycznie, nie zmienia wyniku punktowego ani oceny i nie sprawdza poprawności merytorycznej tekstu. Ogranicza długość danych wejściowych i wyjściowych, oznacza podsumowanie jako wygenerowane przez AI i wskazuje, że miarodajne są poszczególne ustalenia. Są to środki kontroli, a nie dowód poprawności zaleceń ani anonimowości raportu. Wcześniejsza ocena prawdopodobieństwa i wagi dla klasyfikacji nie stanowi sama w sobie oceny tego dodanego etapu generowania; jego ryzyko szczątkowe należy ocenić z uwzględnieniem rzeczywistych danych i wykorzystania sprawdzenia będącego jego podstawą.

R11 – Wspólna lista blokad ze zgłoszeń wielu stron internetowych

Domena na liście powoduje, że wiadomości z linkami do niej trafiają na wszystkich połączonych stronach internetowych do kwarantanny. Jeżeli domena należy do osoby prywatnej – rzemieślnika, fotografki, bloga – jej wiadomości z linkiem do własnej strony internetowej docierają do odbiorców z opóźnieniem. Taka domena może trafić na listę, ponieważ spamerzy ją nadużywają, albo ponieważ ktoś celowo wysyła z nią na kilka stron internetowych wiadomości, które zostają zatrzymane.

Przeciwdziała temu (cfg/swarm_lib.php): minimalna liczba trzech różnych stron internetowych i pięciu trafień w ciągu siedmiu dni; stałe wyjątki dla dużych usług; nigdy domeny naszych Klientów; ręczne usuwanie z listy za pomocą narzędzia na serwerze; kwarantanna zamiast usuwania; lista jest codziennie tworzona od nowa, a to, co nie jest już zgłaszane, z niej wypada. Osoba, której to dotyczy, nie widzi listy i nie ma własnej drogi, by zażądać usunięcia z niej, poza zwróceniem się do nas.

Prawdopodobieństwo – możliwe. Waga – ograniczona, ponieważ nic nie ginie, a odbiorca może zwolnić wiadomość. Poziom – niski do średniego. Przy włączonych sieciach IP dotknięte byłyby sieci całych dostawców, adresy IP są danymi osobowymi, a waga wzrosłaby do istotnej: wysoki.

R12 – Raporty i zrzuty ekranu pod publicznym linkiem

Raporty z bezpłatnego sprawdzenia, ze sprawdzenia potencjalnego klienta i ze sprawdzeń domen Klientów są dostępne bez logowania pod losowym linkiem. Link zawiera 128 bitów losowości i nie da się go odgadnąć (cfg/check_lib.php). Strony mają noindex, aplikacja wysyła politykę Referrer-Policy, która przekazuje tylko pochodzenie (www/.htaccess), a zrzuty ekranu są udostępniane tylko razem z raportem, do którego należą; cudzy numer obrazu zwraca „nie znaleziono” (www/shot.php). Ryzyko nie jest kryptograficzne, lecz ludzkie: link jest przekazywany dalej, kopiowany do zgłoszenia serwisowego, udostępniany na czacie. Kto go otwiera, jest rejestrowany tylko tak jak przy każdym wyświetleniu strony – w dzienniku wyświetleń stron (60 dni), w którym sam link jest zapisany wyłącznie w postaci zamaskowanej; listy czytelników poszczególnych raportów nie ma.

Prawdopodobieństwo – możliwe. Waga – ograniczona, ponieważ raport pokazuje tylko to, co publiczne, i wygasa po 30 lub 90 dniach; raporty dotyczące domen Klientów pozostają dostępne, dopóki istnieje sprawdzenie (13 miesięcy, ostatnie dłużej). Poziom – niski.

R13 – Słabości infrastruktury

Poniższe punkty figurują w naszym wewnętrznym pakiecie do weryfikacji jako otwarte i nie są tu upiększane. Opisujemy je tak dokładnie, jak potrzebują tego Klienci do własnej oceny, ale nie tak dokładnie, by opis wskazywał drogę atakującemu; szczegóły przedstawiamy organowi nadzorczemu na jego żądanie.

Kopie zapasowe bazy danych znajdują się obecnie w tej samej lokalizacji co baza danych i nie są dodatkowo szyfrowane; planowana jest zaszyfrowana kopia w drugiej lokalizacji (cfg/backup_lib.php). Do tego czasu nie chronią przed utratą lokalizacji, a kto uzyska bazę danych, uzyska także kopie zapasowe. Dane dostępowe do skanu za logowaniem są w nich zawarte wyłącznie jako szyfrogram.
Brak szyfrowania bazy danych w spoczynku. Wyjątkiem są pola szyfrowane indywidualnie (dane dostępowe kont testowych, sekret uwierzytelniania dwuskładnikowego).
Połączenia wewnątrz naszej sieci wewnętrznej nie są w całości szyfrowane.
Administrowanie serwerami. Zabezpieczenie dostępów administracyjnych do naszych serwerów nie odpowiada jeszcze poziomowi, który przewidujemy dla działalności produkcyjnej; utwardzanie administrowania serwerami jest kontynuowane.
Środowisko sprawdzania. Serwer skanujący otwiera cudze strony internetowe w przeglądarce. Kontenery sprawdzające są odizolowane – własna sieć, brak uprawnień specjalnych, tylko do odczytu, z limitami (scanner/src/worker.js). Oddzielenie środowiska sprawdzania od pozostałych części usługi jest dalej wzmacniane (pkt 9.3).

Prawdopodobieństwo – możliwe. Waga – poważna, ponieważ w razie incydentu wszystko zostałoby dotknięte jednocześnie. Poziom – wysoki. Poszczególne punkty można usunąć zwykłymi środkami (pkt 9.3).

R14 – Prawa osób, których dane dotyczą, w przypadku osób, które nas nie znają

Kto przypadkowo pojawia się na zrzucie ekranu albo czyja wiadomość przeszła przez kopię kontrolną, z reguły nie wie, że istniejemy. Nawet jeśli wie, nie ma klucza do „swoich” danych: nie przechowujemy ich według osób, lecz według domeny i sprawdzenia. Na żądanie dostępu na podstawie art. 15 możemy odpowiedzieć tylko wtedy, gdy osoba wskaże domenę; wtedy możemy przejrzeć istniejące sprawdzenia i obrazy. W odniesieniu do prawdziwych wiadomości odwiedzających nie ma czego udostępnić, ponieważ ich nie przechowujemy – poza domeną nadawcy z R1. Opt-out działa tylko dla operatorów domeny, a nie dla osób widocznych na obrazach; dla nich pozostaje droga przez contact@lukaswojcik.com.

Prawdopodobieństwo – prawdopodobne jako sytuacja strukturalna. Waga – ograniczona, ponieważ dane są krótkotrwałe i nieuporządkowane według osób. Poziom – niski.

9. (d) Środki zaradcze

Każdy środek ma status, a statusy nie są ozdobnikami. Obecnie wdrożone – sprawdzone oznacza: odczytane w kodzie systemu deweloperskiego i, tam gdzie to było możliwe, zweryfikowane pomiarem w bazie danych. Częściowo oznacza: mechanizm istnieje, ale jeszcze nie osiąga w pełni swojego celu. Planowane oznacza: zaproponowane w tej ocenie i niezbudowane; czy i kiedy, decyduje właściciel. Do ustalenia są procedury i decyzje, których żaden kod nie zastąpi. Ocena skutków, która przedstawia środki planowane jako wdrożone, traci wartość dokładnie w sytuacji, w której jest potrzebna.

9.1 Obecnie wdrożone – sprawdzone

Środek	Przeciwdziała	Miejsce w kodzie
robots.txt jest odczytywany przez crawler przed każdym sprawdzeniem; wykluczenie obejmujące stronę główną, niedostępny plik robots.txt lub błąd serwera kończą sprawdzenie (podścieżki nie są respektowane osobno; puls, pobieranie dowodu, narzędzie do nagłówków i wyszukiwanie plików go nie odczytują)	R5, zgodność z prawem	`scanner/src/net.js`
Opt-out bez dowodu, skuteczny natychmiast, dla domeny i jej wariantu www, dla sprawdzeń anonimowych, potencjalnych klientów, badań i sprawdzeń Klientów (bieżące monitorowanie kończy się z następnym zaplanowanym sprawdzeniem); sprawdzany dwukrotnie (aplikacja i usługa sprawdzania); uchylany tylko przez nas na wniosek z dowodem	R5, R7, art. 21	`cfg/check_lib.php`; `cfg/akquise_lib.php`; `cfg/studie_lib.php`; `scanner/src/worker.js`
Bezpłatne sprawdzenie: wyłącznik awaryjny, reCAPTCHA, jedno sprawdzenie na domenę w tygodniu, limity na adres IP i sesję, dzienny limit, brak młodych domen, tylko adresy publiczne, adnotacja i sygnał bez treści przy nieprawidłowościach	R5	`cfg/check_lib.php`
Sesja jest na potrzeby limitów zapisywana tylko jako wartość skrótu, nigdy jako identyfikator sesji	minimalizacja	`cfg/check_lib.php`
Brak wartości pól (początki pól ukrytych i atrybuty data są odczytywane tylko w trakcie sprawdzenia, pkt 6.2); adresy odbiorców tylko jako domena; identyfikatory kont w adresach skryptów ukryte	minimalizacja	`scanner/src/crawl.js`
Bezpłatny raport jest wyciągiem: tylko podstawowe ustalenia, bez dowodów ze wszystkich detektorów	R5	`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`
Raporty pod 128-bitowym losowym linkiem, `noindex`, obrazy tylko do własnego raportu, poza publicznym katalogiem WWW; link jest zapisany w dzienniku wyświetleń stron wyłącznie w postaci zamaskowanej	R12	`cfg/check_lib.php`; `www/report.php`; `www/shot.php`
Usuwanie: raporty anonimowe po 30 dniach, potencjalni klienci po 90 dniach, sprawdzenia Klientów po 13 miesiącach (ostatnie dla każdej domeny pozostaje, dopóki domena istnieje), dane usuniętej domeny natychmiast (wyjątki zob. pkt 6.11), obrazy za każdym razem razem z nimi	ograniczenie przechowywania	`cfg/check_lib.php`; `cfg/fristen_lib.php`
Badanie: publikacja tylko jako suma, segmenty dopiero od 20 stron internetowych z formularzem, dane surowe usuwane wraz z publikacją	R4 częściowo, V3	`cfg/studie_lib.php`
Kontenery sprawdzające: własna odizolowana sieć, brak uprawnień specjalnych, tylko do odczytu, limity pamięci i procesów, limit czasu; filtr przeciw prywatnym celom dla każdego żądania, service workery zablokowane, a połączenia WebSocket zamykane, aby nic nie omijało filtra; pobrania wykonywane przez serwer WWW tylko na portach WWW i tylko do dokładnie tego publicznego adresu, który wcześniej sprawdzono	R13	`scanner/src/worker.js`; `scanner/src/net.js`
Sprawdzenie aktywne w przypadku Klientów tylko przy zweryfikowanej domenie (wewnętrznie dodatkowo dla własnych domen testowych i demonstracyjnych) i włączonym wyłączniku awaryjnym, sprawdzane dwukrotnie; najwyżej pięć zgłoszeń; tylko wyraźnie rozpoznane formularze kontaktowe bez obowiązkowych danych osobowych; bez domen urzędów, placówek edukacyjnych, klinik, gabinetów, policji i sądów; model językowy nie może niczego dopuścić; wiadomość testowa bez danych osobowych, oznaczona, z odesłaniem do strony o crawlerze i do opt-out	R9	`scanner/src/worker.js`; `scanner/src/classify.js`; `scanner/src/active.js`
Ścieżki przeglądarki: tylko GET i HEAD, niebezpieczne adresy zablokowane, zmyślone wartości nie opuszczają przeglądarki, obrazy z zaczernionymi polami wprowadzania	R3 (dla tych obrazów), R9	`scanner/src/browser.js`
Sprawdzanie plików: tylko zweryfikowane domeny, jedno pobranie na ścieżkę, najwyżej 8 KB, treść nigdy nie jest zapisywana	R9	`cfg/dateien_lib.php`
Druga sonda: domyślnie wyłączona; otrzymywałaby tylko stałą listę nieszkodliwych informacji, podpisaną	odbiorcy	`cfg/formular_probe_lib.php`
Skan za logowaniem: tylko zweryfikowana domena, płatny plan, właściciel lub administrator, potwierdzenie „konto testowe”; szyfrowanie kluczem publicznym serwera skanującego, z powiązaniem z domeną; dane dostępowe nigdy nie są wyświetlane, zapisywane w dziennikach ani wydawane przez interfejs; przekazanie tylko przez standardowe wejście; pole w zleceniu natychmiast czyszczone, pozostałości po godzinie; brak zrzutów ekranu, brak zgłoszeń, brak adresów wylogowania i usuwania, przerwanie przy CAPTCHA; ostateczne usunięcie z nadpisaniem	R8	`cfg/login_lib.php`; `scanner/src/login.js`; `scanner/src/geheim.js`; `scanner/src/worker.js`
Kontrola doręczenia: domyślnie wyłączona; pobieranie odczytuje tylko nagłówki i 8 KB, bez oznaczania jako przeczytane; treść i adres odwiedzającego nigdy w bazie danych; każda pobrana wiadomość jest usuwana, także nieprzypisane; przypisania usuwane po 180 dniach; dowód tylko na podstawie kopii dokładnie tego testu	R1, R2	`cfg/zustellung_lib.php`
Ochrona roju: tylko domeny, sieci IP wyłączone; minimalne progi; wyjątki dla dużych usług i domen Klientów; kwarantanna zamiast usuwania; lista codziennie od nowa; zgłoszenia usuwane po 30 dniach	R11	`cfg/swarm_lib.php`
Model językowy na własnym serwerze, bez prawa do wysyłania	R10	`scanner/src/classify.js`
Plan działań: lokalne generowanie na podstawie wybranych ustaleń, bez zrzutów ekranu i wpisanych wartości pól w poleceniu; ograniczona liczba ustaleń i długość notatek; oczyszczony zwykły tekst o ograniczonej długości; widoczny komunikat o AI, miarodajne poszczególne ustalenia; bez automatycznych zmian strony internetowej i rozstrzygania o wyniku punktowym lub ocenie	Częściowo R10; nadal możliwe są błędne wskazówki i przypadkowe dane osobowe	`cfg/plan_lib.php`; `www/report.php`
Sygnały przez Telegram zawierają tylko stałe zdanie bez zmiennych	odbiorcy	`cfg/check_lib.php`
Cotygodniowa próba odtworzenia kopii zapasowej, z alertem w razie niepowodzenia	dostępność	`cfg/backup_lib.php`; `srv/cron_status.php`

9.2 Częściowo – istnieje, ale jeszcze nie osiąga swojego celu

Środek	Dlaczego jeszcze nie działa w pełni
„Oczyszczone” zrzuty ekranu	Zaczernione są tylko obrazy ze ścieżek przeglądarki. Obrazy crawlera – strona główna i elementy formularzy – oraz obraz strony odpowiedzi przy sprawdzeniu aktywnym nie są (R3).
Terminy dla danych sprawdzeń	Działają dla sprawdzeń anonimowych, potencjalnych klientów i Klientów; nie dla sprawdzeń wewnętrznych i nieopublikowanych badań; niewyjaśnione adnotacje o nieprawidłowościach bez terminu (R4).
Usuwanie kopii kontrolnych	Działa w naszym widoku skrzynki. Przy przerwaniu przebiegu wiadomości pozostają; co dostawca skrzynki przechowuje we własnych kopiach zapasowych, nie zostało sprawdzone (R2).
Ochrona danych dostępowych przy skanie za logowaniem	Silna w spoczynku i w usłudze sprawdzania; w drodze do strony internetowej nie: `http` jest dopuszczony, błędy certyfikatów są pomijane (R8).
Potwierdzenie uprawnień do domeny	Jest sprawdzane jeden raz, a potem obowiązuje na zawsze; nazwy hosta domeny z potwierdzeniem uprawnień nie można jednak zmienić, więc potwierdzenie nie przechodzi na inny host (R7).
Informowanie osób, których dane dotyczą	Dla operatorów istnieje przez stronę o crawlerze, identyfikator, Politykę prywatności i opt-out; dla odwiedzających przy kontroli doręczenia zależy od tego, czy Klient przejmie gotowy tekst; aplikacja tego nie sprawdza.
Prośba do Klientów, aby nie przekazywać szczególnych kategorii danych w kopii kontrolnej	Widnieje w dokumentach prawnych, ale nie jest wspierana technicznie: aplikacja przy konfiguracji nie pyta o rodzaj strony internetowej i nie ostrzega przy domenach, które wyglądają na związane ze zdrowiem, prawem lub edukacją (R1).

9.3 Planowane – niewdrożone

Środek	Przeciwdziała	Priorytet
Ścieżka usuwania dla sprawdzeń wewnętrznych: usuwać sprawdzenia bez domeny i bez raportu po stałym terminie (propozycja: 30 dni); usuwać dane surowe badania najpóźniej po stałym terminie od jego zakończenia, także bez publikacji (propozycja: 90 dni); jednorazowo usunąć zasób 85 sprawdzeń z 369 obrazami	R4	Najpierw
Udostępnić kontrolę doręczenia dopiero wtedy, gdy umowa z dostawcą skrzynki zostanie zawarta, miejsca przechowywania, dalsze podmioty przetwarzające i okresy przechowywania kopii zapasowych zostaną udokumentowane, a podstawa przekazywania dla dostawcy skrzynki wyjaśniona i rekordy MX naszej domeny będą wskazywać bezpośrednio na skrzynkę; do tego czasu pozostawić funkcję zablokowaną w systemie produkcyjnym	R2	Najpierw
Sprawdzić zabezpieczenie pobierania ze skrzynki w systemie produkcyjnym i udokumentować je, zanim kontrola doręczenia zostanie udostępniona	R2	Najpierw
Skan za logowaniem tylko przez `https` i z ważnym certyfikatem; odrzucać adresy `http`; błędy certyfikatu przy logowaniu jako powód przerwania	R8	Najpierw
Nie zapisywać wartości pól ukrytych za logowaniem (tylko nazwa, typ i długość) – już tak wdrożone, bez dalszego kroku	R8	załatwione
Ograniczyć kopię kontrolną do wiadomości testowych tam, gdzie używana jest wtyczka lub rozszerzenie: ukryta kopia tylko dla zgłoszeń z naszym identyfikatorem testu	R1	Wysoki
Nie zapisywać domeny nadawcy prawdziwych wiadomości i nie umieszczać jej w alertach, jeżeli nie jest ani domeną strony internetowej, ani domeną znanej usługi wysyłkowej; zamiast tego w alercie „obca domena nadawcy”	R1	Wysoki
Ostrzeżenie przy konfiguracji kontroli doręczenia dla domen, które wyglądają na związane ze zdrowiem, prawem, sprawami socjalnymi lub edukacją, ze wskazaniem na własną ocenę skutków Klienta	R1	Wysoki
Regularnie odnawiać potwierdzenie uprawnień do domeny (propozycja: przed każdym sprawdzeniem aktywnym sprawdzać, czy wpis DNS, metatag, plik lub połączenie z wtyczką nadal istnieją; w przeciwnym razie kontynuować pasywnie i powiadomić Klienta)	R7	Wysoki
Nie wykonywać już zrzutów strony głównej albo tylko z zaczernionymi obrazami i twarzami; ograniczyć obrazy formularzy do elementu formularza (jak obecnie) i maskować pola wprowadzania jak przy ścieżkach przeglądarki	R3	Wysoki
Wskazówka w interfejsie sprawdzenia potencjalnego klienta: wysłanie krótkiego podsumowania bez zapytania e-mailem lub telefonicznie jest także między przedsiębiorcami marketingiem bezpośrednim i wymaga uprzedniej zgody (art. 398 PKE; w Niemczech § 7 ust. 2 UWG, przy czym w przypadku połączeń telefonicznych do przedsiębiorców wystarcza domniemana zgoda)	R6	Wysoki
Infrastruktura: zakończyć utwardzanie administrowania serwerami; zaszyfrowana kopia zapasowa w drugiej lokalizacji; połączenia w sieci wewnętrznej szyfrowane w całości; dalsze wzmocnienie rozdzielenia serwera skanującego i aplikacji	R13	Wysoki
Termin dla niewyjaśnionych adnotacji o nieprawidłowościach (propozycja: wyjaśnienie w ciągu 30 dni, w przeciwnym razie usunięcie adresu IP)	R4	Średni
Strona lub formularz, za pomocą którego można zażądać usunięcia domeny z ochrony roju	R11, R14	Średni
Przed włączeniem sieci IP w ochronie roju: nowa wersja tej oceny	R11	Warunek
Ustalenie, czy oprogramowanie modelu językowego zapisuje zapytania, i w razie potrzeby wyłączenie tych dzienników	R10	Niski

9.4 Procedury i decyzje, które należy jeszcze ustalić

Art. 35 ust. 7 lit. d wymaga oprócz zabezpieczeń technicznych także procedur. Te są jeszcze w toku:

Naruszenie ochrony danych. Wykrycie: właściciel, alert o błędach aplikacji, zgłoszenia przez punkt zgłaszania podatności lub contact@lukaswojcik.com. Decyzja o zgłoszeniu do Prezesa UODO w ciągu 72 godzin (art. 33 ust. 1): właściciel. Powiadomienie dotkniętych Klientów jako administratorów: niezwłocznie, w miarę możliwości w ciągu 48 godzin, jak przyrzeczono w Umowie powierzenia przetwarzania danych. Do ustalenia: pisemny opis procedury i pierwsze ćwiczenie; dla kontroli doręczenia dodatkowo sposób ustalenia, których Klientów dotyczy naruszenie u dostawcy skrzynki.
Branże. Do ustalenia: czy kontrola doręczenia ma być oferowana dla stron internetowych z obszaru zdrowia, prawa, spraw socjalnych i edukacji, oferowana z ostrzeżeniem czy wyłączona.
Sprawdzenia wewnętrzne. Do ustalenia: do czego Usługodawca wykorzystuje wewnętrzne sprawdzenia z wiersza poleceń, kto może je tworzyć i jak długo pozostają ich wyniki; oraz czy poza Rejestrem czynności przetwarzania należy je wymienić także w Polityce prywatności.
Badania. Do ustalenia: kto zestawia listy, według jakich źródeł, z jaką maksymalną wielkością, oraz kontrola przed każdym badaniem, czy spełnia ono założenia tej oceny.
Opinia osób, których dane dotyczą (art. 35 ust. 9). Na potrzeby tej wersji nie została zasięgnięta. Art. 35 ust. 9 wymaga zasięgnięcia opinii tylko „w stosownych przypadkach”; według naszej oceny obecnie nie jest to taki przypadek. Operatorzy sprawdzanych stron internetowych i odwiedzający strony Klientów nie mają z nami własnego kanału; celowe zwracanie się do nich byłoby samo w sobie nowym przetwarzaniem ich danych, a usługa nie została jeszcze uruchomiona, więc nie istnieje jeszcze krąg osób, których dane faktycznie dotyczą. Ich interesy są uwzględnione pośrednio: przez robots.txt i opt-out, przez krótkie terminy oraz przez to, że treści kopii kontrolnych nie są zapisywane. Przy każdym przeglądzie zgodnie z pkt 12 ponownie sprawdzamy, czy zasięgnięcie opinii jest stosowne, np. przez informacje zwrotne na stronie o crawlerze lub u Klientów korzystających z kontroli doręczenia.

10. Ryzyko szczątkowe i uprzednie konsultacje na podstawie art. 36

Art. 36 ust. 1 wymaga uprzednich konsultacji z organem nadzorczym, jeżeli ocena skutków wykaże, że przetwarzanie powodowałoby wysokie ryzyko, gdyby administrator nie zastosował środków w celu zminimalizowania tego ryzyka. Pytanie nie brzmi więc, czy stwierdzono wysokie ryzyko – stwierdzono cztery – lecz czy wysokie ryzyko pozostaje po wdrożeniu środków.

W odniesieniu do przetwarzań, dla których formexposed jest administratorem (V1–V4, V7), wysokie ryzyka R4 i R13 można usunąć zwykłymi środkami: ścieżką usuwania i oczyszczeniem zasobu, zaszyfrowaną kopią zapasową poza siedzibą i utwardzeniem dwóch serwerów. Przy środkach z pkt 9.3 spadają one do poziomu niskiego do średniego. R3, R5, R6 i R7 są na poziomie średnim i przy zaproponowanych środkach spadają do niskiego. Ochrona roju bez sieci IP pozostaje na poziomie niskim do średniego. Uprzednie konsultacje dla tej części nie są wskazane, jeżeli środki oznaczone jako „najpierw” i „wysoki” zostaną wdrożone przed uruchomieniem. Jeżeli któryś z tych środków nie zostanie wdrożony przed uruchomieniem, dla danego przetwarzania pozostaje wysokie ryzyko. Wówczas przetwarzanie to zostanie podjęte dopiero po wdrożeniu środka albo po uprzednich konsultacjach z Prezesem UODO zgodnie z art. 36 ust. 1.

W odniesieniu do kontroli doręczenia (V6) sytuacja jest inna, i to z powodu, którego żaden środek nie usuwa całkowicie: o tym, co pisze odwiedzający, decyduje on sam. Przy zawartej umowie, zabezpieczonym pobieraniu, ograniczeniu do wiadomości testowych tam, gdzie to możliwe, i rezygnacji z domeny nadawcy R2 spada do niskiego, a R1 do średniego. U Klientów, których odwiedzający zwykle podają dane z art. 9, R1 może mimo to pozostać wysokie. Obowiązek konsultacji spoczywa wtedy na Kliencie jako administratorze, a nie na formexposed. Naszą rekomendacją dla takich Klientów jest skonfigurowanie kopii kontrolnej nie dla ogólnego formularza kontaktowego, lecz tylko dla formularzy bez treści wrażliwych, albo rezygnacja z kontroli doręczenia.

Ryzyko szczątkowe, nazwane uczciwie. Obecnie, przy środkach z pkt 9.1, cztery ryzyka są na poziomie wysokim: R1 i R2 (kontrola doręczenia), R4 (dane sprawdzeń bez ścieżki usuwania) i R13 (infrastruktura). Przy środkach z pkt 9.3 R2, R4 i R13 spadają do poziomu niskiego do średniego. R1 pozostaje na poziomie średnim i trwale zależy od decyzji podejmowanych przez Klientów. Żadne z pozostałych ryzyk po wdrożeniu środków nie przekracza poziomu średniego.

Art. 36 nie jest karą, a konsultacja nie jest przyznaniem się do winy. Jest drogą, którą rozporządzenie przewiduje na sytuację, w której użyteczny proces niesie ryzyko, nad którym administrator nie panuje w pełni. Klient, który chce korzystać z kontroli doręczenia dla wiadomości zawierających informacje o zdrowiu, znajdzie tu fakty potrzebne do tej decyzji.

11. Czego Klienci potrzebują do własnej oceny skutków (art. 28 ust. 3 lit. f)

W odniesieniu do kontroli doręczenia i skanu za logowaniem administratorem jest Klient. Ta strona dostarcza mu opisu (pkt 6.5 i 6.6), ryzyka z naszej perspektywy (R1, R2, R8) i stanu środków (pkt 9). Na następujące pytania może odpowiedzieć tylko on:

Co piszą moi odwiedzający? Czy należy się spodziewać, że przez formularz będą przychodzić informacje o zdrowiu, religii, pochodzeniu, przynależności do związków zawodowych, orientacji seksualnej, przestępstwach lub dotyczące dzieci? Wtedy ocena skutków dla kopii kontrolnej jest z reguły wymagana, a kopię kontrolną dla tego formularza należy przemyśleć.
Czy potrzebuję kopii kontrolnej dla wszystkich wiadomości? Do wykazania, że nasza wiadomość testowa dociera, wystarczy kopia tej wiadomości. Tam, gdzie formularz na to pozwala, ustawić ukrytą kopię tylko dla wiadomości testowych.
Jak poinformuję moich odwiedzających? Wymaga tego Umowa powierzenia przetwarzania danych; gotowy tekst do Twojej polityki prywatności opisuje drogę kopii i naszą rolę.
Jaką mam podstawę prawną? Nasza propozycja tekstu wskazuje art. 6 ust. 1 lit. f (niezawodne otrzymywanie zapytań). Dla danych z art. 9 sama ta podstawa nie wystarcza.
Jakie kanały alertów wybieram? Alerty ze sprawdzania autentyczności mogą podawać domenę nadawcy. Kto wysyła alerty do komunikatorów spoza UE, przekazuje ją tam.
W odniesieniu do skanu za logowaniem: Czy konto testowe jest rzeczywiście kontem testowym z najmniejszymi niezbędnymi uprawnieniami? Czy strona logowania jest dostępna tylko przez https? Czy konto testowe widzi dane innych użytkowników? Jeśli tak: na których ze wskazanych podstron?
Kiedy usuwam? Kontrolę doręczenia i konto testowe można w każdej chwili wyłączyć i usunąć; konto testowe jest przy tym ostatecznie nadpisywane.

Dalsze dokumenty do oceny Klienta: Umowa powierzenia przetwarzania danych, środki techniczne i organizacyjne, lista dalszych podmiotów przetwarzających i Rejestr czynności przetwarzania. Na pytania dotyczące poszczególnych faktów odpowiadamy pod adresem contact@lukaswojcik.com.

12. Przegląd, wersja i zatwierdzenie

Art. 35 ust. 11 wymaga przeglądu, czy przetwarzanie odbywa się zgodnie z oceną skutków, przynajmniej gdy zmienia się ryzyko. Dokonujemy przeglądu tej oceny co najmniej raz w roku, a ponadto przed każdym z następujących zdarzeń; każde z nich uruchamia nowy pomiar, a nie tylko lekturę:

uruchomienie działalności produkcyjnej, z liczbami z systemu produkcyjnego zamiast deweloperskiego;
pierwsze włączenie kontroli doręczenia w systemie produkcyjnym i zawarcie umowy z dostawcą skrzynki;
włączenie sieci IP w ochronie roju;
pierwsze badanie i każde badanie z większą listą niż poprzednie;
włączenie drugiej sondy lub nowego odbiorcy na ścieżce sprawdzania;
nowe zastosowanie modelu językowego, wykraczające poza zastosowania objęte tą oceną; plan działań według priorytetów w płatnych raportach jest dodanym zastosowaniem i wymaga przeglądu oceny;
każda zmiana dotycząca zrzutów ekranu, terminów lub przesłanek sprawdzeń aktywnych.

Punkt	Wpis
Administrator	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polska · NIP 7252266190 · contact@lukaswojcik.com
Właściwy organ nadzorczy	Prezes Urzędu Ochrony Danych Osobowych (Prezes UODO), ul. Moniuszki 1A, 00-014 Warszawa, Polska
Inspektor ochrony danych	Niewyznaczony; ocena na podstawie art. 37 w pkt 4
Podstawa faktów	Kod źródłowy aplikacji i usługi sprawdzania, schemat bazy danych, liczby wierszy i ustawienia systemu deweloperskiego, według pomiaru z 11 października 2026 r., wyłącznie w trybie odczytu
Powiązane dokumenty	Polityka prywatności, Umowa powierzenia przetwarzania danych, Środki techniczne i organizacyjne, Podmioty przetwarzające dalej, Rejestr czynności przetwarzania, AI Act UE, Dopuszczalne użytkowanie i nadużycia, FormExposedBot, Opt-out
Wersja	1.1 z 23 października 2026 r.; uzupełnienie faktów dotyczące lokalnego etapu planu działań do pierwszej wersji z 11 października 2026 r.
Przeglądy zgodnie z art. 35 ust. 11	23 października 2026 r.: przegląd kodu źródłowego dodanego lokalnego etapu planu działań. Do odpowiednich części dodano dane wejściowe, przechowywanie, role, doradczy charakter wyniku i wdrożone zabezpieczenia; nie stwierdza się zakończenia pomiarów produkcyjnych ani ustalenia nowego poziomu ryzyka szczątkowego. Wcześniejsze pomiary z 11 października 2026 r. i poniższy stan zatwierdzenia pozostają bez zmian. Dalsze przeglądy są wpisywane tutaj z datą, powodem i wynikiem.
Zatwierdzenie	Jeszcze niezatwierdzona. Zatwierdzenie przez właściciela po weryfikacji prawnej i po podjęciu decyzji co do środków z pkt 9.3 i kwestii z pkt 9.4. Zewnętrznej porady w zakresie ochrony danych dotychczas nie zasięgnięto.

Jedna obserwacja końcowa należy do dokumentu, a nie do pisma przewodniego. Te części formexposed, które najgłębiej sięgają w cudze obszary – zgłoszenia testowe i logowanie z cudzymi danymi dostępowymi – są zbudowane z największą ostrożnością: dwie bramki, twarde limity, szyfrowanie, które wyklucza nawet nas. Ryzyka tej oceny leżą przeważnie gdzie indziej: w tym, co przychodzi przy okazji – prawdziwe wiadomości w ukrytej kopii, ludzie na zrzucie ekranu, sprawdzenia, których już nikt nie usuwa. To korzystny punkt wyjścia, ponieważ to, co dzieje się przy okazji, można wyeliminować bez zmiany usługi.

Jak możemy pomóc?