Verifying a Data Subject's Identity for a Privacy Request

Identity verification is the step where privacy requests go wrong in both directions. Verify too loosely and you can hand a stranger a complete file on someone else, which is itself a data breach. Verify too aggressively and you violate the data minimisation rule by demanding a passport scan to confirm an email address. In 2022 the California Attorney General's settlement with Sephora and the later action against Todd Snyder both touched this nerve: a business cannot turn identity verification into a barrier that defeats the right. The job is to match the strength of your check to the sensitivity of what is being asked, and to know the requests where you are not permitted to verify at all.

Here is how to set that bar under GDPR and the CCPA. For the surrounding workflow, see DSAR handling for website owners.

The GDPR rule: proportionality first

GDPR does not prescribe documents. Article 12(6) says that where you have reasonable doubts about the identity of the person making a request, you may ask for additional information necessary to confirm it. Recital 64 tells you to use reasonable measures to verify identity, especially in the context of online services. Two principles fall out of that:

• Doubt first, then verify. You do not verify by default. You verify when you have a genuine reason to doubt who is asking.
• Proportionate to the data. The check should match the sensitivity and volume of what you hold. Confirming an account holder through the account they are already logged into can be enough. Releasing a decade of health-adjacent records warrants more.

The EDPB has warned specifically against using verification to collect more data than you held before. Asking a requester to upload government ID that you then have to store, secure, and eventually delete can create a new privacy problem larger than the one you solved.

The CCPA rule: two tiers with named thresholds

California is more prescriptive. The CCPA regulations (sections 7060 to 7063) define a verifiable consumer request and set two thresholds depending on what is being asked:

• Reasonable degree of certainty. For a request to know categories of personal information, match at least two data points the consumer provides against information you already hold. (Section 7062(b).)
• Reasonably high degree of certainty. For a request to know specific pieces of personal information, match at least three data points, plus obtain a signed declaration under penalty of perjury that the requester is the consumer whose data it is. (Section 7062(c).)

The regulations also tell you to verify using information you already maintain before asking the consumer for anything new, and to avoid collecting sensitive identifiers (like a government ID number) for verification unless there is no less intrusive way. If you genuinely cannot verify a consumer to the required certainty, you may deny the request, but you have to say so in your response and in your privacy policy, and reassess annually whether a method now exists. For enforcement context, see the California enforcement guide.

Match the check to the request type

A single verification policy for every request is either too weak for the sensitive ones or too heavy for the trivial ones. Grade it:

• Opt-out / do-not-sell: no identity verification. Confirm just enough to target the right record.
• Correction (rectification): moderate. You need enough confidence to change a record without letting someone alter another person's data.
• Access to categories: moderate. GDPR proportionality, or the CCPA two-data-point match.
• Access to specific pieces, or deletion: higher. These are the destructive or fully revealing actions. CCPA wants three data points and a signed declaration; GDPR wants confidence proportionate to the exposure.

The cleanest signal you can use is one you already have. If the requester is authenticated in an existing account, that account is the verification for most requests. Reserve document-based checks for the rare case where you hold sensitive data, have no prior relationship, and have a real reason to doubt the requester.

Email verification: the sensible default for web requests

For most website-driven requests, a confirmed email address is a proportionate first factor. Send a one-time verification link to the address on file or the address the request came from, and only action the request once the link is clicked. This proves control of the mailbox tied to the account without collecting anything new, and it defeats casual spoofing where someone types a stranger's email into a form. It is not sufficient on its own for highly sensitive disclosures, but as a baseline for access, correction, and deletion on ordinary account data, it hits the proportionality mark. Time-box the link so an intercepted email does not stay valid indefinitely.

Authorised agents and requests on behalf of others

People can ask someone else to make a request for them: a privacy-service company, a lawyer, a parent for a child. Both GDPR and the CCPA let you take reasonable steps to confirm two things: that the agent is genuinely authorised, and that the underlying person is who the agent says. Under the CCPA you can require proof of the agent's authorisation (for example, a signed permission or power of attorney) and, in some cases, direct confirmation from the consumer. Do not use the agent layer as an excuse to demand more than the situation needs, but do confirm the chain of authority before releasing or deleting anything, because a mistaken disclosure to an unauthorised agent is your breach, not theirs.

Where consent records help

When a request touches cookie, analytics, or advertising data, a consent log gives you a built-in corroboration point. Each consent event carries a unique consent ID, a timestamp, and contextual data, so you can match the requester to their recorded choices without asking them to re-prove anything. CookieBeam's privacy portal ties each request to the requester's email and verifies it before the request is actioned, and it detects the visitor's region so the request types offered already match the jurisdiction's rules (for example, it does not put a verification gate in front of a California opt-out). The verification token is time-limited, so a stale link cannot be reused. For how those records are structured, see proof of consent.

Authoritative sources

• GDPR Article 12(6), verification and reasonable doubt
• GDPR Recital 64, identity verification
• CCPA Regulations section 7060, general rules on verification
• CCPA Regulations section 7062, verification thresholds
• California Attorney General: CCPA