Understanding Purpose Versioning
Major/minor versioning can empower your organization and privacy teams with greater control and precision in managing consent while maintaining a clear changelog for retrospective analysis. This feature also supports an automated re-consent workflow that allows you to trigger re-consent based on major changes, ensuring that consent remains valid and aligned with evolving data practices. Beyond simply tracking changes, it enables smarter collaboration, stronger compliance, and seamless integration across systems.
Benefits of major/minor versioning
Safer user collaboration
With major/minor versioning, you can reduce the risk of compliance gaps caused by unclear or undocumented changes. For example, avoiding accidental overwrites or unintended updates, being able to ensure that significant changes are reviewed and justified before publishing, and maintaining a clean and understandable version history, making it easier to audit and explain decisions.
Better synchronization across systems
This improves operational efficiency and ensures that users receive accurate, up-to-date information no matter where they interact with the organization. You can automatically notify connected systems when a purpose has been updated, ensure that consent language, settings, and policies are consistent across platforms, or trigger re-consent workflows in real time.
Stronger compliance and change management
Major/minor versioning provides a structured way to manage consent in line with regulatory expectations. This not only simplifies audits but also ensures that consent remains valid over time. You can automate responses to major changes, such as re-consent requests or privacy notice updates and tie consent records to specific versions of a purpose including additional information of why and when changes were made.
Purpose Details Screen Reference
On the Purposes details screen, you can manage and edit your purpose information and settings.
General information section
- Field
- Description
- Name
-
The unique name of the purpose.
- Purpose category
-
The primary intent or function of the purpose. This categorization helps users understand the context and relevance of the purpose.
- Purpose ID
-
The unique identifier assigned to the purpose.
- Purpose type
-
Standard (the reason a data subject’s data is collected and processed) or Cookie (created and managed within Cookie Consent).
- Organization(s)
-
The organization(s) to which the purpose of processing is linked.
- Expiration
-
The length of time in days, months, or years that a data subject's consent will remain valid.
- Version type
-
Select minor or major depending on the magnitude of the changes.
- Geolocation tracking
-
Enable this setting to capture a data subject's geolocation.
- Implicit consent
-
Enable this setting to capture implicit consent for this purpose.
- Lifespan of implicit consent
-
The length of time in days, months, or years that a data subject's implicit consent to the purpose will remain valid.
- Show explicit consent checkbox in preference center
-
Enable this setting to allow data subjects to confirm consent explicitly in your preference center.
- Implicit confirmation text
-
The description that you want to show for implicit consent capture in the Implicit confirmation text field.
- Description (Public)
-
A brief explanation of the purpose's intended use, visible to all users.
- Version notes (Internal use only)
-
Internal comments about changes made in the current version, only visible to internal users.
Custom attributes section
- Field
- Description
- Purpose attribute
-
The custom attribute that describes your purpose.
Other information
- Field
- Description
- Created date
-
The date and time when the purpose was initially created.
- Created by
-
The name of the user that originally created the purpose.
- Updated date
-
The most recent date and time when the purpose was modified or updated.
- Updated by
-
The name of the user that performed the latest update to the purpose.
- Published date
-
The date and time when the purpose was made available to its intended audience.
- Published by
-
The name of the user who published the purpose.
Version history
- Field
- Description
- Purpose name
-
The unique name of the purpose.
- Latest version
-
Indicates the most recent version of the purpose.
- Created date
-
The date and time when the version of the purpose was created.
- Published date
-
The date and time when the version of the purpose was published.
- Version status
-
The current state of the version, which may include values such as Draft, Active, or Retired.
- Updated by
-
The name of the user that updated the version of the purpose.
- Version type
-
Specifies the nature of the changes made in the version.
-
Major: Significant updates that affect the core content requiring a new consent request.
-
Minor: Small changes such as typo corrections or other non-substantial edits.
-
- Version notes
-
Internal comments about changes made in the version, only visible to internal users.
Major and minor use cases
Major changes typically require a new consent request because they significantly alter the context of data processing. See some examples below:
- Adding a new purpose of processing
-
Starting to use collected data for marketing when it was originally gathered for participation in events.
- International data transfers
-
Moving data to a new country or vendor, possibly requiring a data adequacy decision.
- Sharing data with a new third party
-
Transferring personal data to a new service provider, partner, or external organization.
- Change in processing method by which data subjects submit consent
-
: Replacing manual submissions introducing AI-based decision-making.
- New legal basis for processing
-
Applying a new law or regulation that changes the justification for using personal data.
Most laws do not clearly define what counts as a minor processing change, so each case must be assessed individually. Instead, they usually refer to “material changes” without listing all possible examples. A change may be considered minor if it does not qualify as major or high-risk. When reviewing the examples below, consider whether the change could be high-risk or have a significant impact.
Key considerations and reminders
Regulations do not define the concept of re-consent and such requests should be treated like regular consent requests. This means all the usual requirements, such as providing clear information to users, still apply. It is the responsibility of each customer to determine what constitutes a major or minor change within their specific context, as these classifications are not explicitly defined in the applicable regulations. Given this, it is important to carefully consider how changes are communicated to users, to ensure that any re-consent request meets the standards for valid consent.
For more information on purposes, see Setting Up Purposes of Processing.