Cookie Consent vs DPDP Consent: What’s the Difference?

Cookie Consent vs DPDP Consent: What’s the Difference?

  • Loading...

Walk onto almost any Indian website today and you’ll see a cookie banner — “Accept,” “Reject,” “Manage Preferences.” Ask most product or marketing teams what that banner has to do with the Digital Personal Data Protection Act, 2023 (DPDP Act), and you’ll get a shrug. The two are often treated as separate compliance boxes: cookie banner for the browser, DPDP notice for the privacy policy. That’s a mistake. Cookie consent is really just one specific, highly visible application of DPDP consent — not a parallel or separate requirement. Understanding how they relate (and where they genuinely differ) matters if you don’t want gaps in either.

Get a callback

The Short Answer

There is no standalone “cookie law” in India, the way the EU has the ePrivacy Directive sitting alongside GDPR. The DPDP Act doesn’t mention the word “cookie” anywhere. But cookies that collect or enable the collection of personal data — behavioral tracking, device identifiers, IP addresses, login-linked activity — fall squarely inside the DPDP Act’s definition of personal data processing. So:

  • Cookie consent is a UI mechanism: the banner, toggle, or preference center that appears on a website or app.
  • DPDP consent is the legal standard that any consent — including the consent captured through that cookie banner — must meet to be valid.

In other words, your cookie banner is not a separate compliance artifact. It’s one of the places where DPDP consent gets operationalized, and if it doesn’t meet the DPDP bar, it’s not valid consent regardless of how good the banner looks.

Why People Conflate Them

The confusion is understandable, for a few reasons:

  1. Cookie banners predate DPDP. Many Indian websites added them years ago to look aligned with GDPR, or because of pressure from ad-tech partners like Google requiring consent signals. That “cookie consent” existed before India’s own law created the impression that it’s a separate, self-contained obligation.
  2. The DPDP Act is silent on the word “cookie.” Because the Act speaks in terms of “personal data” and “processing” rather than specific technologies, teams don’t always connect the dots between a banner asking about “analytics cookies” and a law about data principal rights.
  3. Cookie consent tools are marketed as compliance products. Consent management platforms (CMPs) sell cookie banners as an end-to-end solution, which can make it feel like installing one “handles” DPDP compliance broadly. It handles a slice of it — the part that touches your website’s tracking technologies.

Where They Actually Overlap

Whether consent is being collected through a cookie banner or a signup form, the DPDP Act’s Section 6 standard applies identically. Valid consent — cookie-related or not — must be:

  • Free — not bundled with access to the site (“accept cookies or you can’t browse”).
  • Specific — tied to a defined purpose (analytics, marketing, personalization), not a blanket “accept all.”
  • Informed — the person needs to understand what’s being collected and why before they consent.
  • Unconditional — access to your product can’t be made contingent on consenting to non-essential cookies.
  • Unambiguous, via clear affirmative action — no pre-checked “Accept” boxes, no assuming consent just because someone kept browsing.

This is exactly why regulators globally have gone after “dark pattern” cookie banners — a prominent “Accept All” button next to a barely visible “Reject” link fails the same “clear affirmative action” test whether you’re evaluating it under DPDP, GDPR, or any comparable law. A well-known example under the EU framework: the Planet49 case, where the Court of Justice of the European Union held that pre-ticked consent boxes don’t constitute valid consent — a principle the DPDP Act’s Section 6 essentially mirrors for India.

The same downstream obligations apply too:

  • Withdrawal must be as easy as consent. If someone can accept cookies in one click, DPDP’s “comparable ease” standard means they need an equally simple way to withdraw — a persistent, accessible preference center, not a support email.
  • You need to prove consent was validly obtained. Section 6(10) puts the burden of proof on the Data Fiduciary. That means your cookie consent tool needs to log who consented, to what categories, when, and under what version of your notice — the same evidentiary bar as any other DPDP consent record.
  • Purpose limitation applies. If a user consents to analytics cookies but not marketing cookies, using their data for retargeting anyway breaches purpose limitation just as clearly as using signup data for an unrelated purpose would.

Where They Genuinely Differ

That said, cookie consent and DPDP consent aren’t identical in scope or mechanics. A few real differences matter:

1. Scope of what’s covered

