Technická a organizační opatření

Tento dokument je zveřejněn v několika jazycích. V případě rozporu mezi jazykovými verzemi je závazná polská verze.

Verze 1.1 · Poslední aktualizace: 22. října 2026

Opatření podle čl. 32 GDPR, kterými LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polsko, chrání službu formexposed. Tato stránka je součástí Smlouvy o zpracování osobních údajů jako příloha 2.

1. Rozsah a zásada

Opatření se vztahují na všechny údaje zpracovávané službou: na údaje, které zpracováváme jménem našich Zákazníků (popsané ve Smlouvě o zpracování osobních údajů), i na údaje, u nichž jsme správcem sami, například zákaznické účty a protokoly. Pro obě skupiny neexistují samostatné úrovně ochrany; co chrání účet, chrání i údaje zpracovávané jako zpracovatel.

Struktura podle čl. 32 odst. 1 GDPR. Pseudonymizace a šifrování (písm. a)) jsou popsány v oddílu 4; trvalá důvěrnost, integrita, dostupnost a odolnost systémů (písm. b)) v oddílech 3, 5, 6 a 7; schopnost včas obnovit dostupnost po incidentu (písm. c)) v oddílu 7.1; proces pravidelného testování, posuzování a hodnocení účinnosti (písm. d)) v oddílu 9. Opatření jsme zvolili na základě rizik popsaných v našem Posouzení vlivu na ochranu osobních údajů s přihlédnutím ke stavu techniky a nákladům na provedení.

Zásada: změřeno, nikoli zamýšleno. Uvádí se zde pouze to, co bylo skutečně zavedeno v kódu nebo v provozu. Co je plánováno, ale dosud nezavedeno, je výslovně uvedeno jako „plánováno“ v oddílu 10. Opatření, které zde chybí, není mlčky zavedeno.

Názvy strojů, interní adresy, porty, uživatelská jména a verze softwaru záměrně neuvádíme. Nikomu nepomohou opatření posoudit, ale pomohou tomu, kdo je chce obejít. Kdo je potřebuje pro audit podle Smlouvy o zpracování osobních údajů, obdrží je v rámci tohoto auditu pod závazkem mlčenlivosti, v rozsahu nezbytném pro audit.

2. Struktura služby

Služba běží na dvou vlastních serverech poskytovatele v Polsku, které se nacházejí ve stejné interní síti:

Webový server s databází. Poskytuje aplikaci, uchovává databázi, odesílá oznámení a zálohuje data. Pouze on je nastaven tak, aby přijímal požadavky z internetu.
Skenovací server. Provádí kontroly webů třetích stran i vlastních webů v prohlížeči a provozuje jazykový model, který klasifikuje jednotlivé formuláře a doplňuje kód ve funkci „Fix it for me“. Není nastaven tak, aby přijímal požadavky z internetu, ale své úlohy si sám vyzvedává z webového serveru a výsledky tam vrací.

Do provozu není zapojen žádný poskytovatel hostingu, datového centra ani cloudu a nic neodchází k externí službě AI. Které třetí strany dostávají údaje, je uvedeno na stránce Další zpracovatelé.

3. Důvěrnost

3.1 Kontrola fyzického přístupu

Servery se nacházejí v prostorách poskytovatele v Polsku, které nejsou veřejně přístupné. Přístup má pouze vlastník (podle prohlášení provozovatele). Přesnou adresu umístění zde záměrně neuvádíme.

3.2 Kontrola přístupu: přihlášení do služby

