A customer disputes a charge and quotes your refund terms. A regulator asks what people were told about their data when they joined in 2024. A former partner says the terms never gave you the right to do what you did. Each question is about a past version of a page, and the page on your site today is not that version.
Many organisations answer by pulling the current text and hoping it has not changed. Some find they cannot say when it last did. This article covers why the old versions matter, what a useful record contains, and how to build one without much effort.
Why the live page is the wrong answer
Three rules, in two jurisdictions, make the old version the thing that counts.
Data protection (EU and UK). Under Article 5(2) of the GDPR, the controller "shall be responsible for, and be able to demonstrate compliance with" the data protection principles. Where processing rests on consent, Article 7(1) adds that the controller "shall be able to demonstrate that the data subject has given consent". Article 13 requires the privacy information to be provided "at the time when personal data are obtained". All three are about a moment in the past. You need to show what was provided then, not what you publish now. These are GDPR articles 5, 7 and 13.
The UK Information Commissioner's Office gives the practical consequence in its guidance on consent. You must keep records of who consented, when, what they were told at the time, how, and whether they have withdrawn. It also tells you to keep a master copy of the consent statement and "any separate privacy policy or other privacy information, including version numbers and dates matching the date consent was given", for as long as you rely on that consent. See the ICO guidance on recording consent.
Consumer terms (UK). Under section 62 of the Consumer Rights Act 2015, a term is unfair if, "contrary to the requirement of good faith, it causes a significant imbalance in the parties' rights and obligations under the contract to the detriment of the consumer". Whether it is fair is decided "by reference to all the circumstances existing when the term was agreed". The text a consumer agreed to is the text a court will examine. See section 62.
Time. In England and Wales, an action founded on simple contract cannot be brought more than six years after the cause of action accrued (Limitation Act 1980, section 5). A dispute can therefore arrive years after a version was retired. Other limits apply to other claims and other countries, so treat six years as an illustration of how long a gap can be, not as a retention period.
What a useful record contains
A version history that holds up has five things for each version.
- The text as it appeared. Not a summary and not your source document. The page the visitor saw, including the footers, linked schedules and fine print.
- The address. Terms are often split across several pages: a privacy policy, a cookie policy, a service agreement, a refund page. Record each address.
- The date range it was live. The start date is when it was published. The end date is when the next version replaced it. Without both, you cannot say which version a given customer saw.
- Evidence the record was not edited afterwards. A document you can edit proves little. A fixed digest and an independent timestamp are what separate a record from a recollection. We explain what a hash proves and how to check a timestamp in earlier posts.
- The reason for the change. A line saying "new processor added" or "refund window shortened to 14 days" makes the history readable when the person who made the change has left.
Your content management system may hold revisions, and that is worth keeping. But a revision history is internal and editable, and it records what you entered, not what the public site served. Templates, includes, cached pages and a CDN can all make those differ. A capture of the public page records what a visitor was served.
Build the history in four steps
1. List every page that states a rule. Privacy policy, cookie policy, terms of service, refund and returns policy, acceptable use, service levels, pricing and plan pages, and any page a sign-up form links to. If a customer clicked "I agree" beside it, it belongs on the list.
2. Capture each one now. You cannot recover the versions you did not keep, so start with today's. Note the date next to each as the baseline for the history.
3. Capture on release day, and again on a schedule. Capture by hand when you publish a change, ideally just before and just after. Then add a regular capture to catch changes you did not make or did not hear about: a developer editing a template, a marketing tool rewriting a footer, a legal page changed by a plugin update. Our post on how often to capture a page suggests weekly for your own terms and policies.
4. Keep a change log beside the captures. One line per change: date, what changed, who approved it, and the address. It is the index to the archive, and it lets you answer "which version applied on 3 March?" in a minute.
Questions you should be able to answer
Test your record with the questions you are most likely to be asked:
- What did the privacy policy say on the day a named person signed up?
- When did we start sharing data with this processor, and when did the policy say so?
- Which refund terms applied to an order placed on a given date?
- Was this clause present at the time of the dispute, or added afterwards?
- Can we show that these files have not been edited since they were saved?
If any of these takes more than an afternoon, or depends on a person's memory, the record has a gap. Fix the gap while nothing is in dispute.
Common gaps
Only the current version is stored. The most common failing. Overwriting the page is easy and leaves nothing behind.
Sign-up flows are not recorded. The policy is one half of "what they were told". The other half is the form, the checkbox wording and any notice shown at the point of consent. Capture the sign-up page too, as far as it is public. A page behind a login is outside what a public capture can reach, so for those, record screenshots and form text in your own change log.
Minor edits skip the log. A corrected typo is harmless. A changed number, a new party or a removed right is not. Log all of them and note which kind each was.
Records live on one laptop. Keep the files where the team can reach them, under a retention rule someone owns.
How Archivepanel helps
Archivepanel captures public pages, one at a time, without logging in. Each capture is a self-contained HTML file with the scripts removed, plus a preview, a plain-text version, a WARC file and a JSON manifest holding a SHA-256 digest of each file. A DigiCert RFC 3161 timestamp is requested for the document when it completes. It is a standard timestamp you can verify with OpenSSL, not an eIDAS qualified timestamp.
For this job, the useful parts are plain. You can capture each policy by hand on release day, and a note and up to twelve tags on a record can carry the reason for the change. On the paid plan, a weekly schedule on each page builds the history without anyone having to remember. Compare with previous shows removed and added lines between two snapshots of the same address, in text only, so a change in layout or images will not show. Snapshots are never rewritten, and the free tier gives you 100 MB to begin.
Sources
- Regulation (EU) 2016/679 (GDPR), Articles 5(2), 7(1) and 13.
- Information Commissioner's Office, How should we obtain, record and manage consent?
- Consumer Rights Act 2015, section 62, legislation.gov.uk.
- Limitation Act 1980, section 5, legislation.gov.uk.