A dual-framework guide to identity verification under the California Consumer Privacy Act (CCPA/CPRA) and the EU General Data Protection Regulation (GDPR), including the CPPA’s implementing regulations and EDPB guidance.

Regulatory Note: This page reflects the CCPA as amended by the CPRA, the CPPA’s final regulations operative from March 29, 2023, and the CPPA’s amended regulations effective January 1, 2026. For the GDPR, it incorporates the EDPB’s final Guidelines 01/2022 on the Right of Access (adopted 2023) and the EDPB’s Coordinated Enforcement Framework (CEF) 2024 Report on the Right of Access (January 2025). Where a 2026 regulatory change is directly relevant, it is flagged in a highlighted notice.

Contents

1. Introduction: Why Verification Is a Two-Sided Legal Problem
2. CCPA: The “Verifiable Consumer Request” Framework
3. CCPA: Tiered Standards of Certainty by Request Type
4. CCPA: Accountholders vs. Non-Accountholders
5. CCPA: Authorized Agents
6. CCPA: Response Timelines and Procedural Requirements
7. GDPR: The Proportionality Framework
8. GDPR: When Verification Is and Is Not Permitted
9. GDPR: Verification Standards by Request Type
10. GDPR: Authorized Representatives
11. GDPR: Response Timelines and the Suspension Rule
12. Comparative Analysis: CCPA vs. GDPR
13. Practical Compliance Considerations
14. Key Citations Quick Reference

I. Introduction: Why Verification Is a Two-Sided Legal Problem

Identity verification sits at the intersection of two competing legal obligations that every privacy-regulated organization must simultaneously honor. On one side is the individual’s legally enforceable right to access personal information held about them, to correct inaccuracies in that information, and to have it deleted. On the other side is the organization’s equally important obligation not to disclose, alter, or destroy personal data in response to a request made by someone who is not the data subject — whether that person is an impersonator, a fraudster, or simply someone who mistakenly submitted a request for another person’s records.

Getting verification wrong in either direction creates material legal exposure. Organizations that impose unnecessarily burdensome verification requirements — systematically demanding copies of government-issued identity documents, requiring account creation, or constructing multi-step authentication gauntlets as a standard practice — are not engaging in cautious risk management. They are actively impeding the exercise of legal rights, and that impairment is itself a violation of both California and EU law. Conversely, an organization that honors requests without adequate identity confirmation risks disclosing sensitive personal information to an unauthorized party, a breach that may trigger data protection notification obligations, regulatory investigation, and civil liability.

This page sets out the identity verification frameworks established by the California Consumer Privacy Act (CCPA), as amended by the California Privacy Rights Act (CPRA), and the European Union’s General Data Protection Regulation (GDPR). The two frameworks share a common concern — preventing unauthorized disclosure or modification while facilitating legitimate individual rights — but they approach verification differently in their architecture, their standards, and their enforcement posture. Understanding both frameworks, and the points at which they converge and diverge, is essential for any organization that collects personal data from both California residents and individuals in the EU or UK.

One preliminary distinction that bears emphasis at the outset: under the CCPA, the right to opt out of the sale or sharing of personal information is expressly excluded from the verifiable consumer request framework. (§ 1798.120; 11 CCR § 7026(b)) An opt-out request does not require a verifiable consumer request, and businesses may not impose identity verification as a condition of honoring one. This page focuses exclusively on access, correction, and deletion requests, where the verification framework applies in full.

CCPA / CPRA

II. CCPA: The “Verifiable Consumer Request” Framework

Statutory Definition

The CCPA defines a “verifiable consumer request” as a request made by a consumer, by a consumer on behalf of the consumer’s minor child, or by a natural person or business entity registered with the California Secretary of State authorized by the consumer to act on their behalf, for which the business can reasonably verify — using commercially reasonable methods — that the person making the request is either the consumer about whom personal information was collected or a person authorized to act on that consumer’s behalf. (§ 1798.140(ak)) The definition is deliberately flexible: “commercially reasonable methods” is not prescribed but must be documented and consistently applied.

The Core Verification Obligation

Every business subject to the CCPA must establish, document, and comply with a reasonable method for verifying that the person submitting a request to know, correct, or delete is in fact the consumer or an authorized representative. (§ 1798.130(a); 11 CCR § 7060(a)) The method must be calibrated to reflect two key variables: the sensitivity of the personal information at issue and the risk of harm to the consumer from unauthorized disclosure, deletion, or correction. A business that maintains a single, undifferentiated verification procedure for all request types — regardless of what data is involved or what action is requested — is unlikely to satisfy this standard.

