How to Create a DPDP-Compliant Cookie Consent Banner

If you've ever opened your browser's DevTools, navigated to the Application tab, and looked at the cookies your site drops on first load, you've probably seen a list that's longer than you expected. Session IDs. Analytics trackers. Ad retargeting pixels. Third-party widgets that inject their own cookies before your page even finishes rendering.

Under the DPDP Act 2023, every one of those cookies that collects or processes personal data now needs explicit, informed, opt-in consent from your users before it fires. Not after. Not alongside. Before.

The Act does not mention the word "cookie" anywhere in its text. But it does not need to. Cookies collect IP addresses, device identifiers, browsing behaviour, and user preferences. All of that qualifies as personal data under Section 2(t) of the DPDP Act. And once something is personal data, the entire consent framework of Sections 5, 6, and 7 applies to it.

This post walks through how to build a cookie consent banner that actually satisfies those requirements, from classifying your cookies to implementing a consent mechanism that holds up to regulatory scrutiny.

Key Takeaways

• The DPDP Act 2023 requires opt-in consent for any cookie that collects or processes personal data. Pre-ticked boxes, implied consent from continued browsing, and "accept all" as the only option are non-compliant.
• Essential cookies required for basic site functionality may qualify as "legitimate uses" under Section 7 of the DPDP Act and can fire without consent. Analytics, advertising, and personalisation cookies cannot.
• A compliant banner must provide granular category-level controls, clear purpose descriptions, and a withdrawal mechanism that is as easy to use as the original consent action.
• Consent records (who consented, to what, when, and how) must be logged and retained. These records are your proof of compliance during a DPBI audit.
• As of February 2026, the DPDP Rules 2025 do not prescribe a specific banner design. The requirements are functional: informed notice, affirmative action, granularity, and withdrawal capability.

Why Does India Need Cookie Consent Banners Under DPDP?

If you have spent any time building products for European markets, you are familiar with the GDPR cookie consent pattern: a banner appears, the user selects their preferences, and non-essential cookies are blocked until consent is recorded. India's DPDP Act 2023 creates a similar obligation, though with some structural differences worth understanding.

The DPDP Act establishes consent as the primary legal basis for processing personal data (Section 6). It requires a notice to the Data Principal before processing begins (Section 5). And it carves out a limited set of "legitimate uses" where consent is not required (Section 7).

Cookies sit squarely inside this framework. When a user visits your site and your analytics script drops a cookie that tracks their browsing pattern, you are processing personal data. The question is whether you had a valid legal basis to do so.

For a full breakdown of Data Fiduciary obligations including consent, see our guide to Data Fiduciary roles under DPDP.

How Should You Classify Cookies Under DPDP?

Before you build anything, you need to audit your site and classify every cookie into one of four categories. This classification determines which cookies need consent and which do not.

Cookie Category	Examples	Consent Required?	Legal Basis
Essential / Strictly Necessary	Session IDs, authentication tokens, CSRF tokens, load balancer cookies, shopping cart state	No (with conditions)	Section 7, DPDP Act 2023 (legitimate use: necessary for service provision)
Functional	Language preferences, theme settings, saved form inputs, region selection	Yes	Section 6, DPDP Act 2023 (consent required; these enhance experience but are not strictly necessary)
Analytics / Performance	Google Analytics (_ga, _gid), Hotjar, Clarity, Mixpanel tracking	Yes	Section 6, DPDP Act 2023
Advertising / Targeting	Google Ads (_gcl_au), Meta Pixel (_fbp), retargeting cookies, cross-site tracking	Yes	Section 6, DPDP Act 2023

A few implementation notes on this classification.

Essential cookies get a narrow exemption. The argument is that Section 7 of the DPDP Act permits processing without consent for "legitimate uses," which includes processing that is necessary for the Data Principal to receive a service they explicitly requested. A session cookie that keeps a user logged in qualifies. An analytics cookie that measures aggregate traffic does not, even if you consider it important for running your business.

The line between "functional" and "essential" trips up a lot of teams. A language preference cookie might feel essential to your product team. From the DPDP's perspective, it enhances the experience but is not required for the service to function. When in doubt, classify conservatively. You can always relax the classification later; reclassifying something from "essential" to "requires consent" after a regulatory inquiry is a much worse conversation.

For a deeper look at when consent is not required, our post on legitimate uses under DPDP covers the complete framework.

What Must the Consent Banner Include?

