Cookie Banners in India: DPDP Notice vs GDPR-Style Consent

The GDPR cookie banner is the most familiar privacy UI in the world, and it is the wrong template for India. India's DPDP Act takes a different approach to notice, consent, and tracking, and companies that copy European banner patterns will build the wrong thing.

This post explains the difference between the two regimes' approach to banners and consent surfaces, and what a DPDP-aligned design actually looks like. It is not legal advice; it is a comparison of two legal frameworks and their product implications.

GDPR's banner problem

Under GDPR, consent is one of six legal bases, and for cookies specifically, the ePrivacy Directive pushes most tracking into consent territory. The result is the pattern Europe lives with: a banner on every site, a wall of toggle groups, and "accept all" as the path of least resistance.

European consent rates reflect the friction. Industry studies consistently show that a large share of users ignore banners entirely, and consent design choices measurably shift acceptance rates. The banner became a compliance artefact that most users experience as noise.

How DPDP differs

The DPDP Act does not have a cookie-specific regime. It has a general consent regime, and three structural differences change the banner calculus:

1. Consent is the primary basis, not one of six. For most Indian consumer processing, consent is the ground. That raises the stakes on every consent interaction, because there is no "legitimate interest" fallback for marketing in the same way GDPR provides.

2. Notice is tied to consent. The Act requires notice when consent is the basis of processing. The Rules add language requirements: English plus Eighth Schedule Indian languages.

3. The test is stricter. Consent must be free, specific, informed, unconditional and unambiguous, given by clear affirmative action. Pre-ticked boxes are out, and per-purpose granularity is in.

What this means for banner design

The GDPR-era pattern of one heavy interstitial with toggle groups is not automatically wrong in India, but the DPDP test pushes the design in specific directions:

• Purpose granularity is a legal requirement. Separate purposes need separate, specific consent. A single Accept button for everything does not meet the specificity test.
• Withdrawal parity is enforceable. Withdrawal must be as easy as giving consent. That means the preference surface, not buried in settings behind a support ticket.
• Language matters. A Hindi-first product with an English-only notice is not providing informed consent to most of its users. Notice routing by language is a compliance feature, not a localisation nicety.
• The record matters more than the banner. What the user saw must be reconstructable. The banner is ephemeral; the receipt is the asset.

The honest comparison table

| | GDPR (Europe) | DPDP (India) | |--|---------------|--------------| | Legal bases | Six, including legitimate interest | Consent plus defined legitimate uses | | Cookie-specific rule | ePrivacy pushes tracking to consent | No separate cookie regime | | Consent test | Freely given, specific, informed, unambiguous | Free, specific, informed, unconditional, unambiguous | | Notice | At collection, always | When consent is the basis of processing | | Language | Member state languages | English plus Eighth Schedule languages | | Withdrawal | As easy as giving consent | As easy as giving consent | | Proof | Record of consent expected | Record of consent expected; evidence-oriented |

The overlap at the bottom is worth noticing: both regimes end at the same operational place, which is "prove what the user saw and chose." The paths differ, the destination does not.

What a DPDP-aligned consent surface looks like

Concretely, a compliant Indian consent flow looks like:

1. A notice in the user's language: who you are, what you collect, why, how to exercise rights
2. Purpose-level choices, with service-necessary processing separated from optional processing
3. A clear affirmative action per purpose, no pre-ticked boxes
4. A receipt recording what was shown and chosen
5. A preference centre where withdrawal is as easy as consent was
6. Downstream enforcement: consent changes propagate to analytics and marketing systems

Notice what is not in the list: dark patterns, urgency language, or "accept all" as the default emotional path. The DPDP test does not forbid persuasive design, but the free and unambiguous conditions punish the manipulative versions of it.

Building for the Indian regime

Erasure's consent product, Accord, is built against the DPDP test: versioned notice, purpose-level configuration, immutable receipts, a hosted preference centre, and HMAC-signed webhooks so consent changes actually reach backend systems. The consent under DPDP post goes through each Section 6 condition, and consent receipts explains the record layer.

For the broader picture, the GDPR vs DPDP comparison covers all the structural differences between the regimes, and the compliance checklist turns it into work items.

The bottom line

Copying a GDPR banner into an Indian product is copying the wrong answer. The DPDP test is stricter on purpose granularity, tied to notice, and unforgiving on proof. Design for the Indian test: clear notice in the right language, per-purpose choice, withdrawal parity, and a receipt you can produce when asked.

The banner is the smallest part of consent compliance. The record, the language, and the enforcement loop are the real work.