The Consent Lifecycle Under India's DPDPA 2023: Why DPDPA Consent Management Is No Longer a Checkbox
Here's the uncomfortable truth most organizations haven't fully absorbed yet: India's DPDPA 2023 didn't just add a new law to the compliance shelf. It changed the rules of engagement between businesses and their customers around personal data — permanently.
For years, "consent" meant one thing operationally: a checkbox during signup. You showed users some text, they clicked agree, you stored a timestamp somewhere in your CRM, and everyone moved on. Done. Auditable? Arguably. Defensible? Barely.
That model is now broken.
Under the DPDPA, consent isn't a moment in time. It's an ongoing relationship — one the customer can modify or exit at any point, and one you're legally obligated to honor in real time. The gap between how most organizations currently handle DPDPA consent management and what the law actually demands is, frankly, significant.
Let me walk through exactly what that lifecycle looks like — and what it takes to manage it correctly.
Stage 1: Notice — You Can't Skip This Step
Before you ask for consent, you have to give a Notice. And no, your existing privacy policy probably doesn't count.
The Notice under DPDPA has teeth. It must be written in plain language — not the kind that requires a law degree to parse. It must be purpose-specific, meaning you can't hide behind phrases like "to enhance your experience." It must clearly identify your organization, explain what data you're collecting, why you need it, and what rights the customer has.
The language must be one the customer actually understands — which has real implications if your user base spans multiple regions or languages.
The Notice isn't just a formality to get past. If your Notice is vague or incomplete, any consent obtained through it is potentially invalid. That's the foundational logic of consent management under DPDPA: you cannot get meaningful consent from someone who doesn't fully understand what they're agreeing to.
Stage 2: Consent Grant — The Metadata Matters as Much as the Click
Once you've given a valid Notice, you can request consent. The DPDPA is clear about what makes valid consent under Indian data protection law: it must be free (no coercion, no access bundled with unrelated conditions), informed (Notice first, consent second — not simultaneously), specific (tied to clearly defined purposes, not a blanket "agree to everything"), and unambiguous (a clear affirmative action — pre-ticked boxes don't qualify).
Most organizations get this part directionally right. Where they fall short is in what they capture alongside the consent.
Every consent event needs metadata: the timestamp, the exact Notice version shown, the purpose being consented to, the channel where it was collected, and a link to the customer's identity. Without this, you don't just have a compliance gap — you have no evidence that the consent ever happened in a valid form.
Storing "Y" in a database column is not DPDPA consent management. It's a flag.
Stage 3: Consent Management — Where Reality Gets Complicated
This is the part that catches most organizations off guard.
Capturing consent is the easy bit. Actually managing it — at scale, in real time, across an entire customer base — is a fundamentally different problem.
Think about what consent lifecycle management means for a loyalty program with ten million active customers and twenty distinct consent purposes. That's 200 million individual consent relationships to track, each potentially in a different state, each potentially changing at any time.
At any given moment, your systems need to answer questions like: Has this customer consented to promotional email? Have they withdrawn consent for analytics processing? Which version of the Notice did they accept? Is this specific data processing operation currently permitted?
These aren't questions you can answer with a lookup on a static database column. They require a queryable, accurate, real-time view of consent state — per customer, per purpose, per channel.
Most CRMs and marketing platforms aren't built for this. That's not a criticism; it's just not what they were designed to do. It's why purpose-built DPDPA consent management platforms exist.
Stage 4: Consent Withdrawal — The Real Test
If you want to understand whether an organization is actually compliant with India's data protection law, watch what happens when a customer withdraws consent.
Withdrawal is supposed to be as easy as giving consent in the first place. When it happens, processing for that purpose must stop immediately. If there's no other legal basis to retain the data, deletion workflows kick in. And critically, it's not enough to update the field in your primary system — every downstream application, marketing tool, analytics platform, and third-party processor relying on that consent must be informed and updated.
In practice, this means consent changes need to propagate in near real time across your entire data stack.
That's a non-trivial engineering problem. And failure here isn't just a technical oversight — it's a separate, independent violation under the DPDPA.
Stage 5: Audit and Evidence — Compliance Is What You Can Prove
This is the part organizations tend to think about last, and it's arguably the most important.
When the Data Protection Board comes calling — whether for a routine inquiry or in response to a complaint — what matters is not what your policies say. It's what your records show.
You need to be able to demonstrate, for any given customer, the complete history: when consent was granted, what Notice was shown, what purposes were accepted, whether consent was ever modified, when it was withdrawn, and what your systems did next. Every step in that chain needs to be preserved in a tamper-resistant, verifiable consent audit trail.
Append-only logs with cryptographic integrity aren't overkill here. They're the difference between being able to defend yourself in front of the Data Protection Board of India and having to take someone's word for it — including your own.
Why You Can't Manage This Manually
At a few thousand customers, you might be able to work around the gaps. At a few million, you simply cannot.
The volume and velocity of consent changes across a large customer base require purpose-built infrastructure. A proper DPDPA consent management solution needs four core capabilities:
A consent storage layer that handles millions of records without degrading
A real-time enforcement layer so applications verify permissions before processing
Event streaming to propagate changes instantly across every downstream system
An immutable audit log that produces clean evidence on demand
These aren't aspirational capabilities. They're the minimum viable infrastructure for operating a DPDPA-compliant data business at scale — whether you're in retail, fintech, hospitality, or healthcare.
Final Thought
The DPDPA has effectively made consent a product, something that needs to be engineered, maintained, and continuously operated, not just collected once and forgotten.
Organizations that invest in the right DPDPA consent management infrastructure early won't just be compliant. They'll have a defensible, customer-trusted data operation that becomes a genuine competitive asset over time.
The ones that continue treating it as a checkbox will find out eventually, usually at the worst possible moment — that the checkbox was never enough.
Ready to see how OneConsent handles the complete DPDPA consent lifecycle, from Notice to audit trail?
OneConsent is Easyrewardz purpose-built DPDPA consent management platform, designed for enterprises managing consent at scale.