Środki techniczne i organizacyjne

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: 22 października 2026 r.

Środki w rozumieniu art. 32 RODO, za pomocą których LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polska, chroni usługę formexposed. Niniejsza strona stanowi załącznik nr 2 i integralną część umowy powierzenia przetwarzania danych.

1. Zakres i zasada

Środki dotyczą wszystkich danych przetwarzanych przez usługę: danych, które przetwarzamy w imieniu naszych Klientów (opisanych w umowie powierzenia przetwarzania danych), oraz danych, za które sami jesteśmy administratorem, na przykład kont Klientów i dzienników. Nie ma odrębnych poziomów ochrony dla obu kategorii; to, co chroni konto, chroni także dane powierzone.

Układ według art. 32 ust. 1 RODO. Pseudonimizacja i szyfrowanie (lit. a) są opisane w punkcie 4; zdolność do ciągłego zapewnienia poufności, integralności, dostępności i odporności systemów (lit. b) – w punktach 3, 5, 6 i 7; zdolność do szybkiego przywrócenia dostępności danych i dostępu do nich w razie incydentu (lit. c) – w punkcie 7.1; procedura regularnego testowania, mierzenia i oceniania skuteczności (lit. d) – w punkcie 9. Środki dobraliśmy według ryzyk opisanych w naszej ocenie skutków dla ochrony danych, uwzględniając stan wiedzy technicznej i koszt wdrażania.

Zasada: zmierzone, a nie zamierzone. Opisujemy tu tylko to, co rzeczywiście zostało wdrożone w kodzie lub w eksploatacji. To, co jest zaplanowane, ale jeszcze niewdrożone, zostało wyraźnie oznaczone w punkcie 10 jako „planowane”. Środek, którego tu brakuje, nie istnieje w sposób dorozumiany.

Celowo nie podajemy nazw komputerów, adresów wewnętrznych, portów, nazw użytkowników ani wersji oprogramowania. Nikomu nie pomagają one ocenić środków, za to mogą pomóc komuś, kto chce je obejść. Kto potrzebuje ich do kontroli na podstawie umowy powierzenia przetwarzania danych, otrzyma je w ramach tej kontroli z zastrzeżeniem poufności, w zakresie, w jakim są one do niej niezbędne.

2. Budowa usługi

Usługa działa na dwóch własnych serwerach Usługodawcy w Polsce, które znajdują się w tej samej sieci wewnętrznej:

Serwer WWW z bazą danych. Udostępnia aplikację, utrzymuje bazę danych, wysyła powiadomienia i wykonuje kopie zapasowe danych. Tylko on jest skonfigurowany do przyjmowania żądań z internetu.
Serwer skanujący. Wykonuje w przeglądarce sprawdzenia cudzych i własnych stron internetowych oraz obsługuje model językowy, który klasyfikuje pojedyncze formularze, podsumowuje ustalenia ze skanu w formie planów działań według priorytetów dla kont płatnych i uzupełnia kod w funkcji „Fix it for me”. Nie jest skonfigurowany do przyjmowania żądań z internetu, lecz sam pobiera zlecenia z serwera WWW i odsyła tam wyniki.

W eksploatacji nie uczestniczy żaden dostawca hostingu, centrum danych ani chmury, a do zewnętrznej usługi AI nic nie trafia. Kto otrzymuje dane, opisuje strona Podmioty przetwarzające dalej.

3. Poufność

3.1 Kontrola dostępu fizycznego

Serwery znajdują się w niedostępnych publicznie pomieszczeniach Usługodawcy w Polsce. Dostęp ma wyłącznie właściciel (informacja Usługodawcy). Dokładny adres lokalizacji celowo nie został tu podany.

3.2 Kontrola dostępu: logowanie do usługi

