GEO supplier change control

How should buyers control changes in a GEO engagement?

Use a six-part GEO change-control decision record to define the request, baseline, impact, evidence, authority and implementation checks before scope, cost or delivery changes.

Published by SALIENS · Published 2026-10-27

Do not let routine iteration become an unapproved commitment

GEO delivery evolves: a new market may be added, a content template may change, a monitoring question set may expand, an AI tool may be replaced, or a technical recommendation may require more implementation than expected. Some adjustments fit within the agreed working method; others alter scope, price, timing, risk, data access, responsibilities or acceptance. The buyer needs a clear boundary between the two.

The UK Government's March 2026 Contract Management Playbook describes change control as the formal process for changing what is detailed in a contract. Its example moves from a defined request through proposal, review, decision, sign-off and record. GovS 008 requires changes to be justified and controlled, with quantified cost, approval before implementation, an audit trail and retained evidence. These standards do not determine the terms of a private GEO engagement, but they provide a useful buyer discipline.

Create one six-part GEO change-control decision record

Use one record for material changes and define a lighter route for agreed operational adjustments. Give every request a stable ID, owner, status and decision date. Record rejected and withdrawn requests as well as approved ones so that the same proposal does not return without its earlier context.

GEO change-control decision record
Decision area	What to record	Buyer test
1. Request and trigger	Requester, date, reason, affected outcome, urgency, proposed change and whether work has started.	Is there a specific request rather than an informal instruction or assumed expansion?
2. Current baseline	Approved scope, deliverable, price, timetable, method, question set, content or technical version, responsibilities and acceptance criteria.	Can the buyer identify exactly what would change from the current agreement?
3. Impact	Effects on cost, timing, quality, risk, data, security, accessibility, languages, dependencies, licences, handover and other commitments.	Are direct and knock-on effects visible rather than hidden inside one price or deadline?
4. Evidence and options	Source evidence, assumptions, alternatives, do-nothing option, benefits, limitations, dependencies and confidence.	Could a reviewer understand why this option was chosen and what remains uncertain?
5. Decision and authority	Approve, approve with conditions, reject, defer or withdraw; authorised decision-maker, advice obtained, conditions, funding and signatures where required.	Was the decision made by the right people before implementation?
6. Implementation and closure	Owner, release plan, communications, version updates, validation, acceptance result, rollback route, residual actions and closure date.	Did the delivered change match the approved request, and was the baseline updated?

Define what needs formal approval

Set thresholds before delivery begins. A wording correction inside an approved page and review route may be ordinary delivery. Adding a country, language, page family, data source, privileged access, subcontractor, tool, recurring report, implementation responsibility or new acceptance metric may require a formal decision. A change can be material even when its price is zero if it alters risk, data use, quality or ownership.

Avoid using a change request to repair an incomplete original commitment without first identifying the cause. If work is already included, record it as contract performance or correction. If the requirement has genuinely changed, show the baseline and assess the variation. This prevents buyers from paying twice and prevents suppliers from absorbing unlimited work through informal instructions.

List examples of included iteration, formal change and emergency action in the statement of work.
Set financial, schedule, risk, data and access thresholds; do not use price as the only trigger.
Name who may request, assess, approve, fund, implement and accept each class of change.
Stop material work until approval unless the documented emergency route applies.

Assess the whole delivery system, not one isolated task

A request to add a new monitoring market may also require new approved facts, translations, question sets, reviewer capacity, licences, privacy assessment, reporting denominators and a revised baseline. Ask the supplier to trace the proposed change through the affected people, systems, evidence, dependencies and acceptance tests. State assumptions separately from verified facts.

Compare at least the proposed option with keeping the current baseline. Where practical, include a smaller or staged option. Quantify cost and time, but also show who carries each risk and which existing commitment moves or stops. An attractive change is not automatically affordable, authorised or better value than completing the agreed plan.

Close the change only after validation

Approval is not closure. Link the decision to the implementation release, update the working scope and relevant versions, communicate new responsibilities, and perform the agreed acceptance check. If the result differs from the approved request, raise a defect or a new change rather than silently rewriting the record.

For an urgent factual, security or access issue, use a pre-agreed emergency route with a named authority, minimum evidence, bounded action and retrospective review deadline. Emergency action should not become a standing bypass. Record the final state, remaining risks, rollback outcome where used, and which superseded documents or configurations are no longer current.

Sample one approved, one rejected and one emergency change and trace each decision end to end.
Confirm the supplier did not start billable or production work before the applicable approval.
Check that scope, price, schedule, evidence register and acceptance criteria now agree.
Keep rejected and withdrawn requests searchable with their reasons and dependencies.

Ask SALIENS for controlled, reviewable GEO delivery

SALIENS provides GEO audits, AI visibility monitoring, content and technical improvements, and ongoing GEO delivery. A scoped engagement can define change thresholds, request templates, impact evidence, decision rights, versioned question sets and deliverables, English and Simplified Chinese review, release checks and buyer-controlled decision records.

Email info@oxfordintelligence.co.uk with your website, markets and languages, current scope, approval and budget owners, systems and access, delivery dependencies, change concerns and procurement timetable. SALIENS is operated by Oxford Intelligence Limited. Change control supports accountable delivery but does not guarantee crawling, indexation, AI mentions, citations, rankings, traffic or enquiries. This guide is a procurement framework, not legal or commercial advice.

Sources

Prepared with AI assistance using the linked sources and SALIENS service information.