DSAR Identity Verification: When and How to Verify Requests

Why Identity Verification Matters for DSARs

Identity verification is the part of the DSAR process that sits between two serious risks. On one side, if you release personal data to the wrong person, you have committed a data breach — one that you caused, with personal liability and regulatory consequences. On the other side, if you create unnecessary barriers to verification, you are effectively preventing people from exercising their legal rights, which is also a violation.

Getting the balance right is not difficult, but it requires you to think about context rather than following a one-size-fits-all rule.

This guide covers when you need to verify identity, what counts as reasonable verification, how much you can ask for (and what you cannot ask for), and how to handle different scenarios — from regular customers to former employees to strangers who contact you out of the blue.

For the full DSAR response process, see our step-by-step guide. For deadlines and timing considerations, see DSAR response deadlines.

The Fundamental Principle: Proportionality

Every privacy law that creates DSAR rights also establishes a principle of proportionality for identity verification. The idea is straightforward:

The level of verification you require should be proportional to the sensitivity of the data and the risk of disclosing it to the wrong person.

In practice, this means:

• A customer who emails you from the email address on their account, asking for a copy of their order history, does not need to provide a passport scan.
• A stranger who phones you claiming to be a former customer and requesting sensitive financial records probably does need to provide some form of identification.

The ICO in the UK, the EDPB in the EU, and the California AG's office have all emphasized this proportionality principle. The message is consistent: verify enough to be confident, but do not create barriers.

When Is Verification Required?

You Must Verify When:

• You have reasonable doubts about the identity of the requester. This is the key legal test under GDPR (GDPR Article 12(6)). If you are not reasonably confident the person making the request is who they claim to be, you must verify before disclosing data.
• The request comes through a channel where identity is not established. A phone call from someone you do not know. An email from a generic address. A letter with no identifiers beyond a name.
• The data involved is sensitive. Health data, financial data, or other special category data warrants more careful verification.
• A third party is making the request on behalf of the data subject. You need to verify both the identity of the third party and their authorization to act.

You Probably Do Not Need to Verify When:

• The requester is already authenticated. A customer logged into their account, an employee using the internal HR system, or someone emailing from the address you have on file.
• You can reasonably confirm identity from context. The person provides details that only the data subject would know (account number, transaction details, specifics of their interactions with you).
• You already have an ongoing relationship. A current customer or employee who contacts you through established channels, using identifiers consistent with your records.

The test is not "can I be 100% certain?" It is "do I have reasonable grounds to believe this is the right person?"

What Counts as Reasonable Verification?

The answer depends on context. Here is a practical framework, organized by risk level.

Level 1: Context-Based Verification (Low Risk)

When to use: The requester contacts you through a channel linked to their identity, and the data is not particularly sensitive.

What this looks like:

• The person emails from the address registered on their account
• A logged-in user submits a request through your website
• An employee submits a request through your HR system
• The person references their customer ID, account number, or other unique identifier

What you do: Accept the request and proceed. The existing authentication is sufficient.

Level 2: Knowledge-Based Verification (Medium Risk)

When to use: The requester's identity is not obvious from the channel they used, but you hold data that you can use to verify them.

What this looks like:

• Someone emails from an address you do not recognize, claiming to be a customer
• A former customer or former employee contacts you
• The person claims to be a data subject but you cannot immediately confirm this from your records

What you do: Ask them to confirm information you hold about them. Useful verification questions include:

• Full name (including any previous names)
• Date of birth
• Address on file
• Account number or customer ID
• Details of specific transactions or interactions (date, product, amount)
• The email address associated with their account

The idea is to confirm that the person knows details that only the genuine data subject would know. You are not asking for proof of identity — you are matching what they tell you against what you already hold.

How many data points? There is no fixed rule, but matching two or three data points typically provides reasonable confidence for non-sensitive data. Under CCPA (Cal. Civ. Code § 1798.130), the regulations are more specific:

• Categories of data only: Match at least two data points (reasonable degree of certainty)
• Specific pieces of data: Match at least three data points plus a signed declaration under penalty of perjury (reasonably high degree of certainty)

Level 3: Document-Based Verification (High Risk)