Hasła są przechowywane wyłącznie jako skrót (hash) wytworzony standardową metodą PHP (bcrypt). Jeżeli metoda standardowa się zmieni, skrót jest odnawiany przy następnym logowaniu. Przy próbie logowania na nieznany adres serwer mimo to oblicza skrót, aby czas odpowiedzi nie zdradzał, czy konto istnieje. Podobnie odpowiedź na prośbę o zresetowanie hasła ani swoją treścią, ani czasem trwania nie zdradza, czy konto istnieje; e-maile do resetowania hasła trafiają na ten sam adres najwyżej trzy razy na godzinę. Nowe hasła muszą mieć co najmniej dziesięć znaków i nie mogą przekraczać 72 bajtów (UTF-8), ponieważ bcrypt nie uwzględnia większej liczby bajtów. Zmiana hasła wylogowuje wszystkie pozostałe urządzenia; zresetowanie hasła za pomocą linku wylogowuje wszystkie urządzenia, a link działa tylko raz.
Blokada po nieudanych próbach. Nieudane logowania są zliczane dla każdego adresu IP; po zbyt wielu w krótkim czasie (obecnie ośmiu w ciągu 15 minut) logowanie z tego adresu zostaje czasowo zablokowane. Udane logowanie zeruje ten licznik. Próby są usuwane po siedmiu dniach. Ponadto przed każdym sprawdzeniem hasła liczona jest jedna próba dla konta (w przypadku nieznanego adresu – dla wpisanego adresu) i dla adresu IP, łącznie z udanymi: obecnie najwyżej osiem na konto z tego samego adresu IP i 80 na adres IP w ciągu 15 minut; dla konta łącznie ze wszystkich adresów obowiązuje znacznie wyższy limit, chroniący przed rozproszonym zgadywaniem. Nieudane próby z obcego adresu nie blokują więc już właścicielowi dostępu do konta. Liczniki te zawierają wyłącznie klucz HMAC, bez adresu e-mail ani adresu IP w postaci jawnej, i wygasają wraz ze swoim oknem czasowym. Jeżeli magazyn liczników jest niedostępny, logowanie zostaje odrzucone, a nie przepuszczone. W ten sam sposób ograniczone są potwierdzenie hasła przed zmianą hasła lub adresu, włączeniem lub wyłączeniem drugiego składnika, przekazaniem obszaru roboczego, eksportem danych i usunięciem konta (pięć prób na konto w ciągu 15 minut), rejestracje (dziesięć na adres IP w ciągu godziny) oraz hasła portali klienta (dziesięć prób na portal i adres IP, 50 na portal w ciągu 15 minut).
Drugi składnik. Każde konto może włączyć logowanie z kodem jednorazowym zgodnie z RFC 6238 (TOTP). Związany z tym sekret jest przechowywany w bazie danych w postaci zaszyfrowanej; klucz nie znajduje się w bazie danych, więc sam zrzut bazy nie wystarczy. Przyjęty kod nie zadziała po raz drugi. Dziesięć kodów odzyskiwania jest przechowywanych wyłącznie jako skrót. Kody jednorazowe i kody odzyskiwania są ograniczone do dziesięciu prób na konto w ciągu 15 minut, także podczas konfiguracji.
Panel administracyjny tylko z drugim składnikiem. Panel administracyjny Usługodawcy otwiera się wyłącznie dla kont z włączonym drugim składnikiem. Lista konfiguracyjna zgłasza każde konto administratora bez drugiego składnika.
Sesje. Plik cookie sesji jest niedostępny dla skryptów (HttpOnly), jest wysyłany tylko przez HTTPS (Secure) i nie jest dołączany do żądań z cudzych stron, które mogłyby coś zmienić (SameSite=Lax). Przy logowaniu powstaje nowy identyfikator sesji, aby wcześniej podstawiony identyfikator przestał obowiązywać; serwer nie przyjmuje identyfikatora sesji, którego sam nie wydał. Każde konto widzi swoje zalogowane urządzenia i może je wylogować pojedynczo.
„Pozostań zalogowany” jest dobrowolne i obowiązuje 30 dni, lecz nie dla kont z uprawnieniami administracyjnymi; logują się one zawsze hasłem i drugim składnikiem. Token składa się z dwóch części; część weryfikująca jest przechowywana w bazie danych wyłącznie jako skrót. Każde użycie zastępuje go nowym, a nawet przy jednoczesnych żądaniach każdy token działa tylko raz, dzięki czemu skradziony token wychodzi na jaw najpóźniej przy następnej rzeczywistej wizycie.
Linki w e-mailach. Linki do potwierdzenia adresu i do resetowania hasła są przechowywane w bazie danych wyłącznie jako skrót. Link do resetowania jest ważny godzinę, link potwierdzający rejestrację – 72 godziny, a link potwierdzający zmieniony adres – 24 godziny. Zmiana adresu e-mail unieważnia niewykorzystany link do resetowania hasła.
Interfejsy. Klucze API, kody połączenia rozszerzeń i kody wdrożeniowe (rollout) są przechowywane wyłącznie jako skrót. Liczba użyć kluczy API na minutę jest ograniczona; kody połączenia rozszerzeń są ważne 15 minut i tylko jednorazowo.
Ochrona przed botami w publicznych formularzach (rejestracja, logowanie, hasło, sprawdzenie, narzędzie do nagłówków, opt-out, wsparcie i kontakt): Google reCAPTCHA, ładowana dopiero przy wysyłaniu. Przyjmowana jest wyłącznie ważna odpowiedź Google z wystarczającym wynikiem dla dokładnie tej akcji, której dotyczy formularz; jeżeli Google nie odpowie w ciągu trzech sekund, wysłanie zostaje odrzucone. Szczegóły zawiera Polityka prywatności.

