GDPR Data Subject Access Requests (DSAR): Complete Guide

A data subject access request is one of the most tangible ways GDPR affects your day-to-day operations. When someone sends an email saying “I want a copy of all the data you hold about me,” the clock starts ticking — and you have exactly one calendar month to deliver a complete, accurate response.

For SaaS companies, DSARs are particularly complex because personal data is rarely stored in a single place. It’s spread across your application database, your CRM, your support ticketing system, your email marketing platform, your analytics tools, and possibly your employees’ email inboxes. Collecting it all within the legal deadline requires a well-defined process.

This guide walks through everything SaaS teams need to know about handling DSARs — from the legal basis to the step-by-step process to the mistakes that lead to enforcement actions.

What Is a DSAR?

A Data Subject Access Request is a formal exercise of the right of access under Article 15 of the GDPR. Any natural person whose personal data you process — whether they’re a customer, an end-user, a website visitor, an employee, or a job applicant — can request:

• Confirmation of whether you process their personal data
• A copy of that personal data
• Supplementary information about your processing: the purposes, the categories of data, the recipients, the retention periods, the source of the data, and whether any automated decision-making applies

A DSAR doesn’t have to use specific legal language. An email saying “Can you tell me what data you have on me?” qualifies. So does a message through your support chat, a verbal request at a meeting, or even a social media message. There is no required format.

This is why training your team matters. If a support agent receives what is effectively a DSAR but doesn’t recognize it as one, your response deadline starts counting down without anyone noticing.

When Does a DSAR Apply to Your SaaS?

B2B SaaS Scenarios

If you’re a B2B SaaS company, you might assume DSARs are mainly a B2C concern. They’re not. Consider the personal data your platform handles:

• End-user data: If your customers’ employees use your platform, their account details, activity logs, and any content they create may constitute personal data.
• Customer contact data: Names, email addresses, phone numbers, and job titles of the people you work with at customer organizations.
• Support interactions: Ticket histories, chat transcripts, and call recordings often contain personal data.
• Analytics data: If you track user behavior with identifiers (even pseudonymized ones that you can re-identify), this is personal data.
• Employee and applicant data: Your own HR records and recruitment data.

Controller vs. Processor

Your response obligations depend on your role:

• As a controller (you decide why and how data is processed): You handle the DSAR directly and provide the data.
• As a processor (you process data on behalf of your customer): You typically redirect the request to your customer (the controller) and assist them in fulfilling it. Your Data Processing Agreement should specify how this works.

In practice, most SaaS companies are controllers for some data (their own customer relationships, employee data, website visitor data) and processors for other data (the data their customers store in the platform). This dual role means you need processes for both scenarios.

The DSAR Response Process: Step by Step

Step 1: Log the Request and Start the Clock

The moment you receive a DSAR, log it with a timestamp. Your 30-day response period starts from the day of receipt — not from when you assign it to someone or when you verify the requester’s identity.

Record:

• Date and time of receipt
• Channel through which it was received
• The requester’s identity (as stated)
• The specific scope of their request (if they specified one)
• The assigned handler

Step 2: Verify the Requester’s Identity

You have a duty to confirm that the person making the request is who they claim to be. Responding to a fraudulent DSAR by disclosing someone else’s data would itself be a data breach.

Verification should be proportionate. If someone makes a request through their authenticated account in your platform, that’s generally sufficient. If the request comes via email, you might ask for additional verification — but don’t make the process so burdensome that it effectively discourages people from exercising their rights.

Reasonable verification methods:

• Matching the request against an existing account
• Asking the requester to confirm details only they would know
• Requesting a copy of government-issued ID (in high-risk cases only)

The clock continues ticking during verification. If you need additional information to verify identity, you should ask promptly.

Step 3: Determine the Scope

Some DSARs are broad (“all data you hold about me”), and some are specific (“the data you collected through your analytics platform”). In either case, you need to identify every system where the requester’s personal data might exist.

For a typical SaaS company, this includes:

• Your application database (user profiles, activity data, user-generated content)
• Your CRM (contact records, deal history, notes)
• Your support system (tickets, chat transcripts)
• Your email marketing platform (subscriber data, engagement history)
• Your analytics tools (behavioral data, event logs)
• Your HR system (if the requester is an employee)
• Email accounts (any correspondence mentioning the requester)
• Physical records (if any)

Step 4: Collect the Data

Gather personal data from all identified systems. This is typically the most time-consuming step, especially if your data is siloed across multiple platforms without a unified search capability.

For each system, extract:

• The personal data itself
• The categories of data (e.g., identity data, contact data, behavioral data)
• The purposes of processing
• Any recipients the data has been shared with
• The retention period or criteria for determining it
• The source of the data if not collected directly from the individual

