DPDP Act & Cookies: What Indian Organisations Must Fix Before May 2027
Understand how India’s DPDP Act applies to cookies, analytics and advertising trackers, what changes by 13 May 2027, and how websites should prepare.
INTRODUCTION:
India’s Digital Personal Data Protection Act, 2023 does not regulate a technology simply because it is called a “cookie”.
The real question is whether a cookie, pixel, SDK or similar tracker is being used to process digital personal data about an identifiable individual.
If it is, the website operator must identify a lawful ground for that processing under the DPDP Act. The two broad routes are consent and the “certain legitimate uses” specifically recognised by the Act. Where consent is relied upon, it must be free, specific, informed, unconditional and unambiguous, and must involve a clear affirmative action.
This distinction matters. A website should not simply copy a GDPR cookie banner and assume that it has solved DPDP compliance. It needs to understand what its trackers actually do, what personal data they process, why the processing occurs and which DPDP ground genuinely supports it.
Most of the substantive obligations relevant to this analysis are scheduled to commence on 13 May 2027.
Are cookies personal data under the DPDP Act?
Sometimes. Not automatically.
The DPDP Act defines personal data as data about an individual who is identifiable by or in relation to that data. It applies to digital personal data processed in India and, in certain circumstances, processing outside India connected with offering goods or services to Data Principals in India.
That means the legal analysis should focus on the data and processing, rather than the word “cookie”.
A cookie or tracking technology is more likely to involve personal data when it contains or contributes to information such as an account identifier, device or browser identifier, browsing history, behavioural profile, persistent analytics identifier or another signal that can be related to an identifiable individual.
By contrast, a purely technical value that cannot identify or be related to an individual may fall outside the definition of personal data.
The practical mistake is therefore to ask:
“Is this a necessary cookie or an analytics cookie?”
before asking the more important questions:
“What information does it process? Can that information relate to an identifiable individual? For what purpose are we processing it?”
The DPDP Act does not create four legal categories of cookies
Websites commonly classify cookies as necessary, functional, analytics and advertising cookies. That taxonomy is useful operationally, but it should not be mistaken for statutory language.
The DPDP Act itself does not establish those four cookie categories. Its legal structure focuses instead on personal data, purpose and the ground for processing. Section 4 permits processing for a lawful purpose where the Data Principal has consented or where one of the Act’s “certain legitimate uses” applies.
A useful operational approach looks like this:
Typical tracker What it may do DPDP question Session/security cookie Maintain login, cart state or security controls Does it process personal data, and if so, does a Section 7 use apply or is consent required? Preference cookie Remember language, region or settings Does the preference relate to an identifiable user, and what ground supports storing it? Analytics tracker Measure visits, journeys, conversions or behaviour Does the configuration create or use identifiable/persistent user-level data? Advertising tracker Retarget users, profile interests or measure ad audiences What personal data is processed, for what advertising purpose, and has valid consent been obtained where consent is the applicable ground? This is more defensible than declaring in advance that every “necessary” cookie is exempt and every “analytics” cookie necessarily requires consent.
What about strictly necessary cookies?
This area needs more care than many cookie-compliance articles suggest.
Section 7(a) of the DPDP Act permits processing for the specified purpose for which a Data Principal has voluntarily provided personal data, provided the individual has not indicated that she does not consent to its use for that purpose. The Act gives examples such as a customer voluntarily providing information so that a receipt can be sent or an individual giving information to a property broker to identify accommodation.
That provision can be relevant to some service-delivery processing, but it is not a blanket statutory exemption for anything labelled “strictly necessary”.
For example, a session identifier used after a person signs into an account may present a different analysis from an advertising identifier placed automatically on a first visit.
Some purely technical cookies may not involve personal data at all. Others may involve personal data but potentially fit a legitimate-use scenario. Others will need consent.
PrivacyTru’s recommended approach is therefore to document the reasoning for each important tracker rather than treating the cookie category itself as the legal basis.
Analytics and advertising trackers require closer scrutiny
Analytics is not inherently unlawful under the DPDP Act, nor does the Act name Google Analytics, Meta Pixel or any other analytics platform as automatically requiring consent.
Configuration matters.
If an analytics or advertising implementation uses persistent identifiers, combines data across sessions, associates activity with an account or device, or otherwise processes information about an identifiable person, the DPDP Act is engaged. The organisation then needs a valid ground under Section 4.
For behavioural advertising and cross-site tracking, relying on consent will often be the more defensible route where no specific Section 7 use applies. In such cases, the tracker should not begin consent-dependent personal-data processing before valid consent has been obtained.
This is also why organisations should audit tags and pixels, not merely the browser’s visible cookie list. Modern tracking can occur through scripts, local storage, SDKs, server-side integrations and other mechanisms.
What valid consent means under the DPDP Act
Where consent is the ground for processing, Section 6 sets a meaningful standard.
Consent must be free, specific, informed, unconditional and unambiguous, involve a clear affirmative action, relate to the specified purpose, and be limited to personal data necessary for that purpose.
That has direct implications for website design.
A banner that merely says “By continuing to use this website, you agree…” presents a significant problem where the organisation is relying on consent: continued browsing is not the clean affirmative action contemplated by Section 6.
Similarly, pre-enabling consent-dependent purposes and asking a user to opt out later is difficult to reconcile with a requirement for clear affirmative action.
The better design is to let the user make a deliberate choice before consent-dependent processing begins.
What should a DPDP-ready cookie notice contain?
Section 5 requires a consent request to be accompanied or preceded by notice describing the personal data and purpose of processing, how the Data Principal may exercise relevant rights and how a complaint may be made to the Board. Section 5 also requires an option to access the notice in English or a language specified in the Eighth Schedule to the Constitution.
The notified DPDP Rules, 2025 further operationalise the notice framework, including clear, independently understandable information about the personal data and specified purposes. The Rules form part of the phased implementation framework notified in November 2025.
For websites, this means the cookie or tracker notice should do more than say:
“we use cookies to improve your experience.”
A useful notice should tell the individual, in plain language, what categories of information are being processed and what those trackers actually enable.
For example:
Analytics: “Measure how visitors use our website so that we can understand page performance and user journeys.”
is more meaningful than:
Analytics: “Helps us improve services.”
Specificity matters.
Accept All, Reject All and Manage Preferences: what does the law actually require?
The DPDP Act does not prescribe particular button labels such as “Accept All”, “Reject All” or “Save Preferences”.
Those are interface choices.
What matters legally is whether consent is genuinely free, specific, informed and unambiguous, and whether withdrawal is as easy as giving consent. Section 6 expressly gives Data Principals the right to withdraw consent at any time with comparable ease.
In practice, a well-designed consent interface often provides a clear way to accept relevant optional processing, reject it and manage individual preferences.
PrivacyTru would also advise against manipulating users through confusing hierarchy, hidden rejection options, misleading wording or unnecessary friction. India’s consumer-protection framework separately includes the Guidelines for Prevention and Regulation of Dark Patterns, 2023, so interface design should be considered from both privacy and consumer-protection perspectives.
The important distinction is that “the three buttons must be exactly equally prominent” should be treated as a prudent design recommendation—not quoted as though those exact words appear in the DPDP Act.
Consent withdrawal cannot be an afterthought
The right to withdraw consent has major technical consequences for websites.
Where processing depends on consent and the Data Principal withdraws it, the Data Fiduciary must cease that processing within a reasonable time and cause its Data Processors to cease as well, unless continued processing is otherwise authorised by law.
A website therefore needs more than a first-visit banner.
It needs a durable way for users to reopen their choices. A footer link such as Privacy Choices or Manage Cookies is one practical implementation.
The technical layer should then actually respect the changed choice. A beautifully designed preference centre is of little value if advertising tags continue firing after withdrawal.
Why evidence of consent matters?
Consent management is not only a user-interface exercise.
Section 6(10) places an important evidentiary responsibility on the Data Fiduciary. If consent is the basis of processing and the issue arises in a proceeding, the Data Fiduciary must be able to prove that the required notice was given and that valid consent was obtained.
That makes consent evidence operationally important.
A mature implementation should therefore be capable of showing what choice was made, the purposes covered by that choice, when it occurred, and which relevant notice or configuration applied at the time.
The objective is not to collect excessive evidence about the user. It is to maintain sufficient accountability for the consent on which the organisation relies.
A seven-step website readiness plan before 13 May 2027
- Inventory tracking technologies. Identify cookies, pixels, tags, analytics tools, local-storage items, advertising scripts and material third-party embeds across the website—not only on the homepage.
- Map the data behind each tracker. Record what information is collected or generated, whether it can relate to an identifiable person, its purpose, recipients or third parties, and relevant retention behaviour.
- Determine the DPDP ground for processing. Do not assign the legal basis merely from the cookie category. Assess consent versus the specific legitimate uses available under Section 7.
- Redesign consent-dependent deployment. Where consent is required, prevent that personal-data processing from beginning before the user has taken the necessary affirmative action.
- Rewrite the notice and preference experience. Explain personal data and purposes clearly, provide meaningful choices, support required language access and avoid manipulative interface patterns.
- Build withdrawal and evidence into the system. Users should be able to revisit choices, while the organisation retains appropriate evidence of the notice and consent on which it relied.
- Create change control for future trackers. Reassess the website when marketing tools, analytics configurations, embeds, tag-manager containers or material site functionality changes. The DPDP Act does not prescribe a universal “quarterly cookie audit”, so the review cadence should reflect the organisation’s technology and risk profile.
One issue websites serving children should not overlook
The DPDP Act creates separate obligations around children’s personal data.
Among other things, Section 9 restricts tracking or behavioural monitoring of children and targeted advertising directed at children, subject to the exemptions permitted by the Act and Rules.
Websites, apps and online services that are likely to be used by children should therefore not treat their cookie review as an ordinary marketing-consent exercise. Age-related processing and tracking practices require a separate assessment.
A cookie CMP is not automatically a DPDP “Consent Manager”
This distinction is increasingly important.
The DPDP Act defines a Consent Manager as a person registered with the Data Protection Board that enables a Data Principal to give, manage, review and withdraw consent through an accessible, transparent and interoperable platform. The Act and Rules establish a specific statutory and registration framework for that role.
A commercial cookie consent management platform, often called a CMP, is a technical product used by a website to collect preferences or control tags.
The two concepts should not be used interchangeably.
A website may use a CMP without that vendor being a statutory Consent Manager under the DPDP Act.
What penalties can apply?
Cookie compliance does not have its own standalone penalty table.
Penalties depend on the provision that has been breached.
Under the Act’s Schedule, breach of “any other provision” of the Act or Rules can attract a penalty of up to ₹50 crore. Separately, failure to take reasonable security safeguards to prevent a personal data breach can attract up to ₹250 crore, while failure to notify the Board or affected Data Principals of a personal data breach can attract up to ₹200 crore.
It is therefore misleading to say that an ordinary defective cookie banner itself automatically attracts a ₹250 crore penalty.
The precise issue, processing activity and statutory breach matter.
Frequently asked questions
Do all cookies require consent under the DPDP Act?
No. First determine whether the cookie or associated technology processes digital personal data. If it does, identify whether consent or one of the Act’s certain legitimate uses supports the processing. The label attached to the cookie does not decide the legal answer.
Do strictly necessary cookies always fall under legitimate use?
No blanket exemption appears in the DPDP Act merely because a cookie is described as “strictly necessary”. Some technical cookies may not process personal data; some service-related processing may potentially fit a Section 7 use; other processing may require consent. The facts and purpose need to be assessed.
Does Google Analytics automatically require consent under the DPDP Act?
The Act does not name Google Analytics or establish a product-specific rule. The correct approach is to analyse the particular configuration and the personal data being processed. Where identifiable or persistent user-level analytics data is processed and no Section 7 use applies, consent may be the appropriate ground.
Can non-essential trackers load before the user answers the banner?
If the processing relies on consent, the organisation should not begin that consent-dependent personal-data processing before valid consent exists. Section 6 requires an affirmative action where consent is the basis.
Are cookie walls expressly prohibited?
The DPDP Act does not contain a provision simply stating “cookie walls are prohibited”. However, where consent is relied upon, the organisation must still demonstrate that consent was free, specific, informed, unconditional and unambiguous. A design that makes unnecessary tracking a condition for unrelated access should therefore be assessed carefully rather than assumed to produce valid consent.
How often should a website perform a cookie audit?
There is no universal quarterly cookie-audit interval prescribed by the DPDP Act. A better operational approach is risk-based monitoring, with reassessment after material changes to the website, tag manager, advertising stack, analytics configuration or third-party integrations.
What is the DPDP compliance date websites should plan around?
For the main processing, notice, consent and Data Fiduciary obligations relevant to website tracking, the statutory commencement notification provides an 18-month implementation period from 13 November 2025. That places the key date at 13 May 2027.
How PrivacyTru approaches website and tracker compliance
Cookie compliance should not begin with a banner.
It should begin with understanding the processing.
PrivacyTru’s approach is to connect the technical website layer with the organisation’s wider DPDP programme: identify tracking technologies, map personal data and purposes, assess the applicable processing ground, review third parties, design appropriate notices and consent journeys, establish withdrawal and evidence mechanisms, and connect website findings to the broader remediation programme.
That approach is deliberately different from installing a consent banner and declaring the website compliant.
A banner is only the interface.
Compliance depends on whether the processing behind it actually follows the choice the user made.
Preparing before May 2027
13 May 2027 should not be treated as the day organisations begin examining their websites.
A proper tracker review can expose dependencies across marketing, analytics, advertising agencies, tag management, web development, security, legal and privacy teams. Those dependencies take time to resolve.
For organisations operating significant digital properties, the useful question today is not:
“Do we have a cookie banner?”
It is:
“Can we explain every material tracker on our website, the personal data it processes, why we process it, what ground supports that processing, and what happens when the user says no?”
If the answer is unclear, the compliance work has already identified where to begin.
About PrivacyTru
PrivacyTru helps organisations operationalise data privacy and DPDP compliance by connecting legal requirements with practical governance, processes, technology and evidence.
This article provides general information and does not constitute legal advice. Applicability should be assessed against the facts of each organisation and processing activity.