3.3 Kontrola dostępu: administrowanie serwerami

Serwer dostępny z internetu przepuszcza przez filtr pakietów tylko usługi, które oferuje, i automatycznie blokuje adresy po powtarzających się nieudanych logowaniach do administracji serwerem.
Automatyczne procesy między serwerami korzystają z odrębnych kluczy o ściśle ograniczonych uprawnieniach. Klucz, którym serwer WWW dostarcza nowe wersje skanera, może na serwerze skanującym wykonywać tylko stałą listę poleceń i kopiować dane wyłącznie do katalogu skanera; interaktywne logowanie za jego pomocą nie jest możliwe, a każde odrzucone polecenie jest rejestrowane. Podobnie serwer skanujący może zapisywać zrzuty ekranu tylko w określonym katalogu serwera WWW.
Proces, który udostępnia stronę internetową, nie ma ani uprawnień do zapisu w instalacji produkcyjnej, ani klucza do serwera skanującego. Wdrożenie uruchomione w panelu administracyjnym jedynie odkłada zlecenie, które wykonuje odrębny proces.
Sekrety, takie jak dostępy do bazy danych i klucze, znajdują się w plikach konfiguracyjnych poza udostępnianym katalogiem i nie są kopiowane przy wdrożeniu. Konfiguracja serwera WWW nie jest rozsyłana przez interfejs WWW.

3.4 Kontrola uprawnień: prawa w usłudze

Role. W każdym obszarze roboczym istnieją role właściciela, administratora i czytelnika. Zmiany, usuwanie, zapraszanie i zapisywanie danych dostępowych są zastrzeżone dla właścicieli i administratorów; zmieniać role i usuwać członków może tylko właściciel. Zaproszenie jest ważne tylko tak długo, jak osoba zapraszająca pozostaje właścicielem lub administratorem. Czytelnicy widzą adresy webhooków i kanałów czatu tylko skrócone do nazwy hosta, ponieważ już sam adres pozwala wysyłać wiadomości do kanału. Weryfikacja odbywa się na serwerze, nie tylko w interfejsie.
Powiązanie z obszarem roboczym. Domeny i ustawienia są dostępne tylko dla członków obszaru roboczego. Do każdego sprawdzenia usługa tworzy raport pod losowym linkiem, którego nie da się odgadnąć; wyniki i zrzuty ekranu sprawdzenia są dostępne przez ten link bez logowania, a zrzuty ekranu tylko razem z linkiem do ich raportu. Link jest widoczny na koncie i w alarmach; kto go przekazuje dalej, przekazuje raport.
Żądania zmieniające stan wymagają tokenu bezpieczeństwa przypisanego do sesji (ochrona CSRF), porównywanego w stałym czasie.
„Widok jako Klient”. Na potrzeby wsparcia Usługodawca może zobaczyć aplikację tak, jak widzi ją Klient. Widok kończy się po godzinie, blokuje zmiany hasła, adresu, drugiego składnika, urządzeń, subskrypcji, eksportu i usunięcia, na ten czas zamyka panel administracyjny i jest rejestrowany. Jego zakończenie całkowicie wylogowuje Usługodawcę; do panelu administracyjnego wraca on tylko po ponownym zalogowaniu hasłem i drugim składnikiem. Klient widzi go w swoim eksporcie danych.
Administracja. Uprawnienia administracyjne ma tylko kilka wyraźnie upoważnionych kont; każde zresetowanie drugiego składnika przez administrację jest rejestrowane.

3.5 Kontrola rozdzielenia

Dane Klientów są logicznie rozdzielone według obszarów roboczych. Każda ścieżka odczytu i zapisu w obszarze dostępnym po zalogowaniu uwzględnia to powiązanie; raporty są ponadto dostępne przez swój link (punkt 3.4).
Rozwój i eksploatacja działają w odrębnych instalacjach z odrębnymi bazami danych i odrębnymi użytkownikami baz danych. Użytkownik środowiska rozwojowego nie ma dostępu do bazy danych eksploatacji. Prawdziwe dane Klientów nie są kopiowane do środowiska rozwojowego; pracujemy tam na wygenerowanych danych przykładowych.
Skaner ma dla każdego środowiska własne dane dostępowe z uprawnieniami tylko do danych potrzebnych do jego zleceń. Nie może odczytywać kont, rozliczeń ani dzienników.
Na serwerze WWW działają także inne usługi tego samego Usługodawcy. Mają one własne bazy danych i własnych użytkowników baz danych bez dostępu do danych tej usługi.

