At a glance
The DPDP Act never mentions cookies by name, but the tracking identifiers most cookies carry are personal data — so non-essential cookies (analytics, advertising, third-party trackers) need real opt-in consent before they load, while strictly necessary cookies can rely on legitimate use. A compliant banner asks first, defaults to nothing switched on, makes rejecting as easy as accepting, and records what each visitor chose. This is an interpreted area — no standalone Indian cookie law exists yet.
Educational resource only. This explains how cookie and consent banners map to India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice — cookie treatment under the Act is still an evolving, interpreted area, so have your setup reviewed against the trackers you actually run.
The situation
You’ve seen the banners on every European site and you’ve probably pasted one onto yours — “We use cookies. Accept All.” The question you actually need answered is narrower: which of your cookies need permission under Indian law, which don’t, and what a banner has to do to make that permission count. Copying a banner built for a different law is how most Indian sites end up with something that looks compliant and isn’t.
Why cookies fall under a law that never names them
The DPDP Act doesn’t regulate “cookies” — it regulates personal data, and most cookies carry exactly that. Nowhere in the Act or its Rules is a cookie mentioned. What the Act governs is any data about an identifiable individual, and the persistent identifiers dropped by analytics, advertising and third-party cookies single out one device and one person over time. That makes them personal data in substance, whatever the technology is called. The practitioner consensus in India has settled here: treat tracking cookies as personal data, and the consent rules that apply to any other collection apply to them too. Because there’s no dedicated Indian cookie statute — no separate “cookie law” the way some read the EU’s ePrivacy regime — the obligation flows entirely from the DPDP Act’s general consent and notice duties, not from a cookie-specific rulebook.
Which cookies actually need consent
The line runs between cookies that make the site work and cookies that watch the visitor. Not every cookie needs a consent tick, and a banner that blocks the ones that don’t just annoys people for no legal gain. The practical split:
- Strictly necessary cookies — session login, a shopping cart, security tokens, load balancing. These are what the visitor asked for by using the site, so the stronger position is that they rest on legitimate use (Section 7) rather than needing a separate opt-in. They still belong in your notice; they just don’t gate behind a toggle.
- Non-essential cookies — analytics, advertising and retargeting pixels, embedded social widgets, A/B-testing and personalisation trackers. These serve your purposes, not the visitor’s immediate request, so they need free, specific, informed opt-in consent (Section 6) before they fire — not after the page has already loaded them.
The test isn’t the vendor or the file name; it’s the purpose. A first-party analytics cookie used only to count page loads and an advertising cookie that follows someone across sites are both “analytics” to a layperson and land on opposite sides of this line.
What goes wrong with a copied EU banner
A banner can display perfect consent language and still be non-compliant if the cookies loaded before anyone clicked. The failures cluster in a few predictable places. The most common is technical, not textual: the analytics and ad scripts are hardcoded in the page head and run on load, so by the time the banner appears the tracking has already happened and the “consent” is theatre. Close behind is the “Accept All” button with no equally prominent “Reject All” — burying rejection two clicks deep in a settings menu isn’t the free choice the Act requires. Then there are pre-ticked category boxes, which aren’t consent at all; consent has to be an affirmative act. And a banner that reappears identically on every visit, with no record of what the person chose, leaves you unable to prove consent was ever given — and the burden of proving valid consent sits on you, not the visitor.
Step by step: building a banner that holds up
Block first, ask clearly, record the answer.
- Inventory every cookie and tracker your site actually sets — including the ones your embeds and tag manager pull in without you noticing. You can’t ask consent for a list you don’t have. A browser dev-tools audit or a scanning tool surfaces the real set.
- Classify each one as strictly necessary or non-essential by its purpose, not its label. This classification is the whole basis of the banner; get it wrong and everything downstream is wrong.
- Block non-essential cookies until consent is given. This is the step copied banners skip. The tracking scripts must not run on page load — they fire only after the visitor opts in. A consent-management setup that only displays a banner while the scripts run regardless is not compliant.
- Give equal-weight choices. “Accept All” and “Reject All” as two buttons of the same prominence on the first layer, with a “Manage preferences” option for granular category control. No pre-ticked boxes.
- State the purpose in the notice layer — what each category does, who the third parties are, and how to change the choice later — in plain language, not a wall of vendor names.
- Record each visitor’s choice — which categories, when, and the banner version shown — so you can demonstrate consent if asked, and so you can honour a later withdrawal.
- Make withdrawal as easy as giving. A persistent, reachable way to reopen preferences and turn tracking off — withdrawing consent has to be as simple as granting it was.
Keeping consent valid as your tag list changes
A cookie banner is only accurate on the day you audited — every new tag silently ages it. Marketing adds a new pixel, a fresh embed arrives with its own trackers, the tag manager ships a vendor you never reviewed — and the banner still lists last quarter’s cookies. Make a cookie re-scan part of the same routine that adds any new third-party script, and re-run a full audit on a fixed interval. Because cookie treatment under the Act is still settling, keep an eye on how the position firms up as the Rules and Board guidance mature — this is one of the areas most likely to sharpen, and you’ll want your setup to move with it rather than lag.
FAQ
Does the DPDP Act have a specific cookie law?
No. There’s no standalone cookie provision or separate cookie regulation in India. Cookies are governed indirectly: the tracking identifiers they carry are personal data, so the Act’s general consent and notice rules apply. Anyone citing a dedicated “Indian cookie law” is describing the EU model, not this one.
Do I need consent for Google Analytics?
For analytics that set persistent, cross-session identifiers, the safer position is yes — treat it as non-essential and gate it behind opt-in. A strictly aggregate, first-party count with no individual identifier is a weaker case for requiring consent, but most standard analytics setups don’t stay that narrow.
Can I use one “Accept All” button to keep it simple?
Not on its own. Consent has to be a free choice, which means rejecting non-essential cookies must be as easy and prominent as accepting them. An “Accept All” with no equally visible “Reject All” doesn’t meet that bar.
Are strictly necessary cookies exempt from the banner?
They don’t need a consent toggle — the stronger position is that they rest on legitimate use — but they should still be disclosed in your notice. “Exempt from consent” is not “exempt from being told about.”
What happens if my trackers load before the visitor clicks?
Then consent was never real, because the collection already happened. The technical fix — blocking non-essential scripts until opt-in — is the part that actually makes the banner compliant, not the wording on it.