What should CMP consent logs retain?
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.
- Keep affirmative consent, refusal, no-choice/default state, later preference changes, and withdrawal as separate states or events so the record does not turn silence into consent.
- Store the banner and preference-centre version that presented the choice, including the accept, reject, settings, and withdrawal routes available at that time.
- Link each consent purpose to the live vendor, cookie, pixel, SDK, local-storage, or identifier inventory used by the site or app.
- Record whether strictly necessary items were separated from analytics, advertising, personalisation, and other optional purposes.
- Retain only the proof needed to demonstrate the consent workflow; avoid expanding the consent log into a separate behavioural tracking dataset.
What should CMP consent logs retain under the EU ePrivacy Directive?
CMP consent logs should retain a replayable record of the user's consent, refusal, withdrawal, and preference changes, linked to the exact banner version, purposes, vendors, cookie or tracker inventory, and information shown at the time. The log should show that optional Article 5(3) storage or access was not activated before valid consent, that rejection was possible where consent was requested, and that withdrawal was available as easily as consent was given. It is supporting evidence only: it does not cure a misleading banner, an inaccurate vendor inventory, pre-ticked choices, a missing reject route, or a national-law rule that requires something more specific.
Grounds the need to connect CMP records to storage of, or access to, information in user terminal equipment.
Supports including non-cookie technologies such as pixels, local storage, identifiers, and similar terminal-equipment access in the consent-log scope.
Supports keeping enough records to demonstrate valid consent without excessive additional data collection.