Most enterprises still think DPDPA is a legal compliance project. DPDPA Act and DPDPA Rules
Most enterprises still think DPDPA is a legal compliance project.
That’s the first mistake.
DPDPA is actually a data architecture stress test disguised as regulation.
The moment you start mapping “personal data,” ugly truths appear fast:
- Nobody knows where all customer data lives
- ERP exports sit in random folders for years
- Teams copy production data into test systems
- Consent tracking is fragmented or fake
- AI copilots quietly ingest sensitive data
- Vendors have more access than employees
- Retention policies exist only in PowerPoint
One telecom-scale dataset can spread across:
Oracle EBS, CRM, HRMS, WhatsApp workflows, analytics lakes, RPA bots, ticketing tools, GenAI copilots, vendor portals, and shadow Excel kingdoms built since 2011.
DPDPA simply shines a flashlight into the basement.
The interesting part?
Most companies are trying to solve this with policy documents.
But the real battle is operational:
- RBAC models
- identity governance
- data lineage
- masking
- consent orchestration
- auditability
- deletion workflows
- AI governance
- cross-border controls
Legal teams write the rulebook.
IT inherits the war.
The biggest surprise for me:
AI adoption is accelerating DPDPA pain exponentially.
Because GenAI systems hate clean boundaries.
They absorb context from everywhere.
And enterprises historically have terrible data hygiene.
That combination becomes radioactive fast.
The companies that survive this well won’t necessarily have the best compliance teams.
They’ll have the cleanest data plumbing.
DPDPA may look like regulation on paper.
Underneath, it’s really India forcing enterprises to grow up architecturally.