Hesla se ukládají pouze jako hash pomocí standardní metody PHP (bcrypt). Změní-li se standardní metoda, hash se při dalším přihlášení obnoví. Při pokusu o přihlášení s neznámou adresou server přesto vypočítá hash, aby doba odezvy neprozradila, zda účet existuje. Stejně tak odpověď na žádost o obnovení hesla neprozrazuje svým zněním ani svou dobou trvání, zda účet existuje; e-maily pro obnovení se na stejnou adresu odesílají nejvýše třikrát za hodinu. Nová hesla musí mít alespoň deset znaků a nesmějí přesáhnout 72 bajtů (UTF-8), protože bcrypt další bajty nezohledňuje. Změna hesla odhlásí všechna ostatní zařízení; obnovení přes odkaz odhlásí všechna zařízení a odkaz je platný pouze jednou.
Zablokování po neúspěšných pokusech. Neúspěšná přihlášení se počítají pro každou IP adresu; po příliš mnoha v krátké době (v současnosti osm za 15 minut) se přihlášení z této adresy dočasně zablokuje. Úspěšné přihlášení toto počítadlo vynuluje. Pokusy se mažou po sedmi dnech. Navíc se před každým ověřením hesla započítá jeden pokus na účet (u neznámé adresy na zadanou adresu) a na IP adresu, včetně úspěšných pokusů: v současnosti nejvýše osm na účet ze stejné IP adresy a 80 na IP adresu za 15 minut; pro každý účet napříč všemi adresami dohromady platí výrazně vyšší limit, proti distribuovanému hádání. Neúspěšné pokusy z jiné adresy proto již vlastníka z účtu nezablokují. Tato počítadla obsahují pouze klíč HMAC, žádnou e-mailovou ani IP adresu v čitelné podobě, a vypršejí se svým časovým oknem. Není-li úložiště počítadel dostupné, přihlášení se odmítne, nikoli propustí. Stejný druh limitu platí pro potvrzení hesla před změnou hesla nebo adresy, zapnutím nebo vypnutím druhého faktoru, převodem pracovního prostoru, exportem dat a smazáním účtu (pět pokusů na účet za 15 minut), pro registrace (deset na IP adresu za hodinu) a pro hesla klientských portálů (deset pokusů na portál a IP adresu, 50 na portál za 15 minut).
Druhý faktor. Každý účet si může zapnout přihlašování jednorázovým kódem podle RFC 6238 (TOTP). Tajemství k tomu se ukládá v databázi šifrovaně; klíč se v databázi neukládá, takže samotný výpis databáze nestačí. Přijatý kód podruhé neplatí. Deset záchranných kódů se ukládá pouze jako hash. Jednorázové a záchranné kódy jsou omezeny na deset pokusů na účet za 15 minut, i během nastavování.
Administrační oblast pouze s druhým faktorem. Administrační oblast provozovatele se otevře pouze účtům se zapnutým druhým faktorem. Kontrolní seznam nastavení hlásí každý administrátorský účet bez druhého faktoru.
Relace. Cookie relace nemohou číst skripty (HttpOnly), odesílá se pouze přes HTTPS (Secure) a neodesílá se s požadavky z cizích webů, které by mohly něco změnit (SameSite=Lax). Při přihlášení se vytvoří nové ID relace, takže předem podstrčené ID již neplatí; server nepřijme ID relace, které sám nevydal. Každý účet vidí svá přihlášená zařízení a může je jednotlivě odhlásit.
„Zůstat přihlášen“ je volitelné a platí 30 dní, nikoli však pro účty s administrátorskými právy; ty se vždy přihlašují heslem a druhým faktorem. Token se skládá ze dvou částí; ověřovací část se v databázi ukládá pouze jako hash. Každé použití jej nahradí novým, a i při souběžných požadavcích platí každý token pouze jednou, takže odcizený token se odhalí nejpozději při další skutečné návštěvě.
Odkazy v e-mailech. Odkazy pro potvrzení adresy a obnovení hesla se v databázi ukládají pouze jako hash. Odkaz pro obnovení platí jednu hodinu, odkaz pro potvrzení registrace 72 hodin, odkaz pro potvrzení změněné adresy 24 hodin. Změní-li se e-mailová adresa, otevřený odkaz pro obnovení pozbude platnosti.
Rozhraní. Klíče API, připojovací kódy rozšíření a kódy pro zavádění se ukládají pouze jako hash. Klíče API lze použít jen omezeně mnohokrát za minutu; připojovací kódy rozšíření platí 15 minut a pouze jednou.
Ochrana proti botům na veřejných formulářích (registrace, přihlášení, heslo, kontrola, nástroj pro hlavičky, opt-out, podpora a kontakt): Google reCAPTCHA, která se načte až při odeslání. Přijímá se pouze platná odpověď od Googlu s dostatečným skóre přesně pro akci formuláře; neodpoví-li Google do tří sekund, odeslání se odmítne. Podrobnosti jsou v Zásadách ochrany osobních údajů.