4. Szyfrowanie, pseudonimizacja i minimalizacja danych

4.1 Dane dostępowe do skanu za logowaniem

Na potrzeby tej funkcji Klient zapisuje nazwę użytkownika i hasło konta testowego. Są to najbardziej wrażliwe dane w usłudze i dlatego są chronione inaczej niż wszystko inne:

Serwer WWW szyfruje je przy zapisie publicznym kluczem serwera skanującego (ECIES: X25519 z kluczem jednorazowym dla każdego rekordu, HKDF-SHA256, AES-256-GCM). Klucz prywatny istnieje wyłącznie na serwerze skanującym. Serwer WWW, baza danych i kopie zapasowe zawierają tylko szyfrogram; nawet my nie możemy go tam odczytać.
Każdy rekord jest kryptograficznie powiązany ze swoją domeną. Po przepięciu do innej domeny odszyfrowanie się nie powiedzie.
Na potrzeby skanu szyfrogram jest dołączany do zlecenia. Serwer skanujący go odszyfrowuje i przekazuje dane dostępowe kontenerowi sprawdzającemu wyłącznie przez standardowe wejście, nigdy jako parametr wywołania, który byłby widoczny na listach procesów. Gdy tylko serwer skanujący go odczyta, szyfrogram jest usuwany ze zlecenia; pozostałości usuwa proces porządkujący najpóźniej po godzinie.
Dane dostępowe nigdy nie są wyświetlane, nigdy nie są zapisywane w dziennikach, nigdy nie są wydawane przez interfejs API i nie są eksportowane. Interfejs pokazuje tylko pierwszy znak i długość nazwy użytkownika. Usunięcie nadpisuje szyfrogram.
Za logowaniem skaner wyłącznie czyta: żadnego wysyłania, żadnego aktywnego testu, żadnych zrzutów ekranu, żadnych stron do wylogowania, usuwania lub wypowiadania.

4.2 Pozostałe szyfrowanie i skróty

Hasła, kody odzyskiwania, hasła do portali klienta, klucze API, kody połączenia i kody wdrożeniowe, tokeny „Pozostań zalogowany”, identyfikatory sesji na liście urządzeń oraz linki do potwierdzenia i resetowania są przechowywane wyłącznie jako skrót.
Sekrety drugiego składnika są przechowywane w postaci zaszyfrowanej (punkt 3.2).
Nie twierdzimy, że cała baza danych jest szyfrowana w stanie spoczynku. Chronione są pojedynczo wartości wrażliwe, jak opisano powyżej.

4.3 Minimalizacja danych w samej konstrukcji

Kontrola doręczenia: Odczytywane są tylko nagłówki i najwyżej pierwsze 8 KB treści. Do bazy danych trafiają tylko czas, przyporządkowanie, ewentualnie identyfikator zgłoszenia testowego oraz wynik weryfikacji autentyczności (SPF, DKIM, DMARC), nigdy treść ani pełny adres nadawcy. Wynik weryfikacji autentyczności ostatniej wiadomości jest zapisywany przy domenie i nadpisywany przez następną; zawiera adres IP przekazującego serwera pocztowego i domenę e-mail nadawcy. Wiadomość jest usuwana ze skrzynki po udanym przetworzeniu; jeżeli pobranie lub usunięcie się nie powiedzie, następuje to przy następnym udanym przebiegu.
Sprawdzenia: Zapisywana jest budowa formularzy z nazwami pól, typami i etykietami, cechą wymagalności i widoczności, bez wartości; początki wstępnie wypełnionych ukrytych pól (do 24 znaków) i atrybutów data (do 60 znaków) skaner odczytuje tylko w trakcie sprawdzenia i ich nie zapisuje. Zrzuty ekranu z pełnego sprawdzenia nie są zaczerniane; tylko sprawdzenia w przeglądarce zakrywają pola wprowadzania. Adresy odbiorców w formularzach są zapisywane tylko jako domena. Aktywne zgłoszenia testowe zawierają wyłącznie oznaczone teksty testowe bez danych osobowych.
Rozszerzenia dla WordPress i TYPO3 przekazują tylko dzienne liczby i cechy, takie jak inwentarz wtyczek, a w przypadku połączonej wtyczki WordPress na potrzeby ochrony roju (domyślnie włączonej) także domeny linków z odrzuconych wiadomości; żadnych dalszych treści, nazwisk, adresów ani adresów IP odwiedzających. Opcjonalne liczniki błędów formularzy i pól są domyślnie wyłączone.
„Fix it for me”: Wklejony kod jest przetwarzany tylko na czas trwania żądania i nie jest zapisywany.
Pieczęć: Obraz pieczęci na stronach Klientów nie ustawia pliku cookie i nie rozpoczyna sesji.
Komunikaty eksploatacyjne wysyłane na telefon Usługodawcy to stałe teksty bez zmiennych, a więc bez nazwisk, adresów i treści. Powiadomienia o błędach wysyłane e-mailem do Usługodawcy zawierają surowy tekst komunikatu o błędzie, nieoczyszczony i skrócony do 400 znaków; w pojedynczych przypadkach może on zawierać adresy lub linki.
Ochrona roju: Między rozszerzeniami Klientów udostępniane są tylko domeny linków z odpartego spamu; wymiana sieci IP jest wyłączona.
Lokalizacja: Kraj adresu IP jest ustalany na podstawie lokalnego pliku bazy danych; żaden adres nie trafia do usługi geolokalizacyjnej.

