Wat een DSAR eigenlijk is

Een inzageverzoek van een betrokkene (DSAR) is het moment waarop een gebruiker de rechten uitoefent die de GDPR hem geeft over zijn persoonsgegevens. Voor een mobiele uitgever is die “betrokkene” een van uw spelers of gebruikers, en het verzoek kan binnenkomen via e-mail, een supportticket, een review in de appstore of een formulier in de app. De aanleiding is simpel: iemand wil weten wat u over hem bewaart — of wil dat u er iets mee doet.

Cruciaal is dat een DSAR de GDPR niet hoeft te noemen, het woord “DSAR” niet hoeft te gebruiken en geen enkel sjabloon hoeft te volgen. Een bericht van één regel als “stuur me mijn gegevens” of “verwijder mijn account” zet de klok net zo stellig in gang als een formele juridische brief. Alleen formeel ogende verzoeken als geldig behandelen is een snelle manier om een termijn te missen.

De rechten achter het verzoek

DSAR's bundelen verschillende afzonderlijke rechten, en hetzelfde bericht kan er meer dan één inroepen. Weten welk recht welk is, bepaalt wat u feitelijk moet doen.

• Inzage — de gebruiker kan een kopie van zijn persoonsgegevens plus context opvragen: wat u verzamelt, waarom, met wie u het deelt en hoe lang u het bewaart.
• Wissing (“recht om vergeten te worden”) — verwijdering van zijn gegevens, inclusief kopieën die zijn doorgegeven aan advertentie- en analysepartners, behoudens enge wettelijke uitzonderingen.
• Overdraagbaarheid — gegevens die hij u heeft gegeven, teruggegeven in een gestructureerd, machineleesbaar formaat zoals JSON of CSV zodat ze elders naartoe kunnen.
• Rectificatie — correctie van onjuiste of onvolledige gegevens, bijvoorbeeld een verkeerd e-mailadres of regio.

Verwante rechten — bezwaar tegen verwerking en beperking — reizen vaak met deze mee, vooral rond advertentiepersonalisatie waar een gebruiker zijn toestemming kan intrekken in plaats van zijn account meteen te verwijderen.

De termijnen zijn streng

U moet zonder onnodige vertraging en binnen één kalendermaand na ontvangst van het verzoek reageren. De klok begint op de dag dat het verzoek binnenkomt, niet op de dag dat iemand in uw team het opmerkt. U mag met twee maanden verlengen voor werkelijk complexe verzoeken, maar alleen als u de gebruiker binnen die eerste maand informeert en uitlegt waarom.

Reacties zijn normaal gesproken gratis. U kunt alleen een redelijke vergoeding vragen of weigeren wanneer een verzoek kennelijk ongegrond of buitensporig is, en de bewijslast daarvoor ligt bij u. Voor de meeste uitgevers is de veilige aanname: gratis, en binnen dertig dagen. Het missen van de termijn is precies het soort verzuim waar toezichthouders op wijzen bij het beoordelen van boetes.

Een workflow bouwen die schaalt

De uitgevers die DSAR's kalm afhandelen, hebben er een herhaalbaar proces van gemaakt in plaats van een brandoefening. Een werkbare workflow ziet er zo uit:

• Intake. Publiceer één aangekondigd kanaal — een formulier in de app of een speciaal privacy@-adres — en leid alles daardoorheen zodat er niets verloren gaat in supportwachtrijen.
• Verifieer de identiteit. Bevestig dat de verzoeker eigenaar is van het account, maar vraag alleen wat u nodig hebt. Een paspoortscan eisen om een in-game ID op te zoeken is zelf al een nalevingsprobleem.
• Registreer en zet een tijdstempel. Leg de datum van binnenkomst onmiddellijk vast; dit is uw ankerpunt voor de termijn.
• Lokaliseer de gegevens. Onderhoud een datakaart van elke opslag — uw backend, crashlogs, analytics, advertentie-SDK's, CRM — die gebruikersgegevens raakt, gesleuteld op een stabiele identifier.
• Voer uit en reageer. Exporteer, verwijder of corrigeer zoals gevraagd, geef verwijderingen door aan verwerkers en antwoord in begrijpelijke taal.
• Sluit de cirkel. Archiveer het verzoek en uw reactie als bewijs dat u op tijd hebt gehandeld.

Veelvoorkomende valkuilen

De meeste fouten zijn operationeel, niet juridisch. Let op de volgende:

• Vergeten dataopslagplaatsen. Advertentie- en attributie-SDK's, pushproviders en crashrapporteurs bewaren allemaal gebruikersgegevens. Een verwijdering die ze overslaat, is onvolledig.
• Te veel verzamelen tijdens verificatie, waardoor een privacyverzoek een privacyrisico wordt.
• Informele berichten als niet-verzoeken behandelen en de maand laten verstrijken.
• Geen bewijs van toestemming. Als een gebruiker betwist dat u ooit een wettelijke grondslag had om zijn gegevens voor advertenties te verwerken, moet u kunnen tonen waarmee hij heeft ingestemd en wanneer.

Hoe een CMP DSAR's beheersbaar maakt

Dit is waar uw toestemmingslaag zich terugbetaalt. Een DSAR is veel makkelijker te beantwoorden wanneer u direct kunt tonen waarmee een gebruiker heeft ingestemd, wanneer en onder welk kader. FlexyConsent — een door Google gecertificeerde CMP die IAB TCF 2.3 en Google Consent Mode v2 ondersteunt — bewaart voor elke gebruiker een toestemmingsregistratie en audittrail met tijdstempel. Wanneer een inzageverzoek binnenkomt, wordt die registratie een kant-en-klaar onderdeel van uw reactie: de geaccepteerde doeleinden, de betrokken vendoren en de versie van de getoonde melding. Wanneer een wissings- of bezwaarverzoek binnenkomt, bewijst dezelfde registratie dat u gepersonaliseerde advertentiesignalen op het juiste moment hebt gestopt. Die toestemmingsgeschiedenis koppelen aan uw datakaart maakt van een DSAR een opzoekactie in plaats van een paniekklus.

Dit artikel is algemene informatie voor uitgevers en is geen juridisch advies; raadpleeg een gekwalificeerde professional voor uw specifieke situatie.

Belangrijkste conclusies

• Elk verzoek — hoe informeel ook — kan een DSAR zijn, en de termijn van één maand, meestal gratis, begint op de dag dat het binnenkomt.
• Breng elke dataopslag in kaart, inclusief advertentie- en analyse-SDK's, zodat inzage en verwijdering ook echt volledig zijn.
• Verifieer de identiteit proportioneel en registreer elk verzoek om te bewijzen dat u op tijd hebt gereageerd.
• De toestemmingsregistraties en audittrail van FlexyConsent geven u direct, verdedigbaar bewijs om inzage-, wissings- en bezwaarverzoeken af te handelen.