3.3 Kontrola přístupu: správa serverů

Server dostupný z internetu pomocí paketového filtru povoluje pouze služby, které nabízí, a po opakovaných neúspěšných přihlášeních ke správě serveru adresy automaticky blokuje.
Automatizované procesy mezi servery používají vlastní klíče s úzce omezenými právy. Klíč, kterým webový server doručuje nové verze skeneru, smí na skenovacím serveru spouštět pouze pevně daný seznam příkazů a smí pouze kopírovat, a to jen zápisem, do adresáře skeneru; interaktivní přihlášení s ním není možné a každý odmítnutý příkaz se protokoluje. Obdobně smí skenovací server zapisovat snímky obrazovky pouze do určitého adresáře na webovém serveru.
Proces, který obsluhuje web, nemá ani oprávnění k zápisu do produkční instalace, ani klíč pro skenovací server. Nasazení spuštěné v administrační oblasti pouze založí úlohu, kterou provede samostatný běh.
Tajemství, jako jsou přístupové údaje k databázi a klíče, se uchovávají v konfiguračních souborech mimo obsluhovaný adresář a při nasazení se nekopírují. Konfigurace webového serveru se přes webové rozhraní nešíří.

3.4 Kontrola oprávnění: práva v rámci služby

Role. Každý pracovní prostor má role vlastník, administrátor a čtenář. Změny, mazání, zvaní a ukládání přihlašovacích údajů jsou vyhrazeny vlastníkům a administrátorům; pouze vlastník smí měnit role a odebírat členy. Pozvánka platí jen tak dlouho, dokud je osoba, která ji odeslala, stále vlastníkem nebo administrátorem. Čtenáři vidí adresy webhooků a chatovacích kanálů pouze zkrácené na hostitele, protože samotná adresa umožňuje do kanálu psát. Kontrola probíhá na serveru, nikoli jen v rozhraní.
Vazba na pracovní prostor. Domény a nastavení jsou dostupné pouze členům pracovního prostoru. Pro každou kontrolu Služba vytvoří zprávu pod náhodným odkazem, který nelze uhodnout; výsledky a snímky obrazovky kontroly jsou přes tento odkaz dostupné bez přihlášení, snímky obrazovky pouze spolu s odkazem jejich zprávy. Odkaz se zobrazuje v účtu a v upozorněních; kdo jej předá dál, předává dál i zprávu.
Požadavky měnící stav vyžadují bezpečnostní token pro každou relaci (ochrana CSRF), který se porovnává v konstantním čase.
„Zobrazit jako zákazník“. Pro účely podpory může provozovatel vidět aplikaci tak, jak ji vidí Zákazník. Zobrazení skončí po jedné hodině, blokuje změny hesla, adresy, druhého faktoru, zařízení, předplatného, exportu a smazání, mezitím uzavírá administrační oblast a je protokolováno. Jeho ukončení provozovatele úplně odhlásí; do administrační oblasti se provozovatel může vrátit pouze opětovným přihlášením heslem a druhým faktorem. Zákazník je vidí ve svém exportu dat.
Správa. Administrátorská práva má jen několik výslovně oprávněných účtů; každé obnovení druhého faktoru správou se protokoluje.

3.5 Kontrola oddělení

