Article 5(3) classifierEU

EU ePrivacy Directive Cookie Scope Classifier Workflow

Classify whether a cookie, pixel, SDK, local storage object, device identifier, or analytics tracer stores or accesses information on terminal equipment, then decide whether consent or a narrow exemption applies.

Use the workflow with privacy, legal, product, web engineering, mobile engineering, analytics, marketing operations, consent-management, and evidence owners before releases that add or change client-side tracking.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 9, 2026

Overview

Use this classifier before deploying or changing cookies, pixels, SDKs, local storage, app identifiers, fingerprinting signals, tracked URLs, or analytics tags. The output is a per-technology scope decision showing whether Article 5(3) is triggered, whether a strictly necessary exemption is supportable, what consent mechanism is needed, and what evidence must be retained.

Section 1

Classifier input: one row per client-side mechanism

Start with an implementation inventory, not the banner labels. Article 5(3) analysis turns on whether the operation stores information or gains access to information already stored in terminal equipment, and the EDPB stresses that the term is broader than personal data.

Create one row for each mechanism that can touch a browser, app, connected device, relay device, or other terminal equipment. Include first-party cookies, third-party cookies, local storage, session storage, SDK-generated IDs, OS or browser identifiers, pixels in web pages or email, tracked URLs, IP-only tracking designs, and IoT or app telemetry that is cached locally before being sent.

Inventory fields: mechanism name, domain or SDK vendor, first-party or third-party context, storage location, read/write action, identifier value, lifetime, purpose, user action that triggers it, and network endpoint receiving the data.
Scope trigger fields: does the mechanism place information on the terminal equipment, read information from it, instruct client-side code to send information, or collect a locally generated value or derivation.
Terminal-equipment fields: browser, mobile app, connected car, connected TV, IoT device, relay phone, dedicated hub, or other equipment directly or indirectly connected to a public communications network.
Purpose fields: transmission, user input, authentication, user-centric security, multimedia playback, load balancing, UI preference, social plug-in sharing, advertising, analytics, market research, product improvement, debugging, or another stated purpose.
Evidence fields: tag manager export, SDK list, network trace, cookie/storage scan, consent-management configuration, vendor contract limits, product requirement, and reviewer approval.

Sources for this answer

EDPB Guidelines 2/2023 on Article 5(3) ePrivacy Directive

Supports the classifier inputs because the technical scope test covers information, terminal equipment, storage, and gaining access, including pixels, local processing, IP-based tracking, IoT reporting, and unique identifiers.

Directive 2009/136/EC amendment to Article 5(3)

Provides the Article 5(3) wording on storing information or gaining access to information already stored in terminal equipment.

European Commission ePrivacy factsheet

Commission material frames ePrivacy as protecting user control over device information, including consent before tracking cookies are stored.

Section 2

Scope decision: storage, access, or out of Article 5(3)

For each inventory row, classify the technical operation before debating purpose. Article 5(3) can apply where storage and access are separate operations, where different entities store and receive information, and where the information was originally created by the user, manufacturer, operating system, browser, sensor, or local software.

Do not treat non-cookie mechanisms as out of scope merely because no browser cookie is set. The EDPB guidance covers JavaScript instructions, pixels and tracked URLs, local storage and browser APIs, device or authentication identifiers, IP-only tracking where the IP originates from terminal equipment, unique identifiers collected in websites or mobile apps, and IoT reporting through direct or relay connections.

In scope: setting a cookie, writing to local storage, caching an identifier, creating an SDK identifier, or otherwise placing information on terminal equipment.
In scope: instructing a browser, app, SDK, or device to send stored or locally generated information back over the network.
In scope: a tracking pixel or tracked URL that causes the client to send an identifier or other targeted information, including in email or web content.
In scope: collection of a persistent or unique identifier from a website or mobile app when client-side code sends the value to the collector.
Potentially in scope: IP-only tracking unless the operator can evidence that the IP address does not originate from the user's terminal equipment.
Out of this Article 5(3) classifier: information used strictly inside the terminal equipment that does not leave the device through a communication network; still route any personal-data processing question to the GDPR analysis.

Sources for this answer

