Last updated on August 8th, 2026 at 08:41 pm
TL;DR: Consent management under India’s DPDP Act is not a policy document, it is something you build: a notice shown before you collect data, a consent mechanism that captures a genuine yes per purpose, a system that logs what was consented to and when, a withdrawal path as easy as the original consent, and a way to purge or stop processing when someone withdraws. This guide walks through exactly what to build, in the order you build it, for a website or app, referencing the specific requirements in the notified DPDP Rules, 2025 rather than general theory.
Quick overview: Most DPDP content explains the five characteristics of valid consent (free, specific, informed, unconditional, unambiguous) and stops there. This guide starts where that leaves off: what does a compliant notice actually say, what does a compliant consent screen actually look like, what has to be logged in your database, and what happens technically when someone withdraws consent or requests their data be deleted. It is written for whoever is actually building this, a founder, a product manager, or a developer, not just for someone reading about the law.
What consent management actually means
Consent management is the system, not the moment. It covers four connected things that have to work together: a notice that tells the person what you are collecting and why, before you collect it; a mechanism that captures their affirmative choice, per purpose, not as a blanket agreement; a record of what was consented to, when, and how; and a way to act on a withdrawal, immediately and completely, not eventually.
Under the DPDP Act, consent must be free, specific, informed, unconditional, and unambiguous, given through clear affirmative action. What follows is how each of those legal requirements translates into something you actually build on a website or in an app.
Step 1: Build the notice (this is where most implementations fail first)
Before you ask for consent, or at the same time, you must give notice, and the Rules are specific about what that notice contains and how it must be presented. This is not your general privacy policy; it is a standalone, purpose-specific notice shown at the point of collection.
What the notice must contain. An itemised list of the categories of personal data you are collecting, not a vague phrase like “information you provide.” Each specific purpose for which that data will be processed, stated separately, not bundled (“to create your account” is one purpose; “to send you marketing emails” is a different one, and they need separate lines, not one combined sentence). The specific goods, services, or functions that rely on that processing. A clear link or pointer to how the person can withdraw consent, raise a grievance, and exercise their other rights.
How it must be presented. In clear, plain language that an average person understands without legal or technical background, no jargon, no legalese. As a standalone communication, not buried inside a long terms-of-service document or combined with an unrelated acceptance click. Available in English and, where relevant to your user base, a regional language.
What this looks like on a real signup screen. Instead of one checkbox reading “I agree to the Terms and Privacy Policy,” a compliant flow shows, near the relevant action: what specific data is being collected right there (email, phone number, location), why (account creation, order fulfilment, marketing), and a separate, clearly labelled action for each distinct purpose. Our guide on what a privacy policy must cover and our privacy policy drafting service cover the underlying policy document; the notice at the point of collection is a separate, shorter, purpose-specific layer on top of it.
Step 2: Build the consent mechanism itself
This is the actual click, toggle, or action the person takes, and the Rules are specific about what makes it valid.
No pre-ticked boxes. Every consent toggle must default to off. A checkbox that arrives pre-selected is not valid consent, regardless of what the notice next to it says.
No bundling. You cannot make agreeing to your terms of service the same click as agreeing to marketing data use. Each purpose needs its own affirmative action. If your signup flow currently has one “I agree” checkbox covering account creation, marketing, and analytics together, that flow needs to be rebuilt into separate toggles or separate confirmation steps.
Granular, not all-or-nothing. A person should be able to say yes to account functionality and no to marketing without losing access to the core service, unless the data is genuinely necessary for that core function. Making an essential service conditional on non-essential consent is not free consent.
One clear affirmative action per purpose. A toggle switch, a checkbox someone actively ticks, or a clearly labelled button. Scrolling past a notice, closing a banner, or continuing to use the site after seeing a notice does not count as consent.
Step 3: Build the consent record (what your database actually needs to store)
Every consent action needs to be logged, and this is a database design decision, not just a legal one. At minimum, your system needs to record, per user and per purpose: which specific purpose the consent relates to, the timestamp of the action, the version of the notice shown at the time (notices change over time, and you need to know which version someone actually saw), the mechanism used to capture it (web form, app screen, API), and the current status (granted, withdrawn, expired).
This matters practically because if a dispute or a Data Protection Board inquiry arises, the burden is on you to prove that a valid notice was given and valid consent was received, not on the individual to prove it wasn’t. A consent record that only stores “consented: yes/no” with no timestamp or purpose breakdown will not meet that burden.
Step 4: Build the withdrawal path
Withdrawal has to be at least as easy as giving consent, not buried three menus deep while consent took one click at signup. Practically, this means a working settings or privacy dashboard where a user can see what they have consented to and toggle it off directly, not just a “contact us to withdraw” email address that nobody monitors.
What must happen technically when someone withdraws. Processing for that specific purpose must stop, and this needs to propagate to every system using that data, not just the front-end flag. If you share data with a third-party vendor or processor for that purpose, you need a mechanism, contractual and technical, to instruct them to stop too; our data processing agreement template is where that obligation should be written into your vendor contracts before you need it in a hurry. Withdrawal does not retroactively make earlier, consented processing unlawful, so you are not required to undo what was already done properly, but you must stop going forward.
Step 5: Handle cookies and tracking correctly
Cookies deserve their own build, because the essential-versus-non-essential distinction changes what consent is needed.
Essential cookies (session management, security, basic load balancing) do not require consent, since the site or app cannot function without them.
Non-essential cookies (analytics, marketing and advertising, third-party embeds, behavioural tracking) require the same standard of consent as any other processing: informed, specific, and opt-in by default off, not opt-out. A cookie banner that loads analytics or marketing scripts before the user has made a choice is non-compliant regardless of what the banner text says, because the processing has already started. Our cookie compliance guide covers the categorisation and consent-banner mechanics in more depth.
Step 6: Prepare for Consent Managers, even before you have to
The Rules establish a new regulated entity, the Consent Manager, an India-incorporated, independent platform that lets a person manage their consent across multiple organisations from one place, similar in concept to the RBI’s Account Aggregator framework for financial data. Full registration of Consent Managers activates on a later phase of the rollout, but the practical point for you now is architectural: your consent system should be built so that it can accept and honour a consent instruction arriving from a registered Consent Manager’s interoperable platform, not only from your own app or website. Building this flexibility in now is considerably cheaper than retrofitting it once integration becomes expected.
Step 7: Meet the minimum security requirements around consent data
Consent records and the personal data they relate to must be protected using the categories of safeguard the Rules actually specify: encryption, obfuscation or masking, or the use of virtual tokens mapped to the real data, alongside general reasonable security practice such as access controls limiting who inside your organisation can view or export consent and personal data records. Avoid overstating your own technical claims here; describe what you actually have in place rather than borrowing generic security language that does not reflect your real architecture.
Step 8: Build breach detection and dual notification into the same system
If a breach affecting consented data occurs, you have two separate, simultaneous obligations: notify the affected individuals without delay, in plain language, and separately report to the Data Protection Board within 72 hours. Because your consent system already tracks who consented to what, it should double as the source of truth for who needs to be notified if a breach touches that data, rather than reconstructing an affected-user list from scratch during an incident. Our complete DPDP Act compliance guide covers this obligation and the wider compliance timeline in full, and our free DPDP compliance checker is a fast way to see where your current setup stands.
A practical build order, if you are starting from nothing
If none of this exists yet, build in this sequence rather than trying to do everything simultaneously. First, audit every place on your website or app where you currently collect personal data and list what is collected and why, in the itemised form the notice requires. Second, rewrite your consent notices and screens to be standalone, itemised, and purpose-separated, removing any pre-ticked boxes or bundled agreements. Third, build or upgrade the database layer to log consent per purpose with a timestamp and notice version, not just a single flag. Fourth, build a working, accessible withdrawal mechanism in a user settings area. Fifth, fix your cookie banner so non-essential scripts do not fire before consent. Sixth, update your vendor and processor contracts so a withdrawal or deletion instruction actually reaches every system holding that data. This order roughly matches where the highest-risk gaps usually sit, notice and consent capture first, records and withdrawal close behind.
Frequently asked questions
What must a DPDP-compliant consent notice actually contain?
An itemised list of the specific categories of personal data being collected, each specific purpose for processing stated separately rather than bundled, the goods, services, or functions that rely on that processing, and a clear way to withdraw consent, raise a grievance, or exercise other rights. It must be written in plain language, presented as a standalone notice rather than buried inside a longer document, and available in a language the user understands.
Are pre-ticked consent boxes allowed under the DPDP Act?
No. Every consent mechanism must default to off, and the person must take a clear, affirmative action to opt in. A checkbox or toggle that arrives pre-selected does not constitute valid consent under the Act, regardless of the notice text next to it, because the Act requires an unambiguous, affirmative action, not the absence of an objection.
Can I bundle consent for multiple purposes into one checkbox?
No. Each distinct purpose, such as account creation, marketing communications, and analytics, requires its own separate affirmative consent action. Bundling them into a single “I agree” checkbox, or combining consent with acceptance of your terms of service, does not meet the specific and unconditional requirements for valid consent.
What has to be logged when someone gives consent?
At minimum, the specific purpose consented to, the exact timestamp, the version of the notice shown at the time, the mechanism through which consent was captured, and the current status of that consent (granted, withdrawn, or expired). This record is what allows you to demonstrate valid consent was obtained if a dispute or regulatory inquiry arises, and the burden of proof sits with you, not the individual.
How easy does withdrawing consent have to be?
Withdrawal must be at least as easy as giving consent was. In practice, this means a working, accessible option in a user-facing settings or privacy dashboard, not only a request sent to an email address. Once consent is withdrawn, processing for that purpose must stop, including instructing any third-party processors who were handling that data for the same purpose to stop as well.
Do essential cookies need consent under the DPDP framework?
No. Cookies necessary for basic website or app functionality, such as session management, security, and load balancing, do not require consent. Non-essential cookies, including analytics, marketing, and third-party tracking cookies, do require informed, specific, opt-in consent, and the underlying scripts should not run before that consent is given.
Authored and reviewed by Prakhar Rai, Advocate, founder of My Legal Pal. Prakhar is enrolled with the Bar Council of India and has over ten years of experience advising technology companies and platforms on data protection and regulatory implementation in India. He is an alumnus of the National Law School of India University, Bangalore, where he completed his Master of Business Laws, and of La Martiniere. Connect on LinkedIn.
This article is general information, not legal advice. Consent management requirements are technical, the Rules continue to be interpreted in practice, and your specific implementation should be reviewed for your actual data flows. For advice on your own consent system, speak to a qualified lawyer.
If you need your consent notices, cookie banners, or underlying policies brought in line with the DPDP Rules, our team can help. Start with our privacy policy drafting service, check your current position with our free DPDP compliance checker, or speak to our technology lawyers about a full implementation review.
