Gyakran kapom a kérdést ügyfeleimtől: „Ha nem használok cookie-kat, akkor megkerülhetem a GDPR-t és a hozzájárulás kérését?” A rövid válasz az, hogy kategorikusan nem. Ebben a bejegyzésben megvizsgáljuk, milyen elképesztő szintre lépett a fingerprinting technológia 2026-ra, és mik ezeknek a rendszereknek az adatvédelmi, jogi vonzatai.

Mi is az a Fingerprinting és miért veszélyes?

A hagyományos sütik apró szöveges fájlok, amiket a böngésző eltárol. Ezzel szemben az ujjlenyomat-készítés (fingerprinting) semmit sem tölt le az Ön gépére. Ehelyett a háttérben futó kódok lekérdezik az Ön eszközének és böngészőjének egyedi hardveres és szoftveres jellemzőit.

A módszer ereje abban rejlik, hogy mélyen a rendszerből fakadó jelekre épül, így inkognitó módban, vagy akár VPN használata mellett is ugyanaz marad az azonosítója. Nem lehet csak úgy „letörölni”, mint egy sütit.

A legújabb technológiák 2026-ban

Míg korábban a fingerprinting főleg a képernyőfelbontásra és a telepített betűtípusokra épült, mára a rendszerek több száz apró jelet kombinálnak. Íme a legfontosabbak:

1. WebGPU és grafikus ujjlenyomatok

A korábbi Canvas és WebGL technikák mellett a WebGPU széleskörű elterjedése lehetővé tette, hogy a weboldalak még mélyebben hozzáférjenek a videókártya (GPU) paramétereihez. Mivel minden grafikus processzor mikroszkopikus mértékben eltérően végez el bizonyos renderelési feladatokat, ez egy rendkívül stabil hardveres jelet ad.

2. Audio Fingerprinting (Hang alapú azonosítás)

A böngésző Web Audio API-ját használva a rendszer egy nagyon alacsony frekvenciájú, emberi füllel nem hallható hanghullámot generál. A processzor és a szoftveres környezet apró matematikai kerekítési hibáiból és jelfeldolgozási sajátosságaiból egy teljesen egyedi „hang ujjlenyomat” jön létre.

És ami adatvédelmi szempontból az egész módszer egyik legfélelmetesebb (és egyben legzseniálisabb) része: mindezt teljesen mikrofon engedély nélkül éri el! Mivel a weboldal nem a külvilág hangjait rögzíti, hanem a gép processzorával generáltat „virtuális hangot” a memóriában (majd azon végez torzításokat), a böngésző semmilyen engedélykérő ablakot nem dob fel. A folyamat teljesen némán, a háttérben zajlik le a másodperc töredéke alatt, anélkül, hogy Ön bármit is észrevenne.

3. Viselkedésalapú biometria (Behavioral Signals)

Az egyik leggyorsabban fejlődő terület. Már nem csak azt nézik, milyen a gépe, hanem azt, hogy Ön hogyan használja azt. Az egérmozgás íve, a görgetés sebessége, a gépelési ritmus, és mobilon a képernyő megérintésének ereje mind olyan egyedi paraméterek, amikből a felhasználó fizikai valójában azonosítható.

4. Hálózati rétegű ujjlenyomat (TLS Fingerprinting)

A böngésző mellett a hálózati kommunikációt is figyelik. A titkosítási kapcsolat (SSL/TLS kézfogás) felépítése során küldött adatcsomagok sorrendje és a támogatott titkosítási algoritmusok alapján pillanatok alatt kiszűrik, ha valaki VPN-t vagy anti-detect böngészőt használ.

5. AI-alapú integrált azonosítás

A legmodernebb rendszerek a fenti adatokat már mesterséges intelligenciával (AI) kombinálják és elemzik. Még ha meg is próbálja megváltoztatni néhány adatát, a gépi tanulási modellek a fennmaradó mintázatokból akár 99,7%-os pontossággal felismerik Önt.

Adatvédelmi megítélés: Sütimentes, tehát szabályos?

A leggyakoribb tévhit a weboldal-üzemeltetők körében, hogy a cookie-kon kívüli technológiák szabadon használhatók. Ez hatalmas tévedés. A jogszabályok nem csupán a konkrét „cookie” szót tiltják vagy kötik hozzájáruláshoz, hanem az adatoknak a felhasználó végberendezésén történő tárolását, vagy az ott tárolt adatokhoz való hozzáférést (ePrivacy irányelv).

• Hozzáférés a végberendezéshez: Bár a fingerprinting nem tárol adatot a gépen, hozzáfér a hardveres és szoftveres konfigurációkhoz (szenzorok adatai, grafikus/audio számítási sajátosságok). Az Európai Adatvédelmi Testület (EDPB) iránymutatásai ezt egyértelműen a cookie-kal egyenértékű megfigyelésnek minősítik. Következésképpen: alkalmazásához kifejezett, előzetes, és önkéntes hozzájárulás (opt-in) szükséges.
• Személyes adat: Egy egyedi hash (ujjlenyomat), amit azért generálnak, hogy a felhasználókat megkülönböztessék, egyértelműen azonosítóvá válik. Így az adatkezelés teljes mértékben a GDPR hatálya alá esik.

Mit tehet az adatkezelő?

Ha Ön weboldal tulajdonos, és harmadik féltől származó szolgáltatásokat (pl. hirdetési rendszereket, haladó analitikát) használ, feltétlenül vizsgáltassa meg, hogy ezek alkalmaznak-e fingerprinting technikákat.

Az Adatkezelési Tájékoztatóban pontosan fel kell tüntetni az alkalmazott technológiát, és a Consent Management Platformon (süti sávon) keresztül előzetes engedélyt kell kérni a felhasználóktól. Kivételt csak a tisztán kiberbiztonsági vagy csalásmegelőzési (anti-fraud) célú, feltétlenül szükséges elemzések jelenthetnek – szigorú érdekmérlegelés mellett.

Gyakran kapom meg a kérdést ügyfelektől: „Eltávolítottuk a neveket az Excelből, ez így már anonim, ugye?” A válaszom eddig is egy határozott „nem” volt, de az Európai Adatvédelmi Testület (EDPB) legújabb, 02/2026-os iránymutatása most végleg rendet tesz a fogalmak között. A dokumentum alapjaiban változtatja meg – vagy legalábbis finomítja – azt, ahogyan az anonimizálásra, mint folyamatra és mint eredményre tekintenünk kell.

Nézzük meg a legfontosabb gyakorlati kérdéseket, határeseteket és a legújabb EDPB-tesztet!

1. Az adatfeldolgozó anonim módon kezelné az adatot

Az új iránymutatás bevezeti a relatív (kontextuális) anonimitás fogalmát: ami az egyik entitás számára személyes adat, az egy másik számára lehet anonim. Felmerül bennünk a kérdés, hogy ha én, mint adatkezelő anonimizálom az adatokat (pl. csak userID-t hagyok meg), és így adom át az adatfeldolgozómnak, akkor ő már nem is kezel személyes adatot?

A válasz: De igen, az adatfeldolgozó minden esetben személyes adatot kezel.

Az EDPB kimondja, hogy ha egy entitás az adatkezelő nevében és utasításai alapján jár el (azaz adatfeldolgozó), akkor az adat minőségét az adatkezelő szemszögéből kell megítélni. Mivel az adatkezelőnél ott van a feloldó kulcs (ő tudja, ki az a userID), az adat jogilag az adatfeldolgozó szintjén is személyes adat marad, hiába nem tudja ő maga azonosítani az érintettet.

2. A kórház és a kutatóintézet esete: Mi van, ha a kutató profilozik?

Vegyünk egy másik példát. Egy kórház kutatási célból továbbítja a betegnyilvántartás kivonatait (kulcs a kórháznál marad) egy teljesen független kutató cégnek. Mivel a cég önálló adatkezelő, a relatív megközelítés alapján az ő szemszögükből kell vizsgálni az adatot. Ha önmagukban az adatok nem teszik lehetővé az azonosítást, a továbbítás megtörténhet, a kutató cég számára az adat anonim.

