Cookie Compliance: A Practical Guide

If you run a SaaS product, ecommerce store, content site, or agency property, cookie work often lands on a small marketing or engineering team. A theme banner that says “we use cookies” is rarely enough once you run ads pixels, serve EU users, or prepare for India’s DPDP notice and consent duties.

This is article 1 of the Cookie Compliance series. Later posts cover OneTrust setup, GDPR detail, a DPDP checklist, banner design, cookie audits, CMP vs manual builds, Consent Mode v2 with OneTrust, consent records, and multi-region programs. This post is the map those how-tos plug into.

Who this is for

Write this for website owners, marketers, product managers, and small tech teams who:

• Ship analytics (GA4 and similar), ads pixels, chat widgets, or experiment scripts.
• Get traffic from more than one legal region (for example EEA, UK, California, and India).
• Need a clear order of work without waiting for a large legal team to finish a full policy rewrite.

Why this still matters even if you “already have a banner”:

• Google Consent Mode v2 is required signalling for many Google Ads and measurement setups serving the EEA, UK, and Switzerland under Google’s EU User Consent Policy. Google announced Consent Mode v2 in late November 2023.
• Enforcement and vendor pressure keep rising: DPAs, platform policies, and enterprise security questionnaires all ask how you collect consent and store proof.
• India’s DPDP Act, 2023 received Presidential assent on 11 August 2023. Detailed Rules from MeitY defining notice, consent, and related duties were still awaited. Teams that wait until Rules land struggle with inventory and vendor contracts. Start the groundwork now.

Plain caveat: this guide is practical orientation, not legal advice. Confirm edge cases with counsel, and check primary sources (Gazette of India, EDPB, California materials, Google docs) for updates.

What cookies and similar tech actually are

A cookie is a small piece of data a site (or an embedded third party) stores in the browser. Similar tech includes local storage, pixels, SDKs, and fingerprinting-style identifiers. Regulators care about storage or access on the user’s device, and about whether the resulting data identifies a person.

First-party vs third-party

• First-party: set under your own domain. Login sessions, carts, and many first-party analytics cookies fall here.
• Third-party: set under another company’s domain from an embedded script (ad networks, some social pixels, older analytics setups). Browsers have restricted third-party cookies for years, so many vendors moved to first-party or server-side patterns. Your compliance map still needs the vendor and the purpose.

Purpose categories teams actually use

CMPs and audits usually group cookies by purpose. Statutes rarely invent these labels, but they help you write notices and wire tag rules:

• Strictly necessary / essential: security, load balancing, login session, consent storage itself. Under EU ePrivacy practice, these are often allowed without marketing-style opt-in when strictly needed for the service the user requested.
• Preferences / functional: language, layout, remembered UI choices.
• Analytics / performance: traffic measurement, funnel diagnostics.
• Marketing / advertising: retargeting, ad measurement, audience building.

If a cookie or pixel can be linked to an identifiable person, treat the processing as personal data work. Conservative product teams plan consent (or a clear opt-out path, depending on the region) for analytics and ads categories either way.

Legal map: three pillars you will meet most often

1. GDPR and the ePrivacy Directive (EEA and related traffic)

If you offer goods or services to people in the EEA, or monitor their behaviour, GDPR territorial rules can reach you even when the company sits elsewhere. For cookies and similar device storage, EU practice rests on Article 5(3) of the ePrivacy Directive plus GDPR consent standards when consent is the basis for later processing.

What website owners must get right for EU visitors, distilled from EDPB cookie-banner work and consent guidelines:

• Prior consent before non-essential cookies or similar trackers fire.
• Informed notice: who, what purposes, what data categories, how to withdraw.
• Reject and accept with comparable prominence. No dark-pattern mazes.
• No valid consent from silence, scrolling alone, or pre-ticked boxes.
• Withdrawal available later, as easy as the original grant.

EDPB guidance on the technical scope of Article 5(3) also stresses that “similar technologies” can include scripts, pixels, and other device access patterns, not only classic HTTP cookies. UK GDPR and UK privacy rules follow a closely related consent model for cookies; treat UK traffic with the same care unless counsel says otherwise for your case.

2. CCPA/CPRA (California consumers)

California’s CCPA (as amended by CPRA) generally does not require an EU-style prior opt-in cookie banner for ordinary collection. It does require clear privacy disclosures. If your business sells or shares personal information (including many ad-tech “share for cross-context behavioural advertising” patterns), you must:

• Offer a clear “Do Not Sell or Share My Personal Information” path (or an equivalent combined link where allowed).
• Honour valid opt-out preference signals such as Global Privacy Control where the rules require it.
• Avoid dark patterns that make opt-out harder than opt-in (California Privacy Protection Agency enforcement advisories stress symmetry in choice).

