Consent Under DPDP Act: Why 'Accept All' Banners Will Hurt You

The single most common piece of consent theatre we still see on Indian websites in 2026 is an "Accept All / Reject All" banner ported from a 2019 GDPR cookie template. It doesn't work under the Digital Personal Data Protection Act, 2023 — and worse, it creates a false sense of coverage.

Here's what a defensible consent system actually looks like under Sections 5 and 6.

What the DPDP Act asks for

Section 6(1) requires consent that is:

• Free — no bundling with the provision of a service where the processing isn't necessary for that service.
• Specific — one consent per purpose, not a single "I agree to everything".
• Informed — preceded or accompanied by a Section 5 notice describing the personal data collected and the purpose.
• Unconditional — the service cannot be conditioned on consent for processing unrelated to the service.
• Unambiguous — expressed through a clear affirmative action.

Section 6(4) then adds the operational teeth: withdrawal must be as easy as giving consent.

The "Accept All" pattern fails at least three of these — it isn't specific, it isn't unconditional, and its withdrawal path is invariably harder than the accept flow.

The three-layer consent architecture

A defensible consent system has three separate layers. Each one exists to satisfy a different obligation, and conflating them is where most implementations fail.

Layer 1: The notice

A plain-language Section 5 notice that lists:

• The categories of personal data collected
• The purposes for each category
• The mechanism to withdraw consent
• How to exercise data principal rights
• Contact details for the grievance officer

Available in English and (where the user base warrants) any language listed in the Eighth Schedule.

Not buried in a 4,000-word privacy policy PDF. The notice is a short screen — usually 200–400 words — shown at the point of collection.

Layer 2: The consent capture

A separate action per purpose. For a typical SaaS product:

• Account creation and service delivery (usually a Section 7 legitimate use — not consent)
• Product analytics (consent)
• Personalisation (consent)
• Marketing communications (consent)
• Third-party sharing for co-marketing (consent, separately)

Each capture is logged with: what was shown, what was accepted, when, from which device, and under which policy version.

Layer 3: The preference centre

A user-facing screen — usually at /account/privacy — that displays every purpose the user has ever consented to, with an individual toggle for each. Toggle off → consent immediately withdrawn → downstream processing stops.

If the user can accept marketing consent in one click during sign-up, they must be able to withdraw it in one click here. Not by emailing support. Not by unsubscribing from one specific email. One click, same layer of friction.

What "as easy" actually means

We audit consent flows against a simple test: count the clicks and required inputs on the accept path, count them on the withdrawal path, and compare.

• Accept: 1 click. Withdrawal: 1 click. Pass.
• Accept: 1 click. Withdrawal: 3 clicks. Fail.
• Accept: modal → agree. Withdrawal: email support → wait 5 days. Fail.
• Accept: on sign-up form. Withdrawal: only via unsubscribe link in a specific email. Fail (that email may never be sent).

The cascade problem

Withdrawing consent isn't just a UI flip. It's a downstream event that must cascade:

• Stop sending the data to any Data Processor being used only for that purpose.
• Delete or anonymise the data if no other lawful basis exists.
• Update the preference in every downstream marketing/analytics platform via API.
• Log the withdrawal event immutably.

This is where architecture matters. If your marketing platform (Mailchimp, HubSpot) is authoritative for consent state, and your product database is authoritative for user state, you need a job that reconciles the two. Otherwise a user who withdraws consent in your product will still receive emails, and a user who unsubscribes from an email will still show as consented in your product.

Special cases

Children

Section 9 requires verifiable parental consent for processing personal data of children (under 18). "I confirm I am over 18" is not verifiable. If your product could plausibly be used by minors, you need a verification mechanism — parent email confirmation with an out-of-band check, government ID, or a registered Consent Manager once available.

Employees

Employment relationships are asymmetric. Consent given as a condition of employment is rarely "free". For most HR processing, rely on Section 7(i) (necessary for employment) rather than consent. Reserve consent for genuinely optional processing (wellness, alumni networks, voluntary surveys).

Marketing to existing customers

Consent for marketing must be separately captured. "Continued use of the service constitutes consent to marketing" is not a valid basis under the DPDP Act.

The cost of getting this right

For a mid-size Indian SaaS, implementing a proper three-layer consent architecture is roughly 4–8 weeks of engineering time plus a designer. The preference centre alone is 2 weeks. This is not expensive — but it must be done in one pass. Bolting it on after launch, one purpose at a time, is where teams spend three times the effort.

For a workshop on redesigning your consent architecture, our privacy program services engagement includes a consent-track deliverable that ships in one sprint.