DPDP Act18 May 2026 8 min read

DPDP Act Consent Requirements: What Valid Consent Means

What constitutes valid consent under India's DPDP Act 2023? This guide covers the four requirements for valid consent, consent notices, bundled consent, and children's consent.

Key Takeaways

Valid consent under Section 6 must be free, specific, informed, unconditional, and unambiguous — a pre-ticked box does not qualify.
Consent must be accompanied by a privacy notice that explains what data is collected and why.
Bundled consent — one checkbox for multiple unrelated purposes — is not valid under the DPDP Act.
Withdrawing consent must be as easy as giving it, and no fees may be charged for withdrawal.
Consent for children requires verifiable parental consent; the Rules will specify the verification mechanism.

In this guide

What Is Valid Consent Under Section 6
The Consent Notice Requirement
Why Bundled Consent Is Invalid
Legitimate Use: Processing Without Consent
Consent Withdrawal: How to Implement It
Children's Consent and Parental Verification
Building a Consent Management System

Section 6(1) of the DPDP Act defines valid consent as consent that is "free, specific, informed, unconditional and unambiguous with a clear affirmative action." Each of these five elements is a necessary condition — fail any one and the consent is invalid.

"Free" means the consent was not coerced or made a condition of receiving a service where processing is not necessary for that service. Requiring a user to consent to marketing emails in order to create an account is not free consent if marketing is not integral to the service. "Specific" means consent is sought for a defined, granular purpose — not a broad sweep of possible future uses.

"Informed" means the Data Principal was given a clear privacy notice before consenting. "Unconditional" means no obligation is attached to the consent decision. "Unambiguous with a clear affirmative action" means the person must actively do something to signal consent — clicking "I agree," checking a box, or signing a form. Silence, pre-checked boxes, and continuing to use a service do not constitute consent.

The Consent Notice Requirement

Section 5 requires that before seeking consent, the Data Fiduciary must provide a notice containing: (a) the personal data to be collected; (b) the purpose for which it will be processed; (c) the manner in which the Data Principal may exercise their rights; and (d) the manner in which the Data Principal may withdraw consent.

The notice must be in clear, plain language — not legalese. It must be accessible in English or any language specified in the Eighth Schedule of the Constitution, allowing notices in Hindi, Tamil, Bengali, and 18 other scheduled languages. This is a significant operational requirement for consumer-facing companies with pan-India user bases.

The notice is separate from your privacy policy. A full privacy policy may contain all required elements, but the Data Principal must be able to find the notice easily before or at the point of consent. A link buried in footer text to a 10,000-word privacy policy does not satisfy the notice requirement.

Section 6(1)'s "specific" requirement prohibits bundled consent — the common practice of seeking one consent for multiple distinct processing purposes. You cannot, for example, use a single checkbox to consent to: account registration, marketing emails, analytics tracking, and sharing with third-party partners. Each distinct purpose requires separate consent.

This has significant implications for product design and onboarding flows. Companies that currently use a single "I accept the terms and privacy policy" checkbox must redesign to present separate consent requests for each material processing purpose. Each consent request must clearly state what it covers.

Practically, this means your registration flow might have: one consent for account creation (core service delivery — possibly a legitimate use rather than consent), a separate opt-in for marketing communications, and a separate opt-in for analytics or profiling. Each must be independently revocable.

Legitimate Use: Processing Without Consent

Section 7 provides a list of "legitimate uses" for which personal data may be processed without consent. Unlike GDPR's six lawful bases, the DPDP Act's legitimate uses are narrower and more specific. They include: (a) processing for the State providing subsidies, benefits, or services; (b) performing a legal function; (c) compliance with a court order or judgment; (d) responding to a medical emergency; (e) employment-related processing (subject to Rules); and (f) public interest processing.

Notably absent is "legitimate interests" — the GDPR lawful basis that allows controllers to process data for business purposes without consent, subject to a balancing test. Indian companies cannot rely on "legitimate interests" to avoid consent for marketing, analytics, fraud prevention, or other commercial purposes.