When to use: The data is sensitive, you have no prior relationship with the requester, or there are specific concerns about the request's legitimacy.

What this looks like:

• A request for sensitive personal data (health records, financial details, special category data under GDPR)
• The requester cannot confirm any details you hold about them
• A third party is making the request and you need to verify both their identity and their authority
• Something about the request raises legitimate concerns (for example, the contact details do not match your records and the data is high-value)

What you do: Request a copy of photo identification. Acceptable forms include:

• Passport
• Driving license
• National identity card

You may also ask for:

• A utility bill or bank statement confirming their address (to match against the address in your records)
• A signed letter of authority (for third-party requests)

Important: Only request the minimum identification necessary. If a passport is sufficient, do not also ask for a utility bill, a selfie, and a signed declaration. And remember — whatever ID you receive, you need to handle it securely and delete it once verification is complete (you should not keep copies of identity documents beyond the verification process).

Third-Party Requests: Verification for Representatives

When someone makes a DSAR on behalf of another person, you need to verify three things:

1. The identity of the data subject — who the data is about
2. The identity of the representative — who is making the request
3. The representative's authority to act — evidence that the data subject has authorized this person to make the request on their behalf

Solicitors and Lawyers

A letter on headed paper from a law firm is usually sufficient to verify the representative's identity and professional status. For authority, you can:

• Accept a letter of authority signed by the data subject
• Contact the data subject directly to confirm they have authorized the request
• Accept the solicitor's professional assurance (solicitors have professional obligations that make fraudulent representations extremely unlikely)

Parents and Guardians

For requests concerning a child's data:

• Verify the parent or guardian's identity
• Verify their relationship to the child (birth certificate, court order, or other documentation)
• Consider whether the child is old enough to make the request themselves — under GDPR, there is no fixed age, but children with sufficient understanding can exercise their own rights. Under UK guidance, children aged 12 and over are generally considered capable.

Other Representatives

For anyone else claiming to represent the data subject:

• Request written authorization from the data subject, signed and dated
• Verify the data subject's identity (contact them directly if possible)
• Verify the representative's identity (knowledge-based or document-based, depending on the context)

What You Should NOT Ask For

Proportionality cuts both ways. Here are things you should not request for DSAR verification:

Do Not Require In-Person Verification

Requiring someone to attend your premises in person to prove their identity is disproportionate in almost all circumstances. If the person makes their request remotely, the verification should be remote too.

Do Not Ask for Original Documents

Requesting original documents (as opposed to copies) is unnecessary and creates risk for the requester. Copies or scans are sufficient for verification.

Do Not Request Excessive Identification

If someone is a current customer contacting you from their registered email, asking for a passport scan is disproportionate. Match the verification level to the actual risk.

Do Not Ask for a Reason

You cannot require the requester to tell you why they want the data as part of the verification process (or at all). The right of access is unconditional — the person does not need to justify their request.

Do Not Collect Unnecessary Data

If someone provides a passport copy for verification, use it only for verification. Do not record the passport number, do not store the copy indefinitely, and do not add it to the person's file. Use it, confirm the identity, delete it.

Do Not Make Verification a Barrier

If your verification process is so onerous that people give up and abandon their requests, you are effectively denying the right of access. Regulators are alert to this. If your DSAR form has 15 mandatory fields, requires three forms of ID, and demands a notarized signature, expect questions from the regulator.

The Timing Issue: Does Verification Pause the Deadline?

This is one of the most common practical questions, and the answer varies slightly by jurisdiction.

Under GDPR / UK GDPR

Strictly speaking, the response deadline starts when you receive the request, not when you verify the identity (GDPR Article 12(3)). However, the ICO and European data protection authorities take a pragmatic approach: if you promptly request verification and the requester takes time to provide it, the authorities are unlikely to find against you for a corresponding delay.

The key word is "promptly." If you receive a DSAR on day 1 and ask for verification on day 1 or 2, and the requester provides it on day 10, it is reasonable to treat day 10 as the effective start of your response period. If you receive a DSAR on day 1 and ask for verification on day 15, you do not get to restart the clock.

Best practice: request verification within 48 hours of receiving the request, and continue your preparatory work (identifying relevant systems, planning your search) while waiting.

Under CCPA

