Five landing page software risks, from an unsupported AI claim to a supplier change

Landing page software risk scenarios help an England operator rehearse decisions before a failure. They are not forecasts. Probability, tolerance and recovery targets remain blank until the buyer supplies evidence and accountable owners approve them.

What to take away

AI output introduces an unsupported claim

Scenario. A connected drafting tool changes an objective product claim or qualification. Trigger: the generated version differs from the approved evidence record. Leading indicators: missing citations, altered numbers or a release without human approval. Counter-signal: a clean comparison against the signed source pack.

Owner: advertising and content approver. Response: stop publication, disable the affected automation and restore the last approved page. Recovery proof: the corrected final render links each claim to current documentary evidence. The ASA's substantiation guidance supplies the UK advertising evidence boundary.

For an England operator, an AI-written "clinically proven" line on a supplement page falls inside the ASA's remit if the signed evidence pack does not support it.

Probability: not set. To fill it, divide qualifying failures by comparable releases over the last 12 months. For illustration, 2 failures in 200 releases is 1 in 100, or 1%.

A page connection exposes unapproved assets or data

Scenario. An AI or integration receives broader page, account or visitor information than the approved task requires. Trigger: permission, destination or supplier documentation changes. Indicators include a new service identity, unexplained transfer or secret in a prompt. A current access map and least-privilege test are counter-signals.

Owner: security lead with data-protection review. Response: revoke access, preserve logs, assess affected information and follow the incident plan. Recovery proof: rotated credentials, repeated permission tests and an approved data map. The government's AI Cyber Security Code covers assets, supply chains, prompts, monitoring and disposal. It is guidance, not product certification.

For an England buyer, the ICO's UK GDPR duties apply if visitor data leaves the approved purpose.

Measurement coverage changes silently

Scenario. A tag, pixel or visitor choice changes recorded events, but a report presents the difference as demand. Trigger: technology, purpose, permission flow or browser behaviour changes. Indicators: unexplained missing events or a shrinking unattributed category. Counter-signal: a versioned tag register and reconciled source totals.

Owner: measurement lead, with PECR and data-protection specialists deciding the configured legal questions. Response: annotate the break, stop trend comparisons and rebuild the eligible population. Recovery proof: reproducible queries and disclosed missing data. Use the ICO's final April 2026 storage and access guidance for current regulator context.

An England retailer that adds a new pixel without updating its consent banner risks PECR action from the ICO.

Generated changes block a critical journey

Scenario. A page variant prevents keyboard completion, obscures focus or produces an unusable error state. Trigger: template, component, copy or integration release. Indicators: failed critical-task tests and unresolved defects. Counter-signal: representative retesting across the supported journey.

Owner: accessibility reviewer and release owner. Response: withdraw the version and restore the approved build. Recovery proof: defect closure tied to the relevant WCAG 2.2 criterion and a successful retest. WCAG is a technical standard; qualified legal review remains separate.

In England, a private retailer still owes Equality Act 2010 duties, and the EHRC can act on accessibility failures.

Supplier change weakens continuity

Scenario. A provider changes a plan, technical route or export behaviour needed by the service. Trigger: revised terms, notice or failed scheduled export. Indicators: inaccessible records, unowned domains or dependence on one operator. Counter-signals: readable exports and a tested alternative publishing route.

Owner: service and procurement leads. Response: freeze non-essential change, preserve assets and invoke the approved transition plan. Recovery proof: the buyer publishes the synthetic baseline elsewhere and reconciles required records.

Retire this scenario only when the dependency ends; otherwise retest on the buyer-set interval. For illustration, use 90 days after the last evidence review. The service owner records the interval in the scenario register and the procurement lead approves it.

A typical England supplier term is 30 days' written notice to change a plan or technical route.

Setting probability and tolerance

When evidence arrives, the accountable owner sets probability from observed qualifying failures divided by comparable releases. Tolerance is the maximum acceptable impact before the response plan triggers.

The owner records the probability, tolerance, retest interval and approval date in the scenario register. The service owner approves the supplier scenario; the advertising and content approver approves the AI claim scenario.

Before you act

Common questions

What should be recorded for each scenario?

Each owner should record assumptions, source dates, observable signs and the condition that would disprove the scenario. These records support the rehearsal and keep the scenario tied to evidence rather than forecast.

When can a scenario be retired?

The service and procurement leads retire the supplier change scenario when the provider is no longer needed. They record that decision, the next review date and the approval in the scenario register.

What is the counter-signal for the AI claim scenario?

A clean comparison against the signed source pack is the counter-signal. Leading indicators include missing citations, altered numbers or a release without human approval. The owner is the advertising and content approver.