For B2B companies, the absence of a legitimate interests basis creates challenges. Processing a business contact's data for CRM purposes may require consent. The Rules may clarify B2B data treatment, but until then, a conservative approach is to obtain consent for all non-contractual processing of identifiable individuals' data.

Consent Withdrawal: How to Implement It

Section 6(4) makes withdrawal of consent a right, and Section 6(5) prohibits making withdrawal more difficult than giving consent. If consent was given by clicking a button in an app, withdrawal must also be achievable by clicking a button in the app — you cannot require users to send a written letter or call a helpline.

Implement consent withdrawal through a dedicated "Privacy Controls" or "Data Settings" section in your product or website. Each consent given should have a corresponding "Withdraw" action. When a user withdraws, your system must: (a) log the withdrawal with a timestamp; (b) cease the processing within the specified period; and (c) cascade the withdrawal to downstream Data Processors.

The challenge for multi-system companies is propagating withdrawals across all downstream systems — marketing automation, analytics platforms, CRM, and third-party tools. Build a consent event stream that all downstream systems subscribe to, so that a withdrawal in your primary system automatically suppresses processing in all dependent systems.

Section 9 imposes the most stringent consent requirements for children (defined as individuals under 18). Before processing a child's data, the Data Fiduciary must: (a) obtain verifiable consent from the child's parent or guardian; (b) not process personal data in a manner that is likely to cause harm to the child; and (c) not track, monitor, or target behavioural advertising at children.

"Verifiable" parental consent is a high bar. Merely asking a user to tick a checkbox stating they are 18 or have parental consent does not satisfy the verifiability requirement. The Rules will specify what constitutes verifiable consent — possibilities include DigiLocker-based verification, Aadhaar OTP, or payment-card verification (as a proxy for adult identity).

Platforms that cannot distinguish between child and adult users face significant risk under this provision. The penalty for violating Section 9 is the maximum ₹250 crore. Consumer apps, gaming platforms, social media services, and e-learning platforms must implement age verification before processing any personal data.

A consent management system (CMS) is the technical infrastructure that records, stores, and acts upon consent decisions. A functional CMS must: record each consent event (what was consented to, when, by whom, and how); make consent records retrievable for audit purposes; propagate withdrawals to downstream systems; and generate compliance reports.

For website cookie consent, a Consent Management Platform (CMP) — such as those built on the IAB Transparency and Consent Framework — provides a starting point. For in-product consent, you will need to build consent event logging into your application database, with timestamps and audit trails.

AuditPath integrates with consent management infrastructure to track consent compliance as a control in your DPDP framework. Maintaining evidence of consent — not just having a privacy policy — is what the Data Protection Board will examine if a complaint is raised.

Frequently Asked Questions

Can we use a single privacy policy acceptance as consent for all data processing?

No. Accepting a privacy policy is not valid consent under the DPDP Act. Consent must be specific to each purpose, with a clear affirmative action. A privacy policy acceptance is a terms-of-service agreement, not a DPDP Act-compliant consent. You need separate, granular consent mechanisms.

Does the DPDP Act require re-obtaining consent for data collected before the Act came into force?

The Rules will address transitional provisions. As a practical matter, for significant processing activities — particularly marketing lists and profiling — re-permissioning campaigns before the Act becomes enforceable are advisable. It is far better to proactively refresh consent than to face enforcement for processing on the basis of invalid historical consent.

Is implied consent valid under the DPDP Act?

No. Section 6(1) requires "unambiguous" consent with "a clear affirmative action." Implied consent — inferred from continued use of a service or failure to opt out — does not satisfy this standard. Every consent must be actively given.

Can we condition access to our service on consent to all data processing?

Only for processing that is strictly necessary to provide the service. You can make account creation conditional on consent to process account data. You cannot make account creation conditional on consent to marketing emails or third-party data sharing that is not integral to service delivery.

How long must we retain records of consent?

The Act does not specify a retention period for consent records. Best practice (and consistent with the Rules expected framework) is to retain consent records for the duration of the relationship plus a reasonable post-relationship period — suggested minimum of 3-5 years to cover any potential Board inquiry.