It lands in your inbox like any other customer email. Maybe the subject line says "Data Request" or maybe it just says "Question about my account." But buried somewhere in that message are words that change everything: "I want a copy of all personal data you have on me."

Congratulations. You've just received a Data Subject Access Request under GDPR—and the clock is now ticking.

For small SaaS and ecommerce businesses, these requests can feel like legal landmines dropped directly into the support queue. Most founders and support leads have heard of GDPR. Fewer know exactly what to do when someone actually exercises their rights. And the penalty for getting it wrong? Fines up to €20 million or 4% of global annual turnover—whichever is higher [1].

The good news: handling DSARs doesn't require a law degree. It requires a clear workflow, the right tools, and a team that knows what to look for. Here's how to recognize these requests when they hit your helpdesk, verify the requester's identity without creating friction, and respond within the legal timeline.

What Is a DSAR and Why Does It Matter for Your Support Team?

A Data Subject Access Request (DSAR) is a formal exercise of the "right of access" under Article 15 of the GDPR [2]. When someone submits one, they're asking your organization to confirm whether you process their personal data and, if so, provide a copy of that data along with specific supplementary information.

This isn't optional. Any individual whose personal data you process—customers, users, even website visitors—has this right.

Here's where support teams come in: DSARs don't arrive through dedicated legal portals at most small businesses. They arrive in the support inbox. Sometimes they're clearly labeled. Often they're not. Your support team is the first line of defense—and potentially the first point of failure.

What Counts as Personal Data in Support Systems

Personal data under GDPR means any information relating to an identified or identifiable person . In a typical helpdesk, that includes:

That last one catches people off guard. Those internal notes where you wrote "customer seems frustrated, offered discount"? That's personal data. It needs to be included in the response.

How to Spot a DSAR in Your Support Queue

DSARs don't follow a template. The GDPR doesn't require requesters to use specific language, cite the regulation, or even mention "GDPR" at all [3]. Any clear indication that someone wants access to their personal data counts as a valid request.

Red-Flag Phrases That Signal a DSAR

Train your team to watch for language like:

Some will be formal. Others will be casual. Both count.

When Requests Get Buried in Other Issues

Sometimes a DSAR hides inside a different ticket. A customer emails about a refund and adds, almost as an afterthought, "Also, can you send me everything you have on file for me?"

That's a DSAR. The fact that it's bundled with another issue doesn't change your obligations. Your team needs to flag it, separate it from the refund conversation, and route it appropriately.

Creating a Tagging System in Your Helpdesk

Most modern helpdesks let you create custom tags or ticket types. Set up a dedicated tag—something like "DSAR" or "Privacy Request"—and train your team to apply it the moment they recognize a request. This creates an audit trail and ensures nothing slips through the cracks.