De mi történik, ha azt vélelmezzük, hogy a sok hasonló kutatás miatt (pl. vénykiváltási adatokat is kap), összeállnak a profilok? Ha a kutató cég észszerűen alkalmazható eszközökkel (jegyezzük meg: MRLTBU) képes összekapcsolni ezeket a különböző forrásból származó adatbázisokat, és ezáltal a profilok egyedivé, „kigyűjthetővé” válnak, az anonimitás elbukik.

És amúgy, ha a kutató utólag érzékeli, hogy a kapott adatokból (akár névvel, akár név nélkül) profilokat tud létrehozni és azonosítani tudja a személyeket, akkor mit kell tegyen? Abban a pillanatban, hogy a kutató felismeri az azonosíthatóságot, az adat visszaváltozik személyes adattá. Innentől kezdve a kutatóra a GDPR teljes szigora vonatkozik: meg kell határoznia az adatkezelés jogalapját, tájékoztatási kötelezettsége van , és garantálnia kell az adatbiztonságot, vagy egyszerűen csak törli az adatokat.

3. Az alapok, amik nem változtak

• A pszeudonim adat továbbra is személyes adat. Az álnevesítés (pszeudonimizálás) pusztán egy biztonsági intézkedés, nem anonimizálás. Ha a kulcs létezik, az adat a GDPR hatálya alatt marad.
• A fénykép, amin valaki felismerhető, továbbra is személyes adat. Nem számít, hogy az adatkezelő személy szerint ismeri-e a fotón látható illetőt. Ha a világon valaki más (családtag, barát, arcfelismerő szoftver) észszerű eszközökkel azonosítani tudja, a fotó személyes adat.

4. Az anonimizálás miatt módosítsunk minden tájékoztatót?

Hm, az EDPB egyértelművé teszi: maga az anonimizálás is adatkezelési művelet, így jogalapra van szükség a végrehajtásához (pl. a korábbi adatkezeléssel összeegyeztethető cél, vagy különleges adatoknál a 9. cikk szerinti garancia).

Emiatt módosítsunk minden adatkezelési tájékoztatót? A rövid válasz: Igen. Az EDPB szerint a transzparencia elve (13-14. cikk) megköveteli, hogy az érintetteket már az adatfelvételkor (vagy legkésőbb a megőrzési idő végén) tájékoztassuk arról, hogy az adataikat a jövőben anonimizálni fogjuk, és azok kikerülnek a GDPR hatálya alól.

5. Az „elhanyagolható” kockázat és a kiberbűnözők fenyegetése

Fontos változás a korábbi (WP216-os) zéró-kockázat elváráshoz képest: azonosítás valószínűsége már nem 0 kell legyen, hanem a valóságban elhanyagolható.

De vigyázat! Ha az adatkezelő nem is tudja saját eszközeivel beazonosítani az egyént, de észszerű kereteken belül igénybe tud venni egy partner eszközt, akkor is személyes adatkezelésről beszélünk. Sőt, az értékelésnél figyelembe kell venni az illegális hozzáférőket is: egy rosszindulatú alkalmazottat, egy hackert, vagy a hatóságokat, amennyiben reális az esélye annak, hogy ők hozzáférnek az adathoz és azonosítják az érintettet.

Ahogy az EDPB (és a kapcsolódó joggyakorlat) olyan szépen megfogalmazza:

„Következesképpen egy természetes személy akkor is azonosítható, ha a szükséges információk egy része – vagy az azonosításra szolgáló eszközök egy része – különböző szervezetek között oszlik meg, és azok megszerzése erőfeszítést igényel, feltéve, hogy ezek az elemek az érintett szervezetek által észszerűen várhatóan alkalmazott eszközökkel összekapcsolhatók.”

6. A technikai teszt: A hármas kritériumrendszer

Az anonimitás tesztelésére az EDPB egy hármas kritériumrendszert állított fel. Ha mindhárom teljesül, az adat anonim.

1. No Record Isolation (Nincs rekord-elkülönítés): Az adatkészlet nem tartalmazhat olyan egyedi attribútum-kombinációt (sorokat, oszlopokat), amely alapján egyetlen egyén „kigyűjthető” a tömegből. Ha az első ponton elbukunk (van egyedi attribútum), már tudjuk, személyes adatot kezelünk.
2. No Linkage (Nincs összekapcsolhatóság): Az adatok nem tehetők összekapcsolhatóvá más adatkészletekben lévő rekordokkal oly módon, hogy az ugyanarra a személyre vonatkozzon.
3. No Inference (Nincs következtetés): Ez az MI korában a legfontosabb. Az adatból nem vonható le specifikus és érdemi következtetés az azonosított egyénre vonatkozóan.

Nézzük a 16. és 17. példát az iránymutatásból a következtetések veszélyeire :

• 16. példa (Aggregált béradatok): Egy cég publikálja, hogy a mérnökök összesített fizetése évi 550.000 euró. Egy belső jelentésből kiderül, hogy a cégnek 6 mérnöke van, ebből 5 a termékfejlesztésen dolgozik, akiknek az összfizetése 480.000 euró. Ebből a látszólag két anonim, aggregált adatból egy kis matekkal azonnal kikövetkeztethető, hogy a 6. mérnök pontosan 70.000 eurót keres.
• 17. példa (Az „anonim” kérdőív): Egy cég elégedettségi felmérést végez. A vezetők csak annyit látnak, hányan adtak 1-től 5-ig terjedő értékelést. Ha egy vezető megtudja, hogy a csapatából mindenki kitöltötte a tesztet, és senki sem adott 3-asnál jobb jegyet, hiába nincs név az adatok mellett, azonnal kikövetkezteti, hogy a csapatában egyénileg mindenki elégedetlen.

7. Adatlopásra készülve…

Az EDPB 22. példája ellentmondásosnak tűnik. Egy kutatóintézet birtokában lévő táblázat (ahol a nem, születési év és irányítószám látszik) No Linkage (összekapcsolhatóság) vizsgálatánál az intézet elismeri, hogy az adatokat elméletileg ellophatják hackerek, vagy megkaphatják újságírók. Mégis arra a következtetésre jutnak, hogy az adat anonim marad.

Miért nem veszik számításba a nyilvánosságra hozatalt?

A trükk a „reálisan alkalmazható eszközök” (MRLTBU) logikájában rejlik. Az iránymutatás szerint hiába lopja el a hacker az adatot, a táblázatban nincs benne, hogy kik vettek részt a kutatásban, és a hackernél vagy az újságírónál sincs meg ez a háttérinformáció. Tehát még ha a tolvaj látja is, hogy „Férfi, 1946, 54-es irányítószám”, fogalma sincs arról, hogy a világon létező sok ezer ilyen profilú emberből ki az az egy konkrét személy, aki az adott kórház kutatásában részt vett. Mivel az összekapcsoláshoz szükséges „kiegészítő információ” (a kutatásban való részvétel ténye) senkinél nincs meg, az adat a kiszivárgás ellenére is anonim marad.

8. Az EDPB technikai elemzési folyamatábrája (magyarosítva)

Az EDPB az iránymutatás 1. mellékletében egy rendkívül hasznos döntési fát (folyamatábrát) publikált. Íme a lépések magyarul, amelyek segítenek a mindennapi döntésekben:

Az Európai Bizottság a napokban közzétette a „Digital Omnibus” nevű javaslatcsomagját, amely hivatalosan a digitális egységes piac szabályainak egyszerűsítését és a GDPR adminisztratív terheinek csökkentését célozza. Azonban a noyb (None of Your Business), Max Schrems vezette digitális jogvédő szervezet legfrissebb elemzése szerint a tervezet nem egyszerűsít, hanem alapjaiban rengeti meg az európai polgárok magánszférájának védelmét.

A javaslatcsomag, ha ebben a formában átmegy, drasztikusan megváltoztatja azt, amit ma digitális önrendelkezésnek hívunk. Elemzésünkben sorra vesszük a javaslat legkritikusabb pontjait, és konkrét példákon keresztül mutatjuk be, mit jelentene ez a gyakorlatban.

