Under India's Digital Personal Data Protection Act (DPDPA), consent is the primary basis on which most organisations may process personal data, and the bar is higher than a cookie banner and a stored 'yes'. Consent must be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action, limited to the personal data needed for a stated purpose. It must be as easy to withdraw as it was to give, and, crucially, you must be able to prove a valid consent existed for every purpose you rely on. This guide sets out each requirement in plain language and how to run consent as an operational, evidenced process rather than a one-off pop-up.
What does the DPDPA require for consent?
The DPDPA treats consent as a request tied to a specific purpose. Before or at the time you ask for consent, you must give the data principal (the individual) a notice describing what personal data you will process and why. The consent you then collect is valid only for the purposes described, and only for as long as that purpose lasts. Processing personal data beyond the consented purpose, or keeping it once the purpose is served, is not covered by the original consent. In practice this means consent is not a single event you capture once at sign-up; it is a live state you have to keep accurate as purposes, notices and the individual's choices change.
The conditions for valid consent under the DPDPA
The Act sets out the qualities consent must have. If any one is missing, the consent is not valid and the processing that relies on it is exposed:
- Free: given without coercion, and not bundled so that a service is refused unless the person agrees to processing that isn't necessary for it.
- Specific: tied to defined purposes, not a blanket agreement to 'use my data'.
- Informed: preceded by a clear notice of what is collected and why, in plain language.
- Unconditional and unambiguous: a clear affirmative action, no pre-ticked boxes, silence or inactivity.
- Limited: covering only the personal data necessary for the specified purpose (data minimisation is built into the consent itself).
- Withdrawable: as easy to withdraw as it was to give, with the consequences of withdrawal borne by the data principal but the process no harder than opting in.
A useful test: could you show, for a given individual and purpose, that they took a clear action to agree, saw the notice that applied at that moment, and could withdraw in one comparable step? If not, the consent is weak.
Notice
Plain-language, per purpose
Capture
Clear affirmative action
Process
Only the consented purpose
Withdraw
As easy as giving
Enforce
Downstream systems honour it
Prove
Tamper-evident record
What must a DPDPA consent notice contain?
The notice is what makes consent 'informed', and the DPDPA Rules are prescriptive about it. At minimum, a consent notice should tell the data principal:
- The personal data being collected and the specific purpose of processing it.
- How they can exercise their rights, including the right to withdraw consent.
- How to make a complaint to the Data Protection Board of India.
- An option to access the notice in English or any language listed in the Eighth Schedule to the Constitution.
The notice must be presented separately or be clearly distinguishable from other information, in clear and plain language. Where you obtained consent before the Act commenced, you are expected to give a fresh notice to continue relying on that consent, which is why 'consent for data we already hold' is one of the hardest parts of a DPDPA programme.
| Valid consent | Invalid or weak consent |
|---|---|
| A clear affirmative tick or tap the person actively makes | A pre-ticked box, or consent inferred from silence |
| Separate, purpose-specific requests | One bundled 'I agree to everything' at sign-up |
| Notice shown at the point of consent, in plain language | Consent buried in a long terms-of-use document |
| Withdrawal available in one comparable step | Withdrawal hidden, delayed, or harder than opting in |
| A record of who consented, to what, when and under which notice | A single boolean flag with no context or history |
The right to withdraw consent
The DPDPA gives data principals the right to withdraw consent at any time, and the withdrawal must be as easy as giving it was. Once consent is withdrawn, you must stop the processing that relied on it within a reasonable time, and ensure your data processors do the same. This is where many implementations fall down: capturing consent is straightforward, but propagating a withdrawal so that every downstream system, analytics tag, marketing tool and processor actually stops is an engineering and governance problem. If a withdrawal doesn't reach the systems doing the processing, you are non-compliant regardless of what your consent screen says.
What is a Consent Manager under the DPDPA?
The DPDPA introduces a specific role: the Consent Manager. This is an entity registered with the Data Protection Board that gives data principals a single, interoperable point to give, review, manage and withdraw their consent across the data fiduciaries they deal with. Consent Managers must meet conditions set out in the Rules (including technical and governance obligations) and act in a fiduciary capacity toward the data principal. Whether or not you integrate with a registered Consent Manager, the direction of travel is clear: consent is expected to be portable, auditable and manageable by the individual, not locked inside each company's database.
Is a cookie banner enough for DPDPA consent?
No. A cookie banner is one surface where consent is captured, but the DPDPA governs consent for all personal data processing, not just cookies and trackers. A compliant approach needs granular, category-level cookie consent with pre-consent blocking (so tags only fire once a valid choice is recorded), but it also needs the same rigour applied to sign-up forms, in-app permissions, marketing preferences and any other point where you collect personal data. Treating consent as a banner problem leaves most of your processing uncovered.
How to operationalise DPDPA consent
Turning the requirements above into something that survives scrutiny looks like this:
- 1Map every purpose for which you process personal data, and the personal data each purpose actually needs.
- 2Write a plain-language notice per purpose, versioned, so you always know which notice a given consent was given against.
- 3Capture consent through a clear affirmative action, separately per purpose, with no pre-ticked boxes or bundling.
- 4Enforce the current consent state in real time, so downstream systems, tags and processors honour changes the moment they happen.
- 5Make withdrawal as easy as giving, and propagate it everywhere the data flows.
- 6Record every consent event (purpose, notice version, language, channel, timestamp) in a tamper-evident log.
- 7Run retrospective notice and re-consent for data you collected before the Act, to bring it up to standard.
Done well, consent stops being a compliance liability and becomes provable trust: you can demonstrate, for any individual and any purpose, that a valid consent existed and was honoured. That is the standard the DPDPA sets, and it is the standard the Data Protection Board will hold you to.
Frequently asked questions
What is valid consent under the DPDPA?+
Consent is valid under the DPDPA when it is free, specific, informed, unconditional and unambiguous, given through a clear affirmative action, and limited to the personal data necessary for a specified purpose. It must also be as easy to withdraw as it was to give. Consent that is bundled, pre-ticked or inferred from silence is not valid.
What must a DPDPA consent notice include?+
A consent notice must describe the personal data being collected and the purpose, explain how the data principal can exercise their rights (including withdrawing consent), explain how to complain to the Data Protection Board of India, and offer access to the notice in English or a language listed in the Eighth Schedule to the Constitution. It must be in clear, plain language and distinguishable from other terms.
Can consent be withdrawn under the DPDPA?+
Yes. A data principal can withdraw consent at any time, and withdrawal must be as easy as giving consent was. Once withdrawn, the data fiduciary and its processors must stop the processing that relied on that consent within a reasonable time.
What is a Consent Manager under the DPDPA?+
A Consent Manager is an entity registered with the Data Protection Board that provides data principals a single, interoperable platform to give, manage, review and withdraw consent across the data fiduciaries they interact with. Consent Managers act in a fiduciary capacity toward the individual and must meet conditions set out in the DPDPA Rules.
Do I need fresh consent for data I already collected?+
Where you relied on consent obtained before the DPDPA commenced, you are expected to give a fresh notice so the data principal can continue or withdraw. In practice this means running retrospective notice and re-consent flows for your existing data, which is often the most demanding part of a DPDPA programme.
Is a cookie banner enough for DPDPA compliance?+
No. A cookie banner addresses one surface. The DPDPA governs consent for all personal data processing, so you also need the same rigour on sign-up forms, in-app permissions and marketing preferences, plus real-time enforcement and a provable record of every consent event.
About the author
Nilesh Wagh
Co-Founder, Pelta Technologies
Former CISO · 10+ years in information security & GRC
Nilesh Wagh is Co-Founder of Pelta Technologies, where he leads its information security, privacy, AI governance and GRC advisory. With over a decade in cyber and information security (including years as a Chief Information Security Officer) he helps regulated organisations move from fragmented compliance to connected, evidence-driven assurance.
Connect on LinkedIn →