Cookie Policy Version History: Track Every Change, Compare Revisions, and Restore a Previous Policy
Every consent banner is one careless save away from a problem: a teammate edits the wrong policy, a translation gets overwritten, or a domain assignment quietly changes and nobody notices until a visitor — or a regulator — does. If you've ever searched for how to recover an overwritten cookie policy, see who changed a privacy policy and when, or prove GDPR policy change history during an audit, you already know the pain this causes.
Some teams try to work around this with manual backups — exporting policy text into a shared doc before every edit, or asking whoever made the change to remember what it looked like before. That approach is slow, easy to skip under deadline pressure, and gives you no reliable record of who changed what, when. Other consent platforms bolt on basic edit logs that tell you a change happened but not what the policy actually said before or after — useless when you need to put the exact previous wording back in front of visitors.
Secure Privacy's built-in policy version history solves this natively: every saved change to a privacy or cookie policy is automatically kept as a full, immutable snapshot, reviewable from a dedicated Versions tab, with one-click restore. By the end of this article, you'll know exactly how versions are created, what a restore does and doesn't touch, how to read and manage your version history, and how it fits alongside Secure Privacy's audit log for full compliance traceability.
Who Is This For
This article is for Secure Privacy admins and compliance teams who manage cookie or privacy policies across one or more domains — especially anyone responsible for GDPR, ePrivacy, or internal audit readiness, or anyone who has ever needed to undo an unwanted policy edit.
Prerequisites
An active Secure Privacy account with at least one saved cookie or privacy policy.
Restoring a version and bulk-deleting versions both require Admin permissions.
What Is a Policy Version?
A version is an immutable copy of a policy's content at the moment it was saved, together with the ID of the person who saved it. Versions are numbered sequentially per policy starting at 1, and the highest version number always mirrors the current live policy. Nothing beyond the snapshot and its provenance is stored in a version record — that separation from the audit log is intentional (more on that below).
When a New Version Is Written
Trigger | Recorded As | Notes |
|---|---|---|
Policy created | Version 1, by the creator | Also applies to a duplicated policy, which starts its own history. |
Policy edited | Next version, by the editor | Only when the save actually changed the stored content — a no-op save writes nothing. |
First edit of an older policy | Baseline version, no user | Policies that predate this feature get their pre-edit state captured, so it stays recoverable. |
Version restored | New version, by the restorer | The restore is appended rather than rewinding, so it can itself be undone. |
Policy enabled / disabled | Nothing | Status is an operational change, recorded in the audit log only. |
How to Restore a Previous Cookie Policy Version in Secure Privacy
Restoring copies the stored content onto the live policy and appends a new version. Four fields are deliberately left on their live values — restoring content must never quietly change where a policy is published or whether it's live.
Which Fields Are Restored
Field | Restored? | Why |
|---|---|---|
Name | Yes | — |
Version (customer-facing label) | Yes | The customer-facing version label. |
ExistingPolicyURL | Yes | — |
Laws | Yes | — |
CustomerPolicy | Yes | The questionnaire answers. |
LegalPolicyTranslations | Yes | — |
LanguagesEnabled | Yes | — |
Domains | No | Unassigning takes a policy off a live site, so it must be explicit. |
MobileApplicationIds | No | Same rule as domains. |
Enabled | No | A restore must not put a disabled policy back in front of visitors. |
Type | No | Settable only at creation; it decides which policy a domain may hold. |
The policy name is unique per account, so a restore is rejected if another policy has taken the snapshot's name in the meantime. Every restore is written to the audit log as a normal policy update, naming the version number that was restored.
Step 1 — Open the Versions Tab
Go to the policy page for the cookie or privacy policy you want to review, and open the Versions tab. Revisions are listed newest first, showing the version number (with a Current marker on the live one), the policy name as it was at the time, when it was saved, and who saved it. Hover any date to see the exact UTC timestamp.
Step 2 — Review the Snapshot Before Restoring
Open a specific version to see its full stored snapshot before committing to a restore, so you know exactly what content — including translations — will go live.
Step 3 — Restore the Version
Click Restore on any row except the current version. This requires Domain Admin permissions. The stored content is copied onto the live policy, a new version is appended (the restore doesn't rewind history, so it can itself be undone later), and domain assignments, mobile app assignments, the Enabled status, and Type are left untouched on their current live values.
Step 4 — Confirm the Live Policy
Check the policy page to confirm the restored content is live, and check the audit log if you need a record of who performed the restore and which version number was restored.
What Happens After You Restore a Version
A brand-new version is appended to the top of the history — the restore itself becomes reversible.
Domain and mobile app assignments, Enabled status, and Type stay exactly as they were before the restore.
The change is logged in the audit trail as a standard policy update, referencing the restored version number.
If another policy has since taken the snapshot's name, the restore is rejected until the naming conflict is resolved.
Deleting Policy Versions
Delete is available per row and in bulk, gated on the same permission as deleting a policy. Deletion is permanent: deleting versions removes those snapshots outright, and deleting a policy removes its entire history. Deleting an account's policies deletes that account's versions as well.
You don't need to manage this manually for storage reasons — only the oldest versions are pruned automatically once a policy passes 50 stored revisions, so recent history is always retained.
Data Storage and Retention
Snapshots are stored in SPPolicyVersion, indexed on PolicyId + VersionNumber and AdminId + PolicyId + VersionNumber. Each append prunes anything beyond the newest 50 revisions for that policy, bounding a collection whose documents carry every translation of a policy. Version numbers are read from the primary database, so replication lag can't hand out the same number twice.
Policy Version History vs. the Audit Log — What's the Difference?
These two systems deliberately don't duplicate each other. The audit log answers who changed what, and when — it carries field-level diffs for names, domains, laws, languages, status, and policy text, including a record of every restore. Version history answers a different question: what did this policy actually say at that point, and can I have it back? A version record has no action type, no changed-field list, and no status flag — for that level of detail, go to the audit log.
The Versions tab lists every saved revision of a cookie policy, newest first, with restore and delete actions per row.
Troubleshooting Policy Version History
I don't see a Restore option on a row
Restore is hidden on the current version's row by design — there's nothing to restore to on the version that's already live.
My restore was rejected
This happens when another policy in your account has already taken the snapshot's name. Rename the conflicting policy, then try the restore again.
I don't have permission to restore or delete versions
Both actions require Admin access. Ask your account owner to grant that role, or to perform the restore or deletion on your behalf.
A very old policy is missing early versions
Policies created before this feature launched get a baseline version captured on their first edit after launch, with no associated user — this is expected, not a data gap.
Saved by shows "System" instead of a name
That's expected for baseline versions captured automatically for pre-existing policies rather than saved by a person.
FAQ: Cookie Policy Version History & Restore
Can I recover a cookie policy after it was accidentally overwritten?
Yes. Every saved change is kept as a full snapshot in the Versions tab, so you can open the previous revision and restore it as the live policy at any time.
Does restoring an old policy version change which domains it's published to?
No. Domain assignments, mobile app assignments, the Enabled status, and the policy Type are always left on their current live values — a restore only brings back the policy content and questionnaire answers.
How many previous versions of a cookie policy does Secure Privacy keep?
Up to 50 revisions per policy. Once a policy passes that number, only the oldest versions are automatically pruned, so your most recent history is always retained.
Who can restore or delete a policy version?
Restoring a version and deleting versions (individually or in bulk) both require Admin permissions on the account.
What's the difference between policy version history and the audit log?
Version history stores what a policy actually said at each save so you can bring it back. The audit log stores who changed what and when, including field-level diffs and a record of every restore — the two are complementary, not duplicates.
Is deleting a policy version permanent?
Yes. Deleting a version removes that snapshot outright, and deleting a policy removes its entire version history — there's no separate recovery step after that.