The Data Minimization Constraint

The CCPA’s verification framework is governed throughout by a data minimization principle that significantly constrains what businesses may demand from consumers in the name of verification. Businesses shall generally avoid requesting additional information from the consumer for purposes of verification. (11 CCR § 7060(b)) The operative word is “generally”: verification should, wherever possible, be conducted using personal information the business already holds about the consumer, rather than asking the consumer to supply new information.

Where the business genuinely cannot verify the consumer’s identity from information it already maintains, it may request additional information — but with strict limitations. Any new personal information collected solely for the purpose of verification must be used only for verification, security, or fraud prevention, and must be deleted as soon as practicable after the request has been processed. It may not be retained, analyzed, disclosed, or used for any other purpose. (11 CCR § 7060(b)) The California Privacy Protection Agency reinforced this principle in its January 2024 Enforcement Advisory, which addressed data minimization in the context of consumer request handling. In no circumstance may a business charge a fee for verifying a consumer’s identity or for processing a verifiable consumer request, regardless of the complexity of the verification required.

When Verification Cannot Be Completed

If a business is unable to verify the consumer’s identity using a commercially reasonable method, it is not required to comply with the request. (11 CCR § 7060(f)) However, the business is not entitled to simply ignore the request. It must inform the consumer that it cannot verify their identity, explain what additional information the consumer may provide to allow verification to be completed, and document the basis for its inability to verify. Businesses that use verification failure as a pretext to avoid processing legitimate requests run a significant regulatory risk, particularly where the CPPA has visibility into the business’s historical patterns of request handling.

III. CCPA: Tiered Standards of Certainty by Request Type

One of the most important features of the CPPA’s verification regulations is the establishment of a tiered system that calibrates the required degree of identity certainty to the nature and risk level of the particular request. (11 CCR § 7062) Rather than applying a single verification standard to all consumer requests, businesses must make a deliberate, documented assessment for each request type. The two primary standards — “reasonable degree of certainty” and “reasonably high degree of certainty” — carry specific procedural benchmarks.

Standard

Reasonable Degree of Certainty

Matching at least two data points provided by the consumer against reliable data points already maintained by the business.

Standard

Reasonably High Degree of Certainty

Matching at least three data points, plus a signed declaration under penalty of perjury that the requestor is the consumer whose information is at issue.

Request to Know — Categories of Personal Information (11 CCR § 7062(b))

A request to know the categories of personal information a business has collected about a consumer requires verification to a reasonable degree of certainty. This standard reflects the fact that category-level disclosure carries a comparatively lower risk of enabling identity theft or harm to the consumer: telling someone that a business has collected “contact information” and “commercial information” about them is meaningfully different from handing over the specific records that fall within those categories. Matching two reliable data points — for example, confirming an email address and a mailing address already on file — will ordinarily satisfy this standard.

Request to Know — Specific Pieces of Personal Information (11 CCR § 7062(c))

A request to know the specific pieces of personal information a business has collected about a consumer demands a materially higher standard: a reasonably high degree of certainty, achieved by matching at least three data points plus obtaining a signed declaration under penalty of perjury. The signed declaration requirement serves a dual purpose. It provides the business with a legal accountability mechanism — if the request is fraudulent, the declarant has committed perjury — and it ensures that the consumer has made an affirmative, deliberate statement of identity rather than simply answering an automated matching exercise. Businesses must design their request workflows to enable the submission of this declaration in a way that is not unduly burdensome but that is sufficiently formal to bear evidentiary weight.

Request to Delete (11 CCR § 7062(d))

The verification standard for deletion requests is not fixed: it is context-dependent, and the business must make a reasoned judgment about whether the lower (“reasonable”) or higher (“reasonably high”) standard applies. The governing factors are the sensitivity of the personal information at issue and the risk of harm from unauthorized deletion. Deletion of a browsing history or a loyalty account with no associated financial data may require only a reasonable degree of certainty. Deletion of financial records, medical data, biometric identifiers, photographs, or other sensitive personal information — where wrongful deletion could cause irreversible loss or harm — should require a reasonably high degree of certainty. Businesses should document this risk-calibration determination and apply it consistently across similar request types.

Request to Correct (11 CCR § 7062(e); § 7060(c))

