How to Respond to a GDPR Data Subject Access Request

A data subject access request, a DSAR, is one sentence from anyone whose personal data you hold: "send me a copy of everything you have on me." No form, no special wording, no requirement that it even mention GDPR by name. It can arrive as a reply-all on a support ticket, a comment on a contact form, or a line buried in an angry email about something else entirely, and the moment it does, a legal deadline starts whether or not anyone on your team has noticed it yet.

Article 15 of the GDPR gives every individual whose data you process the right to confirmation that you're processing their data, a copy of that data, and a specific list of information about how and why. Getting the response right, on time, matters more than most teams assume: a missed or incomplete DSAR response is one of the more common triggers for a complaint to a data protection authority, precisely because it's easy to spot from the outside and easy to prove.

The response process, step by step

Step 1: Log the date the request arrived, not the date you noticed it

The one month deadline in Article 12(3) runs from receipt of the request, not from when it lands on the right desk. If a DSAR comes in through a general support inbox and sits unread for a week before someone forwards it to legal or the DPO, that week still counts against the deadline. The fix is procedural, not legal: every channel that could plausibly receive a request, support email, contact form, social media, in-app chat, needs a routing rule that timestamps and forwards anything that looks like a data request the same day.

Step 2: Verify who's actually asking

Article 12(6) lets you ask for reasonable additional information to confirm identity when you have reasonable doubts, and you should use that right before handing over personal data to the wrong person. In practice that means matching the request to an existing account, email address, or customer record you already hold, not demanding a government ID for a routine request from someone whose identity is already obvious from the account they're logged into. Over-verifying is its own problem: asking for more identity information than you need, or than you'd need for any other interaction, is itself a data minimization issue regulators have flagged in enforcement guidance.

Step 3: Search every system that might hold their data, not just the obvious one

This is where most incomplete responses fail. A DSAR covers personal data wherever it lives, the CRM, the support ticketing system, marketing automation lists, server and application logs, backups a reasonable search would reach, and internal tools like a shared spreadsheet a sales rep uses to track leads. It doesn't require an unlimited forensic search of every backup tape ever created, but "we only checked the database" is not a defensible search when the request clearly implicates other systems too.

Step 4: Apply exemptions carefully, not by default

Article 15(4) says the right to a copy "shall not adversely affect the rights and freedoms of others." That means redacting or withholding a third party's personal data mixed into the requester's own records, a colleague's name in an internal email thread, for example, rather than refusing the whole request. It does not mean withholding data because it's commercially inconvenient, embarrassing, or mixed in with business analysis. National implementing laws add a small number of specific exemptions on top of this (legal privilege being the most common), and those should be applied narrowly and documented, not treated as a general escape hatch.

Step 5: Compile a response that actually contains what Article 15 requires

A response that says "here is your data" without the surrounding context Article 15 requires is incomplete, even if the underlying data export is accurate.

What the reply itself has to include

Beyond a copy of the personal data undergoing processing, Article 15(1) requires the response to cover, specifically:

• The purposes of the processing.
• The categories of personal data involved.
• The recipients or categories of recipients the data has been or will be disclosed to, including any recipients in third countries.
• The envisaged retention period, or the criteria used to decide it, when a fixed period isn't possible.
• The existence of the rights to request rectification, erasure, or restriction of processing, or to object to it.
• The right to lodge a complaint with a supervisory authority.
• Where the data wasn't collected directly from the individual, any available information about its source.
• The existence of any automated decision-making, including profiling, with meaningful information about the logic involved and the significance and envisaged consequences of that processing.

A response missing several of these items is a common, avoidable gap: it's easy to focus on producing the data export itself and forget that Article 15 is asking for an explanation of the processing, not just the raw records.

Common pitfalls that turn a compliant process into a complaint

Treating an informal request as invalid. A DSAR doesn't need to use the words "GDPR," "Article 15," or "subject access request." A customer who emails "what information do you have on me" has made a valid request, whether or not they know the legal term for it.

Charging a fee by default. The right to a copy is free for a first, reasonable request. A fee or a refusal is only available for requests that are manifestly unfounded or excessive, typically because they're repetitive, and that standard is meant to be applied narrowly, not as a routine deterrent.

Missing the deadline because "complex" wasn't flagged early. The two month extension only applies if you notify the requester within the original one month window, along with the reasons for the delay. Deciding on day 25 that a request is complex, after the deadline has effectively already passed, doesn't unlock the extension retroactively.

Redacting too much, or too little. Withholding a colleague's name buried in a support ticket is usually correct under Article 15(4). Withholding an entire category of data because it's inconvenient to explain is not, and it's exactly the kind of response that reads as evasive if a regulator ever reviews it.

Not keeping a record of the request itself. A short internal log, the date received, the date verified, the date responded, and what was searched, is what turns "we believe we handled this correctly" into something you can actually demonstrate if the requester escalates to a supervisory authority.

Build the response habit into your policy, not just your process

A DSAR response process only works if the underlying privacy policy already tells people what to expect: how to make a request, roughly how long it takes, and what rights they have once the response arrives. Our Privacy Policy Generator builds that data-subject-rights language, access, rectification, erasure, restriction, objection, and the right to complain to a supervisory authority, into a policy matched to the jurisdictions you actually operate in, so the promises in your policy and the process your team actually follows say the same thing.

For a sense of what a full response cycle costs in practice, our breakdown of what a DSAR response actually costs walks through the time and tooling most companies spend per request. And if GDPR and CCPA both apply to your business, GDPR vs CCPA Cookie Consent Requirements Explained covers how the two laws' very different consent models interact with the rights each one grants.

The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.