The DPDP Act never mentions cookies, but personal-data rules still apply when they identify a user. Owners must audit purpose, not just labels.
Run a search for the word "cookie" inside India's Digital Personal Data Protection Act, 2023, and you'll get nothing.
Zero matches.
Some website owners read that silence as a green light โ if the law doesn't name the technology, surely it doesn't regulate it. That reading is exactly backwards, and it's worth understanding why before it becomes an expensive assumption.
The Act Doesn't Regulate Technology. It Regulates What the Technology Does.
The DPDP Act was written to govern an activity, not a tool.
That activity is the processing of personal data by a data fiduciary about a data principal โ language that sounds abstract until you realise a cookie can trigger it without ever collecting a name.
Section 2(t) defines personal data as data about an individual who is identifiable by or in relation to that data. A cookie that assigns a visitor a unique ID, logs their device details, or tracks their movement across a site can meet that definition just as easily as a signup form can. The absence of a name in the data doesn't automatically mean the absence of an identifiable person behind it.
This is a deliberate design choice, not an oversight. Cookies are one tracking mechanism among many, and lawmakers had little reason to hard-code a 1990s browser feature into 2023 legislation when newer methods โ fingerprinting, server-side IDs, embedded SDKs โ already existed and more will follow. A law tied to a specific technology ages badly. A law tied to an activity doesn't.
The Digital Personal Data Protection Rules, 2025, notified by MeitY on 14 November 2025, reinforce this same logic. They don't list cookies either. Instead, they specify what a valid notice and consent process has to look like โ regardless of which technology is doing the collecting.
Same Word, Different Risk: Why "Cookie" Isn't a Useful Category
Two cookies can sit on the same page and carry entirely different weight under the law.
One remembers that a returning visitor prefers the site in Marathi. The other assigns that same visitor a persistent ID, records every article they read over several weeks, and passes that reading history to an ad network for retargeting.
Both get called "cookies" in a browser's dev tools. Only one of them is quietly building an identifiable profile of a person's behaviour โ and that's the one the DPDP Act cares about. This is precisely why sorting cookies by name or by which team installed them tells you very little. A cookie labelled lang_pref might do nothing risky at all, while one labelled session_util could be feeding data to a third-party analytics vendor nobody on the compliance team has ever heard of.
Most organisations don't discover this by design โ they discover it by accident. A vendor's tracking pixel arrives bundled inside a chatbot plugin. A redesign quietly swaps one analytics tool for another with different data-sharing defaults. None of it happens with a compliance sign-off, which is exactly the point: the question that matters is what data a cookie processes and why โ never what it's called.
Is a Cookie Banner Legally Required in India?
Partially โ and the honest answer sits between two overused claims.
India has no dedicated cookie law the way the EU's ePrivacy rules operate. The DPDP Act doesn't specify a banner format, a button colour, or a mandatory pop-up. So "every website legally needs a cookie banner" overstates the position.
But "cookies aren't named in the Act, so no consent is required" is the more dangerous claim, because it's wrong in the cases that matter most. Wherever a cookie processes personal data, the DPDP Act's obligations around notice, consent, purpose limitation, and a data principal's rights apply โ with or without a banner enforcing them.
The practical takeaway: don't start by asking whether you need a banner. Start by asking whether your cookies process personal data. The banner is simply how you operationalise the answer.
What Falls Under Scrutiny โ and What Doesn't
Not every cookie deserves equal attention. As a working filter:
CategoryTypical purposeCompliance weightStrictly necessaryLogin sessions, carts, securityGenerally lower โ but still document it, don't assumeAnalyticsPage views, session length, device dataDepends entirely on whether outputs are identifiableAdvertising/trackingBehavioural profiling, cross-site targetingHighest โ this is where consent obligations bite hardestPersonalisationLanguage, saved preferencesUsually low, but verify what's actually collected
This table is a starting filter, not a final answer. The only way to know which row a specific cookie belongs in is to look at what it actually sends, and where.
Why the Deadline Isn't as Far Off as It Looks
The substantive parts of the DPDP framework โ the notice and consent obligations that touch cookies directly โ carry an 18-month transition period from the Rules' notification, landing around 13 May 2027. That sounds distant. It isn't, once you account for how long a proper audit, banner redesign, and vendor review actually take inside most organisations.
Waiting until the deadline approaches means compressing months of discovery work into weeks. Starting now means the compliance work happens on your timeline instead of the regulator's.
Two things follow naturally from here, and we'll cover both in this series: building a complete inventory of every cookie actually running on your site, and testing whether your existing consent banner meets the DPDP Act's standard in practice, not just in appearance.
The Real Question Behind the Cookie Question
Website owners who can't answer what their trackers collect, where the data travels, and how a user withdraws consent aren't facing a cookie problem. They're facing a visibility problem that happens to show up in a cookie banner first. Fixing the banner without fixing the visibility gap behind it treats the symptom, not the cause.