Who actually delivers your GEO work? Map the supplier dependency chain

Map the real delivery chain before comparing suppliers

A proposal may name one GEO supplier while the service actually depends on several people, buyer approvers, publishing systems, monitoring tools, hosting services, language reviewers and specialist subcontractors. The buyer cannot assess access, continuity, change or exit if these relationships stay hidden behind a single supplier name.

Start with each promised deliverable and trace what must happen for it to reach an accepted state. For a bilingual factual correction, that might include an approved source, English and Chinese owners, repository access, a release platform, domain controls, validation evidence and a buyer decision. This is a delivery map, not an accusation that every dependency is risky; it shows where ownership and assurance are needed.

Complete one eight-field dependency register

Ask the supplier to complete the register for the proposed scope, then compare it with the actual mobilisation and delivery workflow. A dependency is controlled only when its function, owner, access, change route and replacement or exit path are visible.

Use the right label for each external party

Do not call every external dependency a sub-processor. A subcontractor may provide research or language review; a processor or sub-processor processes personal data for the controller; a SaaS vendor supplies a tool; and a search, AI or social platform may publish or interpret public material under its own terms. One organisation can occupy more than one role, but the control must follow the specific activity.

Where a GEO supplier acts as a processor and appoints a sub-processor, the ICO says the controller's prior specific or general written authorisation is required, intended changes under general authorisation must be notified with an opportunity to object, and equivalent Article 28 data-protection obligations must flow down. These requirements should not be applied to parties that do not process personal data, but privacy labels must not be used to conceal real access.

• Record the legal entity and service, not only a product name or logo.
• Separate buyer-owned accounts from supplier-owned licences and public platforms.
• Identify who can view, change, publish, approve, export and delete information.
• Document geographic access and personal-data processing in the separate data-protection assessment where applicable.

Keep ownership and decision rights visible

For each handoff, record who supplies the input, who performs the work, who approves it and who accepts the result. The buyer should normally keep verified ownership of its domain, publishing systems, primary data, brand facts and emergency administrator access. Supplier access can then be scoped to the agreed task without transferring institutional control.

The NCSC's supply-chain guidance is aimed at procurement and risk teams that need confidence in supplier mitigations, while its current continuity guidance recommends understanding critical services and dependencies and involving delivery partners and suppliers in advance. Apply those principles proportionately: a short audit needs less machinery than an ongoing multilingual publishing and monitoring service, but both still need a visible source of truth and acceptance owner.

Set change notices and retest triggers

The register should be a live control, not a questionnaire filed after onboarding. Agree which changes require notice or approval: a key-person replacement, new subcontractor or sub-processor, different AI or monitoring tool, new hosting or data location, altered publishing access, material workflow change, failed control, acquisition, financial distress or planned exit. The notice period and decision route should follow the service's risk and contract rather than a universal number.

When a dependency changes, update the map, identify affected deliverables and repeat only the relevant acceptance tests. A new language reviewer may require authority, briefing and sample approval checks; a new platform may require ownership, permission, export, evidence and recovery checks. Record the decision and residual risk instead of treating notification alone as acceptance.

Run a dependency-removal acceptance test

Choose one important deliverable and remove one dependency in a tabletop test. For example, assume the primary delivery lead and the normal monitoring workspace are unavailable while a bilingual service fact must be corrected. Ask the team to identify the authoritative fact, activate alternate roles, use buyer-controlled access, preserve approval, publish or prepare the change, validate both language versions and record any blocked step.

The test passes when the workflow, decision owners, evidence and recovery or transfer route are demonstrable—not simply when someone says an alternative exists. Feed each gap back into the dependency register with an owner and review date. For exit, the GOV.UK Sourcing Playbook recommends early planning, clear activities, roles, timelines, interfaces and dependencies, asset transfers, contract-data protocols and sufficient knowledge transfer; use that as a proportionate checklist rather than assuming the incumbent will always be available.

How SALIENS supports controlled GEO delivery

SALIENS provides GEO audits, AI visibility monitoring, content and technical improvements, and ongoing GEO delivery. An agreed scope can include a buyer-owned dependency register, named roles and approval gates, platform and data-access boundaries, change records, supplier checks, release evidence and an exit handover. These controls improve visibility and accountability; they do not guarantee crawling, indexation, AI mentions, citations, rankings, traffic or enquiries.

Email info@oxfordintelligence.co.uk with your website, markets and languages, proposed deliverables, existing systems and approvers, known external parties, access constraints and transition requirements. SALIENS is operated by Oxford Intelligence Limited. This guide is a procurement framework, not legal, data-protection, cyber-security or continuity advice; the buyer should assess specialist obligations for its own circumstances.