GDPR-megfelelés weboldalaknál: mit kell valójában megépíteni

A legtöbb online GDPR-tanács jogászoknak szól, vagy azoknak, akik szabályzatgenerátort vásárolnak. Nagyon kevés készül annak, akinek szerkesztőt kell nyitnia és meg kell változtatnia valamit.

Ez az útmutató a második fajtából való. Végigmegy azon, mit kíván az általános adatvédelmi rendelet egy weboldaltól és a mögötte álló rendszerektől, olyan dolgokként megfogalmazva, amiket megépít, beállít vagy töröl. Ezt a munkát 2018 óta, a rendelet alkalmazásának kezdete óta végezzük EU-ban működő cégeknek, és az, ami el szokott romlani, azóta alig változott.

Egy megjegyzés az elején: a GDPR nem lett könnyebb attól, hogy újabb szabályok érkeztek. Fontosabb lett, mert az uniós digitális szabályok jelenlegi hullámában szinte minden feltételezi, hogy a személyes adatai már rendben vannak.

Kezdje őszinte adatleltárral

Szinte minden megörökölt, kudarcba fulladt GDPR-projekt ugyanott bukott el. A csapat előbb írta meg a szabályzatot, és később fedezte fel az adatokat.

Minden más előtt térképezze fel, milyen személyes adatokat gyűjt valóban a webhelye. Nem azt, amit a termékspecifikáció mond. Azt, ami az adatbázisban, a naplókban, az analitikai platformon, a CRM-ben, a támogatási eszközben, a marketingautomatizálási rendszerben, a hibakövetőben, a CDN-naplókban és az oldalon lévő harmadik féltől származó szkriptekben van.

Gyakorlatban ez azt jelenti:

• Fésülje át a sémát. Minden oszlopot, amely önmagában vagy másikkal kombinálva azonosíthat egy személyt.
• Olvassa el a hálózati fület valós oldalbetöltésnél. Minden kimenő kérés olyan tartományra, amelyet nem Ön felügyel, potenciális személyesadat-továbbítás, mert az IP-cím plusz a user agent személyes adat.
• Nézze meg, mit rögzít a hibakövető. A hívási veremben rutinszerűen van e-mail-cím, token és kéréstörzs.
• Nézze meg a naplómegőrzést. Az örökre megtartott, IP-címet tartalmazó hozzáférési naplók az egyik leggyakoribb megállapítás és az egyik legkönnyebben javítható.

Írja le adatkezelési tevékenységek nyilvántartásaként. A 30. cikk ezt a legtöbb szervezettől amúgy is megköveteli, a fejlesztők számára hasznos változat pedig egy táblázat rendszerrel, adatokkal, céllal, jogalappal, megőrzési idővel és címzettekkel.

Válasszon jogalapot célonként, ne rendszerenként

A 6. cikk hat jogalapot ad. A leggyakoribb hiba egyet választani az egész termékre.

Szinte biztosan több cél fut egyszerre. A megrendelés teljesítése szerződés. A csalásellenőrzés általában jogos érdek vagy jogi kötelezettség. A számlák törvényes ideig való megőrzése jogi kötelezettség. A marketinglevél a legtöbb tagállamban hozzájárulás. A nem elengedhetetlen analitika hozzájárulás, a végberendezéshez való hozzáférésre vonatkozó ePrivacy-szabályok miatt, nem magának a GDPR-nek köszönhetően.

A gyakorlati következmény, hogy az adatmodelljének tudnia kell, melyik célt szolgálja az egyes rekordok. Ha nem tudja szétválasztani a marketingprofilt a rendelési rekordtól, nem tud eleget tenni egy marketing-tiltakozásnak a rendeléstörténet szétverése nélkül. Ez a szétválasztás sémadöntés, és fájdalmas utólag beépíteni.

A hozzájárulásnak valósnak kell lennie, és rögzíteni kell

Ha hozzájárulásra támaszkodik, annak önkéntesnek, konkrétnak, tájékozottnak és egyértelműnek kell lennie, és később bizonyítani is tudnia kell.

Konkrétan:

• Semmi nem elengedhetetlen dolog nem indul el, mielőtt a felhasználó cselekedne. Ide tartozik az analitikai kódrészlet, a hirdetési pixel, a csevegőwidget, a harmadik féltől származó CDN-ről betöltött betűtípus és az A/B tesztelő szkript.
• Az elutasításnak ugyanolyan könnyűnek kell lennie, mint az elfogadásnak. Ugyanaz a réteg, ugyanaz a hangsúly, ugyanannyi kattintás. A hatóságok minden mást sötét mintaként kezelnek, és ebben következetesek.
• A hozzájárulás célonkénti. Egyetlen kapcsoló, amely lefedi az „analitikát és marketinget és személyre szabást", nem konkrét.
• A visszavonás ugyanolyan könnyű, mint a megadás. Állandó hivatkozás vagy lebegő gomb, nem e-mail a támogatásnak.
• Őrizze meg a bizonyítékot: időbélyeget, a hozzájárulási karakterláncot vagy az egyes kategóriák állapotát, a banner verzióját és a felhasználónak megjelenített szöveget. Verzió nélkül nem tud megvédeni egy kétéves hozzájárulási bejegyzést.