Step 5: Review for Exemptions and Third-Party Data

Before handing over the collected data, review it for:

• Third-party personal data: If your records contain personal data about other individuals (e.g., a support ticket that mentions another person by name), you may need to redact that information to protect the third party’s rights.
• Trade secrets or intellectual property: You can withhold data if disclosure would adversely affect the rights and freedoms of others, including trade secrets — but this exemption is interpreted narrowly.
• Legal privilege: Communications covered by legal professional privilege can be withheld.
• Repetitive requests: If the same person makes identical requests repeatedly, you may be able to refuse or charge a reasonable fee — but only if the requests are “manifestly unfounded or excessive.”

Step 6: Prepare and Deliver the Response

Compile the data into a structured, commonly used, machine-readable format. PDF is widely used, but CSV or JSON may be more appropriate for technical data. The response should include:

• Confirmation that you process their personal data (or that you don’t)
• A copy of the personal data
• The supplementary information required by Article 15(1): purposes, categories, recipients, retention periods, rights information, source of data, and automated decision-making details

Deliver the response through a secure channel. Email with an encrypted attachment is common. A secure download portal is better.

Step 7: Document Everything

Record the entire process: what was requested, what steps you took, what data you collected, what (if anything) you redacted and why, how you delivered the response, and the date of delivery.

This documentation serves dual purposes. First, it demonstrates compliance with the accountability principle if you’re ever audited. Second, it helps you identify process improvements — if a DSAR took 25 days because data collection from one system was slow, you know where to focus.

Timelines and Exemptions

The 30-Day Rule

You must respond to a DSAR within one calendar month of receipt. This is a hard deadline, not a target.

If the request is complex or if you’ve received a high volume of requests from the same individual, you can extend the deadline by two additional months — but you must notify the requester within the first month, explain the reason for the delay, and inform them of their right to complain to a supervisory authority.

When You Can Refuse

GDPR allows you to refuse or charge a fee for DSARs that are “manifestly unfounded or excessive.” The bar is high:

• Manifestly unfounded: The requester has no intention of exercising their access right — for example, they explicitly state they’re making the request to cause disruption.
• Excessive: The requester makes the same request repeatedly with no reasonable interval between requests. Note: a second request after you’ve acquired new data about them is not excessive.

The burden of proof for demonstrating that a request is unfounded or excessive falls on you. When in doubt, fulfill the request.

No Fee for the First Copy

The first copy of their data must be provided free of charge. You can charge a “reasonable fee based on administrative costs” for additional copies or for requests that are manifestly excessive.

DSAR Mistakes That Lead to Enforcement Actions

Missing the deadline. The most common and most avoidable mistake. If your internal process isn’t defined before the first DSAR arrives, you’ll waste days figuring out who handles it, where to find the data, and how to respond. By then, you’ve already burned half your timeline.

Incomplete data collection. Supervisory authorities have issued fines where organizations provided some of the requester’s data but missed data stored in secondary systems — legacy databases, email archives, or third-party platforms. A DSAR response that omits data is not compliant.

No identity verification. Handing over personal data to someone who hasn’t been properly verified is a data breach. But overly aggressive verification — demanding notarized documents for a simple request — can be seen as obstructing the right of access.

Providing data without the supplementary information. Article 15 requires more than just a data dump. You must also explain the purposes of processing, the categories of data, the recipients, the retention periods, and the requester’s rights. Many organizations provide the raw data but forget the context.

No audit trail. If you can’t demonstrate how you handled a DSAR — when you received it, what steps you took, when you responded — you’ve failed the accountability test regardless of whether your response was substantively correct. Our guide on GDPR fines and penalties covers what’s at stake.

How GRCTrail Automates DSARs

Handling DSARs manually works when you get one or two a year. It breaks down quickly at scale — or even at moderate volume if your data is spread across multiple systems.

GRCTrail provides a structured DSAR workflow:

Intake and tracking. Receive requests through a dedicated portal or log them manually. Each request is timestamped with automatic deadline calculation and progress tracking.

Automated data collection. Connect your data sources and GRCTrail pulls relevant personal data across systems, reducing the hours spent on manual collection.

Review and redaction. Review collected data in a single interface. Flag items for redaction with documented justification.

Response delivery. Generate structured responses and deliver them through secure channels. Every step is logged for accountability.

Deadline alerts. Get notified as deadlines approach. Never miss a 30-day window because a request sat in someone’s inbox.

Handle DSARs in minutes, not days →

Related Guides

• GDPR Compliance Checklist — The full compliance framework
• Records of Processing Activities (ROPA) — Document your processing for DSAR responses
• Privacy Notice Requirements — What you must tell data subjects
• GDPR Fines and Penalties — The cost of getting DSARs wrong

Get started with GRCTrail →