DSAR Identity Verification: How to Verify a Subject Access Request

Identity verification for a DSAR means confirming, before you disclose anything, that the requester is the person whose data they are asking for. Under the CCPA regulations that is two matching data points for categories of personal information, and three matching data points plus a signed declaration under penalty of perjury for specific pieces. Under the GDPR you may only ask for more proof where you have reasonable doubts, and what you ask for has to be proportionate.

Verification is the step that decides whether a data subject access request ends as a compliance win or a data breach. Disclose to an impostor and you have handed a stranger someone's file. Over-verify and you have collected a passport scan you now have to protect, delayed the response past the deadline, and given a regulator a second thing to look at. Neither failure is theoretical: identity-verification mistakes on access requests have produced enforcement actions in both the US and the EU.

What is the verification standard for each law?

The laws split into two camps. California wrote actual verification rules with numbers in them. Everyone else, including the GDPR and the other nineteen state laws, tells you to make a reasonable effort and leaves the method to you.

The CCPA numbers are the useful anchor even outside California, because they are the only figures a regulator has ever put in writing. A privacy team that verifies at the California standard is defensible everywhere, and it saves you from designing twenty different verification flows.

How many data points do you need to verify a CCPA request?

Two for a request to know categories of personal information, three for a request to know specific pieces, and the three-point request also requires a signed declaration under penalty of perjury that the requester is the consumer whose data is at issue. The data points must be ones you already hold and can compare against, not new information you ask the person to invent.

That last part is where most workflows quietly break. Asking for an email address, a phone number, and a date of birth only verifies anything if all three are already in your records for that person. If your CRM has an email and nothing else, you have one usable data point no matter how many fields your intake form contains. Knowing what you hold on someone is a prerequisite for verifying them, which is why personal data discovery usually has to run before verification finishes, not after.

Can you ask for a driver's license or a passport?

You can, but only when nothing less intrusive will do, and you should treat it as the exception. Collecting a government ID to answer an access request means creating a new copy of sensitive identity data, storing it, protecting it, and deleting it afterward. Regulators have been explicit that demanding more identification than the request warrants is itself a compliance problem, not a safe default.

A better ladder, in order: use the authentication the person already has, then match data points you already hold, then ask for a signed declaration, and only then ask for documentary proof. If you do end up taking an ID document, use it for verification and nothing else, do not add it to the person's marketing or CRM record, and delete it once the request is closed. Document that deletion, because the ID you collected is now personal data subject to the same rights as everything else.

How do you verify a request from someone who has an account?

Use the login. The CCPA regulations let you verify an account holder through your existing authentication practices, and they require re-authentication before you disclose, delete, or correct anything, so a session that was opened last week is not enough on its own. Two-factor authentication is the cleanest way to satisfy this, and it is usually already built.

Two prohibitions matter here. You cannot require someone to create an account in order to submit a request, so a public intake route has to exist alongside the in-product one. And for online deletion requests you should use a two-step process: submit, then separately confirm. That confirmation step is not bureaucracy, it is the thing that stops an accidental or malicious erasure you can never undo.

What do you do when you cannot verify the requester?

Say so, in writing, and explain why. Under the CCPA, if there is no reasonable method to verify a consumer to the required degree of certainty, you must tell the consumer that in your response, state it in your privacy policy, explain why no method exists, and reassess at least once a year whether one can be established. A request for specific pieces that you can only verify to the lower standard should be treated as a request for categories rather than refused outright.

Under the Virginia-model state laws the rule is shorter: if you cannot authenticate the request using commercially reasonable efforts, you may decline to act, and you have to tell the consumer that is why. Under the GDPR you may ask for what you need to resolve a genuine doubt, but you cannot use verification as a way to run out the clock or to refuse a request you would rather not answer.

Do you have to accept a request from an authorized agent?

Yes, and the verification burden shifts but does not disappear. Under the California rules, unless the consumer has given the agent a power of attorney under Probate Code sections 4000 to 4465, you may require the consumer to give the agent signed permission, verify their own identity directly with you, or directly confirm to you that they authorized the agent. You are also entitled to verify the agent's own identity and their authority to act.

Volume is the reason this matters commercially. Privacy-tool services and data-removal companies file requests in bulk on behalf of thousands of people, and those requests are valid requests. A workflow that treats every agent submission as a manual investigation will drown. A workflow that waves them through without checking the authorization is disclosing personal data to a third party on trust.