Údaje zákazníků jsou logicky odděleny podle pracovního prostoru. Každá cesta čtení a zápisu v přihlášené oblasti s sebou tuto vazbu nese; zprávy jsou navíc dostupné přes svůj odkaz (oddíl 3.4).
Vývoj a provoz běží v oddělených instalacích s oddělenými databázemi a oddělenými databázovými uživateli. Vývojový uživatel nemá přístup k produkční databázi. Skutečné zákaznické údaje se do vývoje nekopírují; tam pracujeme s generovanými ukázkovými daty.
Pro každé prostředí má skener vlastní přístupové údaje s právy pouze k údajům, které potřebuje pro své úlohy. Nemůže číst účty, fakturaci ani protokoly.
Na webovém serveru běží i další služby téhož poskytovatele. Mají vlastní databáze a vlastní databázové uživatele bez přístupu k údajům této služby.

4. Šifrování, pseudonymizace a minimalizace údajů

4.1 Přihlašovací údaje pro kontrolu za přihlášením

Pro tuto funkci ukládá Zákazník uživatelské jméno a heslo testovacího účtu. Jde o nejcitlivější údaje ve službě, a proto jsou chráněny jinak než vše ostatní:

Při uložení je webový server zašifruje veřejným klíčem skenovacího serveru (ECIES: X25519 s jednorázovým klíčem pro každý záznam, HKDF-SHA256, AES-256-GCM). Soukromý klíč existuje pouze na skenovacím serveru. Webový server, databáze a zálohy obsahují pouze šifrový text; ani my jej tam nedokážeme přečíst.
Každý záznam je kryptograficky vázán na svou doménu. Při přesunu na jinou doménu dešifrování selže.
Pro kontrolu se šifrový text připojí k úloze. Skenovací server jej dešifruje a přihlašovací údaje předá kontrolnímu kontejneru pouze přes standardní vstup, nikdy jako argument příkazového řádku, který by byl viditelný ve výpisech procesů. Jakmile jej skenovací server přečte, šifrový text se z úlohy smaže; běh uklidí případné zbytky nejpozději po jedné hodině.
Přihlašovací údaje se nikdy nezobrazují, nikdy neprotokolují, nikdy nevydávají přes API a neexportují se. Rozhraní ukazuje pouze první znak a délku uživatelského jména. Jejich odebrání šifrový text přepíše.
Za přihlášením skener pouze čte: žádné odesílání, žádný aktivní test, žádné snímky obrazovky, žádné stránky pro odhlášení, smazání nebo zrušení.

4.2 Další šifrování a hashe

Hesla, záchranné kódy, hesla klientských portálů, klíče API, připojovací kódy a kódy pro zavádění, tokeny „Zůstat přihlášen“, ID relací v seznamu zařízení a odkazy pro potvrzení a obnovení se ukládají pouze jako hash.
Tajemství pro druhý faktor se ukládají šifrovaně (oddíl 3.2).
Netvrdíme, že je celá databáze v klidovém stavu šifrována. Citlivé hodnoty jsou chráněny jednotlivě, jak je popsáno výše.

4.3 Minimalizace údajů již při návrhu

Kontrola doručení: Čtou se pouze hlavičky a nejvýše prvních 8 KB textu. Do databáze se dostane pouze čas, přiřazení, případně ID testovacího odeslání a výsledek kontroly pravosti (SPF, DKIM, DMARC), nikdy obsah ani úplná adresa odesílatele. Výsledek kontroly pravosti nejnovějšího e-mailu se uchovává u domény a další jej přepíše; obsahuje IP adresu doručujícího poštovního serveru a e-mailovou doménu odesílatele. E-mail se po úspěšném zpracování ze schránky smaže; selže-li načtení nebo mazání, stane se tak při dalším úspěšném běhu.
Kontroly: Struktura formulářů se ukládá s názvy polí, typy a popisky, atributy povinnosti a viditelnosti, bez hodnot; začátky předvyplněných skrytých polí (do 24 znaků) a datových atributů (do 60 znaků) skener čte pouze během kontroly a neukládá je. Snímky obrazovky z úplné kontroly nejsou začerněny; vstupní pole zakrývají pouze kontroly v prohlížeči. Adresy příjemců formulářů se ukládají pouze jako doména. Aktivní testovací odeslání obsahují pouze označené testovací texty bez osobních údajů.
Rozšíření pro WordPress a TYPO3 předávají pouze denní čísla a charakteristiky, jako je soupis pluginů, a u připojeného pluginu pro WordPress také domény odkazů ze zablokovaných zpráv pro rojovou ochranu (ve výchozím nastavení zapnuto); žádný jiný obsah, žádná jména, adresy ani IP adresy návštěvníků. Volitelné počty chyb formulářů a polí jsou ve výchozím nastavení vypnuty.
„Fix it for me“: Vložený kód se zpracovává pouze po dobu trvání požadavku a neukládá se.
Odznak: Obrázek odznaku na webech zákazníků nenastavuje žádnou cookie a nespouští žádnou relaci.
Provozní oznámení na telefon provozovatele jsou pevné texty bez proměnných, tedy bez jmen, adres nebo obsahu. Chybová oznámení e-mailem provozovateli obsahují surový text chybového hlášení, neočištěný a zkrácený na 400 znaků; v jednotlivých případech může obsahovat adresy nebo odkazy.
Rojová ochrana: Mezi rozšířeními Zákazníků se sdílejí pouze domény z odkazů v zablokovaném spamu; výměna IP sítí je vypnuta.
Poloha: Země IP adresy se určuje z místního databázového souboru; žádná adresa neodchází ke službě geolokace.