A request to correct inaccurate personal information requires verification to a reasonable degree of certainty. However, correction requests present a structural challenge that other request types do not: if the consumer is seeking to correct the very information the business would ordinarily use to verify their identity — for example, a name, address, date of birth, or email address — then using that information as a verification data point creates a circular problem. The regulations address this directly: to the extent possible, the business should attempt to verify the consumer’s identity using personal information that is not itself the subject of the correction request. Businesses should identify in advance which alternative data points they will use in this scenario and document that approach in their verification procedures.

IV. CCPA: Accountholders vs. Non-Accountholders

Password-Protected Account Holders (11 CCR § 7061)

Where a consumer submits a request through a password-protected account that the consumer maintains with the business, and does so while authenticated, the submission of that request through the authenticated session constitutes a verifiable consumer request. The logic is straightforward: the act of logging in with correct credentials provides a baseline level of identity assurance that is commercially reasonable for many request types.

However, this baseline is not unlimited. For actions that carry a higher degree of finality or risk — particularly disclosure of specific pieces of personal information, execution of a deletion, or implementation of a correction to sensitive fields — the business must require re-authentication before proceeding. A session that is already open at the time of the request does not substitute for a contemporaneous, affirmative re-authentication step. Businesses should define clearly within their internal procedures which request types trigger re-authentication and implement that requirement consistently in their consumer-facing workflows.

Where a business has grounds to suspect fraudulent or malicious activity on or from an account — for example, because the account’s recent login patterns are anomalous, because it has received a contemporaneous report of unauthorized access, or because the nature of the request is inconsistent with the account’s historical activity — the business shall not comply with a consumer request until it has conducted additional verification procedures confirming the request is authentic. In that circumstance, the business may apply the non-accountholder verification procedure as a supplemental check. (11 CCR § 7061(b))

Non-Accountholders (11 CCR § 7062)

Where a consumer does not maintain a password-protected account with the business — or cannot access one — the tiered data-point matching framework described in Section III applies. The business must match data points that the consumer provides against data points the business already holds and has assessed to be reliable for verification purposes. Examples of commonly used reliable data points include the consumer’s email address on file, mailing address on file, telephone number on file, date of last transaction, account number, or other identifiers already in the business’s records. The business cannot require the consumer to produce information it does not already maintain — the requirement to match against existing records is a floor, not a ceiling.

For requests to know specific pieces of personal information, a signed declaration under penalty of perjury must be obtained in addition to the three-data-point match. Businesses must design their request submission processes to make providing this declaration accessible — not buried in a portal, not requiring download of a separate form — while still ensuring it constitutes a meaningful, deliberate statement. The business should retain this declaration as part of its record of the request.

Government-Issued Identity Documents: Neither the CCPA statute nor the CPPA regulations prohibit a business from requesting a government-issued identity document in appropriate circumstances. However, the regulations’ instruction to “generally avoid requesting additional information” and the data minimization requirement counsel strongly against making ID document production a standard step in the verification process. Identity documents collected for verification purposes must be used only for that purpose and deleted promptly after the request is processed. Businesses that routinely require ID documents as a default — rather than as a last resort when other matching methods have failed — face both regulatory risk and practical data security exposure from holding copies of government credentials.

V. CCPA: Authorized Agents

The CCPA recognizes that consumers may wish to exercise their privacy rights through a representative — whether because they lack the technical capacity to navigate a business’s request portal, because they are incapacitated, or simply because they prefer to delegate the task. A consumer may designate any natural person or business entity registered with the California Secretary of State as an authorized agent to submit requests on their behalf. (11 CCR § 7063)

Establishing the Agent’s Authority

When an authorized agent submits a request to know, correct, or delete on a consumer’s behalf, the business may require the agent to provide proof that the consumer has granted the necessary authority. There are two recognized forms of proof. The first is a written permission signed by the consumer authorizing the agent to submit the specific type of request at issue. The second is a power of attorney executed pursuant to California Probate Code Sections 4000 through 4465. Where a valid power of attorney is presented, the business may not demand additional verification from the consumer directly — the legal instrument itself establishes authority, and the business must treat it as such. Where the agent relies on signed written permission rather than a power of attorney, the business may additionally require the consumer to verify their own identity directly with the business, providing an independent check that the consumer is aware of and has genuinely authorized the agent’s action.

Limitations on Agent Conduct

