Compliance Audit
PUBLIC / REFERENCEEngine
EPRIVACY / RULE REFERENCE

ePrivacy — the cookie rule

The ePrivacy Directive — the "cookie law" — predates GDPR and is stricter in one way: consent is required for storing or accessing anything on the user’s device, whether or not it is personal data. The "strictly necessary" exemption is narrow: session auth, CSRF tokens, load-balancer stickiness, shopping carts. Analytics and marketing pixels never qualify, and regulators — the CNIL especially — have fined major properties for scripts that fired before consent.

The rule

Storing or accessing information on a user’s device requires prior consent — except what is "strictly necessary" for the service the user asked for. Analytics and marketing pixels are never strictly necessary.

What it means for how you build

Either gate every non-essential script behind an opt-in banner, or ship nothing that needs one. Session auth and CSRF tokens are exempt; GA4 is not.

Self-check

  • Does any non-essential storage or read happen before an affirmative opt-in? Third-party tags count.
  • Is "reject" as easy as "accept" — same layer, same number of clicks?
  • Have you audited localStorage/sessionStorage and fingerprinting, not just document.cookie?
  • Is the consent-state record itself classified as strictly necessary?

Common pitfalls

  • Pre-consent pixels: a tag-manager analytics trigger firing on page load has already breached.
  • Cookie walls misread as consent — nudging UX is dark-pattern territory under both ePrivacy and GDPR.
  • Fingerprinting as a workaround: reading device identifiers without cookies is still "accessing information on the device".

How the engine checks it

Zero third-party tracking by construction — functional sessions plus a first-party heartbeat only.

Last reviewed 2026-11-01.

Reading up on ePrivacy — the cookie rule? The engine verifies this surface from the perimeter — live on sovereign EU/UK partitions.