Every CMP has a category labelled “Necessary” or “Strictly Necessary.” Cookies in that bucket are exempt from the consent requirement — they load before the banner, every time. That exemption exists because the GDPR and ePrivacy Directive both recognise that some cookies are technically required for a service to function. The problem is that the category is routinely stretched. Analytics cookies classified as necessary. A/B testing scripts categorised as functional. Ad-targeting pixels buried under “performance.” Each misclassification silently removes a consent requirement and creates a compliance gap that DPA audits will find.
TL;DR
- "Strictly necessary" means technically required — the service cannot deliver its core function without the cookie. Business convenience does not qualify.
- Session tokens, CSRF tokens, load-balancer stickiness cookies, and shopping cart IDs are the canonical examples of genuinely necessary cookies.
- GA4, Meta Pixel, Hotjar, and any cookie whose primary purpose is measurement or advertising are not necessary — regardless of how your CMP categorises them.
- Misclassification is one of the most common findings in DPA audits. It voids the consent record for those cookies entirely.
Verdict
Necessity is a technical standard, not a business justification. If the page still loads without the cookie, it is not necessary. Classify it honestly, gate it behind consent, and document the legal basis. The alternative is a misclassified cookie sitting in the “always-on” bucket waiting to appear in an audit.
The legal definition of “strictly necessary”
The exemption comes from Recital 25 and Article 5(3) of the ePrivacy Directive, which excludes cookies that are “strictly necessary in order to provide an information society service explicitly requested by the subscriber or user.” The GDPR supplements this through Article 6(1)(b), which allows processing necessary to perform a contract the user has entered into.
The operative word is “necessary.” Regulatory guidance — including guidance from the UK ICO and France’s CNIL — consistently applies a proportionality test: could the service deliver its core function without this cookie? If yes, the cookie is not strictly necessary.
“Core function” means the service the user explicitly requested. Not analytics about the service. Not advertising that funds the service. Not A/B tests that improve the service. The service itself, as the user asked for it.
What passes and what doesn’t
Cookies that typically qualify as strictly necessary:
- Session authentication tokens — the cookie that keeps a logged-in user logged in.
- CSRF protection tokens — required to prevent cross-site request forgery on form submissions.
- Shopping cart session identifiers — required for an e-commerce session to persist items.
- Load-balancer stickiness cookies — required for server-side session consistency in multi-server deployments.
- User-selected language or accessibility preferences — where the user explicitly set a preference and the site needs to honour it.
Cookies that do not qualify, regardless of how they are labelled in a CMP:
- GA4 / Google Analytics — measurement is not required for the site to function.
- Meta Pixel / Facebook CAPI — advertising attribution is not required for the service.
- Hotjar / FullStory / Microsoft Clarity — session recording exists for operator benefit, not user necessity.
- A/B testing cookies (Optimizely, VWO, Google Optimize) — experimentation is not technically required.
- Chatbot cookies (Intercom, HubSpot chat) — optional service enhancements, not core functionality.
Your site is leaking data before consent.
Free headless-browser scan. Catches GA4, Meta Pixel, TikTok and more firing before the click. Results in 10 seconds.
Run a free scan →The “user preferences” exception — and its limits
One legitimate grey area is user-preference storage. If a user explicitly sets a dark-mode preference or a cookie-consent decision, storing that in a cookie to honour it on the next visit can qualify as strictly necessary. The key conditions:
- The preference must have been explicitly set by the user, not inferred.
- The cookie stores only what is needed to honour the preference — not behavioural data alongside it.
- The cookie does not persist longer than is proportionate to the purpose.
Where this goes wrong: CMP vendors sometimes classify their own consent-record cookies under “strictly necessary.” That is defensible — the consent record genuinely is required to operate a compliant banner. What is not defensible is a CMP that also places analytics tags in the same bucket to avoid gating them.
How CMPs get this wrong by default
Most CMP platforms ship with a default cookie inventory that vendors have self-reported. The “purpose” and “category” fields in that inventory are populated by the tag vendor, not by a DPA. Vendors have an obvious incentive to categorise their cookies as broadly acceptable.
The result is cookie inventories that classify Google Analytics cookies under “performance” with a “legitimate interest” legal basis, or Hotjar under “functional,” or HubSpot under “necessary.” None of these classifications have been validated by a data protection authority. They are vendor defaults.
The operator — the business running the site — is responsible for accurate classification. Blaming the CMP vendor is not a defence DPAs have accepted. CMP setup mistakes agencies make →
How to audit your cookie inventory for misclassification
Apply this test to every cookie in the “Necessary” bucket:
- Disable the cookie in a browser session and load the site. Does the core service still function? If yes, the cookie is not necessary.
- Ask whose purpose it serves. A session token serves the user (they requested the session). An analytics cookie serves the operator (measurement). Operator-benefit cookies require consent.
- Check the vendor's own documentation. Many vendors explicitly classify their cookies as analytics or advertising in their own documentation, regardless of what a CMP vendor inventory says.
- Run a live network scan. Every request that appears before any consent interaction should originate from a genuinely necessary cookie. Requests to analytics.google.com, connect.facebook.net, or analytics.tiktok.com in that pre-consent window are violations.
The network scan is the only method that produces forensic evidence of how the site actually behaves — not how it is configured to behave. How to test your cookie banner for GDPR compliance →
Your site is leaking data before consent.
See exactly which cookies fire before any consent click — and whether your “necessary” classification holds up. No signup, 10 seconds.
Run a free scan →Further Reading