Consent Evidence Is a Timeline. Keep the Versions.
A single page app loads the consent tool once and then navigates without reloading. Any tag logic that assumed a fresh page load, a fresh consent read, a fresh page view event, silently runs on stale assumptions. Consent itself may be stored correctly while the firing logic built around page loads never revisits it.
Consent evidence needs version history: dated screenshots, configuration exports, and notice versions, each tied to the dates it ran. A consent record that points at a notice version the team cannot produce proves nothing, because the auditor cannot check what the visitor actually agreed to.
What an audit actually asks for
The questions are specific. What purposes were shown on this date. What notice version was live. What did the banner look like, and what did the buttons say. What was the visitor's choice, and when did they change it. A record with a timestamp and a choice but no version answers two of those questions and leaves the rest open.
The gap is usually the banner itself. Teams keep the current configuration and overwrite it with every change, so last year's banner exists only in memory. The consent records survive; the thing they consent to does not. That is backwards, and it is the most common evidence failure on consent audits.
What to keep, and how to keep it
Keep a dated screenshot and a configuration export for every banner version, stored with the date it went live and the date it was replaced. Keep every privacy notice version the same way, with the same dates. The export does not need to be pretty; it needs to be retrievable by date, by a person who was not on the team when it was saved.
Tie the consent record to the version. Each record should carry the notice version the visitor saw, so an auditor can pull the version file and the record side by side. If your consent platform cannot store the version in the record, keep a version log with the dates each version ran, and let the record's timestamp do the join.
Testing retrieval before an auditor does
Pick a consent record from six months ago and produce the complete evidence for it: the record, the notice version, and the banner screenshot, using only the tools and access the team has today. Time the exercise. If it takes a vendor ticket or a colleague who has left, the evidence keeping has already failed, and the fix is a storage habit, not a search.
Run that test quarterly. Banner versions change with copy edits, design updates, and vendor updates, and each change that goes unrecorded opens a gap in the timeline that cannot be closed later.
Keep reading: Single Page Apps Break Consent in a Specific Place: The Route Change, Your Banner Speaks Three Languages and Your Site Speaks One: Consent Language Matching, and Embedded Maps, Videos, and Widgets Set Cookies Your Banner Never Mentions cover the nearby cases in this series.
Frequently asked questions
How long should banner versions be kept?
For as long as the data collected under them is held, plus the period in which a complaint or claim could be brought. Deleting the version while keeping the data is the combination to avoid.
What is a configuration export?
A saved copy of the banner settings: purposes, categories, button labels, and the consent platform configuration, exported on the date it changed. A screenshot helps, but the export carries details a screenshot misses.
Does the consent record really need the notice version?
Yes. Without the version, the record shows a choice but not what was agreed to. Auditors ask for the version because consent is specific to the purposes shown at the time.
Who should own version keeping?
The same person who owns the consent platform changes. Every banner or notice change triggers the export, so the habit has to sit with the change, not with a separate quarterly task.