Search every question across sub-FAQs

Do not classify analytics cookies as strictly necessary under the general Article 5(3) exemptions merely because the site operator needs measurement. WP29 states that first-party analytics are often useful but are not strictly necessary for a user-requested website feature because the user can still access the site when those cookies are disabled.

Some national implementations or regulator guidance may create narrower analytics approaches or safeguards, but this page does not state country-specific exemptions. Before relying on analytics without consent, check the Member State law and competent authority guidance that applies to the website, the user group, and the deployment.

Retain the consent event, refusal event, and withdrawal event at purpose level, tied to the exact banner or preference-centre version shown to the user. Article 5(3) is triggered by storing information on, or gaining access to information in, terminal equipment; the log therefore needs to connect the user's choice to the cookies, pixels, SDKs, local storage, identifiers, or similar technologies deployed at that time.

Neither Article 5(3) nor the EDPB consent guidance prescribes a fixed CMP log schema. A practical record normally includes a timestamp; the site or app and market; a pseudonymous user, device, or session key only where needed; the choice and affected purposes; vendor and tracker-inventory versions; banner language and version; the preference payload; and the resulting tag state. Collect only what is needed to demonstrate the choice and its implementation.

A log is useful only if it captures consent quality, not just a positive flag. Preserve signals showing that the user saw clear purpose information, made a granular affirmative choice, could refuse optional cookies or trackers, and could later withdraw without undue effort.

For review, keep the evidence that the CMP did not rely on silence, pre-ticked boxes, scrolling, inactivity, or a design that made acceptance look mandatory. If the banner changed, keep the old versioned proof because later screenshots do not prove what a user saw earlier.

The CMP log should not stand alone. It should point to the inventory that explains which cookies, pixels, SDKs, local-storage entries, tags, or identifiers were present, which were strictly necessary, which required consent, and which vendor or controller received resulting data.

When vendors, purposes, cookies, scripts, consent strings, or banner text change, version the inventory and the CMP configuration together. That versioning lets reviewers distinguish a historical valid choice from a later deployment that needs fresh consent or a new assessment.

A CMP log proves that the system recorded a stated choice under a particular configuration. It does not by itself prove that consent was valid, that the banner was lawful, that all trackers were disclosed, that optional tags were actually blocked, or that the right national authority would accept the implementation.

Use the log with screenshots or rendered banner copies, CMP settings, tag-manager release records, cookie scans, vendor lists, policy text, and withdrawal test results. Keep the national-law caveat explicit: cookie placement or reading is governed by Member State laws transposing the ePrivacy Directive, while subsequent personal-data processing may also be assessed under the GDPR.