Verifying Identity for a DSAR Without Overcollecting Data
You have to confirm a requester is who they claim to be before handing over personal data, but asking for too much identification is its own privacy problem. Here's how to calibrate verification.
Identity verification for a data subject access request creates a genuine tension: send data to the wrong person and you’ve caused a breach, but demand a passport scan for a simple newsletter unsubscribe and you’ve collected more sensitive data than the original request ever involved.
Match verification to sensitivity, not to habit
The right amount of verification depends on what’s being requested, not a fixed company-wide policy:
- Low sensitivity (unsubscribe from marketing, delete a newsletter signup): confirming the request comes from the email address on file is usually sufficient.
- Moderate sensitivity (account data, order history, support tickets): confirming account access, a login, a reply from the account’s registered email, or answering a security question already on file, is a reasonable middle ground.
- High sensitivity (financial records, health-adjacent data, anything tied to a payment method): stronger verification is justified, but should still be proportionate, a government ID copy is rarely necessary and creates its own retention and security burden.
What “reasonable” looks like in practice
A defensible verification step is one you could explain to a regulator in one sentence: “we confirmed the request came from the email address associated with the account before releasing account data.” If your verification step requires collecting new sensitive information you wouldn’t otherwise hold, that’s usually a sign you’ve over-corrected.
Common mistakes
- Requiring notarized ID for routine requests. This is disproportionate for most consumer data and creates friction that looks like stonewalling.
- Skipping verification entirely for convenience. Sending account data to whoever emails in, without any check, is how DSARs turn into account takeover vectors.
- Reusing the verification data as new personal data you now retain. If you ask for ID to verify a request, delete or minimize that document once verification is complete, don’t quietly add it to the person’s file.
Enzuzo
If a requester already has an account or has interacted with your consent banner, that existing record (login, consent timestamp, session history) is often enough to verify identity without asking for anything new. Enzuzo's request handling ties into the same account and consent data you already have.
When you can push back
You’re not obligated to fulfill a request from someone you reasonably can’t verify. Under both GDPR and CCPA/CPRA, if you can’t confirm identity with reasonable certainty, you can request additional information necessary to confirm identity, and if that isn’t provided, you can decline to act on the request while documenting why.
A simple decision framework
- What category of data is being requested?
- What’s the minimum confirmation that would reasonably tie the requester to that data?
- Does the verification method itself require collecting anything more sensitive than the request?
- If yes, is there a lighter alternative that still meets the “reasonable certainty” bar?
The bottom line
Verification exists to prevent the wrong person from getting someone else’s data, not to create a second barrier on top of the request itself. Calibrating the check to the sensitivity of what’s being asked for keeps you compliant without turning every request into an identity audit.
This guide is educational and not legal advice. For your specific situation, consult a privacy attorney.