1. A „személyes adat” fogalmának trükkös szűkítése

A GDPR jelenlegi egyik sarokköve a „személyes adat” objektív definíciója: ha egy adat (akár közvetve, egy azonosító számon keresztül) összekapcsolható egy természetes személlyel, az személyes adatnak minősül.

A Digital Omnibus javaslat ezt egy szubjektív megközelítéssel váltaná fel. A tervezet szerint, ha egy vállalat azt állítja, hogy nem áll szándékában azonosítani az érintettet, akkor a kezelt adatokra nem (vagy csak korlátozottan) vonatkozna a GDPR.

Gyakorlati példa: A „Nem te vagy, csak egy szám” trükk

Képzeljük el, hogy böngészünk a neten, cipőket nézegetünk, híreket olvasunk. A hirdetési cégek profilozzák minden lépésünket. A jövőben, ha a cég azt mondja, hogy ők nem „Kovács Jánost” követik, hanem az „12345-ös felhasználót”, és jelenleg nincs szándékukban összekötni a nevet az ID-vel, akkor ez nem számítana személyes adatnak.

A következmény: A GDPR védelme megszűnik erre az adatra. Az adatbrókerek szabadabban adhatják-vehetik a profilunkat, mi pedig elveszítjük a kontrollt afölött, ki tudja rólunk, milyen betegségekre kerestünk rá.

2. Az AI „adatéhségének” kiszolgálása a múltunkkal

A javaslat egyik legvitatottabb eleme a mesterséges intelligencia fejlesztésének támogatása a személyes adatok védelmének kárára. A tervezet elhárítaná a jogi akadályokat az elől, hogy a technológiai óriások (Meta, Google stb.) felhasználják a birtokukban lévő hatalmas adatmennyiséget AI modellek tanítására. Akár 15 évnyi közösségi média előzményeit is betáplálhatnák az AI modellekbe. Mindezt úgy, hogy az adatkezelés alapértelmezetten engedélyezett lenne és a felhasználónak kellene tiltakoznia, ha ez ellen kifogása van (opt-out).

Gyakorlati példa: A „Digitális Zombi” fotók esete

Jelenleg, ha feltöltünk egy fotót a közösségi médiába, azt az ismerőseinknek szánjuk. A javaslat után a Meta vagy a Google foghatja az összes valaha feltöltött fotónkat, posztunkat (akár 15 évre visszamenőleg), és „betáplálhatja” őket az új AI modelljébe.

A következmény: Az AI megtanulja az arcunkat, a stílusunkat, a gondolatainkat. Mivel több száz cég fejleszthet AI-t, a gyakorlatban lehetetlen lenne mindegyiknél külön-külön tiltakozni (opt-outolni). Azt sem tudnánk, kinek a modelljében „él” tovább a digitális másunk.

3. A „süti-fáradtság” ellenszere: A megfigyelés legalizálása?

A Bizottság ígérete szerint a reform megszüntetné a zavaró cookie bannereket. A tervezet bevezetné a „fehérlistás” (whitelisted) adatkezeléseket, amelyekhez nem lenne szükség a felhasználó hozzájárulására. Ide tartoznának a „biztonsági” és „statisztikai” célok is.

Gyakorlati példa: A telefonunk „távoli átkutatása”

Eddig az ePrivacy szabályok szigorúan védték az eszközeinken (telefon, laptop) tárolt adatokat. Az új javaslat engedélyezné a hozzáférést az eszközhöz „biztonsági” okokra hivatkozva.

A következmény: Ez a gumifogalom lehetőséget adhat arra, hogy applikációk vagy weboldalak a háttérben mélyreható szkennelést végezzenek az eszközünkön anélkül, hogy ehhez valaha is az „Elfogadom” gombra nyomtunk volna. A követés láthatatlanná válna.

4. Az érintetti jogok korlátozása: Hozzáférés csak „célhoz kötötten”

Talán a legmegdöbbentőbb javaslat a hozzáférési jog (GDPR 15. cikk) korlátozása. Német lobbinyomásra a Bizottság bevezetné, hogy az érintettek csak akkor kérhetik ki a róluk tárolt adatokat, ha igazolják a „adatvédelmi célt”.

Gyakorlati példa: A „Ne kíváncsiskodj!” szabály

Tegyük fel, hogy valakit jogtalanul bocsátanak el, vagy a bank indoklás nélkül elutasítja a hitelét. Jelenleg az érintett kikérheti az adatait (munkaidő-nyilvántartás, hitelbírálati pontszám), hogy bizonyítékot szerezzen.

A következmény: A javaslat alapján a cég azt mondhatja: „Elutasítjuk a kérést. Ön ezt az infót munkaügyi vitára/hitelbírálatra akarja használni, nem pedig adatvédelmi célra.” Ezzel az egyén elveszít egy fontos fegyvert a nagyvállalatokkal szembeni vitákban.

Konklúzió

Az Európai Bizottság lépése szakértők szerint pánikreakció a globális technológiai versenyben és az amerikai nyomásra válaszul. Ahelyett, hogy a 2026-ra tervezett átfogó felülvizsgálatot várnák meg, egy gyorsított eljárásban, hatástanulmányok nélkül próbálnak átvinni olyan módosításokat, amelyek a GDPR alapelveit ássák alá.

A „Digital Omnibus” jelenlegi formájában nem az európai KKV-k adminisztrációját csökkenti, hanem a nagy technológiai vállalatoknak és az adatbrókereknek nyit új kapukat. Ahogy a noyb rámutat: ez a javaslat a Szilícium-völgy hírhedt „Move fast and break things” (Mozogj gyorsan és törj össze dolgokat) mottóját követi, kockáztatva az elmúlt évtizedben kivívott európai adatvédelmi szintet.

Forrás: noyb.eu, EU Commission Digital Omnibus Proposal

Az új SCCs elkészítését nemcsak az indokolta, hogy egy évtizeddel ezelőtt elkészített dokumentumok újragondolásáról volt szó, hanem az is, hogy a tavaly nyáron megszületett ún. Schrems II. döntés miatt pillanatnyilag nem tud személyes adat az EU-n kívülre jogszerűen kerülni. A jogszerű adatáramlás egyik pilléréül szolgálnának az SCCs.

Eddig pl. azt láttuk, hogy az USA-beli szolgáltatótól megkaptuk a szolgáltatási szerződésüket (Terms and Conditions/Service Agreement) és valahol a mellékletek között ott volt az adatfeldolgozási szerződés (Data Processing Agreement), emellett azonban nem volt szükség további dokumentumra, mert létezett az EU és az USA között megkötött ún. Privacy Shield megállapodás, amely megadta a jogi kereteket a biztonságos adatáramláshoz.  Mivel a Schrems II. döntés épp ezt a nemzetközi megállapodást érvénytelenítette, a piaci szereplőknek maguknak kell a pótlásáról gondoskodniuk, ami jellemzően az SCCs használatával történik. Az SCCs gyakorlatilag szerződésminták, amelyet a felek (adatkezelők, adatfeldolgozók importőri vagy exportőri pozícióban) használhatnak igényeik szerint alakítva. Bármilyen módon alakíthatók a Bizottság által kiadott minták mindaddig, amíg nem ütköznek a módosítások a GDPR-ba vagy nem sérül a magánszemélyek alapjoga. Mivel a B2B adattranszferek igen nagy része SCCs-n fog nyugodni, szinte az összes USA-beli szolgáltatónak alkalmazkodnia kell az új szerződésrendszerhez a hatálybalépésig nyitva álló 2 éven belül.

Véleményem szerint egy új korszak kezdetén állunk, ami sok tekintetben feladatot ad nekünk is:

–          vélhetően az érintettek most nem a kivárást fogják választani, mert a gyors, GDPR-biztos megoldások kínálatával meg lehet majd nyerni új ügyfeleket,

–          az SCCs adta kereteket minden egyes adatkezelés tekintetében „testre kell szabni”, vagyis – ellentétben a korábbi SCCs-el – nem egy másolandó dokumentumot kapnak a cégek, hanem mind a szerződéses, mind pedig a biztonságos adatáramlást lehetővé tevő egyéb rendelkezések, megoldások tekintetében át kell gondolni a rögzítendő feltételeket (ún. moduláris szerződésminta),