DPDP consent applies to all personal data processing — signup forms, HR records, customer support tickets, payment data, biometric data, everything. Cookie consent covers a narrower slice: data collected through browser or app tracking technologies (cookies, pixels, SDKs, local storage). Every cookie consent event is a DPDP consent event, but the reverse isn’t true — most of your DPDP obligations have nothing to do with cookies at all.

2. Granularity expectations

Cookie consent tools have matured toward a fairly standardized UX pattern: category-based toggles (Essential, Analytics, Marketing, Personalization), an “Accept All / Reject All / Customize” pattern, and auto-expiring preferences. DPDP consent, more broadly, doesn’t prescribe a specific UI pattern — it prescribes an outcome (free, specific, informed, unconditional, unambiguous consent via affirmative action). This gives you more flexibility, and more responsibility, to design a compliant experience for consent flows outside the cookie context — think of a fintech app asking for consent to pull your account statements, or a healthtech platform asking for consent to process medical history.

3. Regulatory guidance

Cookie consent in India has more specific operational guidance today than DPDP consent does generally, thanks to the Business Requirements Document for Consent Management Systems (BRDCMS), released by the Ministry of Electronics and Information Technology (MeitY) in mid-2025. While not legally binding, it gives concrete recommendations: cookie banners should offer “Accept,” “Reject,” and “Customize” options, support multilingual delivery, allow consent to be withdrawn or changed at any time, and auto-expire cookie preferences after a defined period to avoid indefinite retention. There isn’t an equivalent, technology-specific rulebook yet for other categories of DPDP consent (say, consent captured over a phone call for a financial service) — those still have to be reasoned out from the Act’s general principles.

4. Third-party dependency

Cookie consent is unusually entangled with third parties — ad networks, analytics vendors, retargeting platforms — who read the consent signal and act on it independently. A rejected marketing cookie needs to actually stop a Meta Pixel or Google Ads tag from firing, not just update a database flag on your server. Getting this technically wrong (banner says “rejected,” but the tag still fires) is one of the most common real-world cookie compliance failures, and it’s a DPDP violation, not just a bad look, because it means personal data is processed without the legal basis your own notice claimed applied.

A Simple Mental Model

Think of it as a nested relationship, not a side-by-side comparison:

DPDP Consent (the legal standard — free, specific, informed,
unconditional, unambiguous, affirmative action, provable, easily withdrawn)
        │
        └── applies to ──▶  Cookie Consent (one implementation surface,
                             covering tracking technologies specifically)

If your cookie banner satisfies DPDP’s consent standard, it’s compliant. If it doesn’t — pre-checked boxes, no real reject option, tags firing regardless of the user’s choice, no way to withdraw later — it’s not compliant, and no amount of “we have a cookie banner” will save it in front of the Data Protection Board.

What This Means Practically for Indian Businesses

  • Don’t treat your cookie consent tool as a substitute for a DPDP compliance program. It solves one visible surface, not the whole obligation.
  • Audit your cookie banner against DPDP’s Section 6 test directly: Is “Reject” as visually prominent as “Accept”? Is consent genuinely optional, with the site still functional if declined? Are cookies categorized so a user can consent to analytics but decline marketing?
  • Wire rejection to actual behavior. Confirm that declining a cookie category actually blocks the relevant script or tag from loading — test this, don’t assume your CMP does it correctly out of the box.
  • Log cookie consent the same way you’d log any other DPDP consent event — who, what categories, when, under which notice version — so you can produce evidence if asked.
  • Set expiry and re-consent cycles. Aligning with data minimization principles, cookie preferences shouldn’t be treated as permanent; periodic re-confirmation keeps the consent current and defensible.
  • Extend the same rigor beyond cookies. Once your cookie banner is DPDP-compliant, use it as the template for every other consent surface in your product — signup, KYC, marketing opt-ins, in-app permissions — since they’re all held to the identical legal standard.

The Bottom Line

Cookie consent and DPDP consent aren’t two different compliance regimes — they’re one legal standard applied to two different surfaces, one narrow (tracking technologies on your site or app) and one broad (every instance of personal data processing across your business). The banner is the part users see; the DPDP Act is the law that decides whether what’s behind that banner actually holds up. Get the underlying consent architecture right once — free, specific, informed, revocable, and provable — and it’ll serve both your cookie banner and everything else your business does with personal data.

This article is for general informational purposes and does not constitute legal advice. Organizations should confirm their specific obligations under the DPDP Act, the DPDP Rules, 2025, and the BRDCMS with qualified legal counsel, as regulatory guidance in this area continues to evolve.

Appointment