An authorized agent may not use the consumer’s personal information, or any information gathered from or about the consumer during the request process, for any purpose beyond fulfilling the consumer’s request, completing the required verification, or preventing fraud. (11 CCR § 7063(c)) This prohibition is direct and enforceable: an agent that monetizes consumer data collected during a privacy rights workflow, or uses it to build profiles for advertising purposes, has violated the statute independently of any failure by the underlying business. Businesses should document the agent authorizations they receive and monitor for patterns that suggest misuse.

Scope-Limited Authorizations

Where a consumer has authorized an agent to submit only a specific type of request — for example, a deletion request but not an access request — the business should honor that scope restriction and decline to process requests from the agent that exceed the authorization. Businesses that accept and process requests beyond the scope of the consumer’s written permission risk unauthorized disclosure or modification.

VI. CCPA: Response Timelines and Procedural Requirements

The 45-Day Default Period (§ 1798.130(a)(2))

A business must disclose and deliver the required information, implement the required correction, or complete the required deletion within 45 calendar days of receiving a verifiable consumer request. The clock starts running on the date the request is received, not the date on which verification is completed. This is a consequential distinction: a business that allows weeks to pass before undertaking verification efforts cannot then claim the benefit of the full 45-day period for its substantive response. The obligation to take prompt steps to determine whether the request constitutes a verifiable consumer request does not pause the response deadline.

A single 45-day extension is available where the business reasonably needs additional time, extending the outer limit to 90 days. To obtain this extension, the business must notify the consumer before the initial 45-day period expires, explaining the reason for the extension. An extension taken without timely notice, or for reasons that are not genuine, does not toll the response deadline.

Extended Lookback Period for Access Requests (Effective January 1, 2026)

2026 Update: Under the amended CPPA regulations effective January 1, 2026, if a business retains personal information for longer than 12 months, it must provide a mechanism for consumers to request personal information going back to January 1, 2022, to the extent it is retained. Businesses may ask consumers to specify a date range within which they are making the request, or offer the option to request all retained personal information, in order to manage the scope of compliance. This change is operationally significant for businesses with long data retention schedules and should be reflected in the request submission interface.

Optional Two-Step Confirmation for Deletion (11 CCR § 7060(d))

The CPPA regulations permit businesses to use a two-step confirmation process for deletion requests: the consumer first submits the deletion request, and then separately confirms the request as a second affirmative step before the business proceeds. This optional process serves as a safeguard against accidental or uninformed deletion requests. If a business uses a two-step process, both steps must be easy to complete and must not require the consumer to create an account or log in solely for the purpose of confirming. The use of a two-step confirmation process does not extend the 45-day response clock: the clock runs from the date of the initial request, and the business must ensure that its two-step process can be completed within the response window.

GDPR

VII. GDPR: The Proportionality Framework

The Legal Architecture

Unlike the CCPA, which establishes an explicit tiered framework with specific data-point benchmarks, the GDPR does not prescribe a verification procedure. Instead, the obligation to verify identity — and the limits on how that verification may be conducted — are derived from a constellation of provisions that together establish a proportionality-based framework. Article 12(6) provides that where the controller has reasonable doubts concerning the identity of the person making a request under Articles 15 through 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject. Recital 64 provides that controllers should use all reasonable measures to verify the identity of a data subject who requests access, particularly in the context of online services and online identifiers. And the overriding obligation under Article 12(2) — that controllers must facilitate the exercise of data subject rights — establishes the constitutional principle within which all verification measures must operate.

The Facilitate-First Principle

The GDPR’s approach to verification begins from a fundamentally different premise than a risk-averse compliance culture might expect. According to both the EDPB’s final Guidelines 01/2022 on the Right of Access and the EDPB’s January 2025 CEF Report on the Right of Access, the right of access exists without any general reservation to proportionality with regard to the efforts the controller has to take to comply. In other words, the cost and inconvenience of compliance do not diminish the obligation; what proportionality limits is the burden placed on the data subject, not the burden placed on the controller. The starting point is that a request has been made, and the controller should look for ways to honor it — not for reasons to decline or delay it.

The EDPB’s CEF 2024 Report, which drew on coordinated enforcement investigations by 30 national data protection authorities across Europe throughout 2024, identified several practices that impede the exercise of the right of access in practice. Among them was the routine request for additional identity information from all requestors as a standard step, regardless of whether any genuine doubt about identity existed. The Report makes clear that this practice — treating supplemental verification as a default rather than a response to specific, articulable doubts — is inconsistent with Article 12. The same principle applies to correction and erasure requests by analogy.

Proportionality Is Context-Dependent

What constitutes proportionate verification under the GDPR depends on the nature and sensitivity of the personal data being processed, the risk to the data subject of unauthorized disclosure or modification, and the context in which the processing takes place. A controller that processes highly sensitive data — health records, genetic data, financial account details, data concerning criminal convictions — may be justified in applying more robust verification measures than a controller whose processing is limited to contact details and transaction history. What is proportionate in a healthcare context may be disproportionate in a retail loyalty program context. Controllers must make this assessment deliberately, document it, and be prepared to justify it to a supervisory authority.

VIII. GDPR: When Verification Is and Is Not Permitted

The “Reasonable Doubts” Trigger (Art. 12(6))

The right to request additional identity information arises only where the controller has reasonable doubts concerning the identity of the requestor. This is a threshold condition, not a background default. “Reasonable doubts” must be based on objective, articulable grounds specific to the request at hand — not on a general policy of treating all requestors as suspects. Examples of circumstances that may give rise to genuine reasonable doubts include: a request arriving from an email address not previously associated with the data subject; internal information suggesting that the account from which the request was submitted has recently been accessed without authorization; material inconsistencies between information provided in the request and information the controller holds; or a pattern of requests across multiple accounts suggesting coordinated fraudulent activity. The existence of such doubts must be assessed on the facts of the individual request, not applied categorically to all requests as a class.

The Benchmark Enforcement Case: Dutch AP Decision (2020)

The Dutch Autoriteit Persoonsgegevens (AP) imposed a penalty of €525,000 on a controller that required a copy of a government-issued identity document for every access request submitted, as a matter of uniform policy. The AP found that this practice violated both the data minimization principle under Article 5(1)(c) and the controller’s obligation to facilitate the exercise of data subject rights under Article 12. The decision established a bright-line principle that has been applied consistently since: requiring identity document copies as a default, blanket requirement for all requests — without first assessing whether doubts about the requestor’s identity actually exist — is disproportionate and unlawful. This decision remains the leading enforcement benchmark on this point and has been referenced repeatedly in subsequent supervisory authority guidance across the EU.

Proportionate Verification Measures

Where reasonable doubts do exist, the EDPB has identified a range of proportionate measures that controllers may employ to confirm identity. Confirmation of a unique identifier previously provided by the data subject — an account number, a customer reference, or a code sent to a device already registered on the account — is generally proportionate and minimally invasive. Sending a one-time authentication code to the email address or mobile telephone number on file is proportionate where those means of contact are already established. Multi-factor authentication through existing account infrastructure is appropriate where the controller already operates such infrastructure. Asking the data subject to confirm one or two pieces of information the controller already holds — without demanding the production of new documents — is proportionate in most circumstances.

Where a controller determines that a copy of an identity document is genuinely necessary in a specific case, the EDPB’s Guidelines recommend that the controller encourage the data subject to redact fields that are not necessary to confirm the relevant aspect of their identity. A name and photograph may be sufficient to confirm identity; the document number, date of issue, and other fields may be redacted without undermining the verification purpose. Any identity documents collected for verification should be handled with appropriate security measures and should not be retained beyond what is necessary to complete the verification and respond to the request.

When a Request Cannot Be Verified (Art. 12(6); EDPB Guidelines 01/2022)

If identification is not possible based on the information included in the original request, the controller must take two steps. First, it must inform the data subject that it has been unable to identify them and explain what additional information, if provided, would allow the controller to do so. Second, where the data subject fails or declines to provide the necessary information, the controller is entitled to decline to process the request. Importantly, this is a procedural hold, not a denial of the substantive right. The data subject retains the right to resubmit with additional identifying information, and the controller’s obligation to facilitate the exercise of that right remains intact. Controllers should document this process carefully — a failure to communicate clearly about what is required may itself constitute an obstacle to the exercise of rights.

IX. GDPR: Verification Standards by Request Type

Access Requests (Art. 15; EDPB Guidelines 01/2022)

The right of access is among the most significant — and most frequently exercised — rights under the GDPR. It encompasses the right to obtain confirmation of whether personal data concerning the data subject are processed, access to those data, and a range of supplementary information about the nature and purposes of the processing. Because compliance with an access request will typically involve the disclosure of potentially substantial volumes of personal data, the primary risk the controller is guarding against during verification is the wrongful disclosure of that data to a person who is not the data subject — an outcome that may itself constitute a personal data breach under Article 4(12).

The appropriate verification approach for access requests is confirmation through information the controller already holds about the data subject — an email address, a unique account identifier, or credentials already registered on the controller’s systems. Routine requests for government-issued identity documents are not proportionate for access requests and should not be deployed as a standard procedure. Where the controller holds data on multiple individuals with common names, and therefore cannot uniquely identify the data subject from the request alone, it may ask for additional information to disambiguate — but only to the minimum extent necessary to identify the correct record.

Rectification Requests (Art. 16)

The right to rectification gives data subjects the right to obtain the correction of inaccurate personal data concerning them without undue delay. The verification standard for rectification requests is equivalent to — or in most cases lower than — the standard applicable to access requests, because rectification involves the modification rather than the disclosure of data. The primary risk is that an unauthorized person causes a controller to alter another person’s records, rather than the disclosure of those records to an unauthorized person. While the harm from unauthorized modification should not be minimized, it is typically recoverable in a way that a data disclosure may not be.

There is an important substantive point about rectification that is distinct from, though related to, verification: before implementing a requested correction, the controller should be satisfied that the data in question is in fact inaccurate. Verification establishes who is asking; the substantive assessment establishes whether the requested change is appropriate. These are separate questions, and conflating them — by, for example, refusing to verify identity because the controller disputes the correction being sought — improperly links procedural and substantive elements of the request. Verification should be completed first; the substantive question of accuracy is assessed thereafter.

Erasure Requests (Art. 17)

The right to erasure — sometimes referred to as the “right to be forgotten” — entitles data subjects to request the deletion of personal data concerning them where one of the grounds enumerated in Article 17(1) is established. These grounds include: the data are no longer necessary for the purposes for which they were collected; the data subject withdraws consent and there is no other legal basis for processing; the data have been unlawfully processed; or the data subject objects to processing under Article 21 and there are no overriding legitimate grounds for continued processing.

Because erasure is irreversible and may affect the rights of third parties — particularly where the data constitutes a record of a mutual transaction — verification for erasure requests warrants careful attention. The fact that deletion cannot be undone supports applying a proportionate but robust verification process, calibrated to the sensitivity and finality of the action. However, the existence of a valid Art. 17(1) ground is itself a distinct and separately necessary condition: even a fully verified request from a clearly identified data subject will not succeed if none of the statutory grounds for erasure is established. Controllers should evaluate both questions — who is asking, and whether the grounds for erasure are present — before proceeding, and should document both assessments.

Requests Involving Children’s Data

Where a request relates to the personal data of a child, and the request is submitted by a parent, guardian, or other legal representative on the child’s behalf, the controller may require additional evidence establishing the representative relationship. This requirement is proportionate: the potential for unauthorized access to or modification of a child’s data by someone falsely claiming parental authority is a legitimate concern. Verification of the representative relationship should itself be proportionate, however — demanding extensive documentation for routine requests involving low-sensitivity data remains disproportionate even in the context of children’s data.

X. GDPR: Authorized Representatives and Third-Party Requests

No Unified EU Framework

Unlike the CCPA’s structured authorized agent regime, the GDPR does not establish a uniform framework for requests submitted by authorized representatives on behalf of data subjects. The regulation presupposes that data subjects will generally exercise their rights directly, and leaves the question of third-party representation to be addressed by national law, which varies across EU Member States. Organizations operating across multiple EU jurisdictions should therefore be aware that the documentation and procedural requirements for accepting requests from representatives may differ from one country to another.

General Principles Applicable Across Jurisdictions

While national law varies, a set of general principles applies consistently across EU jurisdictions. A controller that receives a request from a person claiming to act on a data subject’s behalf is entitled to require evidence of the representative’s authority — for example, a power of attorney, a signed letter of authorization from the data subject, evidence of legal guardianship, or other documentation establishing the representative relationship. The controller should verify both the identity of the representative and the scope and validity of the authority under which they are acting. However, the proportionality principle applies to the verification of representative authority with the same force that it applies to the verification of the data subject’s own identity: demanding extensive or excessive documentation for a low-stakes request is disproportionate even where the request is submitted through a third party.

UK GDPR: ICO Guidance

The UK Information Commissioner’s Office has confirmed that a person acting on another’s behalf must provide sufficient evidence of their authority to do so, but that the controller cannot require an excessive level of proof. In straightforward, uncontested circumstances, a signed letter of authorization from the data subject will generally suffice. Where the circumstances are more complex — for example, where the data subject is incapacitated and cannot themselves confirm the representative relationship — controllers may seek additional evidence appropriate to the circumstances, while remaining within the bounds of proportionality.

XI. GDPR: Response Timelines and the Suspension Rule

The One-Month Default Period (Art. 12(3))

Controllers must respond to data subject requests without undue delay and in any event within one month of receiving the request. The one-month clock begins on the date the request is received — not on the date on which verification is completed, and not on the date on which the controller acknowledges the request. This is a firm deadline: a controller that treats the one-month period as starting only when it begins substantive processing of a request, rather than when the request arrives, is misreading its obligations.

Where a request is complex or where the controller receives a large number of requests simultaneously, the one-month period may be extended by a further two months — to a total of three months from the date of receipt. The extension requires two conditions: it must be genuinely necessary given the complexity or volume of the requests, and the controller must inform the data subject within the initial one-month period of the extension and the reasons for it. An extension taken without timely notice, or taken as a general organizational convenience rather than a response to genuine complexity, does not constitute a valid extension under Article 12(3).

Suspension of the Clock Where Verification Is Required (Art. 12(6); EDPB Guidelines 01/2022)

Where the controller has reasonable doubts about the identity of the requestor and requests additional identifying information, the one-month response period may be suspended from the date on which the controller requests the additional information until the date on which it is received. This suspension mechanism distinguishes the GDPR’s response framework from the CCPA’s: under the CCPA, verification efforts must be completed within the running 45-day clock; under the GDPR, the clock may be paused while the identity question is being resolved.

The suspension is not automatic and does not arise merely because the controller has decided to ask for additional information. It is triggered by a genuine, objectively grounded doubt about the requestor’s identity, and the controller’s request for additional information must itself be proportionate. A controller that manufactures a pretext to suspend the clock — by claiming doubt where none exists — is acting in bad faith and risks challenge from both the data subject and a supervisory authority. Controllers should document both the basis for the doubt and the date on which additional information was requested, in order to maintain a clear record of the suspension period.

Manifestly Unfounded or Excessive Requests (Art. 12(5))

Where a request is manifestly unfounded or excessive — in particular where it is repetitive — the controller has two options: it may charge a reasonable fee that reflects the administrative costs of compliance, or it may refuse to act on the request. These are significant powers, and they are intentionally difficult to invoke: the burden of demonstrating that a request is manifestly unfounded or excessive rests with the controller, not the data subject. The mere fact that a data subject has submitted multiple requests, or that a request would require significant effort to honor, does not establish that it is manifestly unfounded or excessive. Controllers that reflexively invoke this provision in response to demanding but legitimate requests risk enforcement action from supervisory authorities, as well as the right of the data subject to lodge a complaint and seek judicial remedy under Articles 77 and 79.

Comparative Analysis

XII. Comparative Analysis: CCPA vs. GDPR

While the CCPA and GDPR share a common objective — ensuring that privacy rights are exercised only by those lawfully entitled to exercise them, without creating barriers so high that legitimate rights become effectively illusory — their approaches to achieving that objective differ in ways that matter for organizations subject to both laws.

The CCPA establishes a structured, rule-based framework with specific data-point thresholds and tiered certainty standards for each request type. This predictability is both a feature and a constraint: businesses know precisely what is required at each tier, but they also cannot deviate from those requirements downward even where the circumstances would seem to warrant a lighter touch. The GDPR, by contrast, establishes a principles-based framework in which the governing standard is proportionality in light of the specific context. This flexibility allows controllers to calibrate verification measures to the actual risk in each case, but it also places a greater burden on the controller to make and document that judgment correctly. A controller that misjudges the proportionality calculus — in either direction — faces regulatory exposure.

One of the most practically significant differences between the two frameworks is the treatment of the response clock in relation to verification. Under the CCPA, the 45-day clock begins running when the request is received and does not pause for verification: the business must both verify and respond within the same 45-day window, with a single 45-day extension available where genuinely necessary. Under the GDPR, the one-month clock may be suspended while the controller seeks additional identity information, providing a structural mechanism for managing the interaction between verification and response that the CCPA does not offer.