–          az adatexportőrnek (vagyis az EU-ban székelő adatkezelőnek/adatfeldolgozónak) dokumentálnia kell, hogy (i) átvizsgálta a nemzetközi adattranszferrel érintett adatkezelési folyamatait és a szerződéses kereteket, (ii) elvégezte az adott célország (adat importőr) szabályozási kockázatának felmérését (mennyire GDPR-szerű az adott országban a személyes adatok védelme), és (iii) meg kell kötnie az új SCC-t a partner vállalkozással. A szerződések, műszaki, biztonsági eljárások újragondolása a Schrems II. döntés óta zajlik az érintett cégeknél, íme pl. a Microsoft terve: https://blogs.microsoft.com/eupolicy/2021/05/06/eu-data-boundary/.

Valójában a munka június közepe után fog felgyorsulni, amikor az EDPB (European Data Protection Board – Európai Adatvédelmi Testület) véglegesíti az alkalmazandó szerződéses-, műszaki- és eljárási-elvárások körét, beleértve számos igen fontos mondást, pl. a titkosításról. Pillanatnyilag még nem lehet sem azt látni, hogy a piacvezető nagy (adatfeldolgozó) cégek ügyfélbarát kockázatelemző megoldásokat ajánlanának vagy iparági összefogások lennének vagy bármilyen módon segítve lenne az egyedi cégek élete akkor, amikor a Microsofttal, Amazonnal, ZenDeskkel, Salesforce-al, Google-al, stb. vagy ezeknél sokkal kisebb vállalkozásokkal kell tárgyalnia és szerződéses együttműködését új alapokra helyeznie. És hogy még érdekesebb legyen a feladat, figyelni kell azokra a szolgáltatókra is, akik nem lépnek semmit az elkövetkező egy éven belül, mert esetükben nagy eséllyel a régi, nem jogszerű működés marad fenn…

A cikk megírásához a Wolters Kluwer Új online Jogtára nyújtott segítséget.

Adatvédelmi tanácsadás szolgáltatásról és az adatvédelmi auditálásról e szövegre kattintva olvashat.

Ha hasznosnak találta írásomat, iratkozzon fel hírlevelemre, hogy első kézből értesüljön az adatvédelem és a közérdekű adatok nyilvánossága témakörével kapcsolatos információkról.

Ezen az oldalon a vakcina útlevél (oltási igazolvány, Covid-útlevél, Covid-passport, vakcina igazolás, digitális zöldigazolvány) felhasználásának GDPR-vonatkozásait vitatjuk meg.

www.vakcinautlevel.eu

Azt gondolom, hogy a GDPR fejezetek közül igazi csemege a nemzetközi adattovábbításra vonatkozó rész (V. fejezet), ami kifejezetten ínyenceknek ajánlott. Ebben a cikkben megpróbálom összefoglalni azokat a nemzetközi eseményeket, amelyek ebből a fejezetből erednek és aktívan tartják az adatvédelmi szakértői közösséget.

A nemzetközi adattranszferek esetében leggyakrabban alkalmazott két megoldást vizsgálom bővebben a következőkben, mivel a legújabb fejlemények ezeket illetik. A Privacy Shield kerül egyéni górcsövem alá az Általános Szerződéses Feltételek (Standard Contractual Clauses, SCC) mellett, finoman érintve, de nem kibontva számos egyéb témát.