Better yet, build a trigger that auto-escalates any ticket tagged as a DSAR to a designated handler (whether that's you, a team lead, or an outsourced partner following your defined SOP). For more on setting up clear pathways, see our guide on escalation policy examples.

Identity Verification: Confirming the Requester Without Creating Barriers

Here's where things get tricky. You need to verify that the person making the request is actually the data subject—or their authorized representative. But GDPR also prohibits using identity verification as a tactic to discourage requests [4].

Balance is everything.

Proportionate Verification Methods

The level of verification should match the sensitivity of the data and the confidence you already have in the requester's identity.

Low-risk scenario: A customer emails from the same address they used to create their account, asking for a copy of their order history. You already have reasonable confidence in their identity. A simple confirmation ("We'll send the information to this email address—please confirm that's correct") is likely sufficient.

Higher-risk scenario: Someone emails from an unknown address claiming to be a customer and requesting data. Here, additional verification makes sense. You might ask them to:

What to Do When Someone Requests Another Person's Data

Authorized representatives—lawyers, parents acting for children, employees acting for their employer—can submit DSARs on behalf of data subjects. But you need evidence of that authorization.

Request a signed letter from the data subject granting permission, or legal documentation establishing the relationship (power of attorney, guardianship documents). Don't release data to third parties without this documentation.

Documenting Your Verification Process

Whatever method you use, document it. Note in the ticket what verification steps you took and why they were appropriate. This creates an audit trail if regulators ever ask how you handled a specific request.

The DSAR Fulfillment Workflow: Step by Step

Once you've confirmed a request is valid and the requester's identity is verified, the real work begins. Here's a practical workflow for small teams.

Step 1: Acknowledge Receipt Immediately

Send a confirmation that you've received the request. This isn't legally required, but it's good practice—and it buys you goodwill if the timeline gets tight.

Your acknowledgment should include:

Step 2: Start the Response Timeline Tracker

Under GDPR, you have one calendar month from receipt to respond. Not 30 days—one month. If a request arrives on January 15, you have until February 15 to respond.

You can extend this by an additional two months for complex or voluminous requests, but only if you notify the requester within that first month, explain why the extension is necessary, and give them the new deadline.

Build a tracking system. A simple spreadsheet works for low-volume situations:

For higher volumes, look at dedicated privacy management tools or build automation in your helpdesk.

Step 3: Locate All Personal Data

This is the part that takes time. You need to search every system where the requester's data might exist.

In your helpdesk, look for:

In connected systems:

Export everything. Most helpdesks offer ticket export functions—use them. If your helpdesk doesn't support bulk exports for a single customer, you may need to manually compile data from individual tickets.

Step 4: Review and Redact

Before sending anything, review the data for:

Third-party personal data: If an exported ticket includes another person's information (another customer CC'd on an email, for example), you need to redact that information unless disclosure is appropriate [2].

Confidential business information: GDPR doesn't require you to reveal trade secrets or proprietary information. You can redact legitimately confidential material, though this exception is narrow.

Exemptions: Certain categories of data may be exempt from disclosure, including data protected by legal privilege or data that would adversely affect the rights of others.

When in doubt, consult with a privacy professional before redacting.

Step 5: Compile the Response Package

Your response needs to include more than just raw data. Article 15 requires you to provide:

Step 6: Deliver Securely

If the request came electronically, you should provide the response electronically in a commonly used format. PDF works for most purposes.

Consider security. Emailing unencrypted files containing personal data creates risk. Options include:

Document how and when you delivered the response.

Building a DSAR Response Template

Having a template ready saves time and ensures consistency. Here's a framework:

Subject: Response to Your Data Access Request

Dear [Name],

Thank you for your request dated [date] for access to your personal data. We have completed our review and are pleased to provide the following information.

Confirmation of ProcessingWe confirm that [Company Name] processes personal data relating to you.

Copy of Your DataPlease find attached a copy of the personal data we hold about you. This includes [brief description of categories included].

Purposes of ProcessingWe process your personal data for the following purposes: [list purposes—e.g., providing customer support, processing orders, sending marketing communications if opted in].

Recipients of Your DataYour data has been shared with the following categories of recipients: [list—e.g., payment processors, shipping providers, helpdesk software provider].

Retention PeriodWe retain your data for [period or criteria—e.g., the duration of your account plus 7 years for tax compliance].

Your RightsYou have additional rights under GDPR, including the right to request rectification or erasure of your data, to restrict or object to processing, and to lodge a complaint with a supervisory authority.

Source of DataThe data we hold was collected directly from you through [sources—e.g., account registration, support interactions, purchase transactions].

If you have any questions about this response, please don't hesitate to contact us.

Sincerely,[Your Name][Company Name]

Attach the data export as a separate file.

Handling Special Situations

The Requester Wants Data Deleted, Not Just Accessed

Sometimes access requests arrive bundled with deletion requests. These are separate rights under GDPR—right of access (Article 15) and right to erasure (Article 17).

Handle them separately. Respond to the access request with the data, then process the erasure request according to your procedures. Note that erasure isn't absolute—you may have legal grounds to retain certain data even if the customer asks for deletion.

You Can't Find Any Data

It happens. Someone requests their data, and your search turns up nothing. Maybe they never actually created an account, or maybe they're using an email address you don't have on file.

Respond honestly. Confirm that you've searched your systems and found no personal data associated with their identifiers. This is still a valid response—you've fulfilled your obligation.

The Request Is Manifestly Unfounded or Excessive

GDPR allows you to refuse requests that are "manifestly unfounded or excessive"—for example, repetitive requests clearly intended to disrupt your operations [10].

