EU ePrivacy Directive Consent-log evidence workflow

Create one record for each cookie, pixel, SDK call, local-storage key, device identifier, or similar technology that stores information on, or accesses information from, a user's terminal equipment. Base the record on the Article 5(3) operation and its purpose rather than the vendor's marketing category.

Classify the item as consent required, exempt under the transmission exception, exempt because it is strictly necessary for a service explicitly requested by the user, disabled until review, or escalated because the implementation facts are incomplete. If the item has multiple purposes, record each purpose separately because an exemption for one purpose does not extend to a non-exempt tracking purpose. National implementing law and regulator guidance can affect the final answer.

For every consent-required purpose, preserve the exact banner configuration shown when the signal was collected. Identify the banner version, language, jurisdiction or audience variant, first-layer text, second-layer settings text, button labels, default toggle state, and the steps needed to accept, reject, manage, and later withdraw. This is evidence design, not an official form.

The evidence should also show whether the banner avoided known weak practices: pre-ticked choices, consent inferred from scrolling or continuing to browse, hidden refusal routes, misleading design that pushes acceptance, and confusing separation between rejecting Article 5(3) storage or access and objecting to later GDPR processing. The EDPB taskforce report states a common denominator among participating authorities; national rules and a case-specific assessment still control.

A consent log should demonstrate that a user gave a clear affirmative signal for the named purpose before the non-exempt storage or access occurred. Article 7(1) GDPR requires the controller to be able to demonstrate consent, but it does not prescribe a particular log. The EDPB also warns that proof should not create excessive additional data processing.

Store enough to prove the consent state and reconstruct the decision: a pseudonymous user or device key where needed, timestamp, region or locale variant, banner version, purpose toggles, vendor list version, policy version, user action, and event source. Keep rejection and no-action states only to the extent needed to enforce and explain blocking; do not turn the proof system into a separate tracking record.

The withdrawal record is part of the consent evidence. Show where the user can reopen privacy settings, when the consent state changes, whether existing cookies or identifiers are deleted, disabled, or allowed to expire under a documented rule, and how later tags, SDK events, server-side events, and vendor calls based on the withdrawn consent are stopped. Withdrawal does not make earlier consent-based processing unlawful, and it does not automatically erase data held for another valid purpose or legal basis.

The log should distinguish withdrawal of consent from a new refusal, browser deletion, opt-out for exempt analytics, and objection to later processing. Where the same user has multiple devices or browsers, record the scope of the signal honestly instead of implying a universal withdrawal that the system cannot enforce.

A consent log is weak if it records user choices but cannot connect them to the live tracker inventory. Maintain a reconciliation job that compares consent categories and vendor lists with browser scans, tag-manager exports, SDK manifests, server-side event routes, and contract or data-processing records.

For each third-party or vendor-operated technology, preserve the evidence that explains the role split: controller, joint controller, processor, or unresolved. The ePrivacy decision concerns storage or access to terminal equipment, while any personal-data processing that follows must also have a GDPR analysis; the workflow should keep those records linked but not merge them into a single legal basis.

Close the workflow only when the team can export a focused evidence pack for a product release, vendor change, regulator question, customer inquiry, or internal audit. The pack should show the decision, the live implementation, the source basis, retention rules, and known limits.

Do not add country-specific penalties, regulator-specific banner rules, or analytics exemptions unless the cited source in the evidence pack supports them. For EU-wide ePrivacy content, record when local counsel or a market owner must review national implementation details.