5. Ochrana proti zneužití skeneru

Skener načítá stránky třetích stran skutečným prohlížečem. Bez ochrany by to byl nástroj, s jehož pomocí by se někdo zvenčí mohl dostat do naší interní sítě nebo k jiným neveřejným cílům (server-side request forgery). Proto existují dvě nezávislé vrstvy a izolace každého jednotlivého běhu.

5.1 Izolovaný běh

Každá kontrola běží ve vlastním kontejneru, který je poté odstraněn. Běží bez administrátorských práv, bez dodatečných schopností operačního systému a bez možnosti eskalace oprávnění. Jeho souborový systém je s výjimkou malých nestálých oblastí pouze pro čtení.
Paměť, počet procesů a doba běhu jsou omezeny; běh, který překročí čas, je ukončen.

5.2 Síť: dvě vrstvy

První vrstva, ve skeneru: Před kontrolou a poté u každého jednotlivého požadavku prohlížeče, včetně přesměrování a vloženého obsahu, se ověřuje, kam se adresa překládá. Privátní, lokální, rezervované a dokumentační sítě (IPv4 a IPv6) se odmítají, stejně jako jiné porty než ty obvyklé pro web. Prohlížeč nepovoluje service workery a spojení WebSocket se uzavírají, protože obojí by mohlo tuto kontrolu obejít.
Druhá vrstva, v síti: Kontejnery běží ve vlastní síti. Pravidla firewallu povolují spojení odtud do internetu pouze na webových portech; spojení do privátních sítí, včetně naší interní sítě s webovým serverem a databází, jsou blokována. Výjimky, které vyžaduje samotný běh kontroly, jsou omezeny na nezbytné minimum a popsány v naší interní dokumentaci. Tato vrstva se uplatní i tehdy, když se název přeloží jinak až po první kontrole.

5.3 Požadavky odesílané webovým serverem

Tam, kde webový server sám dotazuje adresy třetích stran – pro prokázání kontroly nad doménou, pro nástroj hlaviček, pro hledání odhalených souborů, pro pulsní požadavky, pro dotazy RDAP a pro kontrolu certifikátů, pro webhooky a upozornění v chatu a pro volitelný druhý kontrolní bod –, platí stejná pravidla: pouze webové protokoly na obvyklých webových portech (webhooky a upozornění v chatu pouze přes HTTPS na standardním portu), pouze veřejné adresy, spojení pouze přesně na předem ověřenou adresu, aby název nemohl být dodatečně přesměrován na interní cíl, přesměrování buď vůbec nesledována, nebo sledována pouze ručně a pokaždé znovu ověřena, krátké časové limity; pro prokázání kontroly nad doménou, pro pulsní požadavky a pro druhý kontrolní bod u kontrol v prohlížeči také omezená velikost odpovědi.

5.4 Co skener na webech třetích stran nedělá