A végrehajtás itt nem elméleti. 2025 szeptemberében a francia hatóság ugyanazon a napon 325 millió euróra bírságolta a Google-t és 150 millióra a Sheint sütikkel kapcsolatos gyakorlatokért. Mindkét ügy a mechanikáról szólt, nem a szabályzat szövegéről: sütik kerültek kihelyezésre bármilyen interakció előtt, és az elutasító gombok valójában nem utasítottak el.

A szabályok is mozgásban vannak. A Digital Omnibus javaslat a végberendezéshez való hozzájárulást magába a GDPR-ba helyezné, és kötelezővé tenné a böngészőjelzéseket. Hogy ez mit változtatna, a sütihozzájárulás a Digital Omnibus után cikkben írtuk meg.

Építse ki korán az érintetti jogok gépezetét

A 15. és 22. cikk közötti rendelkezések hozzáférési, helyesbítési, törlési, korlátozási, hordozhatósági és tiltakozási jogot adnak. Egy hónapja van a válaszra, bonyolult esetben háromra hosszabbítható.

A csapatok az első kéréseket általában kézzel intézik, ami pontosan addig működik, amíg nem. Amit jóval a mennyiség megérkezése előtt érdemes birtokolni:

Egy feloldó, amely rendszereken átívelően megtalál egy személyt. Egy e-mail-címhez visszaadni mindent: a fiókot, a rendeléseket, a támogatási jegyeket, a marketingprofilt, az analitikai azonosítót, a naplókat. Ha egy embernek kell emlékeznie arra, hogy van még egy harmadik féltől származó értékelési platform adatokkal, valaki egyszer elfelejti.

Egy törlési útvonal, amely tiszteletben tartja a megőrzési kötelezettségeket. A törlés nem abszolút. A számláknak adózási okból általában túl kell élniük. Amire szükség van: puha törlés célhoz kötött végleges törléssel, hogy eltávolíthassa a marketingprofilt a könyvelési rekord megtartása mellett, és hogy az a rekord maga is időben lejárjon.

Hordozható export. Strukturált, széles körben használt, géppel olvasható. A JSON rendben van. Egy megjelenített HTML-oldal PDF-je nem.

Egy tiltakozási jelző, amelyet az egész rendszer olvas. A profilalkotás elleni tiltakozásnak valóban meg kell állítania a profilalkotást, beleértve a hajnali háromkor futó kötegelt feladatot is, amely nem nézi a jelzőt.

A megőrzés munka, nem szabályzatsor

A tárolás korlátozása az az elv, amelyet az egyébként jól megépített rendszerek a leggyakrabban sértenek meg, mert a törléshez valakinek meg kell írnia és ütemeznie kell egy feladatot, amit senki nem kér.

Adjon minden adatkategóriának meghatározott élettartamot, majd valósítsa is meg. A hozzáférési naplók, munkamenetek, elhagyott kosarak, meg nem erősített regisztrációk, lezárt jegyek, régi biztonsági mentések és nyers analitikai adatok mind lejáratot igényelnek. A biztonsági mentések külön figyelmet érdemelnek: ha a visszaállítási folyamat feltámasztja a törölt személyes adatokat, a törlése hiányos, a szokásos válasz pedig dokumentált mentésrotáció maximális korral, plusz a törlések újbóli alkalmazása minden visszaállítás után.

Továbbítások, további adatfeldolgozók és hogy hol fut valójában a rendszere

Az EGT-n kívüli továbbításokhoz jogi mechanizmus kell, általában az EU és az USA közötti adatvédelmi keret a tanúsított amerikai címzetteknél, vagy általános szerződési feltételek plusz továbbítási hatásvizsgálat máshol.

A mérnöki oldal egyszerűbb a jogi oldalnál: tudni, hol vannak fizikailag az adatai. Ez azt jelenti: minden szolgáltatás felhőrégiója, a mentések helye, a felügyelt adatbázis régiója, a CDN élkonfigurációja és, ami fontos, minden használt SaaS-eszköz támogatási modellje. Egy Frankfurtban tárolt szolgáltató, amelynek támogatási csapata az EGT-n kívülről fér hozzá az éles rendszerhez, továbbra is továbbítás.

Általában azt javasoljuk, hogy a személyes adatokat EU-régiókban tartsák, ha nincs erős ok az ellenkezőjére. Ez egy egész vitakategóriát eltüntet, a költségkülönbség pedig általában zaj.

Vezessen listát a további adatfeldolgozókról, és tartsa naprakészen. A 28. cikk mindegyikkel írásbeli szerződést kíván, és ez a lista az is, amit az ügyfelei átvilágításkor kérni fognak.

Alapértelmezett biztonság, konfigurációként megfogalmazva

A 32. cikk megfelelő technikai és szervezési intézkedéseket kíván. Ez szándékosan homályos, de a 2026-os weboldal alapja nem alku tárgya:

• TLS mindenhol, HSTS bekapcsolva, vegyes tartalom nélkül.
• Jelszavak modern, memóriaigényes függvénnyel hashelve, és többtényezős hitelesítés elérhető a személyes adatokat tartalmazó fiókoknál.
• Titkosítás nyugalmi állapotban az adatbázisokra és mentésekre.
• Az éles személyes adatokhoz való hozzáférés szerep szerint korlátozva és naplózva, valóban megtörténő felülvizsgálatokkal.
• Álnevesítés, ahol lehetséges: az azonosító hashelése az analitikában, a megfeleltetési tábla külön és korlátozott hozzáféréssel.
• Tesztelt visszaállítás, nem csak mentés.

A beépített és alapértelmezett adatvédelem a 25. cikkben azt jelenti, hogy az adatvédelmet szolgáló beállítás az, amit tétlenül is megkap. Hírlevél-jelölőnégyzet üresen. Profil láthatósága privát. Az opcionális mezők opcionálisak.

Az adatvédelmi incidens bejelentése forgatókönyvet kíván

Hetvenkét óra a tudomásszerzéstől a felügyeleti hatóság értesítéséig nem sok, különösen ha az incidenst pénteken este fedezik fel. A Digital Omnibus javaslat ezt kilencvenhat órára tolná, de ez még nem hatályos jog.

Készüljön előre: ki nyilvánít incidenst, ki értékeli, hogy érintettek-e személyes adatok, ki keresi meg a hatóságot, mit tartalmaz a bejelentés, és hogyan tájékoztatja az érintetteket, ha magas a kockázat. Írja meg forgatókönyvként megnevezett szerepekkel, és gyakorolja egyszer. Az első használat ne az első olvasás legyen.

Maga a webhelyfelület

A GDPR egy része látszik az oldalon, és megéri ezeket a részleteket rendben tartani, mert éppen ezeket jelentik be az emberek.

Az adatvédelmi tájékoztatónak meg kell adnia az adatkezelő kilétét és elérhetőségét, a célokat és jogalapokat, a címzetteket és címzetti kategóriákat, a továbbítási mechanizmusokat, a megőrzési időket, a jogok teljes listáját a felügyeleti hatósághoz benyújtható panasz jogával együtt, és azt, hogy van-e automatizált döntéshozatal. Írjon olyan nyelven, amit egy hétköznapi ember követni tud. A rétegzett tájékoztatók, rövid változattal, amely a részletekre mutat, jobban működnek, mint a szövegfal.

Az űrlapok csak azt gyűjtsék, amire szükség van. Minden mező egy indoklás, amit esetleg meg kell adnia. Ha a marketing-hozzájárulási négyzet ugyanabban a beküldésben van, mint a rendelés, külön kell üresen hagyni és külön kell megfogalmazni.

A harmadik féltől beágyazott tartalmak a csendes hiba. YouTube fokozott adatvédelmi módban, térképek kattintásra betöltődő helyőrző mögött, betűtípusok saját tárhelyen a harmadik féltől származó CDN helyett. Mindegyik változtatás kicsi, és egy megállapítást töröl.

Mit látunk a leggyakrabban elromlani

Elég sok auditálás után ugyanaz a rövid lista bukkan fel:

1. Analitika, amely a hozzájárulás előtt töltődik be, általában mert a címkekezelőt a marketing állította be, és a mérnöki csapat soha nem nézte át.
2. Elutasító gombok, amelyek egy harmadik féltől származó szkript alapértelmezett viselkedése miatt mégis hozzájárulást váltanak ki.
3. Egyáltalán nincsenek megőrzési feladatok, egyetlen táblán sem.
4. Törlés, amely kihagyja a mentéseket, a naplókat és a CRM-et.
5. Adatvédelmi tájékoztató, amely tizennyolc hónapja megváltozott adatáramlást ír le.
6. További adatfeldolgozói listák, amelyek megállnak a három nyilvánvaló szolgáltatónál.
7. Hozzájárulási bejegyzések a megjelenített szöveg verziója nélkül.

Egyik sem nehéz probléma. Egyszerűen olyan munka, amit senki nem osztott ki.

Segítségkérés

Ha második szempárt szeretne egy meglévő webhelyre, technikai GDPR-auditokat végzünk, amelyek jelentés helyett rangsorolt feladatlistát adnak: mit javítson, milyen sorrendben, tételenkénti becsléssel. Ha újat épít, jóval olcsóbb az adatmodellt és a hozzájárulási architektúrát rögtön jól megcsinálni.

Lefedjük a szélesebb uniós megfelelési felületet is, benne az akadálymentesítéssel és az európai piacra lépéssel. Elérhetőségünk: office@c9group.dev.

Szoftvert építünk. Nem adunk jogi tanácsot, és egy konkrét követelmény értelmezése a jogászaira tartozik. Amit tehetünk: gondoskodunk arról, hogy a rendszer azt tegye, amit a jogászai mondanak.