EDPB Guidelines 2/2023 on Article 5(3) ePrivacy Directive

Supports the technical scope branches for cookies, JavaScript, pixels, tracked URLs, local processing, IP-based tracking, IoT reporting, and unique identifiers.

WP29 Opinion 04/2012 on Cookie Consent Exemption

Confirms that Article 5(3) is not limited to RFC6265 cookies and applies to related technologies storing or accessing terminal-device information.

Section 3

Exemption decision: narrow strictly necessary tests

If the row is in Article 5(3) scope, decide whether consent is required or a narrow exemption can be evidenced. The Directive preserves two routes without consent: technical storage or access for the sole purpose of carrying out transmission over an electronic communications network, or what is strictly necessary to provide an information society service explicitly requested by the user.

Apply the exemption to each distinct purpose, not to the technology name. A cookie or SDK used for both authentication and advertising cannot inherit the authentication exemption for the advertising purpose.

Transmission exemption evidence: show the communication cannot be carried out without the mechanism, such as routing, ordering data items, detecting transmission errors, or maintaining a load-balancing session endpoint.
Explicitly requested service evidence: identify the exact functionality the user requested and show the mechanism is needed because the functionality will not work if it is disabled.
Likely exempt when limited to the supporting purpose: user-input session IDs for multi-step forms or shopping carts, session authentication cookies, user-centric security cookies, multimedia player session cookies, load-balancing session cookies, short-term UI preference cookies, and logged-in social plug-in sharing cookies.
Not exempt on this basis: behavioural advertising, frequency capping, ad affiliation, cross-site social plug-in tracking, market research, product improvement, debugging, and third-party analytics or advertising identifiers.
Escalate if the row has mixed purposes, persistent identifiers, third-party tracking, cross-site use, or a user-visible feature that still works when the mechanism is disabled.

Sources for this answer

Directive 2009/136/EC amendment to Article 5(3)

Provides the consent condition and the two Article 5(3) exemption routes for transmission and strictly necessary requested services.

WP29 Opinion 04/2012 on Cookie Consent Exemption

Supports the exemption use cases and the rule that strict necessity is assessed from the user's requested functionality, not the operator's business convenience.

Section 4

Analytics branch: consent, opt-out, or blocked exemption

Classify analytics separately because website operators often label analytics as necessary even where the user can use the site or app without it. WP29 states that first-party analytics cookies are not within the two Article 5(3) exemptions, while recognizing lower privacy risk when safeguards are present. CNIL guidance describes a narrower national analytics exemption model with conditions and warns that most large audience-measurement offerings do not fit it.

Do not generalize the CNIL analytics conditions into an EU-wide country rule. Use them as a documented analytics exemption checklist only where local legal review confirms that the applicable national implementation recognizes the approach.

Default analytics decision: consent required before depositing or reading the analytics tracer unless a documented national analytics exemption applies.
CNIL-style exemption evidence: user information, ability to object, audience measurement or A/B testing only, no cross-checking with customer files or other sites, one site or app editor, last-byte IP truncation, tracker lifetime limited to 13 months, and independent data/tracker separation when a processor serves multiple publishers.
Blocked exemption: cross-site analytics, third-party common identifiers, enrichment with CRM or advertising data, product improvement beyond audience measurement or A/B testing, or vendor use for its own purposes.
Consent banner mapping: analytics rows that require consent must remain off by default until consent, must be separately understandable from advertising, and must have a withdrawal path that is as easy as giving consent.
Evidence output: analytics tool configuration, IP truncation proof, retention setting, opt-out or consent setting, vendor purpose limits, and reviewer note explaining whether the row is consent-required or exemption-supported.

Sources for this answer

WP29 Opinion 04/2012 on Cookie Consent Exemption

Supports the default position that first-party analytics cookies are not within the Article 5(3) consent exemptions, while identifying safeguards for lower-risk analytics.

CNIL Sheet 16: Use analytics on your websites and applications

Supports the analytics-specific conditions for a consent exemption model, including audience measurement limits, objection, IP truncation, tracker lifetime, and independent processing by processors.

EDPB Cookie Banner Taskforce report

Supports consent-banner controls for consent-required analytics rows, including no default placement before consent and withdrawal accessibility.

