Consent Management Under India’s DPDP Act: A Practical Guide

Why Consent Management Matters Under the DPDP Act

Consent is the backbone of India's data protection law, and getting it wrong undermines everything built on top. DPDP consent management in India is how businesses capture, record and honour consent exactly as the Digital Personal Data Protection Act, 2023 demands.

Done well it is invisible to users and defensible to auditors. Done badly it is the first thing a partner or regulator questions, because consent collected unlawfully cannot be fixed retroactively.

This guide covers what the Act requires, how to collect and withdraw consent, and how apps, websites and global firms stay compliant.

The stakes are practical as well as legal. Invalid consent can mean deleting data and re-acquiring it, losing analytics history and personalisation, so good consent management protects the business, not only the user.

In short: consent management is the system of notices, choices and records that proves personal data was processed with valid consent. Under Section 6 of the Act, consent must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action; pre-ticked boxes and bundled consent do not qualify. Each request comes with a notice describing the data and purpose, which the person can read in English or any language in the Eighth Schedule to the Constitution. Every choice is logged, and withdrawal must be as easy as giving consent, after which processing for that purpose stops. Most of these duties apply from 13 May 2027 under the DPDP Rules, 2025.

What Consent Management Covers

It is the system that proves every piece of personal data was collected with valid consent, spanning the first signup to the final deletion request.

At its core is a record: capture consent, log it with a timestamp and the notice shown, and let users withdraw as easily as they agreed. Without that record you cannot prove lawful processing.

It is not a one-time popup. Consent needs ongoing management: fresh consent when purposes change, and a clear trail for every choice a user makes.

Treat the log as permanent. Never overwrite it, because the history of consent is itself evidence.

The Act also recognises registered Consent Managers: platforms, registered with the Data Protection Board, through which people give, manage, review and withdraw consent across businesses. The Rules governing them apply from 13 November 2026.

At a glance

• Clear, itemised notices in plain language, available in English and Eighth Schedule languages.
• Granular, opt-in consent captured separately for each purpose.
• A consent record that logs every choice with a timestamp and notice version.
• Withdrawal that is as easy as giving consent.
• An auditable trail of every consent and withdrawal event.

How to Collect Consent

Start with notice. Before or when asking for consent, tell users what personal data you process, why, how to exercise their rights and withdraw consent, and how to complain to the Data Protection Board, in clear language.

Then capture opt-in consent per purpose. Pre-ticked boxes and bundled consent fail the Act's standard; each purpose needs its own free, specific choice you can prove later.

Finally, log everything. Record who consented, to what, when, and which notice they saw, so you hold evidence the moment a user or auditor asks.

Document the purpose. Recording why each consent was sought makes audits faster and helps you spot when a new feature needs fresh consent rather than reusing an old tick.

What the Act Demands

The standard is strict: consent must be free, specific, informed, unconditional and unambiguous, with a clear affirmative action. Silence or inactivity never counts, and consent to processing that is not necessary for the purpose is invalid to that extent.

Consent is contextual. A user who agreed to analytics did not agree to marketing, so keep each purpose separate and never reuse a tick from one context in another.

Consent is not the only lawful ground. Section 7 lists certain legitimate uses, such as data a person voluntarily provides for a specified purpose without objecting, or processing required by law, but for most commercial processing consent is the basis you will rely on.

Handling Withdrawal

Withdrawal must be as easy as giving consent. If signing up took one tap, opting out cannot take ten, and that asymmetry is a common and costly failure.

When a user withdraws, stop processing for that purpose within a reasonable time and make sure your processors stop too. Erase the data unless you must retain it by law. Your consent system should trigger these downstream actions automatically, not leave them to manual follow-up.

Keep the withdrawal record. Proving when consent ended matters as much as proving when it began.

Test the journey yourself. Walk through signup and withdrawal as a user every release, because a broken opt-out is both a compliance failure and a fast way to lose trust.

Apps and Websites

Channels differ. In apps, consent means in-app consent screens, granular toggles in settings, and SDK-level controls so third-party trackers respect each choice, with a fresh prompt when purposes change.

On the web, it covers tracker and cookie consent, form-level notices, and a preference centre users can revisit at any time.

Both must share one source of truth. Whether a user consents in your app or on your site, the choice should land in the same auditable record.

Overseas firms serving people in India must meet the same standard. Where they already run GDPR or CCPA preference centres, those can usually be extended with the DPDP Act's notice and language requirements rather than rebuilt.

How SecureRoot Helps

SecureRoot designs and reviews DPDP consent management in India through its DPDP Act compliance services, and connects the work to your wider compliance programme so consent, security and breach response run as one system.

Our team has supported BFSI, fintech, healthcare and government clients across India and abroad. The official text of the law is published by MeitY, and every engagement maps directly to the Act and its Rules.

