Strategy
A change-control template for a landing page, one row per change
Log every change to a live landing page in one row: old and new state, affected approvals, release decision and a recovery check, with a worked example.
A landing page keeps changing after launch. A new headline, a shorter form or an added tag can each void an approval that was given for the earlier version. A change-control record ties every edit to the approvals it affects and to a version that can be restored. No file is provided, so copy the text into your own document.
What to take away
- Write the baseline first, because a change row compares two states and the first must be recorded.
- Add a row for any change to the offer, the audience, the form, the tracking or the supplier terms.
- Reopen only the affected gates, and never assume an earlier approval transfers.
- A copied page is a new controlled object if its audience, claim or data path differs.
- Note the safe version and prove it restores before the change goes live.
Section 0: record the baseline first
A change row compares an old state with a new one, so the old state has to exist on paper. Before any tool is chosen, record the decision, owner, problem, route, evidence, objective and task. Leave an unknown blank, not an assumption.
Decision and baseline fields
- Decision to be made
- Decision owner and date
- Observed buyer problem
- Current route
- Baseline evidence
- Business objective
- Visitor task
Write each field with its own evidence:
- Decision to be made:
- [buy, configure, retain, replace or avoid a landing page tool]
- Decision owner and date:
- [name or role] | [date]
- Observed buyer problem:
- [event] | [affected population] | [period] | [source record]
- Current route:
- [existing website, manual page, form or other process]
- Baseline evidence:
- [query, version and extraction date] | [known gaps]
- Business objective:
- [measure, unit, population and period]
- Visitor task:
- [what an eligible visitor is trying to complete] | [research source]
A manual baseline as the control keeps later changes honest, and the objective should be one a defined event and denominator can measure. Do not make the page builder itself the problem statement.
What counts as a change
Add one row whenever the proposition, acquisition route, audience rule, form, tracking, supplier edition or contract changes. If an edit touches one of these, it changes a controlled object, however small it looks on screen. Headline tweaks that alter the offer belong here too.
A copied page is a new controlled object if its audience, claim or data path differs from the original. Reopen only the affected gates, but do not assume an earlier approval transfers automatically. The approval was given for one version, and a copy is a different version until a reviewer says otherwise.
Which evidence each change reopens
The table gives a starting point for the "affected evidence and approvals" line. A reviewer may add rows, but should not remove one without recording why.
| Type of change | Start with | Approval to reopen |
|---|---|---|
| Proposition or audience rule | Claim file and source-to-page promise | Claims |
| Form fields | Data map and form test | Privacy and accessibility |
| Tracking or tags | Technology inventory and consent test | PECR |
| Supplier edition | Supplier terms and access roles | Security |
| Contract | Exit, export and deletion terms | Contract |
For tracking, apply the ICO's storage and access technologies guidance to the technologies actually in use. A banner or supplier default does not decide the legal analysis. A purpose-by-purpose data map makes the form row quicker to check, and a changed claim belongs with the claims and testimonials checks.
The privacy approval for a changed form field is a UK GDPR and Data Protection Act 2018 question. The accessibility approval needs a direct check of the delivered page, because WCAG 2.2 is a technical reference, not proof of accessibility. The Equality Act 2010 is the wider legal frame in England.
The change-control row
Each row has four lines. Keep them short, and keep every row in one controlled workspace with a date and owner, so each version points back to its record.
| Line | What to write | Example for a shorter form |
|---|---|---|
| Change | Old state, new state, requester, date | Five-field form to three-field form, requested by the content editor |
| Affected evidence and approvals | Claim file, data map, test, reviewer | Privacy and claims |
| Release decision | Accept, reject or return, with owner and reason | Accept: the test met the recorded acceptance evidence |
| Recovery check | Last approved state and restoration evidence | Restore the previous form version |
Copy this blank row into the workspace for each change:
- Change:
- [old state] | [new state] | [requester] | [date]
- Affected evidence and approvals:
- [claim file, data map, test, reviewer]
- Release decision:
- [accept, reject or return] | [decision owner] | [reason]
- Recovery check:
- [last approved state] | [restoration evidence]
Worked example: a form gets shorter
The example is illustrative, so replace each entry with your own evidence. It follows one request from log to release.
- The content editor asks to replace a five-field form with a three-field form.
- The row records the old state, new state, requester and date.
- Privacy and claims are marked as affected, and only those two gates reopen.
- The decision owner accepts, because the test met the recorded acceptance evidence.
- The recovery check shows the previous form version can be restored before release.
Notice what the log does not do. It does not claim the shorter form is better, and it does not re-run approvals that the change could not affect.
The recovery line is for the person who withdraws
If monitoring finds a material defect after release, the withdrawal owner needs a known safe version to return to. The recovery check supplies it. Name that version and show it can be restored before the change goes live, not after a problem appears.
Supplier changes need the same care. Where the page runs in a page builder or other landing page software, the row records which edition and terms were in force.
For supplier risk, the NCSC says that choosing a cloud provider includes understanding security responsibilities, as described in the shared responsibility model. A new supplier edition is a row of its own, and the risk scenarios show how a supplier change can ripple through a page.
Before you act
- Write the baseline fields before the first change row.
- Name the decision owner and date.
- Log each edit that alters the offer, audience, form, tracking or supplier terms.
- List the affected evidence and approvals on each row.
- Name a safe version to restore for every release.
- Mark a copied page as a new controlled object.
Common questions
When does a change need its own row?
Whenever the page changes what it says, who it reaches, what it collects or which supplier terms apply. Each row shows the old and new state, the requester and the date.
Does an earlier approval carry over to a copied page?
Not automatically. A copy with a different audience, claim or data path is a new controlled object, so the affected gates reopen and the others stay as they are.
Why record a recovery check for every change?
It gives the withdrawal owner a version to fall back on if monitoring finds a material defect after release, plus proof that restoring it works.
