InsightData Protection
DPDP compliance is a product decision before it is a legal one
Most DPDP programmes fail at the same point: the legal team writes a notice for data flows the product team never documented. The fix is to sequence the work the other way around.
- 3
- Workstreams that matter
- 18 mo
- Typical remediation runway
- 1
- Owner per data domain
Start with retention, not notice
Retention is where legacy exposure lives. Every table you cannot justify keeping is a liability that no consent language will cure, and deletion pipelines take longer to build than policies take to write.
Consent is an interface problem
Granular, withdrawable, purpose-linked consent has to be represented in the product's data model. If consent state is not a first-class field that services read at query time, the notice is decorative.
Processors are your perimeter
Analytics, support tooling and model vendors are where data actually leaves. Contractual flow-down is necessary but insufficient — you need an inventory that engineering, not legal, maintains.
What good looks like
One accountable owner per data domain, a retention schedule enforced in code, and a breach playbook that has been rehearsed once. Everything else follows from those three.
More from Clarié
- Case study
Fintech ·
Licensing a co-lending stack across four NBFC partners
A consumer lending platform needed a structure regulators could read in one pass. We rebuilt the flow of funds and the paper around it.
- Case study
SaaS / Enterprise Tech ·
Merger clearance for two overlapping enterprise platforms
Two vertical SaaS players with adjacent customer bases. The theory of harm was obvious — so we addressed it in the filing rather than the hearing.
- Insight
Gaming & Esports ·
Skill, chance and the tax question underneath both
The classification debate has moved from constitutional argument to fiscal exposure. Product design is now the primary defence.