Aktivní testovací odeslání (nejvýše pět na kontrolu) existují pro Zákazníky pouze u domén, u nichž byla prokázána kontrola nad doménou (DNS, meta tag, soubor nebo rozšíření); jedinou výjimkou jsou interní kontroly našich vlastních testovacích a ukázkových domén. Název hostitele domény s prokázanou kontrolou nelze změnit, aby prokázání nepřešlo na jiného hostitele. Vše ostatní je pasivní: čtení stránek jako návštěvník.
Kontroly v prohlížeči jdou až do okamžiku před odesláním a nespouštějí žádnou objednávku, platbu ani odeslání.
Domény na seznamu opt-out se nekontrolují; probíhající monitorování končí s nejbližší naplánovanou kontrolou.

6. Integrita: přenos a vstup

6.1 Přenos

Aplikace je z internetu dostupná pouze přes HTTPS; prohlížeč je instruován, aby po dobu jednoho roku používal pouze HTTPS (HSTS). Certifikáty se obnovují automaticky.
Další hlavičky omezují vkládání aplikace do stránek třetích stran, odhadování typů souborů a odesílání formulářů na cíle třetích stran. Zásady zabezpečení obsahu (Content Security Policy) nechávají v aplikaci běžet pouze ty skripty, které server uvolní s příslušnou odpovědí; aktuální prohlížeče nespouštějí vložené skripty ani obslužné rutiny událostí v HTML.
Schránka kontroly doručení se načítá šifrovaným spojením s ověřením certifikátu.
Webhooky lze podepsat tajemstvím Zákazníka (HMAC-SHA256 s časovým razítkem), aby příjemce mohl ověřit původ a integritu. Požadavky na volitelný druhý kontrolní bod jsou podepsány, u kontrol v prohlížeči i jejich odpovědi.
Uvádíme otevřeně: Spojení v rámci naší interní sítě nejsou šifrována v celém rozsahu. Přihlašovací údaje pro kontrolu za přihlášením zůstávají šifrované po celou dobu (oddíl 4.1).

6.2 Kontrola vstupu a protokoly

Důležité akce v účtech a pracovních prostorech (například přihlášení, změny domén, cílů upozornění a práv, mazání, přístupy podpory) se zaznamenávají do protokolu aktivit s účtem, časem, IP adresou a zemí a mažou se po 365 dnech.
Záznamy o přístupech ke stránkám vedené pro účely zabezpečení a předcházení zneužití se mažou po 60 dnech, protokoly chyb po 90 dnech, obsah odeslaných e-mailů po 30 dnech. Přístupové tokeny v požadovaných adresách a refererech, například tokeny odkazů na zprávy nebo portály, se v záznamech o přístupech ke stránkám objevují pouze v maskované podobě.
Přijetí smluvních dokumentů se ukládá se zobrazenou verzí, jejím kontrolním součtem, časem, IP adresou a identifikátorem prohlížeče.
Důkazní protokoly lze opatřit časovým razítkem od externí autority časových razítek; odchází k ní pouze kontrolní součet obsahu, nikoli obsah samotný.

7. Dostupnost a odolnost

7.1 Zálohování

Databáze se zálohuje každou noc. Záloha dostane svůj konečný název až po kontrole jejího obsahu: úspěšné dokončení zálohovacího programu, alespoň jeden záznam, tolik tabulek, kolik má databáze, a závěrečný řádek úplného běhu. Starší zálohy se odstraňují až po úspěšné nové záloze.
Každá záloha se smaže po 14 dnech. Úložiště je mimo jakýkoli obsluhovaný adresář; umístění uvnitř projektu se odmítá.
Test obnovy: Jednou týdně se nejnovější záloha načte do jednorázové databáze, porovná se tabulku po tabulce s produkcí a opět se smaže. Výsledek se ukládá.
Selže-li záloha nebo test, odejde oznámení e-mailem a na telefon provozovatele.
Obnova po incidentu: Selže-li databáze nebo dojde-li k poškození dat, obnovíme nejnovější otestovanou zálohu. Změny provedené od této zálohy, zpravidla nejvýše změny jednoho dne, se přitom mohou ztratit; selhala-li záloha, odpovídajícím způsobem více. Poté znovu provedeme známé pozdější žádosti o výmaz (oddíl 8). Nezavazujeme se k žádné konkrétní době obnovy.
Omezení, uvedené otevřeně: Zálohy jsou v současnosti uloženy na stejném místě jako databáze a nejsou samostatně šifrovány. Chrání před chybami obsluhy, chybnými změnami a poškozenými daty, nikoli před ztrátou samotného serveru. Šifrovaná kopie na druhém místě je plánována (oddíl 10).
Přihlašovací údaje pro kontrolu za přihlášením jsou v zálohách obsaženy pouze jako šifrový text; tajemství druhého faktoru pouze v šifrované podobě, s klíčem mimo databázi.

