How should you test a GEO supplier's business continuity plan?

Test continuity separately from incident response

Yesterday's incident-response question was about detecting, escalating, containing and correcting a specific event. Business continuity asks a different procurement question: if a person, platform, account, data source or supplier becomes unavailable, which GEO services must continue, at what minimum acceptable level, and how will the buyer know recovery is safe? A supplier can have a polished incident plan yet still depend on one person, one login or one undocumented workflow.

Start with the buyer's outcomes rather than a generic promise of high availability. A one-off audit may tolerate a short delay; a multilingual factual correction, critical admissions page or controlled release may not. Define priorities, tolerable interruption and evidence-loss limits for each deliverable. These are buyer decisions informed by risk, not universal figures that a supplier can invent.

Complete an eight-part recovery acceptance record

Ask the supplier to complete one record for the real scope and then demonstrate the controls. A document that names no assets, people, dependencies or acceptance evidence is not yet a usable continuity plan.

Map the service before choosing recovery targets

The NCSC advises organisations to identify business-critical services and their dependencies so that feasible workarounds can be prepared and restoration sequenced. For a GEO engagement, map the actual chain: approved facts, content owner, language reviewer, source repository, publishing platform, domain controls, analytics or monitoring access, release evidence and third-party services. Include the supplier's own key people and sub-processors where they are essential.

Then assign a buyer-approved service priority. Record what a minimum viable service means—for example, preserving approved content and maintaining a correction route even while non-critical optimisation work is paused. A recovery-time objective is useful only when its start point, end point, scope and evidence are clear. The same applies to acceptable data or evidence loss: decide whether drafts, approvals, monitoring observations and release records must be restored, reconstructed or can be recreated.

• Keep verified ownership of domains, publishing systems and emergency administrator access with the buyer.
• Store the dependency map, recovery instructions and buyer contacts somewhere accessible when the normal workspace is unavailable.
• Do not assume a SaaS provider's availability automatically covers the supplier's people, access, data or process dependencies.
• Identify which workarounds create new records and how those records will be reconciled after restoration.

Run one recovery exercise, not only a document review

Use a scenario that removes more than one convenience. For example: the primary delivery lead is unavailable, the normal project workspace cannot be reached and an approved bilingual service fact needs correction before the next release. Ask the supplier to activate the alternate contact, retrieve the last approved state, prepare a correction without bypassing approval, preserve the change record and communicate what is known, blocked and next being tested.

The NCSC says continuity and recovery plans should be tested regularly because plans often fail in practice. A useful test records actual timings and decisions, but it should pass on evidence rather than speed alone: the right people were reached; ownership remained with the buyer; the correct version and language relationship were restored; interim work was reconciled; live output was checked; and every gap became an owned, dated improvement. For technical restoration, a claimed backup is not enough—the restore and reconciliation process must function.

Connect continuity to contract management and exit

Continuity is a shared operating control, not a paragraph left unread in a supplier policy. GOV.UK contract-management principles call for clear accountability, documented governance and suitable continuity and contingency plans. The Sourcing Playbook also emphasises early exit planning, defined activities, responsibilities, timelines, dependencies, asset transfers and knowledge transfer. The exact proportionate approach will differ for a small advisory engagement and a critical managed service.

Set review triggers: a key-person change, new platform or sub-processor, material scope change, failed exercise, ownership change, major incident or approaching exit. Require the supplier to update the dependency record and retest affected controls rather than refreshing only the document date. At exit, verify returned files and evidence, transferred knowledge, revoked access, deletion where agreed and the buyer's ability to operate the critical workflow.

How SALIENS supports resilient GEO delivery

SALIENS provides GEO audits, AI visibility monitoring, content and technical improvements, and ongoing GEO delivery. A scope can include a buyer-owned dependency register, named delivery cover, approved-content records, controlled workarounds, recovery checks, communication routes and an exit handover appropriate to the agreed service. These controls improve recoverability and accountability; they do not guarantee uninterrupted service, crawling, indexation, AI mentions, citations, rankings, traffic or enquiries.

Email info@oxfordintelligence.co.uk with your website, markets and languages, critical GEO deliverables, current owners, platforms, access model and continuity requirements. SALIENS is operated by Oxford Intelligence Limited. This guide is a procurement framework, not legal, cyber-security or business-continuity advice; the buyer should set its own risk thresholds and obtain specialist advice where required.