Az SCC minta dokumentumokat hosszú évekkel ezelőtt dolgozta ki a Bizottság (https://ec.europa.eu/info/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en), és véleményem szerint értelmezhetetlenül általánosra sikerültek. Eddig az volt az alapvetés, hogy csupán a megfelelő SCC kiválasztásával, mellékletének kitöltésével és a szerződés megkötésével a felek eleget tettek a GDPR nemzetközi adatátadásra vonatkozó elvárásainak. Az SCC törzsszövegből és mellékletből áll, ám a törzsszöveghez nyúlni nem szabad, különben elveszíti érvényességét, ezért az üzlet számára csupán az a lehetőség maradt hátra, hogy a mellékletbe tegye bele mindazt, amit relevánsnak ítélt meg az adott adattranszfer tekintetében. Jellemzően nem szorgoskodtak a cégek a dokumentumok testre szabásával. Ékes példa a dokumentum rendkívül általános szintjére a Schrems I. ügyiratai között ma is fellehető Facebook SCC, amely csupán két oldalban részletezte a FB által végzett nemzetközi adattovábbításokkal érintett adatok körét, adatkezelés célját, adatkezelési műveleteket, stb.

Még az irányelv hatálya alatt dolgozta ki az Európai Unió Bizottsága és az USA az un. Safe Harbour megállapodást, ami hosszú évekig jogilag biztonságos keretet adott az EU-ból az USA-ba történő adatexport és ottani adatfelhasználás számára. A Safe Harbour rendszer gyakorlatilag ön-minősítésen alapuló rendszer volt, amikor az adott USA cégek maguk dönthették el, hogy megfelelnek-e az elfogadott alapelveknek, és ha igen, elhelyezhették a Safe Harbour jelzést weboldalukon, szolgáltatásukon, jelezvén, hogy ők jogszerű keretek között használják az adatokat. Valójában semmilyen tényleges előzetes ellenőrzés nem képezte részét a rendszernek és csak néha-néha hallottunk esetekről, amikor kiderült, hogy a magukat biztonságosként, jogszerűen eljáróként feltüntető cégek nem tökéletesen feleltek ennek meg.

Amikor megszületett a Schrems I. döntés (2015. október), egy pillanatra a világ megfagyott és komolyan elkezdett mindenki azon töprengeni, hogyan tovább? Az európai adatvédelmi hatóságok azonnal türelmi időt hirdettek, mondván, az új helyzetet intézményi szinten kell megoldani. Ekkor munkába lendült az EU Bizottsága, tárgyalt USA-beli partner szervezeteivel és nyélbe ütötték 2016 júliusára a Privacy Shield elnevezésű megállapodást. A Privacy Shield átláthatóbb elvek mentén került kialakításra, mint a korábbi Safe Harbour, de a minősítés, rendszerbe való bekerülés logikája változatlan maradt, mert elsősorban a cégek saját megítélésén alapult. A helyzet ingatagságát mégsem ez okozta, hanem egy sokkal magasabb szintű konfliktus, amit Max Schrems a dokumentum elfogadásának első pillanatától hirdetett.

A Schrems II. néven elhíresült ítéletében az Európai Unió Bírósága 2020. július 16-án kimondta – többek között – a Privacy Shield érvénytelenségét, mert nem látja biztosítottnak a személyes adatok védelmét az USA adott jogi keretei között. Egyrészt nevesített egyes, adatvédelmi ön-korlátozásokat nem tartalmazó nemzetbiztonsági jogköröket rögzítő jogszabályokat (pl. Section 702 FISA and EO 12333), amelyek szinte korlátlan hozzáférést engednek/biztosítanak bármely, USA bűnmegelőzési joga alá eső vállalkozás birtokában lévő adatokhoz. Másrészt az EU állampolgárok jogorvoslathoz való jog teljes hiányát rója fel az EUB. Számos szakcikk elolvasása után arra a következtetésre jutottam, hogy ember nincs, aki ma meg tudná mondani, hogy milyen USA szerveknek, milyen célból, milyen adatokhoz, milyen módon, stb. van hozzáférése akár az EU polgárainak adatait illetően.

A Privacy Shield érvénytelenítésével azonnal megszűnt az a helyzet, amikor örömmel nyugtáztuk, hogy nincs további teendőnk, ha a https://www.privacyshield.gov/ oldal adatbázisában megtaláltuk a leendő USA szolgáltató szerződéses partner adott szolgáltatását. A döntést követően a Privacy Shield és az azon alapuló nemzetközi adattovábbítás egy csapásra a múlt részévé vált.

AZ EUB ugyanakkor nem hagyta teljesen eszköztelenül a nemzetközi adattovábbítással érintett cégeket, mert azt is kimondta, hogy az Általános Szerződéses Feltételek (Standard Contractual Clauses, SCCs) viszont érvényben maradnak. Tulajdonképpen ez a lehetőség maradt az egyetlen valódi eszköz a legtöbb vállalkozás számára, mivel a Kötelező Vállalati Szabályok (Binding Corporate Rules – BCRs) kizárólag cégcsoportok esetén jelenthet – költséges és bonyolult – megoldást.

Az EUB az SCC egyszerű, „copy- paste” alkalmazhatóságán is csavart egyet, mondván, hogy az SCC is csak akkor töltheti be a GPDR szerinti szerepét, ha a célország jogrendjében az adatvédelem lényegében az EU-ban (és a GDPR-ban) biztosított szinten létezik. Az EUB akként vizionálta a feladatot, hogy az SCC megkötése előtt a felek (adatátadó/importőr és adatátvevő/exportőr) case-by-case megvizsgálják az egyes adatátadási eseteket, eldöntik, hogy az adott adatkezelésre vonatkozik-e olyan szabály az adott célországban (különösen a közhatalmi szervek vonatkozásában), amely nem megfelelő a GDPR-ral összevetve, pl. a hatóságok és bíróságok adatokhoz való hozzáférése hogyan valósulhat meg? A vizsgálat szempontrendszere emellett magánszemély fókuszú is, ezért azt is figyelembe kell venni, hogy az egyén számára állnak-e rendelkezésre megfelelő biztosítékok, érvényesíthető jogok és valódi jogorvoslatot biztosító eszközök? A feltárást követően, a GDPR védelmi szintjéhez képest fennálló hiányosságok, ellentmondások esetén a feleknek szerződéses keretek között kell rendezniük a hiányosságokat, ellentmondásokat, amennyiben lehetséges, megfelelő biztosítékok kidolgozásával. Gyakorlatilag a vizsgálat jelentős része a risk assessment-en túl arra kell, hogy fókuszáljon, hogy vajon az USA importőr cég a bűnmegelőzési rezsim alá tartozik-e és ha igen, mikor, hogyan szál vitába az adott hatósággal az adatok védelme érdekében. Természetesen, ügyelni kell arra is, hogy az így kialakított szerződéses „védelmi” vagy kiegészítő biztosítékok az adott jogrend keretei között valóban az elvárt cél tudják szolgálni és ne csak üres klauzulák maradjanak. Ha a felek nem találnak megoldást, akkor a nemzetközi adattovábbítás nem tud jogszerűen megvalósulni, ezért azt fel kell függeszteni vagy be kell szüntetni, vagy ha mégis folytatni kívánják, akkor jelenteni kell az adatvédelmi hatóság felé, vállalva a következményeket.

Gyakran alkalmazták cégek azt az alternatívát, hogy USA szolgáltató EU-ban elhelyezett szerverein tárolták az adataikat és kizárólag ott tartózkodó kollégák fértek hozzájuk, elkerülve ezáltal az adatok nemzetközi mozgását. Ez a megoldás azonban „üres biztosítékká” vált 2018 nyarán, amikor megszületett a CLOUD Act. Ezzel a jogszabállyal az USA nemzetbiztonsági szerveinek közvetlen hozzáférése nyílt meg bármely USA szolgáltató nem USA-ban elhelyezett szerverein tárolt ügyféladatokhoz. (Ez anno a híres Microsoft ügy „lezárásaként” született meg (https://en.wikipedia.org/wiki/Microsoft_Corp._v._United_States). Ez a törvény pont a holland szerverparkok biztonságába vetett hitet semmisítette meg, mert adott esetben az ott tárolt e-mail fiókban lévő levelezést is ki kellett adnia a szolgáltatónak a hatóság felé. Tehát a lehetséges kiegészítő biztosítékok között biztosan hátrébb sorolandó az EU szerver park, mint „safe harbour”.

Bizonyos értelemben hasznos ötlettel ált elő a napokban (2020. szeptember 8.) a svájci adatvédelmi hatóság, amikor (a Svájc – USA Privacy Shield érvénytelenítése mellett) azt tanácsolja a vállalkozások számára, hogy USA szolgáltatók EU (felhő) tárhelyeit úgy használják, hogy vigyék a saját titkosító kulcsukat vagy titkosítási megoldásukat (bring-your-own-key (BYOK), bring-your-own-encryption (BYOE). Nem mondja ki, de világos, hogy a CLOUD-ra kívántak választ adni. A svájci döntéshozó is hozzáteszi, hogy amennyiben ez a megoldás nem működik és/vagy a szerződéses biztosítékokkal együtt sem biztosított a személyes adatok megfelelő védelme, akkor az adattovábbítás nem támogatott az adott ország felé.

Az EUB ítélet után a piac néhány napig várta, hogy türelmi időt hirdessenek a hatóságok, de ehelyett az Európai Adatvédelmi Testület (European Data Protection Board, EDPB) iránymutatása jelent meg (2020. július 23.) a leggyakoribb kérdésekről, értelmezve az ítélet kulcsgondolatit. https://edpb.europa.eu/our-work-tools/our-documents/ovrigt/frequently-asked-questions-judgment-court-justice-european-union_en

A dokumentum vége felé, amikor már az izgalmasabb részek következnek, az egyik fejezet címe a „kiegészítő biztosítékok” fordulatot viseli. Sajnos, a szöveg üres, a dokumentum írásakor az EDPB-nek sem volt annyi muníciója, hogy ötleteket adjon a piac számára jogi, technológiai vagy szervezeti kiegészítő intézkedésekre abban az esetben, ha az exportőr országa nem biztosít megfelelő védelmet (tehát az összes USA cég által nyújtott szolgáltatásra).

További fejlemény, hogy 2020. szeptember 4-én az EDPB bejelentette, két szakbizottságot is felállítanak a Schrems II. ítéletet követően, amelyek közül az egyik kifejezetten az ígért kiegészítő megoldások kidolgozására hivatott a piaci vállalkozások támogatása érdekében. Azt gondolom, hogy ez egy nagyon jó irány, mert sem az EU-ban, sem az USA-ban nincs olyan tanácsadó, aki pontosan és az elvárt szinten meg tudná fogalmazni a kiegészítő intézkedések csokrát vagy akár néhányat is közülük. Az sem lett volna üdvözítő megoldás, ha az EU adatvédelmi hatóságai egyenként adnak ki iránymutatásokat ezekre az intézkedésekre, mert globális szolgáltatásokról van szó, amelyekre globális válaszokat kell adni. Azt ígérik, hogy hamarosan előállnak az ötleteikkel, amelyet természetesen mi, jellemzően jogkövető, most azonban bizonytalan és a jogszerűtlenség szélére sodort vállalkozások nagyon várunk. Természetesen, az EDPB hangsúlyozza, hogy bármi is szülessék, senki nem fogja megúszni a valódi munkát, mert nem „dobozos” terméket fognak legyártatni és igenis mindenkinek végig kell majd mennie a saját vizsgálati, megoldás-keresési folyamatán.

A másik szakbizottság feladata nem kevésbé érdekes, mert az ő feladata lesz egységes válaszok, megállapítások és eljárások kidolgozása a Max Schrems, és az általa képviselt szervezet (None of Your Business, NOYB) 2020. augusztus 17-én 101 online vállalkozás ellen tett feljelentése miatt a különböző EU adatvédelmi hatóságoknál indult eljárásokban. Ezek azok a sajtóból is ismert ügyek, amelyek az indexet, időképet és a 24.hu-t érintik, mert továbbra is alkalmazzák a Facebook Connect-et és/vagy Googly Analytics-et, azaz az EUB döntés után is nemzetközi adattovábbítást folytatnak, immár jogellenesen. A magyar online szolgáltatók ügye az osztrák hatóság előtt van. A keresetek szerelmeseinek ajánlom: https://noyb.eu/en/eu-us-transfers-complaint-overview. A szakbizottság létrejötte és munkája igen fontos lépés abban a tekintetben, hogy az egyes EU adatvédelmi hatóságok ne maguk állítsák fel az USA-ba történő adattovábbítások (többé vagy kevésbé szigorú) feltételeit, hanem egységes, EU szintű elvárások fogalmazódjanak meg. 

Az EU adatvédelmi hatóságoknak az EUB ítélet után „csőre töltött” puska van a kezében, amit talán használni is fognak, ha úgy ítélik meg, hogy jogellenes adatátadás került a látókörükbe. Szeptember elején épp ennek jegyében az ír hatóság küldött egy megkeresést a Facebooknak felhívva a figyelmét arra, hogy az SCC nem képez megfelelő jogalapot a továbbiakban a kiegészítő biztosítékok hiánya miatt és a jogellenes adattovábbítás megszüntetésére hívta fel a címzettet. Ez volt az első alkalom, amikor a Facebook fontos döntéshozóinak megemelkedett a szemöldöke és elkezdték komolyan venni az EU-ban folyó hatósági, bírósági eljárások (potenciális) következményeit. A hónap feléig kaptak határidőt véleményük kifejtésére, amelyet további hatósági lépések követhetnek, akár további hatóságok bevonása mellett. Egyes elemzők szerint arra a pontra jutott a helyzet, amikor akár a Facebook lobbi erejének köszönhetően az USA jogszabályai változhatnak, akár a Facebook létezhet EU és USA verzióban, megfelelve a jogi elvárásoknak.

Finnországban az Adatvédelmi Hatóság „piackutatást” tart, aminek keretében szeptember elején levélben keresett meg cégeket az USA-ba történő adattovábbításokról érdeklődve. A hatóság tudni szeretné, hogy a még folyamatban lévő adatátadások a Privacy Shield-en vagy SCC-n alapulnak, milyen kiegészítő biztosítékokat alakítottak ki a cégek és mit vár a piac a helyi hatóságtól?

Nagyon nehéz összegzést adni ennyi esemény és fejlemény tükrében.

A wait and see minden bizonnyal a vállalkozások igen jelentős részénél alkalmazható, mivel annál sokkal többet nem nagyon lehet tenni, mint várni az EDPB szakbizottság iránymutatását az SCC kiegészítő biztosítékokról vagy az EU Bizottság új SCC szövegeit (amelyeket karácsonyi ajándéknak ígérnek) vagy beszerezni ügyes titkosító szoftvereket, amit sokan a pillanatnyilag egyetlen üdvözítő megoldásként látnak.

Az biztosan nem jó eljárás, ha USA szolgáltatók nyomásának eleget téve alávetjük magunkat az általuk javasolt SCC-nek, anélkül, hogy elvégeznénk a kockázatelemzést és/vagy a kiegészítő intézkedések kialakítását.

A cikk megírásához a Wolters Kluwer Új online Jogtára nyújtott segítséget.

Adatvédelmi tanácsadás szolgáltatásról és az adatvédelmi auditálásról e szövegre kattintva olvashat.

Ha hasznosnak találta írásomat, iratkozzon fel hírlevelemre, hogy első kézből értesüljön az adatvédelem és a közérdekű adatok nyilvánossága témakörével kapcsolatos információkról.

Az utóbbi években jelentősen megnövekedtek a weboldalak elleni támadások, amelyek eredményeképpen minden eddiginél több személyes adat került illetéktelen kezekbe a weben. Cikkemben az okoknak és a lehetséges védekezési módoknak próbálok meg utána járni.

Miért nőttek meg a weboldalak biztonságával kapcsolatos problémák?

A weboldalak elleni támadások növekedésének egyik fő oka a nyílt forráskódú tartalomkezelő rendszerek népszerűsége. Az utóbbi években a nyílt forráskódú WordPress tartalomkezelő rendszer lett magasan a legelterjedtebb a weben. 2020-ban a világ összes weboldalának 34%-a mögött a WordPress áll.

WordPress-el készült a New York Times, a The White House, a The Walt Disney Company és a BBC America weboldala is, hogy a legforgalmasabb weboldalak közül említsek néhányat.

A WordPress népszerűségét az alábbiaknak köszönheti:

• Ingyenes
• Egyszerűen és gyorsan telepíthető
• Felhasználóbarát adminisztrációs felület
• Számtalan kiegészítő (plugin) telepíthető rá

A WordPress rendszer telepítését, beüzemelését, testreszabását még egy kezdő webfejlesztő is gyorsan el tudja sajátítani. Ennek köszönhetően a weboldal készítés már nem csak a profi programozók kiváltsága, hanem szinte bárki megpróbálkozhat vele.

Az utóbbi években ezrével jelentek meg az olyan weboldal fejlesztéssel foglalkozó szakemberek, akik minimális előképzettséggel, autodidakta módon sajátították el a webfejlesztés tudományát és ontják magukból az új weboldalakat.

Információ biztonsági és adatbiztonsági képzettség hiányában azonban ezek a weboldalak sajnos olyan problémákat rejthetnek, amelyek könnyen támadhatóvá teszik őket.

A nyílt forráskódú weboldalak biztonsága

Maga a WordPress rendszer biztonságosnak mondható, de csak abban az esetben, ha a fejlesztő és weboldal tulajdonos betartja az írott és íratlan biztonsági szabályokat.

Ennek hiányában a weboldalt előbb-utóbb feltörik vagy vírus fertőzött lesz, amely lehetőséget biztosít a támadóknak arra, hogy az oldalon tárolt személyes adatokat,

• neveket
• e-mail címeket
• lakcímeket
• jelszavakat
• IP címeket
• …. stb.

eltulajdonítsanak és ezzel visszaéljenek.

Gondoljunk csak bele milyen aggályos egy olyan feltört webshop, amelyen keresztül naponta több száz ember személyes adatai, vásárlási információi keresztülfolynak.

Milyen okai vannak annak, hogy a nyílt forráskódú weboldalak támadhatók?

Egy weboldal több különböző csatornán keresztül is támadhatóvá válik, ha nem védjük megfelelően.

A sérülékenységek legnépszerűbb okai az alábbiak:

• Gyenge jelszavak – a támadók könnyen bejutnak a jelszóval védett adminisztrációs rendszerbe
• Frissítések hiánya – a nyílt forráskódú tartalomkezelő rendszereket folyamatosan frissíteni kell. Ha ezek a biztonsági frissítések elmaradnak, a weboldal támadhatóvá válik
• Sérülékeny plugin-ek – a rendelkezésre álló több százezer plugin közül nagyon óvatosan kell kiválasztani azokat, amelyeket telepítünk, mert sok plugin hordoz magában sérülékenységet
• Nem biztonságos tárhely – a tárhely FTP hozzáférése ha nem elég erős, akkor ezen keresztül közvetlenül a weboldal fájlok megfertőzhetők. Ha a tárhely védelmi mechanizmusa nem megfelelő, akkor ez szintén veszélyt jelenthet a weboldalra.
• Biztonsági mentés hiánya – ez nem jelent önmagában veszélyt a weboldalra nézve, de elmaradása estén a fertőzött weboldal visszaállítása meghiúsulhat.

Mi értelme van a weboldalak elleni támadásoknak?

Az olvasóban itt megfogalmazódhat a kérdés, hogy vajon miért támadják a weboldalakat, kinek és miért éri meg ezzel foglalkozni? A válasz megint csak a WordPress népszerűségében keresendő.

Az azonos alap rendszerre írt weboldalaknak ugyanis könnyen lekérdezhető a verziószáma, plugin-jeinek a neve, így nem nehéz olyan automatikus szoftvereket készíteni, amelyek gyakorlatilag emberi beavatkozás nélkül „bóklásznak” a weben és minden szembejövő weboldalnak lekérdezik a legfontosabb információit.

Ha pedig egy olyan WordPress weboldalba ütköznek, amely elavult vagy valamelyik plugin-je nem biztonságos, akkor automatizáltan feltörik.

A weboldal feltörések mögött az alábbi okok húzódnak meg:

• személyes adatok eltulajdonítása
• bizalmas adatok eltulajdonítása
• spam küldés
• káros programok telepítése
• illegális külső weboldalra mutató linkek elrejtése a weboldalban

Ezek a szolgáltatások a „dark weben” megvásárolhatók, így válik a weboldal feltörésekkel megszerzett információ pénzzé.

A weboldal üzemeltetők ráadásul az esetek 61,5%-ában nem is szereznek tudomást a feltörésről, így a támadó hosszú időn keresztül tud gyakorlatilag észrevétlenül adatot gyűjteni.

Hogyan előzhetjük meg a problémákat és tarthatjuk biztonságban weboldalunkat?

Bárki aki weboldalt fejleszt vagy üzemeltet, fontos, hogy képben legyen a legfontosabb adatbiztonsági és adatvédelmi eljárásokkal kapcsolatban, mert csak így tudhatja weboldalát hosszú távon biztonságban.

A legfontosabb biztonsági ajánlások, javaslatok a következők:

• A „core” rendszer legyen rendszeresen frissítve
• A lehető legkevesebb plugin legyen a weboldalba telepítve.
• A plugin-ek legyenek nagyon körültekintően kiválasztva. Megbízható fejlesztő, magas értékelések, magas letöltés szám, gyakori frissítések. Ezek a jellemzők elég beszédesek.
• Az adminsztrációs felület alapértelmezett útvonala legyen megváltoztatva.
• Az adminisztrációs felülethez minél kevesebb személy kapjon hozzáférés, jelszavaik legyenek biztonságosak
• A weboldal tárhelyéhez minél kevesebb személynek legyen hozzáférése. Az FTP jelszó legyen biztonságos. Ha választani lehet, akkor legyen SFTP kapcsolat, FTP helyett.
• A teljes weboldalról készüljön napi és heti mentés
• A tárhely szolgáltató legyen körültekintően kiválasztva. Célszerű olyan tárhely szolgáltatót választani, akinek megoldásai vannak a nyílt forráskódú weboldalak védelmére.
• Legyen biztonsági plugin telepítve a weboldalra, ami extra védelmet nyújt

A cikk megírásához a Wolters Kluwer Új online Jogtára nyújtott segítséget.

Adatvédelmi tanácsadás szolgáltatásról és az adatvédelmi auditálásról e szövegre kattintva olvashat.

Ha hasznosnak találta írásomat, iratkozzon fel hírlevelemre, hogy első kézből értesüljön az adatvédelem és a közérdekű adatok nyilvánossága témakörével kapcsolatos információkról.

Azt már a korábbi iránymutatás is tartalmazta, hogy az adatkezelő érvelhet azzal, hogy a szervezet valós választási lehetőséget biztosít az érintetteknek, ha választani tudnak egyrészt a további célokra történő személyesadat-felhasználáshoz való hozzájárulást tartalmazó szolgáltatás, és ugyanazon adatkezelő egyenértékű szolgáltatása között, amely nem foglal magában hozzájárulást. Amíg ugyanahhoz a szolgáltatáshoz van lehetőség hozzájárulás nélkül hozzáférni, azt jelenti, hogy nem feltételhez kötött szolgáltatás.

Az Európai Adatvédelmi Testület szerint a hozzájárulás nem lehet önkéntes, ha az adatkezelő úgy érvel, hogy létezik választás az általa kínált szolgáltatás, amelynél személyes adatokhoz való hozzáférés szükséges és más adatkezelő ugyanolyan szolgáltatása között. Ilyen esetben a választás szabadsága attól függene, hogy más piaci szereplők hogyan viselkednek és vajon az érintett a másik szolgáltató szolgáltatását valóban egyenlőnek értékeli-e. Továbbá ez magában foglalna egy kötelezettséget az adatkezelők részéről, hogy figyeljék a piaci fejlesztéseket, hogy így biztosítsák a hozzájárulás folyamatos érvényességét adatkezelési folyamatokban, ugyanis egy versenytárs módosíthatja a szolgáltatását egy későbbi időpontban. Ennélfogva egy harmadik fél által kínált alternatív opcióra hivatkozó hozzájárulás nem összeegyeztethető a GDPR-ral, ami azt jelenti, hogy a szolgáltatást nyújtó nem akadályozhatja meg az érintetteket a szolgáltatáshoz jutástól, olyan alapon, hogy nem adták hozzájárulásukat.

Ahhoz, hogy a hozzájárulás önkéntes legyen, a szolgáltatáshoz vagy funkciókhoz való hozzáférés nem tehető függővé az információ tárolásra vonatkozó vagy a már tárolt információhoz való hozzáférésre vonatkozó felhasználói hozzájárulásától a végfelhasználói eszközön (pl.: laptop, mobiltelefon, tablet).

Például a weboldal üzemeltető elhelyez egy olyan szkriptet, ami blokkolja a tartalom láthatóságát kivéve, arra való felhívást, hogy a felhasználó fogadja el a cookie-kat és az arra vonatkozó információkat, hogy milyen cookie-k milyen célból kezelik az adatokat. Nincs más lehetőség, a tartalomhoz való hozzáféréshez, mint hogy a felhasználó a „Cookie-k elfogadása” gombra kattint. Mivel az érintettnek nincs valódi választási lehetősége, a hozzájárulás nem önkéntes. Ez nem jelent önkéntes hozzájárulást, a szolgáltatáshoz való hozzáférés attól függ, hogy az érintett a „Cookie-k elfogadása” gombra kattint-e.

Tehát, ha a weblap csak úgy érhető el, hogy a cookie-khoz hozzájárulást ad a felhasználó, az nem lesz megfelelő adatkezelés a GDPR alapján. Azonban, ha van lehetőség a cookie-kat elutasítva hozzáférni a tartalomhoz, szolgáltatáshoz, akkor megfelelő a cookie-banner.

Az egyenértékű szolgáltatások esetén, ha személyes adatok kezeléséhez való hozzájárulás helyett díj ellenében lehet hozzáférni egy oldal tartalmához, szintén jogszerű lehet a fentebb kifejtettek alapján. Ilyen például az osztrák The Standard (https://apps.derstandard.at/privacywall/) oldala.

Szintén nem megfelelő az oldalon való görgetés, suhintás, vagy hasonló tevékenység hozzájárulás megadásához, mert ezt nehéz megkülönböztetni a felhasználó más tevékenységtől, és így az önkéntesség sem megállapítható. Továbbá, ilyen esetben nehéz lenne biztosítani, hogy a hozzájárulás visszavonása ugyanolyan könnyű legyen, mint a hozzájárulás megadása.

A cikk megírásához a Wolters Kluwer Új online Jogtára nyújtott segítséget.

Adatvédelmi tanácsadás szolgáltatásról és az adatvédelmi auditálásról e szövegre kattintva olvashat.

Ha hasznosnak találta írásomat, iratkozzon fel hírlevelemre, hogy első kézből értesüljön az adatvédelem és a közérdekű adatok nyilvánossága témakörével kapcsolatos információkról.

4. Adatvédelmi incidens fogalma, bemutatása (Dr. Szabó Endre Győző)

Az incidens fogalmi elemeinek didaktikus ismertetése történik a videóban.

Fontos emlékezni arra, hogy nem minden információbiztonsági incidens adatvédelmi incidens, de minden adatvédelmi incidens információbiztonsági incidens is egyben. Ugyanakkor minden adatvédelmi incidens adatvédelmi jogsértés, amely következményeivel számolnia kell az adatkezelőnek.

A biztonság sérülését okozhatja, hogy
– a megvalósított intézkedések nem kellően hatékonyak,
– a megfelelő intézkedéseket nem tartották be, vagy
– nem hozták meg az arányos és elvárható biztonsági intézkedéseket.

Biztonság átmeneti sérülése is lehet incidens, amennyiben a kockázatok azzá minősítik. pl. zsarolóvírus titkosítása után, a visszaállítás ideje alatt nem folytatható az adatkezelő tevékenysége az adatok hiánya miatt.
Ha a zsaroló vírus a titkosítást követően másolatot készít és azt továbbítja valamilyen tárhelyre, akkor a bizalmasság és a hozzáférhetőség is sérül!

5. Az adatvédelmi incidensek kezeléséhez kapcsolódó feladatok (Dr. Szabó Endre Győző)

A hatóság minden bejelentetett incidens esetén hatósági ellenőrzés végez, amely során végzéssel nyilatkozattételt, iratszolgáltatást írhat elő. Ha kielégítőek az adatkezelő által megtett vagy tervezett intézkedések, értesítés nélkül 60 napon belül lezárja az eljárást, jogsértés megállapításának mellőzésével.

2019 folyamán 720 incidens bejelentés érkezett a hatósághoz, amelyek közül 19 hatósági ellenőrzés után folyt le hatósági eljárás. 6 esetben történt bírságolás.

Említett jogeset: elveszett a munkavállalói adatokat tartalmazó pendrive, amely sem jelszóval nem védett, sem az adatok nem voltak titkosítva, az adatkezelőnél létező előírás ellenére. Az adatok elvesztése a biztonság sérülését okozta, jogosulatlan hozzáférésre, nyilvánosságra hozatalra nem volt utaló jel. A bírság összegének kalkulálásakor figyelembe vették, hogy a bizalmasság további sérülésének veszélye fennáll, mert a pendrive nem védett.

A hatóság nem fogadja el a 72 órás bejelentési kötelezettség elmulasztásának indokaként a felettes szerv vagy anyavállalat jóváhagyására várakozást, belső egyeztetést. Szakaszos bejelentést támogatnak és a visszavonás lehetősége folyamatosan fennáll.

6. Az adatvédelmi tisztviselők kérdései az adatvédelmi incidens, az adatvédelmi hatásvizsgálat és a harmadik országba történő adattovábbítás kapcsán (Dr. Szabó Endre Győző)

Ha az adatvédelmi incidens nem jár kockázattal (pl. az elveszett adatok erősen titkosítottak vagy álnevesítettek és létezik mentés) csak a nyilvántartásba kell felvenni az esetet.

Azonban mindig az eset konkrét körülményeinek ismeretében dönthető el a kockázat mértéke. Kockázat: súlyosság és valószínűség szempontjából jellemez valamilyen eseményt és annak következményeit. Adatvédelmi incidens esetén az érintettek jogait és azokra gyakorolt hatást kell vizsgálni (a preambulum 75. pont szerint), így az incidens jellegét, érintett adatok jellegét, típusát, mennyiségét, könnyen azonosíthatók-e az egyének, a következmények súlyosságát. A kockázat magasabb, ha rosszhiszemű személyekhez került az adat, a következmények tartósságát, a különleges adat érintettsége is súlyosbító tényező, és figyelembe veszik az érintettek számát.

Előzetes hatásvizsgálat lefolytatása azoknál a GDPR életbe lépésekor már folyó adatkezeléseknél szükséges, amelyeknél valószínűsíthető a magas kockázat és amelynél megváltozott a kockázat figyelemmel az adatkezelés körülményeire, jellegére és céljára. Azon adatkezelés esetén, ami változatlan módon folyik, nem szükséges, ha a DPO vagy a hatóság jóváhagyta. A kötelező hatásvizsgálattal érintett adatkezelések meghatározásában a NAIH által kiadott un. fekete lista is segít.

7. A hatóság főbb eljárásai (Dr. Vass Norbert)

Vizsgálati eljárást bárki kezdeményezhet, ez a „bevezető” eljárás. A hatóság ilyenkor is iratokba betekinthet, helyiségbe beléphet, adatot kérhet bárkitől. A GDPR és az Infotörvény alapján jár el a hatóság. Lezárható az ügy felszólítással, ajánlással vagy hatósági eljárással.

Hatósági eljárás GDPR, Infotv. és az Ákr. szabályai szerint folyik, és a hatóság alkalmazza a rendelkezésére álló, a tényfeltérést, bizonyítást lehetővé tevő eljárásjogi eszközöket.

Ha az adatkezelő az előírt kötelezettség teljesítését nem igazolja, a NAIH úgy tekinti, mintha nem teljesítette volna.

8. Az érintetti jogok gyakorlására irányuló kérelmek (Dr. Vass Norbert)

Az érintetti megkeresés érkezhet bármely elérhetőségen, nemcsak dedikált csatornán és nincs formakényszer sem, tehát nem írható elő pl. az e-mailes forma. Az adatkezelő csak a már nála meglévő adatokat kérheti be az azonosítás érdekében és az adattakarékosság elvére az azonosítás során fokozottan figyelemmel kell lennie.

Amennyiben a megkeresés elutasításra kerül, azt ésszerű részletességgel indokolni kell. Akkor kérheti az adatkezelő – dokumentált formában – a kérelem pontosítását, ha régóta vagy sok adatot kezel az érintettről. A szerződéses vagy üzleti kapcsolat megszűnésétől függetlenül nem tagadható meg az adatokhoz hozzáférés, mert az adatkezelők jellemzően kezelik még az adatot jogi kötelezettség (pl. számviteli törvény) alapján. Kamerafelvételről maszkolással (vagy hasonló módszer alkalmazásával) adható másolat. Üzleti titokra hivatkozással nem tagadható meg az adtok kiadása, a hozzáférés biztosítása.

9. Egyes GDPR szerinti jogalapokkal kapcsolatos kérdések (Dr. Vass Norbert)

Érdekességként hívnám fel a figyelmet arra, hogy az oktató videóban a NAIH a tájékoztatás paramétereit a GDPR 13. és 14. cikkei szerint határozza meg, ugyanakkor nem hivatkozik a korábban, a témában kiadott állásfoglalásra. Nem lehet tudni, hogy ez csupán figyelmetlenség a hatóság részéről, vagy esetleg valóban részben vagy egészben meghaladottként tekint a korábbi állásfoglalásra, ezért annak említését tudatosan mellőzték.

A hozzájárulás kapcsán elhangzik, hogy célonként külön-külön megadandó és a nem cselekvés (előre bepipált check box vagy használat folytatás) nem elegendő az érvényes hozzájáruláshoz. Pl. a „közbiztonság” nem jó cél, mert nem egyértelmű, az adatkezelési célnak és az adatkezelés folyamatának mindig konkrétnak kell lennie. A hozzájárulás visszavonására könnyen elérhető eszközt kell biztosítani és a visszavonás jelentős hátránnyal nem járhat.

A szerződéses jogalap esetében csak a szerződés teljesítéséhez szükséges adatok kezelhetők, a profilozás csak akkor végezhető, ha a szerződés teljesítése azt indokolja. A szerződés nem teljesítésének kikényszerítése nem megfelelő a szerződéses jogalap (GDPR 6. cikk (1) b)), hanem jogos érdek (GDPR 6. cikk (1) f)). Fontos figyelemmel lenni a 2/2019 EDPB iránymutatásban foglaltakra.

10. A kis- és közepes vállalkozásoktól a hatósághoz beérkező kérdések bemutatása (Nagy Renáta)

Eddig 191 kérdés érkezett, talán mert a KKV adatkezelők számára nem volt ismert ez a lehetőség.

A GDPR vonatkozik a KKV-kra is, még akkor is, ha az adatkezelő tevékenysége nem jár semmilyen adatkezeléssel, de vannak munkavállalók. Ekkor a munkavállalói adatok kezelése tekintetében alkalmazandó.

11. További adatvédelmi tárgyú kérdések
12 oldalas írásos dokumentum, amelyet érdemes átfutni, mert a kérdések alapján könnyen eldönthető, hogy releváns-e az adott téma.

12. Információ szabadsággal kapcsolatban érkezett kérdések
Jelen cikkben nem tárgyaljuk.

A cikk megírásához a Wolters Kluwer Új online Jogtára nyújtott segítséget.

Adatvédelmi tanácsadás szolgáltatásról és az adatvédelmi auditálásról e szövegre kattintva olvashat.

Ha hasznosnak találta írásomat, iratkozzon fel hírlevelemre, hogy első kézből értesüljön az adatvédelem és a közérdekű adatok nyilvánossága témakörével kapcsolatos információkról.