Section 5 of the DPDP Act requires a notice to the Data Principal before processing begins. Section 6 specifies that consent must be free, specific, informed, unconditional, and unambiguous, given through a clear affirmative action.

Translated into banner requirements, here is what you need:

1. Clear Purpose Descriptions

For each cookie category, tell the user what data the cookies collect and why. "We use cookies to improve your experience" does not satisfy Section 5. That sentence tells the user nothing about what data is collected, who processes it, or what purpose it serves.

A compliant description looks more like: "Analytics cookies collect anonymised usage data (pages visited, time on site, device type) to help us understand how visitors use our site. This data is processed by Google Analytics and stored for 14 months."

2. Granular Category Controls

The user must be able to accept or reject each cookie category independently. An "Accept All" button is fine only if a "Reject All" or "Manage Preferences" option is equally prominent. Section 6(1)(a) of the DPDP Act specifies that consent must be "free," given without "deceptive or manipulative practice." A banner that makes "Accept All" a large green button and buries the reject option in grey text below the fold would fail this test.

Here is the minimum control set:

• Essential cookies: On by default, non-toggleable (with a clear explanation of why)
• Functional cookies: Off by default, user toggles on
• Analytics cookies: Off by default, user toggles on
• Advertising cookies: Off by default, user toggles on

3. Affirmative Action, Not Passive Agreement

Pre-ticked checkboxes do not constitute consent under Section 6(1)(e). The consent must be "unambiguous" and "expressed by way of any clear affirmative action and not by mere inaction or disengagement." This means:

• Scrolling past the banner is not consent
• Continuing to browse is not consent
• A pre-checked "I agree" box is not consent
• Clicking an explicit "Accept Selected" or "Accept All" button is consent

4. Withdrawal Mechanism

Section 6(1)(f) of the DPDP Act states that consent must come "with the option to withdraw: as easily as it may be given." If your banner lets users consent with a single click, they must be able to withdraw with the same effort.

In practice, this means a persistent cookie settings link (typically in the footer) that reopens the preference panel and lets users modify their choices. When a user withdraws consent for a category, the associated cookies must be cleared and the corresponding scripts must stop firing.

I have seen implementations where the "Manage Cookies" link exists but only displays the current settings without letting users change them. That does not satisfy the withdrawal requirement.

5. Multilingual Support

Section 5(3) of the DPDP Act requires that notices be available in English and the languages specified in the Eighth Schedule to the Constitution. That is 22 languages. Your cookie banner does not need to support all 22 on day one, but it should at least cover the languages your audience uses. For most Indian websites with national traffic, Hindi and English are the minimum; regional-focused sites should add the relevant regional language.

How Should You Handle the Technical Implementation?

The implementation challenge with cookie consent is not the banner UI. That is the easy part. The hard part is ensuring that cookies are actually blocked until consent is recorded, and that they are cleared when consent is withdrawn.

The Consent-Before-Cookies Pattern

The correct implementation blocks all non-essential cookie scripts from loading until the user has made a choice. This is the fundamental architectural decision. There are two approaches:

Approach 1: Script attribute modification. Add a type="text/plain" attribute to all non-essential script tags, preventing the browser from executing them. When the user grants consent for a category, your consent manager changes the type back to text/javascript and the scripts load.

Approach 2: Tag manager integration. Use Google Tag Manager (or equivalent) with a consent-aware configuration. Tags are grouped by consent category and only fire when the corresponding consent signal is present. This is the approach most teams end up using because it scales better.

If you are using Google Tag Manager with Google Analytics or Google Ads, you will also need to implement Google Consent Mode v2 to ensure your Google tags respect the consent state. We will cover that integration in detail in a future post.

Consent State Management

Your consent banner needs to persist the user's choice across sessions. The typical approach is storing the consent state in a first-party cookie (yes, the irony is acknowledged) with the following structure:

• Consent ID: A unique identifier for this specific consent event
• Timestamp: When consent was given or modified
• Categories accepted: Which cookie categories the user opted into
• Categories rejected: Which categories the user explicitly declined
• Version: The version of your consent notice (so you can re-prompt when the notice changes)

When the user returns, read this cookie before loading any scripts. If the consent cookie is absent or expired, show the banner again. If it is present, load only the categories the user approved.

Consent Record Logging

This is the part most implementations skip, and it is the part that matters most during an audit.

The DPDP Rules 2025 require Data Fiduciaries to maintain records of consent. For cookie consent, that means logging:

Record Field	What to Store	Why It Matters
Consent ID	UUID linking the consent event to the user session	Unique identification for audit trail
Timestamp	ISO 8601 datetime of consent action	Proves when consent was obtained
IP address (hashed)	Hashed IP for verification without storing raw PII	Links consent to a session without excessive data collection
Categories consented	Array of accepted categories (e.g., ["analytics", "functional"])	Proves what the user agreed to
Notice version	Version hash of the consent notice text shown	Proves the user saw the current notice, not an outdated one
Action taken	accept_all, accept_selected, reject_all, withdraw	Distinguishes between consent types
User agent	Browser and device information	Context for the consent event

Store these records server-side, not just in a client-side cookie. A cookie can be cleared by the user. Your compliance evidence should not depend on the user's browser cache.

For how consent records fit into your broader compliance documentation, see our DPDP compliance checklist.

What Are the Common Mistakes in Cookie Consent Implementation?

Having worked on consent implementations across multiple products, these are the patterns I see teams get wrong repeatedly.

Mistake 1: Loading analytics before consent. Your Google Analytics tag fires on page load, then the consent banner appears. By the time the user clicks "Reject," you have already collected their data. This is the most common technical violation, and it often happens because the analytics tag was added directly to the HTML head before the consent system was integrated. Move it behind your tag manager's consent gate.

Mistake 2: Treating consent as a one-time event. You collect consent today. Six months later, you add a new advertising pixel and update your cookie notice. That user's original consent does not cover the new purpose. Section 6(1)(b) of the DPDP Act requires consent to be "specific: not for more than the specified purpose and, if the purpose changes, then a fresh consent shall be obtained." Version your consent notice. When the version changes, re-prompt users who consented to the old version.

Mistake 3: No withdrawal mechanism, or a broken one. The "Manage Cookies" link in your footer opens a modal, but the toggles do not actually clear the cookies when switched off. Or worse, the link returns a 404 because nobody tested it after the last deployment. Test your withdrawal flow on every release.

Mistake 4: Cookie wall (blocking access until consent). Some implementations refuse to show any content until the user accepts cookies. Section 6(1)(a) prohibits making consent "a precondition for the provision of any good or service." If your site blocks access to content unless the user accepts all cookies, that is non-compliant. Users must be able to use your site with only essential cookies.

Mistake 5: Not accounting for third-party cookies. Your consent banner manages the cookies your site sets directly. But what about the cookies dropped by embedded third-party widgets: a chat widget, a social media embed, a payment provider's iframe? Each of these may inject cookies before your consent system has a chance to intervene. Audit your third-party integrations and ensure they respect the consent state, either through their own consent APIs or by lazy-loading them only after consent is granted.

DPDP Cookie Consent vs. GDPR Cookie Consent: What is Different?

If you have already built GDPR-compliant cookie consent (for European visitors or because you are an Indian SaaS with EU customers), here is how the DPDP requirements compare.

Dimension	GDPR (EU)	DPDP Act 2023 (India)
Explicit cookie mention	Yes, via ePrivacy Directive	No. Cookies are covered as "personal data" under Section 2(t)
Consent standard	Freely given, specific, informed, unambiguous (GDPR Art. 7)	Free, specific, informed, unconditional, unambiguous (Section 6(1))
Essential cookie exemption	Yes (strictly necessary cookies under ePrivacy)	Yes (arguable under Section 7 "legitimate uses")
Withdrawal requirement	Must be as easy as giving consent (GDPR Art. 7(3))	Must be as easy as giving consent (Section 6(1)(f))
Granularity required	Purpose-level granularity expected	Category-level granularity expected
Language requirements	Local language of the member state	English + languages from the Eighth Schedule (22 languages)
Pre-ticked boxes	Explicitly banned (Planet49, CJEU)	Banned via "clear affirmative action" requirement
Penalty for non-compliance	Up to €20M or 4% global turnover	Up to ₹250 crore (approximately €27M at current exchange rates)
Cookie wall legality	Generally prohibited (EDPB guidelines)	Prohibited (consent cannot be precondition for service, Section 6(1)(a))
Enforcement status	Active since 2018, significant enforcement history	Enforcement expected from May 2027

The structural similarity is deliberate. The DPDP Act borrowed heavily from GDPR's consent framework. If your existing GDPR consent implementation is solid, adapting it for DPDP is largely a matter of adding multilingual support, ensuring your legitimate use classification aligns with Section 7 rather than GDPR Article 6(1)(f), and adjusting your consent records to match whatever format the DPBI eventually prescribes.

For a full comparison of the two frameworks, see our DPDP Act 2023 complete guide, which covers the broader regulatory differences beyond cookies.