7.2 Monitorování

Stavový běh každých pět minut kontroluje součásti služby, včetně databáze, fronty a signálu činnosti (heartbeat) skeneru, který skener pravidelně zapisuje i v nečinnosti. Selže-li některá součást, odejde oznámení; zotaví-li se, odejde oznámení o pominutí.
Vzájemný dohled: Stavový běh nemůže ohlásit výpadek stroje, na kterém sám běží. Skenovací server proto každou minutu kontroluje, zda aplikace odpovídá, a po několika po sobě jdoucích selháních to ohlásí pevným textem na telefon provozovatele. Naopak webový server sleduje signál činnosti skeneru; kontrolní seznam nastavení ukazuje, zda vzájemný dohled běží.
Chybový alarm: Typ chyby, který se dosud nikdy nevyskytl, se ohlásí jednou okamžitě; nahromadění chyb vyvolá pouze jeden signál na telefon provozovatele; jednou denně se odesílá přehled. Díky tomu se o chybě nedozvíme až od Zákazníka.
Omezení, uvedené otevřeně: Oba servery jsou na stejném místě. Výpadek celého místa, například napájení nebo internetového připojení, neohlásí žádný mechanismus upozornění, ale všimne si jej člověk.

7.3 Změny a nasazení

Nové verze se nejprve sestavují a testují v odděleném vývojovém prostředí. Nasazení před zápisem prvního souboru ověří všechny předpoklady, provede změny databázového schématu a nechá běžící kontroly řádně doběhnout, než se skener restartuje.
Pro cestu nového Zákazníka existuje smoke test přes skutečné HTTP, který se spouští po přechodech. Netvrdíme, že před každým jednotlivým nasazením běží automatizovaná sada testů.

8. Výmaz a doby uložení

Běh mazání každou noc prosazuje lhůty uvedené v Zásadách ochrany osobních údajů a ve Smlouvě o zpracování osobních údajů. Čte stejná nastavení, ze kterých pocházejí čísla v textech; u těchto lhůt se proto text a chování nerozcházejí.
Výsledky kontrol včetně snímků obrazovky se mažou po 13 měsících (nejnovější pro každou doménu zůstává), čísla z rozšíření po 13 měsících, protokoly doručení upozornění po 90 dnech, požadavky na podporu po 24 měsících.
Odebrání domény smaže údaje domény, včetně kontrol, formulářů, zjištění, snímků obrazovky, zpráv, úloh, cílů a protokolů upozornění, incidentů, údajů o doručení, přihlašovacích údajů pro kontrolu za přihlášením a důkazů.
Smazání účtu proběhne okamžitě; pracovní prostory bez dalších členů se smažou se svými údaji, pracovní prostory s dalšími členy přecházejí na jiného člena, přednostně na administrátory a mezi nimi na toho, kdo je členem nejdéle. Až do vypršení jejich vlastních lhůt zůstávají: protokoly, jejichž záznamy si ponechávají staré číslo účtu, které již neodkazuje na žádný existující účet, včetně záznamu o smazání, dále odeslané e-maily, doklad o uzavření smlouvy, požadavky na podporu, zprávy z kontrol potenciálních klientů (až 90 dní) a fakturační údaje u Stripe; podrobnosti jsou v Zásadách ochrany osobních údajů.
Smazané údaje zůstávají v zálohách do jejich vypršení po 14 dnech. Cílené mazání v rámci zálohy neprobíhá; je-li záloha obnovena, provedou se známé pozdější žádosti o výmaz znovu ručně.

