Adatvédelmi hatásvizsgálat (a GDPR 35. cikke)

Ez a dokumentum több nyelven jelenik meg. A nyelvi változatok közötti bármilyen eltérés esetén a lengyel változat az irányadó.

1.0 verzió · Utolsó frissítés: 2026. október 16.

1. Miről szól ez, és mi ez az oldal

Ez az oldal a formexposed GDPR 35. cikke szerinti adatvédelmi hatásvizsgálata. Először azt az előzetes kérdést válaszolja meg, hogy egyáltalán szükséges-e adatvédelmi hatásvizsgálat – minden adatkezelési műveletre külön, nem a szolgáltatás egészére. Ahol a válasz igen, elvégzi a 35. cikk (7) bekezdésének a)–d) pontja szerinti értékelést: szisztematikus leírás, szükségesség és arányosság, az érintetteket fenyegető kockázatok és az ezek kezelésére szolgáló intézkedések. Ezt követi a fennmaradó kockázat, a 36. cikk szerinti előzetes konzultáció kérdése és a felülvizsgálat szabályai.

A 35. cikk nem írja elő az adatvédelmi hatásvizsgálat közzétételét. Két okból tesszük közzé. Először: a kézbesítési ellenőrzést vagy a bejelentkezés mögötti ellenőrzést használó Ügyfeleknek saját értékelésükhöz olyan tényekre van szükségük, amelyeket csak mi ismerünk; ezeket adatfeldolgozóként mindenképpen kötelesek vagyunk rendelkezésükre bocsátani (a GDPR 28. cikke (3) bekezdésének f) pontja). Másodszor: bejárónk olyan webhelyeket ellenőriz, amelyek üzemeltetői nem ismernek minket. Lehetőséget kell kapniuk arra, hogy elolvassák, milyen kockázatokat látunk rájuk és az oldalaikon szereplő személyekre nézve, és mit teszünk ezek ellen.

Jogi jelleg. Ez az adatvédelmi hatásvizsgálat az adatkezelő GDPR 35. cikke szerinti dokumentációja, amelyet önként teszünk közzé. Nem része semmilyen szerződésnek, és nem minősül az Ügyfelekkel vagy harmadik felekkel szembeni nyilatkozatnak, garanciának vagy a minőségre vonatkozó megállapodásnak. Azt, hogy milyen szolgáltatásokkal és biztosítékokkal tartozunk az Ügyfeleknek, a Szolgáltatási feltételek, az Adatfeldolgozási szerződés és annak mellékletei szabályozzák; e kötelezettségek tekintetében ezek elsőbbséget élveznek ezzel az oldallal szemben. Az oldal a jelen változat dátumakor fennálló helyzetet írja le. A kockázati besorolások és értékelések a saját álláspontunkat tükrözik, és nem előlegezik meg a felügyeleti hatóság vagy bíróság jogi értékelését; a „tervezettként” megjelölt intézkedések vállalt határidő nélküli szándékok. Az Ügyfelek számára az oldal a saját értékelésük alapja, nem jogi tanácsadás.

Ez az előzetes értékelés első változata. Adatkezelési műveletenként vizsgálja meg, hogy szükséges-e adatvédelmi hatásvizsgálat, és az eredményt a 3.5. szakaszban rögzíti.

Minden tényállításra ugyanaz az elv vonatkozik, mint a többi jogi dokumentumunkban: a mért állapot, nem a szándék. Amit a kód vagy az adatbázis bizonyít, azt itt forráshivatkozással közöljük. Amit nem sikerült igazolni, azt „nem ellenőrzöttként” jelöljük. Ami pusztán terv, azt „tervezettnek” nevezzük. A nyitott kérdéseket nyíltan megnevezzük a tervezett intézkedéssel együtt; az olyan adatvédelmi hatásvizsgálat, amely csak az erősségeket sorolja fel, nem segíti az érintett személyeket.

Fogalmak: üzemeltető az, aki az ellenőrzött webhelyet működteti. Az Ügyfél fiókkal rendelkezik a formexposed szolgáltatásnál. Látogató az, aki az Ügyfél webhelyét, például annak kapcsolatfelvételi űrlapját használja. A forráshivatkozás a forráskódban található fájlt, függvényt vagy beállítást jelenti, a fejlesztői rendszer 2026. október 11-i állapotához mérten.

A nyíltságnak tudatosan meghúzzuk egy határát: saját szervereink védelmének nyitott kérdéseit csak általánosságban írjuk le (R13). Megnevezzük a kockázatot és annak szintjét, de nem a konkrét sérülékenységhez vezető utat; a részleteket kérésre a felügyeleti hatóság rendelkezésére bocsátjuk.

2. Szerepek: kit terhel a kötelezettség, és miért

A 35. cikk a kötelezettséget az adatkezelőre telepíti. A formexposed egyes adatkezelési műveleteknél adatkezelő, másoknál az Ügyfelei adatfeldolgozója, azon adatok tekintetében pedig egyik sem, amelyeket WordPress-bővítményünk és TYPO3-kiegészítőnk az Ügyfél webhelyén tárol. E dokumentum szinte minden kérdésére adott válasz attól függ, hogy melyik szerepre vonatkozik a kérdés. A szerepek elhatárolása az Adatvédelmi tájékoztatót és az Adatfeldolgozási szerződést követi.

Adatkezelési művelet	A formexposed szerepe	Kit terhel a 35. cikk szerinti kötelezettség
Harmadik felek webhelyeinek ellenőrzése az üzemeltetőjük utasítása nélkül: ingyenes ellenőrzés, érdeklődői ellenőrzés ügynökségek számára, tanulmány	Adatkezelő	formexposed
Az ügyfélfiókban található domainek ellenőrzése: felügyelet, aktív tesztbeküldések, böngészős folyamatok, védtelen fájlok, űrlap-állapotjelzés	Adatkezelő az Ügyfél fiók- és ellenőrzési adatai tekintetében; adatfeldolgozó az Ügyfél igazolt webhelyén látható, harmadik felekhez tartozó személyes adatok tekintetében; amíg a domain nem igazolt, adatkezelő, az ingyenes ellenőrzéshez hasonlóan	formexposed a saját részéért; az Ügyfél a webhelyén található, harmadik felekhez tartozó adatokért
Bejelentkezés mögötti ellenőrzés tesztfiókkal	Adatfeldolgozó: a hitelesítő adatok és a bejelentkezés mögötti tartalom az Ügyfél webhelyéhez tartoznak	Az Ügyfél; a formexposed segítséget nyújt
Kézbesítési ellenőrzés ellenőrző másolattal	Adatfeldolgozó	Az Ügyfél; a formexposed segítséget nyújt
Rajvédelem: a blokkolt levélszemétből származó hivatkozásdomainek közös listája	Adatkezelő: számos webhely bejelentéseit egyesítjük, összeállítjuk és terjesztjük a listát	formexposed
Ügyfélfiókok, bejelentkezés, naplók, ügyfélszolgálat, e-mail-küldés, fizetések, igazolási nyilvántartások	Adatkezelő	formexposed
Ügyfélportál és havi jelentés az ügynökség feliratkozóinak	Adatfeldolgozó	Az ügynökség
A bővítmény és a kiegészítő által az Ügyfél webhelyén tárolt adatok (karantén, biztonsági háló, tárolt megkeresések)	Egyik sem: az adatok soha nem hagyják el a webhelyet	A webhely üzemeltetője

Ebből olyan különbségtétel következik, amelyet kifejezetten rögzítünk, mert gyakran mindkét irányban félreértik. Ahol a formexposed adatkezelő, ott magunk végezzük el az értékelést, és viseljük annak eredményét. Ahol adatfeldolgozók vagyunk, ott nem végezhetjük el az Ügyfél helyett annak értékelését, nem dönthetjük el helyette a szükségesség kérdését, és nem konzultálhatunk a nevében a felügyeleti hatósággal a 36. cikk alapján. Amit ott megtehetünk és meg kell tennünk: rendelkezésére bocsátunk mindent, amire szüksége van – az a) pont szerinti leírást, a c) pont szerinti kockázatokra vonatkozó mért tényeket és a d) pont szerinti intézkedések állapotának őszinte felsorolását. A kézbesítési ellenőrzés és a bejelentkezés mögötti ellenőrzés tekintetében ez az oldal pontosan ezt nyújtja.

Az az Ügyfél, aki a kézbesítési ellenőrzésről szóló szakaszokat változatlanul átveszi saját adatvédelmi hatásvizsgálataként, nem végzett hatásvizsgálatot. Csak ő döntheti el, hogy az ellenőrző másolat indokolt-e a saját űrlapjainál, várhatók-e ott különleges személyes adatok, és hogyan tájékoztatja látogatóit. A 11. szakasz összefoglalja, hogy ehhez mit kell tisztázni.

3. Előzetes értékelés: szükséges-e adatvédelmi hatásvizsgálat?

3.1 A 35. cikk (1) bekezdése és a 35. cikk (3) bekezdése

A 35. cikk (1) bekezdése adatvédelmi hatásvizsgálatot ír elő, ha az adatkezelés valamely típusa – különösen új technológiák alkalmazása esetén, figyelembe véve az adatkezelés jellegét, hatókörét, körülményeit és céljait – valószínűsíthetően magas kockázattal jár a természetes személyek jogaira és szabadságaira nézve. A 35. cikk (3) bekezdése három esetet nevez meg, amelyekben ez különösen így van. A három közül egyik sem illik a formexposed szolgáltatásra, és ezt indokolni kell, nem csupán állítani:

• Az a) pont – a természetes személyekre vonatkozó személyes jellemzők szisztematikus és kiterjedt értékelése, amely automatizált adatkezelésen alapul, és amelyre az érintettre nézve joghatással járó vagy őt hasonlóképpen jelentős mértékben érintő döntések épülnek. Űrlapokat és webhelyeket értékelünk, nem emberek személyes jellemzőit. A szolgáltatás nem hoz senkire nézve joghatással járó döntést. Ehhez a rajvédelem áll a legközelebb: a listázott domainre mutató hivatkozást tartalmazó üzenetek a csatlakoztatott webhelyeken karanténba kerülnek. Ez az üzenetre vonatkozó automatizált következmény, nem egy személy kiterjedt értékelése; a 3.3. szakasz „Értékelés vagy pontozás” szempontjánál foglalkozunk vele.
• A b) pont – a 9. cikk szerinti különleges adatok vagy a 10. cikk szerinti büntetőjogi vonatkozású adatok nagy számban történő kezelése. Nem célunk, és nem erre építettük a rendszert. Ilyen adatok mégis eljuthatnak hozzánk egy úton: a kézbesítési ellenőrzés során a valódi látogatói üzenetek ellenőrző másolatában. Ez az egyedi esettől függ, és e rendelkezés értelmében nem nagy léptékű; a kockázatértékelésben azonban figyelembe vesszük (R1).
• A c) pont – nyilvános helyek nagymértékű, módszeres megfigyelése. Ez helyszínek fizikai megfigyelését jelenti, nem nyilvános weboldalak lekérését. Helytelen lenne erre a rendelkezésre hivatkozni egy webhelybejáró kapcsán.

A helyes kiindulópont ezért maga a 35. cikk (1) bekezdése, amelyet a 29. cikk szerinti munkacsoport adatvédelmi hatásvizsgálatról szóló iránymutatásának kilenc szempontja (WP248 rev.01, az Európai Adatvédelmi Testület által jóváhagyva), valamint a lengyel felügyeleti hatóság 35. cikk (4) bekezdése szerinti listája alapján alkalmazunk (3.4. szakasz).

3.2 A WP248 iránymutatás kilenc szempontja

Az iránymutatás kilenc olyan jellemzőt nevez meg, amely valószínűsíthető magas kockázatra utal. Ökölszabályként: ha egy adatkezelési művelet kettőnek megfelel, a legtöbb esetben adatvédelmi hatásvizsgálat szükséges. Az adatkezelő egyedi esetben eltérő következtetésre juthat, de azt meg kell indokolnia és dokumentálnia kell. Fordítva: egyetlen szempont is elegendő lehet. Ezen az oldalon a következő rövid megnevezéseket használjuk:

1. C1 – Értékelés vagy pontozás, beleértve a profilalkotást és előrejelzést, például a munkahelyi teljesítmény, gazdasági helyzet, megbízhatóság vagy magatartás tekintetében.
2. C2 – Joghatással vagy hasonlóképpen jelentős hatással járó automatizált döntéshozatal.
3. C3 – Módszeres megfigyelés, vagyis az érintettek megfigyelésére, nyomon követésére vagy ellenőrzésére használt adatkezelés, hálózatokon keresztül is. Az iránymutatás ezt a szempontot kifejezetten azzal indokolja, hogy az érintettek gyakran nem tudják, ki és milyen célból gyűjti az adataikat.
4. C4 – Érzékeny adatok vagy fokozottan személyes jellegű adatok: a 9. és 10. cikk szerinti különleges kategóriák, továbbá olyan adatok, amelyek nyilvánosságra kerülése jelentősen befolyásolja a mindennapi életet, beleértve az elektronikus kommunikációt, amelynek bizalmasságát védeni kell.
5. C5 – Nagy számban kezelt adatok, az érintettek száma, az adatok mennyisége és köre, az időtartam és a földrajzi kiterjedés alapján mérve.
6. C6 – Adatállományok egyeztetése vagy összevonása, amelyek eltérő adatkezelési műveletekből vagy különböző adatkezelőktől származnak, olyan módon, amelyre az érintettek nem számítanának.
7. C7 – Kiszolgáltatott érintettekre vonatkozó adatok, például munkavállalók, gyermekek, betegek vagy más, egyenlőtlen erőviszonyok között lévő személyek adatai.
8. C8 – Új technológiai vagy szervezési megoldások innovatív használata vagy alkalmazása; a felügyeleti gyakorlat a mesterséges intelligencia használatát rendszeresen e szempont alá sorolja.
9. C9 – Olyan adatkezelés, amely megakadályozza az érintetteket valamely jog gyakorlásában, szolgáltatás igénybevételében vagy szerződés érvényesítésében.

Minden szempontot „teljesül”, „határeset” vagy „nem teljesül” minősítéssel látunk el, és a minősítést a kód alapján indokoljuk. A határeset az összesítésben nem számít teljesültnek, de az eredményben megnevezzük; ha több határeset azonos irányba mutat, az adatkezelési műveletet bevonjuk az értékelésbe.

3.3 Értékelés adatkezelési műveletenként

P1 – Ingyenes ellenőrzés fiók nélkül (bármely harmadik fél webhelyének ellenőrzése kérésre)

A kezdőlapon bárki megadhat egy domaint. A bejáró ezután lekéri a webhely legfeljebb nyolc nyilvános oldalát, beolvassa az űrlapokat, képernyőképeket készít, és jelentést állít elő, amelyet bárki megtekinthet, aki ismeri annak véletlenszerű hivatkozását. A webhely üzemeltetője erről nem szerez tudomást, hacsak nem veszi észre a bejáró azonosítóját a naplóiban.

• C1 – határeset. A jelentés az űrlap védelmét egy szinttel („Védtelen”, „Részben védett”, „Védett”) és pontszámmal értékeli. Korlátolt felelősségű társaságnál ez nem természetes személyt érint. Egyéni vállalkozóknál és szabadúszóknál a domain az egyénhez rendelhető, és a szint így mond valamit a szakmai tevékenysége során tanúsított gondosságról. Az értékelés tárgya azonban műszaki kialakítás, nem egy személy magatartása vagy jellemzői. Ezt határesetként kezeljük.
• C2 – nem teljesül. Az üzemeltetővel kapcsolatban nem születik döntés. Az ellenőrzést kérő személyre IP-címenkénti és munkamenetenkénti korlátok vonatkoznak (cfg/check_lib.php); az elutasított ellenőrzésnek nincs jelentős hatása.
• C3 – nem teljesül. Egyszeri, kérésre történő lekérésről van szó, domainenként és hetente legfeljebb egyszer (cfg/check_lib.php, fc_domain_days beállítás = 7). Nem figyelünk meg embereket. Az a körülmény azonban fennáll, amellyel az iránymutatás a C3 szempontot indokolja: az érintettek semmit nem tudnak az adatkezelésről. Ezt figyelembe vesszük a kockázatértékelésben (R5).
• C4 – nem teljesül. Az űrlap szerkezetét és a megállapításokat tároljuk, nem a megadott értékeket (a scanner/src/crawl.js a látható mezőknél csak az érték hosszát tárolja). Az ellenőrző az előre kitöltött rejtett mezők elejét (legfeljebb 24 karakterig) és az adatattribútumokat (legfeljebb 60 karakterig) csak az ellenőrzés során olvassa be a tokenek és időbélyegek felismeréséhez; ezeket nem tárolja. A képernyőképeken járulékosan emberek és nevek is láthatók lehetnek; egy orvosi rendelő webhelyének képén megjelenik a szakterülete. Ezek nyilvános szakmai adatok, nem egy konkrét személy egészségügyi adatai.
• C5 – határeset. A napi felső korlát 200 elfogadott ellenőrzés (fc_daily_cap), azaz számtanilag legfeljebb körülbelül 73 000 webhely évente. Webhelyenként csak kevés személyes adat keletkezik, és az időtartam rövid (30 nap). A fejlesztői rendszeren végzett mérés szerint az adatállományban 2 névtelen ellenőrzés van. Ma nem teljesül; a tervezett kapacitás alapján határeset.
• C6 – nem teljesül. Az oldalak lekérésén kívül a szolgáltatás az rdap.org RDAP-szolgáltatáson keresztül lekérdezi a domain korát (csak a domainnevet továbbítja; csak a regisztrációs dátumot tárolja, gyorsítótárazva), és DNS-feloldást végez. Ezek a domain műszaki adatai, nem személyekre vonatkozó adatállományok összevonása.
• C7 – nem teljesül.
• C8 – teljesül, gyenge formában. Automatizált böngésző ellenőrzi az oldalakat, és a saját szerverünkön futó nyelvi modell besorolja azokat az űrlapokat, amelyeket a szabályok nem ismernek fel (scanner/src/classify.js). A modell látja az oldal címét, URL-címét, a mezőcímkéket és az űrlap szövegének legfeljebb 400 karakterét. Soha nem tehet egy űrlapot „beküldhetővé”.
• C9 – nem teljesül.

