How to Handle a DSAR When You're Both Controller and Processor

An email lands in your agency's shared inbox: "I am writing to formally request a copy of all personal data you hold on me under Article 15 of the GDPR, as well as the immediate deletion of this data under Article 17."

If you are like most agency operators or marketing managers, your first reaction is panic. Your second is confusion. Do you handle this yourself? Do you forward it to your client? Do you delete the data, or are you legally required to keep it?

The answer depends entirely on whose data it is and in what capacity your agency holds it. When you operate as both a data controller and a data processor simultaneously, a Data Subject Access Request (DSAR) becomes a jurisdictional puzzle. Let's break down exactly how to solve it.

What a DSAR Actually Is (in 30 Seconds)

Under Articles 15 through 22 of the GDPR, individuals have specific fundamental rights over their personal data. They have the right to access it, rectify (correct) it, erase it, restrict its processing, port it to another service, and object to its use. A DSAR is simply the mechanism by which an individual exercises those rights. It doesn't have to follow a specific legal format; an email saying "what data do you have on me?" is a valid DSAR and starts the legal clock ticking.

The Dual-Role Problem

Agencies operate in a unique environment. You are controllers of your own data (your employees, your sales prospects, your newsletter subscribers). But you are also processors of your clients' data (managing a client's HubSpot instance, running their email campaigns, handling their customer lists).

When a DSAR arrives, the very first question you must ask is never "how do I respond?" Instead, it must be: "Which hat am I wearing for this specific data?" (For a deeper dive into this distinction, see our GDPR compliance guide for agencies).

Scenario A: You're the Controller

The Situation: Someone on your agency's own mailing list, a former job applicant, or an ex-employee submits a DSAR.

Your Action: This is fully your responsibility. You are the controller, and the buck stops with you. You have exactly one calendar month from the date of receipt to respond to the request.

Here is what your response actually requires:

• Verify identity: Before handing over personal data, ensure the person asking is who they claim to be. (Handing data to an impersonator is a data breach).
• Search all systems: You must locate where their data exists across your entire infrastructure. This includes your CRM, email inboxes, Slack channels, Google Drive folders, and analytics platforms. (This is why having an accurate ROPA is non-negotiable—you can't search if you don't know where to look).
• Compile and deliver: Export the data and deliver it securely in a commonly used electronic format.

A note on erasure: If their DSAR includes a request for deletion (the "right to be forgotten"), you must comply and purge their data from your systems unless you have a supervening legal obligation to retain it (e.g., keeping financial transaction records for tax authorities).

Scenario B: You're the Processor

The Situation: Someone contacts your agency directly about data you hold purely on behalf of a client. For example, a customer replies to an email campaign you manage for Client X via Mailchimp, demanding to know what data you have on them.

Your Action: Stop. Do not fulfill this request yourself. Do not delete their data. Do not export their profile. As a processor, you do not have the legal authority to make decisions about this data.

Your legal obligation is to notify your client (the controller) without undue delay so that they can handle the response. Your Data Processing Agreement (DPA) with the client should specify exactly how quickly you must notify them (often 24 to 48 hours) and what assistance you must provide in gathering the data. If your standard DPA does not explicitly cover DSAR handling procedures, that is a massive compliance gap you need to fix immediately.

Scenario C: The Messy One (Both Hats at Once)

The Situation: The same person exists in both your controller data and your processor data. Imagine a scenario where a marketing director at a target company is on your agency's prospecting newsletter (Controller data), but they are also a registered user in a SaaS platform you are currently marketing for one of your clients (Processor data).

Your Action: You now have two parallel, distinct legal obligations.

1. Wear the Controller Hat: You must independently fulfill the DSAR for the data your agency controls (the prospecting newsletter data). Search your CRM, compile the data, and deliver it (or delete it, if requested) within one month.
2. Wear the Processor Hat: You must immediately notify your client that a DSAR was received concerning a user in their database. You then assist the client in fulfilling their DSAR process according to your DPA.

The Operational Playbook

You cannot wait until a DSAR arrives to figure out this workflow. The one-month deadline is unforgiving. Every agency should have the following operational playbook documented and ready:

• A dedicated intake channel: Establish a `privacy@youragency.com` alias so requests don't get lost in support queues or personal inboxes.
• An identity verification template: A standard reply asking for reasonable proof of identity before proceeding.
• A documented search procedure: A checklist of exactly which SaaS tools, shared drives, and communication platforms must be queried.
• Response templates: Pre-written emails for acknowledging the request, delivering the data, confirming deletion, or explaining why deletion isn't legally possible.
• An escalation path for processor DSARs: Clear instructions for your team on how to instantly route a request to the correct client contact.
• A DSAR tracking log: A secure ledger tracking the request from receipt to completion to prove your accountability to regulators.

Common Mistakes to Avoid

• Responding to a processor DSAR without notifying the client: You just made an unauthorized decision about data you don't own.
• Missing the one-month deadline: Usually happens because the email sat in a shared generic inbox for three weeks before someone realized what it was.
• Failing to search all systems: You checked your CRM and exported the profile, but you forgot to search Slack, Google Drive, or your billing software. The DSAR covers all personal data.
• Not verifying identity: Blindly handing over a complete dossier of personal information to an email address without verifying they are the actual data subject is a severe data breach.

The Bottom Line

When a DSAR hits your inbox, take a breath and figure out your role. If it's your data, execute your search-and-compile process. If it's your client's data, sound the alarm and pass it up the chain. Understanding the difference is what separates compliant agencies from those facing massive liability.