Skip to main content
Cookie Gate
Dark green background, "Weak Application Security Can Cost You Millions," 3 slanted images of fingers pointing to digital locks, and a "Learn the Basics" button
Category: Consent Records

Consent Version

Also known as: Consent Record Version, Consent String Version
Simply put

A consent version is a label or number that identifies a specific state of a website's cookie consent setup at the time a user made a choice. Because the wording of a consent notice, the list of cookies, or the available options can change over time, recording the version helps an organization know exactly what a user agreed to and when. This supports keeping accurate records and re-asking for consent when material changes occur.

Formal definition

Consent version is an identifier attached to a stored consent record that ties a user's captured preferences to the specific configuration of the consent notice, purpose descriptions, cookie or vendor inventory, and policy text in force when consent was collected. It is a component of consent logging and record-keeping practices generally used to demonstrate the informed and specific nature of consent, and to determine when re-consent may be required following material changes to processing purposes, vendors, or disclosures. Versioning is typically implemented and managed by a consent management platform (CMP) and may be reflected in structured formats such as those defined by the IAB Transparency and Consent Framework, though the precise data captured varies by implementation. The evidence packet provided does not contain sources specific to cookie consent versioning, and this definition reflects general practitioner usage rather than any cited technical or regulatory specification. Whether a given change is 'material' enough to invalidate prior consent and require re-consent is a fact-specific judgment that depends on applicable law (for example, ePrivacy implementations and the GDPR in the EU) and evolving guidance from data protection authorities; this is out of scope for a definitional entry.

Why it matters

For organizations operating under EU law, valid consent must generally be informed and specific, which means being able to show precisely what a user was told and what options they were offered at the moment they made their choice. A consent version supports this by tying each stored consent record to the exact configuration of the notice, purpose descriptions, and cookie or vendor inventory in force at that time. Without this linkage, an organization may struggle to demonstrate the informed and specific nature of the consent it relies on, which is a common expectation in EU record-keeping practice.

Versioning also underpins the practical question of when to re-ask users for consent. Consent notices, cookie lists, and processing purposes change over time, and material changes may render previously collected consent no longer adequate. Knowing which version a user agreed to lets an organization identify populations that consented under an outdated configuration and prompt them again where appropriate. Whether a particular change is 'material' enough to require re-consent is a fact-specific legal judgment that varies by jurisdiction and evolving regulatory guidance, and is beyond what a version label alone can determine.

The evidence provided does not contain sources specific to cookie consent versioning, so this entry reflects general practitioner usage rather than any cited technical or regulatory specification. Readers should treat consent versioning as a supporting record-keeping practice rather than a guarantee of compliance, and should apply legal judgment to their own facts and applicable regimes.

Who it's relevant to

Privacy officers and data protection professionals
Those responsible for demonstrating that consent was informed and specific rely on version identifiers to reconstruct exactly what a user was shown and agreed to. This supports record-keeping expectations, particularly under EU regimes such as the ePrivacy implementations and the GDPR, though the specific obligations vary by jurisdiction.
Legal counsel and compliance teams
Counsel assessing whether a change to a consent notice, purpose, or vendor list requires re-consent depend on versioned records to scope the affected user population. Whether a change is 'material' enough to invalidate prior consent is a fact-specific judgment that depends on applicable law and evolving guidance from data protection authorities.
Web developers and CMP administrators
Those configuring and maintaining a consent management platform implement the versioning logic that increments identifiers when the notice, cookie inventory, or purposes change, and that stores the version alongside each consent record. Tools support this practice but do not replace the legal judgment needed to decide when versions should change or when re-consent is triggered.
Marketing compliance teams
Teams deploying analytics, advertising, and other non-essential cookies and similar technologies use version records to confirm which users consented under the current configuration before relying on that consent, helping avoid processing based on outdated or superseded permissions.

Inside Consent Version

Version Identifier
A unique label or number assigned to a specific state of the consent configuration, allowing each recorded consent to be tied to the exact wording, categories, and choices presented to the user at the time consent was captured.
Consent Notice and Text
The specific information, disclosures, and cookie categories shown to the user under that version, which supports the requirement that consent under the GDPR be informed. Changes to this text generally warrant a new version.
Cookie and Technology Inventory
The set of cookies and similar technologies (such as pixels, local storage, SDKs, or fingerprinting) covered by the version. Because these technologies fall within the same rules as cookies under EU law, changes to the inventory may trigger a new version.
Timestamp and Effective Period
The date and time from which a version applied, enabling practitioners to determine which configuration governed a given user's consent and to demonstrate record-keeping consistent with accountability expectations.
Linkage to Consent Records
The association between individual consent logs and the version in force at the moment of collection, supporting the ability to reconstruct what a specific user actually agreed to.

Common questions

Answers to the questions practitioners most commonly ask about Consent Version.