P1 részeredménye: egy szempont gyenge formában (C8), két határeset (C1, C5). Az ökölszabály alapján nincs kötelezettség. Mivel mindkét határeset azonos irányba mutat, és az érintettek semmit nem tudnak az adatkezelésről, a P1 műveletet bevonjuk az értékelésbe.

P2 – Érdeklődői ellenőrzés ügynökségek számára

A Business csomagot használó, saját márkát beállított ügynökség passzívan ellenőriztetheti egy érdeklődő webhelyét. Saját márkája alatt rövid megállapítást és részletes jelentést kap, és a hivatkozást maga adja tovább (cfg/akquise_lib.php). Mi senkivel nem lépünk kapcsolatba.

• C1 – határeset, erősebb, mint a P1 esetében. A rövid megállapítás kifejezett célja, hogy „megnyissa az utat az első beszélgetéshez”. A webhely értékelése így egy személy üzleti célú megkeresésének alapjává válik.
• C5 – nem teljesül. Ügynökségenként és havonta legfeljebb 30 ellenőrzés (prospect_monthly), törlés 90 nap után.
• C8 – teljesül, gyenge formában (ugyanaz a technológia, mint a P1 esetében).
• A többi szempont – nem teljesül. A megállapítás az ügynökség márkájával jelenik meg, de nem kapcsolódik az üzemeltetőre vonatkozó más adatokhoz.

P2 részeredménye: az ökölszabály alapján nincs kötelezettség; ugyanazon okokból vonjuk be, mint a P1 műveletet, továbbá azért, mert a cél – az ügyfélszerzés – önálló kockázatot hordoz (R6).

P3 – „Form Security Index” tanulmány

A tanulmányhoz webhelyek listáját ellenőrizzük passzívan, az ötpercenként futó állapotfolyamat futtatásonként legfeljebb öt nyitott feladatra korlátozva (cfg/studie_lib.php). Csak összesített adatokat teszünk közzé, szegmenseket pedig csak legalább 20, űrlapot tartalmazó webhely esetén (study_min_segment, cfg/studie_lib.php). A nyers adatokat a közzétételkor töröljük (cfg/studie_lib.php).

• C5 – határeset, nagy listáknál teljesül. A kód nem korlátozza a lista méretét; az ütemezési korlátozás számtanilag napi ezernél több ellenőrzést tesz lehetővé. Egy nemzeti piacról készült tanulmány több ezer webhelyet fed le, amelyek közül sokat egyéni vállalkozók működtetnek. Ilyen mérettől kezdve teljesültnek tekintjük a szempontot.
• C8 – teljesül, gyenge formában.
• C1 – nem teljesül. Bár az egyes webhelyeket értékeljük, csak az összesített eredményt tesszük közzé; az értékelés nem arra szolgál, hogy az egyes üzemeltetőkről állítást tegyen.
• A többi szempont – nem teljesül.

P3 részeredménye: a tervezett méretű tanulmányoknál két szempont (C5, C8) teljesül. A tanulmány ezért eléri a küszöböt; a formexposed adatkezelőként elvégzi az értékelést. A fejlesztői rendszeren végzett mérés szerint eddig nem hoztak létre tanulmányt.

P4 – Az ügyfélfiókban található domainek ellenőrzése

Az Ügyfél rendszeresen ellenőrizteti a fiókjában található domaineket. Miután igazolta a domain feletti rendelkezési jogosultságát, ehhez aktív tesztbeküldések (ellenőrzésenként legfeljebb öt), védtelen fájlok keresése és beállított böngészős folyamatok társulnak.

• C3 – nem teljesül. Az ellenőrzés ütemezett és ismétlődő, de az Ügyfél saját webhelyére vonatkozik, és az ő kérésére történik, nem emberek megfigyelése céljából.
• C4 – határeset, nem. A védtelen fájlok keresése legfeljebb az első 8 KB-ot olvassa be olyan elérési utakról, mint a /backup.sql vagy egy hibakeresési napló, hogy a tartalomból megállapítsa, valóban védtelenül elérhető-e a fájl (cfg/dateien_lib.php). Az ilyen részlet tartalmazhat látogatók által megadott űrlapadatokat. Csak a memóriában ellenőrizzük, és soha nem tároljuk; az elérési utat, a típust és a súlyosságot tároljuk.
• C8 – teljesül, gyenge formában.
• A többi szempont – nem teljesül.

P4 részeredménye: nincs kötelezettség. Bevonjuk, mert az aktív tesztbeküldések és a fájlellenőrzés olyan igazolástól függnek, amelyet soha nem újítunk meg (R7).

P5 – Bejelentkezés mögötti ellenőrzés

Igazolt domain esetén az Ügyfél eltárolhat egy tesztfiókot a webhelyéhez. Az ellenőrző ezzel bejelentkezik, és beolvassa a tagi felület legfeljebb öt megadott oldalán található űrlapokat (cfg/login_lib.php, scanner/src/login.js).

• C4 – határeset. A hitelesítő adatok az iránymutatás értelmében nem fokozottan személyes jellegű adatok, de a velük való visszaélés megnyitja a tagi felületet. A webhelytől függően a bejelentkezés mögött bizalmas tartalom lehet, például tagi vagy betegportálon. Ez az Ügyféltől függ, nem tőlünk.
• C8 – nem teljesül. Az automatizált bejelentkezés elterjedt a felügyeleti szolgáltatásokban.
• A többi szempont – nem teljesül.

P5 részeredménye: az ökölszabály alapján nincs kötelezettség. Azoknál az Ügyfeleknél, akiknek tagi felületén bizalmas tartalom látható, ez változhat; a döntés ekkor az ő kezükben van. A biztonsági kockázatok miatt bevonjuk (R8).

P6 – Kézbesítési ellenőrzés ellenőrző másolattal

Az Ügyfél az űrlap levelezési beállításaiban titkos másolati címként megadja a formexposed ellenőrző címét. Ennek következtében minden űrlap-e-mail az ellenőrző postaládánkba is eljut – a tesztüzenetünk és a látogatók minden valódi üzenete egyaránt. Automatizált lekérés olvassa be a fejléceket és az első 8 KB-ot, hozzárendeli az e-mailt, értékeli az SPF, DKIM és DMARC eredményét, majd törli a levelet (cfg/zustellung_lib.php).

• C4 – teljesül. Amit a látogatók a kapcsolatfelvételi űrlapba írnak, az egy vállalkozásnak címzett, tetszőleges tartalmú elektronikus kommunikáció. Orvosi rendelő, ügyvédi iroda, tanácsadó szolgálat vagy iskola webhelyén a 9. cikk szerinti vagy gyermekekre vonatkozó adatokra kell számítani. Az iránymutatás ennél a szempontnál kifejezetten megnevezi a bizalmas elektronikus kommunikációt.
• C3 – határeset, inkább teljesül. Minden üzenetről tervszerűen és folyamatosan másolat készül, amelyet automatikusan értékelünk, anélkül, hogy a feladó ezt észrevenné. A cél a levél útjának ellenőrzése, nem emberek megfigyelése. Az a körülmény azonban, amellyel az iránymutatás ezt a szempontot indokolja – az érintettek nem tudják, ki kapja meg az adataikat –, teljes mértékben fennáll mindaddig, amíg az Ügyfél nem tájékoztatja látogatóit.
• C7 – az Ügyféltől függ. Betegek, ügyvédi irodák ügyfelei, álláspályázók, szülők és tanulók gyakran függőségi viszonyban állnak üzenetük címzettjével.
• C5 – határeset, nem. Az egyes Ügyfeleknél nem nagy léptékű. A formexposed szolgáltatásnál sok Ügyfél másolatai egy postaládába futnak össze; ez az incidens súlyát növeli, nem az adatkezelőnkénti számot.
• A többi szempont – nem teljesül. A domainhez és teszthez való hozzárendelés nem személyekre vonatkozó adatállományok egyeztetése; a technológia nem új.

P6 részeredménye: C4 teljesül, C3 határeset és inkább teljesül, C7 sok tipikus Ügyfélnél teljesül. A tipikus felállásban ezért két vagy több szempont teljesül. Adatvédelmi hatásvizsgálat szükséges – az adatkezelőként eljáró Ügyfél kötelezettségeként. A 6–11. szakasz ehhez biztosítja számára a tényeket.

P7 – Rajvédelem

A csatlakoztatott WordPress-webhelyek naponta egyszer jelentik a védelmi rétegük által megállított üzenetekben szereplő hivatkozások domainjeit. Az a domain, amely hét napon belül legalább három különböző webhelyen, legalább öt találattal jelenik meg, közös listára kerül; a listát visszaküldjük minden csatlakoztatott webhelynek, amelyek ezután karanténba helyezik az adott domainre mutató hivatkozást tartalmazó üzeneteket (cfg/swarm_lib.php).

• C6 – teljesül. Számos, egymástól független webhely, vagyis különböző adatkezelők bejelentéseit egyesítjük, és közös listaként mindegyiküknek visszaküldjük.
• C1 – teljesül, amennyiben a domain természetes személyhez rendelhető. A lista levélszemétforrásként sorolja be a domaint. Az iránymutatás e szempont példájaként említi a közös csalási adatbázissal való összevetést. Az ilyen listákon szereplő domainek többsége vállalkozásokhoz tartozik vagy eldobható domain; azonban egy magánszemély domainje is rákerülhet, jogosan vagy szándékosan elhelyezett hamis bejelentések révén.
• C9 – határeset. A listázott hivatkozást tartalmazó üzenet nem jut el azonnal a címzetthez, hanem a karanténjában marad, amíg fel nem oldja a visszatartást. Nem vész el.
• C2 – nem teljesül. A karantén az üzenetre vonatkozó automatizált következmény, joghatás nélkül, a címzett általi emberi feloldással.
• A többi szempont – nem teljesül. Az IP-hálózatok ki vannak kapcsolva (swarm_ip_enabled = 0, cfg/swarm_lib.php).

P7 részeredménye: két szempont (C6, C1) és egy határeset (C9). A küszöböt eléri; a formexposed adatkezelőként elvégzi az értékelést. Bekapcsolt IP-hálózatok mellett a C1 és C6 korlátozás nélkül teljesülne; bekapcsolásuk az értékelés új változatát igényli (12. szakasz). A fejlesztői rendszeren végzett mérés szerint nincsenek sem bejelentések, sem listabejegyzések.

P8 – Ügyfélfiókok, bejelentkezés, naplók, ügyfélszolgálat, e-mail, fizetések

• C1 és C9 – nem teljesül. Az ingyenes ellenőrzés során észlelt feltűnő viselkedés az IP-címet tartalmazó feljegyzéshez (cfg/check_lib.php) és adott esetben további ellenőrzések elutasításához vezet. Ez csekély hatású visszaélés-megelőzés, nem személyes jellemzők értékelése.
• A többi szempont – nem teljesül. Ezek egy vállalkozásoknak nyújtott szolgáltatás szokásos adatai.

P8 részeredménye: adatvédelmi hatásvizsgálat nem szükséges. Az adatkezelési műveleteket az Adatkezelési tevékenységek nyilvántartása írja le.

P9 – A bővítmény mutatói, mezőhibák, rögzítő, jelvény, ügyfélportál, „Fix it for me”

• A bővítmény és a kiegészítő napi mutatókat, bővítményleltárt és hibakategóriákat továbbít, a WordPress-bővítmény ezenfelül hivatkozásdomaineket is küld a rajvédelemhez (alapértelmezés szerint bekapcsolva) (P7), tartalmat, címeket, neveket vagy látogatói IP-címeket nem; a rögzítő a szelektorokat legfeljebb 15 percig tartja az adminisztrátor böngészőjében. Egyetlen szempont sem teljesül.
• Betöltéskor a jelvény a szokásos kapcsolati adatokat továbbítja a webszerver naplójába, süti nélkül. Egyetlen szempont sem teljesül.
• Az ügyfélportál az ügynökség megbízásából, kettős megerősítéses feliratkozással kezeli a feliratkozók e-mail-címét. Egyetlen szempont sem teljesül.
• A „Fix it for me” a saját szerverünkön futó nyelvi modellel íratja át a beillesztett űrlapkódot; a kódot nem tároljuk. C8 gyenge formában, más semmi.

P9 részeredménye: adatvédelmi hatásvizsgálat nem szükséges.

3.4 A lengyel felügyeleti hatóság 35. cikk (4) bekezdése szerinti listája

Az illetékes hatóság a Személyes Adatok Védelméért Felelős Hivatal elnöke (Prezes Urzędu Ochrony Danych Osobowych, UODO). Az elnök a 2019. június 17-i közleményben tette közzé az adatvédelmi hatásvizsgálatot igénylő adatkezelési művelettípusok listáját (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, Monitor Polski 2019, 666. tétel). A lista a bejegyzéseit a WP248 iránymutatás szempontjaihoz rendeli, példákat ad, és kifejezetten nem teljes körű; nem helyettesíti a 35. cikk (1) bekezdése szerinti értékelést.

Értelmezésünk szerint a listán szereplő alábbi adatkezelési típusok tartalmilag megfelelnek a formexposed adatkezelési műveleteinek:

A lista szerinti adatkezelési típus (átfogalmazva)	Hozzárendelt szempont	Adatkezelési művelet a formexposed szolgáltatásnál	Értékelés
Különböző forrásokból származó adatok elemzésén alapuló összehasonlítás, értékelés vagy következtetés	C6	P7 Rajvédelem	alkalmazandó
Értékelés vagy pontozás, beleértve a profilalkotást	C1	P7 Rajvédelem; P1 és P2 határesetként	a P7 esetében alkalmazandó
Különleges személyes adatok kezelése	C4	P6 Kézbesítési ellenőrzés	az Ügyféltől függően alkalmazandó
Technológiai megoldások innovatív használata vagy alkalmazása	C8	P1–P4 (nyelvi modell a besoroláshoz)	gyenge formában alkalmazandó
Nagy léptékű adatkezelés	C5	P3 Tanulmány	nagy listákra alkalmazandó
Nyilvános helyek módszeres megfigyelése, jellemzők felismerésével is	C3	–	nem alkalmazandó: helyszínekre vonatkozik, nem webhelyekre

Ez a megfeleltetés értelmezés, nem idézet; a jogi felülvizsgálat során össze kell vetni a bejegyzések szövegével. Megerősíti a 3.3. szakasz eredményét, de nem változtat rajta. Tudomásunk szerint az UODO nem tett közzé a 35. cikk (5) bekezdése szerinti listát azokról az adatkezelési műveletekről, amelyekhez nem szükséges adatvédelmi hatásvizsgálat.

3.5 Az előzetes értékelés eredménye

Adatkezelési művelet	Teljesül	Határeset	Eredmény
P1 Ingyenes ellenőrzés	C8 (gyenge)	C1, C5	nem kötelező; bevonva
P2 Érdeklődői ellenőrzés	C8 (gyenge)	C1	nem kötelező; bevonva
P3 Tanulmány	C8 (gyenge), C5 nagy listáknál	–	szükséges (a formexposed kötelezettsége)
P4 Ügyféldomainek ellenőrzése	C8 (gyenge)	C4 (fájlellenőrzés)	nem kötelező; bevonva
P5 Bejelentkezés mögötti ellenőrzés	–	C4	nem kötelező; bevonva; az Ügyfélnél a tartalomtól függ
P6 Kézbesítési ellenőrzés	C4; C7 az Ügyféltől függően	C3 (inkább teljesül), C5	szükséges (az Ügyfél kötelezettsége; ez az oldal a 28. cikk (3) bekezdésének f) pontja szerint segítséget nyújt)
P7 Rajvédelem	C6, C1	C9	szükséges (a formexposed kötelezettsége)
P8 Fiókok, naplók, ügyfélszolgálat, fizetések	–	–	nem szükséges
P9 A bővítmény mutatói, jelvény, portál, „Fix it for me”	C8 (gyenge, csak a „Fix it for me”)	–	nem szükséges

