Alistair.PEditor
SEO agencies lose time when access decisions remain implicit. A strategist assumes that a developer can edit a website; a client assumes that the agency owns its Search Console property; and an outgoing supplier may still have administrator access after the work has changed hands. An access register helps small organisations separate practical working permissions from legal and operational ownership. It records which systems matter, who is allowed to use them, the purpose of that access and the person responsible for approving changes. Its goal is not to collect passwords or grant everyone administrator rights. It is to help the right person perform an authorised task without creating unnecessary security, privacy or delivery risks.
Identify systems and the reasons access is needed
Begin with a short inventory of platforms used for the engagement: the content management system, website hosting, Google Search Console, analytics, tag management, an advertising platform, business profiles, reporting tools, ticket systems and shared documents where applicable. Every account should have a concrete job. Search Console might be necessary to examine indexing and search performance. A CMS editor role may be needed to draft or publish approved text. Hosting-level permissions are a different matter because they can affect routing, security or the website's availability.
Do not list a platform merely because the agency has used it in another project. Confirm whether it is actually part of this engagement and whether another authorised supplier manages it. If the company no longer uses a particular dashboard, its continuing access deserves review rather than automatic preservation. Include the official property or service name, its business owner, the authorised agency role and any pending dependency. Avoid storing raw account recovery information in a spreadsheet. The register is an index of permissions and decisions, not a secret store.
For a small company, the difference between an account owner and a working user can be decisive. A marketing analyst should be able to review relevant data without necessarily possessing the ability to delete properties, add unlimited administrators or change website infrastructure. Keeping that distinction visible reduces accidental overreach and helps the client retain control when external providers change.
Separate ownership from day-to-day permissions
Ownership establishes who can make foundational decisions about an account. A delegated role determines what somebody can actually do for a particular task. The two should not be confused. A client that owns its website may authorise a developer to deploy code and an editor to revise articles, but that does not transfer the company's ultimate responsibility for customer-facing claims or data handling. Similarly, a consultant can analyse a Search Console property without becoming the verified owner of that property.
Google's Search Console user and ownership guidance describes the different roles and capabilities available on that platform. Use the current provider settings rather than assuming every tool uses identical terms. Analytics roles may offer other combinations of viewing, editing and administrative privileges. Record the actual granted role, not a shorthand label that conceals elevated permissions. Where multiple accounts or properties exist, verify which one corresponds to the relevant website and market.
Limit permissions to the job and period for which they are required. An agency preparing recommendations might need reporting access but not production publishing rights. An implementation specialist may need a temporary deployment role but not ongoing access after acceptance. If somebody requests a higher privilege, identify the exact task and why the existing role cannot complete it. Granting broad control simply to avoid a conversation can create consequences much larger than the initial convenience.
Record the approval and invitation process
An access request should name the user or service identity, business purpose, requested role, intended scope, approver and expected review or removal date. This creates a small decision record and prevents account changes being reconstructed from memory. The client-owned administrator should confirm a request that changes meaningful permissions. An agency manager may approve that an employee needs a certain tool, but that internal approval does not automatically grant authority to change a client's property.
Use individual accounts wherever the provider supports them. Shared login credentials make it harder to identify who changed a setting, and password distribution through email or ordinary project notes introduces unnecessary risk. Where service identities or automation credentials are genuinely needed, document the custodian, precise function and rotation or revocation procedure through the organisation's approved security route. Do not place the token itself into the access register.
Verify that the invitation was actually accepted and that the person can perform the agreed task. A pending email is not evidence of working access. Likewise, an invitation that grants a broader role than authorised should be corrected. A status such as requested, approved, invited, confirmed, suspended or revoked is useful, but it should reflect the actual platform state. Record meaningful exceptions explicitly so a future colleague understands why work remains blocked.
Include access dependencies in the delivery plan
Permissions can determine when an SEO task is ready. A redirect recommendation cannot be implemented without an authorised route to the hosting or server environment. A content update may be drafted but await a publishing owner. A reporting assignment may depend on access to the correct Search Console property or analytics view. Recognising these dependencies early reduces time spent preparing work that nobody is yet able to complete.
Make the dependency precise. Instead of writing 'waiting for access', state which property, role and authorised inviter are required, and what work becomes possible after permission is confirmed. A consultant may be able to complete source research and prepare a test specification while implementation remains blocked. That is legitimate partial progress, but it should not be reported as deployed work. Keep approval, preparation, database persistence, public deployment and acceptance as separate states.
Some access questions expose deeper ownership problems. A company may discover that a former supplier created its analytics property using the supplier's credentials or that several websites share a management account. Do not attempt to take over the account through unofficial means. Follow the provider's supported transfer and verification process, involving the current legitimate owner and the client. Document the resolution, including any limitations that remain.
Protect data while maintaining useful reporting access
SEO platforms can expose commercially sensitive information, account configurations and sometimes personal data. A person who needs search impressions may not require raw identifiable customer enquiries. Assess the minimum information needed for the task before exporting or granting access. The UK ICO's data-minimisation guidance provides relevant principles for personal data, while contractual and platform requirements may impose additional restrictions. The guidance does not grant blanket permission to retain copies indefinitely.
Separate public metrics from restricted customer-level information in the engagement workflow. A Search Console report can show clicks and impressions, but it does not identify a specific paying customer or establish the source of a sale. A CRM may contain much more sensitive records. Avoid giving a reporting assistant unrestricted customer-data access solely to produce a page-level SEO chart. Where a report requires information from several systems, agree the approved aggregation and access method.
Consider what will happen when an employee changes roles or leaves. Their individual access should be reviewed in the same way as an external supplier's. The register should not expose private personal information beyond what is necessary to administer permissions. An authorised contact or role is often more appropriate than copying full personal dossiers into a widely shared operations document.
Review permissions at meaningful milestones
Access review is not only a task for project kickoff. Revisit permissions after a change of agency, an account handover, a major deployment, an incident or completion of a temporary specialist assignment. A small team may not need a complex automated governance platform, but it does need a reliable owner and a habit of checking actual platform settings. A row marked revoked because somebody sent an email is not evidence of revocation; confirm the provider's current permissions list where authorised.
Remove access that is no longer needed in an orderly manner. Before revoking an outgoing provider, verify that the client retains a legitimate owner and that required deliverables and approved records have been transferred. Reassign automation and reporting tasks if their service account or integrations would otherwise break. Keep the minimum necessary final evidence under the agreed retention rules; do not retain a secret administrative login as a substitute for a proper handover.
Record remaining uncertainty honestly. An agency may be unable to inspect one tool's user list and therefore cannot certify that every account was removed. That is a specific open check requiring the system owner's confirmation. Never claim organisation-wide security compliance from a single spreadsheet or assume that deleting an agency email account automatically removes every integration token associated with it.
Connect permissions to actual production verification
A working permission is not proof that a project task succeeded. If an editor obtains CMS access and saves a long article, a native database read-back can confirm content persistence. The public site may still display cached text, omit a comparison table or fail to load an image. Similarly, a developer with deployment rights can release a redirect configuration that does not send old URLs to relevant destinations. Those implementation outcomes require their own tests and owners.
Plan who can perform the verification before a task is assigned. A content reviewer may inspect the rendered article, links and mobile layout, while an engineer checks HTTP responses. For meaningful customer actions, an authorised person should test the route through to the expected receiving system. If the necessary browser or production access is unavailable, label that acceptance check open rather than equating an access request with completion. This keeps client reporting precise without denying progress already made.
A role matrix can clarify responsibility: the client approves business claims and strategic access, the agency prepares and reviews authorised work, the technical owner deploys code, and a designated reviewer verifies the public result. In a small organisation, a person may perform several functions, but approvals and evidence should still be distinguished.
Keep the register simple enough to maintain
A practical row contains the system and property, purpose, legitimate owner, delegated user or service role, effective permission, approval reference, date confirmed, review trigger and actual current state. Link to the provider's permissions screen or approved evidence where that is permitted instead of replicating sensitive records. A useful example may say that a Search Console viewer role was granted to a named agency team member to investigate a defined property, with a scheduled review when the engagement closes. It should not contain that person's password.
Use the register to support real decisions rather than to manufacture a complete-looking table. If a role or owner is unknown, mark it for investigation. If the account is not relevant to the engagement, exclude it or close the record. If a former supplier still holds rights, give an authorised person responsibility for the review. The value lies in consistent, defensible information about who can do what and why—not in the number of columns.
For a UK SEO agency, a disciplined access register reduces handover friction, protects client control and helps teams identify delivery dependencies early. It also makes a crucial boundary explicit: permission to act is not evidence that an action worked. Manage access through appropriate owners, verify changes on the real platform and report unresolved permissions honestly. That approach supports both reliable delivery and more trustworthy relationships with clients.