A cookie banner alone is not automatically a valid sale/share opt-out method under California regulations. Wire both the CMP preference model and the California-specific link or signal handling.

3. India: DPDP Act (cookies by principle, not by name)

The Digital Personal Data Protection Act, 2023 does not use the word “cookie.” There is no India ePrivacy twin. Coverage comes from general personal-data rules when cookies process personal data. The Act received assent on 11 August 2023. Detailed Rules from MeitY were still awaited as of this writing; teams should treat the Act’s notice and consent principles as the planning baseline and prepare inventory, notice text, and consent flows now ahead of forthcoming Rules:

• Lawful processing: process personal data only for a lawful purpose with a valid ground (consent is the main ground website teams meet for optional tracking).
• Notice (Section 5): clear, standalone notice in plain language. Itemise personal data categories and purposes. Link to how users withdraw consent, exercise rights, and complain to the Board. Expect Rule-level detail once MeitY notifies the Rules.
• Consent quality (Section 6): free, specific, informed, unconditional, unambiguous, shown by clear affirmative action. Pre-ticked boxes and bundled “accept everything to use the site” patterns fail this test.
• Withdrawal: as easy as giving consent. Keep a lasting way to reopen preferences.
• Children (Section 9): verifiable parental consent before processing a child’s personal data. Tracking, behavioural monitoring, and targeted advertising directed at children are restricted under the Act’s child provisions. Expect further Rule detail once notified.

Whether a bare random tracker ID always counts as identifiable personal data under the Act remains an open interpretation point; account-linked or profile-linked tracking clearly does. Do not wait for Rules to finish your cookie inventory and notice drafts.

Quick overlap table

Other US state privacy laws and sector rules may also apply. Start with the three pillars above, then extend geo rules as your traffic and counsel require.

A practical compliance stack

Laws differ. The engineering stack looks similar across regions if you build once with geo rules.

1. Inventory and cookie audit

List every tag and storage key on staging and production: name, domain, party, purpose, vendor, data shared, retention if known. Scan with browser tools, your tag manager workspace, and a CMP scanner if you use one. Fix orphaned pixels. A later series article covers audit method in depth; for now, refuse to design a banner before you know what you set.

2. Banner plus preference center

• First layer: short purpose summary, Accept all, Reject non-essential (or equivalent), and a link to finer controls.
• Second layer: toggles by purpose (and vendor lists where useful).
• Always-available reopen control in the footer or floating preference icon.

3. Consent records

Store proof of what the user saw and chose: timestamp, policy or notice version, purposes granted or denied, region rule, and identifiers your CMP supports. You will need this for disputes, vendor questionnaires, and regulator questions.

4. Tag blocking until consent

Non-essential tags must not run before grant in consent-required regions. Implement through the CMP’s auto-blocking, Google Tag Manager consent checks, or server-side gating. A pretty banner that fires Meta and Google Ads on page one is not compliance.

5. Google Consent Mode v2 (brief)

Consent Mode tells Google tags how to behave based on user choice. v2 adds ad_user_data and ad_personalization beside ad_storage and analytics_storage. Set defaults before tags configure; update when the user chooses; persist and reapply on later pages. Google’s developer docs describe basic vs advanced implementations and region-scoped defaults. Marketers running EEA campaigns should treat v2 as part of the same project as the banner, not a later add-on. A dedicated series article covers OneTrust wiring for Consent Mode v2 in more depth.

OneTrust as one common CMP path

A Consent Management Platform centralises geolocation rules, cookie categorisation, banner templates, preference centers, and consent receipts. OneTrust Cookie Consent is widely used for that job. At a high level it can:

• Scan and categorise cookies.
• Show region-aware banners and preference centers.
• Log consent receipts and dashboard records when capture is enabled on the relevant geolocation rule.
• Integrate with tag managers and Consent Mode templates so grants and denials update Google signals.

You can also build a lighter custom banner for a small brochure site. The trade-off is maintenance: multi-region scripts, receipt storage, vendor list updates, and Consent Mode edge cases add up. Article 2 walks through OneTrust setup. A later comparison article weighs OneTrust against a manual build so you can pick based on traffic mix and team size, not brand habit.

30-day action checklist

