A global SaaS product can have one database and three different privacy regimes applying to different users.
That creates a tempting shortcut:
Build for the strictest law and call everything compliant.
Sometimes that works for security controls.
It does not reliably work for privacy rights, legal bases, notices, or opt-out mechanisms.
GDPR, India's DPDP, and California's CCPA overlap heavily in principle and diverge in implementation.
The high-level comparison
| Area | GDPR | DPDP | CCPA |
|---|---|---|---|
| Core concept | Personal data / data subjects | Digital personal data / Data Principals | Personal information / consumers |
| Lawful basis | Multiple bases | Consent + specified legitimate uses | Different notice/opt-out structure |
| Access | Yes | Yes, as prescribed | Yes |
| Deletion | Yes, with exceptions | Yes, subject to conditions | Yes, with exceptions |
| Correction | Yes | Yes | Yes |
| Portability | Yes | Not equivalent to GDPR | Certain access/portable disclosure rights |
| Marketing opt-out | Depends on lawful basis | Depends on processing basis | Explicit sale/sharing opt-out framework |
| Automated decision rules | Specific GDPR framework | Different framework | Emerging / context-dependent |
This is a simplified comparison. Specific obligations depend on scope, role, jurisdiction, and applicable exemptions.
Consent is where teams get into trouble
A GDPR flow may rely on a lawful basis other than consent.
A DPDP processing activity may need consent or a Section 7 legitimate use.
A CCPA business may have disclosure and opt-out obligations that are not expressed as a GDPR-style consent requirement.
Therefore:
“User opted out”
must have a jurisdictional meaning.
Do not hard-code one universal boolean called consent=false and expect it to represent every privacy preference globally.
Rights need a policy engine
The three regimes do not give identical rights.
GDPR users can have access, rectification, erasure, restriction, portability and objection rights, subject to conditions.
DPDP Data Principals have access-related, correction/erasure, grievance and nomination rights, alongside consent withdrawal where consent is the basis.
CCPA provides rights including know, delete, correct, opt out of sale/sharing, and limit certain uses/disclosures of sensitive personal information for covered businesses.
Your system should route requests based on:
User
→ jurisdiction
→ applicable law
→ request type
→ verification
→ workflow
The vendor layer also differs
A vendor that is acceptable under one framework may still require a different contractual approach under another.
Your processor inventory should therefore capture:
- Role
- Jurisdiction
- Contract
- Data location
- Subprocessors
- Deletion
- Legal restrictions
Use common evidence wherever possible
A good architecture avoids building three different evidence systems.
For example, one consent event can store:
User
Purpose
Notice version
Timestamp
Action
Jurisdiction
Source
The legal interpretation is different, but the underlying event can be reused as evidence.
Where teams fail
One global policy copied to every market.
One rights workflow for every law.
Treating CCPA opt-out as identical to consent withdrawal.
Using GDPR terminology as if it were universal.
Where Privra fits
Privra keeps the technical evidence layer unified while applying jurisdiction-specific privacy rules on top.
That matters for global products: build the infrastructure once, but do not flatten the law into one checkbox.