Key Takeaways
- GDPR and DPDPA share data types but operate on fundamentally different enforcement philosophies
- Most Indian companies were “compliant,” but only to a European framework never built for India’s consent model
- The audit process itself, done wrong, becomes a breach vector
- A DPDPA compliance audit is a continuous engineering posture, not a one-time certificate
Before India had its own data protection law, most serious companies here did one of two things: they followed GDPR because their international clients demanded it, or they followed nothing at all.
The GDPR crowd felt covered. Privacy policies drafted, consent banners deployed, data processing agreements signed. Boxes ticked.
Then the Digital Personal Data Protection Act, 2023 arrived. And suddenly that entire compliance stack had a quiet, uncomfortable problem, it was built for Europe. Not for a country where Aadhaar is the backbone of identity verification and UPI now processes over 23 billion transactions every single month.
When I started looking for GRC tools built ground-up for Indian law, the answer was: nothing. A contact who had just entered the space put it plainly, “Tools exist, but everything is heavily customised, you configure it to your use case, a few things automate, most things stay manual.” That confirmed what I already suspected. Nobody had built the thing that should exist.
Indian Companies Were Already “Compliant,” Just to the Wrong Law
Here’s something the compliance industry doesn’t say loudly enough: GDPR does cover phone numbers, financial data, biometrics, and consent. It covers them seriously. In some areas, like biometric data classified as “Special Category” under Article 9, GDPR is actually stricter than DPDPA.
So the problem was never that Indian companies ignored data protection. The problem was they followed a European philosophy and assumed it translated to Indian law. It doesn’t.
Think of it this way: GDPR is a rights-first, individual-heavy framework with six different legal bases for processing data. DPDPA is consent-centric, government-heavy, and built specifically for how India’s digital economy actually works. Same ingredients, completely different recipe.
The numbers show exactly how this played out. Pre-DPDPA, roughly 65–70% of Indian IT and BPO firms had strong GDPR alignment, because their European clients contractually required it. Among domestic MSMEs and startups? That number dropped to 15–20%. Not because they were careless. Because there was no Indian law pushing them, and GDPR was someone else’s regulation.
Honestly, following GDPR gave Indian companies false confidence, and compliance vendors let them believe it because it was easier to sell.
When DPDPA arrived, it didn’t just add new rules on top of GDPR. It introduced a completely different operating model:
- Consent is the only gateway. GDPR gives you five other legal bases including “Legitimate Interest,” a flexible clause Indian compliance teams loved. DPDPA’s equivalent, “Legitimate Uses,” is a narrow, government-defined list. Your marketing team’s interpretation doesn’t qualify.
- The age of consent is strictly 18. GDPR lets member states set it anywhere from 13 to 16. Every Indian app that onboarded teenagers using EU thresholds is now sitting on a compliance gap.
- Breach notification covers every breach not just high-risk ones. Under GDPR you notify authorities within 72 hours if there’s significant risk. Under DPDPA you notify the Data Protection Board for every breach, regardless of severity. Most engineering teams aren’t built for this.
- Consent Managers, a regulatory-registered intermediary, exist under DPDPA with no GDPR equivalent at all.
The companies that treated GDPR compliance as a substitute for DPDPA readiness didn’t make a bad decision; they made a reasonable one given what existed. But the law has changed, and the gap is real.
The Audit Process Itself Is a Breach Vector
Here’s something nobody in the Indian compliance industry wants to say out loud.
Most DPDPA “audits” right now are Excel checklists emailed to a consultant. Your system architecture, consent flow descriptions, logging configurations: described in plain text, attached to a Gmail thread, shipped off to someone in another city.
The audit itself becomes a potential breach.
This isn’t theoretical. During my time supporting cyber investigations with the Gurugram Cyber Police, a recurring pattern in data leak cases was that companies couldn’t even produce basic records when asked, not because they were hiding anything, but because their “compliance process” lived in a shared Google Drive folder managed by a consultant who had since left. The audit artefacts, the very documents meant to prove compliance, were the most poorly secured thing in their entire infrastructure.
But it gets worse. Some companies, genuinely trying to do the right thing, upload source code snippets and server configuration files to foreign-hosted SaaS compliance platforms to prove they’re compliant. And while DPDPA’s cross-border data restrictions are still pending full government notification as of mid-2026, the fundamental contradiction remains: you’re exposing your architecture to systems outside your control, to comply with a law about protecting Indian user data.
What most organisations don’t know yet
DPDPA gives your users hard statutory rights. They can query their data, withdraw consent, and demand deletion, which means you need an actual technical pipeline to respond with documented timelines. A “contact us” email isn’t a compliance posture. It’s a liability waiting to be triggered.
The GRC professional I spoke to when building this confirmed it: tools exist in the market, but they’re heavily manual, heavily customised, and built around the assumption that a human consultant will interpret the output. Nobody had built something where the audit runs automatically, locally, and tells you exactly where you stand without a consultant in the middle.
Why a DPDPA Compliance Audit Must Run Client-Side
This is the architectural decision that drove everything at Kryptasys.
If you’re scanning your codebase, consent flows, or log infrastructure for compliance gaps, that engine must run inside your environment. Not on our servers. Not routed through a US or EU data centre. Yours.
DPDP Shield’s audit engine runs locally in your browser using WebAssembly. Your configuration data, your log samples, your consent architecture: none of it leaves your machine during the audit. Only your structural compliance score reaches our systems. The sensitive context that generated that score stays with you.
You can’t claim data sovereignty in your privacy policy while your audit tool is uploading your system config to Frankfurt. For a DPDPA compliance audit specifically, client-side execution isn’t just a feature. It’s the only architecture that doesn’t contradict the law you’re trying to comply with.
A DPDPA Compliance Audit Is Engineering, Not a Certificate
Most compliance vendors are selling legal comfort. A PDF report. A logo on your website.
That certificate means nothing if your Nginx logs are printing Aadhaar numbers in plaintext at 3am on a Tuesday.
Real DPDPA compliance audit isn’t an event. It’s a continuous engineering posture. Consent flows change when you ship new features. Logging configs drift when engineers debug production incidents. Third-party SDKs update quietly and start capturing data they didn’t before.
The DPDP Board hasn’t started active enforcement yet. The full compliance deadline is May 13, 2027. That window won’t last. And when enforcement begins, the companies that survive won’t be the ones with the nicest certificates. They’ll be the ones who built audit into their engineering pipeline, running continuously, locally, and without shipping their architecture somewhere else to get the answer.
If you’re still running your DPDPA compliance audit off a Google Form, you’re not compliant. You’re just not caught yet.
Ready to know your real score?
Run your first DPDPA compliance audit, locally, privately, in minutes.
Try DPDP Shield Free →