Most guidance on data subject access requests covers intake forms, response templates, and deadline tracking, as if the hard part is knowing what to do. In most cases, the hard part is finding the data in the first place.
Take a company well past the "we're too small for this" stage, with a privacy contact and a documented process on paper. A former employee sends a deletion request. It lands with HR. HR deletes the record and moves on, without looping in legal or privacy. Nobody checks whether the same data exists elsewhere: the HRIS, an old applicant tracking export, a Slack thread, a backup. The request gets closed out. Whether it was actually handled correctly is a different question, and it's the one that matters if a regulator asks later.
Companies can build a clean intake process, name a privacy contact, and track deadlines carefully, and still fail to comply, because nobody has mapped where personal data actually lives. If a signup form from years ago fed into three separate tools and nobody remembers that, you can't produce, correct, or delete that data on request no matter how organized the process looks.
DSAR Response Deadlines
The deadlines below are the easy part, and worth having on hand:
| Law | Standard response period | Possible extension |
|---|---|---|
| GDPR | 1 month | Extendable by 2 more months with notice to the requester |
| CCPA (California) | 45 days | Extendable by 45 more days, one time |
| Most other US state laws | 45 days | Extendable by 45 more days, one time |
A common shortcut is to build your process around the strictest deadline you're subject to and treat that as covering the rest. As a starting point for a company that can't run five separate playbooks, that's fine. It just isn't a full substitute.
GDPR and CCPA diverge on more than the clock: CCPA has its own rules on opt-out rights and identity verification that a GDPR-shaped process won't automatically satisfy. Check the specific requirement before assuming the stricter deadline means full coverage.
Not Every Request Deserves the Same Response
Not every DSAR is genuine. Companies with any exposure to Germany should plan for this specifically: deletion requests, some of them tests to see whether a company will respond correctly, show up often enough there to be a real drain on time, not a rare exception.
Bad-faith requests aren't limited to Germany, though. In one case, a company received an application that was clearly fabricated, submitted so the sender could follow up later with a deletion request and see what happened. The person claimed a California address but wouldn't provide anything to support it, and wouldn't confirm identity beyond what was already on file.
Past a certain point, pushing for more verification stops being diligence and starts being wasted effort on a request that was never going anywhere. The data was deleted, and the request was closed.
The judgment involved isn't a fixed rule about verifying more or less. It's knowing where the line sits for a given request, and being able to explain the reasoning behind stopping there if anyone asks.
What DSAR Compliance Means in Practice
For a company too small for a dedicated privacy platform, the fix isn't a better intake form. It's knowing where the data actually lives, and making sure the people most likely to receive a request first, whether that's HR, support, or sales, know to route it rather than act on it directly. Process matters, but only once there's something for it to point to.
A useful test: could your company say where a given person's data lives within a day, if asked right now? If the answer isn't clearly yes, that's the gap worth closing first, and it's usually bigger than it looks from the outside.
Get Help Building a Defensible DSAR Process
If you're not sure where to start, or you want a second opinion on whether your current setup would actually hold up under a real request, General Legal can help you build the process and map where your data actually lives.
- Most guidance on data subject access requests focuses on intake forms and deadlines, but the harder and more common failure point is not knowing where the requested data actually lives.
- A company can have a clean intake process and a named privacy contact and still fail to comply if a request gets closed out by one team, like HR, without checking whether the same data exists elsewhere.
- GDPR gives one month, extendable by two more, to respond, while CCPA and most other US state laws give 45 days, extendable by another 45, but building around the strictest deadline doesn't cover requirements, like CCPA's identity verification rules, that diverge in other ways.
- Not every request is made in good faith; companies with any exposure to Germany in particular see a meaningful volume of test deletion requests, and the right response to a clearly fabricated request is to stop pushing for verification once further diligence stops being useful.
- For companies too small for a dedicated privacy platform, the practical fix is knowing where personal data actually lives and making sure the teams most likely to receive a request, like HR, support, or sales, know to route it rather than act on it unilaterally.
- A useful self-test is whether the company could say, within a day, where a specific person's data lives if asked right now; if the answer isn't clearly yes, that's the gap to close first.
| The real DSAR problem | It's not the intake process or deadline tracking that trips companies up, it's not knowing where personal data actually lives across systems. |
|---|---|
| How it goes wrong in practice | A deletion request lands with one team, like HR, which deletes its own record and closes the request without checking whether the data also exists in other tools, exports, or backups. |
| GDPR deadlines | GDPR gives one month to respond, extendable by two more months with notice to the requester. |
| US deadlines | CCPA and most other US state laws give 45 days, extendable once by another 45 days, but CCPA also has separate rules on opt-out rights and identity verification. |
| Bad-faith requests | Not every DSAR is genuine; companies with exposure to Germany in particular see a real volume of test deletion requests, and diligence on verification should stop once it's clearly a wasted effort. |
| What compliance actually requires | Knowing where data lives and making sure front-line teams like HR, support, and sales route requests instead of acting on them directly matters more than a polished intake form. |
| A practical self-test | Ask whether your company could say where a specific person's data lives within a day if asked right now; if not, that gap needs to be closed first. |
What's the biggest mistake companies make when handling data subject access requests?
Assuming a clean intake process and documented deadlines are enough, when the real risk is not knowing where the requested person's data actually lives across all systems.
How long does a company have to respond to a DSAR?
GDPR gives one month, extendable by two more months with notice; CCPA and most other US state laws give 45 days, extendable once by another 45 days.
Is it enough to build a DSAR process around the strictest deadline you're subject to?
It's a reasonable starting point but not a full substitute, since GDPR and CCPA diverge on more than timing, including CCPA's separate rules on opt-out rights and identity verification.
How should a company handle a DSAR it suspects is fabricated or made in bad faith?
Push for reasonable identity verification, but recognize the point where further diligence stops being useful; the article describes deleting the data and closing a clearly fabricated request rather than continuing to chase verification.
What should a small company without a dedicated privacy platform actually do first?
Map where personal data actually lives and make sure teams likely to receive a request, like HR, support, or sales, know to route it to the right person instead of handling it themselves.
- Where Knowledge Lives: What You're Actually Buying From a Law FirmLaw firms sell knowledge. The real question is where that knowledge lives once someone walks out the door.
- Synthetic Data: The Most Exciting Privacy-Enhancing Technology, and the Most OversoldSynthetic doesn't mean private. Generative models can leak real records—here's what testing catches.