DPDP consent-banner requirements — exactly what your Indian website needs

The DPDP Act defines valid consent in Section 6: free, specific, informed, unconditional, unambiguous, given through clear affirmative action, and signifying agreement to processing for a specific purpose. Every adjective in that sentence kills a banner pattern that is still routine on Indian websites. There is no GDPR-style legitimate-interest carve-out for tracking; if a tracker fires on your site without prior consent, you are violating Section 6 every page load.

**Criterion 1 — Free.** The user can refuse without losing access to the service. This rules out 'pay or okay' walls for non-essential trackers, and rules out banners that block the whole site until Accept is clicked. **What passes:** a top-banner or bottom-bar that allows the user to dismiss it after rejecting, with the site fully functional in either state. **What fails:** a full-screen modal with no working Reject option.

**Criterion 2 — Specific.** Consent is per purpose, not blanket. Section 6(1) explicitly says consent is for 'a specified purpose'; a single 'I agree to the privacy policy' tickbox covers nothing under DPDP. **What passes:** a banner with separate toggles for analytics, marketing and personalisation, with descriptions for each. **What fails:** one 'Accept all' button that bundles tracking, profiling, retargeting and any other category the site might invent later.

**Criterion 3 — Informed.** The user knows what they are consenting to before they click. This is where the consent notice (Section 5) and the banner intersect: the banner must link to a notice that itemises the data, the processors, the purposes and the rights. **What passes:** a banner that names the cookie categories, links to the full notice, and lists the third-party processors by name. **What fails:** 'We use cookies to improve your experience' with no purpose, no processor, no notice link.

**Criterion 4 — Unambiguous + clear affirmative action.** Silence, pre-ticked boxes, scrolling past the banner — none of these count. **What passes:** a tick-box defaulted to OFF that the user actively flips ON, or a clearly-labelled 'Accept' button that requires an explicit click. **What fails:** a banner where the categories are pre-ticked, or where dismissing the banner is treated as consent.

**Criterion 5 — Withdrawable as easily as given (Section 6(4)).** This is the criterion that ends most cookie-banner architectures. If consent took one click on the banner, withdrawal must take one click via a persistent footer link that re-opens the same banner. **What passes:** a 'Manage cookies' link in the footer of every page, that reopens the banner with the existing per-category state and lets the user flip switches. **What fails:** a withdrawal flow that requires an account, an email to grievance@, or a CAPTCHA-protected portal three clicks deep.

**Criterion 6 — Equal prominence for Accept and Reject.** This is not explicit in Section 6 but flows from the 'free' and 'unambiguous' criteria — and from the prohibition on dark patterns. **What passes:** Accept and Reject side by side, same size, same colour weight, on the first banner screen. **What fails:** big green Accept, grey-text Reject behind a 'Manage' sub-menu. The asymmetry is what the Data Protection Board has signalled as the first enforcement target.

**The minimum viable DPDP banner.** Three top-level buttons: Accept all, Reject non-essential, Manage preferences. Inside the preferences view, one switch per category — Essential (locked ON, explained), Analytics (default OFF), Marketing (default OFF), Personalisation (default OFF). Each switch carries a one-line description and a link to the relevant section of the privacy notice. The banner emits a JavaScript event when state changes so SDKs can listen and start or stop firing without a page reload. State persists in localStorage with a max expiry of 12 months (after which the user is re-prompted).

**Tooling.** The [checkDPDP banner builder](/tools/banner-builder) generates a compliant banner in about ten minutes — pick brand colours, declare your cookies, paste the script before </body>. Complianz, CookieYes, Tsaaro and Consentmo all support DPDP-compliant configurations once you tick the right boxes in their region settings. Whatever you pick, run the [checkDPDP scanner](/scan) on the result — the banner-rendering check is one of the ten categories and tells you in seconds whether your banner is observably compliant or quietly leaking.

**Common failure modes from real scans.** Trackers loading before the banner renders (almost universal — the fix is to put the CMP script higher in <head> than your tag manager). 'Reject' that closes the banner but keeps the previous state (subtle, but visible in localStorage). A preference centre that does not actually disconnect the trackers when the user toggles off (the deepest bug — the banner UI works, but the backend wiring is broken). All three are flagged by the scanner; all three are 30-minute fixes once you know where to look.