Data Subject Access Request (DSAR) Response Guide

A Data Subject Access Request, or DSAR, is a request from an individual asking what personal data you hold about them under GDPR Article 15. The request is straightforward in principle and often complex in execution. This page covers the practical response process, common pitfalls, and what to do when the request is unusual.

What rights are you actually responding to

GDPR Article 15 gives data subjects the right to obtain confirmation as to whether personal data concerning them is being processed, and where that is the case, access to the personal data and information about the processing.

The information you must provide includes the purposes of processing, the categories of personal data, the recipients or categories of recipients to whom the personal data has been or will be disclosed (including recipients in third countries), the envisaged period for which the personal data will be stored, the existence of the right to rectification, erasure, restriction, or objection, the right to lodge a complaint with a supervisory authority, the source of the data where not collected from the data subject, and the existence of automated decision-making including profiling.

You must also provide a copy of the personal data being processed.

The timeline

You must respond to a DSAR without undue delay and in any event within one month of receipt of the request. The one-month period can be extended by a further two months where necessary, taking into account the complexity and number of the requests. You must inform the data subject of any such extension within one month of receipt.

The clock starts when you receive the request, not when your privacy team sees it. A request sitting in a general info inbox for two weeks has already consumed half your response window. This is why DSAR intake processes matter.

Step 1: Verify the request

Confirm the requester's identity. You must take reasonable steps to verify identity, but you cannot demand more information than necessary. For an existing customer, matching account details (email, account holder name, recent transaction reference) is typically sufficient. For an unknown requester claiming a relationship with your company, you may request additional verification.

Do not over-verify. Demanding excessive identity proof to delay or deter requests is itself a GDPR violation. The verification should be proportionate to the risk and the sensitivity of the data.

Document the verification process and decision.

Step 2: Scope the request

Determine what the requester is actually asking for. Many DSARs are broad ("all my data") but the requester may be looking for something specific. You may ask the data subject to clarify the request, but you cannot use clarification as a delay tactic.

Identify which of your systems contain personal data about the requester. Tech companies often have data in production databases, customer relationship management systems, support ticket systems, email correspondence, marketing automation tools, analytics platforms, employee directories (for B2B contacts), payment systems, and backup systems.

Decide whether the request covers all of these or a subset.

Step 3: Collect the data

Pull personal data from each relevant system. This is often the most time-consuming step, particularly for companies that have not built DSAR automation.

For each piece of data, determine what category it falls into, whether it should be included in the response (some data may be exempt), and what format to provide it in.

Common exclusions and exemptions:

Data of other individuals. If responding would disclose personal data of someone other than the requester (for example, an internal note that mentions both the requester and another customer), the other person's data must be redacted.

Confidential business information. Internal company information that is not personal data does not need to be disclosed, but be careful about over-redaction.

Legal privilege. Material covered by legal professional privilege may be withheld.

Trade secrets. Trade secrets can be withheld but cannot be used as a blanket exemption.

Manifestly unfounded or excessive requests. Article 12(5) permits a charge or refusal for manifestly unfounded or excessive requests, but this is narrowly applied. The threshold is high and documented basis is required.

Step 4: Format and deliver

Provide the response in commonly used electronic format, typically PDF or structured data depending on the type of information.

Structure the response clearly. A typical DSAR response includes a cover letter explaining the response, a summary of what is included, a list of categories of personal data, the actual personal data organized by source system or category, the supporting information required under Article 15 (purposes, recipients, retention, rights, sources, automated decision-making), and instructions for further questions or rights.

Deliver securely. Personal data sent in response to a DSAR is itself personal data and must be protected. Use encrypted email, password-protected PDF, or secure transfer.

Common difficult scenarios

The request comes from a current or former employee. Employee DSARs are increasingly common, particularly during disputes or terminations. Treat them with the same rigor as any other DSAR but be alert to employment records that contain confidential management evaluations, references from third parties, and internal correspondence about the employee.

The request comes from a third party purporting to act on behalf of a data subject. You can require evidence of authority (typically a signed authorization). Common patterns: law firms acting for clients in litigation, and subject access request services that act for many individuals on a commercial basis.

The request is vague or covers an extreme volume of data. You may ask the data subject to clarify or narrow the scope. Document the clarification request and the timeline impact.

The request appears manifestly unfounded or designed to disrupt your business. This is a recognized category under Article 12(5) and the regulator has guidance on what qualifies. The bar is high. Document the basis for any refusal carefully and expect the data subject to complain to the supervisory authority if you refuse on this basis.

The requester wants the response in a specific unusual format. Reasonable format requests should be accommodated. Unusual or burdensome format requests can be declined with explanation.

The data is held by a sub-processor or vendor. You remain responsible for the response. Coordinate with the sub-processor under your data processing agreement.

What can go wrong

Failure to respond within the deadline. This is itself a GDPR violation and a common basis for supervisory authority complaints.

Inadequate response. Providing partial information, missing categories of data, or failing to include the required Article 15 information can trigger a follow-up complaint to the supervisory authority.

Disclosing third-party personal data in the response. This is itself a breach, and is the most common technical failure in DSAR responses.

Excessive verification. Demanding burdensome proof of identity is itself a GDPR violation.

Mishandling a manifestly unfounded request claim. Refusing a request on this basis without clear documentation can result in a supervisory authority finding against you.

How Engage Compliance helps

DSAR response is a core part of fractional DPO services. We handle DSARs end-to-end for clients including verification, scoping, collection coordination, redaction, response drafting, and supervisory authority correspondence where needed.

For non-clients with a particularly complex or contested DSAR (former employee dispute, law firm acting for a litigation party, regulator inquiry), we engage on focused project basis.

Get started

If you have a complex DSAR or a backlog of unresponded requests, book a consultation. We can typically scope the work and start within a few days.