EU ePrivacy Directive Cookie Scope Classifier Workflow

Build the inventory from implementation evidence rather than banner labels. Article 5(3) analysis depends 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, or other possible terminal equipment. Also record relay devices in mediated IoT flows, but classify their function: the EDPB says equipment that only conveys information without modifying it is not terminal equipment in that context. 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.

For each inventory row, classify the technical operation before debating purpose. Storage and access are alternative triggers; both do not need to occur. Different entities may instruct the terminal, store the information, and receive it, and the information may have been 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.

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.

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 rule. Its 11 June 2020 sheet is a historical French example, not a complete current eligibility test. For a French deployment, obtain the current official eligibility source and test each condition against the actual configuration. Use the applicable Member State's own law and authority material for other markets.

Where the classifier returns consent required, the consent mechanism must be designed and evidenced before the mechanism runs. Consent must be freely given, specific, informed, and unambiguous. The EDPB cookie banner taskforce report records a common denominator among participating authorities on several patterns, but it is not a substitute for the applicable national rule or a case-specific assessment.

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.