5. Ochrona przed nadużyciem skanera

Skaner ładuje cudze strony prawdziwą przeglądarką. Bez ochrony byłby narzędziem, za pomocą którego ktoś z zewnątrz mógłby dotrzeć do naszej sieci wewnętrznej lub innych niepublicznych celów (Server-Side Request Forgery). Dlatego istnieją dwie niezależne warstwy oraz odizolowanie każdego pojedynczego przebiegu.

5.1 Odizolowany przebieg

Każde sprawdzenie działa we własnym kontenerze, który jest następnie usuwany. Działa bez uprawnień administratora, bez dodatkowych uprawnień (capabilities) systemu operacyjnego i bez możliwości rozszerzenia uprawnień. Jego system plików jest tylko do odczytu, z wyjątkiem niewielkich obszarów ulotnych.
Pamięć, liczba procesów i czas działania są ograniczone; przebieg, który przekroczy czas, zostaje zakończony.

5.2 Sieć: dwie warstwy

Pierwsza warstwa, w skanerze: Przed skanem, a następnie dla każdego pojedynczego żądania przeglądarki, także dla przekierowań i treści osadzonych, sprawdzane jest, na jaki adres rozwiązuje się nazwa. Sieci prywatne, lokalne, zarezerwowane i dokumentacyjne (IPv4 i IPv6) są odrzucane, podobnie jak porty inne niż typowe dla WWW. Przeglądarka nie dopuszcza service workerów, a połączenia WebSocket są zamykane, ponieważ jedne i drugie mogłyby ominąć tę kontrolę.
Druga warstwa, w sieci: Kontenery działają we własnej sieci. Reguły zapory pozwalają stamtąd w internecie tylko na połączenia na porty WWW; połączenia do sieci prywatnych, a więc również do naszej sieci wewnętrznej z serwerem WWW i bazą danych, są zablokowane. Wyjątki, których wymaga sam przebieg sprawdzenia, są ograniczone do niezbędnego minimum i opisane w naszej dokumentacji wewnętrznej. Ta warstwa działa także wtedy, gdy nazwa po pierwszym sprawdzeniu zostanie rozwiązana inaczej.

5.3 Pobrania wykonywane przez serwer WWW

Tam, gdzie serwer WWW sam pobiera cudze adresy – przy potwierdzaniu uprawnień do domeny, w narzędziu do nagłówków, przy wyszukiwaniu publicznie dostępnych plików, przy pobraniach pulsu, przy zapytaniach RDAP i przy sprawdzaniu certyfikatów, przy webhookach i alarmach na czat oraz przy opcjonalnym drugim punkcie kontrolnym – obowiązują te same zasady: tylko protokoły WWW na typowych portach WWW (webhooki i alarmy na czat tylko przez HTTPS na porcie standardowym), tylko adresy publiczne, połączenie wyłącznie z dokładnie tym adresem, który wcześniej sprawdzono, aby nazwy nie dało się później przekierować na cel wewnętrzny, przekierowania albo w ogóle nie, albo śledzone ręcznie i za każdym razem ponownie sprawdzane, krótkie limity czasu; przy potwierdzaniu uprawnień do domeny, przy pobraniach pulsu i przy drugim punkcie kontrolnym dla sprawdzeń w przeglądarce także ograniczony rozmiar odpowiedzi.

5.4 Czego skaner nie robi na cudzych stronach

