GEO supplier access and governance
What access should you give a GEO supplier?
Use a least-privilege access register and staged approval workflow to give a GEO supplier enough access to deliver without handing over unnecessary control.
Published by SALIENS · Published
Start with tasks, not an administrator request
A GEO supplier may need to inspect search data, review analytics, prepare content, examine templates or structured data, and verify a release. Those tasks do not automatically require ownership of Search Console, administrator access to analytics, unrestricted CMS publishing, a shared company password or permanent production credentials.
The UK National Cyber Security Centre recommends least privilege: identities should receive only the access required for their role, privileged access should be used only when necessary, and third-party access should be revocable. For a GEO engagement, the buyer should translate each agreed task into the smallest usable permission, a named identity, an approval owner and an expiry condition.
Match access to the delivery task
Use the platform's own roles where they exist and keep the organisation's verified owner or administrator accounts under buyer control. The exact role depends on the agreed scope and the system's current permission model; the following matrix is a purchasing starting point, not a request for every listed system.
| Delivery task | Typical minimum access | Control to retain |
|---|---|---|
| Search performance review | A named Search Console user role sufficient to view the required reports and inspection evidence. | The buyer retains verified ownership and user-management control. |
| Analytics review | Viewer or Analyst-level access to the relevant property, with data restrictions where appropriate. | Do not grant Administrator merely to read reports; keep user management with the buyer. |
| Content recommendations | Approved page exports, briefs or a draft-only CMS role. | The buyer controls final factual approval and production publication. |
| Content implementation | A scoped editor role for agreed sections, preferably with preview or staging. | Separate drafting, approval and publishing where the platform allows. |
| Technical review | Read access to the relevant templates, repository area, rendered pages or configuration evidence. | Do not expose unrelated repositories, environments, customer data or secrets. |
| Technical change | A time-bounded branch, staging environment or change request for the agreed files. | Require review, tests and an authorised production release. |
| AI visibility monitoring | The approved question set, markets, languages and observation record. | Monitoring alone normally does not justify CMS or production access. |
| Evidence exchange | A dedicated folder containing only approved source material and delivery records. | Avoid granting access to an entire drive, inbox or customer workspace. |
| API or automation | A buyer-managed service identity limited to the required operation, if the scope genuinely needs it. | Do not share personal credentials; record ownership, storage, rotation and revocation. |
| Handover and exit | Read access long enough to export agreed deliverables and verify transfer. | Revoke supplier identities, tokens and integrations and preserve buyer-owned copies. |
Complete an eight-field access register
Record access before inviting a supplier. One row should represent one identity in one system; broad labels such as “website access” or “analytics access” are not precise enough for approval or removal.
| Field | What to record |
|---|---|
| Task and deliverable | The specific agreed work that requires access and the evidence it must return. |
| System and boundary | The property, site, folder, repository, environment or account in scope—and what remains out of scope. |
| Named identity | The supplier person or buyer-managed service identity; avoid generic shared accounts. |
| Permission level | The exact role, data restriction and permitted actions. |
| Reason and alternatives | Why this access is necessary and whether an export, screenshot, draft or supervised session would be enough. |
| Approval and review owner | The buyer who approves access and the person responsible for periodic review. |
| Start, review and expiry | When access begins, when it must be reviewed and the event or date that ends it. |
| Evidence and revocation | Where activity or change evidence is stored and how removal will be confirmed at pause, role change or exit. |
Use a staged access workflow
Access should expand only when the next accepted delivery stage requires it. A useful sequence is: read-only discovery; written recommendation; approved draft or change set; staging or preview verification; authorised production release; post-release evidence; and removal or reduction of access. A supplier should not keep broad write access merely because it may be useful later.
Google Search Console distinguishes owners, full users and restricted users, while Google Analytics provides Administrator, Editor, Analyst and Viewer roles plus data restrictions. Buyers should use those current product controls deliberately rather than transferring an owner's account or password. The supplier should state which actions a proposed role enables and which deliverable depends on them.
- Invite a named organisational identity; do not send a personal or shared password.
- Require multi-factor authentication where the service supports it.
- Begin with read-only or the lowest suitable role and elevate only for an approved task.
- Keep factual approval, user management, billing, domain control and emergency ownership with the buyer.
- Use preview, staging, branches or change requests before production where practical.
- Preserve change history, approvals, test results and release evidence.
- Review access when scope, personnel or risk changes—not only at contract end.
- Remove identities, ownership tokens, service credentials and integrations at exit, then verify removal.
Write the supplier acceptance test
Before work starts, ask the supplier to return the proposed access register and explain why each role is needed. Accept the access plan only when every permission maps to an agreed task, the buyer retains an accountable owner, approval and activity evidence can be inspected, and expiry or revocation is testable.
At handover, request a final access list, exported buyer-owned deliverables, a record of outstanding changes, confirmation that supplier-held credentials and integrations were removed or transferred, and a buyer-side verification. A completed article, audit or dashboard is not a complete handover while unrecorded access remains active.
How SALIENS can work within your access controls
SALIENS provides GEO audits, AI visibility monitoring, content and technical improvements, and ongoing GEO delivery. We can define required inputs by deliverable, start with supplied exports or limited read access where appropriate, document any requested elevation, work through buyer approvals and include access reduction or removal in handover.
Email info@oxfordintelligence.co.uk with your website, target markets and languages, intended scope, systems in view, internal approvers and access constraints. SALIENS is operated by Oxford Intelligence Limited. Access does not change the fact that crawling, indexation, AI mentions, citations, rankings, traffic and enquiries are not guaranteed.
Sources
- UK National Cyber Security Centre: Identity and access management (checked 12 October 2026)
- UK National Cyber Security Centre: Using Software as a Service securely (checked 12 October 2026)
- Google Search Console: Managing owners, users and permissions (checked 12 October 2026)
- Google Analytics: Access and data-restriction management (checked 12 October 2026)
- SALIENS: GEO contract scope, exclusions and handover
Prepared with AI assistance using the linked sources and SALIENS service information.