Teams that implemented Consent Mode v2 for Google's own enforcement deadline often assume it covers them for DPDP. It covers one layer of a four-layer obligation.
What does Consent Mode v2 actually do?
It defines consent states — most relevantly analytics_storage and ad_storage, plus ad_user_data and ad_personalization added in v2 — and communicates them to Google tags. Depending on your configuration, tags then either operate normally, or send cookieless pings, or do nothing.
That is genuinely useful. It is a transport layer for a decision, not the mechanism that makes the decision, records it, or proves it.
What DPDP requires that Consent Mode doesn't provide
Four requirements. Consent Mode addresses part of one.
1. A compliant notice. Rule 3 of the DPDP Rules requires the notice to be presented independently of any other information, in clear and plain language, with an itemised description of the personal data, the specified purpose with an itemised account of the goods, services or uses enabled, and the communication link to withdraw consent, exercise rights and complain to the Board. Consent Mode has no notice layer at all.
2. Consent meeting the section 6 standard. Free, specific, informed, unconditional and unambiguous, by clear affirmative action, limited to the data necessary for the purpose. Consent Mode consumes a decision; it does not collect one to a legal standard.
3. A retrievable record. Where a question arises, the Data Fiduciary must be able to demonstrate that notice was given and consent obtained in accordance with the Act. That means the specific consent event, the notice version shown, the language, the purposes accepted, the timestamp. Consent Mode does not store consent records — it passes state to tags. Nothing persists that you could produce eighteen months later.
4. Withdrawal with parity. Section 6(4) requires withdrawal to be as easy as giving. Consent Mode will faithfully transmit a withdrawal — if something in your stack gives the visitor a way to make one and updates the state.
| Requirement | Consent Mode v2 | What you still need |
|---|---|---|
| Notice content per Rule 3 | ✗ | A notice layer |
| Consent to the s. 6 standard | Partial — transmits, doesn't collect | A compliant capture mechanism |
| Retrievable consent record | ✗ | Versioned, timestamped storage |
| Withdrawal parity (s. 6(4)) | Transmits only | A withdrawal route and propagation |
| Non-Google tags | ✗ | Consent gating across all vendors |
| 22 Eighth Schedule languages | ✗ | Multi-language notice delivery |
The non-Google gap
This is the part most often missed. Consent Mode governs Google tags. It has no effect on Meta Pixel, LinkedIn Insight Tag, TikTok Pixel, Hotjar, Microsoft Clarity, Twitter/X Pixel, affiliate tracking, chat widgets, review platforms, A/B testing tools, session recording, or CRM tracking scripts.
On a typical Indian D2C or SaaS site, Google tags are a minority of the third-party requests. A correctly configured Consent Mode implementation alongside an ungated Meta Pixel is not compliant — it is selectively compliant, which is not a category the Act recognises.
Confirm which of these you are running before assuming Consent Mode covers it. → Check your own site in 10 minutes
The defaults problem
Enabling Consent Mode is not configuring it. The common failure is leaving defaults permissive so that measurement continues before a choice is made. Under section 6 that is processing without affirmative action, whatever the dashboard says.
For DPDP purposes the defensible configuration sets analytics_storage, ad_storage, ad_user_data and ad_personalization to denied by default, then updates on the consent event. Yes, this reduces the data you collect from visitors who decline. That is what consent means.
Gate every tag, not just the Google ones
Consiva integrates with your tag manager to pass consent state to Consent Mode, so your existing Google setup keeps working — while covering notice, capture, records and withdrawal for everything else.
Start Free on Consiva.ai — No Credit Card →What a DPDP-ready setup looks like
Layer 1 — Notice. Rule 3-compliant, presented independently, in the visitor's chosen language from the Eighth Schedule.
Layer 2 — Capture. Purpose-level, affirmative action, no bundling, no pre-ticked categories, reject with equal prominence to accept.
Layer 3 — Enforcement. Every tag gated on the consent signal — Google tags via Consent Mode, everything else via the container or direct integration.
Layer 4 — Record. Consent event stored with notice version, language, purposes, timestamp, and full state history including withdrawals.
Layer 5 — Withdrawal. A route with parity to the giving, propagating to every downstream system.
Consent Mode v2 is a component of Layer 3. It is a good component. It is one of five.
Frequently Asked Questions
No. It signals consent state to Google tags. It does not deliver a Rule 3 notice, collect consent to the section 6 standard, store a retrievable record, or govern non-Google tags.
Consent Mode transmits a decision to Google’s tags. A CMP delivers the notice, collects the decision to a legal standard, stores the record, enforces it across every vendor, and handles withdrawal.
No. It passes state to tags at runtime. Demonstrating that notice was given and consent obtained — which the Act requires of the Data Fiduciary — needs separate, persistent, versioned storage.
Setting the four consent types to denied by default and updating on the consent event is the defensible configuration, since section 6 requires clear affirmative action before processing.
No. It governs Google tags only. Non-Google trackers need gating through your tag manager or a direct CMP integration.
Fill the Other Four Layers — Free
Consiva provides Layers 1, 2, 4 and 5, and integrates with your tag manager for Layer 3 — one domain, 1,000 cookie consents a month, no credit card.