Consent Under the DPDP Act — What's Valid, What's Not, and How to Implement It

Section 6 — What the Law Says

Section 6 lays down the consent framework. The core requirement:

Five words. One requirement each.

The 5 Pillars of Valid Consent

1. Free

Consent must not be coerced or made a condition of a service when it is not actually necessary.

• Invalid: "Accept our marketing communications to create an account."
• Valid: Account creation consent (necessary) offered separately from marketing consent (optional).

2. Specific

Consent must be granular — tied to a specific purpose, not a catch-all blanket permission.

• Invalid: "I consent to the use of my data for all purposes as described in the privacy policy."
• Valid: Three separate consent toggles — one for order processing, one for personalised recommendations, one for marketing emails.

3. Informed

The Data Principal must understand what they are consenting to before they consent. Consent must be accompanied by a clear, plain-language notice describing what data is collected, the purpose, how data will be used, stored, and shared, and the right to withdraw consent. Notice must be in English and at least one Indian language specified by the user, where feasible.

4. Unconditional

Consent cannot be a take-it-or-leave-it gateway to accessing a service unless that processing is genuinely essential.

• Invalid: "You must consent to share your location data at all times to use our food ordering app."
• Valid: "Allow location access during delivery tracking" — scoped to necessity.

5. Unambiguous with a Clear Affirmative Action

Consent must be an active, deliberate act — not passive acceptance.

• Invalid: Pre-ticked checkboxes, continued use of a website interpreted as consent, silence treated as agreement
• Valid: A clearly labelled checkbox the user ticks themselves, a "Yes, I Agree" button distinct from the general "Sign Up" flow, a toggle that defaults to OFF

The Notice Requirement — Before Consent Can Be Sought

The DPDP Act requires that a Notice be provided to the Data Principal before or at the time consent is sought. The notice must be written in clear and plain language, available in English and a scheduled Indian language, and cover: data collected, purposes, rights, grievance mechanism, and how consent can be withdrawn.

Legitimate Uses Without Consent (Section 7)

Consent is not the only lawful basis. Section 7 lists narrow circumstances where processing is permitted without consent — but these are frequently misunderstood as loopholes.

If you are a commercial SaaS company, you likely cannot invoke State purposes. And using "contract performance" as a basis requires that the processing is genuinely necessary for the contract — not just convenient.

What Is Invalid — The Common Consent Mistakes

• Bundled consent: Combining necessary and non-necessary processing in a single acceptance — "By creating an account, you consent to receiving promotional emails and sharing your data with our partners."
• Pre-ticked or default-ON opt-ins: Any consent checkbox that comes pre-selected.
• Vague language: "We may use your data to improve our services" — improve how? For what? This is not specific.
• Consent-walled services: Refusing to provide a service because a user declined non-essential consent.
• Retrospective consent: Claiming consent for processing that began before it was collected.
• No withdrawal mechanism: If users cannot withdraw consent as easily as they gave it, the consent architecture is non-compliant.

Children's Consent — A Stricter Regime

For Data Principals under 18, the DPDP Act mandates verifiable parental consent before any personal data is collected, no behavioural tracking or targeted advertising directed at minors, and age verification mechanisms. This applies even if the child is using a general-purpose platform — if you know or should reasonably know the user is a minor, heightened obligations kick in.

Consent Managers — A New Ecosystem Player (Section 6(9))

The DPDP Act introduces Consent Managers — registered entities that allow Data Principals to manage their consents across multiple Fiduciaries through a single, interoperable interface. Think of it as a consent dashboard that a user can access to see all the platforms they have consented to, and revoke any of them from one place.

Your consent records must be machine-readable and API-accessible to integrate with registered Consent Managers once the ecosystem matures. Audit trails of all consents must be maintained and exportable. Consent Managers must register with the Data Protection Board — this regulatory infrastructure is being built now.

How to Implement Compliant Consent — A Technical Blueprint

• Layer 1 — Consent Notice UI: Trigger a layered privacy notice before data collection begins. Use progressive disclosure: short notice upfront, expandable detail sections. Offer language selection — at minimum English plus one regional language.
• Layer 2 — Granular Consent Capture: Use separate toggles for each processing purpose. Default all non-essential toggles to OFF. Record: timestamp, version of notice shown, user identifier, purpose, acceptance or rejection.
• Layer 3 — Consent Records Database: Store consent records with user ID, consent timestamp, notice version, purpose code, and status. Maintain immutable audit logs — tamper-evident and retrievable for Board audits.
• Layer 4 — Withdrawal Workflow: Surface a "Manage My Consents" page in account settings. Allow per-purpose withdrawal with immediate effect. Trigger downstream: stop processing, notify processors, update records.
• Layer 5 — Periodic Consent Refresh: If you materially change your processing purposes, re-seek consent — do not just update the privacy policy quietly. Material changes require a clear re-consent flow.

Review your existing consent flows against these five pillars today. If any fail the test, you are already in a remediation cycle you would rather start before an audit than after one. For the full picture on what additional obligations apply to Significant Data Fiduciaries, read Part 4 of this series.