GDPR vs CCPA: Key Differences for Business Owners Building Apps

What Matters
- -GDPR uses opt-in consent (ask before collecting); CCPA uses opt-out (collect by default, let users opt out of sales/sharing)
- -GDPR applies to any company handling EU data regardless of size; CCPA only kicks in at $25M+ revenue or 100K+ California consumers
- -GDPR fines can hit 4% of global revenue; CCPA allows private lawsuits for data breaches at $100-$750 per consumer
- -Both laws give users the right to access and delete their data, but the mechanics and timelines differ
- -If your app serves both markets, build for GDPR first (stricter) then layer CCPA-specific requirements (opt-out mechanism, GPC support)
A SaaS company based in Austin built their product for the US market. CCPA compliance was on the roadmap. Then a London-based enterprise customer wanted to sign a six-figure annual contract - but only if the product was GDPR-compliant.
The engineering team assumed GDPR was "basically CCPA but for Europe." It isn't. They spent the next three months rebuilding their consent system from opt-out to opt-in, adding data portability exports, implementing a right-to-erasure pipeline that cascaded across 12 services, and hiring a DPO.
GDPR and CCPA protect user privacy. But they do it in fundamentally different ways. If your app serves both markets, you need to understand where they align, where they diverge, and how to satisfy both without building two separate systems.
The Side-by-Side Comparison
GDPR vs CCPA / CPRA
If you serve both jurisdictions, build the stricter GDPR foundation first, then add the California-specific opt-out and disclosure layer.
The Five Critical Differences
1. Consent Model: Opt-In vs. Opt-Out
This is the fundamental difference that affects your entire app architecture.
GDPR: You cannot collect or process personal data until the user explicitly opts in. No pre-checked boxes. No implied consent. No "by using this site you agree" banners. The user must take a clear, affirmative action to consent - and that consent must be granular (separate consent for analytics, marketing, third-party sharing).
CCPA: You can collect and use personal data by default. The user's right is to opt out of data sales and sharing, not to prevent collection. You still need to disclose what you collect (notice at collection), but you don't need to ask permission first.
What this means for your app: If you serve both markets, you need geography-aware consent logic. EU users see an opt-in consent banner that blocks data collection until they consent. California users see a "Do Not Sell or Share" option but their data is collected from the first pageview.
2. Who's Covered: Everyone vs. Threshold-Based
GDPR: Applies to any organization of any size that processes personal data of EU residents. A one-person startup and a Fortune 500 company face the same obligations.
CCPA: Only applies to for-profit businesses meeting at least one threshold: $25M+ annual revenue, 100K+ California consumers/households annually, or 50%+ revenue from data sales.
What this means: Small businesses serving EU customers still need GDPR compliance. Small businesses with California customers may not trigger CCPA. But growing past the thresholds means sudden CCPA obligations - plan ahead.
3. Enforcement Mechanism: Regulatory vs. Lawsuits
GDPR: Enforced by national data protection authorities (DPAs) in each EU member state. Fines can reach 4% of global annual revenue. The largest fine to date was 1.2 billion euros against Meta.
CCPA: Enforced by the California Attorney General and the California Privacy Protection Agency (CPPA). Per-violation fines are smaller ($2,500-$7,500). But CCPA's private right of action allows consumers to sue directly for data breaches involving non-encrypted personal information - $100-$750 per consumer per incident.
Why CCPA's private right of action matters more than it looks: A data breach affecting 100,000 California consumers at $750 per consumer is a $75 million class action exposure. Several multi-million dollar settlements have already been reached under this provision. In some scenarios, CCPA's breach liability exceeds GDPR's fine structure.
4. Data Definition: Individual vs. Household
GDPR: Protects data that identifies a "natural person" - a specific individual.
CCPA: Protects data that identifies a "consumer or household." Household-level data - information about a shared address, a family's purchasing patterns, or internet activity from a shared device - is personal information under CCPA even if it doesn't identify a specific person within the household.
What this means for your app: If you aggregate data at the household level (common in e-commerce, real estate, and advertising), that data has CCPA protections that GDPR doesn't cover.
5. Data Sale vs. Data Processing
GDPR: Regulates all "processing" of personal data - a broad term covering collection, storage, use, sharing, and deletion.
CCPA: Specifically regulates "selling" and "sharing" of personal information. CCPA's definition of "sale" is broader than a cash transaction - it includes any exchange for "valuable consideration." Sharing data with an ad network for retargeting counts as a sale.
What this means for your app: GDPR consent covers all processing activities. CCPA opt-out specifically covers sales and sharing. Your app may need to track which data flows constitute "sales" under CCPA separately from general data processing.
How to Comply with Both
The practical approach: build for GDPR first, then layer CCPA-specific requirements on top.
Step 1: Build the GDPR Foundation
GDPR is stricter, so meeting GDPR requirements covers approximately 70% of CCPA requirements automatically:
- Consent management (GDPR's opt-in covers CCPA's disclosure requirements)
- Data subject rights (access, deletion, correction, portability - both laws require these)
- Data inventory and mapping (both laws need you to know what data you have and where)
- Security controls (encryption, access controls, logging - both laws expect reasonable security)
- Data processing agreements (GDPR calls them DPAs; CCPA requires service provider contracts)
Step 2: Add CCPA-Specific Requirements
On top of the GDPR foundation, add:
- Opt-out mechanism - "Do Not Sell or Share My Personal Information" link and functionality
- GPC signal detection - Detect and honor Global Privacy Control browser signals
- Geography-aware consent - EU users get opt-in consent flow; California users get opt-out notice + functionality
- CCPA-specific disclosures - Categories of data collected, categories sold/shared, categories of third parties
- Sensitive data limitation - "Limit the Use of My Sensitive Personal Information" mechanism (CPRA addition)
- Verified consumer requests - Identity verification for California consumer requests
- Non-discrimination - Make sure opt-out consumers aren't treated differently in pricing or service quality
Step 3: Handle the Edge Cases
Users who travel: An EU resident visiting California is covered by both laws. A California resident visiting Europe is covered by both laws. Your system needs to handle users whose geographic context changes.
Users with VPNs: You can't perfectly determine user location. Don't try to be clever - if a user claims GDPR or CCPA rights, honor them regardless of detected location.
Business customers: GDPR applies to all data subjects. CCPA (after CPRA amendments) now covers employee data and B2B contact data. Your compliance framework needs to cover internal data, not just customer-facing data.
Architecture for Dual Compliance
| Component | How It Serves Both Laws |
|---|---|
| Consent management system | Stores per-user consent state with jurisdiction awareness. EU users: opt-in required. CA users: opt-out available. Others: applicable law. |
| Data subject rights portal | Unified request handling for access, deletion, correction, portability. Routes to appropriate response workflow based on jurisdiction. |
| Data inventory | Maps all personal data by type, purpose, storage location, and third-party recipients. Serves both GDPR Article 30 records and CCPA disclosure requirements. |
| Privacy policy | Single policy with jurisdiction-specific sections. California consumers see CCPA disclosures. EU users see GDPR-specific information. |
| Third-party data flow controls | Server-side logic that blocks data transmission to third parties based on consent state (GDPR) or opt-out state (CCPA). |
| Audit logging | Records consent grants/withdrawals, data access, deletion requests, and opt-out events for both regulatory frameworks. |
Questions to Ask Your Development Partner
-
"Have you built apps that comply with both GDPR and CCPA simultaneously?" - This is more complex than single-regulation compliance. Look for experience with geography-aware consent and dual privacy frameworks.
-
"How do you handle the opt-in vs. opt-out difference technically?" - The answer should involve server-side consent state management with geography detection, not just different cookie banners.
-
"How do you handle users whose jurisdiction changes?" - An EU user moving to California, or a California user traveling to the EU. The partner should have a thoughtful answer.
-
"What consent management platform do you recommend?" - Tools like OneTrust, Cookiebot, or Osano handle multi-jurisdiction consent. Your partner should recommend one and explain the integration approach.
-
"How do you handle GPC signals alongside GDPR consent?" - GPC is a CCPA requirement that doesn't exist in GDPR. The partner should explain how both consent mechanisms coexist.
Your Dual Compliance Checklist
- Map user geography (where are your users? which laws apply?)
- Build GDPR opt-in consent management as the foundation
- Add CCPA opt-out mechanism ("Do Not Sell or Share") for California users
- Add GPC signal detection and enforcement
- Build unified data subject rights handling (access, delete, correct, port)
- Create a privacy policy covering both GDPR and CCPA disclosures
- Set up geography-aware consent logic (different flows for EU vs. CA vs. other)
- Map all third-party data flows and classify as processors/service providers
- Sign DPAs (GDPR) and service provider agreements (CCPA) with all vendors
- Test consent flow for EU users (nothing fires before opt-in)
- Test opt-out flow for California users (data sales stop on opt-out)
- Test GPC signal handling (data sales stop when GPC is detected)
- Test data deletion across all systems and service providers
- Document data processing activities for both GDPR Article 30 and CCPA disclosures
Building for two privacy laws sounds twice as hard. In practice, the 70% overlap means it's closer to 1.3x the effort of building for one. Start with GDPR, layer CCPA, and you're covered for the two largest privacy enforcement regimes in the world.
Frequently asked questions
If your app has EU users and meets CCPA thresholds (California users + $25M+ revenue or 100K+ consumers), yes. The good news: about 70% of the technical requirements overlap. Building for GDPR first gives you most of the foundation for CCPA. The main additions for CCPA are the opt-out mechanism, GPC signal support, and CCPA-specific disclosures.
Related Articles
App Compliance Guide (Pillar)
Read articleGDPR Compliance for Apps
Read articleCCPA & CPRA Compliance Guide
Read articleFurther Reading
Related posts

App Compliance Laws Every Business Owner Should Know Before Building
GDPR, HIPAA, PCI DSS, SOC 2 - if you're building an app, the wrong compliance miss can cost millions. Here's every regulation you need to know, mapped by geography, industry, and data type.

GDPR Compliance for Apps: What Business Owners Must Know
GDPR isn't a European problem - it applies to any app that collects data from EU residents. Here's what the law requires, how it affects your app's architecture, and what to ask your development team before they write a line of code.

CCPA & CPRA Compliance: California Privacy Laws for App Builders
California's privacy laws apply to far more businesses than most realize. If you have 50K+ California users or $25M+ revenue, CCPA/CPRA compliance isn't optional. Here's what the law requires and how it affects your app.