DSAR Explained: Handling Data Subject Requests
A data subject access request is a person asking what data you hold on them — and a clock starting the moment it arrives. Here's the DSAR privacy playbook: the rights behind it, the GDPR and CCPA deadlines, and the six-step process for handling one without a misstep.
What's on this page
A DSAR — a data subject access request — is one of the most concrete moments in DSAR privacy work: a real person exercises their legal right to ask what personal data you hold about them, and you have a fixed, short window to answer. Get it right and it's routine. Get it wrong — miss the deadline, hand data to an imposter, or fail to find everything — and a single request can turn into a complaint, an investigation, or a fine. This guide covers what a DSAR is, the rights behind it, exactly how long you have under GDPR and CCPA, and a six-step process for handling one cleanly. It also flags the thing most DSAR guides never mention: the privacy exposure that handling requests perfectly still leaves wide open.
What is a DSAR?
A data subject access request (DSAR) is a request from an individual to access the personal data an organization holds about them. Under the GDPR it flows from the right of access in Article 15 — the person can ask what data you process, why, who you share it with, how long you keep it, and receive a copy. A DSAR can arrive through any channel: an email, a web form, a social-media message, even a verbal request to a staff member. There's no required wording and no official form — if a reasonable person would read it as someone asking for their data, the clock has started.
That informality is the first trap. Because a DSAR doesn't have to say "DSAR," staff who aren't trained to recognize one can let the deadline run silently. The first rule of DSAR privacy is simply: recognize the request, and log the date it arrived.
DSAR vs DSR: the rights map
You'll see two acronyms — DSAR and DSR (or "DSR privacy") — and they're not quite the same. Historically, "DSAR" meant an access request specifically (GDPR Article 15). "DSR" — data subject request — is the broader umbrella covering all the data-subject rights. In everyday use the terms blur together, but it helps to see the whole family, because a request that starts as "send me my data" can just as easily be "delete my data" or "stop processing it."
The practical implication: build a process that recognizes any data-subject request, not just access. The intake, verification, deadline and record-keeping steps are nearly identical whether someone wants a copy of their data or wants it deleted — only the middle "action" step changes.
The deadlines: GDPR vs CCPA
The deadline is the part you cannot get wrong, and it differs by law. Under the GDPR, you must respond "without undue delay and in any event within one month of receipt." That month can be extended by two further months where the request is complex or numerous — but you must tell the person about the extension, with reasons, within the first month. So the real GDPR clock is one month, stretchable to three only if you communicate.
Under California's CCPA/CPRA, the window is 45 days from receipt of a verifiable request, extendable by another 45 (90 total) with notice. Most other US state privacy laws — Virginia, Colorado, Connecticut, Texas and the rest — land on a similar 45-day baseline, several with their own extension and appeal rules.
The 6-step DSAR response process
Every DSAR — access, deletion or otherwise — moves through the same six stages. Building your process around these steps is what turns a stressful scramble into a repeatable workflow.
1 · Receive & log
Record the date received (the deadline anchor), the requester, and what they're asking for. Route it to whoever owns DSARs so it doesn't sit unseen.
2 · Verify identity
Confirm the requester is who they claim, proportionate to the sensitivity of the data — more on this below. Never send data to an unverified requester.
3 · Locate the data
Find every place the person's data lives — CRM, email, analytics, support tools, backups, spreadsheets. This is the hardest step, and it's only as easy as your data map makes it. If you don't know where data is, you can't produce it.
4 · Review & redact
Apply any exemptions, and redact third-party personal data (another person's information caught up in the response). Don't over-disclose.
5 · Respond
Deliver within the deadline, in a commonly used electronic format, free of charge. For access requests, include the required context: purposes, recipients, retention, and the person's rights.
6 · Record
Log the request and your response as proof. If a regulator later asks whether you handled it correctly, this record is your evidence.
Do you even know what you're collecting?
You can't fulfill a DSAR for data you didn't know you were gathering. Scan your site free and see which trackers fire — and what visitor data they collect — before consent, in about 10 seconds.
Run a free scan →Verifying identity (without causing a breach)
Identity verification is where DSARs get genuinely risky in both directions. Disclose someone's personal data to an imposter, and you've caused a data breach — by trying to comply with a privacy right. But demand excessive proof of identity, and you're obstructing a legitimate request, which is its own violation.
The rule is proportionality: verify to a level that matches the sensitivity of the data being requested. For a simple account, confirming control of the registered email may be enough. For sensitive records, stronger verification is warranted. What you should not do is routinely demand a passport scan for every request — collecting more identity data than necessary is itself a privacy problem. If you can't verify a requester after reasonable effort, you can decline, but document why.
Exemptions, redactions & fees
A DSAR is broad but not unlimited. A few boundaries worth knowing:
The five costly DSAR mistakes
Most DSAR failures aren't exotic — they're the same handful, repeated. Check your process against these:
Who has to handle DSARs — and how to get ready
A common misconception is that DSARs are only a big-company or EU-only problem. In reality, almost any organization that processes personal data can receive one. Under the GDPR, the right of access applies to any controller handling EU or UK residents' data, regardless of company size. In the US, the CCPA and the growing list of state laws (Virginia, Colorado, Connecticut, Texas and more) grant similar access and deletion rights once a business meets their thresholds. If you have customers, run analytics, or send marketing, you're in scope somewhere — and the right can be exercised by anyone whose data you hold, including a former employee or a prospect who never bought anything.
The good news is that DSAR readiness is mostly preparation, not heroics. Three things make the difference between a calm response and a scramble:
None of this requires a large team. It requires deciding in advance who does what, so the first DSAR you receive isn't also the moment you design your process.
Don't forget your vendors
One step teams routinely miss: your data doesn't only live in your systems. When you use third-party processors — a CRM, an email platform, a support tool, an analytics provider — they hold the person's data on your behalf, and a complete DSAR response has to account for it. Your data-processing agreements should already require those vendors to help you fulfill requests, so build them into your workflow: know which vendor holds what, and how to retrieve or delete it there. A response that covers your own database but ignores the five SaaS tools around it is incomplete — and "our vendor had it" is not a defense to the person who asked.
The exposure a DSAR doesn't touch
Here's the point most DSAR guides never make. Handling data subject requests is a reactive, rights-based obligation — someone asks, you respond. You can build a flawless DSAR process and still be exposed to an entirely separate, preventive problem: trackers firing on your website before a visitor consents.
These are two different halves of privacy compliance. A DSAR answers "what do you have on me, and honor my rights over it." The preventive half answers "did you have permission to collect it in the first place." In the United States, that second question is where the litigation is — trackers running before consent are the basis of the wave of California Invasion of Privacy Act (CIPA) suits, where statutory damages run to $5,000 per violation under Cal. Penal Code §637.2. No amount of DSAR diligence addresses it, because the harm happened at collection, long before anyone filed a request.
A perfect DSAR process answers requests about data you already collected. It says nothing about whether you were allowed to collect it. Those are two different compliance problems — and US litigation lives in the second.
There's also a quieter connection between the two. A DSAR is only as complete as your knowledge of what you collect — and undisclosed trackers quietly gather visitor data that should surface in an access request but often doesn't, because nobody knew it was there. So the same blind spot that creates CIPA exposure also undermines your DSAR accuracy. This is the prevention-first case: ConsentPixel handles DSARs — intake, routing, deadline tracking, response and proof — and, through the same platform, blocks trackers before consent so the preventive half is covered too. You can see what's actually firing on your site with the privacy scanner.
Key takeaways
- A DSAR is a person's request to access the data you hold on them (GDPR Article 15). "DSR" is the wider family — access, erasure, rectification, portability, objection and more.
- A DSAR can arrive any way, with no set wording — so recognizing and logging it is the first, most-missed step.
- Deadlines: GDPR is one month (extendable to three if you notify); CCPA is 45 days (extendable to 90). The clock starts on receipt, not recognition.
- Handle every request through the same six steps: receive, verify, locate, review, respond, record. "Locate" is where most stall.
- Verify proportionately — enough to stop an imposter, not so much that you obstruct a genuine request or over-collect ID.
- Requests are free unless manifestly unfounded or excessive; redact third-party data; keep a record as proof.
- The gap: a flawless DSAR process is reactive and doesn't touch the preventive exposure of trackers firing before consent — a separate, US-litigation risk ($5,000/violation, §637.2).
Frequently asked questions
What is a DSAR in privacy terms?
A DSAR — data subject access request — is an individual's request to access the personal data an organization holds about them, based on the GDPR's right of access (Article 15). It can arrive through any channel and requires no special wording; if someone is asking for their data, it's a DSAR.
What's the difference between a DSAR and a DSR?
"DSAR" historically means an access request specifically (Article 15). "DSR" (data subject request) is the broader umbrella covering all data-subject rights — access, rectification, erasure, restriction, portability, objection and rights around automated decisions. In everyday use the terms overlap, but your process should handle any of them.
How long do I have to respond to a DSAR?
Under the GDPR, one month from receipt, extendable by two further months for complex or numerous requests — but you must tell the person about the extension, with reasons, within the first month. Under California's CCPA, 45 days, extendable by another 45 (90 total) with notice. The clock starts when the request arrives, not when you notice it.
Can I charge for a DSAR?
Generally no — DSARs are free of charge. You may charge a reasonable fee or refuse only where a request is manifestly unfounded or excessive, particularly if it's repetitive, and the burden is on you to demonstrate that. Routinely charging for access requests is not permitted.
How do I verify the requester's identity?
Verify to a level proportionate to the sensitivity of the data. For a basic account, confirming control of the registered email may suffice; for sensitive records, stronger checks are warranted. Don't over-collect identity documents, and never disclose data to an unverified requester — an imposter DSAR is a real attack.
What happens if I miss a DSAR deadline?
Missing the deadline is a compliance failure that can lead to complaints to a supervisory authority, investigations, and enforcement action or fines under the relevant law. Beyond the legal risk, late or incomplete responses erode trust. Logging the receipt date and tracking the deadline is the simplest way to avoid this.
Does handling DSARs make my website compliant?
No — DSAR handling covers your reactive, rights-based obligations, but not the preventive side: whether trackers fire before a visitor consents. That preventive gap is the basis of US wiretap (CIPA) litigation, and no DSAR process addresses it. Full compliance needs both halves — honoring requests and controlling what you collect in the first place.
The bottom line
A DSAR isn't complicated once you have a process: recognize the request, start the clock, verify who's asking, find all the data, review it, respond in time, and keep the proof. The failures come from treating it as ad-hoc — a request lost in an inbox, a system nobody checked, an imposter handed a profile.
But don't mistake a clean DSAR process for full compliance. It answers requests about data you already hold; it says nothing about whether you were allowed to collect that data to begin with. Handle the requests well — and separately make sure nothing is collecting visitor data before consent. Those two together are what compliance actually looks like.
Cover the half a DSAR can't — free
See which trackers fire before consent on your site — the preventive exposure DSAR handling doesn't touch — mapped to CIPA, CCPA and GDPR, in about 10 seconds. No extension, no code.
Run your free scan →A plain-English guide, not legal advice. DSAR obligations, deadlines and exemptions vary by jurisdiction and change over time. GDPR timelines are drawn from Article 12; CCPA timelines from the CCPA/CPRA; verify the rules for your specific situation. The $5,000 figure refers to statutory damages available under California Penal Code §637.2. Confirm your obligations with a qualified professional or your DPO.