The Consent Lifecycle Under DPDPA: Grant, Manage, Revoke — In One Platform

Most Businesses Have Built Half the System

Walk into almost any Indian organisation that has started its DPDPA preparation, and you'll find some version of the same thing: a consent checkbox at sign-up, maybe a marketing opt-in toggle somewhere in account settings, and a legal team that's satisfied something has been done.

That's the grant step. It's one stage in a five-stage lifecycle. The other four are where most businesses are currently exposed — and where the Data Protection Board will look first when a complaint lands.

The DPDPA 2023 treats consent not as a gate you clear at registration but as an ongoing, dynamic relationship between your organisation and every customer whose data you hold. It can be granted, modified, and revoked at any time. Every state change must be recorded. Every record must be enforceable in real time. And the full history must be auditable for years, not because it's good practice, but because it's the evidence, you'll need to defend yourself.

Stage 1: Notice Comes Before Everything

Before you collect a single byte of personal data, a Notice must be provided. Not a privacy policy buried three links deep in your footer. A clear, plain-language document — available in the language the Data Principal actually reads — that tells them what data is being collected, the specific purpose, who the Data Fiduciary is, and what rights the customer has.

The word "specific" is doing real work here. A Notice that says "we may use your data to improve your experience" is not a valid Notice under DPDPA. The purpose must be named. If you're collecting email for marketing communications, it says that. If you're collecting location data for personalised offers, it says that. Vague language doesn't protect you — it invalidates every consent collected under it.

Section 5 of the Act governs Notice requirements. The DPDP Rules 2025 go further, requiring multilingual support for organisations serving users across India's linguistic regions. If your consent infrastructure currently delivers one English-language Notice across all users, that's a gap worth addressing before enforcement begins.

Stage 2: What a Valid Consent Grant Actually Requires

Section 6 sets four conditions that every consent must satisfy: it must be free, informed, specific, and unambiguous.

Free means no bundling. You cannot make access to your core service conditional on consent for non-essential processing like marketing analytics or third-party data sharing. Informed means the Notice was provided and understood before the consent action. Specific means one consent item per processing purpose — marketing emails, SMS campaigns, personalisation, partner data sharing are separate items, each independently revokable. Unambiguous means an affirmative action: a tap, a click, a signature. Pre-ticked boxes and passive acceptance don't qualify.

When the consent grant happens, four things must be recorded: the timestamp, the exact version of the Notice the customer was shown, the channel through which consent was collected (web, mobile app, in-store, call centre), and the identity of the Data Principal. That record is your legal evidence that the grant was valid. If you can't produce it on demand, the consent might as well not exist.

Stage 3: Managing Consent at Scale Is a Technical Problem

This is the stage that surprises organisations when they actually sit down and calculate the numbers.

A loyalty program with 5 million members and 10 consent purposes has 50 million consent records to manage. Add channel-level granularity and you're well above 100 million. Every one of those records must reflect current status — not last week's batch update. Every processing system that touches customer data must be able to query consent status before it operates, in milliseconds, without failure.

A field in your CRM that says "opted in to marketing" doesn't do this. It has no per-purpose granularity. It has no audit history. It can be edited. It doesn't propagate changes to downstream systems in real time. It will not hold up under a Data Protection Board investigation.

What's actually required is a dedicated consent storage layer with quarriable records per customer per purpose, backed by a real-time enforcement cache that sits between your processing systems and their data access. When consent status changes, that cache updates immediately — before the next processing operation runs.

Stage 4: Withdrawal Is Not Optional and Not Slow

Section 6(4) gives every Data Principal the unconditional right to withdraw consent at any time. The Act doesn't say "within a reasonable period." It doesn't say "subject to operational constraints." The withdrawal takes effect immediately.

And it must be as easy as the original grant. If consent was granted with a single tap on a mobile screen, withdrawal must also be a single tap — not a journey through settings menus, a customer support call, or a written request form.

When withdrawal happens, three things follow. First, your consent record updates. Second, your enforcement cache invalidates — so no downstream system can process data for that purpose after the withdrawal. Third, if there's no other legal basis to retain the data that was processed under the withdrawn consent, deletion is triggered. Non-compliance with a withdrawal request is an independent violation under DPDPA. It's not a downstream consequence of the original consent failure — it's a fresh one.

Stage 5: The Audit Trail Is Your Only Defence

Every grant, every modification, every withdrawal must be preserved in an immutable audit log. Not a database record that can be edited by an admin. Not a log file that gets overwritten. An append-only event store where every consent event is written once and never modified — with a cryptographic hash chain that makes any tampering immediately detectable.

This is what you show the Data Protection Board when they ask for evidence of compliance. A consent event log that says: this customer was shown Notice version 3.2, granted consent for marketing on this date via the mobile app, withdrew consent for third-party data sharing on this later date, and here is every state the record has ever been in.

Without this, you have no compliance evidence. You have assertions.

The Infrastructure Reality

None of this is manageable manually at any meaningful scale. An organisation with a million customers, ten consent purposes, and real-time grant and revoke operations needs four things working together: a consent event store that accepts millions of records reliably, a real-time enforcement cache that answers consent queries in sub-milliseconds, an event streaming layer that propagates consent changes to every downstream system immediately, and an audit log architecture that was built to be immutable — not retrofitted to look that way.

This is precisely what a purpose-built consent management platform provides. Not a CRM with a privacy module bolted on. Not a homegrown database table with a few boolean flags. Infrastructure designed around the lifecycle, from Notice through to deletion.

The consent lifecycle is not one compliance task among many. It's the backbone everything else depends on — DSAR fulfilment, breach response, grievance management, vendor contracts. Build it correctly and the rest of the program has something to stand on.

OneConsent manages the complete consent lifecycle — Notice delivery, per-purpose grant, real-time enforcement, withdrawal, and tamper-proof audit — across millions of customer records and unlimited tenants.