GDPR vs CCPA: Key differences for business owners building apps

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.

European regulators have imposed over EUR 7.1 billion in total GDPR fines since 2018, according to DLA Piper's 2026 survey. On the US side, the California AG has settled seven CCPA enforcement actions, including a $2.75 million settlement with Disney and $1.2 million with Sephora. Both regimes are actively enforced - and missing requirements in either can kill an enterprise deal.

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

"When we build for both markets, we implement GDPR's opt-in model as the baseline and layer CCPA's opt-out logic on top. The mistake teams make is building two separate consent systems. One system with jurisdiction-aware configuration is always the right answer." - Ashit Vora, Captain at RaftLabs

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. The IAPP reports that DPAs collectively receive over 100,000 complaints annually.

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.

"The 70% overlap between GDPR and CCPA is real, but it's the 30% that bites teams. Different consent models, different verification standards for deletion requests, different definitions of what counts as a 'sale.' Map both laws before you design your consent architecture, not after." - RaftLabs Engineering Team

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

Questions to ask your development partner

1. "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.

2. "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.

3. "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.

4. "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.

5. "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.