Does keeping a consent version mean my old consent records are no longer valid?
Not necessarily. A new consent version typically reflects a change in your cookie categories, purposes, third parties, or disclosures, but it does not automatically invalidate consents previously collected under an earlier version. Whether prior consents remain valid generally depends on how materially the processing has changed. Where new purposes or technologies are introduced, or disclosures change substantially, EU data protection authorities generally expect fresh consent to be sought, because the original consent may no longer be specific and informed for the new context. Minor cosmetic changes may not require re-consent. This is a fact-specific legal judgment rather than an automatic consequence of incrementing a version number.
Is the consent version the same thing as the version of my consent management platform (CMP)?
No. The consent version generally refers to the version of your consent configuration and disclosures presented to the user, meaning the specific set of purposes, cookie categories, vendors, and text that a user consented to at a given point in time. The CMP software version is a separate technical attribute describing the release of the tool itself. A CMP may be updated without changing what the user is asked to consent to, and your consent configuration may change without a CMP software update. Consent records should ideally capture the consent configuration version so you can demonstrate what a user actually agreed to, independent of the software release.
What information should a consent version capture to support record-keeping obligations?
To support the accountability and record-keeping expectations that generally apply under the GDPR, a consent version is typically associated with details such as the cookie categories and purposes presented, the vendors or third parties involved, the wording of the consent notice, and the date range during which that configuration was live. Linking each stored consent to its version helps you demonstrate what a given user was shown and agreed to at the relevant time. The precise fields you need depend on your processing and the interpretation of applicable requirements, so this should be assessed against your own compliance needs rather than treated as a fixed checklist.
When should I create a new consent version rather than editing the existing one?
As a general practice, a new consent version is warranted whenever the substance of what users are being asked to consent to changes, for example when adding new purposes, cookie categories, vendors, or tracking technologies, or when materially revising the disclosures. Creating a new version rather than overwriting the existing one preserves an accurate historical record of what earlier users agreed to. Whether a particular change is material enough to require re-consent for existing users is a separate legal question. This entry does not resolve that assessment, which should be made with reference to the applicable regime and any relevant regulatory guidance.
How does consent version relate to deciding whether users must re-consent after a change?
The consent version is primarily a record-keeping and configuration construct; it documents what changed and when. It does not by itself determine whether re-consent is required. That determination generally turns on whether the change is material to the specificity and informed nature of the original consent, which is a legal judgment that varies by jurisdiction and depends on the facts. In practice, versioning supports that decision by making it clear what a user previously agreed to, but the tool or version scheme does not replace the legal analysis of whether fresh consent must be obtained.
How should consent versions be handled across different jurisdictions?
Because consent obligations differ between the EU, the UK, and individual US states such as under the CCPA and CPRA, the way you configure and version consent may vary by region. For example, EU and UK practice generally centers on prior opt-in consent for non-essential cookies, whereas several US state frameworks often rely on opt-out mechanisms. A single global consent version may not capture these differences accurately, so many organizations maintain region-specific configurations and version them separately. The appropriate approach depends on which regimes apply to your users and how you have scoped your processing; this entry does not prescribe a specific multi-jurisdiction design.

Common misconceptions

A single consent version can cover material changes to cookies or notice text indefinitely without re-obtaining consent.
Because valid consent under the GDPR must be specific and informed, substantive changes to the categories, purposes, or technologies in use may mean previously captured consent no longer covers the new processing. In many EU jurisdictions this can warrant a new version and, potentially, fresh consent, though whether re-consent is required depends on the facts and evolving regulatory guidance.
Maintaining consent versions through a CMP guarantees compliance.
Versioning and logging within a consent management platform support accountability and record-keeping, but tools do not replace legal judgment. Whether the underlying consent mechanism meets the applicable standard still depends on how consent is obtained and on the requirements of the relevant regime.
Consent versioning requirements are the same everywhere.
Obligations and expectations vary between the EU, the UK, and individual US states such as California under the CCPA and CPRA. EU frameworks generally rely on prior opt-in consent, while several US state laws rely on opt-out mechanisms, so the practical role and content of versioning differs by jurisdiction.

Best practices

Assign a unique version identifier to each distinct consent configuration and record the timestamp indicating when it took effect, so consent records can be tied to the exact state that governed them.
Retain the full notice text, cookie and technology inventory, and category structure associated with each version, rather than only the latest configuration, to support the accountability and record-keeping expectations under EU law.
Assess whether material changes to categories, purposes, or the technologies in use (including pixels, SDKs, local storage, or fingerprinting) warrant creating a new version and, where appropriate, seeking fresh consent, recognizing that this judgment depends on the specific facts.
Link each individual consent log to the version in force at the moment of collection so you can reconstruct what a given user actually agreed to.
Document the geographic and legal scope each version is intended to serve, since requirements differ across the EU, the UK, and US state regimes such as the CCPA and CPRA.
Treat CMP versioning features as support for compliance rather than a substitute for legal review, and periodically validate versioning practices against current guidance from the relevant data protection authorities.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide