GDPR vs CCPA Data Requests: Deadlines, Scope, and Differences

The main differences between GDPR and CCPA data requests are the deadline, the scope of what you must disclose, and who has the right to ask. The GDPR gives people in the EU and UK one month to receive a copy of their personal data, while the CCPA gives California consumers 45 days and focuses on the categories and specific pieces of personal information collected, sold, or shared. Both are access rights, but the mechanics and the underlying frameworks differ.

This is general information, not legal advice. Below we compare the two regimes on the points that matter when you actually handle a request.

The core rights compared

Deadlines: one month vs 45 days

Under the GDPR, you respond within one month of receipt, extendable by up to two further months for complex or numerous requests, with notice to the requester in the first month. Under the CCPA, you respond within 45 days, including verification time, extendable once by a further 45 days with notice. In both cases the clock starts on receipt, so intake speed matters. The full mechanics are in the DSAR response deadline guide. Whichever applies, automated deadline tracking keeps the right countdown in view.

Scope: what you actually disclose

This is where the two rights feel different in practice.

Under the GDPR

A data subject access request is broad. The person is entitled to a copy of their personal data and to supplementary information: why you process it, the categories involved, who it is shared with, how long you keep it, and where it came from if not from them. The emphasis is on a full copy of the data itself. Meeting this is a core part of GDPR compliance.

Under the CCPA

The California right to know leans toward disclosing the categories of personal information you collected, the sources, the business purpose, the categories of third parties you shared it with, and, on request, the specific pieces of personal information. It is closely tied to concepts of selling and sharing data that do not have a direct GDPR equivalent. Meeting it is central to CCPA compliance.

What is the same

Despite the differences, the operational work overlaps almost entirely, which is why one workflow can serve both:

• Verify identity first. Both regimes require you to be reasonably sure who is asking before you disclose, which is the job of identity verification.
• Find the data everywhere. Both require you to locate a person's data across your systems, which is what personal data discovery does.
• Protect other people. Both require you to avoid disclosing third-party personal data, so redaction applies in each.
• Keep a human in control. A person should approve the final disclosure under either law.

Because the heavy lifting, discovery and review, is shared, most teams run a single DSAR process and adjust the response language and disclosure detail to the applicable law.

Fees and refusals

Both regimes make access free in the ordinary case. The GDPR lets you charge a reasonable fee or refuse only where a request is manifestly unfounded or excessive, and the CCPA limits how often a consumer can make free requests. Neither should be treated as a routine escape hatch. The withholding rules are covered in the DSAR exemptions guide.

Identity verification differs in emphasis

Both laws require you to confirm who is asking, but the CCPA is more explicit about matching the verification standard to the sensitivity of the data and the risk of the disclosure. A request for the specific pieces of personal information generally warrants a higher degree of certainty than a request for categories alone. Under the GDPR you must be reasonably satisfied of identity and may ask for confirming information, but you should not use verification as a way to obstruct a genuine request. In both cases the practical answer is the same: verify proportionately and promptly, because a slow check burns the deadline. That balance is what identity verification is built to strike.

Records and accountability

Both regimes reward good record-keeping. If a requester disputes your response or a regulator asks questions, you want to show what you disclosed, what you withheld, and why. Keep a log of the request, the verification step, the systems searched, the redactions applied, and the approval. That record is your evidence that the request was handled properly, and it is easier to produce when the whole workflow runs in one place rather than across scattered inboxes and spreadsheets.

Which one applies to you

It depends on who is asking and where they are, and many organizations are subject to both. A California consumer might invoke the CCPA; an EU or UK resident invokes the GDPR. A business with no European office can still be caught by the second one, and GDPR for US companies sets out when Article 3 reaches across the Atlantic and when you need an EU representative. Rather than build two separate operations, it is usually simpler to run one intake and discovery workflow and shape the response to the law that applies. That way a request from either regime hits the same reliable steps, and you decide the disclosure detail at the drafting stage.

California is also no longer the only US law to plan around. Twenty states with data privacy laws now have a comprehensive statute in effect, most of them following Virginia's template rather than California's, with a 45-day clock and an appeal right the CCPA does not have. If you are building a process for the CCPA, it is worth building it to cover the other nineteen at the same time.

Want to handle both without maintaining two processes? Obtainer runs one workflow for intake, discovery, and review, tracks the GDPR one-month and CCPA 45-day clocks, and shapes the response to the applicable law. DSAR automation keeps you in control of what gets redacted and approved before disclosure.