Eredmény a 35. cikk (1) bekezdésére vonatkozóan: A formexposed egyes adatkezelési műveleteihez adatvédelmi hatásvizsgálat szükséges. Szükséges a rajvédelemhez és a tervezett méretű tanulmányokhoz, és a formexposed adatkezelőként végzi el. A kézbesítési ellenőrzéshez a tipikus felállásban szükséges, de az Ügyfél kötelezettségeként; a formexposed biztosítja az alapot. Harmadik felek és saját webhelyek egyéb ellenőrzéseinél nem kötelező. Mégis bevonjuk őket, mert ugyanazt a technológiát használják, mert több határeset azonos irányba mutat, és mert az érintettek – a fiókkal nem rendelkező üzemeltetők és az ellenőrzött oldalakon szereplő személyek – semmit nem tudnak az adatkezelésről. A fiókokhoz, naplókhoz, ügyfélszolgálathoz és fizetésekhez nem szükséges értékelés.

A 6–10. szakasz ezért a P1–P7 műveletekre vonatkozik. Ha egy állítás ezek közül csak egy adatkezelési műveletre érvényes, azt külön jelöljük.

4. Adatvédelmi tisztviselő: a 37. cikk szerinti értékelés

Nem jelöltünk ki adatvédelmi tisztviselőt. A 37. cikk (1) bekezdése az adatkezelőt és az adatfeldolgozót egyaránt kötelezi; a kérdés ezért a sajátunk. A három törvényi eset:

37. cikk (1) bekezdés	Feltétel	Eredmény
a) pont	Közhatalmi szerv vagy egyéb, közfeladatot ellátó szerv	Nem alkalmazandó; az LW IT Solutions Company Lukas Wójcik magán-egyéni vállalkozás.
b) pont	A fő tevékenységek olyan adatkezelési műveleteket foglalnak magukban, amelyek az érintettek rendszeres és szisztematikus, nagymértékű megfigyelését teszik szükségessé	A fő tevékenység webhelyek és űrlapok rendszeres és szisztematikus ellenőrzése és felügyelete. Embereket azonban nem figyelünk meg: a bejáró nem figyeli a viselkedést, a kézbesítési ellenőrzés pedig az e-maileket csak a kézbesítés és a hitelesség szempontjából értékeli. Nem teljesül.
c) pont	A fő tevékenységek a 9. vagy 10. cikk szerinti adatok nagy számban történő kezelését foglalják magukban	A kialakítás szerint nem. Különleges adatok a kézbesítési ellenőrzés ellenőrző másolatán keresztül eljuthatnak hozzánk; ez járulékos, nem fő tevékenység. Nem teljesül.

Értékelésünk szerint ezért nincs kijelölési kötelezettség. Az, hogy a lengyel jog ezen túlmenően a 37. cikk (4) bekezdése alapján előírja-e a kijelölést, a jogi felülvizsgálat nyitott kérdése. Mivel nem jelöltünk ki adatvédelmi tisztviselőt, a 35. cikk (2) bekezdése szerinti tanácskérés nem alkalmazandó. Ha a jogi felülvizsgálat kijelölési kötelezettséget állapít meg, az ezt követően kijelölt adatvédelmi tisztviselő tanácsát e hatásvizsgálat jóváhagyása előtt kikérjük (12. szakasz). Az értékeléssel kapcsolatos kérdésekben a kapcsolattartó a tulajdonos, a contact@lukaswojcik.com címen.

5. E változat módszere, forrásai és korlátai

A dokumentumban szereplő tények az alkalmazás és az ellenőrző forráskódjából, az adatbázissémából, valamint a fejlesztői rendszer 2026. október 11-én mért rekordszámaiból és beállításaiból származnak. Az adatbázishoz és a szerverekhez csak olvasási céllal fértünk hozzá. Ahol egy mérés ellentmond egy szándéknak – beleértve a saját jogi dokumentumainkban szereplő állítást is –, a mérést közöljük. Nem alkalmazunk a 40. cikk szerinti jóváhagyott magatartási kódexet, amelynek betartását a 35. cikk (8) bekezdése szerint figyelembe kellene venni.

• A fejlesztői rendszeren végeztük a mérést. A szolgáltatás még nem indult el. A számok ezért alacsonyak és részben a tesztelésből erednek: 112 ellenőrzés, ebből 110 ügyféldomain nélkül; 432 képernyőkép; 2 domain, ebből 1 igazolt; nincs bekapcsolt kézbesítési ellenőrzés; nincs eltárolt tesztfiók a bejelentkezés mögötti ellenőrzéshez; nincs tanulmány; nincsenek bejelentések a rajvédelemben. A méréseket indulás előtt, majd rendszeres időközönként meg kell ismételni.
• E változatban nem mértük fel, és a jóváhagyás előtt pótolni kell a következőket: az éles rendszer konfigurációja, beleértve azt, hogy be van-e állítva az ellenőrző postaláda, és ha igen, hogyan, valamint hogy ott be van-e állítva a bejelentkezés mögötti ellenőrzés kulcspárja; naplózza-e a kéréseket a nyelvi modell szoftvere; a szerveradminisztráció állapota (R13); az e-mail-szolgáltatóval kötött szerződés.
• Nem lehetett megmérni, hány valódi látogatói üzenet halad majd át az ellenőrző másolaton, és mely ágazatokból érkeznek az Ügyfelek. Mindkettő meghatározza az R1 és R2 súlyát, és az indulás után fel kell mérni.
• A forráshivatkozások a fejlesztői rendszer forráskódjában található fájlokra és függvényekre mutatnak. A leírt működés a döntő, nem a fájlon belüli helye.

Ez a dokumentum tervezet. Az adatkezelő még nem hagyta jóvá (12. szakasz), és két következtetése – a P1 és P3 léptékének értékelése, valamint a kézbesítési ellenőrzés súlya – olyan számoktól függ, amelyek csak az indulás után állnak majd rendelkezésre.

6. (a) Az adatkezelési műveletek és célok szisztematikus leírása

6.1 Az ellenőrzési rendszer felépítése

A formexposed saját szervereken működik Lengyelországban, külső tárhelyszolgáltató nélkül: egy webszerveren az alkalmazás és az adatbázis, egy ellenőrzőszerveren pedig az ellenőrzési szolgáltatás és egy helyi nyelvi modell fut, mindkettő ugyanazon a belső hálózaton. Egy ellenőrzés menete a következő:

1. Az alkalmazás feladatot hoz létre az adatbázisban – a 6.3. szakaszban meghatározott korlátok és tiltások figyelembevételével.
2. Az ellenőrzőszerveren futó ellenőrzési szolgáltatás lekéri a feladatot, másodszor is ellenőrzi a tiltólistát, a kiszolgálóneveket és névtelen ellenőrzéseknél a domain korát, majd kizárólag ehhez a feladathoz elkülönített konténert indít: saját hálózat saját szűrési szabályokkal, különleges jogosultságok nélkül, csak olvasható fájlrendszerrel, memória- és folyamatkorlátokkal, valamint időkorláttal (scanner/src/worker.js).
3. A konténeren belül egy automatizált böngésző legfeljebb nyolc nyilvános oldalt kér le, először a kezdőlapot, majd lehetőleg kapcsolatfelvételi, impresszum- és támogatási oldalakat. Előtte beolvassa a robots.txt fájlt; a FormExposedBotra vagy minden bejáróra vonatkozó, a kezdőlapot lefedő kizárás megszakítja az ellenőrzést, ahogy az elérhetetlen robots.txt vagy a lekérésekor fellépő szerverhiba is (scanner/src/net.js). Az egyes alútvonalakra vonatkozó tiltásokat külön nem veszi figyelembe. Az űrlap-állapotjelzés, az igazolás lekérése, a fejlécellenőrző eszköz és a védtelen fájlok keresése nem olvassa a robots.txt fájlt. A nyolc oldalon felül legfeljebb három oldalt ellenőriz a sütisáv „Elutasítás” gombjára kattintva, legfeljebb három oldalt telefonos nézetben, aktív próbákat végez az igazolt domaineken, és legfeljebb öt oldalt ellenőriz bejelentkezés mögött; az oldalakat egymás után tölti be, nem párhuzamosan. A böngésző minden kérése – az átirányításokat és a beágyazott tartalmat is beleértve – olyan szűrőn halad át, amely elutasítja a magánhálózatokat és az egyéb portokat.
4. A konténer az eredményt és a képernyőképeket ideiglenes könyvtárba írja. Az ellenőrzési szolgáltatás a belső hálózaton átadja az eredményt és a képeket az alkalmazásnak, és törli az ideiglenes könyvtárat, hiba után is (scanner/src/worker.js).
5. Az alkalmazás feldolgozza az eredményt, ügyféldomainek esetében összeveti az előző ellenőrzéssel, és jelenti a változásokat az Ügyfél által beállított célokra.

6.2 Mit tárol a bejáró – és mit nem

Elem	Mit tárolunk	Mit nem tárolunk	Forráshivatkozás
Oldalak	Cím, HTTP-állapot, fejlécek, Content Security Policy, a kérésekben szereplő külső kiszolgálók (legfeljebb 120)	Az oldal tartalma szövegként vagy HTML-ként	scanner/src/crawl.js
Űrlapmezők	Típus, név, címke, helyőrző, kötelező mező, láthatóság, meglévő érték hossza	Mezőértékek; rejtett mezőknél az érték első 24 karakterét csak az ellenőrzés során olvassuk be (tokenek felismeréséhez)	scanner/src/crawl.js
Címzettcímek az űrlapban	csak a domain	a cím	scanner/src/crawl.js
Szkriptek	Leltár ellenőrzőösszeggel; címek és kezdő szöveg a hirdetési és elemzési szolgáltatások fiókazonosítói nélkül	Fiók- és pixelazonosítók	scanner/src/crawl.js
Lehallgatók	mely hirdetési pixelek és rögzítőeszközök töltődnek be a sütisáv „Elutasítás” gombjára kattintás előtt és után, és maszkolják-e a bevitt adatokat	Az e szolgáltatásoknál használt fiókok azonosítói	scanner/src/mitleser.js, scanner/src/einwilligung.js
Űrlapszöveg	legfeljebb 400 karakter kerül a helyi nyelvi modellhez, ha a szabályok nem ismerik fel a típust	Harmadik félnek történő átadás; a szöveg tárolása	scanner/src/classify.js
Képernyőképek (bejáró)	az első oldal látható területe; minden látható űrlapnál az űrlapelem képe	–	scanner/src/crawl.js
Képernyőképek (aktív ellenőrzés)	A tesztbeküldés válaszoldalának képe; ezenfelül az állapot, a célcím, a cím és a szöveg első 300 karaktere	–	scanner/src/active.js
Képernyőképek (böngészős folyamatok)	Az űrlap képe kitakart beviteli mezőkkel, tömörítve, legfeljebb 32 KB méretben	Bevitt adatok	scanner/src/browser.js
Bejelentkezés mögött	a fenti űrlapmezőknél leírtak szerint	Képernyőképek, sütik, hivatkozások	scanner/src/login.js

Ezek az elemek a kialakítás szándéka szerint nem tartalmaznak személyes adatokat, járulékosan azonban igen: a kapcsolattartó neve az űrlap mellett, csapatfotó a kezdőlapon, telefonszám egy címkében, egy magánszemély e-mail-domainje, név egy helyőrzőben. Bejelentkezés mögött ehhez hozzáadódnak a tesztfiók és a webhelytől függően más felhasználók adatai.

6.3 Ki indítja el az ellenőrzést, és mi vonatkozik rá

Kiváltó esemény	Bizalmi szint a feladatban	Tesztbeküldések	Az eredmény elérhetősége	Törlés
Valaki megad egy domaint a kezdőlapon (ingyenes ellenőrzés)	névtelen	nem	Jelentés véletlenszerű hivatkozáson	30 nap, a képekkel együtt (cfg/check_lib.php)
Bővítmény vagy kiegészítő fiók nélkül	bővítmény	nem	Jelentés véletlenszerű hivatkozáson	30 nap
Ügynökség egy érdeklődő számára	regisztrált	nem	Rövid megállapítás és jelentés véletlenszerű hivatkozáson	90 nap (cfg/akquise_lib.php)
Ügyfél, domain igazolás nélkül	regisztrált	nem	Fiók; jelentés véletlenszerű hivatkozáson	13 hónap, az utolsó ellenőrzés megmarad
Ügyfél, domain igazolással	igazolt	igen, ellenőrzésenként legfeljebb öt	Fiók; jelentés véletlenszerű hivatkozáson	13 hónap, az utolsó ellenőrzés megmarad (cfg/fristen_lib.php)
Tanulmány	belső	nem	csak összesített adatok a közzététel után	közzétételkor; közzététel nélkül nincs időkorlát (R4)
A szolgáltató által parancssorból indított belső ellenőrzés	belső; saját teszt- és bemutató domainjeinknél „igazolt” is	nem; „igazolt” szintnél igen (csak saját teszt- és bemutató domainjeink)	csak belsőleg	nincs időkorlát (R4)

Az ingyenes ellenőrzés előtt több védelmi réteg áll (cfg/check_lib.php): vészleállítás; reCAPTCHA; ugyanaz a domain hét nap alatt legfeljebb egyszer (utána a meglévő jelentés jelenik meg); IP-címenkénti, munkamenetenkénti (kivonatértékként, soha nem magával a munkamenet-azonosítóval) és a teljes szolgáltatásra vonatkozó napi korlátok; a kizárásokból és a robots.txt-ből származó tiltólista; annak ellenőrzése, hogy a domain nyilvános címekre mutat-e; valamint a nagyon új vagy ismeretlen domainek tiltása. A rendellenességeket – sok különböző domain egy IP-címről, sok kérés rövid időn belül – az IP-címmel együtt feljegyezzük, és tartalom nélküli jelzést váltanak ki (cfg/check_lib.php).

6.4 Az ügyfélfiókban található domainek ellenőrzése

Az Ügyfél igazolja a domain feletti rendelkezési jogosultságát: DNS-rekorddal, metacímkével, fájllal vagy a bővítményünkön keresztül (cfg/verify_lib.php). A domaint csak ezután kezeljük igazoltként. A felügyeleti ütemező csak aktív, felügyelt és igazolt domainekhez tervez rendszeres ellenőrzéseket (cfg/monitor_lib.php).

• Az aktív tesztbeküldések két ellenőrzési kapuhoz kötődnek: az alkalmazás az Ügyfelek számára csak igazolt domaineknél állítja be az aktív módot (saját teszt- és bemutató domainjeinknél a szolgáltató belső parancssori eszközzel „igazolt” szintű ellenőrzést hozhat létre), az ellenőrzési szolgáltatás pedig ismét ellenőrzi a bizalmi szintet és a fc_active_enabled vészleállítást (scanner/src/worker.js). Csak olyan űrlap küldhető be, amelyet a szabályok nagy bizonyossággal általános kapcsolatfelvételi űrlapként ismernek fel, amelynek nincsenek valódi személyes adatokat kérő kötelező mezői, és amelynek domainje nem tűnik hatóság, oktatási intézmény, klinika, orvosi rendelő, rendőrség vagy bíróság domainjének (scanner/src/classify.js). A nyelvi modell nem tehet egy űrlapot beküldhetővé (scanner/src/classify.js). Ellenőrzésenként legfeljebb öt beküldés történik (fc_active_max_posts), egyértelmű jelöléssel, dummy@formexposed.com feladóval, az e-mail-ellenőrzés teszteléséhez .invalid alatti címmel és a fejlécinjektálás felismeréséhez ártalmatlan további fejlécsorral (scanner/src/active.js).
• A böngészős folyamatok a beállított űrlapfolyamatokat böngészőben, közvetlenül a beküldés előtti pontig ellenőrzik. Csak GET és HEAD kérések engedélyezettek; minden mást megszakítunk, ahogy azokat a címeket is, amelyek kijelentkezésre, törlésre, vásárlásra vagy fizetésre utaló szavakat tartalmaznak (scanner/src/browser.js). Az ellenőrzéshez a kötelező mezőket kitalált értékekkel töltjük ki, amelyek soha nem hagyják el a böngészőt.
• Védtelen fájlokat hetente keresünk, csak igazolt domaineknél, elérési utanként legfeljebb egy lekéréssel, legfeljebb 8 KB méretig, a tartalmat pedig soha nem tároljuk (cfg/dateien_lib.php).
• Egy független második mérőpont elő van készítve, és alapértelmezés szerint ki van kapcsolva (browser_probe_enabled = 0). Bekapcsolás esetén csak a domaint, a címet, a szelektort, a lépéseket és a böngészőválasztást kapná meg, hitelesítő adatokat, képernyőképeket vagy látogatói adatokat soha (cfg/formular_probe_lib.php).

6.5 Bejelentkezés mögötti ellenőrzés

Előfeltételek: a funkció be van állítva, a domain igazolt, az Ügyfél fizetős csomagot használ, és a munkaterület tulajdonosa vagy adminisztrátora (cfg/login_lib.php); megerősíti, hogy a fiók a lehető legkevesebb jogosultsággal rendelkező tesztfiók (cfg/login_lib.php).

1. A felhasználónevet és a jelszót a webszerver azonnal titkosítja az ellenőrzőszerver nyilvános kulcsával: rekordonként egyszer használatos kulcs (X25519), kulcsszármaztatás (HKDF-SHA256), AES-256-GCM, a domainhez kötve (cfg/login_lib.php). A magánkulccsal csak az ellenőrzőszerveren futó ellenőrzési szolgáltatás rendelkezik (scanner/src/geheim.js). Aki hozzáfér a webszerverhez, az adatbázishoz vagy egy biztonsági mentéshez, csak titkosított adatokhoz jut.
2. A felület csak a felhasználónév első karakterét és hosszát mutatja (cfg/login_lib.php). A hitelesítő adatokat soha nem jelenítjük meg, nem naplózzuk, és az API-n keresztül sem adjuk ki.
3. Az ellenőrzéshez az alkalmazás a titkosított adatokat a feladathoz csatolja. Az ellenőrzési szolgáltatás visszafejti őket, azonnal kiüríti a feladat megfelelő mezőjét, és a hitelesítő adatokat csak a szabványos bemeneten keresztül adja át a konténernek, parancssori argumentumként soha (scanner/src/worker.js). A megszakadt feladatokban maradt adatokat az állapotfolyamat egy óra elteltével törli (cfg/login_lib.php).
4. A konténeren belül a böngésző bejelentkezik. Megszakítja a műveletet, ha a bejelentkezési oldal másik kiszolgálóra irányít át, ha a bejelentkezési űrlapon CAPTCHA van (nem kerülünk meg CAPTCHA-kat), vagy ha a beküldés után továbbra is látható jelszómező (scanner/src/login.js). Ezután kiüríti a jelszómezőt az oldal memóriájában, és elfelejti a hitelesítő adatokat (scanner/src/login.js).
5. Ugyanazon domain legfeljebb öt, az Ügyfél által megadott oldalát olvassa be. A kijelentkezésre, törlésre, eltávolításra vagy lemondásra utaló szavakat tartalmazó címeket blokkolja (scanner/src/login.js). Bejelentkezés mögött semmit nem küld be, nem készít képernyőképeket, és a sütik, illetve hivatkozások nem kerülnek az eredménybe (scanner/src/login.js).
6. A törlés végleges: a titkosított adatokat azonos hosszúságú véletlenszerű adatokkal felülírjuk, a sort töröljük, és a függőben lévő feladatokat kiürítjük (cfg/login_lib.php). A domain törlésekor a sor idegen kulcson keresztül automatikusan eltűnik.

6.6 Kézbesítési ellenőrzés

A kézbesítési ellenőrzés arra a kérdésre ad választ, hogy valóban megérkezik-e a kapcsolatfelvételi űrlap e-mailje, és értékeli annak hitelességi jellemzőit. Opcionális, alapértelmezés szerint ki van kapcsolva, és beállított ellenőrző postaládát igényel (cfg/zustellung_lib.php).

1. Ha az Ügyfél bekapcsolja, a domain véletlenszerű jelölést kap. Az Ügyfél az ezzel a jelöléssel ellátott ellenőrző címet titkos másolati címként adja meg az űrlapjában.
2. Ettől kezdve minden űrlap-e-mail az ellenőrző postaládába is eljut: a megjelölt tesztbeküldéseink és a látogatók összes valódi üzenete. Az e-mailek közvetlenül a Namecheap, Inc. (Private Email), Phoenix, Arizona, USA szolgáltatónál lévő postaládába kerülnek – csak akkor érkeznek meg, ha domainünk MX-rekordjai oda mutatnak; továbbításon keresztül, például a Namecheap, Inc. domainregisztrátornál, nem jutnak el a postaládába –, és a lekérésükig ott maradnak.
3. Az állapotfolyamat ötpercenként lekéri a postaláda tartalmát (srv/cron_status.php). Minden e-mailnél beolvassa a fejléceket és a szöveg legfeljebb első 8 KB-ját anélkül, hogy olvasottnak jelölné a levelet (cfg/zustellung_lib.php).
4. A fejlécekből meghatározza a jelölést és így a domaint, a szövegből pedig adott esetben a tesztünk azonosítóját (cfg/zustellung_lib.php). Az időpontot, a domaint és adott esetben a tesztazonosítót tároljuk (cfg/zustellung_lib.php), 180 napig (cfg/zustellung_lib.php).
5. A fejlécekből értékeli az SPF, DKIM és DMARC eredményét, és a domainhez tárolja az eredményt: az ellenőrzési eredményeket, a feladói cím domainjét, az aláírások domainjeit és a küldő levelezőszerver címét (cfg/zustellung_lib.php). Ha az eredmény romlik, az Ügyfél egyszeri riasztást kap, amely megnevezheti a feladó domainjét (cfg/zustellung_lib.php).
6. Ezután minden lekért e-mailt törlésre jelöl, azt is, amelyet nem sikerült domainhez rendelni, és a futtatás végén eltávolítja a postaládából (cfg/zustellung_lib.php). Ha a futtatás ezt megelőzően megszakad, az e-mailek a következő sikeres futtatásig megmaradnak.
7. Kézbesítési bizonyítéknak csak pontosan az érintett teszt másolata számít (cfg/zustellung_lib.php). Ha három órán belül nem érkezik meg (delivery_wait_h), a szolgáltatás „Hiányzó kézbesítés” állapotot jelez.

A valódi üzenetek szövege soha nem kerül az adatbázisba, ahogy a látogató címe sem. Mindkettőt beolvassuk azonban: a lekérés minden e-mail első 8 KB-ját a memóriába tölti a tesztazonosító kereséséhez.

6.7 Rajvédelem

1. A WordPress-bővítmény védelmi rétege levélszemétként megállít egy üzenetet, és megszámolja a benne található hivatkozások domainjeit. A bővítmény naponta egyszer jelenti nekünk ezeket a domaineket a találatszámukkal együtt, naponta legfeljebb 60-at; címek, szöveg és IP-címek nélkül (cfg/swarm_lib.php).
2. Ebből naponta egyszer összeállítjuk a listát: egy domain akkor kerül rá, ha hét napon belül legalább három különböző webhely jelentette, legalább öt találattal (swarm_min_sites, swarm_window_days, cfg/swarm_lib.php). A rögzített kivétellistán szereplő nagy szolgáltatások és Ügyfeleink domainjei – mindkét esetben az aldomainekkel együtt – soha nem kerülnek a listára (cfg/swarm_lib.php).
3. A listát a napi jelentésre adott válasszal minden csatlakoztatott webhely megkapja. Védelmi rétegük a listázott domainekre mutató hivatkozásokat tartalmazó üzeneteket karanténba helyezi, nem a kukába.
4. Ami az új listán már nem szerepel, kiesik; a bejelentéseket 30 nap után töröljük (cfg/swarm_lib.php).
5. Az IP-hálózatok (/24 vagy /48) elő vannak készítve, de a jogi felülvizsgálat befejezéséig ki vannak kapcsolva (cfg/swarm_lib.php).

6.8 Mesterséges intelligencia használata

A nyelvi modell a saját ellenőrzőszerverünkön fut, nem MI-szolgáltatónál. Két helyen használjuk: az ellenőrzési szolgáltatásban besorolja azokat az űrlapokat, amelyek típusát a szabályok nem ismerik fel; ehhez látja az oldal címét, URL-címét, a beküldőgombok címkéit, a mezők típusát, nevét, címkéjét és helyőrzőit, valamint az űrlap szövegének legfeljebb 400 karakterét (scanner/src/classify.js). Csak akkor kérdezzük meg, ha a szabályok „ismeretlen” eredményt adnak; az így besorolt űrlapokat soha nem küldjük be, és nem számítanak bele a pontszámba és a minősítésbe. A pontszám, a minősítés, a visszaélés-megelőzés, a rajvédelem és a levélszemétszabályok rögzített szabályokon alapulnak, nem MI-n. A „Fix it for me” funkcióban a modell átírja a beillesztett űrlapkódot; a kódot nem tároljuk. A modell nem hoz emberekre vonatkozó döntéseket. További részletek az EU MI-rendelet: Hogyan használ a formexposed mesterséges intelligenciát oldalon.

6.9 Jogalapok

Adatkezelési művelet	Jogalap
P1 Ingyenes ellenőrzés: a kért domain ellenőrzése; korlátok és visszaélés-megelőzés	a kérelmező személy tekintetében a 6. cikk (1) bekezdésének b) pontja; az üzemeltető és az ábrázolt személyek tekintetében a 6. cikk (1) bekezdésének f) pontja; visszaélés-megelőzés: a 6. cikk (1) bekezdésének f) pontja
P2 Érdeklődői ellenőrzés	A 6. cikk (1) bekezdésének f) pontja (az ügynökség és a formexposed jogos érdeke)
P3 Tanulmány	A 6. cikk (1) bekezdésének f) pontja
P4 Ügyféldomainek ellenőrzése	A 6. cikk (1) bekezdésének b) pontja az Ügyfél tekintetében; a webhelyén található, harmadik felekhez tartozó adatoknál az Ügyfél 28. cikk szerinti utasításai
P5 Bejelentkezés mögötti ellenőrzés	Az Ügyfél 28. cikk szerinti utasításai; az Ügyfél jogalapja
P6 Kézbesítési ellenőrzés	Az Ügyfél 28. cikk szerinti utasításai; az Ügyfél jogalapja (az Ügyfeleknek javasolt szövegünkben a 6. cikk (1) bekezdésének f) pontja)
P7 Rajvédelem	A 6. cikk (1) bekezdésének f) pontja (közös védekezés a levélszemét ellen számos webhelyen)

A P1–P3 esetében jogos érdekünk abban áll, hogy az üzemeltetőknek és szolgáltatóiknak megmutassuk az űrlapjaik gyengeségeit, mielőtt azokat levélszemétküldésre vagy visszaélésre használnák ki, valamint hogy nyújtsuk a szolgáltatást. Az adatok nyilvánosan hozzáférhető forrásokból származnak. Az érdekmérlegelést a 7. szakasz ismerteti; a jogi felülvizsgálat nyitott kérdése, hogy a 6. cikk (1) bekezdésének f) pontja megalapozza-e harmadik felek webhelyeinek kérésre történő ellenőrzését.

6.10 Címzettek és harmadik országokba történő adattovábbítások

Címzett	Mi	Adatkezelési művelet	Állapot
A formexposed szervezetén kívül senki	Ellenőrzési eredmények, képernyőképek, a nyelvi modell általi besorolás	P1–P5	Az ellenőrzési szolgáltatás és a nyelvi modell saját szervereinken fut; a bejáró ellenőrzési útvonalán nem találtunk harmadik félhez intézett hívást, kivéve magát az ellenőrzött webhelyet, az általa beágyazott tartalmat szolgáltató szolgáltatásokat (mint bármely látogatónál), valamint a domain korához használt rdap.org RDAP-szolgáltatást (csak a domainnév); a felügyelet figyelőfunkcióit a következő sor sorolja fel
Bárki, aki ismeri a hivatkozást	Jelentés megállapításokkal és képernyőképekkel	P1, P2, P4	128 bites véletlenszerű hivatkozás (cfg/check_lib.php), noindex jelölésű oldalak (www/report.php)
Az ügyféldomain felügyelete által lekérdezett szolgáltatások	DNS-tiltólisták (SpamCop, PSBL, Mailspike, SURBL): domainek és szerverek IP-címei, látogatói adatok nélkül; Google Web Risk csak beállítás esetén: a kezdőlap címe; Certum és DigiCert időbélyegző hatóságok: csak a bizonyítéknapló kivonatértéke; RDAP az IANA nyilvántartásán keresztül: csak a domainnév; szolgáltatók állapotoldalai: semmit nem továbbítunk; wpvulnerability.net: bővítmény (verzió nélkül) vagy sablon azonosítója és a WordPress verziója	P4	használatban; részletek az Adatkezelési tevékenységek nyilvántartásában és a További adatfeldolgozók oldalon
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Ellenőrző másolatok, a valódi látogatói üzenetekkel együtt	P6	A szerződést még nem kötöttük meg; az adatkezelés helyszínét és az adattovábbítási mechanizmust még vizsgálni kell
Namecheap, Inc. (USA)	Regisztrátor és DNS; a postaláda beállításáig a domainünk címeire érkező általános e-mailek továbbítása, az ellenőrző másolatoké nem (ezek csak a közvetlenül a postaládára mutató MX-rekordokon keresztül jutnak el oda)	– (ellenőrző másolatok nélkül)	Az adattovábbítási mechanizmust vizsgálni kell
Az Ügyfél által választott riasztási csatornák (e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram)	Esemény, domain, hivatkozás; a hitelességi ellenőrzésnél a feladó domainje, ha nem a webhelyhez tartozik	P4, P6	az Ügyfél által választott cél; részben az EU-n kívül. A Telegram-üzeneteket a botunkon keresztül küldjük; ennek adattovábbítási mechanizmusa a jogi felülvizsgálat nyitott kérdése
Minden csatlakoztatott webhely	Hivatkozásdomainek listája	P7	a bővítménynek küldött válaszon keresztül
Második mérőpont	Domain, űrlapcím, szelektor, lépések	P4	kikapcsolva

6.11 Megőrzés: a mért állapot, nem a szándék

A törlés többnyire éjszaka, 03:00-kor történik az állapotfolyamatban (srv/cron_status.php, cfg/fristen_lib.php); a rajvédelmi bejelentések és az érdeklődői rekordok naponta 04:00-tól törlődnek, a kézbesítési ellenőrzés hozzárendelései minden lekéréskor; a névtelen és érdeklődői jelentéseket a lejárati idejük alapján töröljük (cfg/check_lib.php). A képernyőképek az ellenőrzésükkel együtt törlődnek a lemezről (cfg/fristen_lib.php).

Adatok	A kód szerinti időszak	Forráshivatkozás	Megállapítás
Ingyenes ellenőrzés a képekkel együtt	30 nap	cfg/check_lib.php	működik
Érdeklődői ellenőrzés a képekkel együtt	90 nap	cfg/akquise_lib.php; srv/cron_status.php (érdeklődői rekordok)	működik
Ügyféldomain ellenőrzései	13 hónap; az utolsó a domain fennállásáig megmarad	cfg/fristen_lib.php	működik
Böngészős folyamatok eredményei a kitakart képekkel együtt	13 hónap	cfg/fristen_lib.php	működik
Törölt domain adatai	azonnal; az árva adatok éjszaka	cfg/fristen_lib.php (fe_domain_loeschen(), fe_fristen_lauf())	működik, a szkriptleltárt és a szkriptváltozásokat is beleértve, amelyeknek ezen túl nincs saját megőrzési időszakuk (lásd az Adatkezelési tevékenységek nyilvántartását)
Tanulmány: nyers adatok a képekkel együtt	közzétételkor	cfg/studie_lib.php	közzététel nélkül nincs időkorlát; az ellenőrzött kiszolgálók listája közzététel után is időkorlát nélkül megmarad
Belső ellenőrzések domain és jelentés nélkül	nincs	–	nincs törlés; mért adat: 85 ellenőrzés 369 képpel 2026. szeptember 22. óta (R4)
A kézbesítési ellenőrzés hozzárendelései	180 nap	cfg/zustellung_lib.php	működik
A domainhez rendelt hitelességi ellenőrzés eredménye	a következő eredményig vagy a domain törléséig	cfg/zustellung_lib.php	felülíródik, nincs időkorlátja
Ellenőrző másolatok a postaládában	a következő sikeres lekérésig (ötperces időköz)	cfg/zustellung_lib.php	a postaláda-szolgáltatónál lévő másolatok és biztonsági mentések nem ellenőrzöttek
Hitelesítő adatok a bejelentkezés mögötti ellenőrzéshez	az Ügyfél általi törlésig vagy a domain törléséig; a feladatban legfeljebb a futtatás végéig, a maradványok egy óra elteltével törlődnek	cfg/login_lib.php	működik; a biztonsági mentésekben csak titkosított formában, legfeljebb 14 napig
Bejelentések a rajvédelemben	30 nap	cfg/swarm_lib.php	működik
Az ingyenes ellenőrzés korlátai (IP, ország, munkamenet-kivonat)	7 nap	srv/cron_status.php	működik
Feltűnő viselkedésre vonatkozó feljegyzések IP-címmel	a lezárás után 90 nap	srv/cron_status.php	le nem zárt feljegyzések időkorlát nélkül; mért adat: 3 feljegyzés, mind lezárt
Kizárási kéréshez kapcsolódó IP-cím, ország, böngésző	12 hónap; a kizárás megmarad	cfg/fristen_lib.php	működik
Adatbázis-mentések	14 nap	cfg/backup_lib.php	működik; a mentéseket jelenleg az adatbázissal azonos helyszínen tároljuk, és külön nincsenek titkosítva; titkosított másolatot tervezünk egy második helyszínen (R13)

7. (b) A szükségesség és arányosság értékelése

A mércét a megjelölt célok adják: megmutatni az üzemeltetőknek, hogy űrlapjaik védettek-e a levélszeméttel és a visszaéléssel szemben (P1–P5), ellenőrizni, hogy az űrlapok e-mailjei megérkeznek-e és hitelesnek tűnnek-e (P6), valamint közösen védekezni a levélszemét ellen számos webhelyen (P7). Ezek jogszerű célok. A 35. cikk (7) bekezdésének b) pontja szerinti kérdés szűkebb: szükséges-e ez az adatkezelés ilyen mélységben a cél eléréséhez, és arányban áll-e a beavatkozás az előnnyel?

Összetevő	Szükséges a célhoz?	Arányos a megvalósított formában?
Néhány nyilvános oldal lekérése, az űrlapok szerkezete, felismert védelmi intézkedések	Igen. Ezek nélkül nincs megállapítás.	Igen. Legfeljebb nyolc oldal (a 6.1. szakaszban leírt nézeteken felül), a robots.txt kezdőlapra vonatkozó tiltását tiszteletben tartjuk, a látható mezők értékeit nem tároljuk, a címzettcímeket csak domainként.
Képernyőkép űrlaponként	Igen, bizonyítékként a jelentésben: az üzemeltető láthatja, melyik űrlapról van szó.	Nagyrészt. A mezők üresek, mert a bejáró semmit nem gépel be. A képen azonban az űrlapelem környezete is látható, kitakarás nélkül (R3).
Képernyőkép a kezdőlapról	Magához a megállapításhoz nem szükséges. Az ellenőrzött webhely felismerését szolgálja a jelentésben.	Csak korlátozottan; további adattakarékosságot tervezünk. A kezdőlapokon gyakran emberek láthatók: csapatfotók, kapcsolattartók, névvel ellátott ügyfélvélemények. Lásd R3 és 9.3. szakasz.
Rejtett mezők értékeinek beolvasása (az első 24 karakter, csak az ellenőrzés során)	Igen: ezekből ismerhetők fel a tokenek és időbélyegek.	Igen. Csak a felismerés eredményét tároljuk, az értéket nem, bejelentkezés mögött sem (R8).
A tesztbeküldés válaszoldala (kép és 300 karakternyi szöveg)	Igen, annak bizonyítékaként, hogyan válaszolt az űrlap.	Igen. A válasz a megjelölt, személyes adatot nem tartalmazó tesztüzenetünkre vonatkozik.
A nyelvi modell általi besorolás	Hasznos, de nem szükséges: nélküle több űrlap marad „ismeretlen”.	Igen. Helyben történik, adattovábbítás és beküldési jogosultság nélkül.
Aktív tesztbeküldések	Igen. Csak teszteléssel derül ki, hogy működik-e egy védelem.	Igen, felső korláttal és jelöléssel. Az előfeltételt – a rendelkezési jogosultság igazolását – azonban soha nem újítjuk meg (R7).
Védtelen fájlok keresése	Igen, az Ügyfél számára, akinek űrlapadatai ott védtelenül elérhetők lehetnek.	Igen. Csak igazolt domainek, legfeljebb 8 KB, a tartalmat soha nem tároljuk.
Bejelentkezés mögötti ellenőrzés	Igen, a tagi felületen lévő űrlapoknál, amelyek különben ellenőrizetlenek maradnának.	Nagyrészt. A titkosítást és törlést gondosan alakítottuk ki; a bejelentkezés azonban elfogad titkosítatlan kapcsolatokat és hibás tanúsítványokat (R8).
Valódi látogatói üzenetek ellenőrző másolata	A kézbesítés igazolásához nem. Az kizárólag a tesztünk másolatára támaszkodik (cfg/zustellung_lib.php). A valódi üzenetek azért érkeznek vele együtt, mert az űrlapban beállított titkos másolat nem különbözteti meg a tesztet a valódi üzenettől. A hitelességi ellenőrzéshez (SPF, DKIM, DMARC) hasznosak, mert megmutatják a tényleges küldési útvonalat.	Részben. A tartalmat nem tároljuk, de beolvassuk, és a lekérésig annál a postaláda-szolgáltatónál marad, amellyel a szerződés még nyitott kérdés (R1, R2). Technikailag lehetséges kevésbé beavatkozó kialakítás: a bővítményünkkel a titkos másolatot a megjelölt tesztüzenetekre lehetne korlátozni (9.3. szakasz).
A valódi üzenetek feladói domainjének tárolása	Részben: megmutatja, hogy az űrlap a látogató címét használja-e feladóként (ami a levélszemétként való besorolás gyakori oka).	Feltételesen. Saját domainnel rendelkező magánszemélynél a domain személyes adat, és a riasztásban eljut az Ügyfélhez és annak csatornáira (R1).
Hivatkozásdomainek közös listája	Igen. Az egyszerre sok webhelyen megjelenő levélszeméthivatkozás erős jelzés, amellyel egyetlen webhely nem rendelkezik.	Igen, minimumszámokkal, kivételekkel és törlés helyett karanténnal. Az IP-hálózatok új értékelés nélkül nem lennének arányosak.
A tanulmány nyers adatai	A kiértékelésig igen.	Maximális időszak nélkül nem (R4).
Jelentés véletlenszerű hivatkozáson	Igen. A jelentés továbbadása – például a webhelyet gondozó szolgáltatónak – az ingyenes ellenőrzés célja.	Igen. 128 bites véletlenszerű hivatkozás, noindex, az ingyenes jelentés csak kivonatként (cfg/check_lib.php, FE_FREE_DETEKTOREN), törlés 30 nap után.

Jogszerűség. A P1–P3 és P7 esetében a 6. cikk (1) bekezdésének f) pontjára támaszkodunk. A mérlegelés mellett szól: az adatok nyilvánosak, és ugyanúgy kérjük le őket, mint bármely látogató; semmit nem küldünk be; a személyes adatok járulékosak és csekély mennyiségűek; az időszakok rövidek; az üzemeltető a robots.txt kezdőlapra vonatkozó tiltásával kizárhatja a bejáró további ellenőrzéseit, a kizárási oldalunkon pedig bármilyen további ellenőrzést, azonnal és igazolás nélkül; az előnyből – a védett űrlapból – az üzemeltető és látogatói is részesülnek. Ellene szól: az üzemeltető semmit nem tud meg az ellenőrzésről, a jelentés harmadik feleknek készül, és egyéni vállalkozók esetében egy személyt értékel. A mérlegelést indokolhatónak tartjuk mindaddig, amíg a 9.1. szakasz intézkedései fennmaradnak; a jogi megerősítés függőben van.

Az érintettek tájékoztatása (13. és 14. cikk). Az üzemeltetőket és az ellenőrzött oldalakon szereplő személyeket a minden lekérés azonosítójában megnevezett bejáróoldalon, az Adatvédelmi tájékoztatón és a kizárási oldalon keresztül tájékoztatjuk. A képernyőképen járulékosan megjelenő személyek egyedi tájékoztatása csak azonosításukkal lenne lehetséges – ami további, súlyosabb beavatkozást jelentene. Ennyiben a 14. cikk (5) bekezdésének b) pontjára támaszkodunk. Azokat a látogatókat, akiknek üzenetei az ellenőrző másolaton keresztül haladnak át, az Ügyfél tájékoztatja; ezt az Adatfeldolgozási szerződés előírja, és szövegblokkot biztosítunk hozzá.

Adattakarékosság (5. cikk (1) bekezdés c) pont). Számos helyen látható és a kódban megalapozott: nincsenek mezőértékek, a címzettcímek csak domainként szerepelnek, a szkriptcímekben lévő fiókazonosítók rejtettek, az ellenőrző másolat tartalma nem kerül az adatbázisba, bejelentkezés mögött nincsenek képernyőképek, a rajvédelemben csak domainek szerepelnek. Két helyen további adattakarékosság lehetséges és tervezett (9.3. szakasz): a kezdőlap kitakarás nélküli képernyőképénél és a valódi üzenetek feladói domainjénél.

Korlátozott tárolhatóság (5. cikk (1) bekezdés e) pont). 2026. szeptember 27. óta az éjszakai futtatás az ügyféladatoknál betartja az Adatvédelmi tájékoztató időszakait, és törli a korábbi időszakból megmaradt, kapcsolódó domain nélküli adatokat (cfg/fristen_lib.php). Két időkorlát nélküli út marad nyitva: a belső ellenőrzések és a közzé nem tett tanulmányok (R4).

Pontosság (5. cikk (1) bekezdés d) pont). Egy megállapítás téves lehet: az űrlap védtelennek tűnik, mert a védelem csak interakció után töltődik be, vagy a tűzfal másként kezelte a bejárót, mint egy látogatót. Annak az üzemeltetőnek, akinek a webhelyét nyilvánosan „Védtelenként” adják tovább, ez jó hírnév kérdése. A jelentés ezért megnevezi a módszert, bizonyítékokat mutat, és felhívja a figyelmet a kívülről végzett ellenőrzés korlátaira.

Az arányosság értékelésének eredménye: Harmadik felek és saját webhelyek ellenőrzése a megvalósított formájában alapvetően arányos. Három helyen van olyan fejlesztési igény, amely szokásos eszközökkel orvosolható, és amelyhez intézkedéseket tervezünk (9.3. szakasz): a kezdőlap képernyőképei, az időkorlát nélküli belső ellenőrzések és a bejelentkezés mögötti ellenőrzés titkosítatlan bejelentkezése. A kézbesítési ellenőrzés a tesztmásolat és a hitelességi ellenőrzés tekintetében arányos; a valódi látogatói üzeneteknél ez csak addig áll fenn, amíg a tartalmukat nem tároljuk, a postaláda-szolgáltatón át vezető út szerződésesen biztosított, és az Ügyfél tájékoztatja látogatóit. Jelenleg e három pont közül a második hiányzik.

8. (c) Az érintettek jogait és szabadságait érintő kockázatok értékelése

Az érintetteket fenyegető kockázatot értékeljük, nem a formexposed kockázatát. A valószínűséget csekély, lehetséges, valószínű vagy bekövetkezett minősítéssel látjuk el; a „bekövetkezett” azt jelenti, hogy az esemény nem előrejelzés, hanem mért állapot. A súlyosság korlátozott, jelentős, súlyos vagy nagyon súlyos lehet attól függően, hogy mit veszíthet az érintett: üzenetének bizalmasságát, a fiókja feletti ellenőrzést, üzleti jó hírnevét, valamely jog gyakorlásának lehetőségét. A szint e kettőből adódik, és a jelenlegi állapotot írja le a 9.1. szakasz intézkedéseivel együtt.

Szám	Kockázat	Adatkezelési művelet	Valószínűség	Súlyosság	Szint
R1	Valódi látogatói üzenetek az ellenőrző másolatban, esetleges különleges adatokkal együtt	P6	Bekapcsoláskor bekövetkezik	Súlyos	Magas
R2	Az ellenőrző másolat útja a postaláda-szolgáltatón keresztül megkötött szerződés nélkül és esetleges harmadik országbeli kapcsolattal	P6	Valószínű, amíg a szerződés hiányzik	Súlyos	Magas
R3	Harmadik felek webhelyeinek képernyőképei kitakarás nélkül	P1–P4	Valószínű	Korlátozott	Közepes
R4	Ellenőrzési adatok és képernyőképek törlési eljárás nélkül	P3, belső ellenőrzések	Bekövetkezett	Jelentős	Magas
R5	Harmadik felek webhelyeinek ellenőrzése és nyilvános értékelése az üzemeltető tudta nélkül; visszaélés felderítőeszközként	P1	Lehetséges	Jelentős	Közepes
R6	Érdeklődői ellenőrzés kéretlen megkeresések alapjaként	P2	Valószínű	Korlátozott	Közepes
R7	A rendelkezési jogosultság igazolását soha nem újítjuk meg	P4, P5	Lehetséges	Jelentős	Közepes
R8	Hitelesítő adatok és tartalom a bejelentkezés mögötti ellenőrzésben	P5	Lehetséges	Súlyos	Közepes; valódi fiókoknál magas
R9	Aktív tesztbeküldések és fájlellenőrzés az Ügyfél webhelyén	P4	Csekély	Jelentős	Alacsony
R10	Nyelvi modell általi besorolás	P1–P4	Csekély	Korlátozott	Alacsony
R11	Számos webhely bejelentéseiből összeállított közös tiltólista	P7	Lehetséges	Korlátozott	Alacsony–közepes; IP-hálózatokkal magas
R12	Jelentések és képernyőképek nyilvános hivatkozáson	P1, P2, P4	Lehetséges	Korlátozott	Alacsony
R13	Infrastrukturális gyengeségek: biztonsági mentések, szerverhozzáférés, ellenőrzőszerver	mindegyik	Lehetséges	Súlyos	Magas
R14	Az érintetti jogok gyakorlása olyan személyeknél, akik nem ismernek minket	P1–P6	Valószínű	Korlátozott	Alacsony

R1 – Valódi látogatói üzenetek az ellenőrző másolatban

Ez a szolgáltatás legsúlyosabb kockázata, és nem hibából, hanem a kialakításából ered. Az űrlap titkos másolata nem tesz különbséget a mi tesztüzenetünk és egy látogató üzenete között. Ha az Ügyfél bekapcsolja a kézbesítés ellenőrzését, az adott űrlapon keresztül küldött minden üzenet eljut az ellenőrző postafiókunkba (cfg/zustellung_lib.php). A lekérés a fejléceket és a szöveg első 8 KB-ját a memóriába olvassa, hogy megkeresse a tesztazonosítónkat (cfg/zustellung_lib.php). Egy szokásos kapcsolatfelvételi űrlap esetében ez a nevet, az e-mail-címet, a telefonszámot és a teljes üzenetet jelenti.

A látogató maga dönti el, mit ír, a mező pedig személyes tartalom megadására ösztönöz: tüneteket leíró időpontkérés egy orvosi rendelőnek, jogvita ismertetése egy ügyvédi irodának, álláspályázat, gyermekkel kapcsolatos érdeklődés egy iskolánál. Jogi dokumentumaink szerint a másolatok „nem tartalmazhatnak személyes adatok különleges kategóriáit”. Ez az Ügyfélhez intézett kérés, nem védelmi intézkedés: sem ő, sem mi nem tudjuk előre, mit fog írni a látogató.

Ehhez két további adatút kapcsolódik. Először is, a hitelesség ellenőrzése a feladó címének domainjét az ellenőrzött domainhez rendelve tárolja (cfg/zustellung_lib.php). Ha az űrlap a látogató címét használja feladóként, ez a látogató domainje – egy nagy levelezőszolgáltató esetében önmagában nem árul el semmit, saját domainnel rendelkező magánszemélynél azonban személyes adat. Ez a domain az Ügyfélnek és az általa választott csatornákra küldött riasztásban is megjelenik (cfg/zustellung_lib.php). Másodszor, eltárolja a küldő levelezőszerver címét (cfg/zustellung_lib.php); ez rendszerint a webhely szervere, nem a látogatóé.

Valószínűség – a bekapcsolással megvalósul. Nem az a kérdés, hogy érkeznek-e valódi üzenetek, hanem az, hogy mennyi. A fejlesztői rendszeren végzett mérés szerint a funkció egyetlen domainnél sincs bekapcsolva. Súlyosság – súlyos. Egy vállalkozásnak küldött üzenet bizalmas jellege sokak számára fontos, és a jellemző Ügyfelek egy részénél a 9. cikk szerinti adatokra is számítani kell. A súlyosságot mérsékli, hogy a tartalom nem kerül az adatbázisba, csak rövid ideig marad a postafiókban, és a formexposed részéről senki nem olvassa el. Szint – magas.

R2 – Az ellenőrző másolat útja a postafiók-szolgáltatón keresztül megkötött szerződés nélkül

Mielőtt a lekérésünk hozzáférne az ellenőrző másolathoz, azt a Namecheap, Inc. (Private Email), Phoenix, Arizona, USA postafiókja tárolja. Csak akkor érkezik meg oda, ha domainünk MX-rekordjai közvetlenül erre a postafiókra mutatnak; a Namecheap, Inc. domainregisztrátornál történő továbbítás nem állomása az ellenőrző másolatok útjának (továbbítással nem jutnak el a postafiókba). A megmaradó állomás szerződéses feltételei még rendezetlenek: a postafiók-szolgáltatóval a szerződés nem jött létre, tárolási helyeit, további adatfeldolgozóit és biztonsági mentéseinek megőrzési idejét még nem állapítottuk meg, és nyitott kérdés, hogy az adatkezelés helye miatt szükséges-e és alkalmazandó-e megfelelőségi határozat vagy általános szerződési feltétel. Saját tranzakciós e-mailjeink esetében ez szerződéskialakítási kérdés. Az ellenőrző másolatoknál súlyosabb a helyzet: ezek olyan adatok, amelyeket adatfeldolgozóként kapunk, és az útvonal minden szolgáltatója további adatfeldolgozó, akiért a 28. cikk (4) bekezdése alapján felelünk.

Ezenfelül a „lekérés után törölve” csak a postafiók általunk látható állapotára vonatkozik. Nem ellenőriztük, hogy a szolgáltató saját biztonsági mentéseiben vagy a kukában megőrzi-e a törölt e-maileket, és ha igen, meddig. Ha a lekérés megszakad, az e-mailek a következő sikeres futásig megmaradnak (cfg/zustellung_lib.php); ha az állapotfolyamat leáll, határozatlan ideig ott maradnak. Végül magának a lekérésnek a biztonsága is az éles rendszeren az indulás előtt ellenőrizendő pontok közé tartozik (9.3. szakasz).

Valószínűség – valószínű, amíg hiányzik a szerződés: minden ellenőrző másolat ezen az útvonalon halad. Súlyosság – súlyos, az R1-nél leírtakkal azonos okokból. Szint – magas. Az alkalmazás beállítási ellenőrzőlistája figyelmeztetésként jelzi a hiányzó postafiókot; nincs olyan zárolás, amely dokumentált szerződés hiányában letiltaná a kézbesítés ellenőrzését.

R3 – Harmadik felek webhelyeiről készült képernyőképek kitakarás nélkül

A bejáró képernyőképet készít az első oldal látható területéről, valamint minden látható űrlap űrlapeleméről (scanner/src/crawl.js). Ennek során semmit nem takar ki. A böngészős folyamatoknál más a helyzet: ott a képernyőkép készítése előtt maszkolja a beviteli mezőket (scanner/src/browser.js). Tehát csak a böngészős folyamatok képei „tisztítottak”, a bejáró képei és az aktív ellenőrzés válaszoldalának képe nem.

Mivel a bejáró nem ír be semmit, az űrlapmezők üresek. Egy kisvállalkozás kezdőlapján azonban gyakran megjelenik a tulajdonos, a csapat, ügyfélvélemények nevekkel és fényképekkel, vagy egy csevegőablak egy munkatárs képével. Mindez nyilvános; a képernyőkép olyan másolatot hoz létre belőle, amelyet nálunk tárolunk, megjelenik a jelentésben, és a hivatkozással továbbadható.

Valószínűség – valószínű. A fejlesztői rendszer adatkészletében 432 képernyőképet mértünk. Súlyosság – korlátozott: a tartalom eleve nyilvános, a fiók nélküli ellenőrzések megőrzési ideje pedig rövid. Szint – közepes, mert az ábrázolt személyek nem tudnak róla, és a kezdőlap képe nem szükséges a megállapításhoz.

R4 – Ellenőrzési adatok és képernyőképek törlési eljárás nélkül

Az éjszakai futás két módon törli az ellenőrzéseket: a jelentés lejárati dátuma alapján (cfg/check_lib.php), illetve az Ügyfél domainjének ellenőrzéseire vonatkozó megőrzési idő alapján (cfg/fristen_lib.php, csak domainhez tartozó ellenőrzéseknél). Az az ellenőrzés, amelyhez sem jelentés, sem domain nem tartozik, mindkét szűrőn átcsúszik. Ezek a „belső” bizalmi szintű ellenőrzések: a tanulmányok és a szolgáltató által parancssorból létrehozott ellenőrzések.

• A tanulmányok közzétételkor törlik a nyers adataikat (cfg/studie_lib.php). Ha egy tanulmányt soha nem tesznek közzé – mert túl kevés benne az űrlappal rendelkező webhely (a cfg/studie_lib.php ilyenkor megtagadja a közzétételt), vagy mert félreteszik –, az ellenőrzések, űrlapok, megállapítások és képernyőképek időkorlát nélkül megmaradnak.
• A parancssorból indított belső ellenőrzésekhez egyáltalán nincs törlési eljárás. A 2026. október 11-i mérés szerint: 85 ilyen ellenőrzés harmadik felek webhelyeiről, 978 űrlappal és 369 képernyőképpel; a legrégebbi 2026. szeptember 22-i, és egyikhez sem tartozik jelentés vagy domain.
• A feltűnő viselkedésről készült feljegyzések az ingyenes ellenőrzés során tartalmazzák az IP-címet, és lezárásuk után 90 nappal törlődnek (srv/cron_status.php). A soha le nem zárt feljegyzés megmarad. A mérés szerint: három feljegyzés, mindegyik lezárva.

Valószínűség – megvalósult. A 85 ellenőrzés nem forgatókönyv, hanem meglévő adat. A fejlesztői rendszeren ezek egy terepi teszt ellenőrzései; az éles rendszeren ugyanaz a kód érvényesül. Súlyosság – jelentős: ezekre az adatokra nincs megőrzési idő. A korlátozott tárolhatóság elvével (5. cikk (1) bekezdés e) pont) kapcsolatban ez nyitott kérdés, amelyhez tervezett intézkedés tartozik (9.3. szakasz, „elsőként” prioritás), és éppen olyan embereket érint, akik semmit sem tudnak az ellenőrzésről. A belső ellenőrzéseket az Adatkezelési tevékenységek nyilvántartása ismerteti; az Adatvédelmi tájékoztató még nem nevezi meg őket külön (9.4. szakasz). Szint – magas.

R5 – Harmadik felek webhelyeinek ellenőrzése és nyilvános minősítése az üzemeltető tudta nélkül

Bárki ellenőriztethet bármely nyilvánosan elérhető webhelyet, fiók és a webhelyhez fűződő bármilyen kapcsolat nélkül. Az üzemeltető nem kap értesítést. Az eredmény egy jelentés, amely a webhelyet „Védtelen”, „Részben védett” vagy „Védett” minősítéssel látja el, és amelyet a hivatkozás birtokában bárki megtekinthet. Az érintettek számára két következmény képzelhető el. Egy egyéni vállalkozó nyilvánosan – még ha csak a hivatkozás címzettjei számára is – olyan minősítést kap, amely téves megállapításon alapulhat. A jelentés pedig megmutatja a spamküldőnek, melyik űrlap tölthető ki akadálytalanul.

Ezzel több korlátozás áll szemben (cfg/check_lib.php): domainenként hét nap alatt legfeljebb egy ellenőrzés, utána ugyanaz a jelentés; IP-címenkénti és munkamenetenkénti korlátok; napi felső határ a teljes szolgáltatásra; a visszaélésekre jellemző nagyon új domainek ellenőrzésének kizárása; feljegyzés és jelzés feltűnő viselkedés esetén; robots.txt és opt-out, kétszer ellenőrizve (a cfg/check_lib.php fájlban és az ellenőrző szolgáltatásban). Az ingyenes jelentés kivonat: csak az alapvető megállapításokat mutatja, nem az összes detektor bizonyítékait. És semmi olyat nem árul el, amit egy bot néhány másodperc alatt magától ne tudna megállapítani – a védtelen űrlap kívülről látható.

Valószínűség – lehetséges. Súlyosság – jelentős egy olyan egyéni vállalkozó számára, akinek az űrlapját a jelentés után célba veszik, vagy akinek a minősítése téves. Szint – közepes.

R6 – Az érdeklődői ellenőrzés mint kéretlen megkeresések alapja

A felület az érdeklődői ellenőrzést az „első beszélgetéshez vezető ajtónyitóként” írja le. Az ügynökség dönti el, hogyan használja fel a rövid megállapítást; technikailag olyan üzemeltetőnek is elküldheti, aki nem kérte. Mi senkivel nem lépünk kapcsolatba (cfg/akquise_lib.php), a Szolgáltatási feltételek pedig kötelezik az ügynökséget a reklámozásra és megkeresésekre vonatkozó szabályok betartására. A megállapítást tartalmazó kéretlen e-mail azonban vállalkozások között is közvetlen üzletszerzésnek minősül, amely Lengyelországban (a Prawo komunikacji elektronicznej, PKE (elektronikus hírközlési törvény) 398. cikke) és Németországban (a Gesetz gegen den unlauteren Wettbewerb, UWG (a tisztességtelen verseny elleni német törvény) 7. § (2) bekezdése) előzetes hozzájárulást igényel. A felület erre nem hívja fel a figyelmet; az érdeklődői ellenőrzés szövegei csak „passzív” ellenőrzésről és „opt-out listáról” beszélnek.

Valószínűség – valószínű, mert a funkció ügyfélszerzést szolgál, és nem tudjuk ellenőrizni, hogy a címzett hozzájárult-e. Súlyosság – korlátozott: az üzemeltető számára ez egy bosszantó marketing-e-mail a webhelyének minősítésével. Szint – közepes. A kockázat az ügynökség magatartásában rejlik; mivel azonban a funkció tőlünk származik, figyelmeztetést tervezünk a felületen (9.3. szakasz).

R7 – A rendelkezési jogosultság igazolását soha nem újítják meg

Az aktív tesztbeküldésekhez, a hozzáférhetővé vált fájlok kereséséhez és a bejelentkezés mögötti ellenőrzéshez az Ügyfélnek igazolnia kell, hogy jogosult rendelkezni a domain felett. Ezt az igazolást egyszer ellenőrizzük (cfg/verify_lib.php), utána soha többé. A kódban nincs olyan eljárás, amelynek révén egy domain elveszítené az igazolt állapotát. Ha a domain tulajdonost vált, az ügynökség megbízása megszűnik, vagy az üzemeltető eltávolítja a DNS-rekordot, az ellenőrzések folytatódnak – akár naponta, legfeljebb öt tesztbeküldéssel, és amennyiben eltárolták, egy olyan tesztfiók belépési adataival, amelyről az új üzemeltető esetleg nem tud. Ezzel szemben az igazolás átnevezéssel nem vihető át másik hosztra: az igazolt rendelkezési jogosultsággal rendelkező domain hosztneve nem módosítható.

Valószínűség – lehetséges: a domainváltások és a megbízások változásai mindennaposak az ügynökségeknél. Súlyosság – jelentős az új üzemeltető és munkatársai számára, akik megjelölt tesztüzeneteket kapnak, és akiknek a webhelyén hozzájárulásuk nélkül keresnek hozzáférhetővé vált fájlokat. Szint – közepes. A tesztüzenetek elmagyarázzák saját céljukat, és hivatkoznak a bejáró oldalára és az opt-out lehetőségére; az opt-out az Ügyfelek által indított ellenőrzéseket is megakadályozza.

R8 – Belépési adatok és tartalom a bejelentkezés mögötti ellenőrzésben

A belépési adatok titkosítása gondosan kialakított: tárolás után a webszerver már nem tudja őket elolvasni, az adatbázis és a biztonsági mentés csak titkosított szöveget tartalmaz, a rekord a domainjéhez van kötve, a belépési adatok csak a szabványos bemeneten keresztül jutnak a konténerbe, majd törlődnek a memóriából (6.5. szakasz). Két hiányosság marad; egy harmadik pont csak az olvasást érinti, a tárolást nem.

• A titkosítatlan bejelentkezés megengedett. A cím ellenőrzése a http használatát is engedi a https mellett (cfg/login_lib.php, scanner/src/login.js). Ha az Ügyfél http protokollú bejelentkezési oldalt ad meg, a felhasználónév és a jelszó minden ellenőrzéskor titkosítatlanul halad át az interneten.
• A tanúsítványhibák nem állítják le a bejelentkezést. A bejelentkezés jelenleg nem szakad meg, ha az Ügyfél webhelyének tanúsítványa érvénytelen (scanner/src/login.js). A tanúsítvány ezért nem védi teljeskörűen a belépési adatokat az Ügyfél webhelyére vezető úton. A tanúsítványhibák esetén történő megszakítás tervezett intézkedés (9.3. szakasz, „elsőként” prioritás).
• A bejelentkezés mögötti rejtett mezők értékeit beolvassuk, de nem tároljuk. A bejáró beolvassa a rejtett mezők értékének első 24 karakterét (scanner/src/crawl.js), és ugyanez a kinyerési függvény fut a bejelentkezés mögött is (scanner/src/login.js). Ott a rejtett mezők gyakran fiókszámot, felhasználói azonosítót vagy a bejelentkezett fiók e-mail-címét tartalmazzák; a mezőtérképbe és a megállapításokba azonban csak a mező neve, típusa, címkéje és a felismerés eredménye kerül.

Ehhez járul az, amit a kód nem tud megakadályozni: az Ügyfél megerősíti, hogy a lehető legkevesebb jogosultsággal rendelkező tesztfiókot használ (cfg/login_lib.php), de megadhat valódi rendszergazdai fiókot is. Az ellenőrző által ezután beolvasott oldalakat az Ügyfél határozza meg; a kijelentkezésre és törlésre utaló szavakat tartalmazó címek blokkolva vannak, de a webhely által egyszerű kéréssel kiváltott egyéb műveletek nem.

Valószínűség – lehetséges. Súlyosság – súlyos, ha széles körű jogosultságokkal rendelkező fiók érintett; ekkor az összes felhasználó adatait tartalmazó tagi felület hozzáférhetővé válik. Szint – közepes kevés jogosultsággal rendelkező tesztfióknál, magas valódi fióknál. A fejlesztői rendszeren végzett mérés szerint nincs eltárolt tesztfiók.

R9 – Aktív tesztbeküldések és fájlellenőrzés az Ügyfél webhelyén

A tesztbeküldés azokhoz jut el, akik az Ügyfél űrlapjának e-mailjeit olvassák – a munkatársaihoz vagy egy szolgáltatóhoz. Nem tartalmaz személyes adatot: a feladó dummy@formexposed.com, a szöveg és a tárgy meg van jelölve, és tartalmazza az ellenőrzés azonosítóját (scanner/src/active.js). A kockázat a téves besorolásban rejlik: ha az ellenőrző egy jelentkezési, foglalási vagy tanácsadási űrlapot kapcsolatfelvételi űrlapnak tekintene, a tesztüzenet olyan folyamatba kerülne, amely következményekkel jár. Ezzel szemben állnak a „beküldhető” minősítés szigorú szabályai (scanner/src/classify.js), a hatóságok, oktatási intézmények, klinikák, orvosi rendelők, rendőrség és bíróságok domainjeinek blokkolása (scanner/src/classify.js), valamint a nyelvi modell kizárása ebből a döntésből (scanner/src/classify.js). A válaszból az állapotot, a célcímet, a címet, 300 karakternyi szöveget és egy képet tárolunk; ezek a tesztüzenetünkhöz kapcsolódnak.

A fájlellenőrzés legfeljebb 8 KB-ot olvas be tipikus elérési utakról. Ha ott valóban hozzáférhető egy adatbázismentés, ez a 8 KB látogatók által megadott űrlapadatokat is tartalmazhat. Ezeket csak jellegzetes mintázat szempontjából ellenőrizzük, majd eldobjuk (cfg/dateien_lib.php); az elérési utat, a típust és a súlyosságot tároljuk.

Valószínűség – csekély. Súlyosság – jelentős. Szint – alacsony. A fejlesztői rendszeren végzett mérés szerint egy aktív ellenőrzés található az adatkészletben, elfogadott beküldés nélkül.

R10 – Nyelvi modell általi besorolás

Azoknál az űrlapoknál, amelyeket a szabályok nem ismernek fel, a nyelvi modell megkapja az oldal címét, webcímét, a gombok szövegét, a mezők leírását és legfeljebb 400 karaktert az űrlap szövegéből (scanner/src/classify.js). Ez nevet is tartalmazhat, például: „Az Ön kapcsolattartója: …”. Saját szerverünkön fut; a kód alapján semmi nem jut harmadik félhez. Nem ellenőriztük, hogy a modell szoftvere naplózza-e a kéréseket. Eredménye csak a megjelenített űrlaptípust határozza meg, és nem tehet egy űrlapot beküldhetővé; a téves besorolás rosszabb megállapításhoz vezet, nem művelethez.