Aktywne zgłoszenia testowe (najwyżej pięć na jedno sprawdzenie) są dla Klientów możliwe tylko dla domen, w przypadku których przedstawiono potwierdzenie uprawnień do domeny (DNS, meta tag, plik lub rozszerzenie); wyjątkiem są jedynie wewnętrzne sprawdzenia naszych własnych domen testowych i demonstracyjnych. Nazwy hosta domeny z potwierdzeniem uprawnień nie można zmienić, aby potwierdzenie nie przeszło na inny host. Wszystko inne jest pasywne: czytanie stron tak jak odwiedzający.
Sprawdzenia w przeglądarce dochodzą do momentu przed wysłaniem i nie wywołują zamówienia, płatności ani zgłoszenia.
Domeny z listy opt-out nie są sprawdzane; trwające monitorowanie kończy się z najbliższym przypadającym sprawdzeniem.

6. Integralność: przekazywanie i wprowadzanie

6.1 Transmisja

Aplikacja jest dostępna z internetu wyłącznie przez HTTPS; przeglądarka otrzymuje polecenie, aby przez rok używać tylko HTTPS (HSTS). Certyfikaty są odnawiane automatycznie.
Dalsze nagłówki ograniczają osadzanie aplikacji w cudzych stronach, zgadywanie typów plików i wysyłanie formularzy do cudzych celów. Polityka Content-Security-Policy pozwala w aplikacji uruchamiać tylko te skrypty, które serwer dopuszcza w danej odpowiedzi; aktualne przeglądarki nie wykonują wstrzykniętych skryptów ani procedur obsługi zdarzeń zapisanych w HTML.
Skrzynka kontroli doręczenia jest odczytywana przez połączenie szyfrowane z weryfikacją certyfikatu.
Webhooki mogą być podpisywane sekretem Klienta (HMAC-SHA256 ze znacznikiem czasu), aby odbiorca mógł sprawdzić pochodzenie i nienaruszoność. Zapytania do opcjonalnego drugiego punktu kontrolnego są podpisywane, a przy sprawdzeniach w przeglądarce także jego odpowiedzi.
Mówimy otwarcie: Połączenia wewnątrz naszej sieci wewnętrznej nie są w całości szyfrowane. Dane dostępowe do skanu za logowaniem pozostają przy tym przez cały czas zaszyfrowane (punkt 4.1).

6.2 Kontrola wprowadzania i dzienniki

Ważne działania w kontach i obszarach roboczych (np. logowanie, zmiany domen, celów alarmów i uprawnień, usunięcia, dostępy w ramach wsparcia) są rejestrowane w dzienniku aktywności wraz z kontem, czasem, adresem IP i krajem oraz usuwane po 365 dniach.
Wywołania stron rejestrowane dla bezpieczeństwa i przeciwdziałania nadużyciom są usuwane po 60 dniach, dzienniki błędów po 90 dniach, treści wysłanych e-maili po 30 dniach. Tokeny dostępu w wywoływanych adresach i stronach odsyłających, na przykład w linkach do raportów lub portali, są w rejestrze wywołań stron zapisywane wyłącznie w postaci zamaskowanej.
Akceptacja dokumentów umownych jest zapisywana wraz z wyświetloną wersją, jej sumą kontrolną, czasem, adresem IP i identyfikatorem przeglądarki.
Protokoły weryfikacji mogą być opatrzone znacznikiem czasu zewnętrznego dostawcy usług znakowania czasem; trafia do niego tylko suma kontrolna treści, nie sama treść.

7. Dostępność i odporność

7.1 Kopia zapasowa

Baza danych jest kopiowana co noc. Kopia zapasowa otrzymuje ostateczną nazwę dopiero po sprawdzeniu jej zawartości: pomyślne zakończenie programu tworzącego kopię, co najmniej jeden rekord, tyle tabel, ile ma baza danych, oraz wiersz końcowy kompletnego przebiegu. Starsze kopie są usuwane dopiero po udanym utworzeniu nowej.
Każda kopia zapasowa jest usuwana po 14 dniach. Miejsce przechowywania znajduje się poza każdym udostępnianym katalogiem; miejsce wewnątrz projektu jest odrzucane.
Próba odtworzenia: Raz w tygodniu najnowsza kopia zapasowa jest wczytywana do jednorazowej bazy danych, porównywana tabela po tabeli z eksploatacją i ponownie usuwana. Wynik jest zapisywany.
Jeżeli kopia zapasowa lub próba się nie powiedzie, Usługodawca otrzymuje powiadomienie e-mailem i na telefon.
Przywrócenie po incydencie: Jeżeli baza danych ulegnie awarii lub dane zostaną uszkodzone, przywracamy najnowszą sprawdzoną kopię zapasową. Zmiany wprowadzone od czasu tej kopii, z reguły najwyżej z jednego dnia, mogą przy tym zostać utracone; jeżeli wykonanie kopii zapasowej się nie powiodło – odpowiednio więcej. Następnie ponownie wykonujemy znane nam późniejsze zlecenia usunięcia (punkt 8). Nie gwarantujemy określonego czasu przywrócenia.
Ograniczenie, mówimy otwarcie: Kopie zapasowe znajdują się obecnie w tej samej lokalizacji co baza danych i nie są odrębnie szyfrowane. Chronią przed błędem obsługi, błędnymi zmianami i uszkodzonymi danymi, ale nie przed utratą samego serwera. Zaszyfrowana kopia w drugiej lokalizacji jest planowana (punkt 10).
Dane dostępowe do skanu za logowaniem są zawarte w kopiach zapasowych wyłącznie jako szyfrogram; sekret drugiego składnika – wyłącznie w postaci zaszyfrowanej, kluczem przechowywanym poza bazą danych.

