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.
The minimum useful record is: timestamp, jurisdiction or site/app surface, pseudonymous user or device/session key where needed, consent status, purpose and category, vendor or recipient list version, cookie/tracker inventory version, banner language/version, policy text version, consent string or preference payload, and whether optional storage or access was blocked until consent.
- Keep affirmative consent, refusal, no-choice/default state, later preference changes, and withdrawal as separate events.
- 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.
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.