What a DSAR Actually Is

A Data Subject Access Request (DSAR) is the moment a user exercises the rights the GDPR grants them over their personal data. For a mobile publisher, that “data subject” is one of your players or users, and the request can arrive by email, support ticket, app store review, or in-app form. The trigger is simple: someone wants to know what you hold about them — or wants you to act on it.

Crucially, a DSAR need not mention the GDPR, use the word “DSAR,” or follow any template. A one-line message like “send me my data” or “delete my account” starts the clock just as firmly as a formal legal letter. Treating only formal-looking requests as valid is a fast way to miss a deadline.

The Rights Behind the Request

DSARs bundle several distinct rights, and the same message may invoke more than one. Knowing which is which determines what you actually have to do.

• Access — the user can ask for a copy of their personal data plus context: what you collect, why, who you share it with, and how long you keep it.
• Erasure (“right to be forgotten”) — deletion of their data, including copies passed to ad and analytics partners, subject to narrow legal exceptions.
• Portability — data they gave you, returned in a structured, machine-readable format such as JSON or CSV so it can move elsewhere.
• Rectification — correction of inaccurate or incomplete data, for example a wrong email or region.

Related rights — objection to processing and restriction — often travel alongside these, especially around ad personalization where a user may withdraw consent rather than delete their account outright.

The Deadlines Are Strict

You must respond without undue delay and within one calendar month of receiving the request. The clock starts the day the request arrives, not the day someone on your team notices it. You may extend by two further months for genuinely complex requests, but only if you tell the user within that first month and explain why.

Responses are normally free. You can charge a reasonable fee or refuse only when a request is manifestly unfounded or excessive, and the burden of proving that sits with you. For most publishers the safe assumption is: free, and inside thirty days. Missing the window is exactly the kind of lapse regulators point to when assessing fines.

Building a Workflow That Scales

The publishers who handle DSARs calmly have turned them into a repeatable process rather than a fire drill. A workable workflow looks like this:

• Intake. Publish a single, advertised channel — an in-app form or a dedicated privacy@ address — and route everything through it so nothing gets lost in support queues.
• Verify identity. Confirm the requester owns the account, but ask only for what you need. Demanding a passport scan to look up an in-game ID is itself a compliance problem.
• Log and timestamp. Record the arrival date immediately; this is your deadline anchor.
• Locate the data. Maintain a data map of every store — your backend, crash logs, analytics, ad SDKs, CRM — that touches user data, keyed by a stable identifier.
• Fulfill & respond. Export, delete, or correct as requested, propagate deletions to processors, and reply in plain language.
• Close the loop. Archive the request and your response as evidence you acted in time.

Common Pitfalls

Most failures are operational, not legal. Watch for these:

• Forgotten data stores. Ad and attribution SDKs, push providers, and crash reporters all hold user data. A deletion that skips them is incomplete.
• Over-collecting during verification, turning a privacy request into a privacy risk.
• Treating informal messages as non-requests and letting the month lapse.
• No proof of consent. If a user disputes that you ever had a lawful basis to process their data for ads, you need to show what they agreed to and when.

How a CMP Makes DSARs Manageable

This is where your consent layer earns its keep. A DSAR is far easier to answer when you can instantly show what a user consented to, when, and under which framework. FlexyConsent — a Google-certified CMP supporting IAB TCF 2.3 and Google Consent Mode v2 — stores a timestamped consent record and audit trail for every user. When an access request lands, that record becomes a ready-made part of your response: the purposes accepted, the vendors involved, and the version of the notice shown. When an erasure or objection request arrives, the same record proves you stopped personalized ad signals at the right moment. Pairing that consent history with your data map turns a DSAR from a scramble into a lookup.

This article is general information for publishers and is not legal advice; consult a qualified professional for your specific situation.

Key Takeaways

• Any request — however informal — can be a DSAR, and the one-month, usually-free deadline starts the day it arrives.
• Map every data store, including ad and analytics SDKs, so access and deletion are actually complete.
• Verify identity proportionately and log each request to prove you responded in time.
• FlexyConsent’s consent records and audit trail give you instant, defensible evidence to fulfill access, erasure, and objection requests.