9. Organizace a přezkum

Osoby: Službu v současnosti provozuje vlastník sám. Další osoby získají přístup pouze po zavázání k mlčenlivosti a pouze v nezbytném rozsahu a zpracovávají údaje pouze na základě našich pokynů (čl. 29 a čl. 32 odst. 4 GDPR).
Další zpracovatelé: Zapojujeme je pouze po přezkoumání jejich záruk a na základě smlouvy podle čl. 28 odst. 4 GDPR a uvádíme je na stránce Další zpracovatelé; podrobnosti upravuje Smlouva o zpracování osobních údajů.
Porušení zabezpečení osobních údajů: Týká-li se porušení zabezpečení osobních údajů údajů zpracovávaných jako zpracovatel, ohlásíme je Zákazníkovi bez zbytečného odkladu, je-li to možné do 48 hodin; podrobnosti upravuje Smlouva o zpracování osobních údajů.
Hlášení zranitelností: Hlášení přijímáme na stránce Zabezpečení a prostřednictvím souboru /.well-known/security.txt.
Kontrolní seznam nastavení a spuštění: V administrační oblasti měří kontrolní seznam stav nastavení důležitých pro zabezpečení, jako je záloha, administrátoři bez druhého faktoru, nastavení pošty a signál činnosti, a zobrazuje odchylky.
Přezkum těchto opatření (čl. 32 odst. 1 písm. d) GDPR): při každé významné změně služby, po každém bezpečnostním incidentu a jinak alespoň jednou ročně. Přitom posuzujeme, zda jsou opatření účinná a stále odpovídají rizikům, a výsledek zaznamenáme v nové verzi této stránky, nebo pokud se nic nemění, s datem přezkumu v oddílu 11. Průběžně měří kontrolní seznam nastavení a spuštění stav nastavení, která pokrývá.
Externí audity: V současnosti nejsou zadány žádné externí penetrační testy a neexistují žádné bezpečnostní certifikace. Uvádíme to zde, aby je nikdo nepředpokládal.

10. Plánováno, dosud nezavedeno

Tyto body nejsou závaznými opatřeními, dokud zde nebudou v nové verzi uvedeny jako zavedené:

Záloha na druhém místě: šifrovaná kopie noční zálohy mimo server, aby ani úplná ztráta serveru nevedla ke ztrátě dat.
Druhý kontrolní bod: Nezávislé potvrzení kontrol v prohlížeči z druhého místa je ve službě připraveno, ale není zřízeno. Bez něj neexistuje potvrzení z druhého místa.
Zpevnění správy serverů: Pokračuje. Z důvodů uvedených v oddílu 1 podrobnosti nezveřejňujeme.

11. Stav a verze

Verze 1.1 · Poslední aktualizace: 22. října 2026 · v případě rozporů mezi jazykovými verzemi má přednost polské znění namísto německého; žádná jiná změna.
Verze 1.0 · Poslední aktualizace: 11. října 2026 · první verze jako samostatná stránka; dříve příloha 2 Smlouvy o zpracování osobních údajů. Opraveno oproti předchozí příloze: test obnovy probíhá týdně, zálohy jsou na stejném serveru, před každým nasazením neběží automatizovaná sada testů, spojení v interní síti nejsou šifrována v celém rozsahu. Nově popsáno: šifrování přihlašovacích údajů pro kontrolu za přihlášením, izolace skeneru, vzájemný dohled a chybový alarm.
Změny se zveřejňují s novým číslem verze zde a v přehledu Změny smluvních dokumentů; při jakémkoli oslabení opatření platí lhůta pro oznámení podle Smlouvy o zpracování osobních údajů.
V případě rozporů mezi jazykovými verzemi má přednost polské znění.

Jak vám můžeme pomoci?