GDPR-kompatibilis weboldal készítés: architektúra-kérdés, nem plugin-kérdés

A legtöbb útmutató a GDPR-ról ugyanott kezdi és ugyanott fejezi be: legyen cookie-banner, legyen adatkezelési tájékoztató. Mindkettő kell. Csakhogy a megfelelés nagyobbik része nem a látható felületen dől el, hanem a motorháztető alatt: azon, hogy a weboldalad hova ír adatot, mikor, és ki fér hozzá. Ezek technikai döntések — és egy sablonos rendszerben jellemzően már meg vannak hozva helyetted. Nem biztos, hogy jól.

Egy dolgot tisztázzunk az elején: ez a cikk nem jogi tanácsadás. Mi a technikai alapot adjuk; az adatkezelési tájékoztatót és a jogi megfelelést ügyvédnek kell összeraknia. Amit viszont egy jogász nem fog megnézni helyetted: hogy a kód tényleg azt csinálja-e, amit a tájékoztatóban leírtatok. Erről szól ez az írás.

Hol tárolódnak ténylegesen az adataid?

Egy tipikus sablonos stackben az adatok útja átláthatatlan. Az űrlapbeküldés egy plugin szerverére megy, a hírlevél-feliratkozás egy amerikai SaaS-be, a mérési adatok egy hirdetési platform rendszerébe — és mindegyik mögött ott a saját adatfeldolgozói lánca. A hosting-régió gyakran alapértelmezésből EU-n kívüli, és senki nem döntött róla tudatosan.

Az első kérdés, amit egy auditon felteszünk, mindig ugyanaz: fel tudod-e sorolni, hova ír adatot az oldalad? Ha a válasz nem, akkor a tájékoztatód sem lehet pontos — legfeljebb véletlenül.

Amikor az „Elutasít" gomb nem állít le semmit

A leggyakoribb technikai hiba, amivel találkozunk: a consent-banner és a tényleges adatgyűjtés két külön világban él. A banner megjelenik, a látogató elutasít — közben a mérőkódok és pixelek már rég betöltődtek az oldal első renderelésekor. A banner ilyenkor díszlet: a hozzájárulás-kezelés UI-ja megvan, a logikája nincs.

A helyes irány fordított: a consent-állapot kapuzza a betöltést. Amíg nincs hozzájárulás, a script el sem indul — és ezt nem a plugin ígéretére bízzuk, hanem a hálózati forgalmon ellenőrizzük. Ez az a pont, ahol a megfelelés kódolási kérdéssé válik.

Third-party scriptek és beágyazások: a legnagyobb szivárgási pont

Minden beágyazott térkép, videó, chat-widget és betűtípus-CDN önálló adatkapcsolat egy harmadik fél felé — jellemzően már azelőtt, hogy a látogató bármihez hozzájárult volna. A sablonos oldalak ebből építkeznek, mert így a leggyorsabb összerakni őket. Az ára az, hogy az adatáramlás feletti kontroll kikerül a kezedből.

Az ökölszabály egyszerű: ami „ingyen" beágyazható, az adattal fizet. Nem kell mindent kidobni — de mindegyikről tudni kell, hogy ott van, mit küld, és consent mögé kell tenni, aminek ott a helye.

Mit ad egy egyedi vagy headless alapú stack?

Az egyedi architektúra a fenti problémák nagy részét tervezési szinten oldja meg:

• Saját adatréteg. Az űrlapok, feliratkozások, ügyféladatok a te adatbázisodba mennek, te döntöd el a tárolás régióját és az élettartamát.

• Szerveroldali, first-party mérés. Az analitika a saját domainedről, a saját szervereden fut — kevesebb third-party kapcsolat, pontosabb adat, tisztább consent-helyzet.

• Granulárisan kikapcsolható integrációk. Minden külső szolgáltatás egy jól körülhatárolt integrációs pont, amit ki lehet kapcsolni vagy le lehet cserélni — nem húsz plugin szövevénye.

• A consent és a betöltés egy kézben van. Ugyanaz a kód dönt a hozzájárulásról és a scriptek indításáról, így a kettő nem tud szétcsúszni.

Arról, hogy egy headless CMS-alapú felállásban ki és hogyan kezeli a tartalmat, külön írtunk: Headless CMS: ki tölti fel a tartalmat, ha nem a fejlesztő?

Törlési és adatkiadási kérelmek gépi kiszolgálása

A GDPR nem csak a gyűjtésről szól: a látogatónak joga van tudni, mit tárolsz róla, kérheti az adatai kiadását és a törlésüket. Ha az adatok húsz rendszerben szóródnak szét, minden ilyen kérelem kézi nyomozás — lassú, drága és hibázós.

Jól strukturált saját adatrétegben ugyanez egy lekérdezés és egy végpont kérdése: a törlési kérelem kiszolgálása automatizálható, és auditálható nyoma marad. Ez tervezéskor olcsó. Utólag ráépíteni egy szétszórt rendszerre — az drága.

Mit kérdezz meg a fejlesztődtől, mielőtt aláírsz?

Ha weboldal-fejlesztésre kérsz ajánlatot, ez a hat kérdés többet elárul a GDPR-érettségről, mint bármilyen tanúsítvány-logó a láblécben:

• Hol tárolódnak az adatok, és melyik régióban?

• Mely harmadik felek kapnak adatot az oldalról, és mi alapján?

• Mit csinál pontosan az „Elutasít" gomb — és hogyan tudjuk ezt ellenőrizni?

• Hogyan teljesítünk egy törlési vagy adatkiadási kérelmet, és mennyi idő alatt?

• Van-e adatfeldolgozói szerződés a felhasznált szolgáltatókkal?

• Mi történik az adatokkal, ha megszűnik az együttműködés?

Aki ezekre habozás nélkül válaszol, az architektúra-szinten gondolkodik a megfelelésről. Aki egy plugin nevével válaszol, az nem.

A bizalom architektúra kérdése

A GDPR-t lehet nyűgként kezelni, és lehet arra használni, amire való: hogy az ügyfeleid adatai tényleg jó kezekben legyenek — és ezt bizonyítani is tudd. Az előbbi egy banner. Az utóbbi egy jól megtervezett rendszer. Ha az utóbbit szeretnéd, a webfejlesztés és az egyedi szoftverfejlesztés oldalunkon leírtuk, hogyan dolgozunk — a jogi részhez pedig hozd az ügyvéded, mi jól kijövünk velük.