A deep dive into what valid consent under the DPDP Act actually requires — notice, the five validity conditions, legitimate-use exceptions, withdrawal mechanics, and where most businesses get it wrong.
A checkbox that says "I agree to the Terms & Conditions and Privacy Policy" has been the default consent mechanism for Indian websites and apps for over a decade. Under the DPDP Act, that single checkbox is no longer good enough — and the gap between what businesses currently have and what the Act actually requires is wider than most realize until they look closely.
Consent sits at the center of the DPDP Act. It's the primary lawful basis for processing personal data, and unlike a policy document nobody reads, it has to meet specific, testable conditions. Here's what those conditions actually are, and where businesses most often fall short.
What Makes Consent Valid Under the Act
Section 6 of the DPDP Act doesn't leave "valid consent" open to interpretation. To count, consent has to be:
- Free — given without coercion, and not bundled into a take-it-or-leave-it condition for accessing a service that doesn't genuinely require that data
- Specific — tied to a particular, clearly stated purpose, not a broad grant covering "any purpose the business may determine"
- Informed — given after the person has actually seen a clear, itemized notice, not buried in dense legal text
- Unconditional — meaning services can't be denied simply because someone declines a purpose that isn't essential to that service
- Unambiguous, through clear affirmative action — a genuine opt-in, not a pre-ticked box, implied consent from continued use, or silence
Each condition closes off a specific practice many businesses currently rely on. "Free" rules out forcing agreement to marketing communications as a condition of signing up for a core service. "Specific" rules out one blanket consent covering everything from account creation to third-party data sharing. "Unambiguous" rules out pre-checked boxes and "by continuing to browse, you agree" banners
.
Notice Has to Come Before — and Alongside — Consent
Consent and notice aren't separate obligations; they work together. Section 5 requires that before or at the time consent is sought, the Data Principal receives an itemized notice describing exactly what personal data is being collected and for what specified purpose. A notice that's technically present but written in dense legal language, or that describes purposes vaguely, doesn't meet the Act's plain-language expectation — and consent obtained on the back of an inadequate notice is on shaky ground.
When Consent Isn't Required: Legitimate Uses
The Act doesn't require consent for every instance of processing. Section 7 sets out specific "legitimate uses" — defined circumstances where a business can process personal data without going through the consent process. These aren't a general escape hatch; they're narrow and specific:
| Legitimate Use | Example Scenario |
|---|---|
| Voluntary provision of data by the individual for a stated purpose | A customer voluntarily shares their phone number to receive an order update |
| Compliance with a legal obligation | Retaining transaction records for statutory audit requirements |
| Performance of a function under law, or for state functions | Processing required for a government-mandated service |
| Responding to a medical emergency | Accessing records to treat a patient with an immediate threat to life or health |
| Employment-related purposes | Processing employee data for functions like payroll or attendance, where consent isn't practically obtainable in that context |
Relying on a legitimate use still requires being able to justify, specifically, which provision applies and why — "we assumed we didn't need consent" isn't the same as having a documented basis under Section 7.
Withdrawal Has to Be as Easy as Giving Consent
One of the more operationally demanding parts of the Act is Section 6's requirement that withdrawing consent be at least as easy as giving it. If someone can opt in with a single click, they need to be able to opt out with comparable ease — not through a multi-step process requiring an email to customer support and a follow-up call. Once consent is withdrawn, the Data Fiduciary and any processors involved are required to stop processing that data within a reasonable time, unless retention is legally required for another reason. That obligation doesn't stop at the business's own systems — it extends to whatever third parties or processors were also handling that data.
Children's Consent Runs on a Different Standard Entirely
Section 9 treats anyone under 18 as a child, and consent for their data has to come through a verifiable parent or lawful guardian — not a simple "I am over 18" checkbox, which offers no real verification at all. On top of that, the Act prohibits tracking, behavioral monitoring, and targeted advertising directed at children outright, a restriction that a parent's consent cannot override. Any product with a meaningful under-18 user base needs a genuine age-and-identity verification mechanism, not a self-declaration field.
Where Businesses Most Commonly Get Consent Wrong
| Common Practice | Why It Falls Short |
|---|---|
| One checkbox covering multiple purposes | Fails the "specific" requirement — each purpose needs its own consent |
| Pre-ticked consent boxes | Fails "unambiguous, clear affirmative action" |
| Blocking access to a service until marketing consent is given | Fails "free" and "unconditional" |
| Consent buried in a long, dense privacy policy | Undermines "informed" consent, since the notice itself doesn't meet plain-language expectations |
| No functioning withdrawal mechanism, or one requiring manual intervention | Fails the "withdrawal as easy as consent" requirement |
| "I confirm I am 18+" as the only age check | Doesn't constitute verifiable parental consent for actual minors |
Building Consent Infrastructure That Holds Up
Meeting these requirements in practice means moving from a single consent event to a consent management system: itemized notices per purpose, consent captured and timestamped per purpose (not as one blanket acceptance), a working withdrawal flow that actually propagates to every system and vendor holding that data, and a verifiable process for anyone whose age can't be confirmed as 18 or above. For most organizations, this also means engaging with a registered Consent Manager framework as it comes into force, giving individuals a consolidated way to manage consent across multiple platforms rather than negotiating it separately with every business they interact with.
Getting From Policy to Practice
Understanding what valid consent requires is the easier half of this problem. The harder half is auditing every consent touchpoint an organization actually has — website forms, app onboarding, in-store data collection, call-center scripts — and finding out how many of them would survive scrutiny against the standard above.
TheDPDPAct.com's assessment platform is built to run exactly that audit: mapping your current consent flows against what Section 6 and Section 9 actually require, and flagging precisely where a checkbox, a bundled purpose, or a missing withdrawal mechanism needs to change before it becomes a Board inquiry instead of an internal fix.