Key takeaways

  • A DSAR is a request under GDPR Article 15 for confirmation of processing, access to the personal data, and information about the purposes, recipients, retention, rights, sources, and automated decision-making.
  • You must respond without undue delay and within one month of receipt, extendable by a further two months for complex or numerous requests if you inform the data subject within one month.
  • The clock starts when you receive the request, not when your privacy team sees it, which is why DSAR intake processes matter.
  • Verify identity proportionately without over-verifying, since demanding excessive identity proof to delay or deter requests is itself a GDPR violation.
  • Disclosing third-party personal data is the most common technical failure, so redact the personal data of anyone other than the requester.

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 outsourced 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.

Note: Outsourced DPO is also referred to as external DPO, virtual DPO, fractional DPO, or DPaaS. Local-language equivalents include externer Datenschutzbeauftragter (Germany), DPO externe (France), DPO esterno (Italy), DPD externo (Spain).

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.

This page is general information, not legal advice.

FAQ

Frequently asked questions

How long do we have to respond to a DSAR?

You must respond without undue delay and in any event within one month of receipt. The one-month period can be extended by a further two months for complex or numerous requests, but only if you inform the data subject of the extension within one month of receipt.

When does the one-month clock start?

It 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 under GDPR Article 15, which is why DSAR intake processes matter.

How much identity verification can we ask for?

Take reasonable steps proportionate to the risk and the sensitivity of the data, but you cannot demand more information than necessary. For an existing customer, matching account details such as email, account holder name, and a recent transaction reference is typically enough. Demanding excessive identity proof to delay or deter requests is itself a GDPR violation.

Can we refuse a request that looks excessive?

Article 12(5) permits a charge or a refusal for manifestly unfounded or excessive requests, but this is narrowly applied, the threshold is high, and a documented basis is required. Expect the data subject to complain to the supervisory authority if you refuse on this basis, so document your reasoning carefully.

What is the most common mistake in DSAR responses?

Disclosing third-party personal data is the most common technical failure, so you must redact the personal data of anyone other than the requester before disclosing. The other frequent failure is missing the deadline simply because nobody flagged the request in time.