GDPR vs CCPA — when each applies to your app

If you're operating a SaaS or consumer app from anywhere in the world, you probably need to comply with both GDPR and CCPA — they reach you based on customer location, not company location. The good news: the requirements overlap significantly, and a single compliance architecture can satisfy both. Here's what triggers each, what they actually require, and where they diverge.

The trigger question for each

GDPR and CCPA reach companies based on customer location and business activity — not on where the company is incorporated or where its servers are. The two trigger tests:

Most B2C SaaS apps with any traction in either market are in scope of both. The CCPA's revenue threshold means very early-stage apps may be CCPA-exempt while still being GDPR-bound — but anyone past Series A typically clears both.

Side-by-side comparison

• Consent model — GDPR requires opt-in (default-off, explicit consent). CCPA is opt-out (collect by default, give consumers right to refuse). This is the single biggest operational difference.
• Lawful bases — GDPR Art. 6 lists six bases (consent, contract, legal obligation, vital interests, public task, legitimate interests). CCPA doesn't have an equivalent — you can process by default unless the consumer opts out.
• Special categories — GDPR Art. 9 sets a higher bar for sensitive data (health, religion, sexual orientation, biometrics). CCPA/CPRA added "sensitive personal information" with similar but narrower scope.
• Data subject rights — Both grant access, deletion, and portability. GDPR adds: rectification, restriction, objection, and rights re: automated decision-making. CCPA adds: right to opt out of sale and right to limit use of sensitive PI.
• Response time — GDPR: 1 month (extendable to 3). CCPA: 45 days (extendable to 90).
• Penalties — GDPR: up to €20M or 4% of global annual turnover, whichever is higher. CCPA: $2,500 per violation (unintentional) or $7,500 (intentional or involving minors).
• Private right of action — GDPR: yes, but most enforcement is via DPAs. CCPA: limited — only for data breaches involving unencrypted/unredacted personal info, $100–$750 per consumer per incident.
• DPO requirement — GDPR: required for public bodies and certain processors. CCPA: no equivalent.

The consent model difference, in practice

This is the part that trips up US founders most often. GDPR's opt-in default means you cannot collect, process, or share most personal data until the user has explicitly consented. Tracking pixels firing on page load — the default behavior of GA4, Meta Pixel, TikTok, and others — is a GDPR violation by default, unless you've gated them behind consent.

CCPA's opt-out default means you can collect and process by default, but you must (a) disclose what you're doing, (b) give consumers a "Do Not Sell or Share My Personal Information" link, and (c) honor opt-out requests. The Global Privacy Control (GPC) signal is now legally binding under CCPA — your site must respect it as an opt-out signal.

Where they overlap (and a single program suffices)

Despite the model differences, a well-designed compliance architecture can satisfy both:

1. Privacy policy — describe data collection, purposes, sharing, rights. Same document works for both, with location-conditional sections.
2. Consent / preference center — implement an opt-in flow for EU users and an opt-out flow for CA users. Modern banner libraries (Cookiebot, OneTrust, Termly, or a custom React hook) handle both with location detection.
3. Data subject request (DSAR) process — one endpoint to receive requests, one workflow to fulfill them. Different response time clocks but the same underlying process.
4. Sub-processor management — both regimes require disclosing and managing data processors. One vendor list works for both.
5. Breach notification — GDPR requires 72-hour notification to DPAs for high-risk breaches. CCPA's private right of action covers breach scenarios. One incident-response runbook covers both.

Where they diverge meaningfully

Four points where you can't merge the programs without losing compliance:

1. Pixel and cookie defaults — for EU users, default off. For CA users (without other regime in play), default on with opt-out. Some teams default off globally for simplicity; this is conservative but reduces revenue from ad attribution.
2. Data minimization — GDPR's principle is strict (collect only what's necessary for the stated purpose). CCPA has a weaker version (proportional to purpose). EU-targeted features may need to collect less data than CA-targeted features.
3. Cross-border transfers — GDPR requires Standard Contractual Clauses (SCCs) and a Transfer Impact Assessment for EU-to-US transfers. CCPA has no equivalent (PI can flow freely to wherever you process it).
4. Children — GDPR Art. 8 requires parental consent for under-16 (member states can lower to 13). CCPA requires opt-in for under-16 (vs default opt-out for adults). COPPA (separate US federal law) reaches under-13 with stricter requirements.

Other state laws that piggyback on CCPA

Since CCPA passed in 2018, 19 other US states have enacted similar consumer-privacy laws — Colorado, Connecticut, Virginia, Utah, Iowa, Indiana, Tennessee, Texas, Montana, Oregon, Delaware, Maryland, Minnesota, Nebraska, New Hampshire, New Jersey, Rhode Island, Kentucky, and Maine as of 2026. Most have lower thresholds than CCPA (typically 100K residents instead of $25M revenue OR 100K) but require similar things.

Operationally, building a CCPA-compliant program at the strictest level (Colorado and Virginia are both stricter than CCPA in some respects) gets you most of the way to compliance in all 20 states. No equivalent of GDPR's harmonized one-stop-shop exists in US state privacy law — you handle requests state-by-state, but the underlying requirements rhyme.

Decision tree

1. Do you have any EU users? → GDPR applies. Build opt-in consent + DSAR + SCCs for transfers.
2. Do you have California users AND meet a threshold? → CCPA applies. Add the "Do Not Sell" link, honor GPC, run the opt-out flow.
3. Do you have users in any of the other 19 state-privacy-law states? → Use the CCPA framework, with minor adjustments (mostly disclosure language and sensitive-PI definitions).
4. Do you handle health, financial, biometric, or children's data? → Add the specialty regimes (HIPAA, GLBA, BIPA, COPPA). These often have stricter consent requirements that override CCPA's opt-out defaults.
5. Do you only have a small US footprint and no EU users? → CCPA may not yet apply (revenue threshold). Most founders should build the architecture before triggering, not after.

Bottom line

Most apps with traction need both GDPR and CCPA compliance. The consent model is the biggest operational divergence (opt-in for EU, opt-out for CA), but a single banner library, a single privacy policy with conditional sections, and a single DSAR endpoint handle both. The diligence cost of building this is modest — typically 1–2 weeks of work — and is dramatically cheaper than retrofitting after an enforcement action. None of this is legal advice — for a specific jurisdictional analysis, talk to a privacy attorney.