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. The record should not begin with the vendor's marketing category; it should begin with the Article 5(3) operation and the purpose it serves.

Classify the item as consent required, exempt under a transmission or strictly necessary analysis, disabled until review, or escalated because the implementation facts are incomplete. If the item has multiple purposes, record each purpose separately because an exemption should not be carried across to a non-exempt tracking purpose.

For every consent-required purpose, store the exact banner configuration shown when the signal was collected. The log should identify the banner version, language, jurisdiction or audience variant, first-layer text, second-layer settings text, button labels, default toggle state, and whether reject and manage choices were available at the same point in the journey.

The evidence should also show whether the banner avoided known weak practices: pre-ticked choices, consent inferred from scrolling or continuing to browse, misleading colour or contrast, hidden refusal routes, and confusing separation between rejecting Article 5(3) storage or access and objecting to later GDPR processing.

A consent log should be able to demonstrate that a user gave a clear affirmative signal for the named purpose before the non-exempt storage or access occurred. At the same time, the log should avoid collecting more personal data than needed to link the signal to the processing operation.

Store enough to prove the consent state and reconstruct the decision: pseudonymous user or device key where needed, timestamp, region or locale variant, banner version, purpose toggles, vendor list version, policy version, user action, and source of the event. Keep rejection and no-action states too, because they explain why trackers remained blocked.

The withdrawal record is part of the consent evidence, not a separate afterthought. The workflow should show where the user can reopen privacy settings, how quickly the consent state changes, which cookies or identifiers are deleted or allowed to expire, and how tags, SDKs, server-side events, and vendor calls are suppressed after withdrawal.

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 compact 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, and the 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, the safer output is a decision workflow that records when local counsel or a market owner must review national implementation details.