1. Days 1 to 3: Name an owner (marketing ops or eng). Export every GTM/tag container. Note countries in analytics that matter for law (EEA, UK, US-CA, IN, and others you care about).
2. Days 4 to 8: Run a cookie and tag inventory on production. Mark essential vs optional. Delete dead tags.
3. Days 9 to 12: Draft itemised notice text: data categories, purposes, withdrawal path, privacy policy link. Keep it separate from Terms of Use.
4. Days 13 to 18: Choose CMP path (OneTrust or lean custom). Configure geo rules: consent-required for EEA/UK; California sale/share opt-out if you sell or share; DPDP-ready notice/consent model for India traffic.
5. Days 19 to 23: Block non-essential tags by default in consent regions. Wire Consent Mode v2 defaults and updates. Test with a clean browser profile.
6. Days 24 to 27: Turn on consent logging. Verify a reject path loads the page without ads/analytics cookies. Verify reopen and withdraw. Verify California opt-out or GPC handling if you sell or share.
7. Days 28 to 30: Document the setup for your team. Schedule a quarterly re-scan. Book legal review if you process children’s data or sensitive categories.

Common mistakes

• Banner theater: Accept-only walls, buried reject links, or pre-ticked marketing toggles.
• Tags that ignore the banner: scripts in the header that never wait for CMP events.
• One policy for every country: forcing EU opt-in UX on California-only flows can confuse users; the reverse under-protects EU visitors.
• Skipping the inventory: consent text that lists three cookies while twenty vendors load.
• No records: “users clicked Accept” with nothing stored.
• Consent Mode as an afterthought: ads and GA4 keep firing full cookies while the banner still asks.
• Ignoring minors: behavioural ads on products popular with children, especially under DPDP Section 9 risk and child-directed advertising rules elsewhere.
• Waiting for Rules before starting: GDPR cookie duties and Consent Mode pressure already apply for many sites; DPDP Act principles are on the books while detailed Rules are still forthcoming. Use the wait productively.

FAQ

Do I need a cookie banner everywhere?

Not identically. EEA/UK traffic generally needs prior consent for non-essential cookies. California focuses on disclosure plus sale/share opt-out when those activities apply. India applies DPDP Act notice and consent principles where personal data is processed through trackers; detailed Rules from MeitY were still awaited as of this writing. Many global sites still ship one CMP with geo rules so the UX matches the visitor’s region.

Are analytics cookies “essential”?

Usually no. Essential means needed to deliver the service the user asked for (security, session, load balancing). Product analytics and advertising measurement are optional purposes in most CMP models and need a consent or opt-out story that matches the region.

Is OneTrust mandatory?

No. Any CMP or careful custom build that meets notice, choice, blocking, and record-keeping can work. OneTrust is a common enterprise-ready option. Match cost and complexity to your regions and tag count.

What is Google Consent Mode v2 in one sentence?

An API that passes ad and analytics consent states (including ad_user_data and ad_personalization) into Google tags so they adjust cookies and pings based on the user’s choice.

If I only have traffic from one country, can I ignore the rest?

Maybe for banner geo rules, but confirm with real analytics and counsel. Vendor contracts, Google Ads settings, and future expansion often pull you into a second regime sooner than you expect.

Do I need a lawyer before publishing a banner?

For a small brochure site with a standard CMP template, many teams ship with policy review soon after. If you sell data, run kids’ products, process health or finance data, or negotiate enterprise DPAs, get counsel involved before go-live.

Sources and further reading

• EDPB Cookie Banner Taskforce report (17 January 2023) and EDPB Guidelines 05/2020 on consent; Guidelines 2/2023 on the technical scope of ePrivacy Article 5(3).
• Google Tag Platform: Set up consent mode on websites (Consent Mode v2 parameters).
• California CCPA/CPRA statute and CPPA materials on sale/share opt-outs and dark patterns.
• Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023). Check meity.gov.in for current PDFs and any Rules notifications.
• OneTrust Cookie Consent docs on consent logging, receipts, and preference centers (vendor documentation).

Next in this series

Up next: How to Set Up OneTrust Cookie Consent on Your Website. That guide will walk through geolocation rules, cookie categories, banner and preference center configuration, publishing to CDN, and a smoke-test checklist so the map in this article becomes a working install.

Later articles cover GDPR owner duties, a DPDP-focused checklist, banner patterns that keep consent rates usable, pre-OneTrust audits, CMP vs manual trade-offs, Consent Mode v2 with OneTrust, why consent records matter, and running CCPA-to-GDPR programs from one stack.

Disclaimer

This article was prepared using publicly available information. It is for general education only and is not legal advice. Please do not rely on it alone when implementing cookie compliance, DSAR handling, consent flows, privacy policies or other privacy and data-protection controls. Consult your own legal counsel for advice that fits your business, jurisdictions, and systems.

Last updated on 12 September 2026