Section 5

Consent controls and evidence outputs

Where the classifier returns consent required, the consent mechanism must be designed and evidenced before the mechanism runs. The EDPB consent guidance requires consent to be freely given, specific, informed, and unambiguous, and the cookie banner taskforce report identifies common banner patterns that fail those requirements.

Close the workflow only when the technical scan, legal classification, consent configuration, and release control all point to the same result. A banner category label is not enough evidence if the tag, SDK, or pixel fires before consent or does something different from the documented purpose.

Consent evidence: purpose text shown to users, category mapping, default-off configuration for consent-required rows, reject option, consent timestamp or signal record, and withdrawal mechanism.
Banner quality checks: no pre-ticked opt-in boxes, no consent-required cookies set before consent, no confusing legitimate-interest layer for Article 5(3) read/write operations, no reject link hidden in paragraph text, and no visual design that clearly pushes acceptance.
Technical evidence: pre-consent and post-consent network traces, storage snapshots, tag manager rules, SDK initialization gates, email-pixel deployment controls, and local storage or identifier lifetime settings.
Decision output per row: out of Article 5(3), in scope and exempt with reason, in scope and consent required, in scope but blocked pending vendor facts, or escalate for national-law review.
Reopen triggers: new SDK, new pixel or email tracking, new analytics vendor, changed identifier lifetime, cross-site enrichment, new mobile or IoT telemetry path, consent-management redesign, or authority/customer challenge.

Sources for this answer

EDPB Guidelines 05/2020 on consent

Supports the consent-quality requirements used when Article 5(3) consent is needed.

EDPB Cookie Banner Taskforce report

Supports banner evidence checks for reject options, pre-ticked boxes, default placement before consent, withdrawal accessibility, and misleading banner design.

EDPB Guidelines 2/2023 on Article 5(3) ePrivacy Directive

Supports keeping technical evidence on client-side instructions, storage, access, and terminal-equipment data flows aligned with the legal classification.

Recommended next step

Classify every cookie, pixel, SDK, and analytics tracer before launch

Sorena can convert this workflow into a row-level scope register, consent-gating checks, exemption evidence, and release review notes for EU ePrivacy work.

Research workflow

Open Research Copilot for EU ePrivacy

Ask source-linked questions about Article 5(3), terminal-equipment scope, cookie exemptions, analytics consent, and banner evidence.

Explore next step

Talk to Sorena

Review an ePrivacy tracking inventory

Work through cookies, pixels, SDK identifiers, local storage, analytics, and consent gaps with Sorena.

Explore next step

Primary sources

References and citations

CNIL Sheet 16: Use analytics on your websites and applications

cnil.fr

Referenced sections

Supports the analytics-specific conditions for a consent exemption model, including audience measurement limits, objection, IP truncation, tracker lifetime, and independent processing by processors.

"audience measurement"

Directive 2009/136/EC amendment to Article 5(3)

eur-lex.europa.eu

Referenced sections

Provides the consent condition and the two Article 5(3) exemption routes for transmission and strictly necessary requested services.

"strictly necessary"

EDPB Cookie Banner Taskforce report

edpb.europa.eu

Referenced sections

Supports banner evidence checks for reject options, pre-ticked boxes, default placement before consent, withdrawal accessibility, and misleading banner design.

"withdraw consent"

EDPB Guidelines 05/2020 on consent

edpb.europa.eu

Referenced sections

Supports the consent-quality requirements used when Article 5(3) consent is needed.

"freely given"

EDPB Guidelines 2/2023 on Article 5(3) ePrivacy Directive

edpb.europa.eu

Referenced sections

Supports keeping technical evidence on client-side instructions, storage, access, and terminal-equipment data flows aligned with the legal classification.

"gaining access"

European Commission ePrivacy factsheet

ec.europa.eu

Referenced sections

Commission material frames ePrivacy as protecting user control over device information, including consent before tracking cookies are stored.

"device"

WP29 Opinion 04/2012 on Cookie Consent Exemption

ec.europa.eu

Referenced sections

Supports the default position that first-party analytics cookies are not within the Article 5(3) consent exemptions, while identifying safeguards for lower-risk analytics.