Should a global product apply GDPR-style opt-in everywhere or run per-region defaults, and why does 'GDPR everywhere' still not make it CCPA compliant?
answer
- strictest default is not a superset
- California's own artefacts
- links, signals, notices, clocks
- the cost of consent rates
- a common core plus adapters
basics
~20 sEither can work, but 'GDPR everywhere' is not a CCPA superset: California still needs its own notice contents, opt-out links or signal handling, a 45-day clock, a 24-month request log and under-16 sale rules, so a strict core needs California adapters.
solid answer
~50 sThere is no single right answer; it is a trade-off. **GDPR-style opt-in everywhere** simplifies engineering and messaging and reduces the risk of misclassifying a user's location, at the cost of lower opt-in rates in markets that permit opt-out models. **Per-region defaults** keep more processing on in California and elsewhere, at the cost of jurisdiction detection and more code paths. Either way, GDPR practices do **not** automatically satisfy the CCPA as amended by the CPRA. California still requires its own **notice at collection** contents (categories, purposes, sold or shared, retention per category; 1798.100(a)), "Do Not Sell or Share" and "Limit" links or the alternative signal route (1798.135), processing valid **opt-out preference signals** where the business sells or shares (11 CCR 7025(b)), the **45-day** response clock (1798.130(a)(2)(A)), a **24-month** request log (11 CCR 7101) and service-provider contract terms (7051). The workable pattern is a strict common core with regime adapters.
go deeper
Recall that the GDPR and the CCPA use different models, so satisfying one does not automatically satisfy the other.
List the California artefacts a GDPR programme does not produce: notice format, opt-out links or signals, 45-day clock, 24-month log.
Design the adapter split so regime-specific obligations are isolated from shared controls, and test both paths.
Own the default-policy decision: weigh revenue dependence, detection reliability and future regimes, and document why the choice was made.
## The decision A product sold in the EU and in California must satisfy the **GDPR** and the **CCPA as amended by the CPRA**. The strategic choice is whether to set **one global default**, usually the stricter GDPR-style opt-in for non-essential processing, or to run **per-region defaults** that follow each regime's own model. Neither is mandated; each has costs. | Option | Gains | Costs | |---|---|---| | GDPR-style opt-in everywhere | one code path for defaults; consistent messaging; less exposure if a user's location is misread | lower consent rates where opt-out would be lawful; still needs California-specific artefacts | | Per-region defaults | processing that California permits by default stays on there | jurisdiction detection; more code paths; risk of applying the wrong model to a user | | Strict core plus regime adapters | shared controls where the regimes overlap, targeted work where they do not | needs a clear map of which obligations are regime-specific | ## Why "GDPR everywhere" is not a CCPA superset The CPRA borrowed GDPR **principles** (minimisation, purpose limitation, correction, a dedicated regulator) but kept California's **architecture**. A GDPR programme does not produce these California artefacts: 1. **Notice at collection in California's format**: categories of personal and sensitive personal information, purposes, whether each is **sold or shared**, and **retention per category** (Civil Code 1798.100(a); 11 CCR 7012). 2. **Opt-out surfaces**: "Do Not Sell or Share My Personal Information" and "Limit the Use of My Sensitive Personal Information" links, a combined link, or the alternative route through opt-out preference signals (1798.135(a)-(b)). 3. **Signal handling**: a business that sells or shares must process a valid **opt-out preference signal** as an opt-out request (11 CCR 7025(b)). A consent banner does not replace this. 4. **California clocks and records**: 10 business days to acknowledge and 45 days to respond (11 CCR 7021; 1798.130(a)(2)(A)), and a request log kept **24 months** (7101). 5. **Contract terms** for service providers and contractors in California's form (1798.100(d); 7051), which a GDPR Art. 28 processor agreement does not automatically meet. 6. **Minors' data**: no selling or sharing of data of consumers known to be **under 16** without affirmative authorization (1798.120(c)). 7. **Terminology**: "sale" and "sharing" are defined terms whose disclosures the privacy policy must list; GDPR notices do not use them. The reverse fails too: a California-style opt-out design gives **no** GDPR lawful basis (Art. 6(1)). ## A defensible architecture - **Common core:** one purpose register; retention schedules per data category; one request pipeline tagged by regime; consent and opt-out state stored as distinct fields. - **GDPR adapter:** lawful basis per purpose, consent proof and withdrawal (Art. 7), Art. 30 records. - **California adapter:** notice formats, opt-out links or signal handling, sale and sharing classification of each recipient, the 45-day and 24-month clocks. - **Default policy:** a product decision on top of the core, revisited per market, not baked into data models. ## How a principal frames the call - What fraction of revenue depends on processing that California permits by default but the EU does not? - How reliable is location or residency detection, and what is the cost of getting it wrong in each direction? - How many more regimes are coming, and will adapters scale better than per-region forks? ## A worked choice Take a subscription product whose advertising revenue is a small share of the total: 1. The team chooses **opt-in everywhere** for advertising and analytics beyond what the service needs, because the lost revenue is small and one default is cheaper to operate. 2. It still builds the **California adapter**: if any selling or sharing remains for California consumers, the opt-out links or signal route and signal processing ship; the notice at collection lists categories, purposes, sold-or-shared status and retention in California's form. 3. It keeps **consent** and **opt-out** as separate stored states, so a Californian who consented to advertising cookies and then sends an opt-out signal is treated as opted out of sale and sharing; the regulations let the business flag the conflict and ask again for consent (11 CCR 7025(c)(3)). 4. It records the decision and the revenue assumptions, and revisits them when a new market or regime arrives. ## Misconceptions - That the strictest regime is automatically a superset of the others. - That a consent banner satisfies California's opt-out signal rules. - That a GDPR processor agreement is a CCPA service-provider contract.
- Does a GDPR Art. 28 processor agreement satisfy the CCPA's service-provider contract requirements?Not automatically. The CCPA requires specific terms, such as a ban on selling or sharing, specific business purposes, a ban on combining data outside the relationship, compliance-monitoring rights and notice if the vendor can no longer comply (1798.100(d); 11 CCR 7051(a)). Many overlap with Art. 28 terms, but each must be checked, and without them the vendor is not a service provider (7050(e)).
- If a business obtains GDPR-style consent for advertising cookies from Californians, must it still process opt-out preference signals?If it sells or shares personal information, yes: 11 CCR 7025(b) requires processing a valid signal as an opt-out request. Consent collected for one regime does not switch off the other regime's opt-out obligations.
saying these in an interview costs you the question
- Applying the GDPR everywhere automatically satisfies the CCPA.
- A consent banner replaces handling opt-out preference signals in California.
- A GDPR processor agreement is automatically a CCPA service-provider contract.
- A CCPA-style opt-out design is enough for an EU launch.
- The law mandates one global default for multi-region products.