A lot of cookie advice online is really GDPR advice with “India” added to the title.
That creates a problem.
The Digital Personal Data Protection Act regulates processing of digital personal data. A cookie is a technology, not a legal category by itself. Some cookies may be strictly functional. Others may involve identifiers, profiles, behavioural information, analytics, advertising, or other processing of personal data.
The right question is therefore not:
“Does India require a cookie banner?”
It is:
“What personal-data processing happens through our cookies and trackers, and what legal route applies to that processing?”
Start by inventorying the browser traffic
Open your website in a clean browser session and inspect network traffic.
List:
- First-party cookies
- Third-party cookies
- Local storage identifiers
- Analytics tags
- Advertising pixels
- Session-recording tools
- Tag managers
- SDKs and embedded services
Then classify each one.
| Technology | Purpose | Personal data involved? | Vendor | Legal route |
|---|---|---|---|---|
| Session cookie | Authentication | Potentially | First party | Depends on processing |
| Analytics ID | Product analytics | Often | Analytics vendor | Depends on processing |
| Ad pixel | Behavioural advertising | Often | Ad network | Usually requires careful consent analysis |
| Preference cookie | Remember settings | Depends | First party | Depends on processing |
Do not make every row “consent required” without analysing the underlying processing.
Why the banner is not the compliance system
A banner can do three things well:
- Present information
- Capture a user choice
- Store the choice
But the hard part is what happens afterwards.
Suppose a user declines marketing tracking.
Banner
↓
Preference recorded
↓
Tag manager
↓
Advertising pixel
↓
Analytics platform
If the pixel fires anyway, your UI is lying about the control it gave the user.
This is the same propagation problem that appears in broader DPDP consent architecture.
What a serious implementation should track
For each purpose, your system should know:
- Purpose name
- Notice shown
- User action
- Timestamp
- Preference state
- Relevant jurisdiction or product context
- Downstream systems that depend on that state
This is much more useful than a single cookie named consent=true.
Equal choice and dark patterns
The UI should not make the preferred business outcome artificially easy and the alternative difficult.
A user should be able to understand the choice and change it later through a clear mechanism.
The final DPDP Rules require the means for withdrawing consent to be as easy as giving consent and require clear notice mechanisms. The exact implementation should be assessed against the processing and user flow, not copied from a generic cookie banner template.
The practical cookie audit
Run these tests:
Test 1: Clean browser
Load the page before any choice is made. Record which technologies fire.
Test 2: Reject or decline
Record what still fires.
Test 3: Accept
Record what becomes active.
Test 4: Withdraw later
Change the preference after a prior choice. Verify downstream behaviour.
Test 5: New vendor
Add a new tag. Confirm the privacy review process catches it.
Common mistakes
Calling every cookie “necessary.” A business preference is not the same thing as a technical necessity.
Blocking the banner but not the tracker. The UI changes; the network request does not.
Ignoring embedded tools. Chat widgets, video players, session recorders and analytics can introduce additional data flows.
Treating the website as separate from the rest of the privacy program. Browser data often flows straight into CRM, analytics, advertising, and support platforms.
Where Privra fits
Privra can continuously inspect product and web flows to identify privacy-relevant processing, compare the observed behaviour with the stated notice, and surface mismatches for remediation.
The objective is not to add another cookie popup.
It is to make the promise behind the popup true.