Consent Version Control When Policies and Tools Change
Without version control, nobody can prove which banner and policy a visitor agreed to. A simple versioning discipline for consent.
Ask most sites a simple question: which banner wording and policy version did this visitor consent to last March. The usual answer is a guess. Consent records without versions prove that a click happened and almost nothing about what was agreed, which is the part that matters.
Version control for consent is not software engineering theatre. It is a small set of habits: number every change, tie records to versions, and keep old versions readable. This guide sets out the minimum that works.
Version the three things that change
Three artefacts decide what a visitor agreed to: the banner text and category descriptions, the cookie inventory and classifications, and the privacy policy sections describing data use. Each needs its own version identifier, and each change needs a date and a one line reason.
Keep the versioning boring: sequential numbers or dates, one shared register, no clever naming. The register should be readable by a non technical colleague under time pressure, because that is who will read it during a complaint.
Tie every consent record to its versions
A consent record should carry the banner version shown, the inventory version in force, and the timestamp, as a minimum. With those three fields, any historical consent can be reconstructed exactly. Without them, reconstruction is archaeology across old emails and memory.
Test the linkage after every platform or banner change: place a test consent, then pull its record and confirm the versions shown match the versions you believe are live. Version drift between what is live and what is recorded is common and silent.
Classify changes: editorial, material, and structural
Editorial changes fix wording without changing meaning and need a version note but no re ask. Material changes alter categories or data use and need a re ask. Structural changes, a new platform or a new consent model, need a re ask and a migration record. Writing those three definitions down ends most internal arguments about whether a change counts.
Record the classification decision and who made it for every material judgement call. Borderline calls are defensible when the reasoning exists on paper. They are indefensible when the only evidence is that nobody remembers discussing it.
Keep old versions accessible and exports current
Archive each superseded banner text, inventory, and policy version in a place the business controls, not only inside the consent platform. If the subscription ends or the vendor changes, the archive is what remains, and consent questions do not respect subscription end dates.
Export consent records on a schedule, monthly is a workable rhythm for most sites, and store exports with the version register. An export taken only during a crisis will be taken under the worst possible conditions and may miss exactly the period in question.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Consent Records for Subscription Checkouts That Renew for Years, Building a Consent Audit Trail Across Multiple Stores, and How Long Should You Keep Consent Logs? A Retention Schedule That Works.
Frequently asked questions
What should a consent record include to be provable?
The banner and inventory versions shown, the categories chosen, and a timestamp, as a minimum. Those fields let you reconstruct exactly what a visitor agreed to at any point in the past.
Which changes require asking visitors again?
Material changes: new categories, new kinds of data use, or a new consent platform or model. Purely editorial wording fixes that do not change meaning need a version note, not a re ask.
Where should old banner and policy versions live?
In an archive the business controls, outside the consent platform, alongside a simple version register with dates and reasons. Vendor only storage disappears exactly when a migration or dispute makes it necessary.
How often should consent records be exported?
On a fixed schedule, monthly for most sites, and after any structural change. Scheduled exports are complete and calm. Crisis exports are rushed and tend to miss the period that matters.