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:
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.