Both frameworks converge on the impermissibility of requiring government-issued identity documents as a standard, default requirement — the CCPA through its data minimization rules and the GDPR through its proportionality principle and the Dutch AP precedent. Both frameworks also converge on the principle that the process for exercising privacy rights must not be deliberately obstructed: the CCPA’s anti-dark-patterns requirement and the GDPR’s Article 12(2) obligation to facilitate the exercise of rights are expressions of the same underlying principle.

Practical Guidance

XIII. Practical Compliance Considerations

Document Your Verification Method

Under both frameworks, an undocumented verification approach is a significant source of regulatory exposure. The EDPB’s CEF 2024 Report specifically identified the lack of documented internal procedures for handling access requests as one of the seven leading challenges to full implementation of the right of access across EU controllers. Under the GDPR’s accountability principle, a controller that cannot demonstrate what its verification procedure is, how it applies it, and how it has trained its staff to implement it has failed a fundamental compliance obligation. Under the CCPA, the requirement to establish, document, and comply with a reasonable method is express, and the CPPA has signaled a willingness to examine request-handling processes in enforcement investigations. At minimum, a written verification policy should specify: which data points are used for each request type; which standard of certainty applies to each request type; how the risk-calibration determination for deletion requests is made; what the escalation process is for requests that cannot be straightforwardly verified; and how the business communicates with requestors when verification cannot be completed.

Avoid Systematic Use of Government-Issued Identity Documents

The convergence between the CCPA and GDPR on this point is striking, and the message is unambiguous: requiring government-issued identity documents as a standard step for all requests — or even for all requests of a particular type — is disproportionate, inconsistent with data minimization principles, and creates its own regulatory risk. This risk is not merely theoretical. Controllers that collect copies of passports, driver’s licenses, and national identity cards as part of routine request processing are aggregating sensitive biometric and identity data in a centralized location, creating both a regulatory compliance problem and a security risk. Identity documents should be reserved for the narrow subset of cases where other matching methods have demonstrably failed, the request type warrants a high degree of certainty, and there is no less intrusive alternative available. Where they are used, they must be handled securely and deleted promptly after the request is processed.

The Correction / Rectification Circularity Problem

Both frameworks present a structural challenge in the context of correction and rectification requests that is not always adequately addressed in published guidance. Where the consumer or data subject is seeking to correct the very information the business or controller would ordinarily use to verify their identity — a name, a date of birth, an address, an email address — the standard verification process is either impossible or circular: the organization cannot ask the data subject to confirm the accuracy of the information they are seeking to correct in order to establish that they are who they say they are. Businesses and controllers should identify alternative verification data points in advance and document how they will handle this specific scenario. Under the CCPA, the regulations expressly direct businesses to attempt verification using information that is not the subject of the correction request. Under the GDPR, the proportionality principle requires controllers to find the least intrusive means of verification that is adequate in the circumstances — which, in the context of a correction request, may require a different set of data points or a different verification method than would ordinarily apply.

Train Staff and Build Institutional Procedures

The EDPB’s CEF 2024 Report identified inadequate staff training as a systemic challenge across controllers subject to GDPR enforcement investigation. The observation that many organizations lack the internal procedures, the trained personnel, and the institutional knowledge necessary to handle data subject requests correctly is not merely an observation about regulatory non-compliance — it is a risk management observation. Requests that are handled inconsistently, delayed, or refused without adequate basis generate complaints, supervisory authority investigations, and reputational damage. Investment in staff training, documented escalation procedures, and periodic review of request-handling workflows is not merely a compliance expense; it is a material reduction in regulatory risk. Under the CCPA, the commercially reasonable standard implicitly requires that businesses have the organizational capacity to execute their stated verification methods — a verification policy that exists only on paper and is not operationalized in staff training and workflow design is unlikely to satisfy the standard under enforcement scrutiny.

Beware the Opt-Out/Verification Conflation

A recurring compliance error — particularly among businesses that have invested significantly in building privacy request portals — is the inadvertent application of verification requirements to opt-out requests submitted alongside or through the same channel as access or deletion requests. Under the CCPA, opt-out requests do not require a verifiable consumer request; imposing verification requirements on opt-out requests is a violation of the statute, not a compliance safeguard. Organizations should audit their request intake workflows to ensure that opt-out requests are routed and processed through a pathway that does not trigger verification requirements, while access and deletion requests are routed through the appropriate verification framework.

XIV. Key Citations Quick Reference