Consent under DPDP

Audience: founders, product, growth, ops, marketing · Last reviewed: March 2026

Consent is not just a checkbox problem. Under DPDP, it is a workflow design problem involving language, timing, purpose, downstream systems, and whether the business actually behaves the way the screen suggests.

What official text means in practice

The safe starting point is to read the Act itself and then translate it into operational questions. The legal point is not only that consent exists. The practical point is that consent should be clear enough for a real person to understand, specific enough for a team to implement honestly, and supported by records good enough to survive internal review later.

That means product, marketing, support, and ops teams should all care. A beautifully worded consent line does not help if lifecycle campaigns, CRM enrichment, analytics, or vendor workflows quietly drift beyond what was actually presented to the user.

What good consent looks like

• the purpose is explained in plain language instead of vague legal filler
• the request appears at the point where the user can understand the context
• separate purposes are not hidden inside one overloaded prompt
• the privacy notice and the product behavior match each other
• the business can later prove what wording, design, and version were shown

Where teams usually get it wrong

• Bundling too many purposes together under one checkbox or button.
• Using soft, fuzzy language such as “improve your experience” when the real use is lead scoring, remarketing, profiling, or broad analytics.
• Collecting consent in the product, then letting other teams reuse the data for adjacent campaigns or tooling without review.
• Keeping no reliable record of the notice text, form version, or event timestamp.
• Treating withdrawal as an email unsubscribe problem instead of a broader systems change.

A practical review checklist

1. List every place where personal data is collected: signup, checkout, lead forms, demos, support, referrals, and mobile permissions.
2. Write the exact purpose for each collection point in one sentence of plain English.
3. Check whether the consent language shown to users matches that sentence.
4. Map which internal systems and vendors receive the data after collection.
5. Confirm the log you keep: version shown, timestamp, user identifier, channel, and any withdrawal event.
6. Test whether support can explain how a person withdraws consent and what happens next.

Questions product and growth teams should ask

• Are we asking for consent because this workflow really needs it, or because we have not clarified the lawful basis properly?
• Would a normal user understand why we want this data right now?
• If we changed the copy, design, or default settings last month, do our logs still show which version applied to each user?
• If consent is withdrawn, which tools must stop using the data: email, ads, CRM, analytics, support, or all of them?
• Can we show a reviewer the full chain from collection screen to downstream use?

Do not confuse consent with blanket permission

Even when a team relies on consent, that should not become an excuse for broad or sloppy processing. Consent for one workflow does not automatically justify adjacent uses later. The discipline is to keep each purpose narrow enough that teams know what is in scope and what needs separate review.

Official and higher-authority sources

Related guides