Tread carefully here. The bar is high. If you refuse, you must explain why and inform the requester of their right to complain to a supervisory authority and seek judicial remedy. Document your reasoning thoroughly.

Complex Situations Requiring Legal Input

Some DSARs need professional guidance:

When in doubt, consult a privacy lawyer before responding.

What Happens If You Miss the Deadline?

The honest answer: it depends.

If you're a day late on an otherwise good-faith response, the world probably won't end. But repeated failures, bad-faith delays, or complete failures to respond create real regulatory risk.

Data protection authorities have issued significant fines for DSAR failures. And beyond fines, poor handling damages customer trust—exactly the opposite of what good support should accomplish.

Build systems that make compliance automatic. Track deadlines. Escalate early when requests look complex. It's far easier to extend a deadline proactively than to explain why you missed one entirely.

When You Work with an Outsourced Support Partner

If you use an outsourced support team (like Evergreen Support), you need clear protocols for DSAR handling.

Your partner should be trained to:

The data controller—that's you, the business owner—remains responsible for compliance. Your partner processes data on your behalf, but the legal obligation to respond correctly and on time stays with you [11].

A good outsourcing relationship includes documented procedures for privacy requests, clear escalation paths, and regular training updates as regulations evolve.

The Bottom Line

DSARs aren't legal traps waiting to destroy your business. They're simply customers exercising legitimate rights over their own information.

With the right workflow—recognition training, proportionate verification, systematic searching, careful redaction, and deadline tracking—you can handle these requests efficiently while staying on the right side of GDPR.

The key is preparation. Build the system before you need it. Train your team. Create templates. Set up tracking. When that first request lands in your inbox (and it will), you'll be ready.

Not sure your support operations are set up to handle privacy requests correctly? Book a call with Evergreen Support to discuss how we work within client-defined DSAR SOPs—recognizing requests fast, escalating to you as the controller, and ensuring nothing falls through the cracks.

Frequently Asked Questions

Do DSARs have to mention GDPR specifically to be valid?

No. The GDPR doesn't require any specific language or formal format. Any clear indication that someone wants access to their personal data counts as a valid DSAR. Your team should watch for any phrasing that expresses a desire to see what data you hold—even if it sounds casual or is buried in another support request.

Can we charge a fee for responding to DSARs?

In most cases, no. GDPR requires that you provide the first copy of personal data free of charge. You may charge a reasonable fee for additional copies or for requests that are manifestly unfounded or excessive, but this exception is narrow and should be used cautiously.

What if a DSAR would reveal information about another customer?

You must redact third-party personal data before responding unless you have grounds to include it. Your obligation is to the data subject making the request—not to disclose other people's information in the process of fulfilling that obligation.

How do we handle verbal DSARs, like someone asking over a support call?

Verbal requests are valid under GDPR. If a customer asks for their data during a phone call, document the request immediately in writing, confirm it back to them via email, and process it through your standard workflow with proper identity verification.

What's the difference between a DSAR and a right to erasure request?

A DSAR (right of access, Article 15) asks for a copy of personal data you hold. A right to erasure request (Article 17) asks you to delete personal data. They're separate rights with different requirements. Handle them independently, even if they arrive in the same email.

About Evergreen Support

Evergreen Support provides US-based, human-powered email support for small SaaS and ecommerce businesses. Our team is trained to recognize DSARs and other privacy requests, tag them appropriately, and escalate to you immediately—following whatever procedures you've defined. We believe compliance shouldn't require you to be tethered to your inbox. Learn more about how we work.

Works Cited

[1] GDPR.eu — "What are the GDPR Fines?" https://gdpr.eu/fines/

[2] Intersoft Consulting — "GDPR Article 15: Right of access by the data subject." https://gdpr-info.eu/art-15-gdpr/

[3] Information Commissioner's Office — "Right of access." https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/

[4] European Data Protection Board — "Guidelines on the Rights of Data Subjects: Right of Access." https://edpb.europa.eu/

[5] Intersoft Consulting — "GDPR Article 17: Right to erasure ('right to be forgotten')." https://gdpr-info.eu/art-17-gdpr/