A cookie banner alone does not constitute evidence of consent. Where consent is relied upon as a lawful basis for processing, the organisation must be able to demonstrate what information was presented, what choices were made, the timing of those decisions, and the manner in which any subsequent changes were managed.
This constitutes an accountability requirement under Article 5(2) of the UK GDPR, as reinforced by the Information Commissioner’s Office (ICO) guidance on recording and managing consent. For organisations operating across multiple websites, applications, brands, or jurisdictions, a reliable consent log should be regarded as a core control mechanism, not merely a supplementary reporting feature.
1. What regulators expect consent records to demonstrate
The primary consideration is not the presence of a consent management platform, but whether the controller can provide sufficient evidence that valid consent was obtained for each specific processing activity.
The ICO states that consent records should establish:
- Who consented
This may involve a user identifier, account reference, session identifier or another proportionate means of linking the event to the relevant browser or individual. - When consent was given
A date and time should be recorded. Consistent time-zone handling is important where websites and applications operate across markets. - How consent was obtained
The record should identify the mechanism used, such as a web banner, preference centre, in-application prompt, paper form or another documented process. - What the individual was told
The organisation should retain the relevant version of the consent interface, privacy information and purpose descriptions shown at the time. - Whether consent was withdrawn
Withdrawal and subsequent changes should be recorded with sufficient detail to establish when the change occurred and which processing purposes were affected.
These requirements are set out in the ICO’s guidance on how to obtain, record and manage consent.
Recommended action: Define the minimum consent evidence required across all channels before selecting or configuring a logging solution. The required evidence should be agreed between privacy, legal, analytics and engineering teams.
2. A consent log is more than an accept or reject flag
A binary field, for example consent = true, is generally insufficient for audit purposes. Such a field does not specify which purposes were accepted, which notice was presented, or whether the decision remains current.
A structured consent event should normally include:
- A pseudonymous identifier or other proportionate reference.
- Date and time of the event.
- Website, application, brand and market.
- Consent status for each relevant purpose or category.
- The version of the CMP interface and privacy notice.
- The method by which the choice was recorded.
- The policy or configuration version in force at the time.
- A record of later amendments, withdrawals or renewals.
- The systems and purposes to which the choice applies.
The precise structure will vary according to the organisation’s architecture. A global organisation may require a central consent service with regional rules, while a smaller organisation may retain records internally. It is important to distinguish between recording a preference and preserving evidence. Preserving evidence requires maintaining sufficient historical context to enable reconstruction of the decision without reference to the current version of the banner or privacy notice.n of the banner or privacy notice.
3. Consent logs must correspond with actual tag behaviour
A consent record provides limited evidential value if the implementation does not enforce the recorded choice in practice.
For example, a consent management platform may record that analytics consent was refused, yet Google Analytics, advertising,g or social media tags may continue to operate. This results in a discrepancy between the documented preference and the actual technical processing activity.
A defensible implementation should demonstrate that:
- Non-essential tags are blocked until the relevant consent is obtained.
- Consent categories map consistently to tags, vendors and processing purposes.
- A withdrawal updates the consent state across applicable pages and applications.
- Server-side and client-side collection respect the same consent decision.
- Consent signals are passed accurately to analytics and advertising platforms.
- Vendor configurations are reviewed when tags, purposes or data destinations change.
This necessitates coordination between the consent management platform, tag management system, data layer, analytics platforms, and downstream data services. Implementation reviews should address both the integration of consent controls and the broader relationship between tagging and data collection.
Recommended action: Consent decisions should be tested as technical states, not solely as user-interface actions. Each processing purpose should be tested for scenarios including consent granted, consent refused, consent withdrawn, and no decision recorded.
4. Version control is essential to proving what was disclosed
Regulators do not only expect evidence that an individual clicked a button. They may also need to establish whether the information presented at that time was sufficiently clear, specific and complete.
A consent record should therefore connect the event to the relevant versions of:
- The CMP interface.
- Purpose and category descriptions.
- Cookie or vendor disclosures.
- Privacy notices.
- Consent wording.
- Regional or market-specific configurations.
- Relevant terms relating to withdrawal.
Without version control, an organisation may be able to demonstrate that consent was recorded, but not what information the individual was presented with or understood at the time of consent.
This is especially important where a processing purpose changes. For instance, an analytics category that originally covered aggregate measurement may later be expanded to include advertising audiences or cross-device analysis. Existing consent cannot automatically be assumed to cover the revised purpose.
The ICO’s guidance on documentation and accountability recommends that records of consent are linked to broader accountability documentation, including records of processing activities. The consent log does not need to replace the record of processing activities; it should provide an accessible evidence trail that supports it.
5. Withdrawal records and downstream action
Article 7(3) of the UK GDPR requires withdrawal to be as easy as giving consent. The European Data Protection Board’s Guidelines 05/2020 on consent also emphasise that consent must be capable of being withdrawn at any time.
An audit trail should therefore cover both the withdrawal event and the response to it. Relevant records may include:
- The date and time of withdrawal.
- The purposes or categories withdrawn.
- The method used to withdraw consent.
- The systems notified of the change.
- The time at which relevant processing stopped.
- Any deletion, anonymisation or suppression action.
- Any continued processing under a different documented lawful basis.
The record should not imply that all data must always be erased immediately. The required action depends on the processing activity, the applicable lawful basis, retention obligations and whether the data has been shared with other processors or controllers. What must be clear is why processing continued, if it did, and under which documented basis.
6. What consent logs do not solve
Consent logging is necessary in many consent-based processing arrangements, but it is not a complete compliance solution.
A consent log does not:
- Make a poorly designed consent banner compliant.
- Validate consent obtained through pre-ticked boxes, inactivity or misleading design.
- Replace prior blocking of non-essential cookies and tags.
- Establish that consent was freely given, specific, informed and unambiguous.
- Resolve an incorrect mapping between purposes and vendors.
- Prove that downstream platforms stopped processing after withdrawal.
- Replace a record of processing activities, DPIA or privacy notice.
- Provide a lawful basis for processing unrelated to the recorded consent.
- Correct inaccurate data collected before. This limitation is significant. An organisation may maintain technically complete logs while still operating an invalid consent mechanism or permitting uncontrolled data flows. The log serves as evidence of a process, but does not, in itself, establish the lawfulness of that process.not make the process lawful by itself.
7. Retention, access and data minimisation
Consent records should be retained for as long as they are needed to demonstrate compliance and while the organisation continues to rely on the relevant consent. They should not be retained indefinitely without a defined purpose.
A retention approach should address:
- The retention period for active and withdrawn consent.
- The difference between records needed for operational enforcement and records needed for accountability.
- Access controls for privacy, legal, analytics and engineering teams.
- Protection against unauthorised alteration or deletion.
- Requirements for data minimisation and pseudonymisation.
- The process for responding to an individual query or regulatory request.
The ICO accountability audit framework specifies that consent records should be thorough and accessible for review. Accessibility should not be interpreted as unrestricted access; rather, authorised personnel must be able to locate and interpret the relevant evidence without the need to manually reconstruct it from disparate systems.
8. A practical approach to audit-ready consent
A practical programme can be organised into six stages:
- Map processing purposes
Identify the purposes that rely on consent and link them to cookies, tags, vendors, analytics tools and data destinations. - Define the consent data model
Specify the fields required for identity or pseudonymous reference, timestamp, purpose, interface version, method, status and withdrawal. - Create version-controlled evidence
Store the relevant CMP configurations, privacy notices and purpose descriptions with effective dates. - Connect consent to enforcement
Confirm that client-side, server-side and application tracking respond consistently to consent state changes. - Test the full lifecycle
Test first visit, acceptance, refusal, partial acceptance, withdrawal, renewal and changes to the CMP configuration. - Establish governance
Assign ownership for consent configuration, vendor changes, monitoring, incident handling and periodic review.
This approach should be supported by regular technical validation. Analytics data quality controls can help identify discrepancies between intended and observed collection, including gaps caused by tagging changes or incomplete consent integration.
Conclusion
Consent logging should be regarded as an accountability control, not merely a reporting convenience. Where consent is relied upon, the organisation must be able to produce a clear record of what was presented, what was chosen, when the event occurred, and how the choice was enforced across all relevant systems.
In practice, this requires more than the storage of an accept or reject value. It requires version control, reliable technical enforcement, accessible records, and a defined governance model that can withstand internal review or regulatory scrutiny.
If you’d like to hear more on this topic and set up a 1:1 call with us, please use the contact form. Contact a Consultant