7.2 Monitorowanie

Proces statusowy co pięć minut sprawdza komponenty usługi, w tym bazę danych, kolejkę oraz sygnał życia skanera, który ten zapisuje regularnie także w stanie bezczynności. Jeżeli komponent ulegnie awarii, wysyłane jest powiadomienie; gdy wróci do działania – odwołanie alarmu.
Straż wzajemna: Proces statusowy nie może zgłosić awarii komputera, na którym sam działa. Dlatego serwer skanujący co minutę sprawdza, czy aplikacja odpowiada, i po kilku kolejnych niepowodzeniach wysyła stały komunikat na telefon Usługodawcy. W drugą stronę serwer WWW monitoruje sygnał życia skanera; czy straż wzajemna działa, pokazuje lista konfiguracyjna.
Alarm o błędach: Rodzaj błędu, który nigdy wcześniej nie wystąpił, jest zgłaszany jednorazowo i natychmiast; przy nagromadzeniu błędów na telefon Usługodawcy trafia tylko pojedynczy sygnał; raz dziennie przychodzi zestawienie. Dzięki temu nie dowiadujemy się o błędzie dopiero od Klienta.
Ograniczenie, mówimy otwarcie: Oba serwery znajdują się w tym samym miejscu. Awaria całej lokalizacji, na przykład zasilania lub łącza internetowego, nie zostanie zgłoszona przez żaden mechanizm powiadamiania, lecz zauważona przez człowieka.

7.3 Zmiany i wdrożenia

Nowe wersje są najpierw budowane i testowane w odrębnym środowisku rozwojowym. Wdrożenie sprawdza wszystkie warunki, zanim zostanie zapisany pierwszy plik, wprowadza zmiany w schemacie bazy danych i pozwala trwającym sprawdzeniom zakończyć się w uporządkowany sposób, zanim skaner zostanie ponownie uruchomiony.
Dla ścieżki nowego Klienta istnieje test dymny (smoke test) przez prawdziwy HTTP, wykonywany po przestawieniach. Nie twierdzimy, że przed każdym pojedynczym wdrożeniem uruchamiany jest automatyczny zestaw testów.

8. Usuwanie i terminy

Przebieg usuwania wykonywany co noc dotrzymuje terminów podanych w Polityce prywatności i w umowie powierzenia przetwarzania danych. Odczytuje te same ustawienia, z których pochodzą liczby w tekstach; w odniesieniu do tych terminów tekst i działanie nie rozjeżdżają się więc.
Wyniki sprawdzeń wraz ze zrzutami ekranu są usuwane po 13 miesiącach (ostatni wynik dla każdej domeny pozostaje), dane liczbowe z rozszerzeń po 13 miesiącach, dzienniki wysyłki alarmów po 90 dniach, zgłoszenia do wsparcia po 24 miesiącach.
Usunięcie domeny usuwa dane domeny, w tym sprawdzenia, formularze, ustalenia, zrzuty ekranu, raporty, zlecenia, cele i dzienniki alarmów, incydenty, dane kontroli doręczenia, dane dostępowe do skanu za logowaniem i potwierdzenia.
Usunięcie konta następuje natychmiast; obszary robocze bez innych członków są usuwane wraz z danymi, obszary robocze z innymi członkami przechodzą na innego członka, w pierwszej kolejności na administratorów, a spośród nich na tego o najdłuższym stażu. Do upływu własnych terminów pozostają dzienniki, których wpisy zachowują dawny numer konta, niewskazujący już na żadne istniejące konto, w tym wpis o usunięciu, a ponadto wysłane e-maile, dowód zawarcia umowy, zgłoszenia do wsparcia, raporty ze sprawdzeń potencjalnych klientów (do 90 dni) i dane rozliczeniowe w Stripe; szczegóły zawiera Polityka prywatności.
W kopiach zapasowych usunięte dane pozostają do czasu wygaśnięcia tych kopii po 14 dniach. Selektywne usuwanie w kopii zapasowej nie jest przeprowadzane; jeżeli kopia zostanie odtworzona, znane późniejsze zlecenia usunięcia są ręcznie wykonywane ponownie.