Talk to SecureRoot →

Frequently asked questions

Straight answers, no marketing speak. If you don’t see your question here, just ask at info@secureroot.co or call +91 73071 48874.

Is consent always required under the DPDP Act?

No. Consent is the main ground for processing personal data, but Section 7 of the Act lists certain legitimate uses that stand on their own. These include data a person voluntarily provides for a specified purpose without indicating any objection, processing that a public authority carries out to provide a subsidy, benefit, service, certificate, licence or permit, processing required by law or by a court order, and responses to medical emergencies, epidemics and disasters. Some employment purposes also qualify, including safeguarding the employer from loss. For most commercial processing, though, marketing, analytics, profiling and product personalisation all rest on consent, so the practical answer for a typical business is that consent is the ground you build for. Where you rely on a legitimate use instead, write down which one and why before launch, because that reasoning is exactly what an auditor or the Data Protection Board will later ask you to produce.

What is a Consent Manager under the DPDP Act?

A Consent Manager is a platform registered with the Data Protection Board through which a person can give, manage, review and withdraw consent across every business they deal with, from a single interoperable interface. It acts on that individual's behalf and is accountable to them, not to the companies reading the consent. The Rules governing registration and the obligations that follow apply from 13 November 2026, earlier than the 13 May 2027 date most other consent duties carry, so this is the part of the regime that arrives first. Practically, it means your consent record must be able to receive and honour a signal that originated somewhere other than your own signup form, and to push withdrawal events back the same way. Design the record now so a Consent Manager becomes one more source feeding a single auditable history, rather than a second parallel system bolted on later at cost.

What makes consent valid under the DPDP Act?

Consent is valid when it is free, specific, informed, unconditional and unambiguous, and given by a clear affirmative action such as ticking an unticked box or tapping a clearly labelled button. Silence, inactivity, pre-ticked boxes and consent bundled across several purposes all fail that standard. It must be limited to the personal data necessary for the stated purpose; consent to anything beyond that is invalid to the extent of the excess. It must be preceded or accompanied by a notice that itemises the data, the purpose, how to exercise rights, how to withdraw and how to complain to the Data Protection Board, and that notice must be available in English or any language in the Eighth Schedule to the Constitution. Finally, validity has to be provable, so log who consented, to what, when, and which version of the notice they saw. Consent you cannot evidence is consent you did not get.

How should apps handle DPDP consent?

Show the notice before you collect anything, capture consent separately for each purpose, and wire those choices into the code that actually moves data. Most app failures are not at the consent screen; they are in the analytics, attribution, crash reporting and advertising SDKs that initialise at launch and start sending before a single tap. Gate SDK initialisation on the stored consent state, and read that state on every cold start rather than caching it from install. Put granular toggles in settings so a user can revisit each purpose, make withdrawal reachable in as few taps as signup was, and prompt again when you add a purpose rather than stretching an old tick to cover a new feature. Log every grant, change and withdrawal to the same record your website writes to, so an audit sees one history per person and not two that quietly disagree.

How do we handle consent withdrawal?

Make withdrawal as easy as giving consent was, in the same place and by the same kind of gesture. If signing up took one tap, opting out cannot take ten, and that asymmetry is the most common and most expensive failure we see. When someone withdraws, stop processing for that purpose within a reasonable time, instruct your processors to stop as well, and erase the data unless another law requires you to retain it. Those downstream actions should be triggered by the consent system itself, not left to a ticket someone works through later. Keep the withdrawal record and its timestamp permanently, because proving when consent ended matters as much as proving when it began; never overwrite the earlier grant. Then walk the whole journey yourself every release, signing up and withdrawing as an ordinary user would, since a broken opt-out is both a compliance failure and a fast way to lose trust.

Can one system cover DPDP Act and GDPR consent?

Usually yes, and rebuilding from scratch is rarely the right call. Both regimes require specific, informed, affirmative consent, separation by purpose, and withdrawal that is as easy as the original grant, so one preference centre and one consent record can serve both, provided the record stores purpose, timestamp, notice version and jurisdiction. What you add for India is the notice content the Act requires, availability of that notice in English or an Eighth Schedule language, and the route to complain to the Data Protection Board. You also add the ability to accept and honour signals from a registered Consent Manager, which has no European equivalent. Where the two regimes diverge, hold the stricter position field by field rather than running two stacks. Overseas firms with a mature preference centre usually extend it; SecureRoot reviews that extension through its DPDP Act compliance services and its Virtual DPO service.

Related service pages

DPDP Act Compliance Services · Compliance Services · Virtual DPO

Ready to get DPDP-ready?

Talk to SecureRoot →

This guide was researched against the DPDP Act, 2023 and its Rules, and reviewed by SecureRoot’s compliance team for accuracy.