The DPDP Act requires consent infrastructure, not consent UI. Most Indian businesses have a checkbox that flips a database flag and stops there — while downstream systems keep processing anyway.
The Button That Does Nothing
Somewhere on your website, there is a checkbox. It says something like "I agree to the Privacy Policy and Terms of Use." A customer ticks it, submits the form, and your database writes a true to a column called consent or marketing_opt_in. That flag sits there. Your email tool reads it. Your WhatsApp campaigns ignore it entirely because they pull from a different list. Your analytics pixel was firing before the checkbox was even rendered.
That checkbox is not consent under the DPDP Act. It is a UI element with no infrastructure behind it.
This is not a theoretical problem. A PwC India survey across 3,233 consumers and 186 organizations found that only 9% of Indian organizations have a comprehensive understanding of the DPDP Act (PwC India, October 2024). Most businesses we talk to assume they are already compliant because they have a privacy policy page and a checkbox. They are not even close.

The DPDP Rules 2025 were gazetted in November 2025. Full substantive enforcement — consent standards, breach notification, data retention, erasure rights — goes live May 2027. That is thirteen months from now. And MeitY has already proposed compressing the compliance timeline for Significant Data Fiduciaries from 18 to 12 months.
The clock is not approaching. It is running.
The Consent Problem Is Not Legal. It Is Architectural.
Here is what "consent" actually means under DPDP, and why your current setup fails.
Consent must be purpose-specific. You cannot bundle marketing consent with analytics consent with transactional messaging consent into one checkbox. The MeitY Business Requirements Document for Consent Management Systems explicitly requires granular, per-purpose consent interfaces. Pre-populated consent fields are prohibited.

Consent must be as easy to withdraw as to give. One tap in, one tap out. Most Indian businesses have no withdrawal mechanism at all — or they have a button that flips a flag in the CRM without stopping the email sequences, the WhatsApp campaigns, or the retargeting pixels that are already running.
This is not hypothetical. Microsoft’s own documentation for Dynamics 365 Customer Insights acknowledges that opting out via the real-time marketing preference center **does not update the legacy DoNotEmail field** on the Contact record. Any outbound workflow checking the old field continues sending. This is documented, acknowledged behavior running in production at thousands of companies right now.
The WhatsApp gap is worse. TRAI’s Do Not Disturb rules cover calls and SMS — not WhatsApp. Businesses that migrated their marketing from SMS to WhatsApp carried over their SMS consent lists, but existing SMS consent does not transfer to a new channel under DPDP. The businesses we have seen running WhatsApp campaigns from personal WhatsApp Web accounts have no consent audit trail at all. No timestamps, no purpose records, no withdrawal logs.
WhatsApp banned 92.36 million Indian accounts in 2024 for spam and bulk messaging (Commsrisk, 2025). That is 7.7 million accounts per month. The platform is already enforcing before the law does.

Consent state fragmentation is the structural failure. A typical Indian business stores consent signals in at least three to five places: the CRM, the email tool, the analytics platform, the push notification service, the WhatsApp API. When a customer withdraws consent in one system, the other four do not know. There is no standardized DPDP consent signal format for cross-platform propagation. Each downstream system requires its own API call to update.
When Zomato announced sharing customer phone numbers with restaurants after opt-in in November 2025, the structural flaw was immediate: once a phone number is shared with a restaurant, there is no mechanism to un-share it. The data has left Zomato’s system. Withdrawal becomes physically impossible. That directly violates Section 6(4) of the Act.
What You Can Do Monday Morning
You do not need a consent management platform to start. You need visibility into where you are right now.
Map every place you collect personal data
Open your website, your WhatsApp Business, your lead forms, your payment flows. For each one, answer: what exactly does the customer agree to? Where is that agreement stored? Can you produce a timestamped record of it?
Most businesses discover they have four or five collection points and zero of them produce a record that would survive an audit.
Track consent withdrawal end-to-end
Have someone on your team submit a test lead through every channel. Then have them request opt-out. Follow the opt-out signal through every system it should reach. Check your email tool — did it stop? Check your WhatsApp lists — is the number still there? Check your analytics — are events still firing for that user?
The businesses we have tested this with find the same thing: withdrawal stops exactly one system. The rest keep running.
Separate your consent purposes
If you have a single "I agree" checkbox that covers marketing, analytics, and transactional messaging, that is the first thing to unbundle. Create separate consent captures for each purpose. Even a simple Tally form with three separate checkboxes, feeding into a Google Sheet with timestamps, is better than a bundled Terms of Use checkbox feeding into nothing.
Check your WhatsApp setup
If you are using personal WhatsApp or WhatsApp Web for business messaging, you have no consent infrastructure at all. The WhatsApp Business API requires channel-specific opt-in, stores data within India, and processes withdrawal with a confirmed opt-out message. Moving to the API is the minimum viable step. Your consent rates will drop. The businesses we have helped move to granular consent typically see transactional WhatsApp opt-in land around 50-55%, and promotional consent closer to 20-25%. That drop is real. But the alternative is operating on fabricated consent that does not hold up.
Where It Gets Harder
Everything above is visibility work. It tells you where you stand. The hard part is making consent a living piece of infrastructure rather than a static database flag.

Under the DPDP Rules, consent withdrawals must be processed immediately, without manual intervention. That means event-driven architecture — a withdrawal event triggers a webhook, the webhook hits a message bus, and every downstream consumer updates simultaneously. CRM suppression lists, analytics configurations, ad platform audiences, WhatsApp campaign lists, AI training data pipelines. All of them. In real time.
The MeitY BRD specifies consent records must include a JWS-signed artifact with schema versioning, purpose IDs, collection method, and an immutable audit hash. Those records must be retained for seven years — but the personal data they reference must be deleted on purpose fulfillment or withdrawal. The audit artifact survives; the data does not. Designing a data lifecycle where the proof of consent outlives the data it authorized is not a configuration toggle. It is a data architecture decision.
By November 2026 — per the DPDP Rules 2025 compliance timeline — every data fiduciary must integrate with registered Consent Managers via real-time API. Zero Consent Managers are formally registered today. The registration window has not opened yet. Foreign platforms like OneTrust and TrustArc are explicitly excluded from registration. The Indian consent manager platforms are building, but the integration surface between your systems and theirs does not exist yet — no standard webhook schema, no consent signal format, no reference implementation.
And then there is breach notification. Under DPDP, every breach must be reported to the Data Protection Board and all affected individuals "without delay." Not just high-risk breaches like GDPR. Every breach. CERT-In’s existing 6-hour reporting directive sees only 10% compliance across Indian companies, per industry assessments as of early 2026. The notification routing alone — identifying which data principals were affected, which consent purposes were active, which downstream systems held copies — requires infrastructure that most businesses have not even scoped. The businesses we have seen scope this work — even ones with full-time engineering teams — find the notification routing alone takes weeks to map.

For a 20-person business running on Zoho CRM, WhatsApp Business, and Google Analytics, the consent propagation graph and the breach notification routing are where the real design decisions live.
← All posts


