Translate the audit into an access list
An audit request should identify the evidence needed, not ask for every account the client owns. List the systems, exact properties and reports required for the agreed scope. For each, state the task, proposed role, named recipient and planned review or removal date. Separate reading evidence from making changes.
Keep this register free of passwords, recovery codes and authentication secrets. The client can grant access through the service’s own user-management feature while continuing to use their own account. A named recipient also makes it easier to identify whose access should end when the assignment finishes.
Choose the role from the actual task
Google recommends read access to Search Console at the audit stage. Its permissions documentation distinguishes owners, full users and restricted users: a full user can take some actions, while a restricted user has simple viewing rights to most data. Do not describe every non-owner role as read-only.
Check the current permission table against the evidence needed. If a requested report is unavailable under the proposed role, document that specific limitation and ask the owner to choose a suitable approach. A targeted export or an owner-led demonstration may answer a narrow question without granting broader standing access.
Have the owner grant and verify access
For Search Console, Google places user management under Settings, then Users and permissions, and requires a property owner to grant permissions. Give the owner the intended recipient account and exact property reference, then let the owner perform the grant. Do not ask them to send their password or a sign-in code.
After access is granted, the recipient signs in using their own account and verifies the property and required reports. Record the role actually observed and any missing evidence. Seeing a similarly named site in a selector is not enough; confirm that the domain or URL-prefix scope matches the audit brief.
Illustrative onboarding with a missing report
Imagine a fictional consultant reviewing a client’s public services site. The access register requests the agreed Search Console property for a named work account. The client grants the selected viewing role, and the consultant verifies the relevant performance report without requesting access to the client’s inbox or hosting account.
If another diagnostic view is unavailable, the consultant records the gap and asks for a dated export or a supervised review of that view. The client decides whether a role change is justified. This example illustrates a decision process, not a claim that one role exposes every report or that access has been granted to a real account.
Close access as part of the handover
At the end of the audit, review the access register with the client. Remove grants that are no longer needed through the relevant service and record the result. If ownership was granted, review the service’s ownership-removal instructions as well: Google notes that a remaining verification token can allow a removed verified owner to verify again.
Do not remove unknown site tokens or other people’s permissions casually; identify the grant and its owner first. Agree on retention of audit exports separately from account access. The completed handover should list the evidence delivered, the access still justified and the items removed, so the next SEO review starts with a clear boundary.