How to Handle a Data Subject Access Request in 30 Days

A Data Subject Access Request (DSAR) is a request from an individual to access the personal data you hold about them. GDPR gives every EU resident this right under Article 15, and you have 30 calendar days to respond. Miss the deadline, respond incompletely, or refuse without valid grounds, and you are exposed to supervisory authority complaints and potential fines.

This guide explains your legal obligations, the response process, and how to build a DSAR handling procedure that scales.

What a DSAR Is (and Isn't)

A data subject access request gives individuals the right to:

• Confirmation of whether you process personal data about them
• A copy of that personal data
• Information about the processing: purposes, categories of data, recipients, retention periods, rights available, and origin of data if not collected directly

A DSAR is not a complaint, a request for erasure, or a subject access request for documents (a legal concept in some jurisdictions). It is specifically a request for the personal data you hold and information about how you process it.

The 30-Day Rule

You must respond within one calendar month from receipt of the request. This is 30 days from the date you receive it, not business days.

Extension: You may extend by a further two months where the request is complex or you receive a large number of requests. But you must notify the individual within the first month that an extension is being taken, and explain why.

When the clock starts: The 30 days begin when you receive the request — not when you verify the requester's identity, not when you confirm it is a valid DSAR, but when it arrives.

If you need to verify identity: You may ask for information to verify the requester's identity if you have reasonable doubts — but you cannot use this to delay the response clock unreasonably. If identity verification is needed, the clock pauses only while you await the required information.

What Information You Must Provide

Under Article 15, the response must include:

1. Confirmation that you process personal data about them (or that you do not)
2. A copy of the personal data
3. The purposes of processing
4. Categories of personal data concerned
5. Recipients or categories of recipients the data has been or will be shared with
6. Retention periods or the criteria used to determine them
7. The right to request rectification, erasure, or restriction of processing
8. The right to lodge a complaint with a supervisory authority
9. Information about the source if data was not collected directly from the individual
10. The existence of automated decision-making including profiling, and meaningful information about the logic involved

Step-by-Step Response Process

Day 1 — Receive and Log the Request

• Log the date received, the channel it came through, and the requester's identity
• Assign it to the person responsible for DSAR handling
• Begin the 30-day clock immediately

Days 1–3 — Verify Identity (If Needed)

• Determine whether you can reasonably identify the requester from the information provided
• Only request additional verification if you have genuine doubt — not as a routine step
• If verification is needed: request the minimum information necessary, pause the clock, and restart when the information is received

Days 3–15 — Gather the Data

• Search across all systems for personal data relating to the requester:
  • Product database (user records, activity logs)
  • CRM (sales and marketing data)
  • Support system (tickets, conversations)
  • Email (correspondence)
  • HR system (if the requester is an employee)
  • Analytics and usage data
  • Any third-party processors — contact them for data they hold
• Document your search methodology

Days 15–25 — Review and Redact

• Review the gathered data for:
  • Third-party personal data: if your data includes information about other individuals, redact their names and identifiers before providing the response
  • Confidential information: trade secrets or legitimately confidential business information may be withheld with explanation
  • Relevance: only include data about the requester, not every document they appear in
• Prepare the data in a structured, commonly used, machine-readable format where possible

Days 25–29 — Compile and Send Response

• Draft a covering letter explaining: confirmation of processing, purposes, categories, recipients, retention periods, rights, complaints procedure, and any relevant automated decision-making
• Attach the data in a readable format
• Send via a secure method — if providing by email, use encryption or a secure document portal
• Document that the response was sent and when

What You Can Withhold (Exemptions)

You may withhold data in limited circumstances:

You cannot withhold information simply because it is inconvenient or because the data is embarrassing. The fact that your customer complained about your service is your data about the customer — it must be disclosed.

DSAR Process as a SaaS Processor

If you are a SaaS company acting as a processor for a controller customer, the DSAR flow is different:

• The DSAR goes to the controller (your customer), not to you
• Your customer must be able to fulfil the DSAR using the data you hold for them — this is an Article 28 obligation you have as a processor
• You must be able to export, provide, or delete individual user data on your customer's request
• If a data subject contacts you directly (bypassing the controller), inform them that the controller is the appropriate contact, but do not simply turn them away — inform the relevant controller customer

Product implication: Your product must support per-user data export and deletion. Customers should be able to self-serve this, or you should be able to fulfil requests within the 30-day window on request.

Building a Scalable DSAR Process

For SaaS companies handling more than a handful of DSARs per month:

• Create a DSAR intake form — a dedicated email address or webform that routes requests to the right team
• Build a data search playbook — document which systems to search and how, so any team member can execute the search
• Automate data export where possible — a user-facing "export my data" button satisfies most requests at zero operational cost
• Use a DSAR tracker — a simple spreadsheet or ticketing system with request date, status, deadline, and response date
• Train your support team — support agents receive the most DSARs; they need to recognise them and escalate immediately