Mi is valójában a DSAR

Az érintetti hozzáférési kérelem (DSAR) az a pillanat, amikor a felhasználó gyakorolja azokat a jogokat, amelyeket a GDPR a személyes adatai felett biztosít számára. Egy mobilkiadó számára ez az „érintett” az egyik játékosa vagy felhasználója, és a kérelem érkezhet e-mailben, support jegyként, alkalmazásbolti értékelésben vagy alkalmazáson belüli űrlapon. A kiváltó ok egyszerű: valaki tudni szeretné, mit tárolsz róla — vagy azt szeretné, hogy tegyél valamit ezzel kapcsolatban.

Lényeges, hogy egy DSAR-nak nem kell megemlítenie a GDPR-t, használnia a „DSAR” szót, vagy követnie bármilyen sablont. Egy egysoros üzenet, mint a „küldd el az adataimat” vagy „töröld a fiókomat” ugyanolyan határozottan elindítja az órát, mint egy hivatalos jogi levél. Csak a hivatalosnak tűnő kérelmeket érvényesnek tekinteni gyors út a határidő elmulasztásához.

A kérelem mögötti jogok

A DSAR-ok több különböző jogot foglalnak magukba, és ugyanaz az üzenet egynél többet is érvényesíthet. Annak ismerete, hogy melyik melyik, meghatározza, mit kell ténylegesen tenned.

• Hozzáférés — a felhasználó kérheti személyes adatainak másolatát a kontextussal együtt: mit gyűjtesz, miért, kivel osztod meg, és meddig őrzöd.
• Törlés („elfeledtetéshez való jog”) — adatainak törlése, beleértve a hirdetési és analitikai partnereknek átadott másolatokat is, szűk jogi kivételek mellett.
• Hordozhatóság — a neked adott adatok visszaadása strukturált, géppel olvasható formátumban, például JSON vagy CSV, hogy máshová mozgathatók legyenek.
• Helyesbítés — a pontatlan vagy hiányos adatok javítása, például egy hibás e-mail vagy régió.

A kapcsolódó jogok — az adatkezelés elleni tiltakozás és a korlátozás — gyakran ezekkel együtt jelennek meg, különösen a hirdetés-személyre szabás körül, ahol a felhasználó inkább visszavonhatja a hozzájárulását, mintsem teljesen törölné a fiókját.

A határidők szigorúak

Indokolatlan késedelem nélkül és egy naptári hónapon belül kell válaszolnod a kérelem beérkezésétől. Az óra azon a napon indul, amikor a kérelem megérkezik, nem azon, amikor valaki a csapatodban észreveszi. Valóban összetett kérelmek esetén további két hónappal hosszabbíthatsz, de csak akkor, ha az első hónapon belül értesíted a felhasználót, és elmagyarázod, miért.

A válaszok általában ingyenesek. Ésszerű díjat csak akkor számíthatsz fel, vagy akkor utasíthatsz vissza, ha egy kérelem nyilvánvalóan megalapozatlan vagy túlzó, és ennek bizonyítása rád hárul. A legtöbb kiadó számára a biztonságos feltételezés: ingyenes és harminc napon belül. Az időablak elmulasztása pontosan az a fajta mulasztás, amelyre a szabályozók a bírságok megállapításakor rámutatnak.

Skálázható munkafolyamat felépítése

Azok a kiadók, akik nyugodtan kezelik a DSAR-okat, ismételhető folyamattá alakították őket tűzoltás helyett. Egy működő munkafolyamat így néz ki:

• Fogadás. Tegyél közzé egyetlen, meghirdetett csatornát — egy alkalmazáson belüli űrlapot vagy egy dedikált privacy@ címet —, és irányíts mindent ezen keresztül, hogy semmi se vesszen el a support sorokban.
• Személyazonosság ellenőrzése. Erősítsd meg, hogy a kérelmező a fiók tulajdonosa, de csak azt kérd, amire szükséged van. Útlevélszkennt kérni egy játékon belüli azonosító kikereséséhez maga is megfelelési probléma.
• Naplózás és időbélyegzés. Rögzítsd azonnal a beérkezés dátumát; ez a határidő horgonyod.
• Az adatok megtalálása. Tarts fenn adattérképet minden tárolóról — a háttérrendszered, összeomlási naplók, analitika, hirdetési SDK-k, CRM —, amely felhasználói adatokat érint, egy stabil azonosító szerint rendezve.
• Teljesítés & válasz. Exportálj, törölj vagy javíts az igénylés szerint, terjeszd ki a törléseket az adatfeldolgozókra, és válaszolj közérthető nyelven.
• A kör lezárása. Archiváld a kérelmet és a válaszodat bizonyítékként, hogy időben cselekedtél.

Gyakori buktatók

A legtöbb hiba operatív, nem jogi jellegű. Figyelj ezekre:

• Elfelejtett adattárolók. A hirdetési és attribúciós SDK-k, push-szolgáltatók és összeomlás-jelentők mind tárolnak felhasználói adatokat. Egy törlés, amely kihagyja őket, hiányos.
• Túlzott adatgyűjtés az ellenőrzés során, ami egy adatvédelmi kérelmet adatvédelmi kockázattá változtat.
• Az informális üzenetek nem-kérelemként kezelése és a hónap elteltének hagyása.
• Nincs bizonyíték a hozzájárulásra. Ha egy felhasználó vitatja, hogy valaha is volt jogalapod az adatai hirdetési célú kezelésére, meg kell tudnod mutatni, mihez és mikor járult hozzá.

Hogyan teszi a CMP kezelhetővé a DSAR-okat

Itt térül meg a hozzájárulási rétegt. Egy DSAR sokkal könnyebben megválaszolható, ha azonnal meg tudod mutatni, mihez járult hozzá a felhasználó, mikor, és milyen keretrendszer szerint. A FlexyConsent — egy Google-tanúsított CMP, amely támogatja az IAB TCF 2.3-at és a Google Consent Mode v2-t — minden felhasználóhoz időbélyeggel ellátott hozzájárulási rekordot és audit nyomvonalat tárol. Amikor egy hozzáférési kérelem érkezik, ez a rekord a válaszod kész részévé válik: az elfogadott célok, az érintett szolgáltatók és a megjelenített értesítés verziója. Amikor törlési vagy tiltakozási kérelem érkezik, ugyanaz a rekord bizonyítja, hogy a megfelelő pillanatban leállítottad a személyre szabott hirdetési jeleket. Ennek a hozzájárulási előzménynek az adattérképeddel való párosítása a DSAR-t kapkodásból egyszerű lekereséssé alakítja.

Ez a cikk általános információ kiadók számára, és nem jogi tanács; konkrét helyzetedhez fordulj képzett szakemberhez.

Legfontosabb tanulságok

• Bármely kérelem — bármennyire informális — lehet DSAR, és az egyhónapos, általában ingyenes határidő a beérkezés napján indul.
• Térképezz fel minden adattárolót, beleértve a hirdetési és analitikai SDK-kat, hogy a hozzáférés és a törlés valóban teljes legyen.
• Ellenőrizd a személyazonosságot arányosan, és naplózz minden kérelmet, hogy bizonyítsd az időben adott választ.
• A FlexyConsent hozzájárulási rekordjai és audit nyomvonala azonnali, védhető bizonyítékot adnak a hozzáférési, törlési és tiltakozási kérelmek teljesítéséhez.