The CCPA regulations state that if you need to request verification, you must do so promptly and the consumer must be given a reasonable time to provide it. The 45-day response period generally starts upon receipt of the request, but the regulations acknowledge that verification may affect the practical timeline.

If the consumer fails to verify their identity after you have requested it, you can notify them that you cannot process the request without verification. You should make at least two attempts to contact the consumer for verification before considering the request abandoned.

Creating a DSAR Verification Policy

Every business should have a simple, documented policy for DSAR identity verification. Here is what yours should cover:

1. Default Verification Levels

Define what level of verification applies to common scenarios:

2. What to Accept as Verification

List the specific forms of verification you accept at each level:

• Context-based: Registered email address, authenticated account, recognized internal system
• Knowledge-based: Matching two or more of: full name, date of birth, address, account number, transaction details
• Document-based: Passport, driving license, national ID card; plus utility bill or bank statement if address verification is needed

3. Process for Requesting Verification

• Template email/letter requesting verification
• Timeline for making the request (within 48 hours of receiving the DSAR)
• What to do if the requester does not respond (follow up once, then document)
• How to handle partial verification (the person can confirm some details but not others)

4. Data Handling for Verification Documents

• How to receive ID copies securely (encrypted email, secure upload link — not unencrypted email)
• How long to retain verification documents (only as long as needed — delete after verification is complete)
• Where to store them during the verification process (securely, with access limited to the DSAR handler)

Verification for Different Request Types

Customer DSARs

For most customer DSARs, context-based or knowledge-based verification is sufficient. If the customer has an account with you and contacts you from a recognized channel, you can usually verify them against your existing records without requesting additional documentation.

Employee DSARs

Employees are easy to verify — you know who they are. If they submit a request through a work channel (work email, HR system, in-person conversation), their identity is established. Former employees may need knowledge-based verification against their personnel records.

For more on handling employee DSARs specifically, see our employee DSAR guide.

Third-Party DSARs

These require the most careful verification. Always verify both the identity of the data subject and the authority of the representative. Never release data to a third party based solely on their claim to be authorized — require evidence.

Anonymous or Pseudonymous Data

If you process data that you cannot link to an identified individual (for example, data identified only by a cookie ID or device ID), you are not required to collect additional data solely to identify the person for the purposes of a DSAR (GDPR Article 11). However, if the individual provides information that allows you to link the data to them, you must process the request.

When Verification Fails

Sometimes you cannot verify the requester's identity. Maybe they cannot confirm any of the details you hold, or the details they provide do not match your records, or they refuse to provide identification.

In these cases:

1. Document your attempts — record what verification you requested and the requester's response
2. Explain the situation — write to the requester explaining that you cannot verify their identity and therefore cannot release the data, as doing so would risk a data breach
3. Offer alternatives — suggest other ways they might verify their identity
4. Do not simply ignore the request — a response explaining why you cannot process the request is still a response

You are not required to disclose data when you cannot confirm the requester's identity. But you must handle the situation transparently and give the person a fair opportunity to verify themselves.

The Balance: Security Without Barriers

The entire verification process comes down to one question: "Am I reasonably confident this is the right person?"

If yes, release the data. If no, take proportionate steps to get there. If you still cannot get there, explain why and offer alternatives.

Do not let verification become a tool for discouraging DSARs. And do not let the fear of a data breach paralyze you into demanding unreasonable proof. Both extremes create problems. The proportionate middle ground is where you want to be.

References

• General Data Protection Regulation (GDPR): Article 12(6) — verification of identity for data subject requests. GDPR Article 12
• California Consumer Privacy Act (CCPA): Cal. Civ. Code § 1798.130 — verification requirements for consumer requests. Full text on the California Legislative Information site
• CCPA Regulations: Title 11, Division 6, California Code of Regulations — detailed verification requirements. Final CCPA regulations (California Office of the Attorney General)
• UK GDPR / Data Protection Act 2018: ICO guidance on the right of access, including identity verification. ICO right of access guidance

Get Your Verification Process Right

Our Identity Verification Guide gives you a complete, ready-to-implement verification framework — including decision trees, template verification request letters, and a policy document you can customize for your business. No guesswork, no gray areas.

Download the Identity Verification Guide