If you operate across the EU, California and India, you do not get to pick one privacy law and generalise it to the others: the GDPR, CCPA/CPRA and India's DPDP Act are built on different applicability tests, different vocabulary and different rights mechanics, and treating them as interchangeable is how programs end up with gaps. The practical path is to map each law's trigger conditions against your actual data flows, then build one internal control set that satisfies the strictest applicable requirement for each function.
Why the differences are operational, not academic
Teams often start a "multi-jurisdiction" privacy program by writing one policy and hoping it covers everything. It rarely does, because the three regimes answer a different question:
- The GDPR asks: is this processing of personal data connected to the EU, regardless of your size or revenue?
- The CCPA/CPRA asks: does your business meet a specific threshold test, and are you dealing with California consumers?
- The DPDP Act asks: are you processing "digital personal data" of a person in India, with obligations that come into force on a rolling schedule set by rules, not all at once.
Get the applicability question wrong and everything downstream — your notices, your rights process, your contracts with vendors — is built on the wrong foundation. This is also the single most common gap our Global Data Privacy Fundamentals course sees in the field: teams assume "we're not that big" exempts them from GDPR, when GDPR simply doesn't use size as a trigger at all.
GDPR: scope-based, not threshold-based
Under Articles 2 and 3 of the GDPR, applicability turns on two tests, and either one alone is enough to bring you in scope:
Material scope (Article 2). The GDPR applies to the processing of personal data wholly or partly by automated means, and to non-automated processing that forms part of a filing system. There is no revenue, headcount or data-volume threshold — a two-person consultancy processing EU client data is in scope in the same way a multinational is.
Territorial scope (Article 3). The GDPR applies to processing carried out by an establishment in the EU (regardless of whether the processing itself happens in the EU), and separately to processing of personal data of individuals in the EU by organisations outside the EU, where that processing relates to offering goods or services to those individuals or to monitoring their behaviour. A US-based e-commerce site with no EU office can still be in scope if it markets to EU customers.
The consequence: you cannot use "we don't hit a size threshold" as a GDPR defence. The question is always whether the processing itself falls inside Article 2 or Article 3 — not how big you are.
CCPA/CPRA: threshold-based applicability
California's law works differently. Under the CCPA as amended by the CPRA, a "business" is only covered if it meets at least one of a defined set of thresholds — broadly: an annual gross revenue figure, a volume of California consumers'/households' personal information bought, sold or shared, or a share of revenue derived from selling or sharing personal information. A small business below all three thresholds is generally outside CCPA's direct obligations, even if it collects California residents' data.
This threshold model is a genuinely different design philosophy from the GDPR's scope-based approach, and it is why a US company can be confident it is "CCPA-exempt" while still being squarely inside GDPR territorial scope if it also serves EU customers. Check current thresholds on the California CPPA's FAQ page rather than relying on a number you read a year ago — thresholds and enforcement guidance are periodically updated.
India's DPDP Act 2023 and the DPDP Rules 2025: phased commencement
India's Digital Personal Data Protection Act 2023 introduces its own vocabulary and rights framework, but a critical operational point is that it does not all take effect at once. The Act itself was notified in stages, and the DPDP Rules 2025 set out further operational detail and their own commencement schedule. This matters in practice: an obligation described in the Act's text may not yet be enforceable on the date you are building your compliance plan, and rules that clarify consent-manager registration, breach notification timing or children's data processes may commence later than the core Act provisions.
Do not assume the DPDP Act is either "not yet in force" or "fully in force" — verify current effective dates against the MeitY DPDP Act 2023 page and the DPDP Rules 2025 gazette notification for your specific obligations before you finalise a launch date for any India-facing control.
A framework for building one program across all three
- Map your data flows to each law's trigger test separately. Don't ask "are we in scope for privacy law" — ask "do we meet Article 3 GDPR territorial scope," "do we cross a CCPA/CPRA threshold," and "are we processing digital personal data of a person in India" as three distinct questions, because the answers can differ business unit by business unit.
- Build a terminology crosswalk. Contracts, notices and internal training all need consistent language. Keep a single reference table (below) so legal, engineering and support teams use the same terms when they mean the same role.
- Identify the strictest applicable rule for each control. For example, if GDPR requires a documented lawful basis and DPDP leans on consent as the primary basis, build your consent capture flow to satisfy both rather than running parallel systems.
- Design one rights-request intake process, then route by jurisdiction. The channel can be common; the timelines, verification steps and response content should branch based on which law applies to the requester.
- Update vendor contracts against the strictest applicable flow-down obligations. Use a structured process like the vendor privacy assessment template so you're not renegotiating contracts law-by-law.
- Set a recheck cadence. Thresholds, rules and effective dates change. Put a quarterly review on the calendar rather than treating this as a one-time mapping exercise.
Worked example
A 60-person B2B SaaS company based in the US sells workflow software to customers in the US, UK and India, with a handful of EU-based enterprise clients. Its data footprint: US-hosted infrastructure, an India-based support team using a CRM, and a marketing site with EU-directed advertising campaigns.
- GDPR: The EU-directed marketing campaigns and the presence of EU enterprise clients mean the company is offering services to individuals in the EU — Article 3 territorial scope applies, regardless of the company's size.
- CCPA/CPRA: The company checks its revenue and California-consumer-record volume against current CPPA thresholds. If it's below all three, CCPA's direct business obligations don't apply yet — but the company still tracks this because growth could cross the threshold within a year.
- DPDP Act: The India-based support team processes digital personal data of individuals in India (both employees and customers), bringing DPDP into scope — but the company checks the current rules-commencement schedule before assuming every DPDP obligation (like consent-manager mechanics) is already enforceable.
The resulting program: one consent and notice framework built to GDPR's lawful-basis standard (which also satisfies DPDP's consent requirements), one rights-intake form with jurisdiction-based routing, and a threshold-monitoring checkpoint tied to the CCPA/CPRA review.
Common failure modes
- Assuming small size exempts you from GDPR — it doesn't; only the absence of Article 2/3 triggers does.
- Assuming CCPA's threshold model applies elsewhere — most other regimes, including GDPR and DPDP, don't use revenue/headcount tests.
- Treating DPDP as either fully live or fully dormant, instead of checking which specific provisions and rules have commenced.
- Using GDPR vocabulary ("controller," "processor") in contracts governed by California or India law without cross-referencing the correct local terms.
- Building three separate rights-request processes instead of one intake with jurisdiction-based branching, which multiplies maintenance cost and inconsistency risk.
Comparison table
| Dimension | GDPR (EU) | CCPA/CPRA (California) | DPDP Act 2023 + Rules 2025 (India) |
|---|---|---|---|
| Applicability trigger | Material scope (Art. 2) + territorial scope (Art. 3) — no size threshold | Defined revenue/volume/revenue-share thresholds for "business" | Processing of digital personal data of a person in India; phased commencement of provisions and rules |
| Core roles | Controller, processor | Business, service provider, third party | Data fiduciary, data processor |
| Primary legal basis model | Lawful basis required for each processing activity (consent is one of several) | Notice-and-choice; opt-out of sale/share rather than opt-in consent for most processing | Consent-centric, with defined "legitimate uses" as an alternative in specific circumstances |
| Individual rights | Access, rectification, erasure, restriction, portability, objection | Know, delete, correct, opt out of sale/sharing, limit use of sensitive PI | Access, correction, erasure, grievance redressal, nomination (for incapacity/death) |
| Operational implication | Build lawful-basis documentation and DPIAs for higher-risk processing | Build threshold-monitoring and opt-out mechanics (e.g., "Do Not Sell or Share") | Build consent-capture and verify current commencement status of specific obligations before relying on them |
Do this next
- Confirm your organisation's applicability status against each law independently — don't reuse one jurisdiction's answer for another.
- Build or update your terminology crosswalk so contracts and notices are internally consistent.
- Check current CPPA threshold figures and current DPDP Rules commencement status before finalising any compliance deadline.
- Consolidate your rights-intake process into one form with jurisdiction-based routing.
- Take our readiness assessment to see where your current program has jurisdiction-specific gaps.
This article is educational and does not constitute legal advice; applicability tests, thresholds and effective dates change, and you should confirm your specific obligations with qualified counsel in each relevant jurisdiction.
Official sources and further reading
Privacy Practice Lab publishes educational and technical guidance. Nothing on this site constitutes legal advice, and it should not be relied on as a legal determination for your organisation.