Valószínűség – csekély. Súlyosság – korlátozott. Szint – alacsony.

R11 – Közös tiltólista számos webhely jelentéseiből

A listán szereplő domain azt eredményezi, hogy az arra mutató hivatkozásokat tartalmazó üzenetek minden csatlakoztatott webhelyen karanténba kerülnek. Ha a domain egy magánszemélyhez tartozik – egy kézműveshez, egy fotóshoz, egy bloghoz –, a saját webhelyére mutató hivatkozást tartalmazó üzenetei késve jutnak el a címzettekhez. Az ilyen domain azért kerülhet a listára, mert spamküldők visszaélnek vele, vagy mert valaki szándékosan olyan, azt tartalmazó üzeneteket küld több webhelyre, amelyek nem mennek át az ellenőrzésen.

Ezzel szemben áll (cfg/swarm_lib.php): legalább három különböző webhely és öt találat hét napon belül; állandó kivételek a nagy szolgáltatásokra; Ügyfeleink domainjei soha nem kerülnek fel; kézi eltávolítás a szerveren található eszközzel; törlés helyett karantén; a lista naponta újraépül, és amiről már nem érkezik jelentés, az kiesik. Az érintettek nem láthatják a listát, és rajtunk kívül nincs saját lehetőségük az eltávolítás követelésére.

Valószínűség – lehetséges. Súlyosság – korlátozott, mert semmi nem vész el, és a címzett feloldhatja az üzenet zárolását. Szint – alacsony és közepes közötti. Az IP-hálózatok bekapcsolásával teljes szolgáltatók hálózatai lennének érintettek, az IP-címek személyes adatok, és a súlyosság jelentősre emelkedne: magas.

R12 – Jelentések és képernyőképek nyilvános hivatkozás alatt

Az ingyenes ellenőrzés, az érdeklődői ellenőrzés és az Ügyfelek domainjein végzett ellenőrzések jelentései bejelentkezés nélkül, véletlenszerű hivatkozás alatt érhetők el. A hivatkozás 128 bitnyi véletlenszerűséget tartalmaz, és nem található ki (cfg/check_lib.php). Az oldalak noindex jelölést kapnak, az alkalmazás olyan hivatkozóházirendet küld, amely csak az eredetet továbbítja (www/.htaccess), a képernyőképek pedig csak a hozzájuk tartozó jelentéssel együtt érhetők el; másik képszám „nem található” választ eredményez (www/shot.php). A kockázat nem kriptográfiai, hanem emberi: a hivatkozást továbbadják, bemásolják egy hibajegybe, megosztják egy csevegésben. Aki megnyitja, az minden más oldalmegtekintéshez hasonlóan csak az oldalelérési naplóban szerepel (60 nap), amelyben maga a hivatkozás csak maszkolt formában jelenik meg; jelentésenként nincs olvasói lista.

Valószínűség – lehetséges. Súlyosság – korlátozott, mert a jelentés csak nyilvános információkat mutat, és 30, illetve 90 nap után lejár; az Ügyfelek domainjeiről készült jelentések addig maradnak elérhetők, amíg az ellenőrzés létezik (13 hónapig, az utolsó ennél tovább). Szint – alacsony.

R13 – Az infrastruktúra gyengeségei

A következő pontok belső felülvizsgálati anyagunkban nyitottként szerepelnek, és itt sem szépítjük őket. Olyan pontossággal írjuk le őket, amilyenre az Ügyfeleknek saját értékelésükhöz szükségük van, de nem olyan részletességgel, hogy a leírás utat mutasson egy támadónak; a részleteket kérésre a felügyeleti hatóság rendelkezésére bocsátjuk.

• Az adatbázis biztonsági mentéseit jelenleg az adatbázissal azonos helyen tároljuk, és külön nem titkosítjuk; egy második helyszínen tárolt titkosított másolatot tervezünk (cfg/backup_lib.php). Addig nem védenek a helyszín elvesztése ellen, és aki megszerzi az adatbázist, a biztonsági mentéseket is megszerzi. A bejelentkezés mögötti ellenőrzés belépési adatait csak titkosított szövegként tartalmazzák.
• Az adatbázis tárolás közben nincs titkosítva. Kivételt képeznek az egyedileg titkosított mezők (a tesztfiókok belépési adatai, a kétfaktoros hitelesítés titkos kulcsa).
• A belső hálózatunkon belüli kapcsolatok nem mindenütt titkosítottak.
• Szerveradminisztráció. A szervereinkhez való adminisztratív hozzáférés biztonsága még nem felel meg az üzemeltetéshez kitűzött szintnek; a szerveradminisztráció biztonságának megerősítése folyamatban van.
• Ellenőrzési környezet. Az ellenőrzőszerver harmadik felek webhelyeit nyitja meg böngészőben. Az ellenőrző konténerek elkülönítettek – saját hálózat, különleges jogosultságok nélkül, csak olvashatóan, korlátozásokkal (scanner/src/worker.js). Az ellenőrzési környezet és a szolgáltatás többi része közötti elkülönítést tovább erősítjük (9.3. szakasz).

Valószínűség – lehetséges. Súlyosság – súlyos, mert vészhelyzetben minden egyszerre lenne érintett. Szint – magas. Az egyes pontok szokásos eszközökkel orvosolhatók (9.3. szakasz).

R14 – Érintetti jogok azok számára, akik nem ismernek minket

Aki véletlenül megjelenik egy képernyőképen, vagy akinek az üzenete ellenőrző másolatként áthaladt a rendszerünkön, rendszerint nem tud a létezésünkről. Még ha tud is róla, nincs kulcsa a „saját” adataihoz: ezeket nem személyenként, hanem domain és ellenőrzés szerint tároljuk. A 15. cikk szerinti hozzáférési kérelemre csak akkor tudunk válaszolni, ha az érintett megnevezi a domaint; ezután át tudjuk nézni a meglévő ellenőrzéseket és képeket. Valódi látogatói üzenetek esetében nincs mit kiadnunk, mert nem tároljuk őket – az R1-ben említett feladói domain kivételével. Az opt-out csak egy domain üzemeltetői számára működik, az ábrázolt személyek számára nem; nekik a contact@lukaswojcik.com címen történő megkeresés marad.

Valószínűség – valószínű, mint a rendszer felépítéséből adódó helyzet. Súlyosság – korlátozott, mert az adatok rövid életűek és nem személyenként vannak rendszerezve. Szint – alacsony.

9. (d) A kockázatok kezelésére irányuló intézkedések

Minden intézkedéshez állapot tartozik, és ezek az állapotok nem díszítőelemek. A jelenleg megvalósítva – ellenőrizve jelentése: a fejlesztői rendszer kódjában elolvastuk, és ahol lehetett, az adatbázis alapján megmértük. A részleges azt jelenti: a mechanizmus létezik, de célját még nem éri el teljesen. A tervezett azt jelenti: ez az értékelés javasolja, és még nem készült el; a tulajdonos dönt arról, hogy megvalósul-e és mikor. A még meghatározandó olyan eljárásokat és döntéseket jelöl, amelyeket semmilyen kód nem helyettesít. Az az adatvédelmi hatásvizsgálat, amely a tervezett intézkedéseket megvalósítottként tünteti fel, éppen abban a helyzetben veszíti el értékét, amelyben szükség lenne rá.

9.1 Jelenleg megvalósítva – ellenőrizve

Intézkedés	Kezelt kockázat	Forráshivatkozás
A bejáró minden ellenőrzés előtt beolvassa a robots.txt fájlt; a kezdőlapra vonatkozó kizárás, az elérhetetlen robots.txt vagy a szerverhiba lezárja az ellenőrzést (az alútvonalakat nem veszi külön figyelembe; az állapotjelzés, az igazolás lekérése, a fejlécvizsgáló eszköz és a fájlkeresés nem olvassa be)	R5, jogszerűség	scanner/src/net.js
Igazolás nélküli, azonnal hatályos opt-out a domainre és annak www változatára, névtelen ellenőrzésekre, érdeklődői ellenőrzésekre, tanulmányokra és Ügyfél-ellenőrzésekre (a folyamatos felügyelet a következő ütemezett ellenőrzéskor ér véget); kétszeri ellenőrzés (alkalmazás és ellenőrző szolgáltatás); csak mi oldjuk fel, kérésre és igazolással	R5, R7, 21. cikk	cfg/check_lib.php; cfg/akquise_lib.php; cfg/studie_lib.php; scanner/src/worker.js
Ingyenes ellenőrzés: vészleállító, reCAPTCHA, domainenként és hetente egy ellenőrzés, IP-címenkénti és munkamenetenkénti korlátok, napi felső határ, új domainek kizárása, csak nyilvános címek, rendellenességek esetén tartalom nélküli feljegyzés és jelzés	R5	cfg/check_lib.php
A korlátokhoz a munkamenetet csak hashértékként tároljuk, a munkamenet-azonosítót soha	Adattakarékosság	cfg/check_lib.php
Nincsenek mezőértékek (a rejtett mezők és adatattribútumok elejét csak az ellenőrzés során olvassuk be, 6.2. szakasz); a címzettek címei csak domainként; a szkriptcímekben található fiókazonosítók elrejtve	Adattakarékosság	scanner/src/crawl.js
Az ingyenes jelentés kivonat: csak alapvető megállapítások, nem tartalmazza az összes detektor bizonyítékait	R5	cfg/check_lib.php, FE_FREE_DETEKTOREN
Jelentések 128 bites véletlenszerű hivatkozás alatt, noindex, képek csak a saját jelentésükhöz, a nyilvános webkönyvtáron kívül; a hivatkozás az oldalelérési naplóban csak maszkolt formában jelenik meg	R12	cfg/check_lib.php; www/report.php; www/shot.php
Törlés: névtelen jelentések 30 nap után, érdeklődői ellenőrzések 90 nap után, Ügyfél-ellenőrzések 13 hónap után (domainenként az utolsót a domain fennállásáig megőrizzük), törölt domain adatai azonnal (a kivételeket lásd a 6.11. szakaszban), a képek minden esetben velük együtt	Korlátozott tárolhatóság	cfg/check_lib.php; cfg/fristen_lib.php
Tanulmány: közzététel csak összesítve, szegmensek csak legalább 20, űrlappal rendelkező webhelytől, nyers adatok törlése közzétételkor	R4 részben, P3	cfg/studie_lib.php
Ellenőrző konténerek: saját elkülönített hálózat, különleges jogosultságok nélkül, csak olvashatóan, memória- és folyamatkorlátok, időkorlát; minden kérésnél szűrő a privát célcímek ellen, a service workerek blokkolva, a WebSocket-kapcsolatok lezárva, hogy semmi ne kerülhesse meg a szűrőt; a webszerver kérései csak webes portokra és kizárólag az előzetesen ellenőrzött konkrét nyilvános címre	R13	scanner/src/worker.js; scanner/src/net.js
Aktív ellenőrzés Ügyfelek számára csak igazolt domainen (belsőleg saját teszt- és bemutató domainjeinken is), bekapcsolt vészleállítóval, kétszer ellenőrizve; legfeljebb öt beküldés; csak egyértelműen felismert kapcsolatfelvételi űrlapok, kötelező személyes adatok nélkül; hatóságok, oktatási intézmények, klinikák, orvosi rendelők, rendőrség és bíróságok domainjeinek kizárása; a nyelvi modell semmit nem engedélyezhet; személyes adatok nélküli, megjelölt tesztüzenet, hivatkozással a bejáró oldalára és az opt-out lehetőségére	R9	scanner/src/worker.js; scanner/src/classify.js; scanner/src/active.js
Böngészős folyamatok: csak GET és HEAD, veszélyes címek blokkolva, a kitalált értékek nem hagyják el a böngészőt, képek kitakart beviteli mezőkkel	R3 (ezeknél a képeknél), R9	scanner/src/browser.js
Fájlellenőrzés: csak igazolt domainek, elérési utanként egy lekérés, legfeljebb 8 KB, a tartalmat soha nem tároljuk	R9	cfg/dateien_lib.php
Második mérőpont: alapértelmezés szerint kikapcsolva; csak ártalmatlan elemek rögzített listáját kapná meg, aláírva	Címzettek	cfg/formular_probe_lib.php
Bejelentkezés mögötti ellenőrzés: csak igazolt domain, fizetős csomag, tulajdonos vagy rendszergazda, „tesztfiók” megerősítése; titkosítás az ellenőrzőszerver nyilvános kulcsával, a domainhez kötve; a belépési adatokat soha nem jelenítjük meg, nem naplózzuk és nem adjuk ki az API-n keresztül; átadás csak szabványos bemeneten; a feladat mezőjének azonnali ürítése, maradványok törlése egy óra után; képernyőképek, beküldések, kijelentkezési vagy törlési címek kizárása, megszakítás CAPTCHA esetén; végleges törlés felülírással	R8	cfg/login_lib.php; scanner/src/login.js; scanner/src/geheim.js; scanner/src/worker.js
Kézbesítés ellenőrzése: alapértelmezés szerint kikapcsolva; a lekérés csak a fejléceket és 8 KB-ot olvas be, olvasottsági jelölés nélkül; a tartalom és a látogató címe soha nem kerül az adatbázisba; minden lekért e-mail törlődik, a hozzá nem rendelhetők is; hozzárendelések törlése 180 nap után; igazolás csak pontosan az adott teszt másolatával	R1, R2	cfg/zustellung_lib.php
Rajvédelem: csak domainek, IP-hálózatok kikapcsolva; minimális darabszámok; kivételek a nagy szolgáltatásokra és az Ügyfelek domainjeire; törlés helyett karantén; a lista naponta újraépül; jelentések törlése 30 nap után	R11	cfg/swarm_lib.php
Nyelvi modell saját szerverünkön, beküldési jogosultság nélkül	R10	scanner/src/classify.js
A Telegramon küldött jelzések csak rögzített mondatot tartalmaznak, változók nélkül	Címzettek	cfg/check_lib.php
A biztonsági mentés heti visszaállítási próbája, hiba esetén riasztással	Rendelkezésre állás	cfg/backup_lib.php; srv/cron_status.php

9.2 Részleges – létezik, de célját még nem éri el

Intézkedés	Miért nem teljesen hatékony még
„Tisztított” képernyőképek	Csak a böngészős folyamatok képein történik kitakarás. A bejáró képein – a kezdőlapon és az űrlapelemeken – és az aktív ellenőrzés válaszoldalának képén nem (R3).
Az ellenőrzési adatok megőrzési ideje	Hatékony a névtelen, az érdeklődői és az Ügyfél-ellenőrzéseknél; a belső ellenőrzéseknél és a közzé nem tett tanulmányoknál nem; a le nem zárt rendellenességi feljegyzések időkorlát nélkül maradnak meg (R4).
Az ellenőrző másolatok törlése	A postafiók általunk látható állapotában hatékony. Ha a futás megszakad, az e-mailek megmaradnak; nem ellenőriztük, mit őriz meg a postafiók-szolgáltató a saját biztonsági mentéseiben (R2).
A belépési adatok védelme a bejelentkezés mögötti ellenőrzésben	Tárolás közben és az ellenőrző szolgáltatásban erős; a webhelyhez vezető úton nem: a http megengedett, a tanúsítványhibákat figyelmen kívül hagyja (R8).
A rendelkezési jogosultság igazolása	Egyszer ellenőrizzük, utána örökre érvényes; az igazolt rendelkezési jogosultsággal rendelkező domain hosztneve azonban nem módosítható, így az igazolás nem kerül át másik hosztra (R7).
Az érintettek tájékoztatása	Az üzemeltetők számára rendelkezésre áll a bejáró oldalán, az azonosítón, az Adatvédelmi tájékoztatón és az opt-out lehetőségén keresztül; a kézbesítés ellenőrzésével érintett látogatóknál attól függ, hogy az Ügyfél átveszi-e a szövegblokkot; az alkalmazás ezt nem ellenőrzi.
Kérés az Ügyfelekhez, hogy különleges adatkategóriák ne kerüljenek az ellenőrző másolatba	A jogi dokumentumokban szerepel, de nincs technikai támogatása: a beállítás során az alkalmazás nem kérdez rá a webhely típusára, és nem figyelmeztet az egészségügyi, jogi vagy oktatási jellegűnek tűnő domaineknél (R1).

9.3 Tervezett – még nem megvalósított

Intézkedés	Kezelt kockázat	Prioritás
Törlési eljárás a belső ellenőrzésekhez: a domain és jelentés nélküli ellenőrzések törlése meghatározott idő után (javaslat: 30 nap); a tanulmány nyers adatainak törlése legkésőbb a befejezése után meghatározott idővel, közzététel nélkül is (javaslat: 90 nap); a meglévő 85 ellenőrzés és 369 kép egyszeri törlése	R4	Elsőként
A kézbesítés ellenőrzésének engedélyezése csak akkor, ha a postafiók-szolgáltatóval megkötöttük a szerződést, dokumentáltuk a tárolási helyeket, a további adatfeldolgozókat és a biztonsági mentések megőrzési idejét, tisztáztuk a postafiók-szolgáltatóra vonatkozó adattovábbítási mechanizmust, és domainünk MX-rekordjai közvetlenül a postafiókra mutatnak; addig a funkció maradjon blokkolva az éles rendszerben	R2	Elsőként
A postafiók lekérésének biztonságát az éles rendszeren ellenőrizni és dokumentálni kell a kézbesítés ellenőrzésének engedélyezése előtt	R2	Elsőként
Bejelentkezés mögötti ellenőrzés csak https protokollal és érvényes tanúsítvánnyal; http címek elutasítása; a bejelentkezéskori tanúsítványhiba megszakítási ok legyen	R8	Elsőként
A bejelentkezés mögötti rejtett mezők értékeit ne tároljuk (csak a nevet, típust és hosszt) – már így van megvalósítva, további lépés nem szükséges	R8	Kész
Ahol a bővítmény vagy a kiegészítő használatban van, az ellenőrző másolat korlátozása a tesztüzenetekre: titkos másolat csak a tesztazonosítónkat tartalmazó beküldéseknél	R1	Magas
A valódi üzenetek feladói domainjét ne tároljuk és ne írjuk a riasztásokba, ha az sem a webhely domainje, sem ismert küldő szolgáltatásé; a riasztásban helyette „idegen feladói domain” szerepeljen	R1	Magas
Figyelmeztetés a kézbesítés ellenőrzésének beállításakor az egészségügyi, jogi, szociális vagy oktatási jellegűnek tűnő domaineknél, hivatkozással az Ügyfél saját adatvédelmi hatásvizsgálatára	R1	Magas
A rendelkezési jogosultság igazolásának rendszeres megújítása (javaslat: minden aktív ellenőrzés előtt ellenőrizzük, hogy a DNS-rekord, metacímke, fájl vagy bővítménykapcsolat továbbra is létezik-e; ellenkező esetben passzívan folytassuk, és értesítsük az Ügyfelet)	R7	Magas
Ne készítsünk több képet a kezdőlapról, vagy csak kitakart képekkel és arcokkal; az űrlapképeket korlátozzuk az űrlapelemre (ahogyan jelenleg), és a beviteli mezőket a böngészős folyamatokhoz hasonlóan maszkoljuk	R3	Magas
Figyelmeztetés az érdeklődői ellenőrzés felületén: a rövid megállapítás kéretlen elküldése e-mailben vagy telefonon vállalkozások között is közvetlen üzletszerzés, és előzetes hozzájárulást igényel (a lengyel elektronikus hírközlési törvény 398. cikke; Németországban az UWG 7. § (2) bekezdése, bár vállalkozások telefonos megkeresésénél elegendő a vélelmezett hozzájárulás)	R6	Magas
Infrastruktúra: a szerveradminisztráció biztonságának megerősítését be kell fejezni; a biztonsági mentés titkosított másolata második helyszínen; a belső hálózati kapcsolatok teljes körű titkosítása; az ellenőrzőszerver és az alkalmazás elkülönítésének további erősítése	R13	Magas
Megőrzési idő a le nem zárt rendellenességi feljegyzésekhez (javaslat: lezárás 30 napon belül, egyébként az IP-cím törlése)	R4	Közepes
Oldal vagy űrlap, amelyen keresztül kérhető egy domain eltávolítása a rajvédelemből	R11, R14	Közepes
Az IP-hálózatok rajvédelemben történő bekapcsolása előtt: az értékelés új változata	R11	Feltétel
Rögzíteni kell, hogy a nyelvi modell szoftvere tárolja-e a kéréseket, és ha igen, ki kell kapcsolni ezeket a naplókat	R10	Alacsony

9.4 Még meghatározandó eljárások és döntések

A technikai garanciák mellett a 35. cikk (7) bekezdés d) pontja eljárásokat is előír. Ezek még hiányoznak:

• Adatvédelmi incidens. Észlelés: a tulajdonos, az alkalmazás hibariasztása, bejelentések a sérülékenység-bejelentő ponton vagy a contact@lukaswojcik.com címen. Döntés az UODO 72 órán belüli értesítéséről (33. cikk (1) bekezdés): a tulajdonos. Az érintett Ügyfelek mint adatkezelők tájékoztatása: indokolatlan késedelem nélkül, lehetőség szerint 48 órán belül, az Adatfeldolgozási szerződésben vállaltak szerint. Még meghatározandó: írásos eljárásleírás és egy első gyakorlat; a kézbesítés ellenőrzése esetében ezenfelül annak módja, hogyan állapítható meg, mely Ügyfeleket érinti a postafiók-szolgáltatónál bekövetkező incidens.
• Ágazatok. Még meghatározandó: az egészségügyi, jogi, szociális és oktatási webhelyek számára a kézbesítés ellenőrzését kínáljuk-e, figyelmeztetéssel kínáljuk-e, vagy kizárjuk.
• Belső ellenőrzések. Még meghatározandó: mire használja a szolgáltató a parancssorból indított belső ellenőrzéseket, ki hozhatja létre őket és meddig maradnak meg az eredményeik; továbbá az Adatkezelési tevékenységek nyilvántartásán túl az Adatvédelmi tájékoztatóban is meg kell-e nevezni őket.
• Tanulmányok. Még meghatározandó: ki állítja össze a listákat, milyen forrásokból, mekkora maximális mérettel, valamint minden tanulmány előtt ellenőrizni kell, hogy megfelel-e ezen értékelés feltételezéseinek.
• Az érintettek véleménye (35. cikk (9) bekezdés). Ehhez a változathoz nem kértük ki. A 35. cikk (9) bekezdése csak „adott esetben” írja elő a véleményük kikérését; értékelésünk szerint ez itt jelenleg nem indokolt. Az ellenőrzött webhelyek üzemeltetőinek és az Ügyfelek webhelyei látogatóinak nincs saját kapcsolati csatornájuk hozzánk; célzott megkeresésük önmagában is adataik újabb kezelését jelentené, és a szolgáltatás még nem indult el, így tényleges érintetti csoport sem létezik még. Érdekeiket közvetetten vesszük figyelembe: a robots.txt és az opt-out révén, a rövid megőrzési időkkel és azzal, hogy az ellenőrző másolatok tartalmát nem tároljuk. A 12. szakasz szerinti minden felülvizsgálatkor újra megfontoljuk, hogy indokolt-e a véleményük kikérése, például a bejáró oldalán adott visszajelzéseken keresztül vagy a kézbesítés ellenőrzését használó Ügyfelektől.

10. Fennmaradó kockázat és előzetes konzultáció a 36. cikk alapján

A 36. cikk (1) bekezdése előzetes konzultációt ír elő a felügyeleti hatósággal, ha az adatvédelmi hatásvizsgálat szerint az adatkezelés az adatkezelő által a kockázat mérséklése érdekében tett intézkedések hiányában magas kockázattal járna. A kérdés tehát nem az, hogy azonosítottunk-e magas kockázatokat – négyet azonosítottunk –, hanem az, hogy az intézkedések bevezetése után is fennmarad-e magas kockázat.

Azoknál az adatkezelési műveleteknél, amelyeknél a formexposed az adatkezelő (P1–P4, P7), az R4 és R13 magas kockázata szokásos eszközökkel orvosolható: törlési eljárással és a meglévő adatok megtisztításával, titkosított, más helyszínen tárolt biztonsági mentéssel és két szerver biztonságának megerősítésével. A 9.3. szakasz intézkedéseivel alacsony és közepes közötti szintre csökkennek. Az R3, R5, R6 és R7 közepes szintű, és a javasolt intézkedésekkel alacsonyra csökken. Az IP-hálózatok nélküli rajvédelem alacsony és közepes közötti marad. Ennél a résznél az előzetes konzultáció nem indokolt, ha az „elsőként” és „magas” jelölésű intézkedéseket az indulás előtt megvalósítják. Ha ezek közül bármelyik intézkedés az indulás előtt nem valósul meg, az érintett adatkezelési műveletnél magas kockázat marad fenn. Az adott adatkezelési műveletet ilyenkor csak az intézkedés megvalósítása után indítjuk el, vagy előbb konzultálunk az UODO-val a 36. cikk (1) bekezdése alapján.

A kézbesítés ellenőrzésénél (P6) más a helyzet, olyan okból, amelyet egyetlen intézkedés sem szüntet meg teljesen: a látogató maga dönti el, mit ír. Megkötött szerződéssel, biztonságos lekéréssel, ahol lehetséges, a tesztüzenetekre való korlátozással és a feladói domain elhagyásával az R2 alacsonyra, az R1 közepesre csökken. Azoknál az Ügyfeleknél azonban, akiknek a látogatói jellemzően a 9. cikk szerinti adatokat adnak meg, az R1 továbbra is magas maradhat. A konzultációs kötelezettség ilyenkor az Ügyfelet mint adatkezelőt terheli, nem a formexposed szolgáltatást. Az ilyen Ügyfeleknek azt javasoljuk, hogy az ellenőrző másolatot ne az általános kapcsolatfelvételi űrlaphoz állítsák be, hanem csak érzékeny tartalom nélküli űrlapokhoz, vagy mondjanak le a kézbesítés ellenőrzéséről.

A fennmaradó kockázat őszinte bemutatása. Jelenleg, a 9.1. szakasz intézkedéseivel négy kockázat magas szintű: R1 és R2 (kézbesítés ellenőrzése), R4 (ellenőrzési adatok törlési eljárás nélkül) és R13 (infrastruktúra). A 9.3. szakasz intézkedéseivel az R2, R4 és R13 alacsony és közepes közötti szintre csökken. Az R1 közepes marad, és tartósan az Ügyfelek döntéseitől függ. Az intézkedések után a többi kockázat egyike sem haladja meg a közepes szintet.

A 36. cikk nem büntetés, és a konzultáció nem beismerés. Ez a rendelet által biztosított eljárás arra a helyzetre, amikor egy hasznos eljárás olyan kockázattal jár, amelyet az adatkezelő nem tart teljesen ellenőrzése alatt. Az az Ügyfél, aki egészségügyi adatokat tartalmazó üzenetekhez szeretné használni a kézbesítés ellenőrzését, itt megtalálja a döntéshez szükséges tényeket.

11. Mire van szükségük az Ügyfeleknek a saját adatvédelmi hatásvizsgálatukhoz (28. cikk (3) bekezdés f) pont)

A kézbesítés ellenőrzésénél és a bejelentkezés mögötti ellenőrzésnél az Ügyfél az adatkezelő. Ez az oldal biztosítja számára a leírást (6.5. és 6.6. szakasz), a kockázatokat a mi szemszögünkből (R1, R2, R8) és az intézkedések állapotát (9. szakasz). A következő kérdésekre csak az Ügyfél tud válaszolni:

1. Mit írnak a látogatóim? Várható-e, hogy az űrlapon keresztül egészségre, vallásra, származásra, szakszervezeti tagságra, szexuális irányultságra, bűncselekményekre vagy gyermekekre vonatkozó adatok érkeznek? Ilyenkor az ellenőrző másolathoz rendszerint adatvédelmi hatásvizsgálat szükséges, és újra meg kell fontolni az ellenőrző másolat alkalmazását ennél az űrlapnál.
2. Minden üzenethez szükségem van az ellenőrző másolatra? A tesztüzenetünk megérkezésének igazolásához elegendő annak a másolata. Ahol az űrlap lehetővé teszi, a titkos másolatot csak a tesztüzenetekhez állítsa be.
3. Hogyan tájékoztatom a látogatóimat? Az Adatfeldolgozási szerződés ezt előírja; az Adatvédelmi tájékoztató szövege az Ön webhelyéhez ismerteti a másolat útját és a szerepünket.
4. Milyen jogalappal rendelkezem? Javasolt szövegünk a 6. cikk (1) bekezdés f) pontját nevezi meg (a megkeresések megbízható fogadása). A 9. cikk szerinti adatoknál ez a jogalap önmagában nem elegendő.
5. Mely riasztási csatornákat választom? A hitelesség ellenőrzéséből származó riasztások megnevezhetik a feladói domaint. Aki EU-n kívüli csevegőszolgáltatásoknak küld riasztásokat, oda továbbítja azt.
6. A bejelentkezés mögötti ellenőrzésnél: Valóban a szükséges legkisebb jogosultságokkal rendelkező tesztfiók a tesztfiók? A bejelentkezési oldal csak https protokollal érhető el? Látja a tesztfiók más felhasználók adatait? Ha igen: a megadott oldalak közül melyeken?
7. Mikor törlök? A kézbesítés ellenőrzése és a tesztfiók bármikor kikapcsolható és törölhető; a tesztfiókot ekkor véglegesen felülírjuk.

További dokumentumok az Ügyfél értékeléséhez: az Adatfeldolgozási szerződés, a műszaki és szervezési intézkedések, a további adatfeldolgozók listája és az Adatkezelési tevékenységek nyilvántartása. Az egyes tényekkel kapcsolatos kérdésekre a contact@lukaswojcik.com címen válaszolunk.

12. Felülvizsgálat, változat és jóváhagyás

A 35. cikk (11) bekezdése felülvizsgálatot ír elő annak értékelésére, hogy az adatkezelés az adatvédelmi hatásvizsgálatnak megfelelően történik-e, legalább akkor, ha a kockázat megváltozik. Ezt az értékelést legalább évente, valamint az alábbi események mindegyike előtt felülvizsgáljuk; mindegyik új mérést vált ki, nem csupán átolvasást:

• az éles üzem indulása, a fejlesztői rendszer helyett az éles rendszer számaival;
• a kézbesítés ellenőrzésének első aktiválása az éles rendszeren és a szerződés megkötése a postafiók-szolgáltatóval;
• az IP-hálózatok bekapcsolása a rajvédelemben;
• az első tanulmány és minden olyan tanulmány, amely az előzőnél nagyobb listával dolgozik;
• a második mérőpont vagy új címzett bekapcsolása az ellenőrzési útvonalba;
• a nyelvi modell minden olyan új felhasználása, amely túlmutat az űrlapok besorolásán és a „Fix it for me” funkción;
• a képernyőképek, a megőrzési idők vagy az aktív ellenőrzések előfeltételeinek bármilyen változása.

Tétel	Bejegyzés
Adatkezelő	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Lengyelország · NIP 7252266190 · contact@lukaswojcik.com
Illetékes felügyeleti hatóság	Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Moniuszki 1A, 00-014 Warszawa, Lengyelország
Adatvédelmi tisztviselő	Nincs kijelölve; a 37. cikk szerinti értékelés a 4. szakaszban
A tények alapja	Az alkalmazás és az ellenőrző szolgáltatás forráskódja, adatbázissémája, a fejlesztői rendszer sorainak száma és beállításai, 2026. október 11-én mérve, csak olvasási hozzáféréssel
Kapcsolódó dokumentumok	Adatvédelmi tájékoztató, Adatfeldolgozási szerződés, Műszaki és szervezési intézkedések, További adatfeldolgozók, Adatkezelési tevékenységek nyilvántartása, Az EU mesterséges intelligenciáról szóló rendelete, Elfogadható használat és visszaélés, FormExposedBot, Opt-out
Változat	1.0, 2026. október 11., első változat
A 35. cikk (11) bekezdése szerinti felülvizsgálatok	Még nem történt (első változat). Minden felülvizsgálatot itt rögzítünk a dátummal, az okkal és az eredménnyel.
Jóváhagyás	Még nincs jóváhagyva. A tulajdonos hagyja jóvá jogi felülvizsgálat után, valamint a 9.3. szakasz intézkedéseiről és a 9.4. szakasz kérdéseiről hozott döntés után. Külső adatvédelmi tanácsadást eddig nem vettünk igénybe.

Egy záró megállapítás a dokumentumba tartozik, nem kísérőlevélbe. A formexposed azon részei, amelyek a legmélyebben nyúlnak be mások domainjeibe – a tesztbeküldések és a más belépési adataival történő bejelentkezés –, a legnagyobb körültekintéssel készültek: két ellenőrzési kapu, szigorú felső korlátok, olyan titkosítás, amely még minket is kizár. Az értékelés kockázatai többnyire máshol rejlenek: abban, ami mellékesen kerül a rendszerbe – valódi üzenetek egy titkos másolatban, emberek egy képernyőképen, ellenőrzések, amelyeket már senki nem töröl. Ez kedvező kiinduló helyzet, mert a járulékos adatkezelés a szolgáltatás megváltoztatása nélkül megszüntethető.