9. Organizacja i przegląd

Osoby: Usługę prowadzi obecnie osobiście właściciel. Inne osoby otrzymują dostęp tylko po zobowiązaniu do zachowania poufności i tylko w niezbędnym zakresie, a dane przetwarzają wyłącznie na nasze polecenie (art. 29 i art. 32 ust. 4 RODO).
Dalsze podmioty przetwarzające: Korzystamy z nich wyłącznie po sprawdzeniu ich gwarancji i na podstawie umowy zgodnej z art. 28 ust. 4 RODO oraz wymieniamy je na stronie Podmioty przetwarzające dalej; szczegóły reguluje umowa powierzenia przetwarzania danych.
Naruszenia ochrony danych: Jeżeli naruszenie ochrony danych osobowych dotyczy danych powierzonych, zgłaszamy je Klientowi bez zbędnej zwłoki, w miarę możliwości w ciągu 48 godzin; szczegóły reguluje umowa powierzenia przetwarzania danych.
Punkt zgłaszania luk bezpieczeństwa: Zgłoszenia przyjmujemy na stronie Bezpieczeństwo oraz przez plik /.well-known/security.txt.
Lista konfiguracyjna i startowa: W panelu administracyjnym lista mierzy stan ustawień istotnych dla bezpieczeństwa, na przykład kopii zapasowej, administratorów bez drugiego składnika, konfiguracji poczty i sygnałów życia, oraz pokazuje odstępstwa.
Przegląd tych środków (art. 32 ust. 1 lit. d RODO): przy każdej istotnej zmianie usługi, po każdym incydencie bezpieczeństwa, a poza tym co najmniej raz w roku. Oceniamy przy tym, czy środki są skuteczne i nadal odpowiadają ryzykom, a wynik utrwalamy w nowej wersji tej strony lub – jeżeli nic się nie zmienia – datą przeglądu w punkcie 11. Na bieżąco stan ujętych w niej ustawień mierzy lista kontrolna konfiguracji i uruchomienia.
Audyty zewnętrzne: Zewnętrzne testy penetracyjne nie są obecnie zlecone i nie posiadamy żadnych certyfikacji bezpieczeństwa. Piszemy o tym, aby nikt ich nie zakładał.

10. Planowane, jeszcze niewdrożone

Poniższe punkty nie są przyrzeczonymi środkami, dopóki nie zostaną tu wskazane jako wdrożone w nowej wersji:

Kopia zapasowa w drugiej lokalizacji: zaszyfrowana kopia nocnej kopii zapasowej poza serwerem, aby nawet całkowita utrata serwera nie prowadziła do utraty danych.
Drugi punkt kontrolny: Niezależne potwierdzanie sprawdzeń w przeglądarce z drugiej lokalizacji jest przygotowane w usłudze, ale nie zostało uruchomione. Bez niego nie ma potwierdzenia z drugiego miejsca.
Utwardzanie administracji serwerami: Prace są kontynuowane. Szczegółów nie podajemy publicznie z powodów wskazanych w punkcie 1.

11. Stan i wersja

Wersja 1.1 · Stan na: 22 października 2026 r. · w razie rozbieżności między wersjami językowymi rozstrzyga wersja polska zamiast niemieckiej; poza tym bez zmian.
Wersja 1.0 · Stan na: 11 października 2026 r. · pierwsza wersja jako odrębna strona; dotychczas załącznik nr 2 do umowy powierzenia przetwarzania danych. W porównaniu z dotychczasowym załącznikiem sprostowano: próba odtworzenia odbywa się co tydzień, kopie zapasowe znajdują się na tym samym serwerze, automatyczny zestaw testów przed każdym wdrożeniem nie jest uruchamiany, połączenia w sieci wewnętrznej nie są w całości szyfrowane. Nowo opisano: szyfrowanie danych dostępowych do skanu za logowaniem, izolację skanera, straż wzajemną i alarm o błędach.
Zmiany są publikowane z nowym numerem wersji tutaj oraz w zestawieniu Zmiany dokumentów umownych; w przypadku osłabienia środków obowiązuje termin zapowiedzi przewidziany w umowie powierzenia przetwarzania danych.
W razie rozbieżności między wersjami językowymi rozstrzyga wersja polska.

Jak możemy pomóc?