Does verification pause the response deadline?

Under the GDPR, where you have reasonable doubts and ask for more information, the one-month period is generally treated as running from when you receive what you need. Under the CCPA and the state laws, verification happens inside your 45 days rather than beside them, so a slow verification step eats the same window you need for discovery, redaction, and review. The 10-business-day acknowledgment California requires runs from receipt either way.

Iowa is the one state where the arithmetic is different, at 90 days plus a 45-day extension, and Florida is tightest at 45 plus 15. The full deadline table by state has the rest. Whichever clock applies, the practical rule holds: send the verification questions the day the request lands, not the week you get to it. Most requests arrive in a shared inbox rather than through a form, and the gap between the day one lands and the day someone notices it is where the window actually goes.

What should you record for every verified request?

Verification is a decision, and a decision you cannot evidence is a decision you did not make as far as an investigator is concerned. For each request, keep the date it arrived, the identifiers the requester supplied, which data points you matched and against which system, who approved the match, whether a declaration was signed, and the date you deleted any documents collected solely for verification.

That record is what turns a disputed disclosure into a closed question. It is also what makes a cure period usable in the states that still offer one: an attorney general who sends a notice wants to see the process, and a timestamped trail is the process. Obtainer produces that trail as a by-product of running the request rather than as a separate compliance chore, and identity verification sits at the front of the workflow so nothing moves to discovery until the requester is confirmed.

Common verification mistakes

• Asking for data points you do not hold. A field the person fills in that you cannot compare against anything verifies nothing. Ask for identifiers you can actually match.
• Requiring a photo ID for a low-risk request. Disproportionate collection is a violation in its own right, and it creates a new sensitive record you now have to protect.
• Treating verification as a reason to stop the clock. Under US state laws it is not. The deadline runs while you verify.
• Verifying once and disclosing forever. Re-authenticate before each disclosure, deletion, or correction, especially for account holders.
• Refusing outright when you cannot verify to the higher standard. Downgrade a specific-pieces request to categories instead, and explain the downgrade.
• No record of the match. If you cannot show which two or three data points you compared, you cannot show you verified at all.

Frequently asked questions

What is identity verification in a DSAR?

It is the step where a business confirms that the person making a data subject access request is the person whose data is being requested, before disclosing, deleting, or correcting anything. It normally works by matching identifiers the requester supplies against identifiers the business already holds, at a certainty level scaled to how sensitive the requested data is.

How do I verify a subject access request under the GDPR?

Only ask for more information where you have reasonable doubts about identity, and keep the request proportionate. Article 12(6) permits the additional information necessary to confirm who the person is, nothing more. For an account holder, existing authentication is usually sufficient. Demanding a passport copy from someone who emailed from the address on file is the kind of over-collection regulators criticize.

Can I refuse a DSAR if I cannot verify the person?

Under the US state laws you may decline to act on a request you cannot authenticate with commercially reasonable effort, and you must tell the requester that is the reason. Under the CCPA, if no reasonable verification method exists at all, you must say so in the response and in your privacy policy, explain why, and reassess annually. You cannot use unverifiability as a general excuse.

Does a data subject have to prove their identity to make a request?

Not upfront. A request is valid however it arrives, including by email or over the phone, and the burden of deciding whether verification is needed sits with the business. You verify because you are about to disclose personal data, not as a condition of accepting the request. Refusing to log a request until proof arrives is where most late responses begin. Record it first and verify second, the same order any well-run client intake process uses.

What counts as a data point for CCPA verification?

Any identifier you already hold that the consumer can supply and you can compare: an email address, a phone number, a mailing address, a date of birth, an account number, or the last four digits of a payment method. It only counts if it is already in your records for that person. Government ID numbers and account passwords should not be used as matching data points.

How long should I keep verification records?

Keep the record of the verification decision for as long as you keep the request record itself, which in most privacy programs is at least two years, and delete any identity documents you collected solely to verify as soon as the request closes. The record of the decision and the documents behind it have different retention needs, and keeping them together is the mistake.

Verification sits at the front of the workflow described in our DSAR process guide, and the consequences of getting the timing wrong are covered in what happens when you miss a DSAR deadline. If most of your requests come from California residents, the obligations specific to that law are in our CCPA compliance guide.