CCPA and GDPR in One Codebase: Where the Engineering Diverges

Compliance

The headlines say CCPA is GDPR-lite. The implementation says otherwise. Consent, data minimisation, and vendor obligations all require different code paths if you want defensible compliance for both.

By Arjun Raghavan, Security & Systems Lead, BIPI · June 13, 2024 · 7 min read

When CCPA passed in 2018, every privacy team I knew told their engineers it was basically GDPR for California. The CPRA amendments in 2020 made the comparison even more popular. After helping six SaaS companies build privacy operations that satisfy both regimes simultaneously, I can say the comparison is misleading enough to cause expensive rework if you take it literally.

The two regulations protect similar rights and use similar vocabulary. The implementation paths in your codebase are different in ways that matter for cookie consent, marketing automation, vendor contracts, and breach notification. Building a single pipeline that satisfies both is possible, but it requires explicit decisions, not a default of doing whatever GDPR says.

Consent and the opt-in opt-out gap

GDPR Article 6 requires a lawful basis for processing. For most marketing and analytics use cases, that lawful basis is consent obtained before processing begins. The model is opt-in. Cookie banners must default to off, with affirmative action required to enable non-essential tracking.

CCPA flips the default. Processing personal information for most business purposes is allowed; consumers have the right to opt out of sale or sharing. CPRA tightened this for sensitive personal information, where you need an explicit opt-in for certain uses, but the baseline remains opt-out. A California consumer can interact with your site for months before they exercise their rights.

The engineering question is whether your consent management platform supports both modes simultaneously based on user geography. Most CMPs claim they do; about half implement it correctly. We tested one well-known vendor and found that their CCPA opt-out signal was being recorded but not propagated to two of the three downstream marketing tools the customer integrated. That is a multi-million dollar exposure if a regulator runs the same test.

Data minimisation is real for one and aspirational for the other

GDPR Article 5(1)(c) requires data minimisation as a principle. Regulators have used this against companies that collected fields they did not need for the stated purpose. The CNIL has issued fines specifically for collecting birth dates when only age was required.

CCPA does not have an equivalent first-class principle. CPRA introduced a purpose limitation requirement and a retention disclosure obligation, but the enforcement posture is different. California regulators care about transparency and consumer rights more than about whether you should have collected the field in the first place.

For engineering, this means GDPR work pulls you toward fewer fields and shorter retention. CCPA work pulls you toward better disclosure of the fields you have and stronger machinery for honoring rights requests. Companies that implement only what GDPR requires end up doing fine on CCPA. Companies that implement only what CCPA requires get embarrassed when GDPR audits arrive.

Vendor obligations diverge in the contract

GDPR Article 28 requires a data processing agreement with every processor. The DPA has prescribed contents: scope, duration, nature, purpose, subject matter, types of data, categories of subjects, and obligations including audit rights. There is a template and most enterprise SaaS vendors offer one.

CCPA uses a different vocabulary. Vendors are either service providers, contractors, or third parties. The contractual requirements differ by category. A service provider contract must prohibit sale, prohibit retention beyond the business purpose, and require flow-down to subprocessors. A third-party arrangement requires its own opt-out mechanism.

1. Inventory every vendor that touches personal data and classify them under both regimes simultaneously.
2. Map your DPA against the CCPA service provider checklist; about 60 percent of standard DPAs are missing the prohibition on combining data, which is a CCPA-specific requirement.
3. For every third-party arrangement, build a separate opt-out flow that does not depend on your service provider opt-out.
4. Run an annual review tying contract category to actual data flows. Vendors graduate from service provider to third party more often than legal teams expect.

Breach notification math

GDPR is 72 hours to the supervisory authority and without undue delay to data subjects when there is a high risk. CCPA has no breach notification rule directly; it relies on California's pre-existing breach notification statute, which is in the most expedient time possible. In practice, plaintiffs and the AG treat 30 days as the soft ceiling, but the statutory damages provision in CCPA makes breaches financially catastrophic regardless of speed.

Run your incident response playbook with the GDPR clock as the binding constraint. If you can hit 72 hours for GDPR, you will hit California's standard with margin. The reverse is not true.

When to handle them separately

We default to a unified pipeline that handles both regimes through configuration rather than parallel code. The exception is consent, where the opt-in opt-out divergence is fundamental enough that bolting it together creates more bugs than it saves. Maintain two consent paths, geo-routed at the edge, with a shared backend for honoring requests. That is the pattern that has held up across every audit we have shepherded.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.