CCPA vs GDPR: What SaaS Companies Need to Know About Both

If your SaaS product has users in both California and the European Union, you are operating under two of the world's most significant privacy laws simultaneously. The California Consumer Privacy Act (CCPA), as amended by the California Privacy Rights Act (CPRA), and the EU General Data Protection Regulation (GDPR) both regulate how you collect, process, and share personal data — but they approach the problem from fundamentally different directions.

Understanding where they overlap and where they diverge is essential for building a compliance programme that satisfies both without duplicating effort.

Different Starting Points

GDPR is a rights-based framework rooted in the European tradition of data protection as a fundamental right. It requires a lawful basis for every act of personal data processing. If you cannot articulate a legal ground — consent, contract, legitimate interest, legal obligation, vital interest, or public task — you cannot process the data at all.

CCPA takes a market-regulation approach. It does not require a lawful basis for collection. Instead, it gives California residents specific rights: the right to know what data you collect, the right to delete it, the right to opt out of its sale or sharing, and the right to non-discrimination for exercising those rights. The default is that you can collect and process data freely, but consumers can pull back specific permissions.

This philosophical difference shapes everything downstream — from your consent mechanisms to your privacy policy structure to your internal data inventory.

Who Is Covered

GDPR applies to any organisation that processes personal data of individuals in the European Economic Area, regardless of where the organisation is based. A SaaS company in San Francisco with three EU customers is subject to GDPR.

CCPA applies to for-profit businesses that collect personal information of California residents and meet at least one of three thresholds: annual gross revenue over $25 million, buying/selling/sharing the personal information of 100,000 or more consumers or households, or deriving 50% or more of annual revenue from selling or sharing personal information.

For most growing SaaS companies, the GDPR trigger comes first — a single EU user puts you in scope. CCPA kicks in once you cross a revenue or volume threshold.

What Counts as Personal Data

GDPR defines personal data broadly: any information relating to an identified or identifiable natural person. This includes obvious identifiers (name, email, IP address) and less obvious ones (cookie IDs, device fingerprints, location data, behavioural profiles).

CCPA uses a similarly broad definition — personal information is information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked to a particular consumer or household. Notably, CCPA extends to household-level data, not just individuals.

In practice, both definitions cover the same data for most SaaS companies. If your data inventory satisfies GDPR's definition, it will cover CCPA's scope as well.

Consent and Opt-Out Models

This is where the two regimes diverge most sharply.

GDPR requires affirmative, informed consent before data processing for many common activities — particularly cookie tracking, marketing communications, and sharing data with third parties. Consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes are explicitly prohibited. You must also make it as easy to withdraw consent as it was to give it.

CCPA does not require prior consent for data collection from adults. Instead, it gives consumers the right to opt out of the sale or sharing of their personal information after collection. You must provide a "Do Not Sell or Share My Personal Information" link on your website. For consumers under 16, CCPA does require opt-in consent (and parental consent for those under 13).

For SaaS companies subject to both: implement GDPR-grade consent as your baseline, since it is stricter. Then layer CCPA's opt-out mechanism on top for California residents. This typically means a cookie consent banner that meets GDPR standards globally, plus a "Do Not Sell or Share" link in your footer for CCPA compliance.

Data Subject Rights Compared

Both frameworks grant individuals rights over their data, but the specific rights differ:

• Right to access/know — both GDPR and CCPA grant this
• Right to deletion — both grant this, though GDPR calls it the "right to erasure" and has broader exceptions
• Right to portability — GDPR grants this; CCPA grants a narrower version (right to receive data in a portable format)
• Right to correction — both grant this (CPRA added this to CCPA)
• Right to opt out of sale/sharing — CCPA-specific; GDPR handles this through the consent model
• Right to restrict processing — GDPR-specific; CCPA has a narrower "limit use of sensitive personal information" right
• Right to object to processing — GDPR-specific
• Right to non-discrimination — CCPA-specific; GDPR achieves a similar result through the consent framework

If you build a data subject request (DSR) workflow that handles access, deletion, correction, and portability, you will satisfy the core requirements of both regimes.

Enforcement and Penalties

GDPR penalties can reach up to 4% of annual global turnover or EUR 20 million, whichever is higher. Enforcement is carried out by national Data Protection Authorities (DPAs). High-profile fines regularly reach hundreds of millions of euros.

CCPA penalties are lower in statutory terms — up to $2,500 per unintentional violation and $7,500 per intentional violation, enforced by the California Attorney General and the California Privacy Protection Agency. However, CCPA also provides a private right of action for data breaches involving unencrypted or unredacted personal information, with statutory damages of $100 to $750 per consumer per incident.

For SaaS companies, the practical risk from CCPA often comes from the private right of action in data breach scenarios rather than regulatory enforcement. GDPR risk comes from regulatory enforcement, which can be triggered by a single complaint to a DPA.

Building a Unified Compliance Programme

Rather than running two parallel compliance tracks, build a single privacy programme that meets the higher standard in each area:

• Data inventory: map all personal data processing activities with enough detail to satisfy both GDPR's Records of Processing Activities (Article 30) and CCPA's disclosure requirements
• Privacy policy: write a single policy that covers GDPR's transparency requirements (Articles 13–14) and CCPA's required disclosures (categories collected, purposes, third-party sharing, consumer rights)
• Consent mechanism: implement GDPR-grade consent as the global default, with CCPA's opt-out link for California visitors
• DSR workflow: build one workflow that handles access, deletion, correction, portability, and opt-out — then route requests based on the requester's jurisdiction
• Vendor management: ensure your data processing agreements (DPAs) with sub-processors meet GDPR's Article 28 requirements; these will also satisfy CCPA's service provider contract obligations

Key Takeaways

• GDPR requires a lawful basis before processing; CCPA allows collection by default but grants opt-out rights
• GDPR triggers from a single EU user; CCPA triggers at revenue or volume thresholds
• Build to the stricter standard in each area and you will satisfy both regimes
• A single data inventory, privacy policy, and DSR workflow can serve both frameworks
• The biggest risk from CCPA is the private right of action for data breaches, not regulatory fines

*Need to map your data processing activities for GDPR and CCPA? Start a free gap analysis at trynorma.com and Norman will identify exactly where your privacy programme has gaps.*

See your compliance gaps in minutes

Norman AI automates gap analysis across ISO 27001, SOC 2, GDPR, and NIS 2. No consultant required.