A data subject access request can arrive as a formal legal letter, a support ticket, or a single line in a reply to a marketing email: "send me everything you have on me." All three are valid. None of them have to use the words "data subject access request."
That is the first thing most teams get wrong. The second is assuming the clock starts when someone recognises it as a DSAR. It starts when it arrives.
Step 1 — Log it and start the clock
Under GDPR you have one month from receipt. You can extend by two further months for genuinely complex requests, but you must tell the requester within the first month and explain why. Under CCPA the window is 45 days, extendable to 90.
Log the date of receipt, the channel it came in on, and the exact wording. If a request sat in a shared inbox for three weeks before anyone noticed, you have three weeks left — and the regulator will not accept the inbox as an excuse.
This is why intake matters more than it sounds. Requests do not arrive through the channel you designed for them.
Step 2 — Verify who is asking
You must be reasonably satisfied the requester is who they claim to be. Handing someone else's personal data to an impostor is itself a breach — and DSAR-based social engineering is a known attack.
But verification cannot become an obstacle course. Regulators have been explicit that you should not demand more information than necessary, and you should not use verification to stall. If the person is a logged-in customer requesting data tied to that account, that is often sufficient.
Whatever you do, record what you asked for and what you accepted.
Step 3 — Search everywhere the data actually lives
This is where the real work is, and it is why DSARs are so much harder than they look.
Personal data is rarely in one place. It is in the CRM, the support desk, the billing system, the marketing platform, the data warehouse, the analytics tool, the shared drive, and in email and chat — where it is unstructured, unindexed, and full of opinions people did not expect to be disclosed.
Two things make this survivable:
- A current record of processing. If you do not know which systems hold personal data, you cannot search them. Every DSAR that turns into a crisis starts here.
- A defined search scope, written down. Which systems, which date range, which identifiers. So you can show what you searched — and so the next person does not have to reinvent it.
Step 4 — Redact third parties and apply exemptions
A DSAR gives the requester their own personal data. It does not give them anyone else's.
Email threads, meeting notes, and support tickets routinely contain data about other people — colleagues, other customers, family members. That has to be removed or the disclosure itself becomes a breach.
Exemptions also exist and are narrower than people hope: legal professional privilege, information that would prejudice a criminal investigation, and in some jurisdictions data whose disclosure would cause serious harm. "It is commercially embarrassing" is not an exemption. Nor is "the employee who wrote it would be upset."
Whatever you withhold, record what and why. You will be asked.
Step 5 — Deliver it properly
The response must be concise, transparent, and in a commonly used electronic format if the request came electronically. It must also tell the requester about their other rights — rectification, erasure, restriction, objection, and the right to complain to a supervisory authority.
A zip of raw database exports is not a response. It is a way of technically complying while making the data unusable, and regulators have taken a dim view of it.
Step 6 — Keep the evidence
Long after the response is sent, you may need to prove you handled it correctly. You should be able to show:
- when the request arrived and when you responded
- how identity was verified
- which systems were searched, and over what period
- what was disclosed, what was withheld, and on what basis
- who approved the response
Teams that do the work but cannot evidence it are, from a regulator's point of view, indistinguishable from teams that did nothing.
Where DSAR processes actually break
Three failure points, in the order they bite:
The request was not recognised. It arrived in a support queue and was answered as a normal ticket. Two weeks of the deadline are gone before anyone flags it.
Nobody knew where the data was. The search becomes an archaeology project across systems nobody has inventoried, and it expands to fill whatever time remains.
It was handled once, by one person, from memory. So the next one starts from scratch — and the third one lands during a dispute, when it is adversarial and the timeline is unforgiving.
The fix for all three is the same: a defined, repeatable process with the record of processing underneath it. That is precisely what DSAR automation exists to encode.