A Practical Implementation Checklist

Here is a condensed checklist for getting your cookie consent banner to a compliant state. This is not comprehensive compliance guidance; it is the technical implementation minimum.

Cookie audit and classification:

• Run a full scan of all cookies your site sets (use browser DevTools or a scanning tool)
• Classify each cookie into Essential, Functional, Analytics, or Advertising
• Document each cookie: name, purpose, duration, domain, and category
• Identify third-party scripts that set cookies and map them to categories
• Review "essential" classifications critically. If a cookie is not required for the site to function for the user, it is not essential

Banner implementation:

• Display the banner before any non-essential cookies are set
• Include clear, specific purpose descriptions for each category
• Provide category-level toggle controls (off by default for non-essential categories)
• Make "Accept All" and "Reject All" equally prominent
• Ensure consent is recorded through a clear affirmative action (no pre-ticked boxes)
• Block all non-essential scripts until the user has made a choice

Withdrawal and persistence:

• Add a persistent "Cookie Settings" link in the site footer
• Ensure the link reopens the preference panel with current settings displayed
• When consent is withdrawn, clear the associated cookies and stop script execution
• Store consent state in a first-party cookie with version tracking
• Re-prompt users when the consent notice version changes

Consent records:

• Log consent events server-side with: consent ID, timestamp, categories, notice version, action
• Retain consent records for the duration required by your data retention policy
• Ensure records are retrievable for DPBI audits

Language and accessibility:

• Support Hindi and English at minimum
• Add regional languages based on your audience demographics
• Ensure the banner is accessible via keyboard navigation and screen readers

Frequently Asked Questions

Does the DPDP Act specifically require cookie consent banners?

The DPDP Act 2023 does not mention "cookies" or "cookie consent banners" by name. However, Section 5 requires notice before processing personal data, and Section 6 requires informed, opt-in consent for processing. Since cookies that collect data such as IP addresses, browsing behaviour, and device identifiers are processing personal data under Section 2(t), the consent requirements apply. A cookie consent banner is the standard mechanism for fulfilling these requirements on websites. As of February 2026, the DPDP Rules 2025 do not prescribe a specific banner format or design.

Can I use a single "Accept All" button without category-level options?

No. Section 6(1)(b) of the DPDP Act requires consent to be "specific," meaning the user should understand and agree to each distinct purpose. A single "Accept All" button without any alternative (such as "Reject All" or "Manage Preferences") also raises concerns under Section 6(1)(a), which prohibits consent obtained through "deceptive or manipulative practice." Providing only one large "Accept All" button with no equally accessible alternative could be interpreted as a manipulative pattern.

Do essential cookies need consent under DPDP?

Strictly necessary cookies, those required for basic website functionality like session management and authentication, may be processed without consent under Section 7 of the DPDP Act (legitimate uses). The argument is that the Data Principal has voluntarily requested a service, and the cookie is necessary to provide it. However, the classification must be defensible: a cookie that tracks user behaviour for analytics purposes does not qualify as essential, even if your development team considers it operationally important.

How long should I retain cookie consent records?

The DPDP Act 2023 requires Data Fiduciaries to retain personal data only for the purpose for which it was collected and to erase it once the purpose is fulfilled. For consent records specifically, retain them for at least as long as the consent they document is active, plus a reasonable period afterward to defend against any regulatory inquiry. Many organisations default to 3 to 7 years. The DPDP Rules 2025 do not prescribe a specific retention period for consent records as of February 2026.

Does continued browsing count as consent under DPDP?

No. Section 6(1)(e) of the DPDP Act explicitly requires consent to be "expressed by way of any clear affirmative action and not by mere inaction or disengagement." Scrolling, continuing to browse, or simply not interacting with the consent banner does not constitute valid consent. The user must take an explicit action, such as clicking an "Accept" button.

Simplify Your DPDP Compliance

This article is for informational purposes and reflects the DPDP Act 2023 and DPDP Rules 2025 as understood at the time of writing. For guidance specific to your business, we recommend consulting a qualified data protection professional.

Implementing a compliant cookie consent banner is one piece of a larger compliance puzzle: privacy notices, DSR handling, consent records, and data processing agreements all need to work together. ComplyZero's self-serve platform helps Indian businesses implement DPDP compliance in minutes, not months, with automated consent management, privacy notices in 22 Indian languages, and audit-ready compliance records that hold up when regulators come asking.

Join the waitlist to get early access before enforcement begins in May 2027.